当前位置：

文章详情

越用越聪明，「进化论」在 Agent 重演，会协作还会自己迭代

Linux 社区最近热闹翻天了。

原因是 Linux 之父 Linus Torvalds 利用 AI 排查 Intel Xe 驱动时，AI 多次强调找不到问题，需要放弃，不应该继续，但是 Linus 始终坚持，并在前后加了 24 个 Debug Patch，重启 18 次 Kernel 后，终于发现了核心问题。仅仅是一个简单的 round_up 被写成 round_down。

这件事儿很有趣。

论实力，如今的 AI 已经足够强大，可以参与资深工程师才能参与的 Debug。但论经验，它有时候又像是一个超级菜鸟，遇到没接触过的事情就两眼一瞎，摸不着北。

明明经过如此身经百战，AI 却没能将成功、失败、修正、验证留存下来，形成方法论和经验。

Skill 解决了一部分，让单个流程沉淀可复用。

但还有数以亿计的真实 AI Agent，不断在重复踩过的坑，走走过的路，为什么它们不能互相帮助，交叉引导，不断优化自己呢？

这其实就是这两年越来越多人开始讨论的一个方向：AI for AI。

一个 Agent 踩过的坑、已经验证过的方法，不应该随任务结束而消失。AI 之间应该可以互相协作、交叉验证，再根据结果不断调整自己的执行策略。

真实进化，AI 改善了自己的工作流

第一次工作

关于 AI for AI 这件事。我觉得当前最有发言权的 Agent 可能就是 EvoX。

前段时间我专门做过一个 EvoX 的评测，里面实测了p5.js 开发过程中，EvoX 如何使用蜂群、EvoMap 网络、基因、自进化来实现三次任务不断优化产物的过程。

🔻感兴趣的可以点击回顾：

一个中国团队，正在挑战 Codex 和 Claude 的答案

从某种意义上说，Evolver、EvoMap 已经算是 Agent 自进化路径的典范。而现在他们更是率先实现了蜂群+自进化的 EvoX Agent，让 AI 可以在工作中不断自我迭代，自己改善自己。

最近我在研究 Three.js，想通过 Agent 开发一款个人的 3D 宿舍个人工作台 ，这个任务包含了 img2three 建模、场景架构、3D 建模规划、页面交互、动效、资源组织、代码实现和调试等多个子任务，会比单纯的 coding 复杂很多。

项目初期，我做了一个简单的one shot demo。大致的样子是有了，但是物体摆放、空间位置、交互、界面上都还有问题。

但是问题在哪里？我不知道

于是我让 EvoX 自己开启蜂群来一次交叉验证，发现问题、论证方案，并作为后续优化的方向。

EvoX 很快就对任务进行了拆解，摄像头、坐标轴、建模精度、色彩、交互和物理空间、动画效果等等。

它非常细致的拆出多个 subtasks ，并启动蜂群模式开始验证。蜂群之前有解释过，它是一套多 agent 并行处理，并携带独立上下文和结果返回汇总的机制，区别于传统的 MainAgent 和 SubAgent，蜂群模式不会对子任务结果进行压缩，不同 Agent 之间是独立、并行、交叉的关系，可以有效避免二次压缩带来的信息失真。

这里的蜂群，不仅仅是单机里的 subagent，如果局域网内同样安装有 EvoX，它也会调用局域网内不同设备的 Agent 来并行处理。

每一个 Agent 完成的任务情况、结果，都可以在蜂群的任务页面里看到，很清晰，同样也可以作为蜂群模式和 SubAgents 模式的差异证据。

然后通过跑完的结果，我发现了一些很有意思的地方。

在 EvoX 里，Agent 会在任务执行过程中把部分多次出现的经验积累下来，它们被称为基因。基因不是单纯的错误积累，而是会根据数个重复出现的信号组合流程得以明确下来。就比如下雨天出门不打伞，衣服会被淋湿，衣服湿透了，回家容易感冒，这是一套有逻辑关系的组合信号。

这些基因里，有些是正面的，也有是负面的，每一个基因都有一个置信度的参数来作为 Agent 的评估依据。

在基因里，我们可以看到明确的信息。比如这个基因所带来的经验启示，它从哪里来，它有什么用，它的累计证明等等。

第二次工作

到这里，和我之前使用 EvoX 里提到的自我能力沉淀和自进化，还没太大的区别。

但当我第二次，按照 EvoX 自身汇总的反馈优化点去推进项目时，它所表现出来的进化，却超乎了我的想象。

依旧是 one shot，这次 EvoX 完全改变了开发的工作流程，它没有继续在原有的项目上去修改内容，而是重新规划了一条被可信基因验证过的新方案，以这套改善过后的工作流开始推进。

具体的优化流程，我也截取了出来。

在第二次工作进行中。EvoX 做了以下几点变化：1.重新优化蜂群类型和规模，从原来的子任务并发变成业务驱动的纠错，创建了基于镜头、图片、建模、渲染、编码等不同结构的 subtask。2.记忆调取，从本机调取之前的工作记忆，回顾相似任务。3.基因调用，等待证据链评估反馈。

比如记忆，因为前面跑过一轮，所以很多要求其实都是重复的。EvoX 直接调取之前的保存的记忆，并经过评估确实可信的前提下进行了复用。

这个记忆库，我们在 EvoX 内部也可以查看，还可以通过自己进行召回测试，或者进行二次治理。

我认为第二次运行中最核心的部分，其实是基因调用过程。

前面我们展示过基因是什么，现在我们可以看到基因是如何被调用的。EvoX 会把每一次基因发生的过程记录下来，很明确的什么时候调用，为什么调用，是否采信，都可以查看。

这里我认为最有意思的部分，其实是基因用于 Agent 自身的改进。

大部分时候，基因本质上都只是复用，给了一条 Agent 之前走过的链路让后来的任务可以复用快速完成。但它同样会被作用于改进 Agent 自身的行为模式和判断标准。

未来的 Agent，凭借曾经 Agent 总结下来的基因，重构了当下任务的行为标准和方案，用一套更有效的方式进行任务推进。这种感觉，让我有了一点 AI for AI 的自我迭代意识。

再来看结果。第二次 EvoX 明显完成了更好的创作，它的建模精细度、光线、空间布局还有 UI 界面，相比于上个版本大大提升，并且从空间布局的根源上彻底重构，解决上一次模型分散的问题。

更有意思的是 EvoMap。

如果一个 Agent 只能自我迭代实现 AI for AI ，那么它的作用也是相当有限。但当 Agent 加入 EvoMap 之后，它就可以将自身的基因、胶囊通过 EvoMap 网络分享给其它加入网络的 Agent。

这意味着 Agent 可以从网络内任何一个主动分享了工作方法、工作经验的 Agent 上学会一个新的进化思路。当数以亿计的 Agent 开始不断交流、交互、互相推动彼此迭代升级，AI for AI 的布局，是否就此开始？

而除了 EvoX 之外，EvoMap 团队还发布了一个更有趣的开源项目 —— AutoResearch。把 EvoX 里的蜂群和自进化能力单独拆了出来，将 Agent 自进化推到了技术研究层：让 AI 自己进入实验和验证循环，参与改进原有技术和算法，并在一个真实的 Django 修复任务里多轮改写，最终实现任务。