主对话塞太多东西后期回答质量断崖式下跌这事我深有体会。我之前让 Claude Code 一次性跑代码审查 测试用例生成 Bug 修复前几轮回答得还算有模有样到第五轮开始它就忘事把 CamelCase 又写回了 snake_case提出的修复方案跟前面自己的结论打架。原因不复杂——上下文窗口的信噪比失衡了。过程日志、工具调用、中间推理全堆在主对话里真正需要保留的结论反而被稀释。顺便一提我做雷达鸭 App一个收录中国一人公司赚钱案例的华为应用市场 微信小程序Uni-app arkTS UniCloud 技术栈时代码审查和测试用例生成这两件事就是用流水线子智能体分开跑的主对话干净得能直接交付。主对话是怎么被塞爆的把 Claude Code 当聊天框用什么任务都往里塞这事我都干过。一次重构任务跑下来主对话里堆着原始代码约 5 万 token、搜索过程约 3 万 token、中间推理约 2 万 token、测试输出日志约 4 万 token。等你想让它做最终决策时留给决策的有效上下文已经被挤到角落。模型不是失忆是被噪声淹没了。子智能体干的事就是把这个过程搬走在独立的子上下文里跑完整个脏活只把结论塞回主对话。主对话保持清爽模型每次决策都基于干净的输入。子智能体长什么样子智能体就是一个 markdown 文件丢在.claude/agents/目录下frontmatter 里写清楚身份和权限!-- .claude/agents/code-reviewer.md -- --- name: code-reviewer description: 审查代码质量、安全漏洞和性能问题的专家。 当用户要求代码审查、安全审计或质量评估时使用。 tools: - Read - Grep - Glob model: sonnet permissionMode: plan --- 你是一个资深的代码审查专家拥有十年以上的工程经验。 ## 审查维度 ### 安全性 - 检查硬编码凭证API Key、密码、Token - 检查 SQL 注入、XSS、CSRF 等注入漏洞 - 检查输入验证的完整性 - 检查敏感数据的处理方式是否加密、是否打日志 ### 代码质量 - 函数是否遵循单一职责原则 - 命名是否清晰、一致 - 是否存在重复代码DRY 原则 - 错误处理是否恰当不吞异常、不用空 catch ### 性能 - 是否有不必要的循环嵌套O(n^2) 以上的复杂度 - 数据库查询是否存在 N1 问题 - 是否有未关闭的资源文件句柄、数据库连接 ## 输出格式 ### 审查摘要 [一段话总结整体代码质量包括亮点和主要问题] ### 发现的问题 - [严重/主要/次要] 问题描述 at file_path:line_number ### 改进建议 [按优先级排列的具体改进建议]frontmatter 这五件套你得记牢name唯一标识主对话靠它派活description路由依据Claude 根据这段话判断什么时候自动 spawn 这个子智能体tools白名单没列出来的工具子智能体拿不到——最小权限原则model可以指定 haiku / sonnet / opus跑测试这种确定性高的活用 haiku 就够单次成本比 sonnet 低一个数量级permissionModeplan 模式只读、acceptEdits 能改文件按需开CEO 委派模型主智能体在子智能体面前扮演 CEO派活、收结论、不做执行。子智能体在自己的上下文里跑完整个调查过程吐出来的就是一个摘要。主对话里出现的不是 “Grep 搜索了 30 个文件发现 5 处疑似 SQL 注入逐个分析…”而是 “发现 2 处 SQL 注入高危位于 userController.js:42 和 orderDao.js:118”。信噪比一下就拉开。CEO 不需要看员工翻了多少档案只要结论。三种协作形态子智能体不是只能单打独斗三种形态覆盖了大多数场景。并行型——多个专家同时干活结果汇总。代码审查可以同时 spawn 三个安全审查员、性能审查员、质量审查员各自跑各自的维度主对话最后合并三份报告。三个独立上下文互不污染。流水线型——串行处理链前一个的输出是后一个的输入。最经典的就是 Bug 修复bug-locator 定位根因bug-fixer 基于定位结论修复bug-verifier 验证修复。每个阶段在自己的上下文里跑阶段间靠固定的输出格式契约传递。团队型——多个会话自组织协作主智能体通过 SendMessage 在子智能体之间传递消息。适合大型特性开发任务自动分解分配。上下文隔离的量化对比我做过一次实测同一个代码审查任务5000 行 ArkTS 代码两种跑法的 token 占用差距非常明显指标主对话直跑子智能体跑主对话过程 token8.6 万0主对话结论 token0.3 万0.3 万子智能体上下文08.4 万主对话有效信噪比3.5%100%后续轮次回答质量明显衰减稳定差距很明显。子智能体那一栏的过程 token 不进主对话主对话里只剩下结论。后续再让它做决策时模型看到的全是有效信息不会被 8.6 万 token 的过程噪声稀释。这就是为什么我前面说后期回答质量断崖式下跌——主对话直跑到第五轮信噪比已经掉到 3.5%模型当然开始忘事。成本上也有讲究。test-runner 我配的是 haiku!-- .claude/agents/test-runner.md -- --- name: test-runner description: 运行项目测试套件并分析测试结果。 当用户要求运行测试、检查测试覆盖率或分析测试失败原因时使用。 tools: - Read - Grep - Glob - Bash model: haiku --- 你是一个测试执行专家。你的核心价值是 从大量测试输出中提炼关键信息为主对话提供精准的测试摘要。 ## 执行流程 1. 确认项目的测试命令查看 package.json 或 CLAUDE.md 2. 运行测试套件 3. 分析输出区分通过和失败的测试 4. 对失败的测试定位失败原因 ## 输出格式严格遵守 ### 测试摘要 - 总计X 个测试 - 通过X 个 - 失败X 个 - 跳过X 个 ### 失败详情仅列出失败的测试 - test_name: 失败原因一句话at file_path:line_number ### 建议 [如果有明显的失败模式给出修复方向] 注意不要在输出中包含完整的测试日志。 只输出上述格式的摘要信息。跑测试这种不需要复杂推理的活haiku 足够省钱又快。流水线型的契约式输出流水线型最容易踩的坑就是阶段间格式不固定。bug-locator 今天输出根因在 xxx明天输出问题出在 xxxbug-fixer 根本解析不了。所以上游必须严格按契约输出!-- .claude/agents/bug-locator.md -- --- name: bug-locator description: 定位 Bug 的根本原因 tools: - Read - Grep - Glob permissionMode: plan --- 你是 Bug 定位专家。你的任务是找到 Bug 的根本原因。 ## 定位流程 1. 理解症状分析错误信息和复现步骤 2. 搜索相关代码通过关键词和文件模式定位可疑区域 3. 追溯调用链从错误点向上追溯到根因 4. 确认根因明确说明是哪行代码导致了问题 ## 输出格式下游阶段依赖此格式请严格遵守 根因文件[file_path:line_number] 问题描述[一句话说明根因] 调用链[从入口到出错点的完整路径] 修复方向[简要的修复思路]下游 bug-fixer 的消费方式也写死!-- .claude/agents/bug-fixer.md -- --- name: bug-fixer description: 基于定位结果修复 Bug tools: - Read - Grep - Glob - Edit - Write - Bash --- 你是 Bug 修复专家。你将收到 bug-locator 的定位结论 基于此进行修复。 ## 修复原则 1. 最小改动只改必须改的代码不做无关重构 2. 不引入新问题修复不能破坏其他功能 3. 保持风格一致遵循项目现有代码风格 4. 添加防御性代码防止同类问题再次发生 ## 输出格式 修改的文件[file_path_1, file_path_2, ...] 每处修改的原因[逐一说明] 潜在副作用[如果有的话] 建议的测试命令[用于验证修复的命令]四行字段、固定顺序、固定标签。bug-fixer 读到 “根因文件” 就知道从这行取路径读到 “修复方向” 就知道这是上下文提示。这种契约一旦定下来整条流水线就稳了。我自己的规则是上游输出格式一旦修改必须同步改下游解析逻辑跟改 API 一个待遇。结尾反正我以后凡是过程噪声大、只需要结论回流的任务一律丢给子智能体。主对话只留给真正需要多轮交互的决策。上下文干净得像新装系统模型每次回答都在最佳状态。标签Claude Code / 子智能体 / 上下文隔离 / AI工程 / Harness个人介绍雷达鸭 App 独立开发者10 年软件开发经验软件设计师 人工智能应用工程师专注鸿蒙 ArkTS Web 前端探索 AI 自动化。MIT 声明本文基于《Claude Code 实战Harness 工程之道》黄佳著第 4 章内容整理实践遵循 MIT 协议。