Sub-agent 是个被低估的工具

2026-04-08

用 Claude Code 几个月之后，我越来越倾向于把任何"看起来要翻 10 个以上文件"的探索性任务丢给 sub-agent，而不是让主 agent 自己 grep 进去。

原因不是节省 token，而是保护主上下文。

主上下文的容量是认知容量

主 agent 的上下文窗口本身可能很大，但有效注意力是有限的。如果主 agent 一边在帮我推进一个 PR，一边塞了 20 个 grep 结果、5 个文件的全文、3 段错误日志——它在做下一步决策的时候，能稳定调用到的 "前情提要" 实际上就被稀释了。

你能感受到这件事，但很难量化。表现是：聊到一半模型开始忘记你十几轮之前定下的规矩；再问一遍，它"恍然大悟"地修正过来。

这一刻的体验很像和一个被噪音淹没的人对话——他不是不聪明，是带宽被占满了。

Sub-agent 是带宽墙

Sub-agent 的妙处在于：它独立 fork 一个上下文去执行重活，干完只把一份精炼的报告递回来。主 agent 拿到的只是结论，不是过程中的所有原始资料。

等价的人类版本就是：你不要让一个人一边写报告一边在搜索引擎里翻 30 个 tab，应该让他派一个实习生去搜，等实习生汇总几句关键发现回来再看。

具体什么时候我会用：

• "这个 bug 可能跟以前的某个 commit 有关，去看看 git log"
• "看看代码库里所有用到了 X 函数的地方，哪些可能受影响"
• "读这份 200 行的设计文档，告诉我里面有没有提到 Y"
• 独立的、可并行做的几件事——一次发出几个 sub-agent

什么时候不用：

• 需要 sub-agent 做判断而不是收集事实——它的判断不一定符合主 agent 的上下文
• 事情本身就两三步，自己做更快
• 需要写代码——sub-agent 写完代码主 agent 还要 review，反而更绕

给 sub-agent 写好 prompt 的几个细节

派给 sub-agent 的 prompt 写法和给主 agent 不一样。它没有这场对话的上下文，每次都是冷启动。我自己的几个习惯：

1. 把目的说清楚，不要只说步骤。"检查 X 是不是 Y" 比 "grep X" 信息量大得多——sub-agent 知道目的之后会判断步骤。
2. 限定输出长度。"用 200 字以内汇报"，不然它会写 1000 字的过程，给主 agent 增加注意力负担。
3. 说清楚你要的是事实还是判断。"列出所有调用点" vs "判断这次重构会不会破坏什么"——两种 prompt 你期待的精度不一样。
4. 一次只让它做一件事。把"调研 + 写代码"塞给一个 sub-agent，它给回来的 PR 通常会带半生不熟的代码片段。让它先调研，调研结果回到主 agent，再决定下一步。

这个工具的真正价值

sub-agent 改变的不是"我能干多少事"，是"我在主流程里需要持有多少东西"。

大多数复杂任务卡住的原因不是不会做某一步，是同时要持有的状态太多——这一段代码的语义、那一段文档的承诺、上次讨论的结论、当前修改的风险。每多一件事在脑子里，下一步就更容易判断错。

把"调研"这一类纯收集型工作外包出去，是减少持有量。这件事在用 AI 之前我只能靠笔记和待办来缓解，效率有限。现在能让 sub-agent 当我的"短期记忆代理"，做完之后只丢一句话回来，省下来的脑力可以全部留给真正需要判断的部分。

这才是 AI coding 工作流改变最大的地方——它让我能更稳定地保持一个干净的工作焦点，而不是"更快地写完代码"。