多 Agent 编排：分角色，不一锅端

多 Agent 不是为了炫技，而是为了职责分离和独立验证。它有真实的成本，所以必须算得过账。

单个 AI 会话容易形成闭环幻觉：它写了代码，又解释为什么这样写，再生成一组刚好通过的测试——整个过程自洽，但没有任何环节独立于其他环节（机制见 Agent 执行的自我偏好与上下文污染分析）。多 Agent 编排的价值，就是把工程交付中的不同职责拆进互相独立的上下文。

一、编排模式：行业已有公共词汇

多 Agent 不是自由发挥的组合，Anthropic 在《Building Effective Agents》中总结的五种基础模式已成为行业公共词汇。本站的执行链路是其中三种的组合：

模式	含义	在 GMV 清洗迁移中的位置
链式（prompt chaining）	上游产物作为下游输入，顺序执行	需求审查 → 架构 → 实现的主干
并行（parallelization）	无依赖任务同时执行	测试与文档同时展开；多视角 review
评估-优化（evaluator-optimizer）	一个执行、一个评审，循环收敛	Review Agent → 修复 Agent → 回归
路由（routing）	按任务类型分发给不同处理者	本站用任务分级承担此职能
编排者-工作者（orchestrator-workers）	动态拆分子任务	用于案例级的大型交付

用公共词汇描述自己的流程有个务实的好处：可以被同行检验。"我的链路 = chaining + parallelization + evaluator-optimizer 的组合"是可讨论的工程方案；"我发明了一套多 Agent 体系"不是。

二、角色与链路

Agent	职责	产物
需求审查	检查需求缺口	待确认问题、风险清单
架构	检查规格自洽性	边界、契约、数据模型的审查报告
实现	按规格写代码	代码改动、实现说明
测试	按风险补测试	测试用例、覆盖与未覆盖说明
Review	独立审查产物	问题清单、修改建议
修复	根据失败结果修复	修复补丁、回归说明
文档	沉淀交付说明	使用文档、变更说明

GMV 清洗迁移链路的完整链路：

需求审查 ──→ 架构 ──→ 实现 ──┬─→ 测试 ──┐
                              └─→ 文档   ├─→ Review ⇄ 修复 ──→ 回归
                                         ┘

每个节点的输入输出和人工检查点见 Agent 执行的链路表；每个节点的任务书格式见 Agent 工作单。本章只补一条链路设计原则：评估-优化环（Review ⇄ 修复）必须有退出条件——通常是"回归全绿 + review 问题清零"或"循环三轮仍不收敛则升级人工"。没有退出条件的自动循环会在两个 Agent 互相礼貌地修改对方产物中烧掉预算。

三、成本模型：多 Agent 必须算得过账

多 Agent 的成本不是修辞，是可量化的。Anthropic 复盘自家多 Agent 研究系统时给过量级：单 agent 任务的 token 消耗约为普通对话的 4 倍，多 agent 系统约为 15 倍。在此之上还有两重开销：

• 延迟：链式节点串行等待，每个节点还要冷启动读规格；
• 集成协调：并行产物合并时的冲突检测与返工。

所以决策标准和任务分级完全一致：缺陷逃逸的代价 > 编排开销，才值得编排。 具体对照：

适合多 Agent：涉及多模块；有经营口径、存量数据和边界风险；需要影响面分析与独立核对；代码量大到单会话必然上下文稀释。

不适合多 Agent：文案与样式调整；单文件低风险改动（S 级）；探索性原型；以及最重要的一条——需求本身还没澄清。需求不清时，多 Agent 只是让 N 个上下文并行地做出 N 组不同的默认假设，编排在放大混乱而不是控制混乱。

四、编排四规则

① 先规格，后并行

规格（数据模型、契约、状态机）未定稿前，只允许链式推进，不允许并行实现。并行的前提是所有分支共享同一份已冻结的事实——这就是规格驱动开发"先定不可逆决策"在编排层的投影。

② 并行分支之间必须有书面契约

字段、入参出参、错误码、状态流转、目录归属——全部落在文件里。两个 Agent 之间不存在"口头对齐"：它们不共享记忆，唯一的通信信道就是写下来的契约。人类团队漏写契约靠茶水间补救，Agent 团队漏写契约直接集成失败。

③ 文件归属明确

每个 Agent 知道自己能改哪些文件、不能改哪些。两个 Agent 写同一个文件约等于必然冲突——边界怎么定义、怎么机器强制，见架构边界。

④ Review 独立

Review Agent 用干净上下文，输入只有规格 + diff，不继承任何实现会话。依据是验收清单和架构边界，不是"看看写得好不好"。这是整条链路里最不能省的一环——省掉它，多 Agent 就退化成了"多个会话的单 Agent"，闭环幻觉原样回归。

五、典型失败模式

编排失败是有形状的，提前认识可以少交学费：

失败模式	原因	预防
集成冲突	规格未冻结就并行	规则①
假设分歧	契约留白，各分支自行脑补	规则②；契约里写"未尽事宜返回人工"而不是"合理处理"
重复劳动	范围重叠，两个 Agent 都改总控或共享规则	规则③ + 工作单【输入】指明已有组件与文件归属
礼貌循环	Review 与修复互改不收敛	评估环设退出条件与轮数上限
放大混乱	需求未澄清就编排	退回需求体检，编排不是澄清工具

六、本章小结

• 多 Agent 的目的在职责分离与独立验证；用行业公共词汇（chaining / parallelization / evaluator-optimizer）描述链路，让方案可被同行检验。
• 成本可量化：多 agent 系统约消耗普通对话 15 倍的 token，外加延迟与集成开销——缺陷逃逸代价高于编排开销才值得用。
• 四规则：先规格后并行；分支间只有书面契约这一条通信信道；文件归属明确；Review 独立且不可省。
• 评估-优化环必须有退出条件；需求未澄清时编排放大混乱。

下一章 工具工作台，讲这些流程如何被工具固化成默认动作。

---

参考资料

• Anthropic, Building Effective Agents（2024）——五种编排模式的原始定义。
• Anthropic, How We Built Our Multi-Agent Research System（2025）——多 agent 约 15 倍 token 消耗的实测量级与工程教训。