多 Agent 不笨，是传话的人太多
Site Owner
Published on 2026-07-26
EvoX 蜂群跑分追平 Codex、成本干到 1.95 美元——多 Agent 的真正瓶颈不在模型智商，而在传话损耗。43% 的正确答案死在汇总那一刻。
多 Agent 不笨，是传话的人太多
先看一个数字：563 个任务，过程中有 373 个本来答对了，最后交付时只剩 217 个正确。
166 个正确答案，在传递和汇总中被吃掉。保留率 55.5%。
这不是模型幻觉，不是能力不够。这是典型的「传话游戏」结局——第一个人说的是"苹果"，传到第五个人变成"红富士还是黄元帅我也分不清了"。
EvoMap 团队最近公布了 EvoX 蜂群系统的测试结果。他们在六大 benchmark 的 424 个任务上，跟 Claude Code、Codex 同台对比，用同一个模型（Opus 4.8），跑分追平 Codex——338 vs 338，只比 Claude Code 少 20 分。而单个任务成本最低干到 1.95 美元。
这不是"我们又训了个更强的模型"那种故事。模型一样，数据一样，唯一变量是协作架构。
真正的差距，从来不在脑子，在嘴巴。
<!-- 配图：多 Agent 传话游戏示意图，每传递一层信息碎片化一层 -->
传话损耗 44.5%，这不是 bug，是架构的必然
主从模式（Agent Team）是现在多 Agent 系统的主流玩法。一个主 Agent 拆任务，派给几个子 Agent，子 Agent 各自干完，把结果交回来，主 Agent 汇总成最终答案。
听起来没毛病。但 EVOX 团队盯着执行过程一看，发现问题出在哪了——
563 个任务，子 Agent 们过程中产出的正确答案有 373 个。也就是说，这帮家伙能力在线，靠自己能把事情做对。但从「子 Agent 交卷」到「主 Agent 汇总成最终答案」这一步，丢了 166 个。
几乎一半的正确产出，在传递中被扔掉。
原因不复杂。主 Agent 要同时看几份答卷，有的写得很长，有的格式不统一，有的结论互相矛盾。它得理解、取舍、整合——每一步都是信息损耗的放大器。
这不是某个 prompt 没写好。这是主从架构的固有属性：只要存在一个负责「汇总」的中心节点，它就会成为带宽瓶颈和单点误判源。你再怎么优化它的指令，它也得从一堆噪音里捞出信号，捞错一次，一个正确答案就白算了。
多 Agent 不是能力不够，是组织方式让它们把力气花在了扯皮上。
蜂群的答案：不传话，只交卷
EvoX 的解法听起来像常识——别让 Agent 互相传话，让它们各自干各自那部分，直接交结果。
他们把任务切成原子级的独立单元，每个 Agent 只负责自己那块。没有主 Agent 派活，没有中间汇总环节。就像蜂群筑巢，每只蜜蜂只管自己眼前那六边形，不需要知道整个巢长什么样，也不需要跟隔壁商量。
所有 Agent 的输出按位置拼接，跳过「汇总」这个单点故障源。
效果？同一套题、同一个模型，蜂群模式拆分后的正确率最高，Agent Team 模式次之，单体 Agent 最差。在 AppWorld 上，EvoX 拿下 87/90，比 Codex 多 9 个。GAIA 上 49/51，跟 Claude Code 并列最高。
<!-- 配图：Benchmark 对比柱状图，突出同模型三种模式下的分数差异 -->
这里有个反直觉的点：单体 Agent 最差不是因为能力弱，是因为上下文太长，模型自己把自己绕晕了。 蜂群不是让一群笨 Agent 加起来变聪明，是把任务拆碎了，让每个 Agent 在短上下文里做简单判断，准确率自然高。
这不叫技术突破，这叫把组织架构当成第一性原理来设计。