Multi-Agent 实战：什么时候该拆分，什么时候不该

给一个任务加上“产品经理 Agent、架构师 Agent、开发 Agent、评审 Agent”，看起来很像一个完整团队。

但如果每个角色只是复述上一个角色的内容，最后只会得到更长的等待时间、更高的成本，以及更多在交接中丢失的细节。

Multi-Agent 的价值不在于角色数量，而在于它是否解决了单 Agent 的一个真实限制：上下文过载、可并行的独立工作、不同工具/知识的隔离，或者需要独立视角来验证高风险结论。

一、先从单 Agent 开始

对于强依赖、顺序明确的小中型任务，单 Agent 往往更好：上下文连续，协调成本低，也不需要处理合并冲突。

读取一个模块 → 修改 → 跑测试 → 审查 diff

上面这个流程如果拆成四个 Agent，通常不会更快。后一个角色仍需要理解前一个角色的完整理由，反而多出四次交接。

拆分前先问一个反直觉的问题：如果只能保留一个 Agent，任务会在哪里真正卡住？

如果答案只是“我觉得多几个角色会更专业”，那就不该拆。

二、四种真正有收益的拆分

模式	适合什么	主要收益	必要条件
Subagent	独立子问题	隔离噪声，压缩结果	输入输出清楚
Parallel research	多来源检索	缩短等待、扩大覆盖	结果可独立比较
Critic / reviewer	高风险方案或改动	独立发现盲点	有明确审查标准
Evaluator–optimizer	可反复改进的产物	用反馈迭代质量	有停止条件与 grader

例如要写一份带证据的技术调研，可以并行拆成“官方文档”“开源实现”“风险与反例”三组检索；主 Agent 只负责比较证据和形成结论。它们的输入输出可以独立定义，因此并行真的能减少墙钟时间。

而“先改一个函数，再根据测试失败继续修”高度依赖上一步结果，通常应保持单 Agent。

三、用一个决策表代替直觉

在创建子 Agent 前，快速回答下面七项：

# 是否拆分 Agent？

- 子任务能否独立定义输入与输出？
- 是否真的可以并行，而非只是在排队？
- 是否需要隔离无关上下文？
- 是否需要不同工具、不同权限或不同专业知识？
- 是否需要独立验证，以避免同一思路的盲点？
- 谁负责合并，合并标准是什么？
- 拆分带来的成本、延迟与冲突风险是否可接受？

结论：single / subagent / parallel / critic / team
停止条件：[时间、调用次数、质量门槛]

其中“谁合并”和“按什么标准合并”最容易被省略。没有裁决者的并行结果，往往只是一组互相矛盾的建议。

四、一个可复制的研究编排例子

任务：评估是否在项目中接入一个新的 Agent 工具协议。

不好的拆法：让五个 Agent 都“研究一下是否值得接入”。它们会搜索相似内容，最后给出五份措辞不同的结论。

更好的拆法是给每个子任务不同证据目标：

Explorer A：只读官方规范，输出能力边界、版本、兼容性。
Explorer B：只读项目现有工具层，输出接入点、改动范围和风险。
Explorer C：只研究安全与运维影响，输出权限、审计、故障模式。
Reviewer：按固定矩阵检查是否遗漏成本、回滚和替代方案。
Orchestrator：不重复搜索；只比较证据，形成采纳/试点/拒绝决定。

每个 Agent 的输出都应尽量结构化，例如：结论、证据链接、假设、风险、未决问题。主 Agent 不需要读取完整过程，只需要读取可审查的结果。

五、并行时必须解决的三件事

1. 文件所有权

多个 Agent 同时改同一文件，通常比单 Agent 更慢。并行实现应提前分配目录、模块或接口，或者把并行限制在只读研究和测试。

2. 共享状态

不要让每个 Agent 都维护自己的“真实进度”。主任务需要一份统一状态，记录谁在做什么、哪些结果已采纳、哪些结论被否决。

3. 失败和预算

并行会放大成本。设定超时、最大子任务数和“无新证据即停止”的规则。只有可量化收益时，复杂编排才值得保留。

六、一个值得优先尝试的模式：独立审查

对设计方案、发布计划、权限规则等高风险产物，最有价值的第二个 Agent 往往不是另一个实现者，而是独立 Reviewer。

给 Reviewer 的任务不应是“评价一下好不好”，而应是：

只根据需求、约束和现有 diff 检查：
1. 是否越过权限或范围边界；
2. 是否遗漏失败恢复与回滚；
3. 是否修改了不允许变化的接口；
4. 每项结论引用具体文件、测试或缺失证据。

这能让它和实现 Agent 拥有不同目标函数，而不是礼貌地认可原方案。

七、用评测证明拆分有效

不要仅凭一次漂亮 demo 决定长期使用 Multi-Agent。把单 Agent 和拆分方案放在同一组代表性任务里比较：

任务成功率、遗漏风险、人工介入率、总调用数、成本、墙钟时间、合并冲突数

如果拆分没有显著改善其中一项，就删除复杂度。会判断“什么时候不用 Multi-Agent”，本身就是成熟的编排能力。

AI 实现摘要

• 要解决的问题：根据任务依赖、上下文隔离、并行收益和独立验证需求，选择恰当的单 Agent 或多 Agent 编排方式。
• 适用版本与前置条件：适用于支持子任务、并行调用或独立审查的 Agent 平台；需要清晰的任务边界和合并者。
• 输入、输出与验收标准：输入为一个复杂任务及约束；输出为拆分决定、子任务输入输出、所有权、停止条件和合并标准。验收时应能证明拆分减少时间、风险或上下文负担。
• 文件改动清单：可新增编排决策模板、任务状态文件和评测报告；无需固定目录。
• 完整命令：无通用命令。使用平台的子任务调度与项目真实验证命令。
• 测试步骤与预期结果：在同一批代表性任务中对比单 Agent 与拆分方案；预期只有具备独立性或独立验证价值的任务从拆分中获益。
• 常见错误、回滚方法与安全边界：不要并发修改同一文件或让多个 Agent 共享生产写权限。无法合并、超预算或缺少证据时，停止子任务并退回单 Agent 或人工决策。