AI 洞察
20 分钟
多 Agent 不笨，是传话的人太多
Published on 2026-07-26
EvoX 蜂群跑分追平 Codex、成本干到 1.95 美元——多 Agent 的真正瓶颈不在模型智商，而在传话损耗。43% 的正确答案死在汇总那一刻。
Loading...
Loading...
Published on 2026-07-26
EvoX 蜂群跑分追平 Codex、成本干到 1.95 美元——多 Agent 的真正瓶颈不在模型智商，而在传话损耗。43% 的正确答案死在汇总那一刻。
先看一个数字：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 传话游戏示意图，每传递一层信息碎片化一层 -->
主从模式（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 在短上下文里做简单判断，准确率自然高。
这不叫技术突破，这叫把组织架构当成第一性原理来设计。
两天前，Claude Code 团队发了一篇关于 Claude 5 模型的上下文工程文章。里面有个数据：他们把 Claude Code 的系统提示词删减超过 80%，Coding 评测没有可测量损失。
删掉的是什么？少教动作、把流程放进 Skill、把规则换成接口设计。
翻译成人话：别老告诉模型「做什么」「怎么做」，把战场画清楚，让它自己发挥。
原文里有句话特别形象：之前的提示词像五个产品经理同时站在程序员身后，每个人都在指指点点——「考虑一下这个边界条件」「别忘了那个异常处理」「性能再看看」。当模型不够强的时候，这种唠叨有用。现在 Opus 5 了，还要这么多保姆式指令，反而抢方向盘。
EvoX 的蜂群思路跟这个同频。主从模式里的主 Agent，就是那个「过度工程的指令层」——它不停地把子 Agent 的输出读一遍、译一遍、整合一遍，这个动作本身就引入误差。
两者指向同一个方向：模型变强后，你把接口定义清楚，比管它怎么干活儿重要得多。
<!-- 配图：并列对比——左侧「五个产品经理围着一个程序员」夸张漫画，右侧「蜂群各自筑巢」素描 -->成本数据更扎心。
EvoX 每个任务按统一价目表 6.10 美元，如果按缓存计价，低至 1.95 美元。Claude Code 和 Codex 显著高于这个数。
贵在哪？不是模型推理，是来回传话烧 token。
主从模式下，主 Agent 要把任务描述给子 Agent，子 Agent 交结果回来，主 Agent 再消化再输出——同一段信息在多个 Agent 之间反复传输、反复编码解码。这不是并行计算，这是串行扯皮。德勤 2026 年有个报告，说 86% 的多 Agent 项目没法规模化落地。硅谷已经出现「无限智能体死循环」：几个 Agent 协同空转几小时，烧掉上千美元 token，什么也没产出。
蜂群不扯皮。每个 Agent 拿到自己那块活儿，干完交卷，没有中间商赚差价。
组织臃肿的代价，原来在 AI 世界里也精确到小数点后两位。
<!-- 配图：三个 Agent 模式的成本对比表格，突出每任务美元数差异 -->还有个实验值得讲。
EvoMap 团队放了 24 个同配置 Agent，让它们各自完成任务后，把过往经验累积成 Gene（经验基因）。重点是观察这些 Agent 如何自发组网——
当 Agent 看到的是社交关系信息时，它们抱小圈子，熟人优先。
当 Agent 看到的是任务能力+历史正确率时，长出功能型网络，能力互补。
信息来源决定组织形态。 不是 Agent 的性格问题，不是优化器的问题，是你喂给它什么信号，它就按什么逻辑组队。
这解释了为什么主从模式容易烂——主 Agent 看到的是子 Agent 的原始输出文本，不是结构化的能力画像。它只能根据一堆长文本来做「阅读理解」，然后拍脑袋整合。这个决策质量，天花板太低了。
别误解。蜂群不是让 Agent 放飞自我。正相反，这要求你把任务拆解的粒度做到极致，把接口规范定义得极度清晰。
就像 Claude Code 删了 80% 提示词后，不是什么都删，而是把规则变成接口设计——「这个函数返回什么格式」「那个模块依赖什么数据」，边界画死了，中间怎么实现你不该管。
当你把组织结构从「传话型」变成「拼图型」，每个 Agent 的脑子才算真正用在了刀刃上。
这是一场关于「信任模型」的迁移——从「信任主 Agent 的判断力」变成「信任接口设计的完备性」。后者更可工程化，更可控，也更经得起版本迭代。
<!-- 配图：成本对比柱状图——EvoX vs Codex vs Claude Code 每任务美元数 -->
接下来 12 个月，多 Agent 赛道的输赢路径已经分得很开。
继续堆 Agent 数量、加一层主 Agent、买更大的上下文窗口、做更聪明的「总管」——这条路线，会越走越像传统软件工程里「给一个巨型函数不断加 if-else」的窘境。模型变强后，这种路线的边际收益递减得比想象中快。
另一条路，是让一群中等聪明的 Agent，各管自己那一亩三分地，通过清晰接口拼出最终交付——这条路线的真正壁垒，最终落在工程团队对任务结构、接口契约、失败重试这三种基础能力的把握上。
赢家不会是参数最大的那个团队，而是最早把「传话游戏」拆成「拼图游戏」的那个团队。蜂群不是终点。它只是一个起点——证明「多 Agent 没用」的根源不在模型，在结构。结构改对了，1.95 美元能买到的正确率，刚刚够让人兴奋。