子代理：主 Agent 的上下文防火墙
先讲那次排查，因为我关于子代理的大部分认识都是那天形成的。
五月中旬，一个 Go 服务的 p99 从 80ms 涨到 400ms，没有发版、没有配置变更。我当时正好在试多 Agent 工作流，就让主 Agent 列了三个候选方向——慢查询、连接池、上游超时配置——然后为每个方向起一个子代理并行调查。
十几分钟后三份报告回来。慢查询方向：EXPLAIN 了最近的慢日志，没有新增慢查询，排除；连接池方向：发现连接数曲线在事发时间点有异常爬升，池配置三个月没动过，存疑；上游方向：某依赖服务的超时从 200ms 被调成了 2s，改动时间和 p99 拐点吻合——命中。后来确认就是上游改超时导致重试堆积。
这个流程如果串行在一个会话里做，会是什么样？我后来复盘估了一下：三条调查线各自要读日志、跑命令、看监控，全部中间过程摞在一个窗口里大概十几万 token。而实际上主窗口最后只收到了三段结论,加起来不到一千 token。这就是子代理的本质——不是「人多干活快」，是上下文防火墙。并行提速是赠品，噪声隔离才是主菜。
什么时候不该用
好，反面案例。同一周我头脑发热，把一个核心模块的重构也拆给了子代理。结果做到一半我想问「刚才为什么选了组合而不是继承」——对话历史里只有子代理返回的一句总结，决策过程全在那个已经结束的子会话里，追问无门。最后等于重新讨论了一遍。
两次经历放一起，判断标准自己浮出来了，就一个问题：
这个子任务，「工作总结」对主流程够不够用？
调查、统计、批量检索——只要结论，够用，拆。核心改动、方案权衡——决策链条本身有价值，随时可能回溯，不拆。用错方向的代价是对称的：该拆不拆，主窗口被噪声塞爆；不该拆硬拆，主 Agent 拿着二手总结做三手决策。
委派契约
子代理用了一个多月之后，我发现效果好坏几乎完全取决于委派那一刻说清楚了什么。「帮我看看这个模块有什么问题」这种委派，收回来的东西基本没法用——它会给你一份面面俱到、毫无重点的「体检报告」。
现在我们委派时强制写七个字段，内部叫委派契约：
Role 你是谁（「你是排查性能问题的 SRE」——视角决定关注点）
Goal 一句话目标
Context 必要背景。注意是必要，不是全部
Allowed 可以做什么（读文件？跑只读命令？）
Forbidden 明确禁止什么（改文件、装依赖、写数据库）
Output 输出格式（三段结论？JSON？带证据的判断？）
Stop 什么情况下停止上报（比如需要生产写权限时）
写这七行大概要两分钟，很多人嫌烦。我的说法是：这两分钟写不出来，说明你自己还没想清楚这个子任务的边界——那委派出去也是垃圾进垃圾出。契约写清楚之后，子代理的产出质量差出一个档次，这是我们内部无争议的共识。
有一条特别提一下：Output 里要写证据要求。子代理说「已排查，无问题」你敢信吗？契约里写明「结论必须附带执行的命令和原始输出」，「无问题」三个字就变成了可以验证的东西。没有证据的总结只是意见。
贴一份那次排查里实际用的契约，脱敏后原样搬过来，感受一下颗粒度：
Role: 你是排查线上性能问题的后端工程师
Goal: 验证或排除「连接池配置不当导致 p99 上涨」这一假设
Context: 服务 X 的 p99 于 5/14 14:00 起从 80ms 涨至 400ms，
无发版记录。监控入口和日志路径见附录
Allowed: 读代码、查监控 API、跑只读诊断命令
Forbidden: 修改任何配置和代码；重启任何服务
Output: 三段式——结论（支持/排除/存疑）、关键证据
（命令+原始输出）、建议的下一步
Stop: 如需要写权限或压测才能进一步验证，停止并说明
写出来就会发现，七要素没一个是废话：少了 Forbidden，它可能「顺手」调大连接池帮你「修复」；少了 Stop，它可能自己找台阶下硬给结论。契约的本质是把你脑子里「不言自明」的边界翻译成文字——而「不言自明」恰恰是委派失败的最大来源，对人和对模型都一样。
深度不超过二
再讲一个用血泪换的规则。有次一个子代理自作主张又起了自己的子代理，三层嵌套。任务本身完成了，但后来出了个小问题需要追查是哪一层做的决定——我对着一棵谁也说不清的调用树查了一个下午。从那之后我们的硬规则：嵌套深度不超过 2，同时并发不超过 5。这两个数字没有理论依据，纯粹是「人类还能 debug 的上限」。
顺便纠正一个常见的误解：有人以为拆子代理省钱。恰恰相反——每个子会话都有自己的系统提示词和工具定义开销，总 token 消耗通常比单会话更高。子代理买的是主窗口的质量，不是账单的数字。预算紧张的话，先做上下文压缩，别拆子代理。
和 Agent Teams 的区别
最近工具链里多了 Agent Teams 这种新形态，经常有人问和子代理什么区别。最简洁的说法：子代理是实习生各自向你汇报，Teams 是小组同事坐一起开会——共享任务列表、队员之间可以直接讨论、各自有独立上下文。
我的使用体感：九成的场景子代理就够了，因为大部分可拆的任务本来就是「互不干扰的分工」。真正值得上 Team 的是多假设互相挑战的场景——生产故障定位时让几个队员互相质疑对方的结论，这个「互相」是子代理拓扑做不到的（它们之间没有通信）。但 Team 的管理成本也真实存在，3-5 个成员是甜区，再多就是开会内耗的 AI 复刻版。
说到底，这套东西对做过分布式系统的人毫无新意：独立地址空间、显式消息传递、故障不扩散、限制扇出。操作系统和微服务用了几十年的道理，换了个执行主体而已。工程直觉可以直接平移，这大概是后端工程师做 Agent 架构的隐藏优势。