--- layout: post.njk source: https://yage.ai/share/multi-agent-what-it-buys-20261021.html web_feed: articleId: cmvk48j4o0003yee7mtf8alxx feedSourceId: webfeed_yage_ai guid: https://yage.ai/share/multi-agent-what-it-buys-20261021.html sourceUrl: https://yage.ai/share/multi-agent-what-it-buys-20261021.html speaker: yage.ai title: 多 agent 不是更聪明，是更贵：它到底买到了什么 date: '2026-10-21' summary: 文章探讨了多 agent 系统并非自动提升智能，而是一笔用数倍 token 预算去换取特定工程指标的交易。多 agent 的价值取决于任务的特性，例如，子任务的独立性可以换取更短的端到端时间；信息复杂可以换取更广的搜索覆盖和查漏补缺；长程任务可以换取搜索多样性；上下文隔离可以换取干净的审查窗口。文章指出，如果任务卡在单步核心推理太难或步骤过于紧密，多 agent 可能会因协调故障而导致重复劳动。最终建议是先看清任务瓶颈，根据瓶颈选择单 agent + 高档位推理，或在特定条件下才考虑引入多 agent。 area: tech-engineering category: ai-application tags: - multi-agent - token-cost - workflow-automation - task-parallelism - system-design people: [] companies_orgs: - Cognition - Anthropic - Vals AI - Cohere products_models: - Devin - GPT-6 - Claude Opus 5.5 - GPT-5.6-terra - GPT-5.5 media_books: [] draft: true status: evergreen --- ## 两个相反的标题，说的是同一件事 经常使用 AI 进行编程、信息检索或构建工作流的开发者可能注意到，做 Devin 的 Cognition 和 Anthropic 对多 agent 系统持有不同的观点。2025 年 6 月，Cognition 发布了一篇名为 《Don’t Build Multi-Agents》 的文章，建议不要构建多 agent 系统。然而，在相近的时间点，Anthropic 也发表了一篇题为 《How we built our multi-agent research system》 的文章，解释了为何他们的研究系统采用多 agent 设计。2026 年 4 月，Cognition 又发布了一篇更新文章《Multi-Agents: What’s Actually Working》，指出他们也开始在生产环境中使用多 agent 系统，但仅限于特定场景。尽管表面上看这两篇文章相互矛盾，但实际上它们反映了相同的信息。想清楚这一点，做架构选型时既不会白烧几倍的 token，也不会在该并行时不敢用。 两个团队观点看似相左，是因为他们站在交易的两端：Anthropic 看的是多花的算力换回了什么结果，Cognition 看的是暴涨的调用费和角色之间的沟通损耗。多 agent 不会让模型一次推理变得更聪明，而是通过编排把更多的 token 砸到同一个问题上。 Anthropic 的这份生产复盘详细分析了这一投入。一个 agent 反复调用工具，模型也要跟着多轮回答，累计消耗的 token 大约是一次普通问答的 4 倍；多 agent 系统则要到 15 倍左右。在 BrowseComp 这类复杂网页检索任务上，token 花得多不多，和最终得分的关系非常直接。 15 倍的 token 买到了什么？Anthropic 把各家系统在 BrowseComp 上的得分和 token 用量放在一起比，发现得分差异里有八成能对上 token 用量的差异：花 token 多的系统，得分通常也高。token 未必是唯一原因，但在这组数据里，它是最能解释胜负的一个变量。Anthropic 工程师的说法是：多 agent 系统有效，主要是因为它把足够解决问题的 token 花出去了（“help spend enough tokens”）。 多 agent 不是一种能让所有工程指标都变好的魔法。它更像是一次用好几倍 token、等待和协调来买一两样特定指标的明确交易，别的指标可能一个不变，甚至变差。Anthropic 自己也只是把这套架构称作带主从分工的工作流，没有说它是全新架构。 ## 大家期待的四样好处，默认配置下往往只付了代价 在把一个单 agent 升级成一个多 agent 团队之前，大家往往会期待四项收益：更强的结果、更快的速度、更全的流程、更省心的互相监督。这四个好处听着像白捡的，但每一项都自带不菲的价格。而且有个更麻烦的现实是，用默认配置，你往往付了三五倍的代价，却没拿到想要的收益。 多 agent 的代价传导链：任务分给多个子 agent，各自重读规格与状态，重复计费的缓存输入乘以调用次数，团队总开销是单干的 1.8 到 5.1 倍。 ### 期待默认更强：调高单模型推理档位往往更划算 直观上会以为多个模型一起讨论、分工，能写出比一个模型闷头单打独斗更好的代码。一个接近现实软件开发的实验是，给模型一个完整的产品规格说明，让它从零写出一个功能齐全的 Web 应用。Vals AI 的评测用的就是包含 100 道类似题目的 Vibe Code Bench 基准。他们选了其中一半题目，对 GPT-6 的高档位 Sol 和 Claude Opus 5.5，在 medium 和 max 两个推理设置下，比较单打独斗和组队时的表现，一共八个配置。两个模型各自在各自的框架上跑一遍，每个配置只跑一次，比较不同题目上的得分差异。 等结果出来一看，组队的开销是单干的 1.8 到 5.1 倍。但四个比较里只有 Sol 在 medium 档位下组队拿到了统计显著的提分（+7.3 分），其他三种情况跟单干相比都没有统计显著的差别。 如果把组队多花的预算省下来，直接用来把 Sol 单模型的推理档位从 medium 调高到 max，得分能涨 11.4 分，比在 medium 档位下组队多拿的分数还高。Opus max 团队虽然拿到了全场最高分，但花掉的钱是 medium 单干的 30 倍，比起 medium 单干只高出 1.6 分，统计上同样不显著。吞掉预算的大头是缓存输入的重复读取：每一个子 agent 上场干活，都得把产品规格说明和当前的工作状态从头读一遍，每调用一次就重新计费一次。哪怕缓存读取的单价便宜，每个子 agent 每次调用都要重发一遍上下文，调用次数一多，总额依然惊人。 ### 期待人多更快：串行波次与任务依赖会让耗时翻倍 另一个直观的想法是，人多力量大，多个 agent 一起干活肯定比一个人快。但 Vals AI 的实验显示，只有 Sol 团队是真的快，Opus 团队串行一波一波派子任务，最慢的时候花的时间达到了单干的 2.3 倍。 Anthropic 在生产复盘时指出，这是因为软件编程任务的并行化程度远不如资料检索和研究任务高。一旦任务需要所有 agent 使用同一个上下文，或前后子步骤衔接紧密，多 agent 就会因等待与同步浪费大量时间，今天并不适用。 ### 期待全流程委派更全：无差别外包只是多付一倍代价 很多人会想，既然组了团队，是不是就可以把探索规划、代码实现、测试验证整个流程交给子 agent 来完成。另一个从零开始构建一个软件的研究，它专门针对这种情况进行了实验，给了模型一个需求和一些测试用例，让它从头把程序写出来。Cohere 的团队规模研究用的是 ProgramBench 这个基准，里面有 200 道这样的题目；每道题给的是一个只能运行、不能读源码的原程序，让 agent 从零重写一个行为一致的版本。每个配置跑了三遍取平均，以降低单次运行的随机性。 组织良好的团队在 ProgramBench 上最多能比单干提升约 10 个百分点，但需要 3 到 7 倍的运行成本。实验中还有一个更清楚的对比：只把探索和规划交给子 agent，得到的分数和把规划、实现、验证全部交出去基本持平，但花费直接减少了一半。 这里的探索与规划不是空泛地想一想。规划阶段的 worker 要反复运行原程序，摸清接口、边界情况和行为，再把发现整理给主控；主控拿着这份更完整的地图自己写实现、自己做验证。Cohere 的数据是：只委派规划的异步团队拿到 63.6%，和全阶段委派基本持平，成本却从 510 美元降到 249 美元。原因不神秘：这个基准的瓶颈就在搞清楚要写什么，把 worker 放在瓶颈上，钱才花得值。Cohere 还对比了另一个基准 Commit0，规格、文档、单测都已经给全；在这种基准上，瓶颈变成把实现写对，最有效的委派阶段也就跟着换成了实现。如果不看任务需要什么，直接把所有步骤都无差别委派给子 agent，那额外付出的代价有一半基本上是浪费的。 ### 期待互相监督更省心：角色增多会带来自有的协作故障 第四，很多人觉得，只要给几个角色互相监督，就不会太操心：一个写代码、一个跑测试、一个做验收，搞砸了团队自己兜底。可一旦真让多个智能体接力跑起来，常能看见两个角色反反复复干同一件事、嘴上说代码改好了其实一行没动，或者压根没跑通验证就宣布大功告成。研究者收集了七个主流多 agent 框架的 1600 多条运行轨迹，整理出一套包含三大类 14 种模式的失效分类体系 MAST。 按照 MAST 的统计，步骤重复占了全部失效的 15.7%，推理和实际行动不一致占了 13.2%。他们分析的框架里有早期知名的 ChatDev；不换模型，只要把角色的职责边界写清楚，就能让成功率明显上涨。往系统里多塞几个角色并不会自动让人省心，职责一旦含糊，反而会凭空造出一堆单 agent 根本不会犯的协调故障。 ## 那它真正买到了什么 那为什么成熟的工程团队还是在某些情况下愿意为多 agent 买单呢？是因为多花的几倍预算确实能换来四个实实在在的工程指标。但每个都有它自己的前提，任务恰好满足这些条件，这笔投资才划算。 多 agent 的四项收益各自对应明确的任务条件：子任务相互独立才能换端到端时间，信息装不进单窗口才能换查漏补缺，长程任务卡在单一思路才能换搜索多样性，上下文太长污染判断才能换上下文隔离。 ### 端到端时间：子任务彼此独立时，花钱买快 一项任务天生可以切成若干相互独立的子任务，并且执行时不会退化成串行等待，多 agent 才可能带来更短的端到端时间。Noam Brown 在 2026 年 9 月做客 Dwarkesh 播客时提供了一个直观的换算：四个 agent 并行，端到端时间减半，价格翻倍；继续增加并行度，边际收益会有所下降。他也强调了一个前提：这个换算只在任务真的能并行时成立。比如写小说这种前后文伏笔和语气紧密咬合的任务，就算堆上再多 agent 也不可能提速。 ### 查漏补缺：信息超窗或规格复杂时，花钱买全 第二个能买到的指标是查漏补缺，适用于需要做广度优先的多路线索排查、涉及的信息装不下一个上下文窗口、需要同时调用大批复杂工具，或需求规格太复杂让单 agent 顾此失彼。Anthropic 的多 agent 系统复盘提到，在这类信息面铺得开的任务上，多 agent 可以靠并发把搜索网同时撒出去。 在大型应用开发中，这项优势表现为对遗漏细节的独立复核。回头看看前面提到的 Vals AI 的 Vibe Code Bench 实验，唯一拿到统计显著提分的那组配置，涨分几乎全来自高难度应用：在难应用上团队比单干高出约 15 分，在简单应用上只高出约 1 分。去翻运行轨迹就能看明白，单 agent 面对复杂繁琐的产品规格时，经常在报告里说自己测过了，实际上漏掉了好几块功能实现或测试验证；多 agent 团队之所以能在难题目上拉开差距，靠的是专门的核验角色去把单 agent 自报完成、实则没落地的缺口补齐并逐项核实。 ### 搜索多样性：长程任务困在单一思路时，花钱跳出洼地 第三项能花钱买到的能力是搜索多样性，专门用来对付超长程任务中的钻牛角尖问题。它生效的条件是任务运行时间长达几小时甚至几天、早期的路线选错会一路走到黑，而且系统在分叉探路之后必须主动清空父代的上下文。一个 agent 在连续几小时执行复杂任务时，一旦开头选定某条技术路线，后面就会一直在同一个思路坑里打转，很难自己跳出来。微软研究院把这种困住 agent 的思路坑叫作 idea basin，并为此设计了 Fork-and-Flush 机制：在关键决策节点像操作系统进程 fork 一样派生多个分支去试探不同方案（Fork），等看出哪个分支有戏之后把父代冗长的思考历史彻底清空（Flush），只留干净的阶段性结论往下传。 微软研究院在一系列单次运行从几小时到几天的长程任务上测试了这一机制，底层在 11 个任务上使用 GPT-5.6-terra，在 kernel 和 tinyCIFAR 两个任务上使用 GPT-5.5，通过 GitHub Copilot CLI 执行。在消耗相同计算资源的情况下，Fork-and-Flush 取得了 0.78 的综合得分，远高于单次长跑的 0.47，也明显高于独立重跑四次取最优的做法，相对单跑提升了 66%。消融实验分别测了两步的贡献：如果只做清空历史或者只做分叉选路，虽然也能带来一些局部起色，但只有把两步合在一起才能拿到完整增益。分叉负责在不同的思路洼地之间挑出更好的路线，清空历史则切断了父代推理留下的惯性，防止分支走着走着又滑回老路上去。 ### 上下文隔离：长上下文沾满试错痕迹时，花钱买干净窗口 第四是上下文隔离。主 agent 在成千上万行代码或报错日志里摸爬滚打太久，窗口里塞满了先入为主的试错痕迹，注意力分散、判断走眼。Chroma 在 2025 年 7 月关于 Context Rot 的研究验证过一条普遍规律：哪怕在非常简单的任务上，只要往模型里塞的输入文本越来越长，模型的表现就会一路退化。 主 agent 经历了几万行代码和报错堆栈，它的上下文早就沾满了之前失败假设留下的痕迹。此时花钱派生一个子 agent，购买的实际上是一个没有污染的独立窗口。Cognition 在 2026 年 4 月的多 agent 工程实践文章中也分享了一个典型的工程体感：带干净上下文的审查角色去看代码，经常会发现写代码的 agent 自己看半天都没发现的 bug。 ## 三类误解：能力、机制、组织 理解了哪些指标根本买不到、哪些得看条件才能买到，实际落地时还会碰到三个常见的坑：能力边界的坑、机制的坑和读写组织的坑。这三类问题不解决，参数调得再细也白搭。 能力上的常见想法是找几个弱一点的模型组个队，靠人多凑出群体智慧，就可以涌现出强模型才有的推理能力。早期的研究比如 More Agents Is All You Need 也确实展示了，对多个 agent 进行多次采样和投票，输出的质量会随实例化的 agent 的数量而增加，且与任务的难度有关，并且还可以和更复杂的协作方式结合使用。 但这样的做法无法跨越主控模型本身的能力天花板。Cohere 在 ProgramBench 上做的跨模型对比给出了直接的反证：团队能不能带来增益主要取决于主控 lead 的能力。用较早的 Opus 4.7 做主控，它几乎从不向下委派任务，因而得不到任何团队增益；Haiku 和 Gemini 的某些版本虽然委派很勤快，得到的结果也几乎没有增益；只有换用较新的 Opus 4.8 和 GPT-5.6 做主控时，才会有效委派并真正受益。用比较弱的模型当主控，再配一帮便宜的 worker，拿到的分数甚至不如一个强模型单打独斗。不论是采样投票还是主从分工，实际上买到的都只是同一能力水位上的采样命中率和规划覆盖度，买不到跨代际的基础推理能力。 机制上的常见想法有两个：一是如果任务复杂，就必须用自治 agent 做多轮自由探索循环；二是长程任务跑久了，定期把长对话历史压缩成摘要，就能跟清空上下文一样有用。代码修复基准 SWE-bench Lite 上的极简方案 Agentless 直接反驳了第一层想法：修代码仓库里的 bug 未必需要让 agent 自己到处乱逛，把流程切成定位、修复、补丁验证三步固定流水线，同样能拿到 32% 的解决率，单题开销只有 0.70 美元，超过了当时所有的开源软件 agent。 至于第二层想法，微软研究院在 Fork-and-Flush 的实验里也给出了反证：就算周期性地压缩对话历史，agent 的思路依然会困在原来的洼地里出不来。压缩只是把旧的推理过程写短了留在窗口里，清空才是把旧包袱彻底扔掉。因此，自治循环买到的是开放问题上的动态探路自由度，分叉加清空买到的是摆脱父代推理惯性的全新起点；流程固定时直接走固定流水线更省钱，思路钻进牛角尖时靠摘要压缩也救不回来。 组织上的常见想法，是把多 agent 做成没有中心结构的蜂群，让一群平级角色自由沟通、同时动手改同一份代码或文档。Cognition 的工程复盘直接给这种设计泼了冷水：非结构化的蜂群放到工程里大多只是噪音；今天真正能跑通的多 agent 系统，写入操作必须保持单线程，额外增加的 agent 只负责提供判断而不直接动手改状态，实际跑得通的形态是分发、汇总和管控。 LangChain 的多 agent 指南从读写操作的本质差异解释了原因：读操作天然容易并发，而并行的写操作既要同步上下文又要合并输出，稍微没对齐就会撞出无法调和的冲突。这也是为什么 Anthropic 的多 agent 研究系统只让子 agent 分头去阅读和搜集资料，最后的成文写作仍然收归单个主 agent 在一次统一调用里完成。在组织层面上，多 agent 真正买到的只是并行的读取、检索和审阅吞吐量，修改和写入权必须留在单线程里。 ## 怎么选：一张四行的表 综合上面的实验和工程踩坑，可以压成一张四行速查表。犹豫要不要加一个 agent，或者不知道怎么花钱买能力的时候，花十秒钟看看当前任务卡在哪一行，选型就清晰很多。 任务卡在哪里 多 agent 管用吗 更划算的做法 单步推理太难、步骤咬得太死、多人同时改同一处 不管用 调高单 agent 推理档位，或改用固定流水线 子任务彼此独立，单纯想缩短等待时间 管用 先确认不会退化成串行，再并行派发 线索面太广、复杂规格漏测 管用 只委派探索与规划；漏测再加独立核验 长跑钻进死胡同、上下文塞太满 管用 分叉加清空历史；另派干净窗口审查 一旦确认任务落在后三行、确实需要上团队，再考虑怎么把团队内部的账单压下来。这里的能力路由买不到第五样收益。它是决定上团队之后的一个减项：改变的是贵多少，不改变比单干贵这件事。 ### 能力路由：只改变贵多少 回到那四项硬指标。只要任务能把拍板和探路拆开、主控模型够强，多 agent 架构还能用不同档位的模型混搭，把团队内部的账单压下来。Cohere 在 ProgramBench 上的异构团队实验测过这笔账：实验用的是另一代 GPT-5.6 系列，Sol 是其中的高档位，Luna 是低档位。用单个 Sol 档模型当主控，下面挂十六个便宜很多的 Luna 档模型做探索与规划，这个团队拿到了 61.8% 的分，和全员用 Sol 档的豪华团队不相上下，开销却只有 155 美元。 这里要把账算清楚。如果同样是只委派探索与规划，全用 Sol 的团队要 249 美元；换成 Sol 主控加 Luna 规划 worker，才降到 155 美元。拿 155 美元去和全阶段都用 Sol 的 510 美元比，里面其实混了两笔账：少委派实现和验证两个阶段，以及把规划阶段的模型换便宜。155 美元仍然是一支 17 个 agent 的团队开销，单干的账单不在这组对比里。所以能力路由不能拿来证明多 agent 省钱。它解决的是另一个问题：既然已经决定上团队，就别让每个角色都烧顶配模型。它的前提是：主控必须足够强，弱主控带便宜 worker，分数还不如强模型单干。 这件事听起来简单，做起来不简单。主控得先判断哪个阶段是瓶颈，便宜模型得在那个阶段真的够用，上下文交接还得既不让 worker 饿着、也不把它淹死。Cohere 让 Luna 做规划，是因为规划是发现型任务、可以并行、对模型上限要求低；换到实现或验证，便宜模型就不一定接得住。所以它很难浓缩成把调研丢给便宜模型一句话。它更像资深工程师带初级工程师：先知道该派什么，再知道怎么派，最后还得会验收。 即便上了多 agent，也要守住并行读与规划、单线程写这条边界，把修改权收归主控，子角色只负责情报、规划和审阅。这条边界守不住，前面省下来的钱很快会被协调故障吃回去。 ## 结论：先看清任务瓶颈，默认从单 agent 提档开始 把各家实测数据摆在一起看，Anthropic 的多 agent 系统会消耗单次普通问答 15 倍的 token，Vals AI 和 Cohere 的团队开销也是单干的好几倍。多 agent 从来不是一个让系统全面变强的免费开关，它是一笔用几倍 token 预算去置换特定工程指标的交易。看清这个交换关系，团队就有了稳定的选型准绳，不用每次市面上出一个新框架就跟着推倒重来。 这笔预算能买到的回报非常具体：子任务彼此独立，换来更短的端到端时间；信息超窗或需求繁杂，换来更广的搜索覆盖和查漏补缺；几十小时长跑容易钻牛角尖，靠分叉加清空历史换来跳出思路洼地的多样性；上下文塞满试错痕迹，换来一个干净的独立审查窗口；每一项都有明确的适用条件，不是随便哪个任务都能兑现。能力路由不在这个清单里；它只在决定上团队之后，改变这支团队贵多少。 反之，若任务卡在单步核心推理太难、前后步骤咬合太紧难以切开，或强行让多个角色同时改同一份代码，用多 agent 只会让同样水平的判断力重复好几遍，为步骤重复、言行不一等协调故障买单。下次在流程里加第二个 agent 前，先看清瓶颈在哪：知道三到五倍的运行成本换来的是上面四项指标中的哪一项，才算把钱花在刀刃上；否则就先用单 agent + 高档位推理。