📘 《深入理解 AI Agent》系列 · 第八篇 | AGENT-03

前篇回顾：Agent 基础篇 #01 从LLM到Agent → Agent 基础篇 #02 四大核心机制 → Agent 基础篇 #03 从单Agent到多Agent

---

开篇：单 Agent 能走多远？

做 AI Agent 的开发者常有一个直觉：当任务变复杂时，加 Agent 就完事了。一个 Agent 不够，就两个；两个不够，就三个——仿佛"多"天然比"少"好。

但工程实践揭示了一个反直觉的事实：绝大多数时候，你以为需要多 Agent 的场景，其实一个 Agent 也能搞定。 真正需要多 Agent 架构的条件，比大多数人想象的苛刻得多。

从三个真实案例说起。

案例一：简单任务——一个 Agent 绰绰有余

"帮我查一下昨天的销售额，做个环比分析，然后发邮件给运营组。"

这是一个典型的企业内部 Agent 场景。任务链路很清晰：理解意图 → 调用数据库工具查数据 → 计算环比 → 调用邮件工具发送。整个过程可能 5-8 轮对话就能完成，上下文窗口完全装得下，工具数量不超过 5 个。

这种场景下，单 Agent 不仅够用，而且是最优解——没有协调开销，没有状态同步问题，调试也简单。

案例二：中等任务——一个 Agent 有点吃力，但还能撑

"帮我做一份竞品分析报告，需要调研 A、B、C 三家公司的产品功能、定价策略、用户评价，最后整理成一份对比表格。"

这个任务复杂度上来了。Agent 需要：搜索多家公司的信息、从多个来源交叉验证、整理结构化数据、生成对比报告。整个过程可能 15-20 轮对话，上下文逐渐变厚，工具调用也更频繁。

但请注意：吃力 ≠ 搞不定。 通过合理的工具设计（比如分步骤搜索、用向量检索替代全量塞入上下文），单 Agent 仍然可以完成任务。质量可能不是最优的，速度可能不是最快的，但功能上是通的。

案例三：复杂任务——一个 Agent 开始崩

"帮我开发一个完整的用户管理模块，包括数据库设计、后端 API、前端页面、单元测试和接口文档。涉及 5 张表、12 个接口、3 个页面。"

到这个量级，单 Agent 就开始出现系统性问题了。你可能观察到以下现象：

• Agent 在第 10 轮对话后"忘记"了第 3 轮确定的数据库设计规范
• Agent 在几十个可用工具中选错了工具
• 所有子任务串行执行，一个 1 小时的任务要跑 5 小时

这不是 Agent 不够聪明，而是它撞上了单 Agent 架构的三堵墙：上下文墙、工具墙、并行墙。

---

一、单 Agent 的三堵墙

单 Agent 不是不够好，而是它的能力边界被三个结构性因素限制住了。这三个因素不来自模型本身，而是来自架构设计。需要说明的是，下文归纳的"三堵墙"并非某一家独创理论，而是业界多篇分析（Anthropic、Vercel、CoderCops 等）反复提及的共识约束，在此做系统化梳理。

1.1 上下文墙：Lost in the Middle

每个做过 Agent 的人都遇到过这种情况：你在对话开头明确告诉 Agent "所有接口必须返回统一的 Response 包装类"，结果到了第 15 轮对话，它写出来的接口直接返回了原始数据。

你以为是模型记性不好，但问题比这更深。

Lost in the Middle 是 2023 年由斯坦福和 UC Berkeley 的研究团队发现并系统验证的现象 (Liu et al., TACL)。研究者把关键信息放在长上下文的不同位置——开头、中间、结尾——然后测试模型能否准确检索到。结果呈现出一条清晰的 U 型曲线：

• 信息在开头时，准确率约 70%
• 信息在中间时，准确率降至约 40%
• 信息在结尾时，准确率回升至约 70%

准确率落差超过 30 个百分点。这不是某一个模型的问题——即使是那些号称支持 200K 甚至 1M token 上下文的模型，都表现出了同样的模式 (harnez.ai)。

这个效应在心理学中有个对应的概念叫系列位置效应（Serial Position Effect）——人类对列表开头和结尾的内容记忆最好，中间最差。但有意思的是，Transformer 的注意力机制理论上应该能平等地关注到任何位置的 token，为什么也会出现这种偏差？

答案是：注意力是有限的资源。 当上下文从 4K 涨到 200K，注意力这块"饼"并没有变大——它只是被切给了更多的 token，每个 token 分到的注意力变薄了 (掘金)。那些夹在中间、又被海量信息淹没的关键内容，就很难在模型的注意力中"脱颖而出"。

Anthropic 的研究进一步指出：多个独立上下文的子 Agent，比单个大上下文的 Agent 效果更好 (51CTO)。原因很简单——每个子 Agent 的上下文是"干净"的，没有其他领域的信息干扰。一个负责"数据库设计"的 Agent，上下文中全是数据库相关的内容，注意力集中度自然更高。

上下文墙的本质是：信息越多，信噪比越低。 你以为给 Agent 更多信息是在帮它，实际上你是在增加它找信息的难度。

1.2 工具墙：选择越多，选错越多

单 Agent 架构的第二堵墙是工具墙——工具越多，Agent 选错工具的概率越高。

这听起来反直觉——工具多了能力不是更强吗？能力确实更强，但前提是 Agent 能选对工具。而工具选择本身就是一个非平凡的推理任务。

Vercel 在 2026 年初做了一组非常有说服力的评估实验 (Vercel Blog)。他们测试了不同方式下 Agent 完成 Next.js 编码任务的通过率：

配置	通过率	相对基准提升
基准（无文档）	53%	—
Skill（默认行为，工具形式加载）	53%	+0pp
Skill + 明确指令	79%	+26pp
AGENTS.md 文档索引（被动上下文）	100%	+47pp

结果令人意外：默认的 Skill（工具）加载方式跟没有文档的效果完全一样——53%。也就是说，Agent 根本不知道什么时候该调用这个 Skill。即使加了明确的调用指令，也只有 79% 的成功率。而把文档以静态 markdown 文件的形式直接放在上下文中，反而达到了 100%。

为什么会这样？Vercel 的结论是：被动上下文优于主动检索，因为没有决策点。 当文档就在上下文中时，Agent 不需要判断"是否需要调用 Skill"——它直接就能看到。而每次多一个决策点，就多一次出错的可能。

这个结论对工具墙的启示很直接：工具数量增加，意味着决策点增加，出错概率指数级上升。

Anthropic 在 MCP 生态中也遇到了同样的问题。当一个 Agent 连接了多个 MCP Server、拥有 50+ 工具时，工具定义本身就要消耗约 72K token——在 200K 的上下文窗口里，工作还没开始，三分之一的空间已经被工具定义占了 (Anthropic Engineering)。

更严重的是准确率问题。内部测试显示，在大型工具库场景下：

• Opus 4 的准确率：49%（无 Tool Search）→ 74%（有 Tool Search）
• Opus 4.5 的准确率：79.5%（无 Tool Search）→ 88.1%（有 Tool Search）

Anthropic 的解决方案是 MCP Tool Search（工具搜索懒加载）——默认不加载所有工具定义，只提供一个"搜索工具"的元工具。当 Agent 需要某个工具时，先搜索，再按需加载相关工具的定义。这个机制在工具描述超过上下文窗口的 10% 时自动启用，将初始 token 开销减少了约 85% (Anthropic Engineering)。

Claude Code 中的实现更具体：当 MCP 工具定义超过上下文的 10% 时自动启用懒加载模式，初始只需约 500 token 的 MCPSearch 工具，实际用到的工具再按需加载（3-5 个相关工具约 3K token） (CSDN)。

工具墙的核心矛盾：工具越多，能力边界越广，但工具选择的准确率越低。这不是一个可以通过"优化 prompt"解决的问题——它是选择的固有代价。

1.3 并行墙：本质串行的架构限制

单 Agent 的第三堵墙是最直观的——它天生是串行的。

一个 Agent 在同一时间只能做一件事：要么在思考，要么在调用工具，要么在生成回复。即使任务中有多个完全独立的子任务，它也只能一个一个来。

举个例子：一个市场分析任务需要同时调研 5 个竞品的定价策略。假设每个竞品的调研需要 10 分钟（搜索 + 整理 + 分析），单 Agent 串行执行就是 50 分钟。如果用 5 个 Agent 并行，理论上可以压缩到 10 分钟左右。

5 倍的速度差距，这不是"优化一下 prompt"能解决的问题——这是架构限制。

当然，单 Agent 也可以做一定程度的"伪并行"——比如一次发起多个工具调用（很多模型支持并行 function calling）。但这仅限于工具调用层面，推理本身仍然是串行的。Agent 不能同时思考两个不同方向的问题。

并行墙在 IO 密集型任务（搜索、API 调用、文件读写）中尤其明显。这类任务中，LLM 推理时间占比很低，大部分时间都在等外部工具返回结果。单 Agent 的架构下，这些等待时间是串行叠加的；多 Agent 架构下，这些等待时间可以并行重叠。

---

二、什么时候"不需要"多 Agent？

讲完了三堵墙，你可能觉得多 Agent 是必选项。但别急——在讨论"什么时候需要多 Agent"之前，先看一个更重要的问题：什么时候不需要多 Agent？

行业实践中存在一个被低估的判断：CoderCops 对生产项目的回顾发现，约 70% 自称"多 Agent"的项目，其实可以简化为"单 Agent + 优质工具" (CoderCops)。Iterathon 对 47 个生产部署的统计也印证了这一点：约 68% 的部署本可以通过精心设计的单 Agent 系统达到同等或更好效果，成本仅为多 Agent 的 30-40%，但能覆盖 90-95% 的效果 (Iterathon)。

这个判断不是拍脑袋来的，而是基于几个观察：

2.1 大多数"多 Agent"只是在调工具

很多所谓的"多 Agent 系统"，拆开来看看：一个 Agent 负责搜索，一个 Agent 负责写代码，一个 Agent 负责测试——每个 Agent 本质上只是在调用一类工具。

这种情况下，你真的需要"多 Agent"吗？还是说，你只是需要一个工具组织得更好的单 Agent？

回想一下 Vercel 的实验结论：被动上下文优于主动工具检索。如果把"搜索Agent"替换成"搜索工具 + 清晰的工具描述 + 合理的使用时机引导"，效果可能差不了多少，但架构复杂度和 token 开销会低很多。

2.2 上下文不够大？先优化上下文管理

很多团队遇到的第一个问题是"上下文不够用了"，然后就想当然地认为需要拆多 Agent。但在拆之前，应该先确认：是否已把上下文管理优化到位？

以下这些手段，每一个都可能让你的单 Agent 再撑几个量级：

• 工具懒加载：参考 Claude Code 的 MCP Tool Search，不要一次性加载所有工具
• 上下文压缩：定期对历史对话做摘要，把不重要的信息压缩掉
• RAG 替代塞入：需要什么信息检索什么，而不是把所有相关文档全塞进上下文
• 关键信息置顶/置底：利用 U 型注意力曲线，把约束条件放在开头，把当前任务放在结尾

如果这些都做了还是不够，再考虑多 Agent 也不迟。

2.3 判断标准：单 Agent 的上下文能装下吗？

以下是一个实用的判断标准：

如果单 Agent 的上下文能装下完成任务所需的所有信息，就不要用多 Agent。

这里的"所有信息"不是指原始数据全塞进上下文，而是指经过合理的检索、摘要、压缩后，完成任务需要的关键信息能否装入一个 Agent 的上下文窗口。

如果能——单 Agent + 优质工具就是最优解。多 Agent 带来的额外协调开销、状态同步开销、token 开销，都是纯粹的成本，没有收益。

如果不能——信息量大到即使经过最优的压缩和检索，一个 Agent 的上下文也装不下——那才是多 Agent 真正的用武之地。

2.4 为什么大家都爱用"多 Agent"？

既然单 Agent 在大多数场景下都够用，为什么"多 Agent"这个概念这么火？

原因有三个：

1. 概念性感："多智能体协作"听起来就比"单 Agent 调工具"要高级，适合用来讲故事
2. 职责分离的思维惯性：人类组织是多角色协作的，工程师容易本能地想用同样的方式组织 AI
3. 回避工程优化：与其花时间优化上下文管理和工具设计，不如"加个 Agent"来得快——虽然长期成本更高，但短期看起来进度很快

但工程是要算账的。多 Agent 不是免费的升级——它是一种用系统复杂度换任务复杂度的交易。只有当任务复杂度的收益大于系统复杂度的成本时，这笔交易才划算。

---

三、四种核心架构模式

如果确认需要多 Agent 架构，接下来的问题是：选哪种模式？

目前业界主流的多 Agent 架构有四种核心模式，每种模式适合不同的任务特征。选错了模式，不仅达不到预期效果，反而可能比单 Agent 更差。

3.1 Supervisor 模式（星型拓扑）

Supervisor 模式是目前生产环境中最常用、最稳定的多 Agent 架构。

架构特点：一个中心协调者（Supervisor / Orchestrator）负责接收任务、拆解子任务、分配给 Worker Agent 执行、汇总结果。Worker Agent 之间不直接通信，所有信息流转都经过 Supervisor。

                    ┌──────────────────┐
                    │   Orchestrator    │
                    │  (任务拆解/路由)   │
                    └──┬───┬───┬───┬───┘
            ┌──────────┘   │   │   └──────────┐
            ▼              ▼   ▼              ▼
      ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
      │ Worker 1 │  │ Worker 2 │  │ Worker 3 │  │ Worker N │
      │ (专家域)  │  │ (专家域)  │  │ (专家域)  │  │ (专家域)  │
      └──────────┘  └──────────┘  └──────────┘  └──────────┘
            ▲              │   │              ▲
            └──────────────┴───┴──────────────┘
                    结果汇聚（无直连）

优点：

• 控制流清晰：所有决策都在 Supervisor，任务链路一目了然
• 易追踪调试：出了问题看 Supervisor 的决策日志就能定位——是分配错了还是执行错了
• 故障隔离：单个 Worker 失败不影响其他 Worker，Supervisor 可以重试或降级
• 通信成本可控：只有 Supervisor 和 Worker 之间的双向通信，没有 N² 的复杂度

缺点：

• 单点瓶颈：Supervisor 的能力决定了整个系统的上限。Supervisor 理解错了任务，后面做得再好也白搭
• 上下文瓶颈：当 Worker 数量多了之后，Supervisor 的 prompt 里要塞下所有 Worker 的能力描述，上下文压力很大
• 不支持 Agent 间直接协作：如果两个子任务之间需要频繁交互，都经过 Supervisor 中转效率太低

适用场景：任务可以被清晰分解为独立子任务，需要全局调度和质量控制。这也是绝大多数企业级场景的选择。

业内顶级 AI 编程产品如 Devin、MetaGPT、ChatDev 都采用了这种架构的变体，通过架构师、开发、测试、调试、文档等多角色 Agent 分工实现完整工程落地 (CSDN)。

3.2 Hierarchical 模式（分层模式）

Hierarchical 模式是 Supervisor 模式的递归扩展——Supervisor 下面还有 Supervisor，形成树状结构。

┌─────────────┐
│  Top-level   │
│  Supervisor  │
└──┬──────┬───┘
   │      │
┌──▼─┐  ┌─▼──┐
│Mid  │  │Mid  │  ← 中层 Supervisor
│Sup  │  │Sup  │
└┬─┬─┘  └┬─┬──┘
 │ │     │ │
▼ ▼     ▼ ▼
... Worker Agents ...

核心逻辑：每个 Supervisor 只管理 3-8 个直接下属（可以是 Worker，也可以是下一级 Supervisor）。当任务规模大到一个 Supervisor 管不过来时，就增加层级——这跟人类组织的管理跨度原则是一样的。

优点：

• 可扩展性强：理论上可以无限增加层级，支持 20+ 甚至上百个 Agent
• 职责分层：高层负责战略决策，中层负责战术协调，底层负责具体执行
• 每层上下文可控：每个 Supervisor 只需要了解自己直接下属的能力，不需要知道全系统

缺点：

• 信息传递损耗：每经过一层，信息就可能有损失或偏差。就像"传话游戏"，传到最后可能已经变味了
• 响应延迟：指令从上到下、结果从下到上，都需要时间
• 架构复杂度高：多层级的调度和异常处理，实现难度指数级上升

适用场景：超大规模任务（20+ Agent），且任务本身有清晰的层级结构。比如一个大型软件开发项目，下面分前端组、后端组、测试组，每组又有更细的分工。

实践中，每个 Supervisor 的最佳管理跨度是 3-8 个下属。少于 3 个显得浪费，多于 8 个则 Supervisor 的上下文和决策质量会明显下降 (掘金)。

3.3 Peer-to-Peer 模式（点对点模式）

P2P 模式没有中心协调者，所有 Agent 地位平等，互相之间可以直接通信。

┌────────┐  ←──→  ┌────────┐
│Agent A │        │Agent B │
└───┬────┘        └────┬───┘
    │    ┌────────┐    │
    └───→│Agent C │←───┘
         └────────┘

核心逻辑：把一群 Agent 扔进一个"聊天室"，它们自己讨论、协商、分工，最终收敛出一个结果。AutoGen 早期的 GroupChat 就是这种模式的典型。

优点：

• 灵活性高：没有预设的流程，Agent 可以自发组织
• 无单点故障：不存在一个挂了全系统就崩的节点
• 适合创意碰撞：多角度讨论、互相启发，适合头脑风暴类任务

缺点：

• 通信复杂度 O(n²)：每个 Agent 都可能跟其他所有 Agent 对话，消息量爆炸
• 难调试：没有中心控制点，出了问题很难定位是哪一步出了错
• 共识难达成：Agent 之间可能陷入无限循环讨论，或者各说各的，最终没有结论
• Token 消耗极高：每个 Agent 都要读取完整的对话历史，上下文膨胀极快

Cisco 的数据很能说明问题：当前的多 Agent 系统有 41%-87% 的时间无法协调达成共享目标；在无中心协调的场景下，决策成功率只有约 1/3 (Hello Marvis AI Today)。

适用场景：开放式问题、需要多角度碰撞的创意任务、代码审查等。但生产环境中很少使用纯 P2P 模式——通常会加一个主持人或仲裁者来控制节奏。

3.4 Debate/Compete 模式（辩论/竞争模式）

Debate 模式让多个 Agent 各自提出方案，然后通过投票或裁判机制选出最优方案。

   ┌─────────────┐
   │   裁判Agent   │
   │  (Judge)    │
   └──┬───┬───┬──┘
      │   │   │
  ┌───┘   │   └───┐
  ▼       ▼       ▼
┌───┐   ┌───┐   ┌───┐
│方案│   │方案│   │方案│
│ A  │   │ B  │   │ C  │
└───┘   └───┘   └───┘

核心逻辑：对同一个问题，多个 Agent 从不同角度各自给出方案和论证，然后由一个裁判 Agent（或投票机制）评估并选择最优方案。有时还会有多轮辩论——Agent 可以反驳其他方案的弱点。

优点：

• 多角度思考：避免单一路径的盲区，提高决策质量
• 可解释性强：每个方案都有论证过程，为什么选这个一目了然
• 适合高风险决策：在错误代价高的场景下，多方案择优可以降低风险

缺点：

• 成本极高：token 消耗是单 Agent 的 10-15 倍——每个方案都要完整推理一遍
• 速度慢：所有方案都要生成，还要辩论和评审
• 裁判质量决定上限：如果裁判 Agent 判断不准，多方案的优势就发挥不出来

适用场景：高风险决策场景，如金融投资决策、医疗诊断辅助、法律分析等。错误代价比计算成本高得多的时候，Debate 模式就是值得的。

---

四、四种模式对比总览

维度	Supervisor	Hierarchical	Peer-to-Peer	Debate
拓扑结构	星型	树型	网状	星型（裁判中心）
控制方式	中心协调	分层协调	去中心化	裁判裁决
通信复杂度	O(n)	O(n log n)	O(n²)	O(n)
调试难度	低	中	高	中
Token开销	中（2-5x）	高（5-10x）	极高（10-20x）	极高（10-15x）
共识达成率	高（Supervisor拍板）	高（层级决策）	低（~36%）	高（裁判裁决）
扩展性	中（3-8个Worker）	高（可无限分层）	低（n²瓶颈）	低（方案数量有限）
适用任务规模	中等（3-8子任务）	大型（20+子任务）	小型创意任务	小型高价值决策
生产成熟度	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐

工程建议：如果你不确定选哪种，先选 Supervisor 模式。它是目前生产验证最充分、坑最少、性价比最高的方案。其他模式都是在特定场景下的补充，而不是替代品。

---

五、工程挑战：多 Agent 的四个硬问题

选择了架构模式，只是第一步。多 Agent 系统在工程落地时，会遇到四个单 Agent 不存在的硬问题。这些问题处理不好，你的多 Agent 系统可能还不如单 Agent 好用。

5.1 通信成本：15 倍的 Token 税

多 Agent 系统最直接的成本是 token 消耗。

研究数据显示，生产环境中的多 Agent 系统，token 总消耗约为等效单 Agent 实现的 15 倍 (CallSphere)。Anthropic 在 2025 年 6 月的内部研究也得出了类似结论：多 Agent 系统的 token 使用量约为聊天交互的 15 倍 (dev.to)。

这 15 倍从哪来？主要是三类开销：

1. 交接税（Handoff Tax）：每次 Agent 之间交接任务，都需要把上下文传递过去。委托方要总结自己知道什么、需要什么、有什么约束；接收方要处理这些信息再开始工作。结果返回后，委托方还要再解读一遍。

在一个简单的三 Agent 流水线中，相同的上下文可能被复制和处理 4-5 次。有生产追踪数据显示，40% 的 token 消耗是冗余的上下文传递 (geta.team)。

2. 反思开销（Reflection Overhead）：每个 Agent 在输出前通常会自我检查一遍——"我真的回答了问题吗？"接收方在行动前也会反思一下收到的信息——"我理解对了吗？"一次交接可能带来两次反思，而一个任务可能有多次交接。

3. 路由开销（Routing Overhead）：Supervisor 每次决定把任务分给谁，都要读一遍所有 Worker 的能力描述、当前状态，然后做决策。Worker 越多，这个开销越大。

关于 token 膨胀的数学分析很有意思。在 AutoGen 的 GroupChat 模式中，总 token 消耗是 O(N × T²) 的量级——N 是 Agent 数量，T 是对话轮次 (dev.to)。这意味着对话越长，token 增长越快，不是线性的，是平方级的。

优化手段：

• 上下文压缩传递：不要把完整上下文传给下一个 Agent，只传必要的摘要信息
• 设置消息格式规范：用结构化的 JSON 替代自然语言传递信息，减少歧义也减少 token
• 限制对话轮次：设置硬上限和提前终止条件，防止无限循环
• 缓存机制：相同的查询结果可以缓存，避免重复计算

5.2 状态同步：失败不是因为不能通信，而是因为不能记住

单 Agent 系统中，状态就是上下文窗口本身——所有信息都在一个地方，不存在同步问题。

多 Agent 系统就不一样了。每个 Agent 都有自己的上下文、自己的记忆、自己对任务的理解。如果这些状态不同步，Agent 之间就会"鸡同鸭讲"。

MongoDB 在一篇关于多 Agent 记忆工程的文章中说得很到位：多 Agent 系统失败，往往不是因为 Agent 之间不能通信，而是因为它们不能记住 (MongoDB Blog)。

状态同步主要有三种模式：

1. 共享状态（Shared State）：所有 Agent 读写同一个中央状态存储（如数据库、黑板）。任何 Agent 更新了状态，其他 Agent 都能看到。

优点：一致性强，所有 Agent 看到的是同一份数据
缺点：并发写入冲突，状态设计不好会变成"大杂烩"

2. 消息传递（Message Passing）：Agent 之间通过发送消息来同步状态。没有中央存储，状态只存在于消息流中。

优点：松耦合，Agent 之间不需要知道对方的内部状态
缺点：消息可能丢失或延迟，最终一致性难以保证

3. 黑板模式（Blackboard Pattern）：一个共享的"黑板"作为中央信息区，Agent 可以在黑板上读写信息。Agent 通过观察黑板的变化来获取新信息。

优点：支持异步协作，适合逐步求解的问题
缺点：黑板结构设计困难，容易信息过载

MongoDB 的文章还提到了多 Agent 记忆工程的五个支柱：持久化架构、检索智能、性能优化、时间一致性、隐私与安全 (MongoDB Blog)。每一个展开都是一个工程领域，这里就不深入了。

5.3 共识达成：谁来拍板？

单 Agent 系统不需要共识——它自己就是决策者。

多 Agent 系统就不同了。当两个 Agent 意见不一致时，听谁的？当任务有多种执行路径时，选哪条？当结果不符合预期时，谁来决定是重试还是放弃？

这就是共识问题。常见的共识机制有：

1. 投票机制：少数服从多数。适合有多个独立 Agent 对同一问题做出判断的场景。

• 优点：简单直观，公平
• 缺点：可能出现"多数暴政"，如果大多数 Agent 都错了呢？

2. 优先级机制：不同 Agent 有不同的优先级，高优先级的意见优先。比如"技术专家 Agent"的技术判断优先级高于"产品经理 Agent"。

• 优点：专业的人做专业的判断
• 缺点：优先级定义困难，跨领域问题不好处理

3. 仲裁 Agent：专门设一个裁判/仲裁 Agent，负责在意见不一致时做最终裁决。Debate 模式就是这种。

• 优点：有明确的最终决策者
• 缺点：仲裁 Agent 成为新的单点瓶颈

4. 回退策略：如果无法达成共识，就降级处理——比如返回多个方案让用户选，或者回退到更保守的方案。

Cisco 的数据很残酷：在没有有效协调机制的情况下，只有约 36% 的多 Agent 讨论能最终达成共识 (Hello Marvis AI Today)。而通过引入协调协议（相当于 Supervisor + 明确的共识规则），这个比例可以提升到 93%。

这就是为什么 Supervisor 模式在生产环境中最受欢迎——它用一个明确的决策者换来了极高的共识达成率。

5.4 故障传播：一个 Agent 崩了，全系统陪葬？

单 Agent 系统中，故障是单点的——Agent 崩了就是崩了，重启就行。

多 Agent 系统中，故障会传播。一个 Agent 输出了错误的结果，下一个 Agent 基于这个错误结果继续工作，错误就像滚雪球一样越变越大。等到最终用户发现问题时，可能已经传了好几手，定位根因极其困难。

故障传播有几种典型模式：

1. 级联失败：A 失败 → B 基于 A 的错误结果继续失败 → C 也失败。多米诺骨牌效应。

2. 静默失败：某个 Agent 输出了错误结果，但没有任何错误标记。下游 Agent 继续处理，最终交付给用户一个看起来正常但实际错误的结果。这是最危险的。

3. 死锁/活锁：Agent A 等 Agent B 的结果，Agent B 等 Agent A 的结果，互相卡住。或者 Agent 之间不停地来回转发同一条消息，没有实质进展。

4. 礼貌螺旋（Polite Loop）：Agent 遇到无法解决的问题时，不是终止或上报，而是变得越来越"礼貌"和重复——"当然，我理解。让我根据那个考虑再试一次。"一轮又一轮，没有实质进展，却在持续消耗 token。多 Agent 系统中，这种现象会因 Agent 之间的"互相客气"而放大——两个被训练为乐于助人的 Agent 可能陷入无意义的致谢和澄清循环 (The Polite Loop Problem)。

应对这些故障，需要几类机制：

• 熔断机制：当某个 Agent 连续失败 N 次后，自动熔断，不再调用，改走降级路径
• 重试策略：区分可重试错误（网络超时）和不可重试错误（逻辑错误），合理设置重试次数和退避策略
• 结果校验：每个 Agent 的输出都要经过基本的格式校验和合理性检查，异常结果直接拦截
• 超时控制：每个 Agent 都有执行超时限制，防止无限等待
• 可观测性：完整的链路追踪，记录每个 Agent 的输入输出、耗时、token 消耗，出了问题能快速定位

Gartner 预测，到 2027 年，超过 40% 的智能体 AI 项目将因成本攀升、业务价值不清晰或风险管控不足而被取消 (Gartner 官方新闻稿)。这些失败的项目中，相当一部分就是因为故障传播和不可控的成本膨胀。

---

六、选型决策树

讲了这么多模式和挑战，你可能会问：到底怎么选？

以下决策树可帮助根据任务特征选择最合适的架构：

决策步骤详解

第一步：任务上下文能装进单个 Agent 吗？

这是第一个也是最重要的判断。如果通过合理的上下文管理（RAG、摘要、工具懒加载），单 Agent 的上下文能装下完成任务所需的所有信息，那就用单 Agent。

不要为了"技术先进性"而引入多 Agent——多 Agent 的系统复杂度成本是真实存在的。

第二步：子任务之间有强依赖关系吗？

如果子任务之间有明确的先后依赖（比如"必须先设计数据库，再写 API"），且依赖关系复杂，你可能需要 Hierarchical 模式——通过分层来管理复杂的依赖关系。

如果子任务相对独立（比如"分别调研三个竞品"），那就是 Supervisor 模式的甜点区。

第三步：需要多少个 Agent？

如果只需要 3-8 个子 Agent，Supervisor 模式是最优解。简单、稳定、易调试。

如果超过 8 个，单层 Supervisor 的上下文压力和决策质量都会下降，这时候应该考虑 Hierarchical 模式——把 Agent 分组，每组一个中层 Supervisor，顶层只管理几个中层 Supervisor。

第四步：任务需要多方辩论/多方案择优吗？

如果任务是高风险决策（金融、医疗、法律），错误代价比计算成本高得多，那应该考虑 Debate 模式。

如果任务是开放式的创意工作（头脑风暴、设计探索），且不需要严格的质量控制，可以尝试 P2P 模式——但要做好心理准备，它的可控性和效率都不如 Supervisor。

一句话总结：先试单 Agent，不行再 Supervisor，Supervisor 管不过来了再 Hierarchical。Debate 和 P2P 是特定场景的补充，不是主流选择。

---

七、多 Agent 的五个常见反模式

选型决策树解决了"要不要上多 Agent、选哪种模式"的问题。但即使选对了模式，实现过程中仍然有大量隐蔽的坑。以下五个反模式在实际项目中反复出现，每一个都足以让多 Agent 系统的效果反而不如单 Agent。

7.1 上下文雪球（Context Snowballing）

现象：Agent A 把完整上下文传给 Agent B，B 处理完后把自己的输出追加到上下文里再传给 C，C 再追加……到链路末端，上下文已经膨胀到原始输入的数十倍。

根因：没有做消息过滤和摘要，每个 Agent 都假设下游需要看到全部信息。实际上，下游 Agent 往往只需要前序结果的一小部分。

信号：链路末端 Agent 的输入 token 数是首个 Agent 的 5 倍以上；响应延迟随链路深度线性增长；LLM 开始"忽略"中间部分的指令。

解法：

• 每个 Agent 定义明确的输入契约，只传必要字段，不要透传整个对话历史
• 长链路上引入摘要节点，对前序结果做压缩后再传递
• 用结构化状态（如 StateGraph 的 State）替代自由文本传递，让每个 Agent 只读取自己关心的 key

7.2 Supervisor 瓶颈（Supervisor Bottleneck）

现象：Supervisor 既负责任务拆解，又负责任务分配，还负责结果验收、异常处理和进度汇报。每个 SubAgent 的结果回来后都要等 Supervisor 做一次决策，系统整体吞吐量被 Supervisor 锁死。

根因：把"需要全局视野的决策"和"可以本地化的决策"混在了一起。任务分配、结果汇总这类确定性工作不需要 LLM 参与，却被塞进了 Supervisor 的 prompt。

信号：Supervisor 的 token 消耗占系统总量的 40% 以上；端到端延迟中 Supervisor 推理时间占比过半；SubAgent 数量增加后系统性能不升反降。

解法：

• 确定性调度下沉到执行引擎（如 DAG 编排器），Supervisor 只在任务拆解和异常分支时介入
• 结果验收可以交给专门的评审 Agent 或规则引擎，不一定要 Supervisor 亲自做
• Supervisor 的 prompt 只保留"做什么"和"谁来做"，不包含"怎么做"的细节

7.3 并行幻觉（Fake Parallelism）

现象：架构图上画了多个 Agent 并行执行，实际运行时却在串行等待。用户看到的是"多 Agent 系统"，体验到的却是比单 Agent 更慢的响应。

根因：Agent 之间存在隐式依赖——B 需要 A 的某个中间结果，但这个依赖没有被显式声明，调度器只能保守地串行执行。或者使用了同步阻塞调用，一个 Agent 等待时整个线程挂起。

信号：多 Agent 版本的延迟比单 Agent 还高；CPU/网络利用率很低但任务耗时长；日志显示 Agent B 的开始时间晚于 Agent A 的结束时间，但两者在设计上本应并行。

解法：

• 用 DAG 显式声明任务依赖关系，让调度器自动发现可并行节点
• 异步非阻塞调用，Agent 等待时不占用线程
• 并行粒度要够粗——如果两个 Agent 只并行 2 秒但通信开销要 1 秒，不如串行

7.4 工具碎片化（Tool Fragmentation）

现象：为了让每个 Agent 看起来"各司其职"，把本来内聚的一组操作硬拆成多个工具，分给不同 Agent。结果一个简单的业务流程需要跨 3 个 Agent 传递 5 次消息，而单 Agent 调 3 个工具就能完成。

根因：把"多 Agent"当成了目标而不是手段。正确的做法是先设计工具和能力边界，再决定是否需要多 Agent；而不是先决定要多 Agent，再硬拆工具去凑数。

信号：Agent 之间的消息量远大于 Agent 调工具的次数；一个业务流程需要 4 次以上 Agent 间跳转；去掉某个 Agent 后流程反而更顺畅。

解法：

• 工具按业务能力聚合，不要按"谁来调"拆分
• 如果一组工具总是被连续调用，它们应该属于同一个 Agent
• 记住 CoderCops 的数据：约 70% 的"多 Agent"项目本质上只是单 Agent + 工具调用

7.5 过度拆分（Over-Decomposition）

现象："写接口的 Agent""写模型的 Agent""写测试的 Agent"各管一摊，结果一个需求同时涉及接口、模型和测试，三个 Agent 之间反复协调，沟通成本远超各自执行的成本。

根因：按技术职能拆分 Agent，而不是按上下文边界拆分。共享大量上下文的任务被分到了不同 Agent，导致信息反复传递和重复加载。

信号：SubAgent 数量超过 8 个但系统整体效率没有提升；Agent 间传递的上下文高度重叠；合并两个 Agent 后响应质量明显改善。

解法：

• 按"上下文边界"拆 Agent：如果两个任务需要理解相同的业务逻辑，它们应该在同一个 Agent 里
• 宁少勿多：先从 2-3 个 Agent 开始，确实遇到瓶颈再拆
• 拆分后做对比测试：多 Agent 版本必须在质量、效率或成本上有可量化的提升，否则回退

---

八、小结

多 Agent 不是银弹。它不是"单 Agent 的升级版"，而是一种在特定条件下才划算的架构选择。

回顾一下核心观点：

1. 单 Agent 有三堵墙：上下文墙（Lost in the Middle）、工具墙（选择越多越容易错）、并行墙（本质串行）。但这三堵墙不是一上来就会撞上的——大多数任务还没到那个程度。
2. 约 70% 的多 Agent 项目本可以简化为单 Agent + 优质工具（CoderCops 生产项目回顾数据）。在引入多 Agent 之前，先优化上下文管理、工具设计和规划策略。
3. 四种架构模式各有适用场景。Supervisor 模式是生产首选，Hierarchical 适合超大规模任务，P2P 适合开放式创意，Debate 适合高风险决策。
4. 多 Agent 有四个硬工程问题：通信成本（15x token）、状态同步、共识达成、故障传播。每一个都可能让你的系统翻车。
5. 五个反模式要提前规避：上下文雪球、Supervisor 瓶颈、并行幻觉、工具碎片化、过度拆分。选对模式只是第一步，避开这些坑才能让多 Agent 真正跑起来。
6. 选型的核心判断标准是：复杂度收益 > 系统复杂度成本。

最后再强调一次：能用单 Agent 就不要用多 Agent。 多 Agent 不是目的，而是手段。当你真的需要它的时候，它会给你带来巨大的价值；但当你不需要它的时候，它只会带来无尽的麻烦。

下一篇将进入多 Agent 编排的工程实现，拆解 Supervisor 如何拆解任务、DAG 引擎如何做波次调度、Agent 间通信如何设计。更多工程化实战细节，也可参考《AI Agent 工程化实战》系列。

有问题评论区见，欢迎交流~

---

参考资料

1. Liu et al., "Lost in the Middle: How Language Models Use Long Contexts", TACL 2024, https://arxiv.org/pdf/2307.03172
2. Vercel, "AGENTS.md outperforms skills in our agent evals", 2026-01, AGENTS.md outperforms skills in our agent evals - Vercel
3. CoderCops, "Building AI Agent Teams That Actually Work in Production", 2026-01, https://blog.codercops.com/blog/building-ai-agent-teams-production-2026/
4. Iterathon, "Multi-Agent Orchestration Economics: When Single Agents Win 2026", 2026-01, frontend
5. Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027", 2025-06-25, https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
6. geta.team, "The 'Polite Loop' Problem: Why Multi-Agent Systems Keep Thanking Each Other Instead of Working", 2026-03, The 'Polite Loop' Problem: Why Multi-Agent Systems Keep Thanking Each Other Instead of Working
7. Cisco Outshift, "Internet of Cognition for AI agents", 2026-07, Cisco's Outshift builds 'Internet of Cognition' for AI agents to coordinate without humans
8. MongoDB, "Why Multi-Agent Systems Need Memory Engineering", 2025-09, Why Multi-Agent Systems Need Memory Engineering | MongoDB
9. CallSphere, "The Context Window Challenge in Multi-Agent Systems", 2026-03, The Context Window Challenge in Multi-Agent Systems: Managing Token Explosion | CallSphere Blog | CallSphere Blog
10. 多智能体架构的5种经典模式, 2026-07, https://juejin.cn/post/7660702098418925610
11. LangGraph、CrewAI与AutoGen三大智能体框架深度对比, 2026-08, 【智能体框架】LangGraph、CrewAI与AutoGen三大智能体框架深度对比_crewai amp-CSDN博客
12. 别再盲目堆叠多Agent，AI应用架构拆分的实战决策指南, 2026-08,  别再盲目堆叠多Agent，AI应用架构拆分的实战决策指南-CSDN博客