上个月我在后台看到一条留言问的是“为什么我们团队把 Agent 从 3 个加到 30 个交付速度反而变慢了” 这个问题我太熟了——我们自己就踩过一个更深的版本早期在某条业务链路里Agent 数量翻了几倍之后线上任务的平均完成时间非但没有缩短反而增加了将近一倍。当时大家的第一反应都是模型不够强换更强的模型、调更高的上下文上限结果没多大用。后来静下来把调用链拆开逐段分析才意识到问题根本不在单个 Agent 的“智力”而在工程侧对多 Agent 协作的组织方式。这篇文章想把这些踩过的坑一次说透为什么 Agent 一多效率反而不升反降哪些瓶颈是必然会出现的哪些其实是设计失误造成的以及我们后来用什么手段把这个问题逐步控制住。内容会贴近真实生产环境那些“看起来能跑”的 Demo 里发现不了的细节很多得靠线上数据才能暴露。如果你已经过了“跑通单个 Agent”的阶段开始尝试让多个 Agent 协作完成任务这篇应该能帮你少走不少弯路。1. 效率衰减的根源拆解为什么理论上的并行没有兑现1.1 非线性增长的沟通成本先说最根本的数学模型。假设一个任务被拆给 N 个 Agent 协作完成每个 Agent 之间需要两两同步状态和信息那么需要管理的连接数就是 N×(N-1)/2。当 N 从 3 变成 10连接数从 3 变成 45当 N 变成 30连接数是 435。这是 O(N²) 的增长而单 Agent 的吞吐能力基本是线性的甚至还会因为上下文变长而下降。这个曲线在真实系统里会转化为一种肉眼可见的“协调税”——每一个 Agent 都要等待其他 Agent 的输出、验证中间结果、处理状态冲突这些等待时间不会让模型跑得更快反而会把本来就有限的推理时间切成碎片。我见过一个典型的案例某个任务本来单个 Agent 能干完硬拆成 5 个 Agent 并行做结果因为反复同步和校正总耗时翻了 3 倍。所以第一个要记住的公式是Agent 的数量增加一倍协调成本可能变成原来的四倍而不是两倍。1.2 注意力机制与上下文窗口的隐性消耗很多人忽略的是多个 Agent 协作时上下文窗口变成了一种共享但极其稀缺的资源。每个 Agent 都要把自己负责部分的背景信息写进上下文还要读取其他 Agent 的输出摘要这部分 token 的膨胀速度非常惊人。我见过一个实际数据在某个 8-Agent 的任务链里因互相传递上下文token 总量比单 Agent 方案多了 5 倍其中很多是重复的背景介绍和状态描述。更麻烦的是大模型的注意力机制对长上下文的利用不是均匀的——相关研究表明中间位置的信息最容易被忽略这个现象常被俗称为“lost in the middle”。当多个 Agent 的输出挤在同一段上下文里关键决策点往往被淹没在中间位置模型会做出错误的加权判断。这不是换个更强的模型就能解决的它本质上是信息组织和压缩的问题。我们后面会上上下文固化与裁剪机制就是为了对抗这个注意力损耗。1.3 单点依赖与木桶效应多 Agent 系统的整体吞吐不是由最快那个 Agent 决定的而是由最慢的那个决定。这句听起来像废话但实际操作中极容易被忽视。Agent 们共享底座模型服务的并发上限每个 Agent 内部还有多轮工具调用只要有一个环节出现高延迟重试或排队后面所有的 Agent 都会陷入等待。我在一次复盘中发现一条 12 个 Agent 的并行链路里其中有 2 个 Agent 承担了约 70% 的任务量它们在反复调用同一个外部接口而这个接口单次响应时间超过 5 秒。结果整个系统完成率看起来不错但延迟的可达性已经崩了。简单说加 Agent 之前得先想清楚有没有能力给它们做负载协调否则加得越多越是在排队链上叠砖头。2. 实操中常见的效率杀手四个大家都会踩的场景2.1 群体踩踏式的失败重试多 Agent 系统最容易被忽视的稳定性问题是“重试风暴”。单个 Agent 在调用外部工具或模型接口时遇到超时或失败会选择重试这个机制本身没问题。但当多个 Agent 共享同一个薄弱服务且彼此之间的任务有顺序依赖时某一个服务的抖动会被层层放大。A 重试B 等待 A 的结果所以也拉长C 因为 B 超时也开始重试……最后看起来就像是所有 Agent 都在疯狂重试系统吞吐跌到接近 0。我们踩过的一次典型事故是这样的某个 Agent 调用一个数据库接口这个接口偶发 2 秒的慢查询本来不至于出大问题。但因为下游有 5 个 Agent 都依赖这个接口返回的数据它们各自启动了自己的超时重试逻辑等慢查询过去后接口瞬间收到 5 倍的重试请求直接被打垮。之后整个任务链持续失败了接近 40 分钟。后来我们定了一条硬规则所有重试必须加指数退避和随机抖动且每个任务链必须有全局重试总次数上限。2.2 上下文漂移带来的信息失真上下文漂移这个词可能听着陌生但现象大家一定见过一个 Agent 在执行任务时原本应该参考的信息被新信息挤掉了或者它记住了早期错误的中间结果后续整个流程跟着错下去。多个 Agent 协作时这个问题的概率会成倍上升因为每个 Agent 都会改写上下文信息在 Agent 之间传递时会发生“损耗失真”。举一个实际例在某个文档处理任务里Agent A 负责提取原始数据Agent B 负责数据修正Agent C 负责生成报告。A 在提取时漏掉了一条数据B 没意识到缺失直接在修正后的数据集上做了计算C 基于计算结果输出了报告。最终报告看起来完整但里面已经有一处隐性错误而且很难追溯是哪一步丢的。整个系统缺少“不变量校验”机制这样的错误就会成为常态。我们的解决方式是在关键节点插入数据校验 Agent专门负责核对上游输出是否完整这种“冗余”反而是保证系统可信度最必要的投入。2.3 工具调用链的饿死与死锁工具调用是 Agent 干活的手脚但多 Agent 环境下工具调用很容易发生饿死或死锁。饿死的典型场景是多个 Agent 排队等待同一个被占用的工具资源但由于等待队列太长部分 Agent 被饿死——不报错也不执行就是干等。死锁则更隐蔽Agent A 需要 Agent B 的输出才能继续Agent B 又在等待 Agent A 的另一个中间结果两边互相等待没有任何一个会主动退出。我在排查线上任务时遇到过典型的死锁现象任务状态卡在“运行中”但实际已经没有任何 Agent 在推进日志里只看得到两个 Agent 在反复转发空状态。这个问题的根因在于Agent 之间的依赖没有设计成有向无环图而是一个回环。后来我们给所有编排层加了依赖检测一旦检测到循环依赖直接中断任务并报警宁可失败重跑也不能卡死浪费资源。2.4 重复劳动与无效计算多 Agent 系统的另一个隐性浪费是重复劳动。表面上看有不同的分工但落到具体执行时几个 Agent 常常在做同一件事只是各自带着不同的参数和上下文。比如多个 Agent 各自维护一份相同的状态快照、各自重新调用同一个数据接口、各自做同一段文档解析。这种重复不是 bug而是任务分配粒度过粗的结果。系统设计者把职责划分成“A 管数据、B 管校验、C 管报告”但实际执行时每个 Agent 都需要访问原始数据来完成自己的部分于是同样的读取和解析被重复执行了三遍。修复方式是在编排层做结果复用建立一个共享的中间结果缓存谁需要谁去取而不是谁都要重新算一遍。这一步做完之后我们某条链路的 token 消耗直接下降了 40%。3. 用数据说话如何定位效率瓶颈的根因3.1 从“凭感觉”到“可量化”的诊断路径遇到多 Agent 效率衰减的问题第一步要做的是画现状拓扑图把每个 Agent 的输入、输出、依赖工具、上下游关系全部梳理出来。拓扑图不用追求美观但必须能回答三个问题每个 Agent 在等什么每个 Agent 产出的东西被谁消费哪个环节是可以并行但实际串行的画完拓扑图就该上埋点数据。每个 Agent 至少需要记录四个指标单次调用耗时包括模型响应时间和工具响应时间、token 消耗量输入 输出、重试次数、等待时间。这组数据不需要复杂的 APM 系统简单的日志聚合就能跑起来。重点不是收集而是看分布——我建议按 P50、P95、P99 三个分位去切分而不是看平均值因为平均值会把偶发拖慢和常态慢混在一起导致误判。3.2 四个关键指标配置监控前先看懂它们指标定义异常信号常见根因等待时间占比Agent 等待上游或工具返回的时间 / 总耗时大于 60%串行依赖过多或外部接口过慢重试率重试次数 / 总调用次数大于 10%接口不稳定或并发超限Token 重复率多个 Agent 重复读取相同内容的 token / 总 token大于 30%缺乏中间结果缓存与共享上下文命中率关键指令在最终决策中的保留程度可抽样评估低于 70%中间层信息压缩过度注意力偏移这四个指标的厉害之处在于它们能帮我们把“感觉不对”的症状翻译成具体的工程问题。比如你看到一个任务链整体很慢但每个 Agent 的模型推理时间都不高那么问题大概率在等待时间占比上——说明编排结构有问题如果你看到重试率高那就得去查外部依赖的健康度而不是一味优化 prompt。3.3 分段计时法半小时内定位瓶颈我自己最常用的定位手段是分段计时。把整个任务链切成几段接收输入、规划拆分、Agent 间同步、外部工具调用、结果合并、输出生成然后在每一段标记时间戳。这个方法听起来土但比任何 profiling 工具都好使。比如有一次排查一个 8-Agent 任务链发现整体耗时 120 秒单看模型推理只花了 30 秒剩下的 90 秒都耗在了“同步”上。顺着时间戳找到最大的同步阻塞点发现是两个 Agent 在循环等待同一个外部接口的返回而接口本身只有 2 秒的响应时间——问题是它们的调用时间段完全错开了等于一个干等另一个释放连接。最后把调用顺序从串行改为并行总耗时直接从 120 秒降到了 45 秒。很多时候慢的根本不是算力而是编排逻辑。4. 落地方案给多 Agent 系统装上“效率护栏”4.1 控制单链 Agent 数量为什么“越少越好”是硬规则在排查完所有问题后我们最终总结出一条反常识的经验单条任务链里的 Agent 数量最好控制在 5 个以内。不是说不能超过 5而是超过 5 之后要做到同样的效率需要投入的工程治理成本会急剧上升。这里有一个经验公式可以分享假设单个 Agent 在理想状态下的处理能力是 1它能拿到的有效上下文比例约等于 0.7因为有注意力损耗和上下文膨胀那 5 个 Agent 协作的总有效输出大约是 3.5但因为协调成本和传递损耗要打一个约 0.6 的折扣实际只有 2.1——可能还不如把任务给 2 个更强的 Agent让它们专注完成各自的部分来得高效。所以我们在设计任务拆分时会先问一个问题这个 Agent 是否是必需的如果删掉它让另一个 Agent 多走一步能否覆盖大多数时候答案是能。4.2 层级编排与专注化设计多 Agent 效率问题的另一条解药是把“平级协作”改成“层级编排”。平级协作是 30 个 Agent 互相商量谁先做谁后做什么都靠模型自己判断层级编排则是引入一个主控制 Agent它不负责具体干活只负责任务拆分、结果验收、异常分发。业内通常会把这个角色称为“规划器”或“调度器”。主控制 Agent 的意义在于它将原本的 O(N²) 沟通成本降成了 O(N)。因为每一个执行 Agent 只需要跟主控制 Agent 沟通不需要两两之间建立连接。实际使用中这个主控制 Agent 的模型能力不需要比执行 Agent 强很多反而更看重它的指令遵循和结构化输出能力因为它主要的产出是一份机器可读的任务清单而不是长篇大论。我们目前的实践是把主控制 Agent 的任务清单定义成严格 JSON 结构里面包含每个执行 Agent 的输入路径、目标描述、依赖输出、完成标准。执行 Agent 之间的数据交换不直接进行全部通过一个共享缓冲区中转。这个模式让系统变稳了很多即使某个 Agent 挂了主控制也能快速感知并把任务分给备用 Agent而不是像平级协作那样整条链等一个超时。4.3 上下文固化与压缩策略上下文管理是让多 Agent 系统持续高效的关键。我们总结了一套“三明治”策略固定顶部和底部、压缩中间。固定顶部是指在系统提示词里放一份“不变量”区块里面写死任务的终极目标、关键约束、行业常识这块内容不允许任何 Agent 改写。压缩中间是指 Agent 之间传递上下文时不要直接丢原始输出而是先用一个小模型做结构化提取——只保留实体、决策、结论和必需的过程数据丢弃寒暄和重复内容。固定底部则是让最新的执行状态和待办列表保持在上下文的末尾方便模型在生成时优先“看到”它们。这套策略实测下来8-Agent 场景的 token 消耗减少了 55%任务成功率反而提升了接近 20%。原理很简单模型在上下文有限的情况下越是重要的信息越需要被放在它更容易注意到的位置。上下文固定和裁剪本质上是在帮模型做注意力管理。4.4 引入结果缓存与任务去重结果缓存听起来像老生常谈但在 Agent 系统里特别容易被遗漏。原因是大家默认 Agent 是“有状态的智能体”每次输出都是新的不做缓存。但实际上很多 Agent 的工具调用是对同一份数据源的重复读取缓存的价值极高。我们实现了一个中间结果缓存层以工具调用参数为 key以返回结果为 value。任何一个 Agent 要调用工具时先查缓存命中就直接用不命中才发起真实调用。这个在数据读取类任务里收益最大实测某些链路里缓存命中率能达到 60% 到 70%整体响应时间减半。再配合任务去重也就是在任务分配前检查这个子任务是不是已经由其他 Agent 完成过如果完成过而且结果可用直接复用结果就不需要再派一个新的 Agent 去做了。这两招组合用下来脏活累活少了很多效率自然也就上来了。5. 常见问题速查效率衰减的快速排查清单症状可能原因排查手段应对策略任务整体耗时拉长但单个 Agent 推理时间正常串行依赖过多等待时间占比高查看每个 Agent 的等待时间统计调整依赖关系改为并行或异步模型频繁给出“已放弃”或“错误”结果上下文被中间信息淹没关键指令漂移检查上下文固化情况抽样阅读最终决策前的上下文压缩中间层内容固定顶部关键信息外部接口 QPS 暴涨部分请求超时多个 Agent 重复调用同一接口且重试无退避看工具调用日志统计相同参数的调用次数加缓存加全局限流与退避重试某几个 Agent 很闲其他几个忙不过来任务分配粒度不均负载不均衡查看各 Agent 的执行任务量和耗时分布细化任务拆分或改用动态分配链路的 token 消耗涨得离谱上下文重复传递缺乏压缩机制统计 token 消耗占比找重复度最高的段落增加结构化提取与裁剪层这套速查表在我们内部是贴墙的排查问题的时候直接按症状对号入座能省掉很多靠猜的时间。如果你正被某一个多 Agent 场景折磨可以先从表格的第一行开始查绝大多数效率问题都逃不开“等待时间占比过高”这一个根因。6. 一些值得内化的原则说到底多 Agent 不是越多越好而是一个需要精细治理的工程系统。我们团队现在设计任何一条 Agent 链路都遵循三条硬原则一是单链不超过 5 个执行 Agent二是所有交互走结构化数据不走自然语言三是每个环节都有可量化的监控指标不允许出现不可观测的隐性环节。这三条看着简单但每一条都是用线上事故换来的教训。我们后来在复盘那起“3 个加到 30 个效率反而下降”的问题时得到的最深的体会是加 Agent 之前先想想这些 Agent 之间要怎么说话、怎么避免重复劳动、怎么共享信息。如果这些问题想不清楚加多少 Agent 都只是在放大混乱而已。真正高效的系统往往不是 Agent 最多的而是每个 Agent 都清楚自己该干什么、做完之后该把结果交给谁的。现在每当我听到“多加几个 Agent 就能提效”的说法都会忍不住提醒一句冷启动跑通一个 Agent 很容易但把 30 个 Agent 组织成一支高效队伍难的是工程不是模型。如果你现在也卡在“加了 Agent 反而更慢”的困境里建议先别急着换更大的模型回到拓扑图和监控数据上看一看大概率能找到比模型更值得优化的瓶颈。等这轮梳理做完再回头看看是不是真的需要那么多 Agent也许会有完全不一样的答案。