子Agent不是万能药：什么时候该拆、拆了怎么收尾，一份落地清单

去年一堆团队把单体Agent拆成「规划者+执行者+审查者」三件套，今年又在往回并。这不是反复横跳，而是踩过了才知道：拆分的收益来自上下文隔离，成本来自信息损耗，只要收益跑不过损耗，拆就是亏的。

一、子Agent真正的价值只有两条

宣传里说的「分工明确」「各司其职」都是叙事，工程上真正成立的收益只有两条：

1. 上下文隔离：子任务污染父上下文的中间过程（大量工具返回、日志、失败尝试）被挡在外面，父Agent只看结论。长任务里这一条能省掉 60% 以上的 token。
2. 并行吞吐：彼此无依赖的子任务可以同时跑，墙钟时间从叠加变成取最大值。

除此之外都不成立。子Agent不会让模型「更聪明」，也不会自动降低错误率——它只是把一次调用变成多次调用，错误面反而变大了。

二、该拆的三类场景

场景1：调研与执行混合的任务。 比如「调研三家竞品的定价，然后写一份对比表」。调研阶段会拉十几个网页、几十次搜索，这些内容留在主上下文里毫无价值。把它丢给子Agent，只回收一份结构化摘要，主上下文立刻干净。

场景2：天然可并行的批处理。 检查 40 个页面的 SEO 问题、给 50 条数据打标、对 20 个文件做同类修改。这类任务拆开后的收益是线性的，风险却很低，因为子任务之间不需要通信。

场景3：需要「对抗性审查」的环节。 让审查者不知道生成者的推理过程，只看到产物，能显著提高挑错率。这是子Agent唯一能提升质量的场景，原理是切断确认偏误。

三、不该拆的四类场景

• 强依赖链：后一步需要前一步的全部中间信息。拆开后你不得不把中间信息塞进消息里，损耗比收益大。
• 需要全局取舍：比如改一个模块同时影响五个文件，拆开后每个子Agent只看局部，做出的改动会互相打架。
• 任务本身很短：一次调用能干完的活拆成三次，纯亏三倍延迟。
• 对一致性要求极高的输出：多路并行生成再合并，风格和口径很难统一，后期修补成本很高。

四、上下文隔离怎么做才不丢信息

给子Agent的任务描述必须是自包含的。最常见的失败是父Agent只说「处理一下上面那个报销单」——子Agent看不到「上面」。一个可用的任务模板长这样：

目标：从这 3 份 PDF 中提取所有金额字段，输出 JSON 数组
输入：<把文件路径或原文明确放进来>
约束：只输出 JSON，不要解释；缺字段填 null
验收：每个金额带 currency 和 confidence

四条缺一条，回收率就会掉。实践中「验收标准」这一条最常被漏掉，而它恰恰决定了合并阶段要不要返工。

五、结果合并是最容易出事的地方

子Agent返回的数据必须走结构化契约，不要回收自由文本再让主Agent二次理解。推荐在提示里强制 JSON Schema 输出，主Agent拿到后做校验，校验失败就带错误信息重跑一次，仍失败则降级为「把这部分标为未完成」。

还有一个坑：并行子Agent的结果常常互相矛盾。比如两个子Agent对同一个字段给了不同值。合并策略必须显式规定：以置信度高的为准、冲突则升级给父Agent裁决、或者统一标为待确认。三种都行，但必须先定，不能靠模型临场发挥。

六、成本与可观测性

拆分的成本要算清楚：子Agent的输入输出全都要计入 token，而且父Agent还要再读一遍结论。一个拆成五路的任务，token 开销常常是单体的 2–3 倍。

同时必须补上链路记录：每个子Agent分配一个 trace id，记录它收到的任务、消耗的 token、返回的状态。否则线上出问题时你只看到「父Agent说有一项没完成」，完全不知道是哪一路挂了。

结论

判断要不要拆，就问三个问题：这个子任务会不会污染主上下文？它能不能和别人并行？它的输出能不能用结构化格式验收？ 三个都是「是」才动手拆。只要有一个是否，单体Agent加更长的上下文通常更划算。