梁文锋看到的大模型下一个瓶颈，这个团队在 Agent 系统里也摸到了

最近，梁文锋在一场投资者交流会上，把AGI下一步该往哪走讲得非常直白：

“我觉得最合理的做法应该是全力做通用的Agent，其他的Agent优先级应该更低。

现在的Agent的能力受限，是因为它不能有效地持续学习。”

一针见血地点破了许多Agent产品都没解决的痛点：

Agent不只需要更强的模型，还需要一套能在长任务里持续验证、汇合、积累经验的系统。

今天的 AI 在智力上已经足够聪明。

它缺的是把一群聪明的个体组织成可靠系统的能力。

在这个问题还没有标准答案的时候，一支在自进化方向持续探索的团队——EvoMap，给出了尝试。

蜂群式自进化Agent集群。

Agent之间不再盲目模仿人类社会的组织形式，follow一套僵化的主从关系。

而是根据具体任务，自主分工、并行协作，模拟自然界的蜂群。

在EvoMap团队的新Agent产品「EvoX」中，他们不仅提出了解法，甚至还做了一组内部实验，并且在主流的6个Benchmark上做了验证。

01静态Agent这道墙，大家都撞过

今天大多数Agent任务系统，基本有两种形态。

第一种，把所有任务都塞给一个Agent，让它从头做到尾。

任务短的时候，这种方式最直接。

任务一长，就会出现上下文截断、关键指令被淹没，信噪比急剧下降。

第二种，是现在绝大多数产品都会采用的Agent Team模式。

主Agent拆，子Agent做，最后再汇报给主Agent。

看起来已经是“Multi-Agent”了，但实际却像传话游戏。

每多传一层，就多一次出错的可能。

最后交付的，不一定是每个Agent做出来的最好结果，而是主Agent在有限上下文里重新理解之后的结果。

所以，多Agent真正的瓶颈，从来不是数量。

而是角色协作、多轮辩论或群体涌现的能力。

EvoX选择的是更贴近产品和用户的判断标准：

• 复杂任务能不能被完整覆盖？

• 局部结果能不能可靠汇合？

• Agent系统能不能进化出更有效的组织方式？

这比“有没有调用多个Agent”复杂得多，也更贴近用户。

02EvoX的选择：不是更多Agent，而是可靠蜂群

EvoX的选择很直接。

复杂任务不应该靠一个超级Agent兜底，也不应该盲目模仿人类社会组织形式。

一个人无论能力有多强，在高强度超负荷的情况下总会有决策失误。

更理想的方案是：一项大任务被拆成清晰的part，每个Agent只负责边界明确的一部分，所有part各自完成自己的部分，通过可靠接口汇合，自动拼成最终的完整拼图。

就像大自然中的「蜂群」筑造蜂巢。

团队用100个逻辑任务、250个普通数学任务、63个竞赛数学任务和150个物理任务共同构成的题库做了验证：

一共三次尝试：

模型、题集和判分标准都保持一致。

唯一变化的是Agent完成任务的模式。

在EvoX蜂群模式下，目标任务被拆成尽可能多的「原子任务」。

每道题分发给独立Agent。Agent只处理自己的局部问题，并把答案写到约定位置，最后由程序按题号收集。

在Agent Team模式下，则模拟Claude Code、Codex等Agent产品常见的主Agent调度机制：

主协调Agent先看到完整题目清单，把任务拆成一系列子任务；Agent Team在连续会话中解题、整理报告并返回；主协调Agent再把30份报告合成最终答案。

单体处理模式最简单，一个Agent直接在同一上下文里处理全部任务。

结果很清楚：

同一个模型，同一组题，正确率被拉出了三档。

这份差距可以拆成三层。

• 第一，任务被拆得更小。子任务边界明确，每个原子任务都有处理者和输出位置，覆盖关系可追踪。

• 第二，执行彼此隔离。每个Agent面对的是局部问题，不需要在巨大上下文里反复切换，也不容易被前面几十项任务积累出的上下文干扰。

• 第三，汇合答案不再依赖另一个Agent重新理解。程序按照约定位置收取原子任务结果，正确答案不需要再经过转述、压缩和主观取舍。

蜂群模式的灵魂在于，多Agent的执行结果，在汇总时不再需要被主Agent的有限上下文卡一遍脖子。

而可以由无限多的Agent在边界清晰的拼图画布上自主交卷，最终给出一幅经过可靠合并后形成的完整拼图。

03真正拉开差距的，是166个被丢掉的正确答案

更有意思的是，团队继续往中间过程里追了一层。

他们看了Agent Team模式的记录，发现563个任务中其实已经有373个做对。

但经过报告传递和主协调Agent最终综合之后，交付结果只剩217个正确。

换句话说，有166个一度正确的答案，在最终交付时变成了错误或缺失。

过程正确答案的保留率，只有55.50%。

当然，这些正确答案的丢失不能全部归咎于最后一次汇总。

就像传话游戏，过程里的每次传递都无法保证信息绝对无损，最后的结果就是传到最后一个人时原始信息早已面目全非。

EvoX蜂群真正做对的地方，正是替更多本来正确的答案避免这一风险。

在这种模式下，每道题有固定处理者和固定输出位置，Agent负责解题，程序负责按题号收集答案。

无需其他任何Agent转述、压缩和取舍。

这就是主从式Agent Team模式和EvoX蜂群模式的根本区别。

前者把“汇总”的责任交给更上层，更聪明的模型判断；

后者却只需要“汇合”可检查、可执行、可复现的接口。

在长任务里，这种工程复杂的的差异往往就是效果的分水岭。

04从可靠执行，到自组织蜂群

但这还不是终点。

真实任务不会像 benchmark 一样天然整齐。

有些part会相互依赖，有些需要不同专长，有些会在执行过程中新增、冲突、失败或重复。

更难的问题是：

Agent能不能不只是被分配任务，而是自己形成专长，自己选择伙伴，自己长出组织结构。

因此，EvoX团队又做了第二个实验，把问题收缩到“选择伙伴”这个最小动作上。

实验里，24个相同配置的Agent先各自完成任务。

每完成一个任务，Agent都会把经验沉淀成memory，团队把这类经验记录称为「Gene（经验基因）」。

某类心得积累越多，Agent下一轮选择同类任务的概率就越高。

经过多轮之后，每个Agent都会形成自己的“履历”：

我更擅长什么，正确率如何，过去做过什么。

随后，实验让这些Agent从同一张圆桌关系网出发，随机打断一部分连接，再让Agent自主选择新的连接对象。

结果很有意思。

同一个Agent，仅仅因为看到的信息不同，就会选择完全不同的伙伴。

只看社交信息时，Agent 选择维持原有关系，因此倾向于保留小圈子；

加入任务信息后，Agent会关注候选者的专业侧重和正确率，选择逻辑开始从“朋友的朋友”转向“谁更能把事做成”。

这说明，组织不是凭空出现的。

系统向Agent暴露什么信息，Agent就会长出什么样的连接方式。

给它看社交关系，得到的是熟人圈。

给它看能力和任务反馈，得到的才更可能是面向结果的协作网络。

信息设计，变成了组织设计。

当然，选队友只是自组织的第一步。

下一步要闭环的是协作——

交换Gene、寻找专业互补的伙伴，并在失败时寻找替代者。

如果说实验一证明了EvoX蜂群能把任务可靠做完，那么实验二看到的是更早期、但更令人兴奋的东西：

Agent蜂群自组织形态。

05Benchmark也在验证这条路

技术路线讲得再漂亮，最后还是要看真实任务里有没有效果。

EvoX团队在Opus 4.8同一模型的基础上，比较了EvoX、Claude Code与Codex。

他们在6个主流benchmark，共计424个独立任务中表现如下。

Claude Code通过358个任务，EvoX与Codex都通过338个任务。

Claude Code领先20个任务，差距为4.72个百分点；EvoX达到Codex的同级别水平。

但EvoX的表现不是平均意义上的“刚好追平”，而是已经出现了明确的强项。

细看各个Benchmark：

AppWorld上，EvoX为87/90，仅比最高分少1个任务，比Codex多9个任务。

GAIA上，EvoX与Claude Code同为49/51，并列最高。

SWE Multilingual的三家差距最小，Claude Code、Codex、EvoX分别通过68、66、65个任务。

短板也同样明显：Terminal-Bench 2和Cybench，是接下来最需要补的两块。

这组结果真正说明的，不是某个单点模型突然变强了。

而是Agent系统本身开始有了可衡量的产品能力：

能拆任务，能并行推进，能保住中间正确结果，也能在复杂环境里更稳定地交付。

06省钱！省钱！还是省钱！

Benchmark往往有一个容易被忽略的维度：成本。

按统一价目表计算，EvoX每个任务的成本为6.10美元，在三家中最低。

按实际缓存计价为1.95美元，接近Claude Code，明显低于Codex。

这组数字至少说明了一件事：EvoX不是靠无限堆预算换分。

这点对产品尤其重要。

真正可持续的Agent，不应该只是“多跑几轮一定更好”。

它应该知道什么时候拆、拆给谁、如何验证、如何汇合，以及失败后如何低成本重试。

能力要能交付，成本也要能被控制。

07跑分之外，是新的技术路线

如果只把EvoX理解成一个benchmark工具，就太窄了。

但也要把边界说清楚：目前的版本仍然在beta阶段。

它已经在一批真实任务和内部实验里展示出方向性的优势，但还不能被包装成一个已经解决所有Agent问题的完成品。

更准确的说法是，它正在把Agent产品从一次性工具，推向一个可以持续演化的系统。

今天的模型API更像一次性交易：你给token，它给答案。

EvoX想做的，是把这件事变成持续变强的关系。

任务越跑，系统越知道怎么拆。

经验越多，Agent越知道谁擅长什么。

反馈越充分，蜂群越能形成更有效的组织。

每一次拆解、每一次失败、每一次成功汇合，都可以沉淀成后续组织方式的参考。

长期看，客户买到的就不只是token结果，而是一套逐渐了解任务边界、团队偏好和业务环境的Agent基础设施。

这也解释了为什么memory、Gene、任务边界、结构化汇合、失败重试和多Agent网络如此重要。

它们看起来不像一个炫目的模型能力，却决定了AI能不能从“会回答”走向“能交付”。

真正走向生产环境，还需要继续验证权限隔离、成本控制、失败恢复、边界任务和长期记忆污染等问题。

所以今天我们看到的，不是“问题已经全部解决”。

而是：他们已经找到了一条值得持续投入的工程路线。

08Agent的下一道门在哪里

这条路线很容易让人想到强化学习之父 Richard Sutton 的那篇《经验时代》。

他的判断是，下一阶段AI的能力提升，不会主要来自继续吸收人类已经产生的数据，而是来自真实环境里长期行动、获得反馈，并持续学习。

放在Agent系统层面，就是自组织蜂群。

静态Agent这道墙，需要被持续进化的系统推倒。

EvoX现在做的，就是在这条路上先跑出一段看得见的距离。

大模型竞争的下一阶段，绝不只是“谁的模型更聪明”。

还要看谁能让任务被正确拆开，谁能让经验真正留下，谁能让一群Agent在没有中央大脑兜底的情况下，把事情做完。

模型们已经站在起点上。

能不能把正确结果送到终点，才是Agent真正要跨过的下一道墙。

朋友圈会发一些具体的案例和商业化日常～

AI交流，欢迎加我本人微信：FrankGPTs