什么是 Subagent

系列入口：如何使用 Agent。本篇是 M5 多 Agent 编排模块的第一篇。

一、一句话定义

子代理（Subagent）是由主 Agent 临时派生、带着独立上下文去完成某个子任务、再把结果交回主 Agent 的「专职工人」。

关键在「独立上下文」：子 Agent 不会把它翻找过程中读到的一大堆文件、跑出来的中间输出全倒进主对话。它在自己的工作区里忙活，最后只把结论或产出带回来。主 Agent 像一个领班，自己不必钻到每一个具体环节里，而是把明确的小块活派下去，收汇总结果做下一步决策。

二、为什么委派反而更稳、更省

直觉上，多一个 Agent 似乎更复杂、更贵。但用对了，它带来三个实在好处：

1. 隔离上下文，保护主窗口（最核心） 像「在整个代码库里找出所有调用某 API 的地方」这种任务，会读几十个文件、产生大量中间结果。交给子 Agent，这些过程性信息都留在它的上下文里，主窗口只收到一份精简结论。这正好呼应上下文预算管理——子代理是最有效的「上下文防火墙」。

2. 可以并行 多个互不依赖的子任务，可以同时派给多个子 Agent 分头跑，最后汇总（详见 并行子代理）。原本串行要一小时的检索，可能十几分钟就齐了。

3. 专门角色配专门设定 每个子 Agent 可以有自己的角色、模型、工具和指令，比如一个只做安全审查、一个只写测试。专门化让它们在窄任务上更稳，也可以给简单子任务用更便宜的模型来省钱。

三、什么任务适合委派

适合委派的子任务通常有这些特征：

• 边界清晰、能独立交付一个结果：比如「调研 X 并给出结论」「给这几个文件补测试」；
• 会产生大量中间信息：大范围搜索、读很多文件——隔离价值最大；
• 彼此独立、可并行：多个子任务之间不需要来回共享状态。

不适合委派的，是那些需要全局视角、要不断和主任务其他部分耦合判断的事——这类留在主 Agent 手里，否则子 Agent 看不到全貌反而容易做偏。判断口诀：能不能一句话说清「要它交回什么」？ 能，就适合派下去。

四、一个真实场景：同一次调研，两种做法

为了让你直观感受差别，来看一个很多人都遇到过的场景。小王接到任务：「我们要把登录模块里用的旧版鉴权库升级，先帮我找出整个仓库里所有调用它的地方，评估影响面。」

做法一，直接在主对话里让它查。 它开始在整个仓库翻找，一个文件接一个文件地读，把每处调用的代码片段、判断过程都吐在主对话里。十几分钟下来，主窗口塞满了几十个文件的中间内容，最后虽然给出了清单，但主对话已经很臃肿，紧接着要讨论升级方案时，模型的注意力被大量无关片段稀释，甚至开始引用已经看过、其实并不关键的代码。

做法二，先派一个子 Agent。 小王说：「派一个调研子代理，在 src/ 下找出所有调用旧鉴权库的位置，逐个确认真伪，最后只交回一份清单：文件路径、行号、调用方式，别的不用带回。」子 Agent 在自己的上下文里翻找、甄别，中间读了多少文件都不影响主窗口，最终只返回一份干净的清单。主对话依然清爽，可以立刻聚焦在升级方案上。

同样的结果，差别在于过程性信息有没有污染主窗口。这正是子代理最核心的价值，也是为什么「多派一个 Agent」看似更重，实际反而更稳、更省。

五、一次示范委派长什么样

派活的说法不必复杂，把「范围 + 要交回什么 + 不要做什么」讲清即可：

请派一个子代理完成下面这件事：
- 范围：只在 packages/api/ 目录内
- 任务：找出所有直接读取环境变量 process.env 的位置
- 交回：列表，每项含文件路径、行号、读取的变量名
- 约束：只读调研，不要修改任何文件，不要带回大段代码

这三要素（范围、产出、约束）说清楚，子 Agent 几乎不会跑偏，主 Agent 也能稳定消费它交回的结构化结果。如果你发现自己无法把「要它交回什么」用一句话描述，通常说明这个子任务边界还不够清晰，更适合留在主 Agent 手里或先拆解。

六、常见误区

• 以为派活就是撒手不管：子 Agent 交回的结果同样要验收，隔离的是过程，不是责任。
• 把高度耦合、需要全局判断的事硬派下去：子 Agent 看不到全貌，反而容易做偏。
• 让它把所有中间过程都带回：这等于放弃了上下文隔离这一最大收益。
• 子任务切得太大：一个子 Agent 干一件边界清晰的事，过大的子任务应再拆。

七、常见问题

Q：子 Agent 和我手动开一个新对话窗口有什么区别？ 机制上相似（都是独立上下文），但子 Agent 由主 Agent 自动派生、结果能被结构化收回并继续编排，适合在一次任务里动态扇出；手动开窗更适合完全独立的另一件事。

Q：子 Agent 会不会因为看不到主对话历史而做不好？ 它只拿到显式传给它的信息。所以派活时要把它所需的背景、范围、判据交代清楚，这是主 Agent 的职责，信息给足后隔离反而是优势。

Q：用子代理一定更省钱吗？ 不一定绝对更省（多了一次调用），但它通过保护主窗口、避免因污染返工、以及可用便宜模型跑子任务，通常在中等以上复杂任务里综合更省。

八点五、子代理和你已经学过的概念怎么衔接

学到这里，你可能会觉得子代理和前面几个模块的概念有重叠，这里专门理清，避免混淆。

先看它和上下文工程的关系。上下文工程讲的是「如何让对的信息进入窗口」，而子代理是其中一个非常具体的手段——用一个隔离的窗口去承接那些过程性、大体量的信息，从而保护主窗口。换句话说，子代理不是脱离上下文工程的新东西，恰恰是上下文隔离原则在「需要另一个执行者」时的延伸。你在 M3 里学到的「窗口是稀缺资源、要预算、要聚焦」，在这里依然完全适用，只是实现方式从「精简喂料」升级成了「分窗口承接」。

再看它和 Skill 的区别，这也是最容易混的一点。Skill 回答的是「怎么做这类事」，是一份可复用的方法说明；子代理回答的是「谁来做这件事」，是一个带着独立上下文去执行的角色。 两者还能组合：一个子 Agent 在干活时，可以加载某个 Skill 来指导自己的步骤。比如「派一个子代理去补测试，让它使用我们的测试 Skill」——这里子代理是执行者，Skill 是它用的方法。分清这层，你就不会在「该写 Skill 还是该派子代理」上纠结：要复用方法就沉淀 Skill，要隔离执行就派子代理，需要时让前者服务后者。

八点六、新手最容易踩的心理预期

除了操作层面，还有一个心理预期需要校准。第一次用子代理的人，常见的落差是：派出去之后，发现它并没有「立刻、完美」地交回结果，有时还会漏一点、偏一点，于是怀疑这东西没用。

这种预期本身就不现实。子代理是一个在窄任务上工作的执行者，它的稳定性依赖你把任务边界、范围、判据交代清楚；你第一次派活，就像第一次给不熟悉项目的新人交代工作，信息不可能一次就给得刚刚好，它有所遗漏或理解偏差，是非常正常的现象。真正成熟的用法，是把第一次交回当作反馈：它漏了什么、哪里理解偏了，就补充或修正后再派，经过一两轮，这类任务的派法会越来越稳，最后甚至可以固化成模板或 Skill。

所以，与其期待子代理「一次做对」，不如期待「通过一两次反馈把这类活的派法打磨好」。当你抱着这种迭代心态，就不会因为第一次的不完美而放弃，反而会逐渐积累起一批你能稳定调度的专职工人——这才是多 Agent 真正的长期价值所在，也是从「偶尔用用」走向「工程化驾驶」的关键一步。

八点七、委派前的一页检查清单

在真正按下「派活」之前，用下面这份简短清单过一遍，能帮你在源头避免大多数委派翻车。它不需要花很多时间，但会强迫你把容易含糊带过的地方想清楚。

• 我能用一句话说清「要它交回什么」吗？说不清，就先别派，先把任务边界理清。
• 它需要的背景、范围、已确认的决定，我都交代了吗？避免它因信息缺失而脑补。
• 我规定了交回的格式吗？结构化、可对齐的格式，主 Agent 才好消费。
• 我划清了「不许做什么」吗？比如只读、不改某些文件、不碰危险命令。
• 这件事真的适合隔离执行吗？高度耦合、需要全局判断的活应留在主 Agent 手里。
• 我准备好验收了吗？想清楚用什么标准判断它交回的结果是否合格。

这六个问题，其实就是把本篇前面讲过的好处和误区，压缩成派活前的一次快速核对。当你用熟之后，它会变成一种下意识的动作，而不是一份负担。

八点八、再看一个反面例子：什么时候委派反而帮倒忙

为了让你对边界更敏感，来看一个「不该派却派了」的例子。小陈在改一个涉及登录、订单、支付多处联动的复杂流程，逻辑环环相扣。他图省事，把「改登录部分」「改订单部分」「改支付部分」分别派给三个子 Agent，以为能并行提速。

结果三个子 Agent 各自只看到自己那一块，对公共的会话状态做了互相冲突的假设，交回的代码单看都合理，拼在一起却处处矛盾；主 Agent 整合时，为了调和这些冲突，不得不反复补派、来回返工，耗时比自己顺序做还长，主窗口也在一轮轮补派中被塞得更满。问题的根源，正是这个任务高度耦合、需要统一视角层层推进，本不适合简单隔离扇出，更适合留在主 Agent 手里，或用有严格交接顺序的协作模式。

这个反例和前面「调研」的正例放在一起，你就能清楚看到分界：能独立交付、边界清晰、过程信息量大的活，委派是加分；需要频繁共享状态、强耦合的活，委派是制造问题。 记住这组对照，比记住任何定义都更能帮你在实际中做出正确选择。

八点九、子代理返回后，如何快速判断质量

派活和等待都讲过了，这里补上最实用的一环——子 Agent 交回结果后，如何在很短时间内判断它到底靠不靠谱，而不是要么照单全收、要么从头再核一遍。

一个高效的判断分三层。先看形：格式是否符合约定、该有的字段（路径、行号、结论）齐不齐，有没有夹带大段无关代码。形式对，说明它确实理解并遵守了任务约束。再看点：从它列出的结论里随机挑两三个，回到实际代码或材料中快速核对——它说这里有调用，是否真有；它说已排除，是否成立。抽样核对比逐条复核省力，又足以暴露「一本正经地编造」。最后看全：它的结论整体上是否回答了最初的问题，有没有「看上去都对、却漏了一整类情况」的缺口。

这三层之所以有效，是因为它们各自针对一种典型失败：形式层抓「没遵守约束」，抽查层抓「看似自信实则编造」，全局层抓「局部正确、整体遗漏」。当你能用这套快速判断，验收就不再是沉重负担，而子代理作为一种可依赖力量，才真正成立。

八点十、什么时候你其实不需要子代理

最后专门讲讲「不用」的情形，避免你把好用的工具用过头。子代理有明确的适用边界，很多任务用主 Agent 直接做反而更自然，硬派出去只会增加交接和协调成本。

第一种是任务很小、几乎不产生中间信息。比如改一个变量名、调整一行逻辑，这类活直接交给主 Agent 几秒完成，为它专门派生一个子代理、写范围、收结果，纯属多余。第二种是任务高度依赖主对话里已有的丰富上下文。如果判断这件事需要不断参考正在讨论的多个细节，派给一个看不到这些上下文的子 Agent，你还得费劲把背景重传一遍，不如留在主 Agent 手里。

第三种，也是最容易被忽视的：你还在探索、自己都没想清楚要做什么的时候。子代理适合执行一个已经明确的子任务，而不是替你探索模糊方向；在边界没理清前派活，往往换来一个做偏的结果和一轮返工。让子代理服务于「明确、独立、信息量大」的子任务，其余交给主 Agent 或先想清楚——懂得在合适的时候不用它，和懂得在合适的时候用它，是同一种成熟。

八点十一、一个常见疑问：子代理会不会「偷懒」或「假干」

有个使用中很现实的顾虑值得专门回应：怎么确认子 Agent 是真的把活干了，而不是表面交回一份像模像样的结果、实际并没认真查？这种「假干」担心并非多余，尤其在它看不到、你也不易逐项核对的调研任务上。

先理解「假干」通常怎么发生。它很少是故意欺骗，更多是两种情况：一是任务范围太大，它在时间或步数压力下只覆盖了一部分，却用一个完整、肯定的口吻把结果包装成「全部」；二是它在某处没找到证据，却没有如实标注「此处未确认」，而是用猜测填补，让产出看上去没有缺口。两种情况下，结果的形式都很完整，问题藏在「覆盖不全」和「把猜测当结论」里。

识别和防范其实不难。第一，看它是否如实报告了覆盖范围和未决项——一个诚实的结果会说清查了哪些地方、哪些没确认；如果你要求之后它依然只给绝对化结论、毫无保留，反而要警惕。第二，坚持前面讲的抽样核对，随机挑几处回到原始材料验证，假干在抽查下很容易露馅。第三，把大任务切小，让每个子 Agent 负责一个你能核对其覆盖度的范围，减少它「覆盖不全却声称全部」的空间。

说到底，防假干靠的不是猜疑，而是「要它交代覆盖度 + 你抽样验证 + 任务切到可核对」这套机制。 当这成为派活的固定动作，你就能放心把子代理当成真正的执行者，而不必每次都担心它是否在走过场。

八、用子代理不等于「放任」

要提醒一点：子 Agent 也是 Agent，它交回的结果同样需要你或主 Agent 验收。委派解决的是上下文隔离和并行，不是责任转移。编排的具体模式（主从、规划-执行-审查、并行）以及要避开的坑，会在本模块后续几篇逐一展开。

总结

子代理就是主 Agent 临时派生、在独立上下文里干完一块明确子任务再交回结论的专职工人：它靠上下文隔离保护主窗口、靠并行提速、靠角色专门化提稳——把边界清晰、会产生大量中间信息的活派下去，多 Agent 反而比单 Agent 更稳更省。