1. 先复盘我是怎么把效率改慢的这是多Agent实战记录的第二篇。上一篇好不容易把基础编排架子搭起来流程能跑通我当时还挺得意。结果真往里面加Agent的时候效率非但没起来反而肉眼可见地变慢。同样的任务之前一个Agent串行跑大概30分钟我调成多个Agent并行想的是“五个环节一起干活那不是快五倍吗”实测将近一小时才出结果。这篇文章就把这段踩坑经历掰开揉碎讲清楚为什么加了更多Agent工作效率反而快不起来。先说结论加Agent不等于加生产力。在很多任务里Agent每多一个通信、上下文、验证这三类成本都会跟着涨涨到一定程度收益就被成本吃光了。更麻烦的是这些成本大多数不会直接出现在任务耗时里藏得很深等你看出来的时候往往已经浪费了大半天。当时的场景是一个内容整理加分发的Demo某跨平台内容整理系统。流程拆成资料搜集、主题提炼、正文初稿、摘要生成、关键词标注、质量检查。最初是一个Agent按顺序从头做到尾我嫌慢改成能并行的环节同时跑。结果总耗时从差不多40分钟涨到了近70分钟第一反应是底层模型变慢了翻日志查了半天问题其实出在编排方式上模型推理根本背不了这个锅。那次复盘让我意识到一个很容易被忽略的事实所谓“并行加速”前提是任务之间真的没有强耦合而且结果的合并成本要足够低。我这批任务恰好两头都不沾——子任务之间既有依赖合并的时候还得额外做一轮一致性检查。这两部分成本在“加Agent能提速”的直觉里完全没被算进去。1.1 直觉错在哪人的直觉很朴素工作分给N个人每人干1/N总工时变成1/N。这句话成立的条件是工作可以被无损耗地切分切完之后不需要额外沟通也不需要有人统一整合。现实里几乎不存在这种任务——哪怕是把一篇长文切成几段让不同人写最后也要有人统一文风、核对衔接、补上过渡。这部分整合消耗的时间在初始的“分配”模型里根本看不见。类比一下就很好懂编辑部来了十个编辑一篇文章按段落分出去。最快的那个早就写完了卡壳的还在中间写完的段落还得有人审、有人改、有人拼接。折腾一圈很可能比一个老编辑从头写到尾还慢。Agent系统也一样数量上去以后瓶颈往往从“干活”转移到“协调”。我当时没有意识到这点一头把Agent堆上去结果就是局部快、整体慢。1.2 慢的不只是模型还有协调还有一种“慢”是看日志才发现的单个Agent的模型调用耗时其实没怎么变但Agent之间的等待时间长得离谱。有的Agent早就完成任务却要等着别的Agent把中间结果送过来有的Agent把同样的原始资料从头读了一遍又一遍只是为了拿到里面一小段关键信息。这些等待和重复读取全被排进了总耗时里。所以后半篇文章要做的就是把这笔“协调账”一笔笔拆开。2. 喊破喉咙也没用五个真正吃掉性能的黑洞下面这五个坑是我在多个实际场景里反复踩过的也是“加Agent反而变慢”最常见的五个根源。如果你想排查自己的多Agent系统拿这五点对号入座就行。2.1 通信成本随Agent数量指数膨胀Agent之间如果要两两同步消息需要维护的通信关系数量是 n(n−1)/2。3个Agent3对关系6个Agent直接变15对。Agent数量翻倍通信开销差不多翻了四倍还不止。这是数学上绕不开的跟具体用什么框架没关系。在真实系统里每条通信消息都有内容都要消耗输入token都要等模型处理完才能继续。Agent越多系统用来“聊天”的时间就越长真正拿来“干活”的时间反而变少。我后来在编排层加了一轮日志打点发现改版后的架构里Agent之间同步消息消耗掉的token占了总消耗的六成。那个数字把我吓到了——大部分成本其实花在了互相说话上。实操中能不两两交换就尽量不要两两交换。我把全链接式的同步改成“结果写进公共状态、需要的人主动取”之后通信量下降非常明显。2.2 上下文窗口被“聊爆”了第二个坑更隐蔽每个Agent都会带上一大段公共上下文里面有任务说明、历史对话、其他Agent的中间结果。模型对上下文长度是有限制的塞进去的内容也不是无限期保留。消息一多早期写下的关键约束很容易被后面的长对话挤掉Agent就会照着变形的信息往下走。我碰到过一个典型事故主控Agent在任务说明里写了“不要改动公共模块X”跑了几个来回之后下游一个Agent完全无视了这条约束直接对公共模块下了手。查日志发现这条约束确实在早期上下文里出现过只是被中间大量无关的讨论记录淹没掉了。解决办法就一条把共享上下文打薄。公共消息尽量精简成结构化状态而不是把整段历史一股脑塞给每个Agent。讨论过程保留在主控日志里就够了下游Agent只需要拿到“结论必要约束”不需要看全过程。2.3 串行依赖并行救不了硬件性能优化里有个经典结论系统整体加速的上限取决于任务里不可并行部分占的比重。如果一个任务中间有一段必须串行——比如A产出的东西B才能用那就算其他部分拆成100个Agent并行整体耗时也被这段拉死。实操里串行依赖比想象的普遍得多。我那套内容系统就是个例子主题提炼必须先做完摘要、关键词、正文才有依据。这几个环节表面看起来是能并行的但它们吃的都是同一个上游结果真正跑起来的时候大部分时间花在等待上游出结果上Agent全在空转。所以判断能不能并行不能只看环节名称要看数据依赖。谁依赖谁谁就在逻辑上排队排队的环节不管加多少Agent都偷不了时间。2.4 分工不清导致返工返工比慢慢做还贵多Agent系统里角色边界不清晰是最容易翻车的事。我在代码重构的场景踩过一次一个Agent负责模块A的重构另一个Agent负责全局依赖梳理两个Agent都发现要动同一个公共函数各自改完冲突了最后把所有改动回滚让其中一个Agent从头再做一遍。返工的代价不是简简单单“再做一遍”它需要回退、需要重新验证、需要额外消耗模型调用和token。一次冲突造成的返工成本可能顶得上正常做三遍。所以分工边界一定要定得比“听起来合理”更严格最好细到文件级、函数级让每个Agent只能动自己那一亩三分地。2.5 验证与纠错成本被严重低估Agent越多产出的可信度就越需要单独验证。以前一个Agent从头生成一篇文章结尾检查一次格式就行现在是五六个Agent各自输出总得确认它们之间的结论一致不一致、有没有互相矛盾的内容。单独看每个Agent的检查都不贵加在一起非常惊人。更麻烦的是错误传播上游Agent把输出当成“事实”传给下游下游Agent不会质疑只会在此基础上继续发挥。一旦上游错下游会错得更彻底等人工发现问题的时候返工范围已经非常大了。我后来立了一条规矩凡是下游要依赖的上游结论先走一道独立校验再进下一环。多一步看起来啰嗦实际上省掉的返工远大于校验成本。3. 实测现场三种配置的耗时差在哪理论说一堆不如直接看数据。我把同一个任务把一份原始资料变成一篇带标题、摘要、关键词的文章用三种方式各跑了好几轮取稳定值做了个对比。配置方式实测总耗时主要成本点纯串行约30分钟环节等待无脑全并行六个Agent同时放开约52分钟重复读取、空转等待、合并核对两阶段并行先串行出任务包再并行执行约19分钟依赖图清晰等待时间大幅缩短3.1 纯串行怎么跑整个流程按顺序执行资料搜集 → 主题提炼 → 写正文 → 写摘要 → 标关键词 → 质量检查。一个Agent干完传给下一个逻辑最简单几乎没有沟通损耗。缺点也很明显总时间等于所有环节耗时相加任何一个环节卡壳后面全部等着。这套跑下来差不多30分钟作为基准线。3.2 无脑全并行怎么跑我把搜集、主题、正文、摘要、关键词、质检六个Agent全部放开让系统“尽量并行”。第一次跑完我愣了半天耗时不仅没降反而直接涨到50多分钟。拆开看原因非常清楚每个Agent都拿到同一份原始资料六个Agent同时读全文数据量直接乘了六倍token开销暴涨模型处理变慢。摘要和关键词本来依赖正文全并行配置里它们只能空转或者先读一份还没定稿的中间版本等正文出来后再补一轮修正。六个并行跑完还需要额外的合并步骤把所有结论整合成一个最终版本合并本身又是时间和模型成本。这就是最典型的“看着能并行、其实并不了”的错配。3.3 两阶段并行怎么跑这是踩完坑之后重新设计的方案。阶段一先串行跑资料搜集 主题提炼产出统一的精简任务包。阶段二再把正文、摘要、关键词、质检并行放开摘要和关键词不再去读正文全文而是依赖任务包里一个“内容骨架关键片段”的中间产物。最后主控做一次轻量合并把四个产出拼成最终文章。这个流程跑下来稳定在19分钟左右比纯串行快了三分之一还多比无脑全并行快了将近一半。最关键的是它没有靠增加Agent数量而是靠理清了依赖关系。谁和谁真正互不依赖谁才该并行全并行和两阶段并行的区别全在这。4. 效率排查清单用数据代替感觉如果你的多Agent系统也出现“越加越慢”的情况别急着猜先拿数据定位。下面是我常用的排查顺序和检查项。4.1 先打点再谈优化第一件事一定是在编排层加日志和统计每个Agent的开始时间、结束时间、输入token量、输出token量、等待时间、重跑次数。没有这些数据后面所有讨论都是感觉。看日志的时候尤其重点看等待时间——如果某个Agent早早结束却花费大量时间等别的Agent响应问题多半出在编排或资源锁上而不是模型本身。4.2 画任务依赖图把任务拆成节点把“谁需要谁的输出”画成连线。有依赖关系的节点不要安排在同一层并行没有连线的节点才是能并行的候选。画完你大概率会发现一件事很多看起来独立的子任务其实共享同一个上游本质上还是在排队。这时候与其加Agent不如优化上游的产出速度或者把上游结果缓存起来让各下游直接打缓存。我自己的习惯是先跑通单向流程再挑候选环节做并行。一次只改一个变量数据变化才说得清理由。4.3 做一次“最少Agent实验”这是我最推荐的做法从1个Agent开始跑同一个标准任务记录总耗时然后逐步加到2个、3个、4个每次只加一个。最后把耗时画成一条曲线基本能看到“先下降、后回升”的拐点。拐点之前的收益是真实的拐点之后就是在为通信成本买单。按我的经验大多数任务在2到4个Agent之间就已经覆盖了主要分工超过这个数之后收益通常是负的。如果你的实验结果真的显示“5个比3个强很多”那是任务本身可拆分性极强值得深挖但别忘了把最终合并成本也算进去有些收益会在合并那一步吐回去。4.4 检查上下文是不是在“重复造轮子”重点看日志里每个Agent收到的公共上下文有多大。如果每个Agent都把原始资料完整带一份但它们实际需要的只是其中30%那就该改主控先对资料做一轮预处理输出精简任务包再把任务包发给各个Agent。聊天记录的长度也要控制该截断就截断该转成结构化数据就转。一个经常被忽略的细节是不要把所有历史消息都塞给下游Agent。它们只需要“结论必要约束”不需要围观讨论全过程。讨论记录留在主控日志里供人工排查比挤占下游Agent的上下文更有价值。4.5 关注接口限流和排队Agent数量涨上去之后模型接口的并发调用量也会同步涨。很多接口都有速率限制并发一多就开始排队排队等待的时间可能比并行省下来的时间还长。如果耗时曲线在Agent数增加后出现一整段平直的等待区多半就是被限流了这时候要降并发或错峰而不是继续加Agent。注意加Agent之前先确认资源侧没有被提前打满。我之前排查过一轮“变慢”问题查了半天发现是并发请求被接口排队了把并发数从8降到4总耗时反而掉了20%。方向搞反的话越调越折腾。5. 什么时候加Agent是真正有用的说了这么多坑并不是要全盘否定多Agent。有些场景加Agent的收益非常明显但通常得满足下面几个条件。5.1 三个前提条件第一子任务之间没有强依赖结果能自动合并而且合并成本要低。典型例子是批量处理多篇独立文档、为多个独立模块分别跑测试、对多个不相关的资料主题做并行检索。第二单个子任务的耗时本身要足够长长到并行收益能盖过通信成本。如果每个子任务两秒就干完了Agent之间消息传递的时间比干活时间还长这种场景就别并行。第三要有明确的主控Agent的角色是执行者而不是决策者。决策集中、执行分散系统出问题的概率和协调成本都会低很多。5.2 不适合并行的场景反过来如果一个任务的核心是一条深度推理链比如从需求分析一路到架构设计再到代码实现这类任务往往串行的单Agent或两三个Agent链式协作更稳、更快。强行拆分成并行等于把完整的推理链路切成几段每一段Agent都看不到全局最终合并出来的方案大概率是散的。我写过一段代码生成的需求尝试过前期的需求理解、技术选型、代码骨架设计全部分给不同Agent并行结果每个Agent自我感觉良好拼到一起连接口都对接不上。后来回到“一个Agent全链路思考两个Agent分别做复查和测试”的结构产出质量和速度反而都正常了。5.3 我的选择标准现在我的选择标准很简单先在纸面上画依赖图如果能清楚标出两三个互不依赖的大块才考虑并行否则就维持串行或极少数Agent。工具为任务服务不是任务为架构服务。这个道理听起来像废话但在我自己身上就是吃了几次亏才真正执行下去的。6. 最后说点私货在这个项目上踩过几轮之后我对多Agent的一个核心看法是Agent数量是结果不是目标。市场上很多介绍把“并行Agent”包装成一个万能加速器但在真实系统里它的价值高度依赖任务结构。如果你现在正打算把Agent从3个加到6个开工之前先问自己三个问题新增的Agent各自负责什么和现有角色有没有重叠新增Agent需要读哪些上下文这些上下文能不能不重复、不冗余它们的产出由谁来验证验证成本由谁承担这三个问题要是答不上来先别加。我自己现在的常规配置一般就是2到4个Agent一个主控负责拆解、合并和验证两到三个执行Agent负责真正的分工。大部分内容处理和轻度开发辅助场景这个配置比豪华的六七个Agent阵容稳定总耗时也更短。最后再分享一个亲测有效的小技巧做效率对比测试时固定一个标准任务连续跑三到五轮取中间值或平均值不要只跑一次。模型输出有随机性单次结果波动很大一不小心就会被一次偶然的快或慢带到错误结论上。多测几轮把波动平均掉数据才有参考价值。这一条比任何优化技巧都省钱省时间。 
长河君 · 2026/10/13 5:14:09 · 阅读 1.2k 加Agent反而变慢？多Agent编排的五个性能黑洞与两阶段并行方案
1. 先复盘我是怎么把效率改慢的这是多Agent实战记录的第二篇。上一篇好不容易把基础编排架子搭起来流程能跑通我当时还挺得意。结果真往里面加Agent的时候效率非但没起来反而肉眼可见地变慢。同样的任务之前一个Agent串行跑大概30分钟我调成多个Agent并行想的是“五个环节一起干活那不是快五倍吗”实测将近一小时才出结果。这篇文章就把这段踩坑经历掰开揉碎讲清楚为什么加了更多Agent工作效率反而快不起来。先说结论加Agent不等于加生产力。在很多任务里Agent每多一个通信、上下文、验证这三类成本都会跟着涨涨到一定程度收益就被成本吃光了。更麻烦的是这些成本大多数不会直接出现在任务耗时里藏得很深等你看出来的时候往往已经浪费了大半天。当时的场景是一个内容整理加分发的Demo某跨平台内容整理系统。流程拆成资料搜集、主题提炼、正文初稿、摘要生成、关键词标注、质量检查。最初是一个Agent按顺序从头做到尾我嫌慢改成能并行的环节同时跑。结果总耗时从差不多40分钟涨到了近70分钟第一反应是底层模型变慢了翻日志查了半天问题其实出在编排方式上模型推理根本背不了这个锅。那次复盘让我意识到一个很容易被忽略的事实所谓“并行加速”前提是任务之间真的没有强耦合而且结果的合并成本要足够低。我这批任务恰好两头都不沾——子任务之间既有依赖合并的时候还得额外做一轮一致性检查。这两部分成本在“加Agent能提速”的直觉里完全没被算进去。1.1 直觉错在哪人的直觉很朴素工作分给N个人每人干1/N总工时变成1/N。这句话成立的条件是工作可以被无损耗地切分切完之后不需要额外沟通也不需要有人统一整合。现实里几乎不存在这种任务——哪怕是把一篇长文切成几段让不同人写最后也要有人统一文风、核对衔接、补上过渡。这部分整合消耗的时间在初始的“分配”模型里根本看不见。类比一下就很好懂编辑部来了十个编辑一篇文章按段落分出去。最快的那个早就写完了卡壳的还在中间写完的段落还得有人审、有人改、有人拼接。折腾一圈很可能比一个老编辑从头写到尾还慢。Agent系统也一样数量上去以后瓶颈往往从“干活”转移到“协调”。我当时没有意识到这点一头把Agent堆上去结果就是局部快、整体慢。1.2 慢的不只是模型还有协调还有一种“慢”是看日志才发现的单个Agent的模型调用耗时其实没怎么变但Agent之间的等待时间长得离谱。有的Agent早就完成任务却要等着别的Agent把中间结果送过来有的Agent把同样的原始资料从头读了一遍又一遍只是为了拿到里面一小段关键信息。这些等待和重复读取全被排进了总耗时里。所以后半篇文章要做的就是把这笔“协调账”一笔笔拆开。2. 喊破喉咙也没用五个真正吃掉性能的黑洞下面这五个坑是我在多个实际场景里反复踩过的也是“加Agent反而变慢”最常见的五个根源。如果你想排查自己的多Agent系统拿这五点对号入座就行。2.1 通信成本随Agent数量指数膨胀Agent之间如果要两两同步消息需要维护的通信关系数量是 n(n−1)/2。3个Agent3对关系6个Agent直接变15对。Agent数量翻倍通信开销差不多翻了四倍还不止。这是数学上绕不开的跟具体用什么框架没关系。在真实系统里每条通信消息都有内容都要消耗输入token都要等模型处理完才能继续。Agent越多系统用来“聊天”的时间就越长真正拿来“干活”的时间反而变少。我后来在编排层加了一轮日志打点发现改版后的架构里Agent之间同步消息消耗掉的token占了总消耗的六成。那个数字把我吓到了——大部分成本其实花在了互相说话上。实操中能不两两交换就尽量不要两两交换。我把全链接式的同步改成“结果写进公共状态、需要的人主动取”之后通信量下降非常明显。2.2 上下文窗口被“聊爆”了第二个坑更隐蔽每个Agent都会带上一大段公共上下文里面有任务说明、历史对话、其他Agent的中间结果。模型对上下文长度是有限制的塞进去的内容也不是无限期保留。消息一多早期写下的关键约束很容易被后面的长对话挤掉Agent就会照着变形的信息往下走。我碰到过一个典型事故主控Agent在任务说明里写了“不要改动公共模块X”跑了几个来回之后下游一个Agent完全无视了这条约束直接对公共模块下了手。查日志发现这条约束确实在早期上下文里出现过只是被中间大量无关的讨论记录淹没掉了。解决办法就一条把共享上下文打薄。公共消息尽量精简成结构化状态而不是把整段历史一股脑塞给每个Agent。讨论过程保留在主控日志里就够了下游Agent只需要拿到“结论必要约束”不需要看全过程。2.3 串行依赖并行救不了硬件性能优化里有个经典结论系统整体加速的上限取决于任务里不可并行部分占的比重。如果一个任务中间有一段必须串行——比如A产出的东西B才能用那就算其他部分拆成100个Agent并行整体耗时也被这段拉死。实操里串行依赖比想象的普遍得多。我那套内容系统就是个例子主题提炼必须先做完摘要、关键词、正文才有依据。这几个环节表面看起来是能并行的但它们吃的都是同一个上游结果真正跑起来的时候大部分时间花在等待上游出结果上Agent全在空转。所以判断能不能并行不能只看环节名称要看数据依赖。谁依赖谁谁就在逻辑上排队排队的环节不管加多少Agent都偷不了时间。2.4 分工不清导致返工返工比慢慢做还贵多Agent系统里角色边界不清晰是最容易翻车的事。我在代码重构的场景踩过一次一个Agent负责模块A的重构另一个Agent负责全局依赖梳理两个Agent都发现要动同一个公共函数各自改完冲突了最后把所有改动回滚让其中一个Agent从头再做一遍。返工的代价不是简简单单“再做一遍”它需要回退、需要重新验证、需要额外消耗模型调用和token。一次冲突造成的返工成本可能顶得上正常做三遍。所以分工边界一定要定得比“听起来合理”更严格最好细到文件级、函数级让每个Agent只能动自己那一亩三分地。2.5 验证与纠错成本被严重低估Agent越多产出的可信度就越需要单独验证。以前一个Agent从头生成一篇文章结尾检查一次格式就行现在是五六个Agent各自输出总得确认它们之间的结论一致不一致、有没有互相矛盾的内容。单独看每个Agent的检查都不贵加在一起非常惊人。更麻烦的是错误传播上游Agent把输出当成“事实”传给下游下游Agent不会质疑只会在此基础上继续发挥。一旦上游错下游会错得更彻底等人工发现问题的时候返工范围已经非常大了。我后来立了一条规矩凡是下游要依赖的上游结论先走一道独立校验再进下一环。多一步看起来啰嗦实际上省掉的返工远大于校验成本。3. 实测现场三种配置的耗时差在哪理论说一堆不如直接看数据。我把同一个任务把一份原始资料变成一篇带标题、摘要、关键词的文章用三种方式各跑了好几轮取稳定值做了个对比。配置方式实测总耗时主要成本点纯串行约30分钟环节等待无脑全并行六个Agent同时放开约52分钟重复读取、空转等待、合并核对两阶段并行先串行出任务包再并行执行约19分钟依赖图清晰等待时间大幅缩短3.1 纯串行怎么跑整个流程按顺序执行资料搜集 → 主题提炼 → 写正文 → 写摘要 → 标关键词 → 质量检查。一个Agent干完传给下一个逻辑最简单几乎没有沟通损耗。缺点也很明显总时间等于所有环节耗时相加任何一个环节卡壳后面全部等着。这套跑下来差不多30分钟作为基准线。3.2 无脑全并行怎么跑我把搜集、主题、正文、摘要、关键词、质检六个Agent全部放开让系统“尽量并行”。第一次跑完我愣了半天耗时不仅没降反而直接涨到50多分钟。拆开看原因非常清楚每个Agent都拿到同一份原始资料六个Agent同时读全文数据量直接乘了六倍token开销暴涨模型处理变慢。摘要和关键词本来依赖正文全并行配置里它们只能空转或者先读一份还没定稿的中间版本等正文出来后再补一轮修正。六个并行跑完还需要额外的合并步骤把所有结论整合成一个最终版本合并本身又是时间和模型成本。这就是最典型的“看着能并行、其实并不了”的错配。3.3 两阶段并行怎么跑这是踩完坑之后重新设计的方案。阶段一先串行跑资料搜集 主题提炼产出统一的精简任务包。阶段二再把正文、摘要、关键词、质检并行放开摘要和关键词不再去读正文全文而是依赖任务包里一个“内容骨架关键片段”的中间产物。最后主控做一次轻量合并把四个产出拼成最终文章。这个流程跑下来稳定在19分钟左右比纯串行快了三分之一还多比无脑全并行快了将近一半。最关键的是它没有靠增加Agent数量而是靠理清了依赖关系。谁和谁真正互不依赖谁才该并行全并行和两阶段并行的区别全在这。4. 效率排查清单用数据代替感觉如果你的多Agent系统也出现“越加越慢”的情况别急着猜先拿数据定位。下面是我常用的排查顺序和检查项。4.1 先打点再谈优化第一件事一定是在编排层加日志和统计每个Agent的开始时间、结束时间、输入token量、输出token量、等待时间、重跑次数。没有这些数据后面所有讨论都是感觉。看日志的时候尤其重点看等待时间——如果某个Agent早早结束却花费大量时间等别的Agent响应问题多半出在编排或资源锁上而不是模型本身。4.2 画任务依赖图把任务拆成节点把“谁需要谁的输出”画成连线。有依赖关系的节点不要安排在同一层并行没有连线的节点才是能并行的候选。画完你大概率会发现一件事很多看起来独立的子任务其实共享同一个上游本质上还是在排队。这时候与其加Agent不如优化上游的产出速度或者把上游结果缓存起来让各下游直接打缓存。我自己的习惯是先跑通单向流程再挑候选环节做并行。一次只改一个变量数据变化才说得清理由。4.3 做一次“最少Agent实验”这是我最推荐的做法从1个Agent开始跑同一个标准任务记录总耗时然后逐步加到2个、3个、4个每次只加一个。最后把耗时画成一条曲线基本能看到“先下降、后回升”的拐点。拐点之前的收益是真实的拐点之后就是在为通信成本买单。按我的经验大多数任务在2到4个Agent之间就已经覆盖了主要分工超过这个数之后收益通常是负的。如果你的实验结果真的显示“5个比3个强很多”那是任务本身可拆分性极强值得深挖但别忘了把最终合并成本也算进去有些收益会在合并那一步吐回去。4.4 检查上下文是不是在“重复造轮子”重点看日志里每个Agent收到的公共上下文有多大。如果每个Agent都把原始资料完整带一份但它们实际需要的只是其中30%那就该改主控先对资料做一轮预处理输出精简任务包再把任务包发给各个Agent。聊天记录的长度也要控制该截断就截断该转成结构化数据就转。一个经常被忽略的细节是不要把所有历史消息都塞给下游Agent。它们只需要“结论必要约束”不需要围观讨论全过程。讨论记录留在主控日志里供人工排查比挤占下游Agent的上下文更有价值。4.5 关注接口限流和排队Agent数量涨上去之后模型接口的并发调用量也会同步涨。很多接口都有速率限制并发一多就开始排队排队等待的时间可能比并行省下来的时间还长。如果耗时曲线在Agent数增加后出现一整段平直的等待区多半就是被限流了这时候要降并发或错峰而不是继续加Agent。注意加Agent之前先确认资源侧没有被提前打满。我之前排查过一轮“变慢”问题查了半天发现是并发请求被接口排队了把并发数从8降到4总耗时反而掉了20%。方向搞反的话越调越折腾。5. 什么时候加Agent是真正有用的说了这么多坑并不是要全盘否定多Agent。有些场景加Agent的收益非常明显但通常得满足下面几个条件。5.1 三个前提条件第一子任务之间没有强依赖结果能自动合并而且合并成本要低。典型例子是批量处理多篇独立文档、为多个独立模块分别跑测试、对多个不相关的资料主题做并行检索。第二单个子任务的耗时本身要足够长长到并行收益能盖过通信成本。如果每个子任务两秒就干完了Agent之间消息传递的时间比干活时间还长这种场景就别并行。第三要有明确的主控Agent的角色是执行者而不是决策者。决策集中、执行分散系统出问题的概率和协调成本都会低很多。5.2 不适合并行的场景反过来如果一个任务的核心是一条深度推理链比如从需求分析一路到架构设计再到代码实现这类任务往往串行的单Agent或两三个Agent链式协作更稳、更快。强行拆分成并行等于把完整的推理链路切成几段每一段Agent都看不到全局最终合并出来的方案大概率是散的。我写过一段代码生成的需求尝试过前期的需求理解、技术选型、代码骨架设计全部分给不同Agent并行结果每个Agent自我感觉良好拼到一起连接口都对接不上。后来回到“一个Agent全链路思考两个Agent分别做复查和测试”的结构产出质量和速度反而都正常了。5.3 我的选择标准现在我的选择标准很简单先在纸面上画依赖图如果能清楚标出两三个互不依赖的大块才考虑并行否则就维持串行或极少数Agent。工具为任务服务不是任务为架构服务。这个道理听起来像废话但在我自己身上就是吃了几次亏才真正执行下去的。6. 最后说点私货在这个项目上踩过几轮之后我对多Agent的一个核心看法是Agent数量是结果不是目标。市场上很多介绍把“并行Agent”包装成一个万能加速器但在真实系统里它的价值高度依赖任务结构。如果你现在正打算把Agent从3个加到6个开工之前先问自己三个问题新增的Agent各自负责什么和现有角色有没有重叠新增Agent需要读哪些上下文这些上下文能不能不重复、不冗余它们的产出由谁来验证验证成本由谁承担这三个问题要是答不上来先别加。我自己现在的常规配置一般就是2到4个Agent一个主控负责拆解、合并和验证两到三个执行Agent负责真正的分工。大部分内容处理和轻度开发辅助场景这个配置比豪华的六七个Agent阵容稳定总耗时也更短。最后再分享一个亲测有效的小技巧做效率对比测试时固定一个标准任务连续跑三到五轮取中间值或平均值不要只跑一次。模型输出有随机性单次结果波动很大一不小心就会被一次偶然的快或慢带到错误结论上。多测几轮把波动平均掉数据才有参考价值。这一条比任何优化技巧都省钱省时间。