Claude 多 Agent 系统的技术实现原理
Anthropic 的多 Agent 方案核心是 编排器-工作器（Orchestrator-Worker）架构：一个主导 Claude Agent 动态生成专用子 Agent，每个子 Agent 在独立的上下文窗口中运行。这一模式已在 Claude Research 功能中投入生产，在内部基准测试中比单个 Claude Opus 4 Agent 高出 90.2%。技术栈由 Claude Agent SDK（Python/TypeScript）、Task 工具（子进程生成）、MCP（工具集成）以及实验性 Agent Teams（跨会话协调）组成。Anthropic 的核心理念是：组合式的简洁优于框架的复杂——从最简单的系统开始，仅在有可衡量改进时才引入多 Agent。
一、编排器-工作器模式：一切的基础
Anthropic 在 2025 年 6 月发布的工程博客中详细介绍了其生产级多 Agent 架构，遵循清晰的层级结构：主导 Agent（通常为 Claude Opus 4 或 4.6）分析用户查询、制定研究策略、将计划保存到持久化内存，然后生成专用 子 Agent（通常为 Claude Sonnet 4）。每个子 Agent 在自己的上下文窗口中运行，拥有定制的系统提示词、专用工具访问权限和独立权限。子 Agent 完成工作后，主导 Agent 综合结果，并可选择性地生成更多轮次的子 Agent。最终由专门的 CitationAgent 处理来源引用。
2024 年 12 月发布的基础性文章《Building Effective Agents》概述了五种复杂度递增的可组合工作流模式：提示链（顺序步骤）、路由（基于意图的分发）、并行化（同时多路 LLM 调用）、编排器-工作器（动态委派）和评估-优化器（生成后评审循环）。Anthropic 明确建议 不要过早跳到多 Agent 系统——大多数问题通过单次 LLM 调用配合检索和工具使用即可解决。他们的指导原则是：“只在能够明确改善结果时才增加复杂度。”
性能数据验证了多 Agent 在复杂任务上的价值。仅 Token 使用量就能解释 BrowseComp 基准测试中 80% 的性能方差。多 Agent 系统的 Token 消耗大约是 标准对话的 15 倍。并行工具调用——子 Agent 同时执行 3 个以上工具调用——使复杂查询的研究时间减少了 90%。架构在提示词中嵌入了精力分配规则：简单的事实查找触发 1 个 Agent 进行 3-10 次工具调用，而复杂研究会生成 10 个以上子 Agent，各有明确的职责划分。
二、Task 工具：子 Agent 的生成与管理机制
Task 工具 是 Claude Code 和 Claude Agent SDK 中多 Agent 委派的核心原语。当 Claude 调用它时，系统会启动一个全新的 CLI 子进程——一个完全独立的 Agent 实例，拥有自己的 200K Token 上下文窗口。每个子进程继承全局配置但独立运行，仅向父 Agent 返回摘要。这种子进程架构保持主 Agent 的上下文干净，同时支持子 Agent 进行深度、专注的工作。
Claude Code 内置三个子 Agent：Explore（运行在 Haiku 上）是一个快速只读 Agent，用于代码库搜索，支持配置搜索深度级别；Plan（Sonnet）在规划阶段收集上下文；通用 Agent（Sonnet）处理需要同时探索和修改的复杂多步任务。一个关键的架构约束是：子 Agent 不能再生成子 Agent。这是刻意的限制，用于防止无限嵌套、Token 成本失控和错误累积。
自定义子 Agent 定义为带有 YAML frontmatter 的 Markdown 文件，存储在 .claude/agents/（项目级）或 ~/.claude/agents/（用户级）。每个文件指定名称、描述、可用工具、模型选择和系统提示词。Claude 根据子 Agent 的 description 字段自动匹配任务——用户也可以显式请求委派。SDK 还支持通过 AgentDefinition 数据类进行编程定义：
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition
async for message in query(
prompt="审查 auth 模块的安全问题",
options=ClaudeAgentOptions(
allowed_tools=["Read", "Grep", "Glob", "Task"],
agents={
"security-reviewer": AgentDefinition(
description="专注漏洞检测的安全专家",
prompt="你是安全专家，专注于注入、XSS...",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
},
),
):
print(message)
Task 工具必须显式包含在 allowed_tools 中才能启用子 Agent 调用。每个 Agent 定义可以指定 model 为 "sonnet"、"opus"、"haiku" 或 "inherit"，在同一工作流中实现成本优化的模型路由。
三、Agent Teams：跨会话协调
除了单会话子 Agent 之外，Claude Code 还提供实验性的 Agent Teams 功能（通过 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 启用），可协调多个完整的 Claude Code 会话并行工作。与子 Agent 仅向父级报告不同，Agent Team 成员通过 共享任务列表和基于邮箱的消息系统 直接相互通信。
该架构引入了若干协调工具：TeamCreate 初始化一个具有共享磁盘文件的团队，TaskCreate/TaskList/TaskUpdate 管理共享任务板，SendMessage 实现 Agent 间的邮箱通信。团队负责人编排工作、分配任务并综合结果，而队友——独立的 Claude 实例——从共享任务板上自行认领任务。生成后端包括进程内（默认）、tmux 面板或 iTerm2 分屏面板。
Anthropic 自己的工程团队展示了该模式的规模——16 个并行 Agent 在约 2,000 个会话中 构建了一个能够编译 Linux 6.9 内核的 C 编译器。Agent Teams 的 Token 消耗约为 标准会话的 7 倍，因此 Anthropic 建议队友使用 Sonnet，而将 Opus 留给团队负责人。
四、MCP：连接 Agent 与工具，而非 Agent 之间
模型上下文协议（MCP）——Anthropic 于 2024 年 11 月推出、2025 年 12 月捐赠给 Linux 基金会 Agentic AI Foundation 的开放标准——本质上是 Agent 到工具的协议，而非 Agent 到 Agent 的协议。MCP 标准化了单个 AI Agent 如何使用 JSON-RPC 2.0 消息（通过 stdio、HTTP 或 Server-Sent Events 传输）连接到外部工具、数据源和系统。截至 2025 年底，MCP 已有 9700 万+月度 SDK 下载量 和 5800+ 个服务器 的生态。
MCP 架构定义三个角色：宿主（Hosts）（如 Claude Desktop 或 Claude Code 等 LLM 应用）、客户端（Clients）（维护与服务器一对一连接的协议连接器）和 服务器（Servers）（暴露工具、资源和提示的轻量级程序）。对于多 Agent 模式，MCP 最重要的原语是 Sampling——一种允许 MCP 服务器向客户端请求 LLM 补全的机制，创建双向智能流。宿主应用本身充当编排 Agent，协调连接到不同专业服务器的多个 MCP 客户端。
Google 的 Agent-to-Agent（A2A）协议被明确设计为 MCP 的补充：MCP 用于工具访问，A2A 用于 Agent 间通信。但 2025 年 11 月的 MCP 规范更新增加了扩展其 Agent 能力的特性：带部分结果的流式传输、可恢复连接、异步长时间运行操作 以及通过 Sampling 和 Elicitation 实现的 多轮交互。Anthropic 的一篇工程博客文章展示了将 MCP 服务器呈现为代码 API 而非直接工具调用可实现 98.7% 的 Token 节省——从 150,000 Token 降至 2,000——让 Agent 在将结果传递给模型之前以编程方式过滤数据。
五、Agent 间的内存、上下文与状态流转
Claude 多 Agent 系统中的上下文共享依赖四种机制，而非单一的共享内存空间：
（1）持久化 Memory： 主导 Agent 将其研究计划和关键发现保存到 Memory 存储中，即使在 200K Token 限制临近上下文窗口截断时也能确保连续性。
（2）Artifact 系统： 子 Agent 将输出写入外部系统（文件、数据库），并向协调器传回轻量级引用，在最小化 Token 开销的同时防止信息丢失。
（3）压缩（Compaction）： Claude Agent SDK 在上下文限制临近时自动总结先前消息，有效实现无限对话。Compaction API（beta，可在 Opus 4.6 上使用）提供服务器端上下文摘要。
（4）子 Agent Memory 字段： 每个 Agent 拥有一个跨对话持久化的目录——子 Agent 随时间积累关于代码库模式、调试洞察和架构决策的知识。对于长时间运行的 Agent，Anthropic 建议维护结构化的 claude-progress.txt 日志，并使用增量加载的初始化脚本。
Agent Teams 通过不同方式实现状态共享——通过 共享磁盘文件、任务板和邮箱消息，而非共享上下文窗口。每个 Agent 维护自己的上下文，协调通过显式通信通道而非隐式状态共享完成。
六、SDK 生态与第三方集成
Claude Agent SDK（2025 年 9 月从 Claude Code SDK 更名）是 Anthropic 构建多 Agent 系统的主要框架。提供 Python（pip install claude-agent-sdk）和 TypeScript（npm install @anthropic-ai/claude-agent-sdk）版本，提供与 Claude Code 相同的 Agent 循环、工具和上下文管理。SDK 支持子 Agent 定义、MCP 服务器集成、作为进程内 MCP 服务器实现的自定义工具、生命周期管理钩子（PreToolUse、PostToolUse、SubagentStop）以及结构化输出验证。
对于需要更低层控制的开发者，标准 Anthropic Python SDK（pip install anthropic）暴露了带 tool_use 的 Messages API——可构建自定义 Agent 循环，其中对"子 Agent"的委派实际上是另一个带有专用系统提示词的 messages.create 调用，由编排器调用自定义委派工具触发。GitHub 上的 Anthropic Cookbook 提供了参考实现，包括一个子 Agent 笔记本，展示了使用 Haiku 子 Agent 和 Opus 编排器进行并发 PDF 分析。
第三方框架提供了替代编排层：AWS Agent Squad（前 Multi-Agent Orchestrator）提供具有智能意图分类的 AnthropicAgent 类；CrewAI 通过 LiteLLM 提供基于角色的多 Agent 设计并集成 Claude；LangGraph 提供基于图的状态机编排并带自动检查点；Microsoft 的 Agent Framework 和 Google 的 ADK 都包含原生 Claude Agent 类。社区构建的 claude-flow 实现了具有多种拓扑和共识协议的群体编排。
七、Anthropic 的战略路径：走向自主 Agent
Anthropic 的多 Agent 路线图遵循清晰的演进路径：Claude Code（开发者工具）→ Claude Agent SDK（可编程 Agent 平台）→ Cowork（面向知识工作者的桌面 Agent，2026 年 1 月发布）→ Enterprise Agents（2026 年 2 月发布，集成 Google Drive、Gmail、DocuSign 连接器）。每一步都在扩大受众的同时建立在相同的编排器-工作器基础之上。
最近一项覆盖数百万次交互的 AI Agent 自主性研究发现，2025 年 10 月至 2026 年 1 月间 自主会话时长几乎翻倍，有经验的用户自动批准 Agent 操作的比率超过 40%（新用户为 20%）。2025 年 8 月到 12 月间，困难任务的内部成功率翻倍，而每次会话的人工干预次数从 5.4 降至 3.3。Anthropic 识别出一个"部署悬崖（deployment overhang）"——模型能力远超用户当前实际使用的自主程度。
总结
Anthropic 的多 Agent 实现体现了务实的工程哲学，而非框架驱动的方法。编排器-工作器模式、基于子进程的隔离、刻意禁止嵌套子 Agent 生成，以及强调从简单开始——这些都源于生产部署的经验教训。他们工作中最关键的技术洞察是：Token 预算是多 Agent 性能的主导因素——不是模型选择，不是架构精巧度。MCP 作为工具集成胶水（而非 Agent 通信协议）的角色将其定位为基础设施，而非多 Agent 解决方案本身，Agent SDK 和 Agent Teams 才是实际的协调层。Claude Agent SDK、Linux 基金会治理下的 MCP 以及 Cowork 桌面 Agent 的融合表明，Anthropic 正在构建一个多 Agent 编排对终端用户透明的未来——抽象在产品背后，而非作为框架暴露出来。