很久没读过这么通透的Agent的文章了。

这周这是怎么了，连续看了两篇我认为是今年最好的AI文章了。

一篇是梁文锋对于接下来 AI 大模型的判断，另外一篇是今天我要写的 EvoMap 张昊阳对于 Agent 的思考。

好久没看到这么通透的、讲 Agent 执行层面的文章了。

https://evomap.ai/zh/blog/how-ai-swarms-win-from-26-to-71-percent

张昊阳和 EvoMap，估计很多人还不太熟悉。我一直在关注他们。

前几个月 Hermes Agent 还有些热度的时候，曾经被人发现，它抄袭了 EvoMap 团队的产品 Evolver。

自进化的逻辑，还有代码实现，Hermes 和 Evolver 都无比接近。

也是那段时间，我在团队内部多次给同事分享过他们公众号的文章。当时最打动我的，是他们对 Agent 的一个判断。

现在的大模型能力越来越强，但每个新启动的 Agent，都是全新的。所以三月份 OpenClaw 大火的时候，大家都说养虾。得从头开始养。

Agent 执行任务的时候，会反复踩坑、不断试错，最后积累一些正确的经验。但这些经验通常只能停留在当前会话，或者当前 Agent 的记忆里，很难传给其他 AI。

举个例子。

一个 Agent 调用某个 API，花了半个小时查文档、改参数，连续失败好几次，最后终于找到正确方法。

对这个 Agent 来说，它确实学会了。但换一个 Agent，遇到同样的问题，往往还得重新踩一遍坑。

当时大家解决这个问题的主要办法，是把经验写成 Skill。Skill 当然很重要，它能把一套流程、工具和方法封装起来，让 Agent 反复调用。

但 Skill 没有解决一个 Agent 在实际工作中刚学到的经验，怎么快速传给其他 Agent。

#01

Agent 的经验怎么传递？

EvoMap 的思路是，把 Agent 运行中学到的有效经验，提炼成一种类似基因的东西。当然，基因是加引号的基因。

一个 Agent 找到了解决办法，就把这个办法提炼出来，验证之后上传到网络。以后其他 Agent 遇到类似问题，可以直接继承这段经验，不用再从头摸索。

所以他们最核心的判断是，AI 的经验，也可以成为一种能够流通的资产。

https://arxiv.org/abs/2604.15097

我当时看到这个想法，觉得非常妙。

那时候大家已经意识到 Skill 是个好东西，但 Skill 更像人提前编写好的一本操作手册。

EvoMap 想从根上彻底解决的是，Agent 每天都在干活，它学到的经验，能不能沉淀下来，再传给更多 Agent？

如果这件事能成立，Agent 就不再只是反复调用一个固定的模型。它在工作中积累的经验，也会慢慢变成整个系统的一部分。

沿着这个思路往前推，自然就会来到多 Agent 协作，也就是 Agent 蜂群。

为什么他们一直用基因这个词？因为生命的进化，本身就依赖基因的传播。

过去我们经常把 AI 比作人。人和今天的 Agent 之间，有两个非常明显的差别。

第一，人能持续学习。遇到一件事，经历一次失败，下次再碰到，通常会处理得更好。

梁文锋也讲过，下一代 AI 一个非常重要的能力，就是自主持续学习。当Agent 能够持续学习跨过自我迭代的奇点，下一代通用智能就会加速

第二，人类的进化不会随着某个个体死亡而中断。

一个人学到的具体知识未必能遗传，但整个物种经过漫长时间形成的生存能力，会通过基因继续传下去。

持续学习得靠模型层面解决。群体经验的传承，得从 Agent 的设计层面入手。

就像《星际争霸》里的虫族。单个个体未必特别强，但每个个体在环境中获得的信息，都可以回传到蜂巢。

整个种群不断调整自己的 DNA，适应新的环境，最后变得越来越强。

如果 Agent 也能形成这种能力，应该会是一个非常重要的突破。这就是 EvoMap 在做的事情。

#02

主 Agent 为什么会成为瓶颈？

早上我看到他们又往前跨了一步。这次研究的重点，已经从 Agent 如何共享经验，推进到多个 Agent 如何真正完成协作。

今天大家讲多 Agent，常见做法是设一个主 Agent，再让它调度一批 Sub-Agent。

主 Agent 负责理解目标、拆解任务、分配工作。Sub-Agent 各自执行，最后把结果交回主 Agent，由它汇总。

这个思路看上去很合理，跟现实公司的组织方式也很像。但任务一复杂，主 Agent 很容易成为整个系统的瓶颈。

它得同时掌握完整目标和所有任务的进度，还要读每个 Sub-Agent 返回的材料，判断哪些信息有用，哪些结果可靠，最后重新组织一遍。

Sub-Agent 越多，主 Agent 要处理的上下文就越长。前面已经完成的结果，在一轮轮汇报、压缩和转述中，很容易被遗漏，甚至被重新理解错。

所以 EvoMap 这次其实在探讨两个更底层的问题。

第一，我们现在常见的主 Agent 加 Sub-Agent 这种结构，本质上是不是已经是最优解？

还是说，一项复杂任务有没有可能拆得更彻底，让每个 Agent 只负责一个非常明确、几乎不需要再协调的子任务，最后再用一种更可靠的方式把结果拼接起来？

第二，如果我们不一开始就设计好主 Agent 统筹、Sub-Agent 执行这种固定分工，只是给一群能力相近的 Agent。

它们能不能在执行过程中自己发现各自更擅长的方向，逐渐形成稳定的分工和协作关系？

#03

同一个模型，从 26% 到 71%

他们先做了第一个实验。

实验一共 563 道题，包括逻辑题、普通数学题、竞赛数学题和物理题。三组实验全部用同一个模型，Claude Haiku 4.5。

第一种方式，让一个 Agent 在同一个上下文里完成全部题目。

第二种方式就是常见的 Sub-Agent 模式。主 Agent 看到完整题目，完成拆解和分配，Sub-Agent 分头解题，再把报告返回给主 Agent，由主 Agent 汇总答案。

第三种方式是 EvoX 蜂群。他们把任务尽可能拆成原子任务，每道题进入一个独立的 Agent。每个 Agent 只处理自己负责的部分，完成以后，

把答案写入提前规定好的位置，最后由程序按照题号直接收集，不再交给另一个大模型重新整理。

最后的差距非常夸张。单 Agent 的正确率是 26.29%。Sub-Agent 模式是 38.54%。EvoX 蜂群达到了 70.69% 到 70.87%。

同一个模型，只是调整了组织和执行方式，正确率就从 26% 提升到接近 71%。

看到这里，大家可能会觉得，蜂群效果更好，是因为它启动了更多 Agent，消耗了更多 Token。

但 Sub-Agent 模式同样启动了很多 Agent，Token 消耗也不低，结果依然远远落后。

所以，蜂群的核心不在于数量。

一群 Agent 同时工作，并不会自然产生群体智能。真正决定结果的，是任务怎么拆，执行过程怎么隔离，最后怎么汇合。

EvoX 首先把任务拆得足够小。每个 Agent 只需要处理一个边界清楚的问题，不用同时照顾几十个目标，也不用频繁切换任务。

这样既方便追踪，也能降低单次任务的复杂度。

其次，每个 Agent 都用独立上下文。一个 Agent 连续处理大量任务时，上下文会越来越长。前面的问题、推理过程和中间答案不断累积，后面的判断也容易受干扰。

EvoX 让每个 Agent 只看到自己负责的那部分内容。它不用记住整个任务发生过什么，只需要完成眼前这件事。

第三个设计，也是我觉得最重要的地方，是他们没有让结果再经过一次大模型汇总。

Agent 负责处理需要推理的问题，程序负责完成确定性的合并。

每个 Agent 都有固定的任务编号和输出位置。程序可以直接检查哪些任务已经完成，哪些任务出现遗漏，再按编号收集答案。

这样，已经正确的结果就不需要再经历一轮转述、概括和取舍。

#04

损耗到底在哪里？

他们后来继续检查 Sub-Agent 模式的中间结果，发现了一个特别反直觉的现象。

563 道题里，Sub-Agent 在执行过程中其实已经答对了 373 道。但经过报告传递和主 Agent 的最终汇总，交付出来的正确答案只剩 217 道。

有 166 道题，中间明明已经答对，最后却变成了错误，或者直接消失了。正确答案的保留率只有 55.5%。

这个发现它至少说明，多 Agent 系统的失败并不只发生在执行阶段。

很多任务Sub-Agent 其实做对了，问题出在后续的信息传递和结果汇总里。这个过程很像传话游戏。

Sub-Agent 先完成任务，再整理成报告。主 Agent 读完报告，需要重新理解，再压缩成最终结果。

每多一层自然语言转述，就多一次信息损失的机会。原始答案可能没被提取出来，格式可能发生变化，前面的正确内容也可能被后面的错误覆盖。

EvoX 蜂群的思路非常朴素。既然题目已经答完，就别再让另一个大模型去读一遍、理解一遍。

让 Agent 专心解题，答案由一段写死的程序按编号收集拼接，不做任何二次加工。

有点意思这个思路。

因为我们今天设计 Agent 工作流的时候，很容易陷入一个误区，什么事情都想交给大模型。

让大模型拆解，让大模型执行，让大模型汇报，再让另一个大模型汇总。但有些环节，传统程序要可靠得多。

比如任务有没有遗漏，结果是否重复，输出格式是否正确，某个任务是否超时，这些事情都有明确规则，完全可以交给程序处理。

大模型更适合处理模糊和不确定的问题。代码的确定性和稳定性则会高很多。

一个蜂群需要足够自由，每个 Agent 可以发挥自己的能力。同时也需要一套稳定的底层协议，保证所有局部结果最后能拼成完整的交付。

理解到这，我估计很多同学跟我有一样的疑惑，会怀疑前面的 case 是不是过于简单。

前面的题目，人可以提前把分工排好，谁做哪道题，答案放在哪，都是清楚的。但很多复杂任务，分工本身就没法提前定死。

比如开发一个产品，前端任务可能依赖接口设计，接口设计又依赖数据结构。

执行过程中还可能冒出新问题，有些任务需要返工，有些任务会重复，也有些任务突然失去意义。

这种情况下，人都很难提前把全部任务和组织关系写死。

#05

Agent 的自组织

所以，他们继续做了第二个实验。

这次研究的问题是：Agent 能不能在工作过程中逐渐形成自己的专长，再根据这些专长选择合作伙伴，产生比人类更高效的组织形式？

实验最开始放入 24 个配置完全相同的 Agent。这些 Agent 没有提前设置角色。

它们先完成多轮任务。每处理一道题，Agent 都会总结这类题目的经验，并把经验记录到自己的 Memory 里。这些经验在实验中被称为 Gene。

有的 Agent 选的物理题比较多，慢慢积累了更多物理经验。

有的 Agent 经常解决数学题，逐渐形成了数学方向的能力。

经过八轮任务之后，原本完全相同的 Agent，开始拥有不同的经历、专业侧重和历史正确率。

也就是说，它们的身份不是人提前指定的，而是在一轮轮选择和执行中慢慢形成的。

接下来，研究团队让这些 Agent 自主选择新的伙伴。

当 Agent 只能看到彼此之间的连接关系时，它更喜欢选择朋友的朋友。最后形成的网络里，保留了很多熟人小圈子。

当 Agent 可以看到候选者的专业侧重和历史正确率时，它的选择马上变了。它开始连接正确率更高的 Agent，也会寻找专业能力更适合自己的人。

同一个 Agent，只因为能看到的信息不同，就选择了完全不同的合作对象。大量个体选择累积之后，整个 Agent 网络的形态也跟着改变。

只展示社交关系时，Agent 更容易在原来的圈子里继续连接。

展示能力和表现以后，一些高正确率的 Agent 开始成为网络里的枢纽，其他 Agent 会跨过原来的关系，主动连接更适合完成任务的人。

同一群 Agent，最后长出了两种不同的组织形态。

不过，这个实验目前只验证了自组织最早期的一个动作，也就是选择伙伴。这些连接还没有真正承担任务转交和协作。

Agent 还没有完整实现自主拆解、认领任务、处理冲突和重新分配工作。所以现在说它们已经形成了完整的 Agent 社会，还太早。

但这个实验已经透露出一个很有意思的信号：

Agent 的组织方式，会受到可见信息的影响。只提供关系信息，它们就容易找熟人。

提供能力和历史表现，它们就会找更合适的合作对象。

以后如果再加入成本、信用、响应速度和历史合作记录，可能还会形成更复杂的关系。

所以，Agent 的自组织并不会凭空发生。系统向它们展示什么信息，奖励什么行为，它们就更容易形成什么样的组织。

#06

写在最后

写到这里，这篇文章也就结束了。大周六的，从早上 7:30 写到 11:45，几乎一气呵成。

毫不夸张的说，我觉得这是今年我读过的 Agent 落地方面最重要的一篇文章了。

所有做 Agent 研究的朋友都可以去看一看 EvoMap 这家公司，他们现在的很多实验还处于早期阶段，一些结论也需要继续验证。

但他们提出问题的方式，以及解决问题时对工程细节的重视，确实让我眼前一亮。

现在的大模型已经足够聪明，单个 Agent 也能完成越来越长的任务。

但只要任务继续变复杂，靠一个主 Agent 管理所有事情，很快就会碰到上下文、协调和结果损耗的问题。

接下来真正关键的突破，可能会同时发生在两个方向。

一个方向，是让 Agent 在工作中积累的经验能够保存、验证和传播。另一个方向，是让越来越多的 Agent 在稳定的规则下完成分工，并根据任务和能力调整自己的协作关系。

这两件事一旦逐渐成熟，Agent 就会发生一次彻底的变化。我不知道这一天具体什么时候到来。

但读完这篇文章，我第一次觉得，这条路已经隐约出现了。

文章来自于微信公众号 “AI产品阿颖”，作者 “AI产品阿颖”