模型一个没换，正确率翻了近三倍，这个项目有点东西啊！

大家好啊，我是开源君！

先给大家看组数字：

563 道逻辑、数学、物理题。 同一个模型，Claude Haiku 4.5。 一次都没换。

单个 Agent 自己上，正确率 26.29%。 换成常见的 Sub-Agent 模式，38.54%。 换成 EvoMap 的蜂群模式，**70.69% ~ 70.87%**。

差了将近三倍。

说实话，我第一反应是，这数据是不是夸张了。

翻源码之后，发现还真不是。

这背后是一个叫"蜂群"的机制。而把它真正跑起来、用数据验证的，是 GitHub 最近开源的一个项目——AutoResearch。

圈里管这种玩法叫 AI4AI：用 AI 去改进 AI。 

项目简介

AutoResearch 是 EvoMap 开源的一个多 Agent 评审系统，一句话概括：让 AI 自动做科研。

从提想法、设计实验、跑实验、写分析，到最后的自我审查，一整条链路全靠 Agent 协作完成。

拆开看其实不复杂：把"一个博士做科研"这件事，拆成四个角色——计划、实现、运行、审查，各干各的，互相配合。

这套分工不是 AutoResearch 自己发明的，底子就是 EvoMap 的蜂群机制——任务拆解、动态组队、并行执行、协同决策。

换句话说：AutoResearch 是考题，蜂群是解题方法。

顺带一提，这套蜂群机制也内置在 EvoMap 旗下的 EvoX 里。一个用在科研，一个用在日常协作，内核是同一套。

核心特点

特点一：没有指挥官

先说架构。现在主流的多 Agent 方案，大多是 Sub-Agent 主从式。

一个中心 Agent 站在中间。任务是它分的，结果是它收的。

问题就出在"收"这一步。

中心节点要理解所有子 Agent 的产出，压缩、归并、再输出。信息只要被重新说一遍，就会丢。

EvoMap 的蜂群，把中心节点直接拿掉了。

没有指挥。

大量 Agent 平级连接，按任务信号自己选协作对象，自己组队。

那结果怎么汇总？

答案是：不让模型去汇总。

结果由程序做确定性汇合。 该并的并，该判重的判重，不经过任何一次"再用大模型复述一遍"。

从机制上，直接把那层损耗抹掉了。

特点二：不让模型给自己打分

刚才说了，它把流程拆成四个角色：计划、实现、运行、审查。

一个提方案，一个写代码，一个跑实验，一个专门挑毛病。

听起来平平无奇。门道在这一句——

计划、实现、运行、审查，不再挤在同一次模型回答里。

为什么重要？

因为大模型最擅长的，是自我说服。

你让一个模型在同一段上下文里既写方案、又写代码、又验证、又评审，它会非常自然地把前面编的东西当成既定事实来引用。

最后自我评估，圆满通过。

这不是模型笨。是结构上就给了它作弊的机会。

拆开之后就不一样了。

写代码的那位看不到评审的那位在想什么；评审的那位拿到的只有产物和指标，不会被"我当时其实是这么想的"污染。

AutoResearch 里还有个设计我很喜欢：盲审。

源码里管这个审查角色叫 critic——先挑战结论，系统再做一轮"不知道对方当时怎么想"的独立复核，只能看证据说话。

这就是从工程机制上，去压 AI 幻觉这类先天缺陷。

特点三：防幻觉，不是靠提示词，是靠证据链

防幻觉靠的不是提示词写得好、多叮嘱几句"如实作答"。

AutoResearch 靠的是证据链：结论必须对应一条可核验的执行记录，自然语言断言不算数。

写代码的说"跑通了"没用，系统要的是那次运行的日志和测试结果。到审查这步，看的也不是"话说得有没有道理"，是这些记录本身——对不上，这轮结论就不成立。

完成的判定权也不在做事的人手里。在官方技术文档中显示，在 Django 修复任务中，AutoResearch 第一轮，本地测试其实全过了，官方只给 2/7——它没辩解，按外部结果重写问题，一路改到 7/7。做的人说"成了"不算，下一关的验证说了才算。

失败也不例外，原样记录进系统，成为下一轮迭代的输入，而不是被悄悄抹掉、换个说法糊弄过去。

执行记录说话、交接处核验、失败入库——这套证据链，才是压幻觉的底气所在。

特点四：损耗在传递环节，不在执行环节

这一段是全文我最想讲的。

EvoMap 在那 563 道题的实验里，记下了一个数字。

Sub-Agent 模式跑到中途，子 Agent 们实际上已经答对了 373 道。

但结果经过中心节点汇总、最终交付之后——只剩 217 道。

保留率 55.5%。

将近一半的正确答案，在"把结果汇报上去"这一步里没了。

以前我也这么想：多 Agent 效果不好，是子任务没执行好。

数据说的是另一回事：执行环节没问题，是传递环节在漏。

活干得挺好，汇报的时候漏了。

而蜂群凭什么能到 70% 以上？

不是它的 Agent 更聪明。是它压根没安排"汇报"这个动作——每个 Agent 独立上下文，结果由程序确定性汇合。

日常场景案例展示

前面讲的都是技术，落到地上是什么样？

说三个场景。

1. 早高峰的写字楼电梯

早上八点五十，一栋 30 层的写字楼。

大堂挤着两百个人。六部电梯全在跑。你要去 27 层，眼睁睁看着 3 号梯在你这层停了、开了门，里面塞满了人。

等了四分半。你迟到了。

这个问题存在了几十年，不是没人解。

现在大部分写字楼用的是群控调度：六部梯交给一套中央算法统一分配，算"哪部离得近""哪部顺路"，然后派单。

听起来挺聪明。但卡住了。

因为中央算法拿到的是几秒前的状态。谁按了按钮、哪层有人在等、哪部刚关门——信息传到中心、算完再下发，电梯早跑过去了。

早高峰每秒都在变。中心节点算得越复杂，决策越滞后。

这就是前面说的传递环节损耗，只不过发生在电梯井里。

换一种思路会怎样？

每部电梯自己掌握自己轿厢的状态，自己决定"这趟接不接这一层的活"；楼层侧自己广播需求；最后用确定规则把分配结果拼起来，不等中心算完再下发。

不是让算法更快，是让决策不用都挤到一个地方。

这跟 EvoMap 蜂群处理多 Agent 协作的思路，其实是同一件事。

等电梯的人，平均等待时间往下走。物业，同样六部梯运力提升，不用花几百万加装电梯。至于写字楼——上班不用排十分钟队的楼，租金是能多要的。

2. 城市路口的红绿灯

再说个每个人都遇到过的。

一条主干道，八个路口。

运气好，一路绿灯。运气不好，每个路口停 40 秒。

现在大部分城市的信号灯用的是固定配时：早高峰一套、平峰一套、夜间一套，写死在设备里。

好一点的会加地感线圈，检测有没有车，稍微调一调。

这套东西上世纪就有，成熟、稳定，但也基本摸到天花板了。

为什么难再优化？

因为一个路口的配时会影响下一个路口的车流，下一个又影响下下个。八个路口的组合是个天文数字。

中心系统要一次算完所有路口再统一下发——算得慢，还不敢乱调，怕一个路口调崩了，整条路堵死。

所以大部分城市宁可用保守方案。

如果每个路口自己算自己的呢？

每个路口只看自己这一段和相邻路口的状态，自己决定放行多久，最后按确定规则拼成区域协同方案，不用等一个中心大脑把八个路口全算明白。

某个路口出了事故，它自己先改，旁边的跟着改，不用等中心重算全局。

这套东西最像蜂群的地方在于：它不追求全局最优，追求的是每个局部都不算错。

通勤的人，一路红灯变少了。公交和救护车，通行时间更稳定。城市这边——不修一条路，只改配时逻辑，通行能力就能往上抬一截。

这是最便宜的"修路"。

3. 超市的补货与临期定价

最后一个，可能你今晚就会遇到。

晚上八点以后，超市熟食开始打折。九点七折，九点半五折。

这套规则的底层，是经验。

店长凭经验下单：明天大概能卖多少盒酸奶，进多少。卖不掉就打折，折到什么程度也凭经验。

结果两头亏：进多了，损耗；进少了，缺货，顾客白跑一趟。

生鲜损耗率全行业一直下不来，就是卡在这。

为什么难？

因为"明天卖多少"受太多东西影响：天气、发薪日、隔壁新开的店、昨晚那场球赛、周末还是工作日。

传统预测模型能做到一定精度，然后就停在那儿了。

不是模型不好。是没人能持续地、低成本地迭代它。

而"不断试、不断改、改完验证、验证完再改"，恰好是 AI 最擅长、人最不擅长的事。

让一套系统自己去跑：换个模型试试？加个天气特征试试？补货和定价一起优化试试？每次都拿真实销量裁决，不行就撤回来，把失败也记进证据里。

这样一来，超市，损耗降下来，这一块直接进利润。顾客，晚上买到更便宜也更新鲜的东西。往大了说，少扔掉的食物是实打实的资源。

三个场景的共同点

电梯群控、信号配时、销量预测。

这三个场景，看着不相关，其实是一个问题。

都不是没有算法，而是有一套跑了很多年、已经很难再优化的老算法。

这些领域都不空白。恰恰相反，它们被研究了很久，剩下的全是硬骨头——靠人去啃，成本高，迭代慢。

而这恰好是 EvoMap 这套机制对得上的地方：用现在的 AI 技术，去优化那些业务里发展停滞的老算法。

小结

回到开头那个问题：26% 到 71%，到底是谁的功劳？

不是模型，它自始至终是同一个。也不是 AutoResearch 凭空造出来的调度逻辑。

是 EvoMap 的蜂群。

往大一点说，EvoMap 把 AI4AI 从愿景变成了成果。

AutoResearch 这个"AI 改进 AI"的科研项目，本身就是蜂群协作完成的产物。它验证了一件事：一群 Agent 在好的机制下协作，能做到单个模型做不到的事。

战绩也在官方技术文档里摆着：Django 修复任务，官方新增功能测试从 2/7 推进到 7/7，203/203 回归测试全程通过。

同一套让Agent分工、协作、审查和沉淀经验的机制，也已经内置在EvoMap旗下的EvoX产品中。

AutoResearch让开发者从源码里验证这套机制，EvoX则让普通用户直接使用它。 想看这群Agent究竟如何协作，可以直接阅读AutoResearch源码；想亲自体验蜂群如何完成任务，也可以进入EvoX Beta版。

更多细节，可以到直接到下方地址进行查阅：

GitHub：https://github.com/EvoMap/AutoResearch
技术文档：https://evomap.ai/zh/research/autoresearch-evidence-loop