Multi-Agent 在 2026 年成了一个被过度使用的词。有人把三个 LLM 调用串起来就叫 Multi-Agent，有人把 prompt chaining 换了个名字就叫 Multi-Agent。在这层噪音下面，真正的问题是：什么条件下必须让多个独立智能体协作？它们之间怎么组织？组织错了会付出什么代价？

本文的目标不是介绍各种框架，而是回答一个更前置的工程判断：你的任务到底需不需要 Multi-Agent，如果需要，选哪种组织模式损耗最小。

先搞清楚概念：不是所有多次 LLM 调用都叫 Multi-Agent

四层能力光谱

1
2
3
4
L1  Single Agent          一个模型 + 工具循环
L2  Agent + Skills        同一模型通过 MCP/RAG/Memory 扩展
L3  Multi-Agent Workflow   多个独立模型，编排逻辑写在代码里
L4  Agent Teams           多个独立模型，编排逻辑由模型自己决定

核心判据：谁持有执行流的控制权。

L1-L2 始终是单模型决策。L3 有多个模型参与，但它们按开发者预写的代码路径执行——Anthropic 把这一层叫 Workflow，不叫 Agent。只有 L4，模型自己决定「接下来谁干什么」，才是完整意义上的 Multi-Agent。

这个区分不是学究式的。它直接影响工程成本：

层级 调试难度 出错时排查路径 Token 开销
L1 低——单模型，看 prompt 和 tool 调用 线性回溯 1x
L2 中——需看工具返回了什么 线性回溯 + 工具日志 1.2-1.5x
L3 高——需跟踪多模型间的信息传递 分布式 trace 2-5x
L4 极高——编排逻辑本身是动态的 需 replay 整个决策链 3-10x

一条硬性规则：如果 L2 能解决问题，不要用 L3。如果 L3 能解决问题，不要用 L4。每升一级的工程复杂度不是线性增加，是指数增加——但能力提升往往只是线性的。

Anthropic 的分界线：Workflow ≠ Agent

Anthropic 在《Building Effective Agents》里做了一个对行业影响深远的术语切割：

  • Workflow：LLM 和工具通过预定义代码路径编排。开发者控制流程。
  • Agent：LLM 动态指挥自身过程和工具使用。模型控制流程。

按这个标准，CrewAI 的 Sequential Process、LangGraph 的固定图结构、Google ADK 的 SequentialAgent/ParallelAgent——全部是 Workflow，不是 Agent。它们用了多个 LLM 实例，但没有任何一个实例拥有「决定整个系统下一步做什么」的自主权。

这个切割的工程含义：Workflow 可预测、可测试、可回放；Agent 不可预测、难测试、需要 Monte Carlo 式的统计评估。 生产环境中 Workflow 的可靠性远高于 Agent，代价是灵活性有限。

四种通信拓扑：Multi-Agent 的底层分类

在讨论具体编排模式之前，需要先建立一个更基础的分类框架。Multi-Agent 系统按 Agent 间的通信拓扑结构可以分为四类：

Independent（独立式）

1
2
3
4
5
6
Agent A        Agent B        Agent C
  │              │              │
  ↓              ↓              ↓
Result A      Result B      Result C
              ↓
          聚合/投票

各 Agent 完全独立工作，之间没有通信。最终结果通过投票、排序或外部聚合逻辑产生。

本质：用并行冗余换正确率。每个 Agent 看到相同输入，独立产出答案，数量优势弥补个体不足。

工程特征：零通信开销、线性可扩展、Agent 之间无协调失败风险。代价是无法处理需要信息交换才能解决的任务——如果答案需要综合多个 Agent 各自持有的不同信息，Independent 模式做不到。

实际案例：Mixture-of-Agents（MoA）的底层思想、Anthropic Parallelization 中的 Voting 变体、「More Agents Is All You Need」论文证明的 sampling-and-voting 策略。45% 法则直接约束这种模式的 ROI。

Centralized（中心化）

1
2
3
     Orchestrator
    /     |      \
Agent A  Agent B  Agent C

一个中央 Agent（Orchestrator）持有全局视图，负责任务分配、进度监控、结果汇总。子 Agent 只和 Orchestrator 通信，彼此之间不直接对话。

本质：用一个强力协调者降低系统整体的协调复杂度。N 个 Agent 的通信路径从 N(N-1)/2 降到 N。

工程特征：全局可控、进度可追踪、失败可定位。代价是 Orchestrator 成为单点瓶颈——它的 context 里需要容纳所有子 Agent 的状态摘要，且它的决策质量决定整个系统的上限。

实际案例：Magentic-One 的双循环 Orchestrator、CrewAI 的 Hierarchical Process、LangGraph 的 Supervisor 模式、Google ADK 的 LlmAgent 层级委派。

Decentralized（去中心化）

1
2
3
Agent A ←→ Agent B
  ↕            ↕
Agent C ←→ Agent D

没有中央协调者。每个 Agent 自己决定何时与谁通信、何时将控制权交给谁。协调逻辑分布在所有参与者中。

本质：用局部决策替代全局编排。每个节点只需要知道「自己能做什么」和「做不了的时候交给谁」。

工程特征：无单点故障、可动态扩展、局部修改不影响全局。代价是缺乏全局视图——没有人知道「整件事做到哪了」，任务可能在 Agent 之间循环传递（ping-pong）而无人检测到。

实际案例：OpenAI Swarm 的 Handoff 机制、AutoGen 的 Swarm 模式、CAMEL 的双 Agent 角色扮演。

Hybrid（混合式）

1
2
3
4
    Orchestrator (高层)
    /          \
Team A        Team B (内部去中心化)
A1←→A2       B1←→B2←→B3

在不同层级采用不同拓扑：高层用 Centralized 做战略协调，低层用 Decentralized 做战术执行。或者：大部分时间 Independent 并行，遇到冲突时切换为 Centralized 仲裁。

本质：承认没有单一拓扑能覆盖所有场景，用组合应对复杂性。

工程特征：灵活性最高，但设计复杂度和调试难度也最高。需要明确定义「什么条件下从一种拓扑切换到另一种」。

实际案例：Magentic-One（外循环 Centralized + 内部各 Agent 有局部自主权）、LangGraph 的层级子图（顶层 Supervisor 管理多个内部自治的子图）、Google ADK 的嵌套组合。

四种拓扑与框架的对应关系

拓扑 通信成本 全局可控性 容错性 适用复杂度
Independent 无 高（不需要协调） 最高 低——子任务完全独立
Centralized 中（N条路径） 最高 低——Orchestrator 挂了全挂 中高——需要协调但可以统一管理
Decentralized 高（最坏 N²） 低 高——单点故障不影响全局 中——协作需求有但不需要全局规划
Hybrid 取决于设计 中高 中 最高——复杂任务的现实选择

这四种拓扑是 Multi-Agent 架构的第一性分类——它决定了信息怎么流动、谁有权做决策、系统在哪里可能断裂。后面讨论的所有框架，都可以映射到这四种拓扑中的一种或多种。

Google ADK 的四种编排原语

在通信拓扑之上，Google Agent Development Kit（ADK）提供了另一个正交维度的分类：执行模式。四种编排原语定义的不是「Agent 怎么通信」，而是「Agent 按什么时序执行」。两套分类互补——拓扑决定信息流，编排原语决定控制流。

SequentialAgent

1
A → B → C

前一步的输出通过 output_key 写入 Session State，后一步从 State 读取。这就是流水线，没什么花哨的。

什么时候用：任务可以清晰分为有先后依赖的阶段。调研 → 写作 → 审校。数据获取 → 分析 → 可视化。

什么时候不用：阶段之间不是严格单向依赖时。如果审校发现问题需要回到写作阶段，纯 Sequential 没有回退机制——需要外面包一层 LoopAgent。

CrewAI 的 Process.sequential 是这个模式的直接实现。AutoGen 的 RoundRobinGroupChat 也是——固定顺序轮流说话。

ParallelAgent

1
2
3
    ┌→ A ─┐
In ─┼→ B ──┼→ 聚合
    └→ C ─┘

多个子 Agent 同时启动，各自独立执行。共享 Session State 但运行在独立上下文分支。

什么时候用：子任务确实互不依赖。并行搜索三个数据库。同一个 prompt 让三个不同模型各生成一版方案然后投票。

致命陷阱：如果子任务之间有你没意识到的隐含依赖——比如两个 Agent 都在修改同一个文件——ParallelAgent 不会报错，它会让两个修改互相覆盖，后写入的赢。这种 bug 极难排查因为它不是每次都复现。

Anthropic 的 Parallelization 分两种变体：Sectioning（不同子任务并行）和 Voting（同一任务执行多次取多数）。Voting 变体直接关联到后面讨论的 45% 法则。

LoopAgent

1
2
3
4
┌→ 生成 → 评估 ─┐
│     ↑         │ 不够好
│     └─────────┘
└── 够好 → 输出

反复执行子 Agent 序列，直到：达到 max_iterations、某子 Agent 发出 escalate=True、或外部判定收敛。

什么时候用：需要迭代改善的任务。代码生成→测试→修复。写作→评审→修订。

常见失败模式——振荡：Generator 改了一处，Critic 说改回去，下一轮 Generator 又改过来。Anthropic 把这种模式叫 Evaluator-Optimizer，他们的建议是 Evaluator 必须给出具体的、单向的改进指令而非模糊的「不够好」，否则容易陷入振荡。

另一个失败模式——退化：每次迭代模型都微调一点，但越改越偏离原始意图。常见于创意类任务——写一篇文章，review 五轮后变成了另一篇文章。解法是 Loop 中保留原始需求的锚定 prompt。

LlmAgent 层级委派

1
2
3
     Orchestrator（LLM 驱动）
    /      |        \
Expert A  Expert B  Expert C

中央 LlmAgent 根据当前输入动态决定委派给谁。两种委派方式：

  • transfer_to_agent()：控制权完全转移，Orchestrator 退出当前循环
  • AgentTool：把子 Agent 包装成工具同步调用，结果返回 Orchestrator 继续决策

什么时候用：输入类型运行时才知道，无法预先写死路由规则。客服系统——退款问题走退款专家，技术问题走技术专家，投诉走投诉处理。

核心风险：Orchestrator 的路由准确性决定整个系统的上限。如果 Orchestrator 误判输入类型，整条链偏移。实操中 Orchestrator 的 prompt 必须包含每个子 Agent 的极精确的能力描述——模糊描述 → 模糊路由 → 错误结果。

这就是 OpenAI Swarm 的本质：去掉中央 Orchestrator，让每个 Agent 自己决定何时把控制权交给谁。Swarm 的 Handoff 机制 = 分布式的层级委派，路由决策下放到每个节点。

组合才是真实系统的常态

Google ADK 的真正贡献不是发明这四种模式——它们各自都是老概念。贡献是证明了四种原语可以任意嵌套，且嵌套后的组合仍然保持可预测性（因为每种原语的行为是确定性的）。

一个实际的生产配置：

1
2
3
4
SequentialAgent (总流程)
├── ParallelAgent (信息采集：并行查三个来源)
├── LoopAgent (分析：生成→验证→改→再验证)
└── LlmAgent (输出路由：根据结果类型选通知方式)

这比「一个全能 Orchestrator 管所有事」的架构鲁棒得多——每一层的行为是局部可预测的，出了问题可以定位到具体哪一层。

Anthropic 为什么说「不要 Multi-Agent」

表面主张

Anthropic 在《Building Effective Agents》中反复传递一个信息：从最简单的方案开始，只有在确认简单方案不够时才升级复杂度。原文：「找到最简单的解决方案，只在需要时增加复杂性」，甚至说「这可能意味着根本不构建 Agent 系统」。

他们推荐的升级路径：

1
2
3
4
5
6
7
8
9
10
11
12
13
优化单次 LLM 调用 + RAG
  ↓ 不够
Prompt Chaining（序列调用 + 程序化校验）
  ↓ 不够
Routing（输入分类 → 专用处理器）
  ↓ 不够
Parallelization（并行 + 投票/切片）
  ↓ 不够
Orchestrator-Workers（动态子任务分配）
  ↓ 不够
Evaluator-Optimizer（生成-评估循环）
  ↓ 都不够
Agent（模型自主控制执行流）

注意前六级全部是 Workflow。Agent 是最后选项。

深层逻辑：这是一个关于模型进化速度的赌注

Anthropic 的立场不是「Multi-Agent 没有用」。它的立场是：在模型能力快速迭代的时期，投资于让单模型用好工具（Skill Augmentation）比投资于多模型间编排（Role Decomposition）的投资回报期更长。

推理链：

  1. Multi-Agent 架构的每一层编排代码都编码了一个假设：「模型做不到 X，所以需要另一个模型帮它做 X」
  2. 模型在快速迭代——Opus 4.5 需要的 context reset 机制在 Opus 4.6 上就不再需要了
  3. 今天为模型能力不足而搭建的编排脚手架，可能半年后就过期
  4. 相比之下，工具设计（ACI）的投资更耐久——好的文件操作工具在 Opus 4.5 和 4.6 上都有用

这就是 Anthropic「Skill 优于 Agent」哲学的本质：Skill（工具/能力）是给模型做加法，编排是给系统做乘法。加法的投资不会因为模型升级而作废，乘法的投资可能会。

Claude Code 是这个哲学的产品化实证：一个 L2 系统（单 Agent + 深度优化的工具集），不用 Multi-Agent，在 SWE-bench 上的表现说明精调 ACI 可以走很远。Anthropic 的原话：「我们花在优化工具设计上的时间比花在整体 prompt 上多得多。」

行业验证：从 Multi-Agent 回退到 Skill 的趋势

这不只是 Anthropic 一家的理论主张。2026 年上半年，一线工程团队中出现了一个明显的回退趋势：先前投入 Multi-Agent 架构的团队，开始主动退回到 Single Agent + Skill 的模式。

驱动回退的原因集中在三点：

  1. 维护成本失控：Multi-Agent 系统的调试需要分布式 trace，Agent 间的通信协议需要持续维护，角色边界在需求变更时需要重新划分——这些维护成本在系统上线后持续增长，且不随模型升级自动降低
  2. 错误归因困难：当系统输出不符合预期时，是 Agent A 的理解有误、Agent B 的工具调错了、还是 Orchestrator 的路由逻辑有 bug？在 Multi-Agent 系统中定位根因的时间成本是 Single Agent 的 3-10 倍
  3. 模型升级使编排层贬值：团队花三个月设计的 Multi-Agent 编排逻辑，在底层模型升级一代后发现单 Agent 就能搞定同样的任务——之前的编排投资归零

回退路径通常是：将原来由多个 Agent 角色承担的能力，重新封装为单 Agent 可调用的 Skill（工具/函数/知识包）。Agent 数量从 N 个缩减为 1 个，但这 1 个 Agent 的工具集变得更丰富、更精调。

这个趋势的工程含义：Multi-Agent 不是演进的终点，而是演进路径上的一个可能的中间态。 随着模型能力提升，之前必须通过角色分离才能解决的问题，可能被更强的单体模型直接吸收。架构设计时应该预留「合并回单 Agent」的退路——不要把 Multi-Agent 的通信协议设计得过于 tight-coupled，以至于无法在不重写整个系统的情况下减少 Agent 数量。

这个逻辑什么时候失效

三种情况下 Anthropic 的路线不适用：

  1. 模型能力停滞：如果接下来两年模型迭代速度放缓，那 Multi-Agent 编排的投资回报期就变长了——今天搭的架构不会那么快过期
  2. 任务天然需要对抗性视角：Red Teaming、辩论式验证——单模型无法同时持有互斥立场。这类任务 Multi-Agent 是逻辑必要的，不是工程选择
  3. 单 context 物理装不下：当每个子领域的工具定义 + instruction 加起来超过模型的有效 context 处理能力时，分离为多 Agent 是物理约束，不是架构偏好

45% 法则：增加 Agent 的收益边界

含义

当单个 Agent 对目标任务的成功率超过 45% 时，通过增加 Agent 数量来提升系统整体成功率的边际收益急剧下降。

数学直觉

考虑最简单的 Multi-Agent 提升策略——三个 Agent 并行执行同一任务，majority voting 取多数。

设单 Agent 成功率为 p。三 Agent majority voting 的系统成功率为：

1
P(system) = 3p² - 2p³
单 Agent 成功率 p 系统成功率 P 绝对提升 相对成本
30% 44% +14pp 3x
40% 53% +13pp 3x
45% 58% +13pp 3x
50% 63% +13pp 3x
60% 65% +5pp 3x
70% 78% +8pp 3x
80% 90% +10pp 3x

等等——这个表格似乎说即使在 60% 时加 Agent 也有收益？为什么说 45% 是边界？

关键在于对比基线：45% 以下时，把同等工程投入花在「提升单 Agent 能力」上的效率通常低于「增加 Agent 数量」。因为把 30% → 45% 往往需要模型级别的改进或大量 prompt engineering，而简单地跑三份投票就能从 30% → 44%。

45% 以上时，情况反转：把同等投入花在「改进 prompt/工具/context 质量」上，让单 Agent 从 60% → 75%（+15pp），比花 3 倍 Token 跑投票从 60% → 65%（+5pp）划算得多。

核心含义不是「45% 以上 Multi-Agent 无用」，而是「45% 以上优先优化单体，45% 以下可以考虑堆量」。

实操指导

  1. 先测基线：在目标任务上跑 50-100 次 Single Agent，统计成功率
  2. 判断区间：
    • p < 20%：模型能力不足，加 Agent 也救不了，等更强模型或重新定义任务
    • p ∈ [20%, 45%]：Multi-Agent（并行+投票或分工+验证）有 ROI
    • p > 45%：优先投资单 Agent 优化（更好的工具、更好的 context、更精准的 prompt）
  3. 注意前提：45% 法则假设各 Agent 的错误是独立的。如果多个 Agent 犯同一种错误（因为用了同一个模型、同一个 prompt），投票不会修正系统性偏差——它只会放大

通信带宽：Multi-Agent 的隐性税

核心问题不是成本，是信息损耗

通信成本（Token 消耗）是显性的、可计算的。但 Multi-Agent 通信的真正代价是信息损耗：每次 Agent A 把工作成果传递给 Agent B，都需要某种形式的序列化——要么全量传递（Token 爆炸），要么摘要传递（信息丢失）。

全量传递的问题：Agent B 看到 Agent A 的所有输出，但 LLM 的 attention 分布不均匀——context 中间的信息被遗忘的概率高于开头和结尾（Lost in the Middle 效应）。结果是 Agent B 名义上「看到了」全部信息，实际上只有效利用了一部分。

摘要传递的问题：LLM 做摘要时必然会丢弃它认为「不重要」的细节。但 Agent B 需要的细节和 Agent A 认为「重要」的细节可能不一致。这种信息不对称在长链路 Multi-Agent 系统中逐级放大。

Brooks 定律的 Token 版本

N 个 Agent 全量广播模式下的沟通路径数 = N(N-1)/2。4 个 Agent = 6 条路径。8 个 Agent = 28 条路径。

但真实的伤害不在于路径数，而在于每个 Agent 的 context 膨胀速度。全量广播下，每个 Agent 每轮要处理 (N-1) 条新消息。5 个 Agent 跑 10 轮，每个 Agent 的 context 里堆积了 40 条来自他人的消息——假设每条 500 token，额外 context 开销 = 20,000 token/Agent。

这不只是账单问题。Context 越长，模型推理质量越不稳定。存在一个实践中反复观察到的现象：Agent 数量增加到某个阈值后，系统整体表现开始下降——不是因为 Agent 能力不够，而是因为每个 Agent 的有效 context 被通信噪声稀释了。

各框架怎么处理这个问题

策略 代表 Token 效率 付出的代价
仅 Handoff 传递 OpenAI Swarm 最高 无全局视图，复杂协作做不了
独立记事板 + 仅结果上报 LangGraph Supervisor 高 Supervisor 可能漏掉关键上下文
SOP 结构化传递 MetaGPT 中高 灵活性受限，非标任务难适配
分层隔离 Magentic-One 中 架构复杂度高
全量广播 + 选人 AutoGen Selector 低 context 膨胀快
层间全连接 MoA 最低 设计本意就是用 Token 换质量

最优解不存在。Token 效率和信息完整性之间是不可调和的 tradeoff——隔离越强，沟通越便宜，但 Agent 做决策时可用的信息也越少。好的架构选择是找到你的任务能容忍的信息损耗下限，然后选择刚好满足这个下限的最高效通信模式。

六个框架的真实 Tradeoff

不做功能列表对比。只说每个框架的核心赌注是什么——它在什么假设下最强，假设不成立时会怎么崩。

OpenAI Swarm / Agents SDK Handoff

核心赌注：每个 Agent 可以独立做局部最优决策，不需要全局协调。

最强场景：能力域清晰分离、路由规则简单的系统。客服系统是完美用例——每个问题类型对应一个专家，专家之间不需要协作。

崩溃条件：任务需要多个 Agent 协作完成一个目标时。Swarm 没有「全局进度追踪」的概念——没有人监控「整件事做完了没有」。如果一个用户问题需要先查订单（Agent A）再退款（Agent B）再发确认邮件（Agent C），这三步的顺序和完整性需要额外机制保障。Swarm 本身不提供这个机制。

Microsoft Magentic-One

核心赌注：长程复杂任务需要持续的进度监控和动态重规划。

最强场景：开放式的多步骤任务（GAIA benchmark 的典型题目——需要搜索、推理、计算、验证的组合）。双循环机制保证了任务不会卡死——内循环检测停滞，外循环触发重规划。

崩溃条件：简单任务上过度工程。如果任务本身只需要两步就能完成，Orchestrator 的双循环监控、Task Ledger 维护、Progress Ledger 自省——全部是浪费。5 个 Agent 的固定开销对简单任务来说是纯税。

MetaGPT

核心赌注：用人类组织的 SOP 可以有效抑制 LLM 的幻觉级联。

最强场景：软件开发——因为软件开发本身就有成熟的 SOP（PRD → 系统设计 → 代码 → 测试），每步的输入输出格式可以严格定义。SOP 充当了 Agent 间通信的 type system，传递的不是自由文本而是结构化文档，偏差可以在传递环节被 schema 校验捕获。

崩溃条件：非标任务。如果你的任务没有公认的 SOP——比如创意写作、开放式研究、异常排查——MetaGPT 的框架会迫使你先发明一个 SOP，然后用不合适的 SOP 约束 Agent，产出质量反而低于 free-form 协作。

LangGraph

核心赌注：Multi-Agent 的可靠性来自编排逻辑的显式可观测。

最强场景：需要精确控制「什么条件下控制权从 A 转到 B」的系统。LangGraph 把 Agent 协作建模为状态机——节点是 Agent，边是转移条件——开发者对整个控制流有完全的可见性和可编程性。出了问题可以检查状态转移日志。

崩溃条件：需要高度灵活性时。状态机的优势（确定性）也是它的约束——所有合法的状态转移必须预先定义。如果运行时出现了没预定义的情况，系统要么卡住，要么走 fallback 路径。对比 Magentic-One 的动态重规划能力，LangGraph 更适合「可以枚举所有可能情况」的领域。

AutoGen / AG2

核心赌注：一个框架应该支持所有协调模式，让用户按需切换。

最强场景：探索期——不确定哪种协调模式最适合你的任务时，AutoGen 让你可以用同一套 Agent 定义快速切换 RoundRobin/Selector/Swarm/GraphFlow，对比效果。这在原型阶段很有价值。

崩溃条件：生产期的极致性能需求。通用性的代价是每种模式都不是为你的特定场景深度优化的。如果你已经确定 Swarm 最适合你，直接用 OpenAI 的 Agents SDK（或自己写 100 行 Handoff 逻辑）比通过 AutoGen 的抽象层更轻量、更可控。

CrewAI

核心赌注：声明式角色定义（「你是一个 Senior Researcher」）足以让 Agent 表现出对应的专业行为。

最强场景：角色分工清晰、每个角色的行为模式可以用 natural language 充分描述的任务。写作团队（Researcher + Writer + Editor）是典型。

崩溃条件：需要精细控制 Agent 行为边界时。CrewAI 的角色描述是自然语言 prompt——模型「理解」了角色不等于它会严格遵守角色边界。当两个角色的职责有灰色地带时，Agent 可能越界执行不属于自己的工作，或者两个 Agent 都认为某事「不是自己负责的」而无人执行。

任务类型 → 架构的映射规则

决策流程图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
你的任务
│
├─ 单次 LLM 调用搞定？ → 直接调用，别折腾
│
├─ 多步但流程固定？
│   ├─ 步骤串行依赖 → SequentialAgent / CrewAI Sequential
│   ├─ 步骤互相独立 → ParallelAgent
│   └─ 需要迭代改善 → LoopAgent + 明确终止条件
│
├─ 需要动态决定下一步？
│   ├─ 能力域 < 5 个且边界清晰 → LlmAgent 层级委派
│   ├─ 能力域多且各自独立 → Swarm Handoff
│   └─ 长程任务需要重规划 → Orchestrator 双循环 (Magentic-One 式)
│
└─ 不确定上面哪种？
    → 先跑 Single Agent 基线 50 次
    → 统计成功率和失败模式
    → 按失败模式选对应的 Multi-Agent 策略

失败模式 → 架构策略

这是一个比「任务类型 → 架构」更实用的映射——先诊断单 Agent 在哪里失败，再选择针对性的 Multi-Agent 策略：

单 Agent 的主要失败模式 对应 Multi-Agent 策略 原理
工具太多选错 分离为专家 Agent + Routing 每个 Agent 只看到自己领域的工具
生成质量不稳定 Parallel + Voting 多次采样取多数，减少方差
长任务中途偏离 Orchestrator + Progress 检测 外部监控及时纠偏
推理步骤多容易错 Sequential + 每步验证 分解复杂度，逐步确认
自我评估能力差 Generator + Independent Critic 用不同 prompt/模型做评估
需要对抗性检验 Debate (两个持反对立场的 Agent) 强制暴露盲点
单次上下文装不下 分治：子任务各自处理后汇总 物理约束的解法

被高估和被低估的

被高估的

「Multi-Agent 是 AGI 的路径」：当前 Multi-Agent 系统的协作质量高度依赖 prompt 设计。Agent 之间的「合作」本质上是开发者预设的通信协议在工作，不是涌现出来的协作智能。把 prompt chaining 包装成「Agent 协作」是营销，不是工程。

「框架选择很重要」：真实的难题不在于选 CrewAI 还是 AutoGen——而在于你怎么定义 Agent 的角色边界、怎么设计它们之间传递什么信息、怎么处理失败。这些决策在任何框架里都需要人做，框架只是执行层面提供了一些方便。

「Mixture-of-Agents 证明了人多力量大」：MoA 的成功有严格前提条件——各 Agent 必须产生 informative disagreement（信息性分歧），而非因为同一个 bias 犯同一种错误。用同一个模型跑三遍大多数时候只是在浪费 3x Token 验证了同一个错误。

被低估的

单 Agent 工具设计的 ROI：Anthropic 反复强调的一个点——他们的 SWE-bench agent 花了最多时间在工具设计上。一个好的 file search 工具、一个精准的 code edit 工具，对单 Agent 性能的提升可能超过加三个 Agent。

通信协议设计：Multi-Agent 系统中 Agent 之间「传什么」「不传什么」「用什么格式传」的决策，对系统效果的影响远大于「用几个 Agent」「用什么模型」的决策。MetaGPT 的成功本质上是通信协议设计（SOP 格式约束）的成功，不是多 Agent 数量的成功。

Failure mode 分析的价值：MAST 论文（Multi-Agent System Failure Taxonomy）在 7 个 Multi-Agent 框架的 1600+ 条 trace 上标注了 14 种失败模式，归为三大类：系统设计缺陷、Agent 间错位、任务验证失败。这种 failure taxonomy 对架构决策的指导价值远大于 benchmark 排名——前者告诉你哪里会断，后者只告诉你跑分高不高。

决策清单

做 Multi-Agent 架构决策之前，按顺序回答这些问题：

  1. 基线在哪：单 Agent 在目标任务上的成功率是多少？>45% → 先别加 Agent。
  2. 失败模式是什么：单 Agent 为什么失败？工具不够？context 不够？推理步数太多？对症选策略。
  3. 子任务之间有依赖吗：有 → Sequential；没有 → Parallel；需要迭代 → Loop。
  4. 编排逻辑是固定的还是动态的：固定 → Workflow（L3 就够）；动态 → Agent Teams（L4）。
  5. 通信税能承受吗：估算通信 Token 占比，>30% 说明通信模式需要从广播切到隔离。
  6. 半年后这个架构还需要吗：如果下一代模型可能让某层编排变得多余，把它设计成可拆卸的。

参考来源：

  • Anthropic, Building Effective Agents, 2024-12-19
  • Google, Agent Development Kit — Workflow Agents & Multi-Agents Documentation, 2025
  • OpenAI, Swarm (experimental/educational framework), 2024; Agents SDK, 2025
  • Microsoft Research, Magentic-One: A Generalist Multi-Agent System, 2024
  • MetaGPT: Meta Programming for Multi-Agent Collaborative Framework, arXiv:2308.00352
  • AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, arXiv:2308.08155
  • LangChain, LangGraph Multi-Agent Workflows, 2024
  • Mixture-of-Agents Enhances Large Language Model Capabilities, arXiv:2406.04692
  • Andrew Ng, How Agents Can Improve LLM Performance, DeepLearning.AI, 2024
  • HuggingFace, smolagents Documentation, 2025
  • MAST: Multi-Agent System Failure Taxonomy, arXiv:2503.13657
  • CrewAI Documentation — Processes, 2025
  • CAMEL: Communicative Agents for “Mind” Exploration of Large Language Model Society