多智能体系统

多智能体（multi-agent）是 2025 年 Agent 工程领域争议最大的话题，没有之一。Anthropic 用一套 orchestrator-worker 多代理系统支撑了 Claude 的 Research 功能，并宣称比单代理强 90.2%；几乎同一时间，Cognition（Devin 的公司）发表《Don't Build Multi-Agents》，断言大多数多代理架构是脆弱的反模式。两篇文章都对——因为它们谈论的是不同形状的任务。

这一页的目标是把这场争论讲清楚，然后给你一套可执行的编排模式清单和一个决策框架：什么时候该拆，拆成什么样，以及拆之前先问自己什么。

一、为什么需要多个 agent

把任务从单个 agent 拆给多个 agent，工程上只有三个站得住的理由：

1. 上下文隔离（最硬核的理由）

一个 agent 的 context window 是它唯一的"工作台"。搜索 20 篇网页、读几十个文件之后，工作台会被原始噪声塞满，真正重要的指令反而被挤出注意力中心。子代理各自拥有独立的 context window，在噪声里翻找完之后，只把压缩后的结论交回主代理——主代理的上下文始终保持干净。

Anthropic 把这一点说得很直白："搜索的本质是压缩"——subagent 充当智能过滤器，在海量语料中探索后只把最重要的 token 蒸馏给 lead agent。这也是 Claude Code 的 subagent 设计哲学：子任务代理只负责"回答一个定义清晰的问题"，它的调查过程不留在主代理的历史里，主代理因此能跑更长的 trace（详见 Claude Code 解剖 与 上下文工程）。

2. 专业化分工

不同子任务需要不同的 system prompt、不同的工具集、甚至不同的模型。让"网页浏览 agent"和"代码执行 agent"共享一套 prompt 和工具，结果是两边都不够用。分工让每一部分的上下文都能被精确裁剪——这和人类组织分工的逻辑一样，区别只在于 agent 的"专业化"是 prompt + 工具 + 模型的组合。

3. 并行

广度优先的任务（"找出 S&P 500 信息技术板块所有公司的董事会成员"）天然可以拆成几十个互不依赖的子查询。单代理串行搜索慢到不可用，多代理并行可以在几分钟内完成。Anthropic 的数据：lead agent 并行启动 3-5 个 subagent、每个 subagent 并行调用 3+ 个工具，这两项改动把复杂查询的研究时间最多缩短了 90%。

为什么多数时候不该用：两派观点

这是本页最重要的部分，两篇文章都值得读原文。

支持方：Anthropic《How we built our multi-agent research system》（2025 年 6 月）

• 内部评测：以 Claude Opus 4 为 lead、Sonnet 4 为 subagent 的多代理系统，在内部研究评测上比单代理 Opus 4 高出 90.2%。
• 关键洞察：多代理系统的本质是"花更多的 token 来解决问题"。在 BrowseComp 评测上，三个因素解释了 95% 的性能方差，其中 token 用量单独解释 80%。多代理架构通过多个独立 context window，把 token 消耗能力扩展到单代理的天花板之上。
• 适用边界（Anthropic 自己划的）：重并行、信息量超过单个 context window、需要对接大量复杂工具的高价值任务。反例他们也给了：大多数编码任务可并行性远低于研究任务，而且 agent 之间实时协调委派的能力还不行。

反对方：Cognition《Don't Build Multi-Agents》（Walden Yan，2025 年 6 月 12 日）

Cognition 的论点建立在两条"上下文工程原则"上：

1. 共享上下文，且要共享完整的 agent trace，而不只是单条消息。
2. 行动隐含决策，冲突的隐含决策导致坏结果。

他用"克隆 Flappy Bird"举例：任务被拆成"做背景"和"做小鸟"两个子任务，两个 subagent 各自做出了误解需求的组件——背景做成了马里奥风格，小鸟根本不像游戏素材——最后合并 agent 面对两个互相矛盾的半成品束手无策。即便把原始任务完整复制给每个子代理，两个子代理仍然看不见彼此的动作，产出物风格冲突。问题的根源是：每个 agent 的行动都携带了隐含决策，而并行拆分让这些决策无法对齐。

Cognition 的替代方案：默认使用单线程线性 agent；上下文要溢出时，用一个专门的压缩模型把行动历史压缩成关键决策与事件（他们在 Cognition 内部甚至为此微调了小模型），而不是拆分上下文。

怎么调和两派？

注意两家的任务形状不同。Anthropic 的场景是广度优先的信息检索：子任务之间几乎无依赖，产出是文本结论，合并成本低、"读"比"写"容易对齐。Cognition 的场景是软件工程：子任务共享同一个代码库，任何两个 agent 写代码都会互相踩踏。经验法则：子任务只读、产出可分离 → 多代理可行；子任务会写同一份状态、决策互相耦合 → 多代理是灾难。两派在各自边界内都是对的。

一个诚实的现状判断

截至 2026 年，多代理系统在"研究/检索类"产品上已被生产验证（Anthropic Research、各类 Deep Research 产品），在编码领域则普遍退回到"单主 agent + 只读子任务"的保守形态。Claude Code 的 subagent 从不与主代理并行写代码，这不是能力不够，是刻意的可靠性设计。把多代理当默认架构，在 2026 年仍然是过度设计。

二、编排模式全览

下面五种模式覆盖了工业界 95% 的多代理系统。选型时先想清楚信息流和决策权在哪，再画箭头。

1. Supervisor / Orchestrator（主管模式）

              ┌──────────────────┐
   用户请求 → │  Supervisor      │ → 最终答案
              │ (规划/分派/汇总)  │
              └───┬───┬───┬──────┘
                  │   │   │  分派子任务（带明确边界）
          ┌───────┘   │   └────────┐
          ▼           ▼            ▼
     ┌─────────┐ ┌─────────┐ ┌─────────┐
     │ Worker A│ │ Worker B│ │ Worker C│   ← 各自独立 context
     │ (搜索)  │ │ (代码)  │ │ (分析)  │
     └────┬────┘ └────┬────┘ └────┬────┘
          └───────────┴───────────┘
                  只回传压缩后的结论

• 决策权集中在 supervisor，worker 是被动的执行单元。
• Anthropic Research、Magentic-One、大多数 Deep Research 产品都是这个模式。
• 适合：任务可以预先（或迭代地）分解、子任务弱耦合、需要一个统一的出口汇总。
• 陷阱：supervisor 成为单点瓶颈与单点故障；委派描述不清会导致 worker 重复劳动或留下覆盖空洞（Anthropic 早期版本就踩过这个坑）。

2. Handoff（移交模式）

  ┌───────┐  判断超出职责   ┌───────┐   ┌───────┐
  │客服agent│ ───────────→ │退款agent│ → │技术agent│
  └───────┘  连同对话上下文  └───────┘   └───────┘
     ↑ 任一时刻只有一个 agent 持有"对话控制权"

• 同一时间只有一个 agent 活跃，通过 handoff 工具把控制权（和上下文）整个移交给下一个 agent。OpenAI 的 Swarm 实验项目和 Agents SDK 把这个模式产品化了（见 OpenAI Agents SDK）。
• 适合：客服路由、分阶段流程（售前→下单→售后），本质是"带 LLM 路由的状态机"。
• 与 supervisor 的区别：handoff 后原 agent 退出，没有人在上面汇总；supervisor 始终在线。

3. Pipeline / 流水线

  输入 → [检索agent] → [分析agent] → [写作agent] → [校对agent] → 输出
            每个环节的输出是下一个环节的输入，方向固定

• 严格说这不一定是"多 agent"——如果每一步是确定性调用，它就是工作流而非代理系统。Anthropic 在《Building Effective Agents》里把这类归为 prompt chaining / workflow，与 agent 明确区分。
• 适合：步骤可预知、每步质量标准明确的任务（报告生成、翻译审校、数据处理）。
• 这是最便宜、最可靠的模式。能用流水线解决就不要上 agent，更不要上多 agent。

4. 群聊 / 辩论（Group Chat / Debate）

        ┌─────────────────────┐
        │   共享消息黑板        │
        └─────────────────────┘
          ↑     ↑      ↑     ↑
      ┌───┴┐ ┌──┴─┐ ┌──┴─┐ ┌─┴───┐
      │提议者│ │批评者│ │检索者│ │主持人│
      └────┘ └────┘ └────┘ └─────┘
        多轮发言直至收敛或达到轮次上限

• AutoGen 的 GroupChat、学术界的 multi-agent debate 属于此类。所有 agent 读写同一块消息板，由主持人（或轮询策略）决定谁发言。
• 适合：开放式头脑风暴、需要对抗性审查的场景（红队测试、方案评审）。
• 警告：这是 Cognition 点名批评的模式。没有明确的收敛机制时，辩论经常空转、互相恭维或跑题，token 消耗不可控。生产系统里很少见到它成功落地。

5. 分层团队（Hierarchical Teams）

                 ┌───────────┐
                 │ 顶层主管   │
                 └─────┬─────┘
              ┌────────┴────────┐
              ▼                 ▼
        ┌───────────┐     ┌───────────┐
        │ 研究组组长 │     │ 工程组组长 │
        └──┬──┬──┬──┘     └──┬──┬──┬──┘
           ▼  ▼  ▼           ▼  ▼  ▼
         [搜索][读取][分析] [前端][后端][测试]

• supervisor 模式的递归：当单个 supervisor 管理的 worker 太多、任务本身有天然的领域分层时，引入中层管理者。
• 适合：大型代码库改造、多领域研究项目。LangGraph 官方文档有专门的 hierarchical teams 教程。
• 代价：每加一层，信息在传递中多失真一次，调试难度和 token 成本同步上升。

模式之间可以组合：Anthropic Research 就是"supervisor 模式 + worker 内部各自跑流水线"，Magentic-One 是"supervisor + 固定专家班组"。

三、上下文工程视角：子代理真正的价值

抛开所有组织架构的比喻，子代理在技术上只做一件事：用一个独立的 context window 执行一段可丢弃的探索，再把压缩结论写回主上下文。

这带来三个直接推论：

1. 子代理的产出必须是"压缩"的。 如果子代理把 5 万 token 的原始搜索结果原样倒回主代理，隔离就失败了。Anthropic 把 subagent 定义为"intelligent filter"，过滤能力就是子代理的核心能力。
2. 委派消息必须是"自足"的。 子代理看不到主代理的对话历史，所以任务描述必须包含目标、输出格式、可用工具、边界。Anthropic 的教训：只写"研究半导体短缺"这种一句话 brief，多个子代理会做完全相同的搜索，或者各自跑偏——他们曾观察到三个子代理里两个在重复调查 2025 年供应链，另一个跑去研究 2021 年汽车芯片危机。
3. 隔离是有代价的，代价就是 Cognition 批评的那一面。 子代理看不见彼此，所以任何需要"对齐隐含决策"的任务都不该拆。上下文隔离和上下文共享是一对根本矛盾，你的任务形状决定了该选哪边。

主代理自己也有上下文上限。Anthropic 的做法是：lead agent 把计划写入外部 Memory 持久化，因为上下文超过 20 万 token 会被截断，计划必须先保住。这套"计划外置 + 上下文压缩"的组合拳，详见 上下文工程 和 Memory 设计。

一个可操作的判断标准

给任务画一条"信息流"：如果子任务的输入可以写成一个自包含的 brief、输出可以压缩成几百 token 的结论，它就是好的子代理候选。如果你发现自己在 brief 里抄了大段对话历史、或者子代理的产出需要主代理逐行审查才能用——这个拆分是错的，退回单 agent。

四、通信与协议

共享状态 vs 消息传递

多代理系统的内部通信有两种基本风格：

• 共享状态（shared state）：所有 agent 读写同一份图状态或消息历史。LangGraph 的 StateGraph、AutoGen 的 GroupChat 都是这个思路。优点是没有信息丢失（满足 Cognition 原则一）；缺点是状态随 agent 数量膨胀，且 agent 之间的耦合度高。
• 消息传递（message passing）：agent 之间只交换定义良好的消息/任务对象，内部状态互不可见。这是微服务式的思路，也是 A2A 协议的思路。优点是解耦、可跨组织；缺点正是 Cognition 警告的"上下文传递不充分"。

经验法则：单进程、单团队、单代码库内的多 agent 用共享状态；跨进程、跨团队、跨组织的 agent 协作用消息传递（协议化）。

A2A 协议：跨组织的 agent 互操作

A2A（Agent2Agent）是 Google 于 2025 年 4 月 9 日发布的开放协议，发布时即获得 50 多家技术伙伴支持；2025 年 6 月 23 日 Google 将其捐赠给 Linux 基金会，成立 Agent2Agent 项目。到 2026 年 4 月（发布一周年），协议进展包括：

• v1.0 稳定版规范发布：引入多协议支持、企业级多租户、现代化安全流程，以及面向早期采用者的迁移路径。
• 支持组织从 50+ 增长到 150+，包括 AWS、Cisco、Google、IBM、Microsoft、Salesforce、SAP、ServiceNow。
• 云平台内置：微软把 A2A 集成进 Azure AI Foundry 和 Copilot Studio；AWS 通过 Amazon Bedrock AgentCore Runtime 支持。
• SDK 从单一 Python 扩展到五种语言（Python、JavaScript、Java、Go、.NET），核心仓库 GitHub star 超 22,000。
• Signed Agent Cards：用密码学签名验证 agent 身份，解决"我怎知道对面这个 agent 是它声称的那个"。
• 生态外沿扩展到支付：Agent Payments Protocol（AP2）已获 60 多家支付与金融机构支持。

A2A 的核心抽象不复杂：

  Client Agent                              A2A Server (Remote Agent)
      │                                            │
      │  1. GET /.well-known/agent-card            │   ← 发现：能力、技能、认证方式
      │ ←──────────────── Agent Card ──────────────│
      │                                            │
      │  2. 按 Agent Card 声明的方案完成认证        │
      │                                            │
      │  3. POST sendMessage / sendMessageStream   │   ← 任务：Task 生命周期
      │ ──────────────── Task (submitted) ────────→│
      │ ←── TaskStatusUpdateEvent (working) ───────│   （SSE 流式推送状态）
      │ ←── TaskArtifactUpdateEvent (artifact) ────│   ← 产出物回流
      │ ←── TaskStatusUpdateEvent (completed) ─────│

关键设计取舍，和 MCP 对比着看最清楚：

维度	MCP	A2A
解决什么	agent 如何接工具/数据	agent 如何与别的 agent 协作
对端是什么	无状态、功能确定的工具	有自主性、可多轮协商的 agent
交互粒度	单次函数调用	长任务（LRO）、流式、多轮对话
内部可见性	工具实现透明给调用方	不透明执行（opaque execution）：不暴露内部逻辑、记忆、工具
托管方	Linux 基金会	Linux 基金会（2025 年 6 月起）

两者是互补的栈：一个 agent 对内用 MCP 接自己的工具，对外用 A2A 和别人的 agent 谈判。A2A 官方文档特别强调"agent 不是工具"——把 agent 包装成一个无状态 tool 调用会丢掉协商、澄清、委派这些多轮能力。更多 MCP 细节见 工具与 MCP。

协议不是银弹

A2A 标准化的是"信封"——发现、认证、任务状态机——而不是"信的内容"。两个 agent 能否真的协作成功，仍取决于任务描述写得有多清楚、产出格式有没有约定好。协议解决集成成本，不解决 Cognition 说的上下文对齐问题。跨组织协作时，这意味着你需要在任务 schema 上投入比在 prompt 上更多的设计功夫。

五、真实系统案例

Anthropic Research：orchestrator-worker 的生产范本

前文已多处引用，这里集中看工程细节：

• 架构：LeadResearcher 分析查询、制定策略、把计划写入 Memory 防截断，然后并行创建多个 subagent 分头搜索；结果汇总后视情况追加新一轮 subagent；最终由独立的 CitationAgent 处理引用归属。
• 投入产出缩放规则写进 prompt：简单事实查询 1 个 agent + 3-10 次工具调用；直接对比 2-4 个 subagent、每个 10-15 次调用；复杂研究 10 个以上分工明确的 subagent。早期版本最常见的失败就是为简单问题 spawn 50 个子代理。
• 工具描述的可维护性：他们造了一个"工具测试 agent"，反复调用有缺陷的 MCP 工具并重写其描述，使后续 agent 的任务完成时间下降 40%。
• 生产运维：错误会沿长 trace 复利式放大，所以他们做了断点恢复（不从头重启）、rainbow deployment（新旧版本并行跑，逐步切流量，避免打断正在运行的 agent）、以及不读取对话内容的高层决策模式 tracing（隐私与可观测性的折中）。更多可观测性实践见 可观测性与 Tracing。
• 遗留瓶颈：subagent 目前是同步执行——lead 必须等整批 subagent 跑完才能继续，期间无法纠偏。异步化在他们的路线图上，但会引入结果协调、状态一致性和错误传播的新问题。

Manus：规划-执行-验证的多代理 + 虚拟机

Manus（2025 年 3 月由 Monica 团队发布，2025 年底官宣加入 Meta 并保持独立运营）是通用 agent 赛道最具话题性的产品。公开资料（包括 Manus 团队自己的上下文工程博客和第三方逆向分析）显示的架构轮廓：

• 任务在独立的云端虚拟机/沙箱中运行（据报道使用 E2B 作为沙箱基础设施），子代理在这个完整计算环境里操作浏览器、终端、文件系统。
• 采用规划（Planner）、执行（Executor）、验证（Verifier）三类角色的分工，Planner 把任务拆解成 todo.md 式的步骤清单，Executor 逐步执行，Verifier 检查结果。
• Manus 团队公开分享的工程经验集中在上下文管理上：围绕 KV cache 设计上下文结构、用"遮蔽而非删除"管理工具可见性、把文件系统当作外部记忆。

需要注意：Manus 从未公开完整架构论文，上述细节来自官方博客片段与社区逆向，颗粒度有限。详见 Manus 案例。

Magentic-One：微软的通用多代理基线

Magentic-One 是微软研究院 2024 年 11 月发布的通用多代理系统（arXiv:2411.04468），构建在 AutoGen 之上，2025 年 1 月随 AutoGen 0.4 正式集成发布：

• 固定专家班组：一个 Orchestrator 协调四个专职 agent——WebSurfer（浏览器操作）、FileSurfer（本地文件）、Coder（写代码）、ComputerTerminal（执行代码）。
• 双账本机制：Orchestrator 维护 Task Ledger（任务分解与计划）和 Progress Ledger（进度追踪与错误恢复），用外环（更新任务账本）+ 内环（跟踪进度）的双层循环驱动。
• 定位是 GAIA 等基准上的通用基线，后续衍生了带人类协作界面的 Magentic-UI（2025 年 5 月开源）。

Magentic-One 的价值不在性能数字，而在它展示了一种"通用化"的分工思路：不按行业分工（财报分析师、法律顾问），而按能力模态分工（上网、读文件、写码、跑码）——这让班组可以不经修改地迁移到不同任务域。

六、成本与可靠性的量化代价

多代理不是免费的性能，价格写在账本上：

• Token 成本：Anthropic 生产数据——agent 交互约消耗聊天 4 倍的 token，多代理系统约 15 倍。这意味着多代理只在"任务价值足以覆盖 15 倍成本"时经济上成立。更系统的成本模型见 成本与延迟优化。
• 可靠性：错误在多代理系统中是相乘不是相加。Anthropic 的原话是"在传统软件里是小事的问题，对 agent 可能是灾难性的"；一步失败会把整个 agent 群带上完全不同的轨迹。
• 调试成本：非确定性 + 多执行体 = 无法靠重放定位问题。没有完整的 trace 基础设施（见 可观测性与 Tracing），多代理系统基本不可维护。
• 评估难度：同样的输入可以走完全不同的合法路径，无法断言"正确步骤"，只能评结果。Anthropic 用单一 LLM judge + 0.0-1.0 打分 + 通过/失败判级的方式做规模化评估，并强调从约 20 条真实查询的小样本起步。方法详见 评估体系。

   单 agent            多 agent
   ─────────────────────────────────────────
   成本:  4× 聊天       15× 聊天          (~4x)
   故障:  单点           N 个点 + 协调失败  (新类别)
   调试:  重放单 trace   需跨 agent trace  关联
   评估:  路径+结果      只能评结果
   上限:  context 顶死   随并行度扩展      ← 你买的就是这个

七、决策框架：什么时候从单 agent 升级

按顺序问自己五个问题，任何一个答"是"都停在原地：

1. 流水线能不能解决？ 步骤可预知 → 用 prompt chaining，连 agent 都不需要。
2. 单 agent + 更好的上下文管理能不能解决？ 先试试压缩历史、外部记忆、更好的工具描述（还记得那 40% 吗）。Cognition 的默认答案——单线程线性 agent——比多数人以为的能走得更远。
3. 任务真的可并行吗？ 子任务之间有没有共享的可写状态？有（同一个代码库、同一份文档）→ 拆分的收益会被合并冲突吃掉。
4. 任务价值撑得起 15 倍 token 吗？ 低价值高频任务上多代理是烧钱行为。
5. 子任务能写成自包含的 brief 吗？ 写不出来 → 说明拆分的边界画错了。

五个问题全部通过，再上多代理，并且从最小的形态开始：一个 supervisor + 少数几个只读 worker，跑通了再考虑更复杂的拓扑。实现层面，LangGraph 的 supervisor/hierarchical 支持和 AutoGen 是两种主流起手式；想自己从零写一个 supervisor 骨架，可以从 动手造一个 Agent 出发加上分派逻辑。安全维度另见 安全与对齐——多代理把提示注入的攻击面从"一个 agent"扩大到"agent 之间的每一条消息"。

# 最小可用的 orchestrator-worker 骨架（纯标准库，框架无关）
import asyncio

async def worker(brief: str) -> str:
    """子代理：独立上下文，执行自包含的 brief，只返回压缩结论。

    真实实现中这里是一个完整的 agent loop（见 /components/agent-loop），
    拥有自己的 system prompt、工具集和 context window。
    """
    return await run_agent_loop(
        system="你是研究员。只返回不超过300字的结论，附来源。",
        task=brief,  # brief 必须自足：目标、边界、输出格式
    )

async def supervisor(query: str) -> str:
    # 1. 规划：把查询拆成互不重叠的 brief（重点是"互不重叠"）
    briefs = await plan(query)  # 例如 ["查A公司2025年财报要点", "查B公司同期财报要点", ...]

    # 2. 并行分派：worker 之间不通信，只读、产出可分离
    findings = await asyncio.gather(*[worker(b) for b in briefs])

    # 3. 汇总：主代理只接触压缩后的结论，上下文保持干净
    return await synthesize(query, findings)

多代理系统不是一个更聪明的 agent，而是一个组织。组织的产出上限更高，但管理成本是真实的——这篇文章存在的意义，就是让你在付这笔管理成本之前，先确认自己确实需要那家"公司"。

参考资料

• How we built our multi-agent research system — Anthropic Engineering —— orchestrator-worker 的生产一手经验，90.2% 提升与 15 倍 token 数据的出处。
• Don't Build Multi-Agents — Cognition —— 反对派纲领，上下文工程两条原则的原始出处。
• A2A Protocol 官方文档：What is A2A? —— Agent Card、Task 生命周期与 A2A/MCP 分工的官方定义。
• A2A Protocol Surpasses 150 Organizations — Linux Foundation 新闻稿（2026-04） —— v1.0 稳定版、云平台集成与生态数据。
• Google Cloud donates A2A to Linux Foundation — Google Developers Blog —— 2025 年 6 月捐赠始末。
• Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks (arXiv:2411.04468) —— 微软通用多代理系统论文。
• 拆解 Manus：沙盒架构深度解析 — 鸟窝 —— Manus 规划-执行架构与 E2B 沙箱的第三方技术分析。