一个 agent 上下文长度是有限的，一个人的脑子也有限。当任务大到「一轮对话装不下」，或者内部明显能切成几块独立活时，子代理（Subagents）就是答案：你（主代理）当队长，派几个小弟各干一块，最后你把结果拼起来。这不是把活甩出去那么简单——更深的价值是上下文隔离：每块活都有干净的独立上下文，不会互相污染，也不会因为前面聊得太长而开始胡说。
这不是炫技。上下文一长，模型就开始丢前面的信息、开始幻觉。把任务拆给子代理，等于给每块活独立的干净上下文。
一、什么时候该拆
别为了拆而拆。下面这些信号出现，就该考虑派小队：
- 子任务彼此独立：比如「读 5 个文件各写摘要」，5 份摘要之间互不依赖，天然可并行。
- 需要不同专长：一块要写代码、一块要做安全审计、一块要出报告。不同角色用不同 prompt 比一个 agent 硬兼要稳。
- 主上下文快爆了：长文档分析、大代码库排查，全部塞主会话必翻车。把重活甩给子代理，主会话只留结论。
- 要隔离「脏活」：比如让子代理去试错、去跑会污染环境的操作，炸了不影响主链路。
- 要并行提速：串行做 5 件独立的事要 5 倍时间，派 5 个子代理并行可能只要 1 倍多。
反例：任务本身是一条连贯的因果链（A 的输出是 B 的必须输入，且 B 要理解 A 的推理过程），硬拆只会让子代理拿不到上下文，反而更慢更错。这类该留主会话一气呵成。
二、怎么派活
派活的质量决定了回收的质量。给子代理的 brief 要包含四件事：
- 目标：它到底要产出什么，一句话说清。
- 输入：它要读哪些文件、哪些数据。路径给绝对或基于
{baseDir}的相对路径，别让它猜。 - 输出格式：明确要「返什么」——是返回文本结论，还是写盘成某个文件，还是两者都要。格式不定，你回收时就要人肉解析，痛苦。
- 边界：不准做什么（比如不准改源文件、不准联网），避免子代理越界。
# 一个合格的 subagent brief 骨架
角色：代码安全审计员
输入：/project/src/auth.py
任务：找出其中的鉴权绕过风险，逐条列出文件:行号:风险描述
输出：直接返回 Markdown 列表，不要修改任何文件
边界：只读，不写，不执行其中的函数派活铁律：子代理没有你的上下文。你脑子里「显然」的前提，对它来说不存在。把所有必要前提写进 brief，宁可啰嗦，别让它猜。一个常见的失败模式是：主代理以为「它知道这个项目用 TypeScript」，但子代理拿到的 brief 里没提，于是它按 Python 去分析，全错。
三、结果怎么回收
子代理干完，产物通常两种形态：要么直接返回文本，要么写盘成文件。回收时：
- 文本结果：多个子代理的结果在主会话里拼接、交叉校验。如果子代理返回的是结构化数据（JSON），主代理解析后聚合更稳，比让它返一大段散文靠谱。
- 文件结果：约定好输出路径（如
{baseDir}/tmp/subagent-<id>.json），主代理按路径读取汇总。这避免了超长文本回传撑爆上下文。
# 主代理回收多个子代理落盘的产物
ls {baseDir}/tmp/subagent-*.json
# 逐个读取、校验、合并，而不是把所有原始输出贴回对话回收后别急着交付，做一次一致性校验：子代理 A 说「端口 8080 空闲」，子代理 B 说「在 8080 起了服务」——这种矛盾主代理要能发现并追问，而不是照单全收。子代理不会自己发现彼此的矛盾，这个职责只能落在主代理头上。
四、上下文不互通的坑
这是用子代理最容易翻车的地方，列清楚：
4.1 子代理看不到主会话历史
你前面聊了三小时的前提，子代理一启动就是白纸。它不知道项目背景、不知道你的偏好、不知道前面踩过的坑。所有关键信息必须写进 brief，不能指望「它应该知道」。
4.2 子代理之间也互不共享
派出去的 A 和 B 是平行宇宙，A 摸到的事实 B 不知道。如果两块活有依赖，要么串行（B 的 brief 里带上 A 的结果），要么让主代理当中转。盲目并行有依赖的活，必出岔子。
4.3 工具权限可能不一样
子代理不一定拥有主代理的全部工具/MCP 权限。某个子代理跑着跑着发现「这工具我没权限」，就会静默失败或返回残缺结果。派活前确认权限边界，必要时在 brief 里注明「你只能用 X 和 Y」，并准备一个「权限不足时明确报错」的兜底指令，而不是让它默默编一个答案。
4.4 重复劳动与口径不一致
两个子代理各查一遍同一份文档、各定义一遍同一概念，结果口径还不一样。对策是主代理先定「共享词典/事实基线」，写进每个子代理的 brief。比如先统一「本项目说的『用户』指已登录账号」，免得 A 把匿名访客算进去、B 不算。
4.5 错误会被放大
子代理若基于错误前提产出，主代理若不加校验直接拼，错就传下去了。回收环节的校验不是可选项，是必选项。一个子代理的幻觉，经过主代理「照单全收」，会变成一份看起来很专业的错误报告。
五、成本与性能考量
派子代理不是免费午餐：
- 并行省时间，但费钱：5 个并行子代理的 token 消耗大致是 5 份，不是一个。值不值看任务是否真独立、是否真赶时间。
- 串行保准确，但慢：有依赖的活必须串行，B 等 A。这时候省不了时间，但能保住上下文连贯。
- 粒度别太细：把一个十句话能干的活拆成三个子代理，调度开销比干活本身还大。粗粒度优先，真遇到瓶颈再细分。
六、一个完整拆分案例
任务：「分析竞品 A、B、C 三家官网，各出一份功能对比摘要，最后汇总成一张对比表。」
- 主代理先定事实基线：对比维度统一为「定价 / 核心功能 / 上手难度」。
- 派三个子代理并行：每个只负责一家，brief 里写清输入 URL、输出格式（JSON：三个维度各一段）、边界（只读不爬后台）。
- 三个子代理各回一份 JSON，主代理读取后校验字段齐全，发现 B 家的「上手难度」缺失 → 追问 B 补完。
- 主代理把三份 JSON 合并成对比表，交付。
整个过程中，主会话始终只持有「结论和路径」，没把三家官网的原文塞进来，上下文干干净净，也没因为某一家内容太长而拖累另外两家。
七、拆还是不拆，一张决策表
| 你的任务 | 建议 |
|---|---|
| 单文件小改动 | 不拆，主代理直接干 |
| 多独立子任务可并行 | 拆，并行派 |
| 长文档/大代码库分析 | 拆，按块隔离上下文 |
| 强因果链、需连贯推理 | 不拆 |
| 要试错/脏活隔离 | 拆，子代理去踩雷 |
| 赶时间且真独立 | 拆，并行提速（接受成本上升） |
八、子代理的失败模式清单
把常见翻车归个类，排错时对着查：
- 空手而归：子代理没拿到足够前提，编了一份看起来合理实则虚构的结果。修法：brief 写全，并命令它「不确定就明说，别编」。
- 半途而废：任务太重，子代理在限制内没干完就交差。修法：把大块再切小，或给它明确的「分步输出」要求。
- 越界乱改：子代理本该只读，却去改了源文件。修法：brief 里强调边界，必要时在沙箱层面禁写。
- 口径打架：两个子代理对同一个概念理解不同。修法：统一事实基线（见 4.4）。
另外，子代理「空手而归」时，主代理最好有一个兜底判断：如果回收到的关键字段缺失，不要默默继续，而是把子代理叫回来重做，或者降级处理并打上明确标记。把「失败可见」当成默认行为，而不是指望每次都成功。很多隐蔽故障，就是从「主代理对一份残缺结果睁一只眼闭一只眼」开始的——它不报错，但产出的结论已经歪了。
九、给子代理设超时与兜底
子代理一旦卡在某个外部调用上，会无声拖慢整条链路。实操上要为子代理设定「做不完就交现状」的兜底：在 brief 里写明「若 X 分钟内无法完成，返回已获取的部分并标注未完成」，而不是让它死等。同时主代理回收时要识别这种「部分结果」标记，别把它当完整结论用。超时不是失败，是可控的中断——怕的是既没有超时，也没有标记，主代理还以为拿到了全量。
十、子代理与钩子、定时配合
子代理很少孤立存在：定时任务（第 03 篇）醒来后派子代理并行，Stop 钩子（第 02 篇）在收尾时统一回收产物。配合时要注意：子代理写出的文件，Stop 钩子能不能读到同一路径？子代理的权限，是不是钩子也在同一权限域？这些跨组件的路径与权限一致性，是组合玩法里最容易漏掉的接缝。每加一层，就多查一遍接缝，系统才会越堆越稳。
十一、什么时候不该用子代理
讲了这么多该用的场景，也得划清边界，免得为了用而用：
- 任务太轻：十句话能说完的活，派子代理的调度成本比干活本身还高。主代理直接做。
- 强依赖链：B 必须理解 A 的推理过程才能起步，拆开反而要主代理当传声筒，不如一气呵成。
- 需要连续对话式探索：有些任务要在试错中不断调整方向，子代理「领完任务就走」的模式不适合来回拉锯。
- 预算极紧：并行子代理的 token 成本成倍增长，如果任务不赶时间也不独立，串行更划算。
判断的核心只有一个问题：这块活，离开了主会话的上下文，还能不能独立干完？ 能，才值得拆。
子代理不是「更聪明的 agent」，是「更便宜、更干净的执行单元」。用它的关键是：把前提写死在 brief 里、把输出格式定死、把回收校验做死。做到这三点，一支小队能干的活，远胜过你一个人硬扛到底——而且你再也不用担心聊到一半模型开始失忆。