多智能体编排：4 种真正有效的架构模式

单个 AI 智能体能做很多令人印象深刻的事情 — 直到它做不到为止。给一个智能体一个包含 200 个文件的代码库、跨越 50 轮的对话历史，再加上混合了重构、测试和文档编写的指令，你就会看到它慢慢崩溃。回复开始偏离主题，成本飙升，智能体开始在项目中不相关的部分之间"幻觉"出联系。

解决方案不是更聪明的模型，而是更好的架构。

多智能体编排 — 协调多个专业化智能体处理复杂任务的实践 — 已经在 2026 年从研究论文走向了生产系统。Claude Code、Cursor 和 Google Antigravity 等工具底层都使用了多智能体模式。对于严肃的 AI 工程师来说，理解这些模式已经不再是可选项。

本指南涵盖四种在生产中真正有效的编排模式、各自的适用场景，以及如何有效实现它们。

为什么单智能体在规模化时会失败

在讨论解决方案之前，先理解问题。单智能体架构在使用增长时会遇到三个可预测的瓶颈。

瓶颈一：记忆膨胀

每次对话都会增加智能体的上下文。记忆文件、项目文档、历史交互 — 全部在不断累积。一个同时处理写作、编码、研究和调试的单智能体，每次请求都要加载数兆字节的上下文。

结果是：响应延迟随使用历史线性增长。 第一天 2 秒就能响应的智能体，到第三周可能需要 8 秒。更糟糕的是，模型的注意力被分散到不相关的上下文上，降低了每次回复的质量。

瓶颈二：上下文污染

这是更隐蔽的杀手。当单个智能体处理多个领域时，一个领域的知识会渗透到另一个领域。让你的万能智能体写营销文案，它会开始插入代码风格的格式；让它审查 Pull Request，它会引用昨天对话中的博客大纲。

上下文污染的发生是因为大语言模型在"主题"之间没有硬边界。上下文窗口中的所有内容都会相互影响。智能体的职责越多样，交叉污染就越严重。

瓶颈三：成本爆炸

这个直接打击预算。如果你的智能体每次请求都携带 50,000 个 token 的累积上下文，无论这些 token 是否相关，你都在为它们付费。一个同时记住你的写作风格偏好、研究笔记和会议摘要的编码智能体，在当前任务中为零价值的上下文消耗着 token。

共同的核心问题：一个承担太多职责的单智能体积累了太多不相关的状态。 解决方案就是专业化。

四种编排模式

多智能体编排不是单一技术 — 它是一系列架构模式。每种模式适合不同的用例。根据 LangChain 的多智能体架构分析和 Anthropic 的智能体设计文档的研究，四种模式已经成为生产系统的主力。

模式一：流水线（Pipeline）

流水线模式将智能体按顺序串联。每个智能体的输出成为下一个智能体的输入，就像流水线上的工位。

用户请求
    ↓
┌──────────┐    ┌──────────┐    ┌──────────┐
│  研究    │ →  │  起草    │ →  │  审查    │
│  智能体  │    │  智能体  │    │  智能体  │
└──────────┘    └──────────┘    └──────────┘
                                     ↓
                                最终输出

工作原理： 研究智能体收集信息并产出结构化的简报。起草智能体基于简报产出内容。审查智能体检查草稿的准确性、风格和完整性。

适用场景：

• 内容创建工作流（研究 → 写作 → 编辑 → 发布）
• 代码开发流水线（设计 → 实现 → 测试 → 审查）
• 数据处理链（收集 → 清洗 → 分析 → 可视化）

优势：

• 易于理解 — 数据单向流动
• 每个智能体的职责狭窄且明确
• 易于调试 — 可以检查每个阶段的输出

劣势：

• 总延迟是所有阶段的总和
• 任何阶段的失败都会阻塞整个流水线
• 无法处理需要在阶段间迭代的任务

生产案例： 很多集成了 CI/CD 的编码工作流使用流水线编排。规划智能体产出规格说明，实现智能体编写代码，测试智能体进行验证。如果测试失败，流水线从实现阶段重新开始，并将测试结果作为额外上下文。

模式二：路由器（Router）

路由器模式使用轻量级分类器将传入请求定向到正确的专家智能体。与流水线不同，这里没有顺序链 — 每个请求只发送给一个智能体。

用户请求
    ↓
┌──────────────┐
│    路由器    │
│  (分类器)    │
└──┬─────┬──┬─┘
   ↓     ↓  ↓
┌────┐ ┌────┐ ┌────┐
│编码│ │写作│ │调试│
│智能│ │智能│ │智能│
│ 体 │ │ 体 │ │ 体 │
└────┘ └────┘ └────┘
   ↓     ↓     ↓
  返回给用户的响应

工作原理： 路由器分析传入请求 — 有时使用更小、更快的模型 — 并将其分类到某个类别。基于分类结果，将请求转发给相应的专家智能体。每个专家有自己的系统提示词、工具和记忆。

适用场景：

• 处理不同任务类型的多功能助手
• 设有专业部门的客服系统
• 编码、调试和文档编写分离的开发环境

优势：

• 低延迟 — 每个请求只有一个专家智能体处理
• 专家可以独立优化（不同模型、不同上下文）
• 水平扩展 — 添加新专家无需更改现有专家

劣势：

• 路由器误分类会将请求发送给错误的智能体
• 无法处理跨多个领域的任务
• 需要良好的训练数据或分类层的规则

生产案例： OpenClaw 的 Bindings 机制是一个确定性路由器。它根据频道、群组 ID 和用户身份匹配传入消息到智能体 — 不需要 LLM 分类，只需基于规则的路由。这种方法对已知路由模式完全消除了误分类。

模式三：编排者-工作者（Orchestrator-Worker）

这是生产 AI 编码工具中最强大、也最常见的模式。中央编排者智能体规划工作、生成工作者智能体执行，并综合它们的结果。

用户请求
    ↓
┌────────────────┐
│    编排者      │
│  (规划工作)    │
└──┬──────┬────┬─┘
   ↓      ↓    ↓     ← 生成工作者
┌─────┐┌─────┐┌─────┐
│工作 ││工作 ││工作 │
│者 1 ││者 2 ││者 3 │
└──┬──┘└──┬──┘└──┬──┘
   ↓      ↓      ↓
┌────────────────┐
│    编排者      │
│  (审查工作)    │
└────────────────┘
    ↓
最终输出

工作原理： 编排者接收复杂任务，将其分解为子任务，将每个子任务分配给工作者智能体，监控进度，并组装最终结果。工作者独立运行，但向编排者汇报。

适用场景：

• 涉及多个文件或系统的复杂编码任务
• 任何需要规划和并行执行的任务
• 子任务独立但最终结果需要整合的场景

优势：

• 自然地处理复杂的多步骤任务
• 工作者可以并行运行以加快完成速度
• 编排者提供质量控制和错误恢复
• 直接映射到人类工程团队的工作方式

劣势：

• 总 token 成本更高（编排者 + 所有工作者）
• 编排者是单点故障
• 需要精心的任务分解以避免工作者范围重叠

生产案例：

Claude Code Worktree： Claude Code 的 Worktree 功能是教科书式的编排者-工作者实现。主 Claude Code 实例充当编排者 — 分析任务，为并行工作创建独立的 git worktree，在每个 worktree 中生成子智能体，最后合并结果。每个工作者在隔离的文件系统分支中操作，防止冲突。

Cursor 后台智能体： Cursor 的多智能体系统允许你生成并行智能体，同时在代码库的不同部分工作。每个智能体获得自己的沙箱环境，结果合并回主分支。

Google Antigravity Manager View： Antigravity 的 Manager View 提供了编排多个智能体的可视化仪表板。你可以看到每个智能体的进度，重新分配任务，在智能体卡住时进行干预 — 本质上是编排者-工作者模式的 GUI。

模式四：评估器-优化器（Evaluator-Optimizer）

评估器-优化器模式在两个智能体之间创建反馈循环：一个生成输出，另一个评估它，生成器根据评估进行迭代。

用户请求
    ↓
┌────────────┐
│   生成器   │ ←──────────────┐
│   智能体   │                │
└─────┬──────┘                │
      ↓                       │
┌────────────┐         ┌──────┴─────┐
│   评估器   │ ──────→ │   反馈     │
│   智能体   │         │   循环     │
└─────┬──────┘         └────────────┘
      ↓
  (满足标准？)
      ↓ 是
  最终输出

工作原理： 生成器智能体产出初始输出。评估器智能体根据预定义标准对其评分并提供具体反馈。如果分数低于阈值，生成器接收反馈并产出改进版本。这个循环重复进行，直到评估器满意或达到最大迭代次数。

适用场景：

• 代码审查和改进循环
• 内容质量保证
• 任何迭代改进优于一次性生成的任务

优势：

• 通过迭代产出更高质量的输出
• 评估器能捕获生成器系统性遗漏的错误
• 明确的停止标准（评估器通过）
• 不同的角色可以使用不同的模型（便宜的模型生成，昂贵的模型评估）

劣势：

• 多次迭代增加延迟和成本
• 如果停止标准太严格，有无限循环的风险
• 评估器和生成器可能发展出对抗性动态

生产案例： StockApp 等团队使用的"集成方法"在评估器-优化器循环中部署多个 AI 模型。一个模型编写代码，另一个模型（有时来自不同提供商）审查代码。模型的多样性提供了更广的错误覆盖 — 每个模型有不同的盲点，跨模型审查比同模型自审能发现更多问题。

选择正确的模式

不是每个任务都需要多智能体编排。从简单开始，只在遇到明确限制时才升级。

推荐的演进路径：

单智能体 + 工具
    ↓ (上下文污染开始出现)
单智能体 + 技能/插件
    ↓ (记忆膨胀、成本问题)
路由器（2-3 个专家智能体）
    ↓ (需要跨智能体协作)
编排者-工作者 或 流水线
    ↓ (需要质量保证)
添加评估器-优化器循环

核心原则： 先加工具，再加智能体。只有在遇到工具级方案无法解决的明确瓶颈时，才升级到多智能体。

自主性光谱

不是所有任务都值得给予智能体相同的独立程度。斯坦福 CS146S 课程（第 4 周，由 Claude Code 创建者 Boris Cherney 讲授）引入了自主性光谱 — 一个帮助你决定给智能体多大自由度的框架。

低自主性：直接执行

• 任务类型： 输入清晰，输出清晰，决策最小
• 例子： 重命名变量、添加类型注解、修复 lint 错误、为现有函数编写单元测试
• 管理方式： 下达指令，接受结果
• 时间节省： 约 95%

在这个层级，智能体本质上是一个非常快的打字员。你告诉它做什么，它就做什么。几乎不需要监督。

中自主性：引导式实现

• 任务类型： 需要一些设计决策，涉及多个文件，有模糊的边界情况
• 例子： 实现新的 API 端点、重构模块、添加带 UI 变更的功能
• 管理方式： 提供详细上下文，在检查点审查，打磨最后的 20%
• 时间节省： 约 80%

这是大多数实际开发工作的所在。智能体处理 80% 的实现，但你需要审查架构选择、处理边界情况，并确保与现有代码库的一致性。

你的角色从"敲代码的人"转变为**“结对编程伙伴”** — 你和智能体协作，你专注于智能体无法做好的决策。

高自主性：战略委派

• 任务类型： 跨系统变更、架构决策、高不确定性
• 例子： 数据库 schema 设计、微服务通信模式、性能优化、安全加固
• 管理方式： 分阶段执行，每个阶段设检查点
• 时间节省： 30-60%

在这个层级，智能体就像初级工程师 — 能够完成大量工作，但在每个关键决策点都需要高级工程师的监督。你规划阶段、为每个阶段定义验收标准、在每个阶段后审查，并根据需要修正方向。

关键思维转变： 不要期望智能体一次性完成复杂任务。将复杂任务拆分为中自主性的子任务，按顺序执行，在继续之前验证每一步。

智能体管理者角色

多智能体系统的兴起创造了一种新技能：智能体管理。这不是关于写代码 — 而是关于指挥写代码的智能体。

Boris Cherney 在斯坦福 CS146S 的演讲中指出，智能体管理是 AI 辅助开发中杠杆率最高的技能。以下是它的核心内容。

任务分解

最重要的智能体管理技能。像"将前端从 Vue 2 迁移到 Vue 3"这样的复杂需求需要被拆分为智能体大小的任务块：

❌ 错误: "将整个前端从 Vue 2 迁移到 Vue 3"

✅ 正确: "将 src/components/Button.vue 迁移到 Vue 3 Composition API。
   保持相同的 props 接口。运行 `npm test -- --grep Button`
   进行验证。不要修改任何其他文件。"

每个子任务应该有：

• 明确的输入： 智能体需要哪些文件/信息
• 明确的输出： 智能体应该产出什么
• 明确的验证： 如何验证子任务已完成
• 有界的范围： 不超过单次 PR 审查的量

检查点审查

不要让智能体长时间无监督运行。设置检查点：

1. 规划后： 在智能体开始编码前审查其计划
2. 实现后： 在运行测试前审查代码
3. 测试后： 在合并前审查测试结果和覆盖率
4. 集成后： 验证变更在更大系统中正常工作

每个检查点都是修正方向的机会。在规划阶段发现错误方向比在实现后发现节省数小时。

上下文管理

你给智能体什么比你让它做什么更重要。遵循最小充分上下文原则：

• 只提供与当前子任务相关的信息
• 使用分层结构：全局上下文（项目规则）→ 本地上下文（当前文件/模块）→ 任务上下文（具体指令）
• 保持上下文一致 — 不同上下文层中的矛盾指令会导致不可预测的行为
• 每个子任务后更新上下文 — 下一个任务可能需要前一个任务输出的信息

这就是 CLAUDE.md 配置文件大显身手的地方。一个写得好的 CLAUDE.md 充当每个智能体会话都继承的持久上下文，消除了在每个提示中重复项目规范的需要。

智能体间通信

在多智能体系统中，智能体之间如何通信与每个智能体做什么同样重要。

结构化消息传递

智能体应该通过结构化数据通信，而不是自由文本。当智能体 A 将工作传递给智能体 B 时，交接应该像这样：

{
  "task": "implement_endpoint",
  "context": {
    "endpoint": "/api/users/:id",
    "method": "GET",
    "schema": "See schema.sql lines 45-60",
    "constraints": ["must return 404 for missing users", "response time < 200ms"]
  },
  "acceptance_criteria": [
    "All existing tests pass",
    "New endpoint has >80% test coverage",
    "Follows project REST conventions in CLAUDE.md"
  ]
}

结构化通信减少误解。像"根据我们讨论的内容实现用户端点"这样的自由文本给接收智能体留了太多错误填补空白的空间。

通信拓扑

不是每个智能体都需要与其他每个智能体通信。定义明确的通信渠道：

• 中心辐射型： 所有通信通过编排者。工作者之间不直接通信。简单但在编排者处造成瓶颈。
• 对等型： 智能体可以直接通信。更灵活但更难调试，可能导致循环依赖。
• 层级型： 智能体组织成树形结构。每个智能体只与其父节点和子节点通信。对大型系统扩展性好。

对于大多数实际应用，通过编排者的中心辐射型是正确的选择。它更易于理解、更易于调试，编排者提供了日志记录和监控的自然切入点。

基于白名单的权限

智能体间通信应该显式启用，而不是隐式可用。遵循最小权限原则：

{
  "agentToAgent": {
    "enabled": true,
    "allow": ["orchestrator", "coder", "reviewer"]
  }
}

只有真正需要通信的智能体才应该在允许列表中。文档智能体不需要直接与部署智能体通信 — 如果它们需要协调，应该通过编排者进行。

实际案例

理论有用，但在生产系统中看到这些模式才能让它们具体化。以下是三个值得研究的实现。

Claude Code Worktree：编排者-工作者的实践

Claude Code 的 Worktree 功能是编码任务中最干净的编排者-工作者生产实现。

工作流程：

1. 你给 Claude Code 一个复杂任务（例如，“为 API 添加认证”）
2. 主实例分析任务并创建计划
3. 创建独立的 git worktree — 仓库的隔离副本
4. 在每个 worktree 中生成子智能体来处理独立的子任务
5. 每个子智能体独立工作互不干扰（通过 git worktree 实现文件系统隔离）
6. 主实例审查完成的工作并合并结果

为什么效果好： Git worktree 提供了真正的文件系统隔离。重构 auth 模块的智能体 A 不可能意外破坏智能体 B 在用户端点上的工作，因为它们实际上在代码的不同副本上工作。这消除了困扰大多数多智能体编码设置的协调开销。

深入了解 Worktree 的设置和使用，请参阅 Claude Code Worktree 指南。

Cursor 后台智能体：并行执行

Cursor 采用了不同的多智能体编码方法。其后台智能体在云沙箱中运行，每个都有完整的开发环境。

核心差异化： Cursor 智能体可以真正并行运行 — 不仅是并发文件编辑，还包括独立的 CI 流水线、测试套件和构建过程。你可以让一个智能体实现功能，同时另一个智能体为不同的功能编写测试，各自在自己的沙箱中运行。

权衡： 云沙箱相比本地执行增加了延迟。但对于在大型代码库上工作的团队来说，并行性的收益大于每个智能体的额外开销。

关于不同工具如何处理多智能体工作流的比较，请参阅 AI 编码智能体对比。

Antigravity Manager View：可视化编排

Google Antigravity 的 Manager View 为智能体编排带来了可视化界面。你得到的不是通过 CLI 命令或配置文件管理智能体，而是一个仪表板，显示：

• 每个智能体的当前任务和进度
• 每个智能体的实时输出
• 暂停、重定向或终止单个智能体的能力
• 子任务如何连接到整体目标的统一视图

这种方法降低了智能体管理的门槛。你不需要熟悉基于终端的工作流就能有效地编排多个智能体。

Claude Code Agent Teams：基于团队的编排

对于需要多个开发者通过 AI 智能体协调的团队，Claude Code 的 Teams 功能提供了共享上下文、一致的编码标准和跨团队成员的协调多智能体工作流。这将编排者-工作者模式从单个开发者扩展到整个工程团队。

生产最佳实践

这些经验来自在生产中运行多智能体系统的团队，而不是玩具示例。

1. 从两个智能体开始，而不是十个

最常见的错误是过度设计智能体拓扑。从简单的拆分开始 — 一个编排者和一个工作者 — 只在有证据表明当前设置遇到瓶颈时才添加智能体。

经验法则： 如果两个智能体 80% 以上的时间在处理类似的任务，合并它们。如果一个智能体的上下文持续被不相关的职责污染，拆分它。

2. 给每个智能体最小权限

写作智能体不需要代码执行能力。测试智能体不需要测试目录以外的文件写入权限。将每个智能体的工具和权限范围限制在它所需的范围内。

写作智能体：read, browse          (不能 exec，不能 write)
编码智能体：read, write, exec     (不能 browse)
审查智能体：read                  (不能 write，不能 exec)

最小权限不仅是安全措施 — 它还减少了智能体采取意外操作偏离工作流的可能性。

3. 为不同角色使用不同模型

不是每个智能体都需要最贵的模型。将模型能力与任务复杂度匹配：

使用更便宜的模型做路由、高端模型做代码生成，可以在不损失质量的情况下将总成本降低 40-60%。

4. 内建回退机制

智能体会失败。网络会超时。模型会返回垃圾。你的多智能体系统需要优雅地处理这些情况：

• 指数退避重试处理瞬态故障
• 工作者智能体无响应时回退到编排者
• 评估器-优化器循环的最大迭代限制防止无限循环
• 超出智能体置信度阈值的任务进行人工升级

5. 记录一切

多智能体调试从根本上比单智能体调试更难。你需要了解：

• 每个智能体收到了什么输入
• 每个智能体产出了什么输出
• 每个智能体用了多长时间
• 发生了哪些智能体间通信
• 故障源自流水线的哪个位置

使用关联 ID（将处理同一用户请求的所有智能体关联起来）的结构化日志是必不可少的。没有它，调试多智能体系统就像在没有链路追踪的情况下调试分布式微服务架构 — 理论上可行，但实际上是噩梦。

6. 设计优雅降级

如果你的审查智能体宕机，系统应该仍然能够产出代码 — 只是没有审查步骤。如果你的研究智能体失败，写作智能体应该能够以降低的质量产出内容，而不是完全失败。

在可能的情况下，将每个智能体交互设计为可选增强而不是硬依赖。

构建你自己的多智能体系统

如果你想深入了解并从零构建多智能体编排，从零构建 AI 智能体指南详细介绍了 Python 中智能体架构的基础 — 包括工具使用、记忆管理和多智能体协调所需的编排原语。

作为实践起点，以下是一个最小的编排者-工作者设置：

class Orchestrator:
    def __init__(self, workers: dict[str, Agent]):
        self.workers = workers

    def execute(self, task: str) -> str:
        # 第一步：规划
        plan = self.plan(task)

        # 第二步：将子任务分配给工作者
        results = {}
        for subtask in plan.subtasks:
            worker = self.workers[subtask.agent_type]
            results[subtask.id] = worker.execute(subtask.instructions)

        # 第三步：综合结果
        return self.synthesize(results)

    def plan(self, task: str) -> Plan:
        """使用 LLM 将任务分解为子任务。"""
        ...

    def synthesize(self, results: dict) -> str:
        """将工作者输出组合为最终结果。"""
        ...

核心洞察：编排本质上是关于规划、委派和综合。编排者决定做什么，工作者执行，编排者组合结果。其他一切 — 错误处理、重试、并行执行、质量检查 — 都建立在这个核心循环之上。

未来展望

多智能体编排正在快速演进。三个值得关注的趋势：

1. 自主智能体团队： 智能体可以自行生成子智能体的系统，无需人工定义拓扑。Claude Code 的 Worktree 已经展现了这一点 — 主智能体自行决定何时以及如何并行化工作。

2. 跨工具编排： 将来自不同提供商的智能体组合使用。想象一下将 Claude Code 智能体用于推理、Cursor 智能体用于 IDE 集成、Antigravity 智能体用于免费并行探索的组合。MCP（Model Context Protocol）正在让这变得更加实际。

3. 智能体原生开发工作流： 不是将现有工作流调整为包含智能体，而是从一开始就设计为多智能体的工作流。这意味着重新思考从版本控制到代码审查再到部署流水线的一切。

现在掌握多智能体编排的开发者，在这些系统成为软件构建的默认方式时将拥有显著优势。

相关阅读

• Claude Code 完全指南 — 掌握开创编码编排者-工作者模式的工具
• Claude Code Worktree 指南 — 深入了解使用 git worktree 的并行智能体执行
• Claude Code Teams 指南 — 跨工程团队的多智能体协调
• AI 编码智能体对比 2026 — 不同工具如何实现多智能体模式
• 从零构建 AI 智能体 — 通过亲手构建来理解智能体内部原理
• Google Antigravity 评测 — 可视化智能体编排与 Manager View
• LangChain: 选择多智能体架构 — 框架层面的编排模式视角
• Anthropic: 构建高效智能体 — Claude 团队的官方智能体设计指南