《深入理解 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%0ppSkill 明确指令79%26ppAGENTS.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 SearchOpus 4.5 的准确率79.5%无 Tool Search→88.1%有 Tool SearchAnthropic 的解决方案是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这个概念这么火原因有三个概念性感多智能体协作听起来就比单 Agent 调工具要高级适合用来讲故事职责分离的思维惯性人类组织是多角色协作的工程师容易本能地想用同样的方式组织 AI回避工程优化与其花时间优化上下文管理和工具设计不如加个 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 失败不影响其他 WorkerSupervisor 可以重试或降级通信成本可控只有 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 模式就是值得的。四、四种模式对比总览维度SupervisorHierarchicalPeer-to-PeerDebate拓扑结构星型树型网状星型裁判中心控制方式中心协调分层协调去中心化裁判裁决通信复杂度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 OverheadSupervisor 每次决定把任务分给谁都要读一遍所有 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 PassingAgent 之间通过发送消息来同步状态。没有中央存储状态只存在于消息流中。优点松耦合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 LoopAgent 遇到无法解决的问题时不是终止或上报而是变得越来越礼貌和重复——当然我理解。让我根据那个考虑再试一次。一轮又一轮没有实质进展却在持续消耗 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 个子 AgentSupervisor 模式是最优解。简单、稳定、易调试。如果超过 8 个单层 Supervisor 的上下文压力和决策质量都会下降这时候应该考虑 Hierarchical 模式——把 Agent 分组每组一个中层 Supervisor顶层只管理几个中层 Supervisor。第四步任务需要多方辩论/多方案择优吗如果任务是高风险决策金融、医疗、法律错误代价比计算成本高得多那应该考虑 Debate 模式。如果任务是开放式的创意工作头脑风暴、设计探索且不需要严格的质量控制可以尝试 P2P 模式——但要做好心理准备它的可控性和效率都不如 Supervisor。一句话总结先试单 Agent不行再 SupervisorSupervisor 管不过来了再 Hierarchical。Debate 和 P2P 是特定场景的补充不是主流选择。七、多 Agent 的五个常见反模式选型决策树解决了要不要上多 Agent、选哪种模式的问题。但即使选对了模式实现过程中仍然有大量隐蔽的坑。以下五个反模式在实际项目中反复出现每一个都足以让多 Agent 系统的效果反而不如单 Agent。7.1 上下文雪球Context Snowballing现象Agent A 把完整上下文传给 Agent BB 处理完后把自己的输出追加到上下文里再传给 CC 再追加……到链路末端上下文已经膨胀到原始输入的数十倍。根因没有做消息过滤和摘要每个 Agent 都假设下游需要看到全部信息。实际上下游 Agent 往往只需要前序结果的一小部分。信号链路末端 Agent 的输入 token 数是首个 Agent 的 5 倍以上响应延迟随链路深度线性增长LLM 开始忽略中间部分的指令。解法每个 Agent 定义明确的输入契约只传必要字段不要透传整个对话历史长链路上引入摘要节点对前序结果做压缩后再传递用结构化状态如 StateGraph 的 State替代自由文本传递让每个 Agent 只读取自己关心的 key7.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 的升级版而是一种在特定条件下才划算的架构选择。回顾一下核心观点单 Agent 有三堵墙上下文墙Lost in the Middle、工具墙选择越多越容易错、并行墙本质串行。但这三堵墙不是一上来就会撞上的——大多数任务还没到那个程度。约 70% 的多 Agent 项目本可以简化为单 Agent 优质工具CoderCops 生产项目回顾数据。在引入多 Agent 之前先优化上下文管理、工具设计和规划策略。四种架构模式各有适用场景。Supervisor 模式是生产首选Hierarchical 适合超大规模任务P2P 适合开放式创意Debate 适合高风险决策。多 Agent 有四个硬工程问题通信成本15x token、状态同步、共识达成、故障传播。每一个都可能让你的系统翻车。五个反模式要提前规避上下文雪球、Supervisor 瓶颈、并行幻觉、工具碎片化、过度拆分。选对模式只是第一步避开这些坑才能让多 Agent 真正跑起来。选型的核心判断标准是复杂度收益 系统复杂度成本。最后再强调一次能用单 Agent 就不要用多 Agent。多 Agent 不是目的而是手段。当你真的需要它的时候它会给你带来巨大的价值但当你不需要它的时候它只会带来无尽的麻烦。下一篇将进入多 Agent 编排的工程实现拆解 Supervisor 如何拆解任务、DAG 引擎如何做波次调度、Agent 间通信如何设计。更多工程化实战细节也可参考《AI Agent 工程化实战》系列。有问题评论区见欢迎交流~参考资料Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL 2024, https://arxiv.org/pdf/2307.03172Vercel, AGENTS.md outperforms skills in our agent evals, 2026-01, AGENTS.md outperforms skills in our agent evals - VercelCoderCops, Building AI Agent Teams That Actually Work in Production, 2026-01, https://blog.codercops.com/blog/building-ai-agent-teams-production-2026/Iterathon, Multi-Agent Orchestration Economics: When Single Agents Win 2026, 2026-01, frontendGartner, 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-2027geta.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 WorkingCisco Outshift, Internet of Cognition for AI agents, 2026-07, Ciscos Outshift builds Internet of Cognition for AI agents to coordinate without humansMongoDB, Why Multi-Agent Systems Need Memory Engineering, 2025-09, Why Multi-Agent Systems Need Memory Engineering | MongoDBCallSphere, 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多智能体架构的5种经典模式, 2026-07, https://juejin.cn/post/7660702098418925610LangGraph、CrewAI与AutoGen三大智能体框架深度对比, 2026-08, 【智能体框架】LangGraph、CrewAI与AutoGen三大智能体框架深度对比_crewai amp-CSDN博客别再盲目堆叠多AgentAI应用架构拆分的实战决策指南, 2026-08, 别再盲目堆叠多AgentAI应用架构拆分的实战决策指南-CSDN博客
《深入理解 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%0ppSkill 明确指令79%26ppAGENTS.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 SearchOpus 4.5 的准确率79.5%无 Tool Search→88.1%有 Tool SearchAnthropic 的解决方案是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这个概念这么火原因有三个概念性感多智能体协作听起来就比单 Agent 调工具要高级适合用来讲故事职责分离的思维惯性人类组织是多角色协作的工程师容易本能地想用同样的方式组织 AI回避工程优化与其花时间优化上下文管理和工具设计不如加个 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 失败不影响其他 WorkerSupervisor 可以重试或降级通信成本可控只有 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 模式就是值得的。四、四种模式对比总览维度SupervisorHierarchicalPeer-to-PeerDebate拓扑结构星型树型网状星型裁判中心控制方式中心协调分层协调去中心化裁判裁决通信复杂度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 OverheadSupervisor 每次决定把任务分给谁都要读一遍所有 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 PassingAgent 之间通过发送消息来同步状态。没有中央存储状态只存在于消息流中。优点松耦合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 LoopAgent 遇到无法解决的问题时不是终止或上报而是变得越来越礼貌和重复——当然我理解。让我根据那个考虑再试一次。一轮又一轮没有实质进展却在持续消耗 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 个子 AgentSupervisor 模式是最优解。简单、稳定、易调试。如果超过 8 个单层 Supervisor 的上下文压力和决策质量都会下降这时候应该考虑 Hierarchical 模式——把 Agent 分组每组一个中层 Supervisor顶层只管理几个中层 Supervisor。第四步任务需要多方辩论/多方案择优吗如果任务是高风险决策金融、医疗、法律错误代价比计算成本高得多那应该考虑 Debate 模式。如果任务是开放式的创意工作头脑风暴、设计探索且不需要严格的质量控制可以尝试 P2P 模式——但要做好心理准备它的可控性和效率都不如 Supervisor。一句话总结先试单 Agent不行再 SupervisorSupervisor 管不过来了再 Hierarchical。Debate 和 P2P 是特定场景的补充不是主流选择。七、多 Agent 的五个常见反模式选型决策树解决了要不要上多 Agent、选哪种模式的问题。但即使选对了模式实现过程中仍然有大量隐蔽的坑。以下五个反模式在实际项目中反复出现每一个都足以让多 Agent 系统的效果反而不如单 Agent。7.1 上下文雪球Context Snowballing现象Agent A 把完整上下文传给 Agent BB 处理完后把自己的输出追加到上下文里再传给 CC 再追加……到链路末端上下文已经膨胀到原始输入的数十倍。根因没有做消息过滤和摘要每个 Agent 都假设下游需要看到全部信息。实际上下游 Agent 往往只需要前序结果的一小部分。信号链路末端 Agent 的输入 token 数是首个 Agent 的 5 倍以上响应延迟随链路深度线性增长LLM 开始忽略中间部分的指令。解法每个 Agent 定义明确的输入契约只传必要字段不要透传整个对话历史长链路上引入摘要节点对前序结果做压缩后再传递用结构化状态如 StateGraph 的 State替代自由文本传递让每个 Agent 只读取自己关心的 key7.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 的升级版而是一种在特定条件下才划算的架构选择。回顾一下核心观点单 Agent 有三堵墙上下文墙Lost in the Middle、工具墙选择越多越容易错、并行墙本质串行。但这三堵墙不是一上来就会撞上的——大多数任务还没到那个程度。约 70% 的多 Agent 项目本可以简化为单 Agent 优质工具CoderCops 生产项目回顾数据。在引入多 Agent 之前先优化上下文管理、工具设计和规划策略。四种架构模式各有适用场景。Supervisor 模式是生产首选Hierarchical 适合超大规模任务P2P 适合开放式创意Debate 适合高风险决策。多 Agent 有四个硬工程问题通信成本15x token、状态同步、共识达成、故障传播。每一个都可能让你的系统翻车。五个反模式要提前规避上下文雪球、Supervisor 瓶颈、并行幻觉、工具碎片化、过度拆分。选对模式只是第一步避开这些坑才能让多 Agent 真正跑起来。选型的核心判断标准是复杂度收益 系统复杂度成本。最后再强调一次能用单 Agent 就不要用多 Agent。多 Agent 不是目的而是手段。当你真的需要它的时候它会给你带来巨大的价值但当你不需要它的时候它只会带来无尽的麻烦。下一篇将进入多 Agent 编排的工程实现拆解 Supervisor 如何拆解任务、DAG 引擎如何做波次调度、Agent 间通信如何设计。更多工程化实战细节也可参考《AI Agent 工程化实战》系列。有问题评论区见欢迎交流~参考资料Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL 2024, https://arxiv.org/pdf/2307.03172Vercel, AGENTS.md outperforms skills in our agent evals, 2026-01, AGENTS.md outperforms skills in our agent evals - VercelCoderCops, Building AI Agent Teams That Actually Work in Production, 2026-01, https://blog.codercops.com/blog/building-ai-agent-teams-production-2026/Iterathon, Multi-Agent Orchestration Economics: When Single Agents Win 2026, 2026-01, frontendGartner, 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-2027geta.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 WorkingCisco Outshift, Internet of Cognition for AI agents, 2026-07, Ciscos Outshift builds Internet of Cognition for AI agents to coordinate without humansMongoDB, Why Multi-Agent Systems Need Memory Engineering, 2025-09, Why Multi-Agent Systems Need Memory Engineering | MongoDBCallSphere, 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多智能体架构的5种经典模式, 2026-07, https://juejin.cn/post/7660702098418925610LangGraph、CrewAI与AutoGen三大智能体框架深度对比, 2026-08, 【智能体框架】LangGraph、CrewAI与AutoGen三大智能体框架深度对比_crewai amp-CSDN博客别再盲目堆叠多AgentAI应用架构拆分的实战决策指南, 2026-08, 别再盲目堆叠多AgentAI应用架构拆分的实战决策指南-CSDN博客
