多 Agent 编排：何时值得与如何拆分

一句话定义

多 Agent 编排只有在子任务「接口清晰、可独立验证、互不共享状态」时才值得——生成者-批评者对是最稳的入门形态，并行批量任务是最稳的扩展形态。

为什么重要

「多个 Agent 一起干活」直觉上更快更聪明，实际常相反：Agent 间没有共享心智，协调成本（上下文同步、接口对齐、合并冲突）会吞掉并行收益，还叠加了跑偏面的数量。明确「何时不编排」与「编排时怎么拆」，能避免把单 Agent 能解决的任务复杂化，也能在真需要并行的场景（批量迁移、大规模测试补充）拿到确定收益。

前置知识

kp-017（Agent 循环与派工单）。

核心概念

• 编排三形态：

1. 主从式：一个主 Agent 拆解派单给多个子 Agent，回收结果汇总；
2. 评审对：生成者与批评者两个角色对同一产出对抗（人做裁判）；
3. 并行批量：同构任务复制 N 份，各自处理互不相交的切片。

• 可编排判据（三条全满足才编排）：子任务接口先行（输入输出契约固定）；可独立验证（各有验收命令）；无共享可变状态（不共改一个文件/一把锁）。
• 协调成本清单：上下文同步（各 Agent 看不到彼此过程）、接口漂移（实现与契约偏差）、合并冲突、总成本上升（token 与等待时间）。
• 接口先行：先由人（或主 Agent）产出接口定义与切片清单，子 Agent 只做实现。

原理与机制

多 Agent 收益的来源是「切片独立性」而非「智能叠加」：并行批量之所以稳，是因为各切片共享同一契约与验收，失败互不传染，最坏情况是单切片重跑。评审对之所以稳，是因为生成与批评的目标函数相反，天然形成制衡，且不需要状态共享。反之，需要共享大量上下文才能推进的任务（同一模块的紧密重构），拆给多 Agent 等于把「人机协作」换成「机机误解」——协调开销全部变成错误率。

实例或案例

操作步骤（并行批量迁移的编排法）：

1. 单 Agent 完成试点切片，产出「映射表 + 写法约定」（kp-015 第 4 步）——这是所有切片的共享契约。
2. 把剩余文件按目录切成互不相交的切片清单，每片附契约与验收命令。
3. 为每片派一个子 Agent，只读共享契约、只写本切片路径（权限隔离，kp-018）。
4. 回收后逐片走 kp-013 审查 + 快照验证，失败切片单独重派。
5. 收尾统一跑全量测试，归档切片记录。

评审对的轻量用法（不需要真的开两个 Agent）：

角色A（已产出diff的生成者）→ 角色B提示：你是严格评审者，
专查并发、空值与规格偏离，列出全部问题，禁止客套。
→ 人对照两份输出裁决。

排错清单：

• 子 Agent 间产出风格冲突 → 共享契约不够具体，把写法约定升级为强制条目。
• 合并冲突频发 → 切片不互斥，重新按文件边界切。
• 总耗时比单 Agent 还长 → 任务本质是强耦合，回到单 Agent 串行 + 人分段把关。
• 主 Agent 派单后失忆 → 让主 Agent 只做「派单-回收-汇总」，不做实现，状态全落盘。

公式或模型

本节不适用：编排收益 = 并行加速 − 协调成本，两项都难精确量化，用切片一次通过率做经验指标。

图示

契约（映射表+验收） ──┬──▶ 子Agent① 切片A ──▶ 逐片审查 ─┐
                     ├──▶ 子Agent② 切片B ──▶ 逐片审查 ─┼──▶ 全量验证
                     └──▶ 子Agent③ 切片C ──▶ 逐片审查 ─┘
评审对：生成者 ⇄ 批评者 ──▶ 人裁决

直观类比

像装修队分工作业：图纸（契约）先定死，水电/瓦工/油漆各干各屋（切片互斥），监理逐屋验收（逐片审查）；要是让三个工人在同一面墙上抢活，只会互相踩脚。

常见误区

• 数量崇拜：「三个 Agent 一定比一个强」——协调成本与错误面随数量上升。
• 用多 Agent 代替任务拆解：拆解是人（或主 Agent）的责任，子 Agent 不该自己发现「原来该这么做」。
• 共享可变状态编排：两个 Agent 同改一个文件 = 合并冲突发生器。

与其他知识点的关系

kp-020 的止损原则同样适用于子 Agent；kp-015 的批次规范是并行编排中「契约」的直接来源。

自测题

要点：接口先行、可独立验证、无共享可变状态——三条全满足才值得编排。

要点：切片共享契约与验收、失败互不传染、最坏单切片重跑；而协作写同一功能需要共享大量上下文，协调开销转化为错误率。

1. 可编排判据的三条是什么？
2. 为什么并行批量比「多 Agent 协作写同一功能」稳？

延伸阅读

本节不适用：多 Agent 编排属快速演进的前沿实践，尚无公认经典，以本节判据为准入门槛。