多智能体协同模式：五种核心架构详解
来源：Anthropic 官方多智能体协同指南，宝玉(@dotey) 推荐。原文探讨了五种经过生产验证的多智能体协调模式，本文基于原文中英文对照整理，方便读者理解每种模式的机制、适用场景和失败模式。
前言
多智能体系统的核心问题是：多个 LLM 实例在独立对话上下文下运行，如何通过代码实现协调？
在这篇官方指南中，Anthropic 梳理了五种经过生产验证的多智能体协调模式：
- Generator-verifier（生成-验证者）
- Orchestrator-subagent（调度-子智能体）
- Agent teams（智能体团队）
- Message bus（消息总线）
- Shared state（共享状态）
模式一：Generator-verifier（生成-验证者）
机制
一个 Agent 负责生成输出，另一个 Agent 负责根据明确标准评估输出质量。
典型案例：代码生成场景 — 一个 Agent 写代码，另一个 Agent 运行测试。
何时有效
当验证标准可以明确界定时，此模式效果显著。Generator 产出内容，Verifier 用独立视角审查，不依赖生成过程的理解。
失败模式
Anthropic 特别警告：
如果团队在实现循环时没有明确定义"验证"的含义，就会制造"虚假的质量控制"——看起来有评估环节，实际上没有实质把关。
另一个常见失败：Verifier 跑了一两个测试看到通过就宣布成功。必须要求完整测试套件运行并制定明确的综合检查标准。
适用场景
- 质量保证（运行测试套件、lint 代码、按 schema 验证输出）
- 合规检查（验证文档是否符合政策要求）
- 输出验证（确认生成内容符合规格再交付）
- 事实核查（由独立 Agent 验证生成内容中的论断或引用）
模式二：Orchestrator-subagent（调度-子智能体）
机制
一种层级结构：Lead Agent（调度者）负责任务分解，将边界清晰的子任务分配给专门的 Subagents。Claude Code 已采用此模式：主 Agent 在处理主要工作的同时，派发后台 Subagents 搜索大型代码库。
核心实现
# Lead Agent 分解问题为独立子任务
facets = await lead_agent.decompose_query(query)
# 并行派发 Subagents 研究每个子任务
tasks = [research_subagent(facet) for facet in facets]
results = await asyncio.gather(*tasks)
# Lead Agent 综合各 Subagent 的发现
return await lead_agent.synthesize(results)
何时有效
- 上下文保护：子任务产生的上下文量大（超过 1000 tokens）但大部分与主任务无关时，Subagent 提供隔离
- 并行化：任务可自然拆分为独立部分（跨多来源的研究、跨多组件的测试）
- 专业化：不同任务需要不同的工具集、系统提示或专业知识
失败模式
Anthropic 指出：
Orchestrator-Subagent 会产生信息瓶颈——关键细节在通过中心协调者路由时经常丢失。
另一个陷阱：按问题类型而非上下文边界分解任务（"一个 Agent 写功能，另一个写测试，第三个做审查"），会产生大量协调开销，每个交接都会损失上下文。
适用场景
适合大多数需要多智能体协同的场景，是新团队的最佳起点，协调开销最低，能处理最广泛的问题类型。
模式三：Agent teams（智能体团队）
机制
多个命名 Agent 组成团队，通过消息路由实现持续协作。每个 Agent 有明确角色，通过消息传递进行通信和协调。Claude Code Agent Teams 正是基于此模式：多个 AI Agent 并行工作，分别处理不同任务部分，同时中心协调者追踪进度并综合结果。
关键协调方式
- 通过共享文件系统传递结果
- 通过工具调用结果共享信息
- 通过顺序检查点同步进度
- 不是通过 Agent 间直接通信
主要优势
| 优势 | 说明 |
|---|---|
| 并行性 | 多个任务同时执行 |
| 更大有效上下文 | 团队总体上下文大于任何单个 Agent |
| 专业化 | 不同 Agent 可专注不同任务部分 |
何时有效
任务足够大、多面，或需要真正并行执行时，Agent teams 的协调开销才能被收益覆盖。对于小型任务，Agent teams 反而增加不必要的复杂度。
失败模式
- 上下文隔离问题：Agent 之间共享上下文的方式如果不清晰，会导致信息丢失或重复
- 合并冲突：当多个 Agent 同时修改相关资源时，冲突处理成本高昂
- Token 密集度：Agent teams 通常比单一 Agent 消耗更多 token
模式四：Message bus（消息总线）
机制
多个 Agent 通过一个共享消息总线进行通信和协调。消息总线作为所有 Agent 之间的中央通信层，Agent 发布消息到总线，并从总线订阅它们需要处理的消息。
与 Orchestrator-subagent 的区别
| 维度 | Message bus | Orchestrator-subagent |
|---|---|---|
| 通信模式 | 发布/订阅 | 点对点任务分配 |
| 协调中心 | 无单一协调者 | Lead Agent 主导 |
| 耦合度 | 松散耦合 | 层级耦合 |
| 适用场景 | 事件驱动、工作流自动化 | 任务分解、结果综合 |
何时有效
- 事件驱动的工作流场景
- 需要多个 Agent 对同一事件作出反应
- 工作流步骤之间的依赖关系复杂但清晰
失败模式
- 消息路由复杂时，调试困难
- 需要额外的消息队列基础设施
- 消息格式不匹配导致 Agent 间通信失败
模式五：Shared state（共享状态）
机制
彻底移除中心协调者。Agent 直接从持久化存储中读写，实时建立在彼此的发现之上。
何时有效
- 研究综合系统：一个 Agent 的发现立即影响另一个 Agent 的调查方向
- Agent 之间需要频繁共享状态但不需要严格的消息传递
- 任务可以自然地分解为"读-处理-写"循环
优势
- 消除中心协调者带来的瓶颈
- 更高的并行度
- 更自然的团队协作模式
失败模式
- 状态一致性挑战：多个 Agent 同时写入可能产生冲突
- 调试困难：状态变化链路不直观
- 缺乏中央视图：难以追踪整体进度
模式选择决策框架
按任务独立性选择
| 任务特征 | 推荐模式 |
|---|---|
| 独立子任务，无交叉依赖 | Parallelization（并行处理） |
| 任务有明确分工，需要协调者 | Orchestrator-subagent |
| 任务需要持续协作和消息传递 | Agent teams / Message bus |
| 任务需要共享上下文和实时协作 | Shared state |
按验证需求选择
| 验证需求 | 推荐模式 |
|---|---|
| 需要明确的生成-验证循环 | Generator-verifier |
| 需要黑盒验证（不依赖生成上下文） | Generator-verifier |
| 需要持续验证每个步骤 | Evaluator-optimizer |
Anthropic 建议
对于大多数应用，Anthropic 推荐从 Orchestrator-subagent 开始。它以最小的协调开销处理最广泛的问题类型。
生产系统通常会组合使用多种模式——比如整体工作流用 Orchestrator-subagent，子任务中需要紧密协作的部分用 Shared state。
各模式的失败模式汇总
| 模式 | 主要失败模式 |
|---|---|
| Generator-verifier | 无限循环（Generator 无法响应反馈）；过早宣布通过（未运行完整验证） |
| Orchestrator-subagent | 信息瓶颈（关键细节在协调者处丢失）；按问题类型而非上下文分解 |
| Agent teams | 上下文隔离不清；合并冲突；Token 消耗过高 |
| Message bus | 消息路由复杂；基础设施开销大 |
| Shared state | 状态一致性冲突；调试困难；缺乏全局视图 |
实战建议
1. 从单一 Agent 开始
一个设计良好的单一 Agent + 适当的工具，往往比多智能体系统完成更多工作。多智能体系统引入开销：每个额外 Agent 都代表一个新的潜在故障点、额外需要维护的 Prompts，以及意外行为的另一个来源。
2. 只有当以下情况才使用多智能体
- 上下文污染降低性能时：当子任务的上下文累积影响后续任务质量时
- 任务可以并行运行时：当任务可自然分解为独立部分时
- 专业化能改进工具选择或任务专注度时：当不同任务需要不兼容的工具集或专业领域时
3. 按上下文分解，而非按问题类型
问题类型分解（通常适得其反）：按工作类型划分（一个 Agent 写功能，另一个写测试，第三个审查），会产生持续的协调开销。
上下文分解（通常有效）：按上下文边界分解——处理一个功能的 Agent 也应该处理它的测试，因为它已经拥有必要的上下文。
4. 设置明确的验证检查点
无论选择哪种模式，都要确保有清晰的验证点，让 Subagents 可以在不需要完整上下文的情况下验证工作。
总结对比
| 模式 | 协调复杂度 | 适用场景 | 代表应用 |
|---|---|---|---|
| Generator-verifier | ⭐ | 需要明确验证标准的任务 | 代码生成+测试、合规检查 |
| Orchestrator-subagent | ⭐⭐ | 需要任务分解和结果综合 | 研究调研、代码审查 |
| Agent teams | ⭐⭐⭐ | 需要多角色持续协作 | 复杂软件开发、商业策划 |
| Message bus | ⭐⭐⭐ | 事件驱动、松散耦合的工作流 | 自动化工作流、事件处理 |
| Shared state | ⭐⭐ | 需要实时共享发现的研究任务 | 研究综合、协作式探索 |
参考来源
-
Anthropic 官方博客：《When to use multi-agent systems (and when not to)》 www.claude.com/blog/buildi…
-
Anthropic 工程博客：《How we built our multi-agent research system》 www.anthropic.com/engineering…
-
宝玉(@dotey) X 转发： x.com/dotey/statu…
-
Claude Code Agent Teams： www.mindstudio.ai/blog/what-i…
-
Multi-agent Coordination Patterns (daily.dev 整理)： app.daily.dev/posts/multi…
本文基于 Anthropic 官方文档整理，保留原文核心内容，仅做中文化处理和必要结构调整。如需深入了解，建议阅读原文。
