Multi-Agent Coordination Patterns: Five Approaches and When to Use Them（多 Agent 协作的五种模式）
📄 来自 Claude 官方博客
- 原文标题
- Multi-Agent Coordination Patterns: Five Approaches and When to Use Them（多 Agent 协作的五种模式）
- 原文链接
- https://claude.com/blog/multi-agent-coordination-patterns
- 作者
- Cara Phillips 等（Anthropic）
- 发布日期
- 2026-04-10
⚠️ 本页是原文的中文结构化整理笔记（保留架构、数据、案例、结论），并非逐字翻译。具体参数与功能名更新很快，落地前请点击上方链接核对原文。
🎯 一句话
多 Agent 的五种常见形态：并行、串行流水线、主从编排、辩论、群体投票。⭐ 但真正的第一个问题是：这个任务真的需要多个 Agent 吗——多 Agent 的协调开销和调试难度都是数量级的上升。
选择多 Agent 协作模式应基于问题的实际需求，而不是模式看起来的先进程度。从最简单可行的模式起步，随局限显现再演进。
五种协作模式
1. 生成器-验证器（Generator-Verifier）
- 机制： 生产者产出，审阅者按定义好的标准评估；被拒则带反馈回炉，直到通过或达到迭代上限
- 适用： 评估标准可显式定义的质量关键型应用——代码生成+测试、事实核查、合规校验、工单回复
- 局限： 验证质量取决于标准质量——「检查一下好不好」这类含糊标准会导致失败；生成器无法响应反馈时循环会卡死
2. 编排器-子 Agent（Orchestrator-Subagent）
- 机制： 主导 Agent 规划、委派专门子 Agent、综合结果
- 适用： 任务分解清晰、子任务间依赖少（Claude Code 是典型例子）；如自动代码审查（安全/测试覆盖/风格/架构各自独立）
- 局限： 当一个子 Agent 的发现应该影响另一个的工作时，编排器成为信息瓶颈；无并行时速度收益减少
3. Agent 团队（Agent Teams）
- 机制： 协调者派生多个持久化工作者，各自从队列认领任务、跨任务保持状态、自主推进多步流程
- 与子 Agent 的区别： 队友跨多个任务持续存在，积累领域上下文
- 适用： 大型代码库迁移——每个队友独立负责一个服务及其依赖和测试
- 局限： 要求任务真正独立；工作相互影响时会冲突（无法共享中间发现）；任务时长不一时完成检测复杂
4. 消息总线（Message Bus）
- 机制： Agent 通过中央路由器发布/订阅事件主题，松耦合交互
- 适用： 随发现而变化的事件驱动流程；新 Agent 能力可接入而无需重新布线。如安全运营中心（SOC）：告警分诊→分类结果路由给专门调查 Agent→发布补充信息请求
- 局限： 分布式处理使执行路径难以追踪；事件路由错误会静默失败；LLM 路由器灵活但引入新故障模式
5. 共享状态（Shared State）
- 机制： Agent 自主运行，直接读写持久化共享存储（数据库/文件系统/文档），通过累积的发现隐式协调；无中央协调者、无单点故障
- 适用： 研究综合——文献分析、行业报告、专利审查、新闻监测各自调查、发现相互启发
- 局限： 可能重复劳动或方向矛盾；可能出现无界循环的反应回路；需要显式终止条件（时间预算、收敛阈值、专职完成判定 Agent）
决策框架
| 对比 | 选择依据 |
|---|---|
| 编排器 vs Agent 团队 | 子任务短、产出离散→编排器；持续多步工作受益于累积上下文→团队 |
| 编排器 vs 消息总线 | 预定流程→编排器；流程由发现的事件涌现→总线 |
| Agent 团队 vs 共享状态 | 可分区的独立工作→团队；发现需要即时互通→共享状态 |
| 消息总线 vs 共享状态 | 事件管道处理→总线；持续知识积累→共享状态 |
建议
- 默认起点：编排器-子 Agent ——以最小的协调复杂度覆盖最广的问题范围
- 生产系统常组合多种模式：如整体用编排器-子 Agent，协作性子任务用共享状态
✅ 检查点
- 五种协作模式各适合什么？
- 多 Agent 最大的隐性成本是什么？
- 什么信号说明你确实该上多 Agent？
👀 答案
- 并行：子任务互相独立，只为提速（如同时查 10 个来源）；串行流水线：每步的输出是下一步的输入，职责清晰；主从编排：一个主 Agent 拆任务派活、汇总结果 —— 最常用；辩论：多个 Agent 互相挑错，用于提高正确率；群体投票：同一任务跑多次取多数，用于降低随机性。
- ⭐ 上下文不共享带来的重复与错位。每个 Agent 只看到自己那部分信息，容易做出局部合理但整体矛盾的决策，而且同样的信息要在多个 Agent 之间反复传递（token 成本成倍）。其次是调试极难——出错时要还原多个 Agent 的交互序列。
- 三个信号：①子任务之间确实独立（否则协调成本吃掉收益）②单个上下文确实装不下③不同子任务需要明显不同的工具集或权限。⚠️ 只是「任务比较复杂」不是理由——先试试单 Agent 加好工具。
🛑 可以停在这里
⚡ 走神救援
五种模式：并行（子任务独立、只为提速）、串行流水线、主从编排（最常用：主 Agent 拆任务派活汇总）、辩论（互相挑错提正确率）、群体投票（多次跑取多数降随机性）。⭐⭐但第一个问题是「真的需要多个 Agent 吗」——协调开销和调试难度都是数量级上升。⭐最大隐性成本是上下文不共享带来的重复与错位：每个 Agent 只看到自己那部分，容易做出局部合理但整体矛盾的决策，同样信息还要反复传递（token 成倍）；其次调试极难。三个该上的信号：子任务确实独立、单个上下文确实装不下、不同子任务需要明显不同的工具集或权限。⚠️「任务比较复杂」不是理由，先试单 Agent 加好工具。