第 5 课:子代理与上下文隔离
学习目标:
- 能说清子代理为什么算一种上下文管理手段:干净窗口加摘要回传,把「过程」挡在主窗口之外
- 能用「过程 token 与结论 token 的比例」加上真实成本数据,判断一个任务值不值得派给子代理
- 能把子代理派发逻辑接进你在本系列第 7 门课写的 harness 循环,保证每次派发只有一条摘要回流主窗口
前置要求:完成第 4 课的压缩与笔记,手边能跑起你在本系列第 7 门课《Agent Harness 基础:循环与控制》写的 harness 循环 | 上一课 第 4 课 << | 下一课 第 6 课 >>
视角切换:这次不谈分工,只谈隔离
在本系列第 6 门课《多 Agent 协作入门》里,你已经见过子代理了:任务怎么拆、结果怎么汇报、几个 Agent 怎么配合。那门课回答的是「多个 Agent 怎么协作」。本课只回答一个新问题:子代理凭什么算一种上下文管理手段?
换句话说,就算你只有一个「主角」Agent,完全不需要团队协作,你仍然会想用子代理——不是为了分工,是为了隔离。
回想第 1 课的预算观:模型在解析上下文时靠的是一份「注意力预算」,每个新进入上下文的 token 都会消耗掉一点1;token 越堆越多,模型从上下文里准确回忆信息的能力就会下降1。而 Agent 恰恰是最能堆 token 的场景——循环里每跑一轮都在产生新数据,而这些数据都「可能与下一轮推理相关」,扔也不是,留也不是1。
最扎心的是探索类任务。假设主代理要在一个几十万行的仓库里查清某个废弃 API 的所有调用点:grep 十几次、打开二十个文件、读几千行代码——这些中间内容动辄几万 token,而真正需要留下的结论可能就五行:「调用点集中在这三个模块,迁移顺序建议是……」。如果这一切都发生在主窗口里,注意力预算就被「过程」吃掉了,留给「结论」和后续工作的所剩无几。
子代理,就是对着这个问题下刀的。
机制:干净窗口进去,压缩摘要出来
机制本身一句话就能说完:专门的子代理在干净的上下文窗口里处理聚焦任务1;探索产生的大量中间内容——搜索结果、文件原文、试错记录——全部留在子代理体内1;最后回传给主代理的,只是一份压缩提炼过的摘要,常见 1,000-2,000 token1。
主代理的窗口因此只承担「结论」,不承担「过程」。这是一种不对称设计:子代理体内可能烧掉了几万 token 的探索,但离开它的只有一小段文字。
落到代码上,就是给你在本系列第 7 门课写的 harness 换个开局。为了让代码紧凑,这里把那门课循环里反复出现的两个动作包成辅助函数:textOf 取出回复里的文本块,appendToolResults 执行这一轮的工具并把 tool_result 追加进消息数组(它内部做的正是你在那门课手写过的「执行每个 tool_use、集中回传」那几行)。
注意三个细节。第一,messages 从一条孤零零的任务描述起步,主代理的历史一个字都没带——这就是「干净窗口」的全部含义。第二,函数返回的是 textOf(response),一段纯文本;循环里垫起来的几十条工具往返,随着局部变量 messages 的销毁一起消失。第三,子代理的系统提示明确要求「不要复述原文」,摘要的压缩质量是在这里定调的。
主代理那一侧,派发动作就是一个普通工具,接进你已有的 stop_reason 循环即可:
留意 task 字段的描述:「自包含的任务描述,子代理看不到本对话的历史」。这句话是写给主代理看的——它必须把任务讲完整,因为对面是个失忆的新窗口。工具描述把用途和边界写到这么明确,正是第 2 课讲过的「工具即上下文」:工具要自成一体、对预期用途极其清晰1。
第一手数据:子代理是「智能过滤器」
机制讲完了,来看实测。Anthropic 公开复盘过他们的多 Agent 研究系统——Claude 的 Research 功能背后的那套架构——这是一份难得的第一手工程材料2。
其中和本课直接相关的三个结论:
- 子代理各占独立的上下文窗口并行运转,压缩正是靠这一点实现的2。每个子代理都在自己的窗口里展开探索,互不挤占。
- 他们把子代理称作「智能过滤器」(intelligent filters):替主代理把最重要的 token 浓缩出来2。过滤器这个词很准——进去的是语料,出来的是要点。
- 一句值得反复咀嚼的总结:「搜索的本质是压缩:从庞大的语料中蒸馏出洞见。」2放在本课的语境里读:子代理做的每一次探索,最终都是为了产出那份千余 token 的蒸馏物。
顺带一提,并行本身还带来速度收益——几路调研同时推进。但那属于编排的话题,本系列第 6 门课已经讲过;本课只盯住压缩这一面。
成本的另一面:隔离不是省钱术
把好处讲完,必须把账单也摊开。还是那份复盘给出的实测数字——注意,这些是 Anthropic 那套研究系统的测量结果,不是放之四海的定律:
- Agent 的 token 用量通常约是普通聊天交互的 4 倍2;
- 多 Agent 系统约是聊天的 15 倍2;
- 在他们分析性能来源时,token 用量这一个变量就解释了 80% 的性能方差2。
他们自己的结论也很坦白:「多 Agent 系统之所以有效,主要是因为它们帮你花足够多的 token 去解决问题。」2
所以把话说透:子代理不是省钱术。 总 token 只会花得更多——任务描述要重复交代,背景要重新铺,几个窗口同时在烧。它买到的是另一样东西:每个窗口都待在不腐化的区间里,注意力密度始终维持在高位。这是一笔「花更多总 token,换每个窗口都干净」的注意力交易。
什么时候值得成交?回到第 1 课的预算观:上下文是边际收益递减的有限资源1。给你两道判断题:
- 过程/结论比:这个任务的中间内容有多大,最终结论有多小?比例越悬殊,隔离的收益越大。反过来,过程本来就短的任务,派出去纯属浪费交接成本。
- 复杂度是否可证明地改善结果:Anthropic 的建议是,只在复杂度能被证明改善结果时才考虑增加它——原文的口气是「consider」,这是一条分寸建议,不是铁律3。多花的 token 若换不来更好的产出,就该退回单窗口方案。
长任务组合技:笔记打底,交接续航
子代理的窗口再干净,也一样有限。真正的长时程任务,那份复盘描述的做法是组合技:每完成一个工作阶段就做总结,把关键信息存进外部记忆2;然后起一个带干净上下文的新子代理接着干,靠仔细的交接维持连续性2。
这正好把第 4 课和本课串成了一套动作:
- 第 4 课的结构化笔记负责「把关键状态放到窗口之外」——NOTES.md 也好,任务清单也好,它们活在文件系统里,不占任何窗口的注意力;
- 本课的隔离负责「让每一段工作都在干净窗口里进行」——新子代理开局第一件事就是读笔记,它不需要继承前任的完整历史,只需要继承前任蒸馏过的要点。
交接文档里该写什么?直接沿用第 4 课压缩时的取舍标准:架构决策、未解决的问题、关键实现细节留下,冗余的工具输出丢掉1。写交接和写压缩摘要,本质上是同一门手艺,只是读者从「未来的自己」换成了「下一个子代理」。
在 Claude Code 里,这套机制长什么样
最后对照一个你天天在用的实现。Claude Code 的官方最佳实践把话说得很直接:上下文窗口填得很快,而且性能会随着填充而下降;「上下文窗口是最需要管理的资源」4。既然上下文是根本约束,子代理就成了手头最有力的工具之一4。
它的实现和本课讲的机制一致:子代理在独立的上下文窗口里运行,只向主对话回报摘要4。你让 Claude Code「查清这个 bug 的根因」,它派出的子代理会去 grep、读文件、顺着调用链摸——这些探索都发生在子代理自己的窗口里,主对话最后只收到一段调查结论。调查类、搜索类的活交给子代理,主上下文就不会被探索过程吃光4。
你在界面上看到一个子任务在后台跑、结束时主对话里只多出一小段汇报——那背后就是本课从头讲到尾的「干净窗口进去,压缩摘要出来」。
到这里,长任务的三件套你都见齐了:压缩(第 4 课)、结构化笔记(第 4 课)、多 Agent 架构(本课)——它们共同的目标,是让 Agent 在长动作序列上保持连贯、不丢上下文、始终朝着目标走1。第 6 课我们动手把这三件套装进你自己的 harness。
小结
- 子代理是一种上下文管理手段:聚焦任务在干净的上下文窗口里进行,探索的中间内容隔离在子代理体内,回传的常见只是 1,000-2,000 token 的提炼摘要——主窗口只承担结论,不承担过程1。
- 在 Anthropic 的多 Agent 研究系统里,子代理各占独立上下文窗口并行运转、以此实现压缩,充当替主代理浓缩最重要 token 的「智能过滤器」;「搜索的本质是压缩」2。
- 同一系统的实测数字:Agent 的 token 用量约是聊天的 4 倍,多 Agent 系统约是 15 倍,而 token 用量这一个变量就解释了 80% 的性能方差——隔离是「花更多总 token,换每个窗口不腐化」的注意力交易,不是省钱术2。
- 值不值得隔离,看过程/结论比,也看增加的复杂度是否可证明地改善结果——Anthropic 的措辞是「consider」,是分寸建议而非铁律3。
- 长任务组合技:阶段完成即总结、要点存入外部记忆,再带干净上下文起新的子代理,靠仔细交接维持连续性——第 4 课的笔记与本课的隔离是配套动作2。
- Claude Code 中上下文窗口是最需要管理的资源,子代理因此是最有力的工具之一:在独立窗口运行,只向主对话回报摘要4。
>> 第 6 课:实战:给 harness 装上上下文管理