学习目标：
在本系列第 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。
其中和本课直接相关的三个结论：
顺带一提，并行本身还带来速度收益——几路调研同时推进。但那属于编排的话题，本系列第 6 门课已经讲过；本课只盯住压缩这一面。
把好处讲完，必须把账单也摊开。还是那份复盘给出的实测数字——注意，这些是 Anthropic 那套研究系统的测量结果，不是放之四海的定律：
他们自己的结论也很坦白：「多 Agent 系统之所以有效，主要是因为它们帮你花足够多的 token 去解决问题。」2
所以把话说透：子代理不是省钱术。 总 token 只会花得更多——任务描述要重复交代，背景要重新铺，几个窗口同时在烧。它买到的是另一样东西：每个窗口都待在不腐化的区间里，注意力密度始终维持在高位。这是一笔「花更多总 token，换每个窗口都干净」的注意力交易。
什么时候值得成交？回到第 1 课的预算观：上下文是边际收益递减的有限资源1。给你两道判断题：
子代理的窗口再干净，也一样有限。真正的长时程任务，那份复盘描述的做法是组合技：每完成一个工作阶段就做总结，把关键信息存进外部记忆2；然后起一个带干净上下文的新子代理接着干，靠仔细的交接维持连续性2。
这正好把第 4 课和本课串成了一套动作：
交接文档里该写什么？直接沿用第 4 课压缩时的取舍标准：架构决策、未解决的问题、关键实现细节留下，冗余的工具输出丢掉1。写交接和写压缩摘要，本质上是同一门手艺，只是读者从「未来的自己」换成了「下一个子代理」。
最后对照一个你天天在用的实现。Claude Code 的官方最佳实践把话说得很直接：上下文窗口填得很快，而且性能会随着填充而下降；「上下文窗口是最需要管理的资源」4。既然上下文是根本约束，子代理就成了手头最有力的工具之一4。
它的实现和本课讲的机制一致：子代理在独立的上下文窗口里运行，只向主对话回报摘要4。你让 Claude Code「查清这个 bug 的根因」，它派出的子代理会去 grep、读文件、顺着调用链摸——这些探索都发生在子代理自己的窗口里，主对话最后只收到一段调查结论。调查类、搜索类的活交给子代理，主上下文就不会被探索过程吃光4。
你在界面上看到一个子任务在后台跑、结束时主对话里只多出一小段汇报——那背后就是本课从头讲到尾的「干净窗口进去，压缩摘要出来」。
到这里，长任务的三件套你都见齐了：压缩（第 4 课）、结构化笔记（第 4 课）、多 Agent 架构（本课）——它们共同的目标，是让 Agent 在长动作序列上保持连贯、不丢上下文、始终朝着目标走1。第 6 课我们动手把这三件套装进你自己的 harness。
Effective context engineering for AI agents — Anthropic Engineering — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11
How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13
Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2
Best practices for Claude Code — Claude Code Docs — https://code.claude.com/docs/en/best-practices ↩ ↩2 ↩3 ↩4 ↩5
LegacyLedgerReader API 的调用点，并给出迁移顺序建议。对每个任务写下你的决定——隔离（派子代理）还是不隔离（主窗口直接干），需要并行的说明并行——并用本课的判断标准各写一两句理由。
症状：派了三次调研之后，主代理的上下文占用就逼近窗口上限，你在第 4 课装上的压缩逻辑被迫提前触发；检查主代理的消息数组，发现其中绝大部分 token 是子代理当初的工具返回原文。
请指出病根，修改代码，使每次派发之后主窗口只增加一条摘要消息。
Jot down thoughts, sticking points, things you didn't get. Written to this course's appendix only — the lesson file is never touched.
const SUBAGENT_SYSTEM = `你是一个调研子代理。
完成任务后, 输出一段不超过 1500 token 的结论:
关键发现、涉及的文件路径、给主代理的行动建议。
不要复述你读到的原文。`;
async function runSubagent(client, task, maxTurns = 15) {
// 关键就在这一行: 全新的消息数组, 不带主代理的任何历史
let messages = [{ role: "user", content: task }];
for (let turn = 0; turn < maxTurns; turn++) {
const response = await client.messages.create({
model: "claude-sonnet-5",
max_tokens: 4096,
system: SUBAGENT_SYSTEM, // 子代理自己的系统提示
tools: SEARCH_TOOLS, // 只给探索要用的工具
messages,
});
if (response.stop_reason === "end_turn") {
return textOf(response); // 只有这段文字会离开子代理
}
// 执行工具, 结果追加进 messages, 全部留在子代理体内
messages = await appendToolResults(messages, response);
}
return "调研未在轮次预算内完成";
}
const DISPATCH_TOOL = {
name: "dispatch_research",
description:
"把一个聚焦的调研任务派给子代理, 返回它的结论摘要。" +
"适用于需要大量探索、但结论可以简短表述的任务。",
input_schema: {
type: "object",
properties: {
task: {
type: "string",
description: "自包含的任务描述, 子代理看不到本对话的历史",
},
},
required: ["task"],
},
};
async function handleDispatch(mainMessages, toolCall) {
const summary = await runSubagent(client, toolCall.input.task);
mainMessages.push({
role: "user",
content: [{
type: "tool_result",
tool_use_id: toolCall.id,
content: summary, // 主窗口只多了这一条
}],
});
}
async function runSubagent(client, task, maxTurns = 15) {
let messages = [{ role: "user", content: task }];
for (let turn = 0; turn < maxTurns; turn++) {
const response = await client.messages.create({
model: "claude-sonnet-5",
max_tokens: 4096,
system: SUBAGENT_SYSTEM,
tools: SEARCH_TOOLS,
messages,
});
if (response.stop_reason === "end_turn") {
// 把最终回复也拼上, 返回完整历史
return [
...messages,
{ role: "assistant", content: textOf(response) },
];
}
messages = await appendToolResults(messages, response);
}
return messages;
}
async function handleDispatch(mainMessages, toolCall) {
const subHistory = await runSubagent(client, toolCall.input.task);
mainMessages.push({
role: "user",
content: [{
type: "tool_result",
tool_use_id: toolCall.id,
// 整段历史渲染成文本塞回主窗口
content: renderAsText(subHistory),
}],
});
}