多智能体 Multi-Agent 协作的 5 种模式：怎么选、怎么演进
Multi-Agent 系统越来越常见，但"用多个 Agent 协作"本身不是目标——选错模式，复杂度只会翻倍。
这篇文章梳理了 Anthropic 给出的 5 种 Multi-Agent 协作模式，每种模式说清楚三件事：适合什么场景、不适合什么场景、核心难点在哪。最后给出选型口诀和演进路径。
核心原则：从最简单的模式开始，看它在哪里撑不住，再往上演化。
五种模式一览
| 模式 | 核心思路 | 类比 |
|---|---|---|
| 生成-验证器 | 一个生成，一个验收，来回迭代直到通过 | 起草与审校 |
| 编排者-子 Agent | 主 Agent 拆任务派任务收结果，子 Agent 处理专项 | 总包经理叫专家会诊 |
| Agent Teams | 协调者带长期存在的 Worker，越干越熟 | 工地常驻班组 |
| 消息总线 | Agent 通过发布/订阅事件协作，Router 负责分发 | 医院分诊台 |
| 共享状态 | 所有 Agent 读写同一共享存储，实时积累信息 | 专案组围着白板办案 |
模式一：生成-验证器（Generator-Verifier）
什么是生成-验证器？ 将"生成"和"验证"拆分为两个独立步骤：生成器先产出结果，验证器按明确标准验收，不通过则反馈修改，循环直到通过或达到最大迭代次数。
关键前提：生成能力和验证能力是可分开的，且验证标准客观、可自动化。
适合：代码生成
生成器写代码，验证器跑测试套件——测试要么通过要么失败，标准客观、可自动化、不依赖人判断。验证器不需要"理解"代码，只需执行并读结果。生成和验证是两种完全不同的能力，天然可拆分。
不适合：文案创作
让验证器判断"这段文案够不够有说服力"——验证难度和生成难度一样高，验证器给不出客观结论，要么流于形式审核，要么循环不收敛。
核心难点
- 验证器缺乏明确标准，易成形式审核
- 生成与评估难度相当时（如判断文案说服力），模式失效
- 循环不收敛，需设置最大迭代次数和 fallback 机制
模式二：编排者-子 Agent（Orchestrator-Subagent）
什么是编排者-子 Agent？ 主 Agent 负责理解总任务、拆分子任务、派发给子 Agent，再回收结果拼成完整答案。核心是层级协调：主 Agent 保持对整体目标的聚焦，子 Agent 在独立上下文处理各自专项工作。
适合：自动代码审查
主 Agent 收到 PR，拆成三个独立子任务分别派给三个子 Agent：检查安全漏洞、检查测试覆盖、检查代码风格。三个任务边界清晰、互不依赖，子 Agent 各自在独立上下文完成后汇报结果，主 Agent 汇总输出审查报告。
不适合：子 Agent 之间需要频繁协商的任务
比如多 Agent 协作写一篇长报告，A 写第一章、B 写第二章——B 的内容依赖 A 的结论，信息必须在子 Agent 之间流转。但这个模式里子 Agent 间没有直接通道，所有信息都要经主 Agent 中转，每次传递都有损耗，链路越长信息失真越严重。
核心难点
- 主 Agent 成为信息瓶颈，子 Agent 间信息需经主 Agent 中转，易损耗
- 无显式并行时速度未必提升，token 成本增加但吞吐量未提高
模式三：Agent Teams
什么是 Agent Teams？ 协调者带长期存在的 Worker，Worker 反复处理特定类型工作，持续积累局部知识。区别于编排者-子 Agent 的"临时专家会诊"，Worker 是常驻班组，对负责领域越来越熟悉。
适合：大型代码库框架迁移
把一个 monorepo 从 React 16 迁移到 React 18，按服务拆分：Worker A 负责用户服务、Worker B 负责支付服务、Worker C 负责通知服务。每个 Worker 长期驻留，熟悉自己负责的模块，迁移过程中积累的上下文（哪些 API 已改、哪些坑踩过）持续复用。
不适合：各模块改动高度耦合的任务
比如全局重构数据库 schema，每张表的改动都会影响其他 Worker 负责的模块。Worker 之间的变更频繁冲突，协调者要不停介入仲裁，常驻的优势反而变成负担——Worker 积累的局部知识可能已经过时。
核心难点
- 任务独立性是硬前提，Worker 间变更易冲突
- 完成检测难，不同 Worker 节奏不同步
- 共享资源冲突（如改同一文件）
模式四：消息总线（Message Bus）
什么是消息总线？ Agent 通过发布（publish）和订阅（subscribe）事件协作，由 Router 负责消息路由。中心从"总指挥"变为"路由层"，扩展性强，新 Agent 订阅相关 topic 即可接入，不用改主流程。
适合：安全运营自动化
告警进来发布到总线，Router 按告警类型路由：DDoS 告警 → 流量分析 Agent，登录异常 → 身份核查 Agent，数据泄露 → 取证 Agent。新增一类告警只需新增一个订阅者。流程本身就是不可预测的——不知道下一条告警是什么类型，消息总线天然适合这种动态分发。
不适合：步骤固定的线性流程
比如"用户下单 → 扣库存 → 扣款 → 发货"这种顺序固定、步骤明确的流程。用消息总线反而引入了不必要的路由层，出了问题要追事件链，比直接写顺序调用难调试得多。
核心难点
- 追踪难，事件链复杂，需详细日志和关联 ID
- 路由准确性关键，分错或丢事件可能导致系统"活着但不工作"。尤其使用 LLM 语义路由时——规则路由是确定性的（
if type == "DDoS" → 流量分析 Agent），LLM 路由是概率性的，同一条消息在不同上下文下可能路由到不同 Agent，出错时难以复现和排查
模式五：共享状态（Shared State）
什么是共享状态？ 所有 Agent 直接读写同一共享存储（数据库、文件系统等），信息实时积累，无中央协调者或 Router。共享存储演化为知识空间，单点 Agent 故障不导致系统停摆。
适合：多 Agent 并行研究
调查一个投资标的：Agent A 查财报、Agent B 查行业报告、Agent C 查专利数据库。三者把发现实时写入共享存储，Agent B 看到 Agent A 发现的财务异常后立刻调整自己的搜索方向。没有中央协调者，任何一个 Agent 挂掉不影响其他人继续工作。
不适合：需要严格执行顺序的流程
比如合同审批流程，必须法务审完才能财务审，财务审完才能 CEO 签字。共享状态里没有天然的顺序控制，多个 Agent 可能同时读写同一份合同，产生并发冲突，还容易触发 reactive loop——A 改了合同，B 看到变化又改，A 再响应……
核心难点
- 工程问题：重复劳动、并发写冲突，需靠锁、版本控制缓解
- 行为问题：reactive loop，Agent 间反复响应导致 token 消耗但不收敛，需设计明确的终止条件
易混淆的模式对比
四个核心判断问题：
- Worker 需要长期保留上下文，还是用完即弃？→ 编排者-子 Agent vs Agent Teams
- 工作流是否可预测？→ 编排者-子 Agent vs 消息总线
- Agent 之间要不要共享中间发现？→ Agent Teams vs 共享状态
- 系统处理的是事件流，还是知识累积？→ 消息总线 vs 共享状态
简单记：
- 编排者-子 Agent vs Agent Teams：前者是临时专家会诊（做完即散），后者是常驻班组（持续存在，越干越熟）
- Agent Teams vs 共享状态：前者各小组独立工作后汇总，后者中间发现实时互相影响
- 消息总线 vs 共享状态：前者围绕事件流（分诊台式路由），后者围绕共享知识（共同更新的"病例"）
选型与演进
从哪里开始
- 任务只有单一质量节点（生成 + 验收）→ 从生成-验证器开始，最简单
- 多任务协作场景 → 从编排者-子 Agent 开始，覆盖面广、协调开销低，适合系统起步阶段先跑通
演进路径
flowchart TD
A[编排者-子 Agent] -->|Worker 需长期保留上下文| B[Agent Teams]
A -->|工作流不可预测，条件分支爆炸| C[消息总线]
B -->|Agent 间需共享中间发现| D[共享状态]
C -->|从处理事件流转向知识累积| D
生成-验证器的特殊作用
生成-验证器更像质量闸门，可在关键节点叠加使用。只要某节点需严格验收且验收标准明确，无论外层是哪种模式，都可以加一个生成-验证器回路。
组合使用
生产系统通常组合多种模式：
- 外层编排者-子 Agent 跑整体工作流，协作密集的子任务用共享状态
- 外层消息总线做事件路由，每类事件由 Team 风格的长期 Worker 处理
- 大部分流程保持可控主线，复杂研究/排查环节切到共享状态
选型口诀
先从编排者-子 Agent 起步，跑通后根据系统信号演进：
- 长期 ownership 重要 → Agent Teams
- 条件分支爆炸 → 消息总线
- 共享发现比分工更重要 → 共享状态
- 关键质量节点 → 叠加生成-验证器
模式是积木而非菜单，需灵活组合。
本文内容整理自慢学AI 视频12，结合 Anthropic 官方博客整理，加入了个人理解和补充。
Footnotes
-
慢学AI 抖音视频：Multi-Agent 协作模式（上） ↩
-
慢学AI 抖音视频：Multi-Agent 协作模式（下） ↩
