前言

随着大模型技术的普及，AI Agent 已经成为了构建智能应用的核心范式。通过 ReAct 思维链、工具调用等能力，单 Agent 已经能够帮我们完成从代码编写到文档分析的大量任务。

为什么需要 Multi-Agent？

当单个 Agent 受制于上下文容量、执行效率与职责边界时，Multi-Agent 通过多个相互协作的独立循环加以应对。其工程本质是：多个独立的 while true 循环并行运行，上下文彼此隔离，互不干扰。

---

一、单 Agent 的三类核心局限

在实际工程落地中，单 Agent 架构面临以下不可回避的瓶颈：

1. 上下文容量受限

面对数十万行的大规模代码库，单一上下文窗口无法完整容纳所有相关信息。即使采用 RAG 或代码压缩技术，当任务涉及跨模块、跨文件的复杂关联时，上下文截断不可避免。

2. 串行执行低效

相互独立的子任务（如同时检索多个数据源、并行审查多个文件）仍须顺序执行，无法并行化。整体吞吐受限，延迟随任务数量线性增长。

3. 职责边界模糊

搜索、编码、审查、测试等异质任务集中于同一 Agent，易导致推理偏移（reasoning drift）。模型在角色切换中混淆目标，输出质量下降。

---

二、理论基础：AutoGen 的对话驱动架构

Microsoft Research 于 2023 年提出的 AutoGen（arXiv:2308.08155） 是 Multi-Agent 领域的奠基性工作，系统化提出了将复杂任务拆分给多个"可对话"Agent 的范式。

核心组件

Agent 类型	职责	特点
Assistant Agent	生成代码与解决方案	具备 LLM 推理能力
User Proxy Agent	执行操作与确认结果	可执行代码、调用工具

关键设计原则

1. 对话即协作：Agent 之间通过结构化消息传递任务与结果，而非共享内存
2. 状态隔离：每个 Agent 维护独立的对话历史，保持上下文隔离
3. 灵活拓扑：支持两方对话（Two-Agent）或多方群聊（Group Chat）模式

AutoGen 的 GroupChatManager 负责协调多个 Agent 的发言顺序，支持轮询、随机或基于 LLM 的智能选择策略 。

---

三、工程实践：Orchestrator-Workers 模式

Anthropic 在《Building Effective Agents》 中提出的 Orchestrator-Workers 模式已成为业界 Multi-Agent 工程实践的黄金标准。

模式架构

Orchestrator（编排者）

• 接收整体目标：理解用户意图与约束条件
• 动态拆解子任务：根据输入实时决定需要哪些子任务（非预定义）
• 按需分派：将子任务分配给各 Worker
• 统一汇总：收集所有 Worker 结果，整合为最终输出

Worker（执行者）

• 独立承接单一子任务：专注特定领域（如代码审查、文档生成）
• 执行完成后回流结果：向 Orchestrator 返回结构化输出
• 并行运行：各 Worker 可同时执行，互不干扰
• 上下文隔离：每个 Worker 拥有独立的对话历史与工具权限

适用场景

根据 Anthropic 的建议，此模式特别适用于 ：

• 代码生成产品：每次执行需对多个文件进行复杂协同修改
• 信息检索任务：从多个来源收集并分析信息以识别相关内容

---

四、源码层：Claude Code 的实现机制

Claude Code 的 Multi-Agent 实现是工程落地的典范。其源码揭示了 Multi-Agent 架构的底层实现细节 。

核心文件架构

模块	关键文件	职责
Agent Tool	AgentTool.tsx	主入口，路由分发，参数解析
执行引擎	runAgent.ts	Agent 生命周期管理，查询循环
上下文管理	forkedAgent.ts	系统提示词构建，上下文隔离
任务系统	LocalAgentTask/	状态追踪，进度更新

Orchestrator 主循环（AgentTool.tsx）

主循环沿用 while true，维持 ReAct 基本范式 ：

// 简化的核心逻辑
async function* queryLoop(params: QueryParams): AsyncGenerator<...> {
  let state: State = { /* 初始化状态 */ };
  
  while (true) {
    // THINK: 组装上下文、系统提示词、工具
    // ACT: 流式调用 Claude 模型
    // OBSERVE: 执行工具调用，收集结果
    // REPEAT: 将结果追加到消息，循环继续
  }
}

当模型输出 tool_use block 中携带 AgentTool 时，触发子 Agent 入口。在 runTools 阶段可同时触发多个 AgentTool，实现并行派发；主循环阻塞等待所有子 Agent 完成 。

Worker 子 Agent（runAgent.ts）

每个子 Agent 的实现遵循以下原则 ：

1. 独立 Agent ID：每个子 Agent 持有唯一标识符
2. 上下文隔离：通过 forkedAgent.ts fork 出独立上下文——消息历史与执行状态完全隔离
3. 独立查询循环：通过 for await query 启动自身的 while true 查询循环
4. 资源隔离：支持 Worktree 隔离（Git 工作树）、Remote 隔离（远程会话）或 In-process 隔离（仅上下文隔离）

// AgentTool.call() 的调度逻辑
AgentTool.call() 处理:
  ├── 解析输入参数
  ├── 判断是否 teammate/fork/built-in/background/worktree/remote
  ├── 选择 agent definition
  ├── 构造 prompt messages
  ├── 组装工具池
  ├── 创建 agent-specific ToolUseContext
  ├── 注册 hooks/skills/MCP servers
  ├── 调用 runAgent()
  └── 汇总结果或走异步任务通知

三种并发模式

Claude Code 同时支持三种 Multi-Agent 运行模型 ：

1. 普通 Subagent：同步或异步执行，完成后返回结果
2. Coordinator → Workers：协调器模式，主 Agent 协调多个并行 Worker
3. Swarm Teammates：团队协作模式，支持 Agent 间通过 SendMessageTool 通信

工程本质：Multi-Agent 即为多个 while true 并发运行——一个循环学会了生出新的循环。

---

五、单 Agent 与 Multi-Agent 对比

维度	单 Agent	Multi-Agent
循环结构	单一 while true	多个 while true
执行方式	串行执行	可并行执行
上下文管理	上下文共享	上下文隔离
职责划分	职责集中	职责分离
延迟特性	随任务数线性增长	接近常数时间（取决于最慢 Worker）
成本模型	单一模型成本	可分层使用强弱模型（Orchestrator 用强模型，Workers 用轻量模型）
调试复杂度	单一调用链	需追踪多 Agent 调用链

六、适用场景与边界

适用于 Multi-Agent 的场景

• 任务规模超出单一上下文窗口：大规模代码库重构、跨文件分析
• 子任务之间可并行处理：多文件修改、多数据源检索、多维度代码审查
• 需要明确角色分工：搜索 Agent、编码 Agent、审查 Agent、测试 Agent 各司其职

不适用 Multi-Agent 的场景

非万能替代：对于需要"边走边看、及时纠偏"的交互式 Agent，仍应保留单循环的灵活性，不宜盲目引入多 Agent 分层。

• 高度交互式任务：需要频繁用户确认、实时反馈调整的场景
• 强依赖顺序的流水线：后一步强依赖前一步输出的串行任务
• 简单任务：增加复杂度反而降低效率的低复杂度任务

---

七、工程实践建议

1. 模型分层策略

采用"强 Orchestrator + 轻量 Workers"的成本优化策略 ：

• Orchestrator：使用 Claude Sonnet / GPT-4 等强模型，负责决策与汇总
• Workers：使用 Claude Haiku / GPT-3.5 等轻量模型，负责执行具体子任务

此策略可在保持质量的同时，将成本降低 60-80%。

2. 上下文隔离实现

参考 Claude Code 的隔离层级 ：

• Worktree 隔离：使用 Git worktree 创建独立工作目录（零外部依赖）
• Context 隔离：仅隔离对话历史，共享文件系统
• Container 隔离：使用容器提供最强隔离（需基础设施支持）

3. 错误处理与超时

• 每个 Worker 应设置独立超时
• Orchestrator 需处理 Worker 失败的重试或降级策略
• 实现请求 ID 传播，便于跨 Agent 追踪

---

核心理念

让合适的 Agent 只做合适的事，而非将单个 Agent 打造为全能体。

Multi-Agent 不是简单的"多开几个 ChatGPT"，而是架构层面的职责分离与并发优化。其本质是将一个复杂的认知任务，拆解为多个可并行、可隔离、可复用的独立认知单元，通过精心设计的协作协议实现整体效能最大化。

在工程落地时，应始终遵循"简单优先"原则：从单 Agent 开始，当确实遇到上下文、效率或职责边界的瓶颈时，再引入 Multi-Agent 架构。正如 Anthropic 所建议的——找到最简单的可行方案，仅在必要时增加复杂度 。

---

本文基于 AutoGen (Microsoft, 2023)、Anthropic《Building Effective Agents》及 Claude Code 开源实现分析整理。