多Agent协作成本失控：一个单任务拆分反例的深度复盘

一直听到的都是“多 Agent 团队协作如何强”今天我来讲一个相反的案例。我们把自己一个本来好好的单 Agent 任务拆成三个 Agent 协作结果耗时变成原来的 32 倍Token 消耗涨到 13 倍最后输出质量还肉眼可见地变差了。这不是理论推演是我们实打实跑过的一个多 Agent 团队协作反例。我会把整个过程、每个环节的 Token 变化、时间花在哪、为什么结果会更差全部拆开来讲顺便给出排查思路和后续改法希望帮大家少踩这个坑。先说明背景这不是某个特殊场景才有的偶然现象而是多 Agent 系统中非常典型的“协作成本失控”。你越是想让 Agent 之间互相检查、互相补全系统就越容易陷入上下文混乱、重复劳动和无效协调。这不是说多 Agent 方案不能做而是说很多人低估了协作本身的代价。这篇文章适合正在做 Agent 编排、正在评估要不要把一个单体任务拆成多 Agent 的人看。1. 这个反例到底反在哪一个看似合理的任务如何跑出 32 倍时间和 13 倍 Token1.1 原始需求与改造动机先说任务本身。我们有一个半结构化的数据清洗与标准化流程输入是几十份格式不统一的文档需要从中抽取关键字段统一枚举值再生成结构化表格。这个任务在改造前是单 Agent 完成的效果其实不差准确率大概 92%单次跑完大约 5 到 8 分钟Token 消耗稳定在 4 万到 6 万之间。当时我们想优化的是两个点第一部分字段抽取的准确率不够稳定第二希望引入一个“质量检查”环节让结果更可控。基于这两个诉求团队做了一个很直觉的决策把任务拆成三个角色分别是抽取 Agent、标准化 Agent、审核 Agent。抽取 Agent 负责从原文定位原始字段标准化 Agent 负责把措辞统一成规范枚举值审核 Agent 负责最后把关。这个设计听起来非常合理分工、质检、回归闭环都有了。按常规预期增加一个审核角色准确率应该从 92% 提升到 96% 以上耗时多 30% 以内Token 多 50% 左右。但实际跑出来的结果和预期差了不止一个数量级。1.2 改造后的实测数据对比改造后的组合采用了典型的串联模式抽取 Agent 输出原始抽取结果标准化 Agent 拿到结果后做映射审核 Agent 再对最终结果做一致性校验。为了降低单次失败的概率每个 Agent 都配置了 retry 机制最多重试三次并且每一步的结果都会写回一个共享上下文方便后续 Agent 引用。实测五组任务的数据指标单 Agent 基线三 Agent 协作版变化倍数平均耗时6.4 分钟205 分钟32 倍Token 消耗4.8 万62.4 万13 倍字段准确率92%88%-4%完整通过率100%60%-40%最讽刺的是准确率不升反降。我们以为加了一个审核角色可以让结果更稳结果审核 Agent 在多个字段上误判了正确结果导致抽取 Agent 反复重新执行最终产出了一份“被多次修改后的妥协版本”反而把原本正确的值改错了。这组数据一下子把所有问题暴露出来时间主要卡在重试和审核退回上Token 主要烧在重复读取上下文和冗余推理上。要理解为什么多 Agent 反而不如单 Agent先得搞明白上下文是怎么被复制和污染的。2. 成本爆炸的四个“元凶”从上下文复制到无效协调2.1 共享上下文变成“每个 Agent 的完整行李箱”多 Agent 协作最常见的实现是把一个共享上下文传给所有 Agent每个 Agent 都能看到历史消息、其他 Agent 的中间输出、当前任务描述。单 Agent 模式下上下文里只有原始文档和一次推理链多 Agent 模式下上下文被反复拼接。举个例子抽取 Agent 第一次输出 8000 Token 的抽取结果标准化 Agent 读取时输入由三部分组成系统提示 2000 Token、原始文档 30000 Token、抽取结果 8000 Token。标准化 Agent 输出 5000 Token 后审核 Agent 又要读前面的全部内容此时上下文变成系统提示 2000、原始文档 30000、抽取结果 8000、标准化结果 5000再加上审核自己的指令可能直接到 5 万 Token。这还只是一轮。只要审核不通过抽取 Agent 重跑时又要把之前所有内容载入一次。上下文呈现指数级叠加Token 成本自然膨胀。更关键的是每个 Agent 都会在上下文中看到其他 Agent 的中间推理这些推理并不都是有效信息反而占用了宝贵的上下文空间干扰注意力。我们在排查时做了一个统计整个过程中真正被最终结果用到的 Token 只占 18%其余 82% 都是中间传递、重复摘录、纠错重新分析产生的冗余信息。你可以理解成一个团队开会每个人发言前都把整份会议纪要念一遍然后再说自己的观点。2.2 “审核—重做”循环会产生雪球效应三 Agent 串联模式最大的隐患是审核 Agent 有极大的“退回权力”。审核 Agent 一旦判断某字段不合格就会把整个任务退回给上游 Agent。上游 Agent 收到退回后不是只修一个字段而是经常把全部输出重新生成一遍。实测中五组任务里有三组都出现过至少一轮完整退回。最极端的一组任务跑了四轮完整循环每一轮 Token 消耗都在 12 万到 18 万之间。由于每个 Agent 重跑时会把之前的结果合并进上下文第四轮的 Token 消耗比第一轮高出接近一倍。这就是雪球效应审核退回导致重跑重跑导致上下文膨胀上下文膨胀导致模型注意力分散注意力分散导致更可能出错出错又触发新一轮退回。整个系统不是收敛的而是发散的。我后来反思审核 Agent 不应该直接退回并要求重跑而应该在结果旁边标注具体修改点。但当时的设计是把“发现错误”和“修正错误”的责任都强行按在抽取 Agent 头上导致系统形成了一种低效的返工闭环。2.3 角色分工反而破坏了问题所有权单 Agent 模式下模型对整个任务有完整的所有权它知道要抽字段、要做标准化、也要保证输出格式正确所以会在一次推理里做出全局权衡。多 Agent 模式下每个 Agent 只负责链条上的一个环节反而丢失了全局视角。问题最明显的是标准化 Agent。它在处理某些字段时会按照自己的理解修改抽取结果导致与原始文档产生偏差。审核 Agent 审核的是标准化后的结果如果标准化结果本身有问题审核 Agent 会有两种表现一是误把错误当正确放过去二是发现不了问题直接通过。但我们这个案例里更常见的是第三种审核 Agent 察觉结果“哪里不对”但又说不出具体怎么改于是以“缺少必要字段”为由退回逼迫抽取 Agent 重新执行。这个过程中没有一个 Agent 真正对“最终交付物的一致性”负责。每个人都在做局部优化最终结果却全局变差。这就是角色分工的悖论你以为明确职责能让系统更可靠实际是一旦协作协议不完善职责切分反而会制造责任真空地带。2.4 无效协调和管理开销被严重低估除了任务本身的 Agent 外我们还在外层加了一个简单的调度器用来决定消息路由、记录任务状态、控制重试次数。调度器本身不直接处理数据但它每轮都要读取上下文判断当前状态生成下一步指令。五个任务跑下来调度器产生的 Token 占总消耗的 21%。这不是说调度器不能加而是说多 Agent 架构里协调层本身就是一个成本中心。如果你用更弱的模型做调度可能省 Token 但容易误判状态用强模型做调度Token 消耗会非常可观。我们当时为了稳定给调度器用了和任务 Agent 同级别的模型调度器的 Token 消耗和任务 Agent 基本持平。这还没算时间上的开销。每次 Agent 调用之间都有网络请求、排队、模型推理时间。单 Agent 一次推理只需要 30 秒左右多 Agent 一轮串联就需要 3 到 5 分钟。尤其是审核 Agent 的推理时间比抽取 Agent 还长因为它要处理的信息量更大。整个系统的延迟被叠加不是简单相加而是每条消息都要经过更多层的处理和等待。3. 实操现场回放一个 205 分钟的失败案例全记录3.1 初始拆分与系统提示设计为了让这个反例可复现我把我们当时的关键配置列出来。三个 Agent 的系统提示分别是这样的虽然不能贴完整原版但核心结构一致抽取 Agent要求从文档中定位指定字段输出 JSON 格式的原始抽取结果。系统提示里包含了所有字段定义、格式要求、示例。提示特别强调“如果发现字段缺失必须标注为 missing”。标准化 Agent要求把抽取结果中的字段值映射到统一枚举值如果遇到未覆盖的值需要添加自定义标准化结果。审核 Agent要求检查抽取结果和标准化结果是否一致、是否存在缺失字段、字段值是否符合枚举定义。一旦发现问题需要退回给上游 Agent 修改。调度器则维护一个任务队列记录当前步骤、剩余重试次数并把每一步 Agent 的输出追加到共享上下文。调度器的逻辑很简单先抽取再标准化最后审核审核不通过就回退到抽取阶段。这个设计的问题在第一步就埋下了。抽取 Agent 和标准化 Agent 的字段定义有细微差异抽取 Agent 的输出里有一个字段叫 report_date标准化 Agent 期望的是 date而且审核 Agent 同时引用了两套字段名导致每次审核都会因为字段名不匹配而报错。3.2 第一次失败循环从标准化到审核再到重抽我们看其中一组任务的时间线。任务开始时调度器先把 30 万字符的原始文档和一些任务说明传给抽取 Agent。抽取 Agent 第一次返回结果耗时 4 分钟输出 7600 Token字段基本齐全准确率按我们后来人工核验大概有 90%。标准化 Agent 拿到抽取结果后耗时 3 分钟输出 5400 Token。它把大部分字段映射到了枚举值但是 report_date 这个字段它没找到因为抽取 Agent 输出的是 report_date而标准化 Agent 期望的是 date。它没有直接重新映射而是把 report_date 保留并加了一条“需要人工确认”的备注。审核 Agent 拿到标准化结果后耗时 5 分钟输出 3200 Token。它发现两个问题第一date 字段缺失因为标准化 Agent 没有生成 date第二report_date 字段缺少标准化映射。于是审核 Agent 判定不合格返回给调度器调度器触发重试。这里第一次重试时抽取 Agent 再次读取的上下文已经包含了抽取结果、标准化结果和审核反馈。它重新执行了抽字段操作结果它没有意识到问题只出在字段名映射上又把所有字段重新抽了一遍输出 8200 Token比第一次还长。标准化 Agent 第二次收到抽取结果后上下文里已经有三份重复的抽取结果它的输出也膨胀到了 7100 Token。审核 Agent 第二次审核时发现 date 字段依旧缺失再次退回。这个循环整整重复了三次每次上下文都比前一次更大Token 消耗曲线像爬楼梯一样攀升。3.3 第四次循环后的最终结果有多离谱第四次循环后整个流程消耗了约 42 万 Token耗时 149 分钟。审核 Agent 在第四次实际上已经“妥协”了它没有再退回而是直接通过了结果。但通过的原因不是结果达标了而是它在超长上下文中丢失了早期检查项的注意力认为当前版本已经涵盖了之前指出的所有问题。我们把最终输出和单 Agent 基线结果做对比发现两个严重问题。第一report_date 的值在前三次循环中本来是对的但是标准化 Agent 在第二次循环时把格式从 2024-08-11 改成了 2024/08/11而审核 Agent 没有发现这个改动不符合输出规范最终结果里就带着错误的日期格式。第二由于多轮循环后上下文里塞满了重复的抽取结果抽取 Agent 在后续循环里出现了幻觉现象在最终结果里塞进来一个原文里根本不存在的字段“source_version”。人工核对时发现这个字段根本不在原始文档中。单 Agent 版本从来没出现过这种问题。这个案例非常典型多 Agent 不是简单地把几个模型串起来每一步都会引入新的误差源而且误差会在循环中放大。最终输出准确率从 92% 降到 88%其中至少有 2 个百分点的下降就是因为这种反复修改和上下文污染造成的。3.4 Token 到底花在了哪里我把这组的 Token 消耗做了详细拆解按 Agent 和轮次统计。第一轮消耗 11.2 万 Token其中抽取 4.2 万、标准化 3.6 万、审核 2.4 万、调度器 1 万。第二轮因为上下文里多了一份完整的抽取结果和标准化结果消耗直接跳到 15.8 万。第三轮 18.7 万。第四轮 21.3 万。这个拆解说明一个反直觉的事实真正的原始文档读取只占第一轮后续几轮的大头都是重复读取之前 Agent 生成的中间结果。也就是说系统的 Token 成本不是在读“新信息”而是在反复搬运“历史垃圾”。如果早一点意识到这一点我们可以在标准化 Agent 里做一个简单处理只要求它读取抽取结果中新增的字段映射关系而不是读取全部上下文。但当时的实现为了方便把所有 Agent 都接入了同一个共享上下文这个教训非常深刻。4. 问题排查实录从数据中发现根因的四步法4.1 第一步先看“分支回退率”而不是只看最终准确率我们刚开始排查时只盯着准确率看发现 88% 比基线低但也说不清低在哪。后来我们把所有 Agent 的执行日志拿出来统计每一步的退回比例才发现标准化 Agent 的退回率高达 70%审核 Agent 的退回率也有 63%。这个数据说明整个流水线基本处于“大部分时间在重跑”的状态。建议大家在排查多 Agent 系统时一定要记录每一步的执行状态、退回原因、重试次数。最终结果准确率只能反映结果无法反映过程而多 Agent 系统的病根往往出在过程上。我们后来把“退回率”作为核心监控指标很快锁定了问题环节。4.2 第二步检查上下文膨胀曲线把五组任务的上下文 Token 变化画出来能非常清晰地看到一条上升曲线。正常系统应该在某一轮后趋于平稳但我们的系统每一轮都比上一轮多出 30% 到 40%。这就是典型的上下文失控。实操时可以给每个 Agent 加一个 Token 计量器记录每次调用的输入大小和输出大小。如果连续三轮输入都显著增长就需要考虑上下文隔离、结果摘要或者任务拆分的方式。不要等到系统跑挂了再查因为一旦上下文膨胀到接近模型窗口上限错误率和重试率会同步飙升。4.3 第三步对比单 Agent 和当前多 Agent 的逐字段准确率我们后来做了一次逐字段的准确率对比发现多 Agent 系统并不是在所有字段上都比单 Agent 差。它在三个字段上准确率略高在五个字段上打平在两个字段上明显更差。其中 report_date 和 source_version 这两个字段单 Agent 是对的多 Agent 反而错了。这种逐字段对比能帮你判断一个多 Agent 拆分到底有没有价值。如果只是少数字段变差你可以在对应 Agent 的提示词里加限制如果整体变差那就要考虑重新设计协作方式了。我们倾向于认为只有当一个 Agent 的能力模型明显无法覆盖某项任务时才需要拆出去单独处理。4.4 第四步单独验证每个 Agent 的独立性最后一步我们把三个 Agent 拆开分别用同样的输入单独测试。结果发现抽取 Agent 单独运行时准确率 91%标准化 Agent 单独运行时能把格式映射做到 95%审核 Agent 单独检查错误的能力也不弱。但把它们串起来之后整体准确率反而下降。这说明问题不在单个 Agent 的能力而在它们之间的接口和协作协议上。我们后来重新设计了字段映射规范统一了字段名并把审核 Agent 的退回条件从“看到任何差异就退回”改成“必须给出具体修改建议才可退回”准确率才回到 93% 左右但 Token 成本依然比单 Agent 高出一倍以上。这也引出一个重要结论先单独验证组件再验证组合不要一上来就测试完整链路。独测能帮你判断 Agent 本身是否有能力问题联测才能暴露协作问题。两者不能混为一谈。5. 避坑经验清单什么时候不要用多 Agent以及如何正确拆5.1 四个明确“不适合”多 Agent 的信号经过这次反例我总结出四个不适合上多 Agent 的信号大家在做方案选型时可以拿来对照。第一任务本身是线性可解的也就是单 Agent 已经能稳定完成准确率没有明显瓶颈。不要为了“架构感”强行拆。第二Agent 之间需要共享大量原始上下文而且每个 Agent 都需要读取全量信息。这种场景适合用单 Agent 或检索增强不适合让每个 Agent 都背全量文档。第三上游 Agent 的输出格式经常不稳定下游 Agent 很容易因为解析失败而触发重试。第四你对最终结果有高强度一致性要求但这种一致性无法用显式规则描述只能通过反复审核保证。我们这次案例基本四个信号全中。说句实话如果当时能拿这个清单自测一下根本不会把三 Agent 方案上线。5.2 如果一定要用多 Agent我推荐的四种稳健拆法不是说多 Agent 一无是处。我后来也做了几轮成功改造有几个拆法被验证过是有效的分享给大家。第一种是并行无关拆法一个大任务先由一个 Agent 做任务分解分解出来的子任务互相独立再把不同子任务交给不同 Agent 并行执行最后用一个轻量级聚合 Agent 汇总。这种形态下各 Agent 不需要共享大量中间上下文Token 成本不会指数膨胀甚至因为并行还能省时间。第二种是受限上下文拆法每个 Agent 只能访问它执行子任务所需的那一段数据不能访问全量上下文。这个改造我们后来做了Token 成本直接降了 70%。核心思路是给每个 Agent 划定信息边界就像团队成员各看各的报表而不是围在一张桌子前翻所有文件。第三种是轻量协调拆法调度器只负责发消息和收结果不做内容判断。我们之前用强模型做调度器后来换成一个小模型加规则路由既便宜又稳定。其实大部分多 Agent 场景根本不需要调度器做智能判断规则路由就够用了。第四种是分层验收拆法审核 Agent 不直接退回整个任务而是输出结构化的问题列表包括字段名、期望值、实际值、修改建议。只有问题列表清晰时上游 Agent 才执行修改。这个改动让重试次数从三轮降到了一轮不到时间从 205 分钟降到 42 分钟准确率回升到 93%。5.3 Token 成本估算公式与上限预算最后给一个可以抄作业的成本估算公式。假设单个任务的原始文档大小是 D Token单 Agent 完成成本约是 alpha多 Agent 串联每轮基础成本约等于所有 Agent 的上下文读取之和与各自输出之和。如果每个 Agent 都能看到完整上下文那么第 N 轮的成本大致是第 N 轮成本 ≈ 原始文档 D 之前所有 Agent 输出总和 本轮所有 Agent 输出总和这个式子最核心的点是“之前输出总和”会不断增长。如果一轮循环中有 K 个 Agent 参与而且每个 Agent 都会输出并附加到共享上下文那么一轮下来新增的输出就是 K 倍。假设每轮 Agent 输出大小是 O那么 n 轮总 Token 大致是总 Token ≈ n × (D n × K × O)这是一个近似式子因为现实里输出大小会波动但它足够说明问题这里的成本是 O(n²) 量级增长。如果你预估 n 已经超过 2 轮就需要特别注意了多 Agent 循环的 Token 膨胀不是线性的而是平方级甚至更差。实际操作中我建议在方案设计阶段就设定三个预算总 Token 预算、最大循环轮数、最长耗时预算。一旦超出预算就自动熔断把当前上下文转给一个兜底 Agent 处理避免系统无限烧钱。我们后来加了一个“最多 2 轮重试”的熔断规则整体成本立刻可控了。5.4 这次反例留给我最值钱的三个认知每次复盘这种失败案例我都能得到比成功案例更多的思考。这个项目让我对多 Agent 系统有了几个很深的认知。第一多 Agent 不是一个“性能增强插件”它有很强的结构性损耗。每增加一个 Agent系统里就多了一个信息传递的失真点和一个协调消耗点。不要在单 Agent 还没跑通前就引入多 Agent先把单体方案做好做到准确率无法通过提示词优化继续提升为止。第二Token 成本和时间成本不是独立的它们会互相强化。Token 多的模型调用慢慢会让队列积压积压会拉长端到端时间。很多团队只盯着 Token 账单看成本忽略了时间其实也是成本的一部分。这次 32 倍时间里有至少一半是因为 Token 膨胀导致推理变慢和重试排队。第三审核 Agent 是一把双刃剑。增加审核角色确实能拦住一些低级错误但它同时会引入误判、来回拉扯和上下文污染。如果你要加审核务必让审核 Agent 的输出是“可执行的结构化修改命令”而不是模糊的“这里不对”。模糊的反馈只会让上游 Agent 做出更多不必要的重跑。个人经验是我现在做 Agent 设计时默认第一个方案永远是单 Agent 强提示词 结构化输出只有在单 Agent 方案确实因为上下文窗口或输出格式限制搞不定时才会考虑拆分工。而且拆分时优先选并行无关拆法其次才考虑串联流水线。串并联之间的决策点不是“看起来有没有必要”而是“去掉任何一个 Agent系统的质量会不会明显下降”。如果不会明显下降就去掉它。这个反例不值得高兴但它确实是我近期做过最有价值的一个实验。它让我意识到多 Agent 团队协作不是银弹性能和成本不会因为“加了更多 Agent”而变好反而会因为沟通成本爆炸而变差。希望这份拆解能让正在设计类似系统的你少跳一次火坑。