章节主旨
讲 子代理:为什么需要它(上下文污染拖垮质量)、它靠什么解决(上下文隔离)、代价与收益、在 Claude Code 里怎么定义,以及作者真正常用的两种子代理——reviewer 与 document。
核心论点
- 上下文越塞越满,输出质量越差——detail 任务、调试、MCP 都在飞快烧 context,塞满即污染。(→ 详解1)
- 子代理的本质是上下文隔离:给它一块干净的独立 context 干脏活,只回传结论。(→ 详解2)
- 子代理不是免费的:多一层就多一次摘要,误差会累积,须权衡「省下的污染」是否大过「多加的误差」。(→ 详解3)
- 两大收益是上下文管理与并行化:主 agent 保持干净,多个子代理可同时跑,抓线索这类活能从数小时压到几十分钟。(→ 详解4)
- 子代理就是 markdown 文件,可由 agent 自己生成,但子代理不能再 spawn 子代理。(→ 详解5)
- 真正值得建的只有两种:reviewer(新眼睛审代码)和 document(把执行脚本的变更回写到 directive),并按最小权限配工具。(→ 详解6)
知识点详解
1. 为什么需要子代理:上下文污染 5:15:07
现在模型 context window 约 20 万到上百万 token,听着很大,但一旦挂上工具就消失得极快。detail 密集的任务、调试、任何 MCP,都因为那个「循环」在猛烧 token。不知不觉半个窗口就被中间产物的垃圾填满,成功输出的概率随之下降。
这种「窗口里堆满垃圾导致输出变差」的现象叫 context pollution:早期讲过的那层中期记忆被无关噪声塞乱了。
大量测试反复印证一条规律:context 里 token 越多,质量通常越差。曲线大致是——零上下文时表现一般;喂进恰当的示例和背景,短期内表现抬升;继续往里灌无关内容,质量就断崖下跌。作者早年做文案时甚至把写手限制在单次 256 token 以内,超过质量就崩;如今这个拐点大约挪到了 1 万 token 附近,但「越多越差」的关系没变,所以其他条件相同就尽量压低 context 里的 token。
2. 核心机制:上下文隔离 5:17:08
子代理解决污染靠的是 上下文隔离:凡是「子代理」而非主 agent 的一部分,就拿到一块全新干净的 context 窗口独立工作。你只给它一个任务,让它在自己的空间里干完所有脏活,最后只把相关结论返回。
普通对话里每轮问答都会层层堆叠 context:五个来回、每块一千词,下一次查询就要连着发五块加新问题、约六千词。把其中某一环换成子代理循环,就能把那部分整块从主上下文里抹掉——模型不再把中间过程原样存进 context,只留下那一步的产出摘要。作者点破:这跟 reasoning token 用完即弃是同一招,思考标签里的 token 并不计入主 context,都是为了减少污染窗口的垃圾总量。
数据也撑得住:Anthropic 用 Claude Code 做过测试,让 Opus 当 lead 指挥一批子代理各干小任务再汇报,结果在研究类任务上比单体 Opus 高出 90% 以上 5:19:41。作者提醒这是研究任务、token 消耗本就巨大,子代理占的便宜比日常任务大得多,别当成普适数字。
3. 代价:实现复杂度与误差累积 5:21:16
作者坦承自己过去两年一直不用子代理,觉得它只是徒增架构复杂度、模型自己就能办;直到模型智能到位,才开始有条件地用。
两个真实代价:一是实现复杂度——你在往里塞自己对「模型该怎么干」的偏见。二是 compounding errors:父代理要把任务摘要后交给子代理,这一步哪怕 99% 准确,步骤一多就滚雪球。他给的例子是单步 99.9% 准确率、拉到 1000 个任务后只剩约 36%。
所以判据很朴素:找到那种「多加步骤带来的误差」被「对 context 的正向作用」压过去的场景。没有拍脑袋就能算准的捷径,只能实测。作者的结论是目前只固定用两种子代理类型。
4. 两大收益:上下文管理与并行化 5:23:08
除隔离外,子代理还有两个大赢面。其一是上下文管理:主 agent 始终只留高相关的东西。把带 MCP 访问的活丢给子代理,让它们去加载各种 context、干完再汇报;只要子代理足够原子,就能反复推进而不污染主窗口。
其二是 并行化:子代理能同时跑。父 agent 一次 spawn 多个,它们各自独立、谁先干完谁先汇报,不是自上而下的顺序完成。你见过 Gemini/Claude 做研究时一下开三四个研究子代理、然后等它们全回来,就是这个机制。
抓线索是典型例子:三万条不必串行一条条爬,父 agent 开三个子代理、每个内部再并行,把总时长砍下来;全干完后各自把结果汇报回主 agent,主 agent 只需把几张清单拼起来——这比亲自编排爬取轻松得多。一件串行要三小时(含启停开销)的活,并行下可能只要 30 分钟,因为把启动和收尾这些固定成本合并了。
5. 落地形态:markdown 文件、anatomy 与不可递归 5:24:14
子代理跟 directive 一样,就是 markdown 文件。Claude Code 里放在 .claude/agents/;想跨整个项目目录全局可用就放到用户级目录,想只限某工作区就放项目里。其他 agentic 编码工具(Gemini、Codex 等)各有自家约定、尚无共识,但本质都是 system prompt,多花点前期功夫都能搭出等价物。
一个子代理文件的 anatomy:name、description、permissions(能访问哪些工具——在 DOE 框架 里就是 directive 和 execution)、然后是它专属的 system prompt。作者强调你不必手写这些,直接跟 agent 说「给我建个做 X/Y/Z 的子代理」,它会生成文件、放对文件夹、立即可用——agent 造 agent,颇为递归。
但有一条硬边界 5:26:16:agent 能创建子代理的定义,也能 spawn 子代理,但子代理不能再 spawn 子代理。这是内存与安全约束——否则层层 spawn 会指数爆炸,把 CPU 烧穿还带来安全隐患。所以父 agent 可以开任意多个子代理,但它们全部只向这个父 agent 汇报。
6. 两种实用子代理与最小权限 5:27:16
reviewer 子代理:orchestrator 自己写的代码,你问它「这代码如何」,它会因见过自己跑对的历史而偏向认为对,如同让人刚写完就审自己的文章。reviewer 拿到全新 context——只有 directive 和 execution、不告诉它用途,纯凭代码质量评判。这逼着代码必须自带文档、简单可读;它没背景反而能看出「同类代码通常有错误处理,这段却没有」并回建议。用法是在 agents.md 里写「每次写完脚本就调 reviewer 检查质量」,作者说这大概提升 5%–10% 准确率;也可手动随时点名它复查。
document 子代理 5:29:46:自退火过程里 agent 反复改脚本却常忘了同步 directive,导致次日新实例按旧 directive 跑就报参数不符、要花五到十分钟调试。document 子代理专门读脚本、把 directive 回写对齐。它拿对所有文件的读权限,但只对 directive 有写权限——保证信息永远是「从 execution 流向 directive」,不反向。
安全上作者搬来层级组织的 least privilege 5:33:45:给每个子代理只配它这份活所需的资源,像给新实习生只开生产库只读权限,免得手生的人 drop 你的表。子代理的自主性是父代理层层赋予的,等于把概率相乘,护栏必须更硬。
局限也要认 5:34:29:子代理有开销和延迟,spawn 再收结果并非瞬时。简单任务里主 agent 直接干几乎总更快,作者也只在 DOE、Claude Skills 这类超特定框架里才用子代理,日常大多不用。演示中他用语音口述需求让 Claude Code 生成 reviewer,并进一步要求它按 Claude 原生的 command 格式(而非 directive)落地,实测审出了效率与路径问题、还顺带改好了脚本。
术语
- context pollution(上下文污染:窗口被中间产物垃圾塞满,导致输出质量下降)
- context isolation(上下文隔离:子代理独占一块干净窗口,只回传结论)
- compounding errors(误差累积:多步各自 99%,叠加后准确率被拉低)
- least privilege(最小权限:每个 agent 只配它本职所需的工具/访问权)
- reviewer sub-agent(审阅子代理:以全新无背景 context 纯凭质量审代码)
- document sub-agent(文档子代理:读脚本、把 directive 回写对齐,只写 directive)
- anatomy(子代理文件构成:name / description / permissions / system prompt)
自检问题
- 为什么把活丢给子代理能提升主 agent 的输出质量? 答案:因为上下文隔离——子代理在独立的干净窗口里干脏活、只回传结论摘要,避免中间产物污染主 agent 的 context;而 context 里 token 越多质量通常越差。对应详解1、2。5:17:08
- 子代理并非稳赚,主要代价是什么? 答案:实现复杂度(塞入自己的偏见)与误差累积——每多一次「父代理摘要交办」就多一处出错点,单步 99.9% 拉到 1000 步只剩约 36%。须确认省下的污染大过多加的误差。对应详解3。5:21:16
- reviewer 与 document 两种子代理各解决什么问题,权限怎么配? 答案:reviewer 用全新无背景 context 纯凭质量审 orchestrator 写的代码,破除「审自己文章」的偏见;document 把执行脚本的变更回写到 directive,避免二者脱节。document 配「读全部文件 + 只写 directive」,体现最小权限。对应详解6。5:27:16
- 为什么子代理不能再 spawn 子代理? 答案:内存与安全约束——否则层层 spawn 会指数爆炸烧穿资源并带来安全隐患;故子代理只能由 agent 创建,且全部只向父 agent 汇报。对应详解5。5:26:16