多 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 在短上下文里做简单判断，准确率自然高。

这不叫技术突破，这叫把组织架构当成第一性原理来设计。

跟 Claude Code 删掉 80% 提示词是同一件事

两天前，Claude Code 团队发了一篇关于 Claude 5 模型的上下文工程文章。里面有个数据：他们把 Claude Code 的系统提示词删减超过 80%，Coding 评测没有可测量损失。

删掉的是什么？少教动作、把流程放进 Skill、把规则换成接口设计。

翻译成人话：别老告诉模型「做什么」「怎么做」，把战场画清楚，让它自己发挥。

原文里有句话特别形象：之前的提示词像五个产品经理同时站在程序员身后，每个人都在指指点点——「考虑一下这个边界条件」「别忘了那个异常处理」「性能再看看」。当模型不够强的时候，这种唠叨有用。现在 Opus 5 了，还要这么多保姆式指令，反而抢方向盘。

EvoX 的蜂群思路跟这个同频。主从模式里的主 Agent，就是那个「过度工程的指令层」——它不停地把子 Agent 的输出读一遍、译一遍、整合一遍，这个动作本身就引入误差。

两者指向同一个方向：模型变强后，你把接口定义清楚，比管它怎么干活儿重要得多。

<!-- 配图：并列对比——左侧「五个产品经理围着一个程序员」夸张漫画，右侧「蜂群各自筑巢」素描 -->

1.95 美元一单，省的不是算力，是无效对话

成本数据更扎心。

EvoX 每个任务按统一价目表 6.10 美元，如果按缓存计价，低至 1.95 美元。Claude Code 和 Codex 显著高于这个数。

贵在哪？不是模型推理，是来回传话烧 token。

主从模式下，主 Agent 要把任务描述给子 Agent，子 Agent 交结果回来，主 Agent 再消化再输出——同一段信息在多个 Agent 之间反复传输、反复编码解码。这不是并行计算，这是串行扯皮。德勤 2026 年有个报告，说 86% 的多 Agent 项目没法规模化落地。硅谷已经出现「无限智能体死循环」：几个 Agent 协同空转几小时，烧掉上千美元 token，什么也没产出。

蜂群不扯皮。每个 Agent 拿到自己那块活儿，干完交卷，没有中间商赚差价。

组织臃肿的代价，原来在 AI 世界里也精确到小数点后两位。

<!-- 配图：三个 Agent 模式的成本对比表格，突出每任务美元数差异 -->

自组织实验：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 美元能买到的正确率，刚刚够让人兴奋。