EvoX Genesis：持久递归世界机制，44美元自主生成25万行代码
Persistent Recursive Worlds Enable Autonomous Software Evolution
在复杂软件系统的生命周期中，存在一个基础却常被忽视的矛盾：软件项目的存活时间，远远超过任何单个代码贡献者的参与周期。当大语言模型被引入代码生成领域时，当前的智能体开发范式几乎都在试图解决一个死胡同般的问题——如何让 Agent 拥有更长的上下文、更持久的记忆或更全局的管理者权限，以维持开发过程的连贯性。香港理工大学的研究团队提出了一项名为 EvoX Genesis 的全新框架，直接颠覆了这一思路。
ArXiv URL：https://arxiv.org/abs/2608.10450v2
EvoX Genesis 不再试图延长单个 Agent 的生命周期，而是将“持久性”交还给软件项目本身，让局部 Agent 保持有限的生命周期和短促的执行过程。通过将软件表示为一个持久的“递归世界”，该框架在空白仓库中利用 DeepSeek V4 Flash 模型，仅耗费 44 美元的 API 成本，历时 120 小时自主构建了一个包含近 25 万行代码的 Rust 版 C 编译器，并成功通过了严苛的 LLVM 和 Csmith 测试。此外，在针对复杂天体物理学软件 MESA 的重构中，该框架成功将超过 10 万行 Fortran 代码重写为 Rust，在保持核心数值计算完全一致的前提下，实现了最高 6.87 倍的性能提升。
这篇论文的核心贡献在于证明了长周期的自动化软件开发不需要一个全知全能、具有无尽记忆的持久化智能体，而是可以通过一个带有版本历史和路径约束的持久化项目空间，配合无数次短促的智能体实例化来实现。
放弃持久化智能体：软件开发的连续性悖论
长周期的软件开发从来不是一个被无限拉长的单一编码任务。一个存活数月或数年的代码仓库会不断积累接口约束、测试用例、架构承诺、部分妥协的解决方案以及历史遗留的失败尝试。这些庞杂的沉淀物构成了后继者进行修改时的硬性边界。当前主流的代码智能体基准测试，往往聚焦于单次问题修复或多步的代码库构建。为了在这些任务中维持连续性，业界普遍采用的方法是扩大上下文窗口、引入持久化记忆机制，或是设计一个具有全局视角的管理者智能体来共享便签本。
这些方法本质上都在试图延伸智能体自身的生命线。然而，研究团队提出了一个更触及灵魂的反问：当处于活跃状态的智能体注定会终止时，到底什么才是必须持久化的？
EvoX Genesis 给出的答案是：连续性属于软件项目，而不属于智能体。在这个系统中，被接受的项目状态及其历史版本是持久存在的，而局部智能体则是即插即用、用完即毁的。一个生命周期有限的智能体只需基于当前被接受的版本和特定的代码库路径进入项目，完成一个有边界的任务，提交更改建议，然后直接终止。这种设计极其巧妙地剥离了两个经常被混为一谈的时间尺度：单个代码智能体的生命周期，以及整个软件开发进程的生命周期。前者可以保持在模型上下文限制和计算预算的安全边界内，而后者则可以跨越成千上万个执行片段、无数个并发的智能体，甚至跨越不同的基础大模型平滑延续。
持久递归世界的数学与架构表达
为了将上述理念工程化，研究团队将 EvoX Genesis 组织为一个持久递归世界（Persistent Recursive World）。在这个世界里，任何一个智能体的工作上下文都被严格锚定在两个坐标上：一个是被接受的代码版本，决定了智能体继承的项目基线；另一个是代码库的相对路径，划定了该智能体局部责任的边界。
这个局部软件世界被形式化定义为：
\[w=(v,p)\]其中 $v$ 代表版本，$p$ 代表路径。在这个框架下，所有的开发行为不再是全局视角的漫无目的修改，而是受到严格约束的递归活动。
当一个生命周期有限的智能体 $A_{i}$ 在局部世界 $(v,p)$ 中接收到一个具体的任务目标 $g_{i}$ 时，它会产生一个候选的修改方案 $\Delta_{i}$：
\[\Delta_{i}=A_{i}\bigl((v,p),g_{i}\bigr)\]如果当前任务过于复杂，智能体可以触发递归委派机制：
\[(v,p)\rightsquigarrow(v,q)\]这一机制允许在不改变当前已被接受的全局版本 $v$ 的前提下，在更具体的子路径 $q$ 上启动一个子智能体。在这个树状结构中，叶子节点的执行者负责直接修改代码文件，而根节点和中间层的管理者则专注于分解目标、向下委派子任务并审查返回的结果。递归机制极大地收敛了当前智能体需要处理的信息量，使得修改行为被严格限制在当前被接受的项目状态内部，而不会因为中间过程的混乱污染主干历史。
最终，只有经过严格验证（如编译测试、约束检查）的候选修改，才能转化为一个被接受的软件事件，从而真正推进持久化的版本历史：
\[(v,p)\longrightarrow(v^{\prime},p^{\prime})\]被拒绝的候选修改不会对全局版本产生任何影响，该智能体在其私有执行空间内产生的所有临时状态，都会随着它本身的生命周期结束而被抹除。这与那些事无巨细记录智能体每一次观察、修改和尝试动作的系统有着本质区别。EvoX Genesis 认为，持久化的应该是软件的变迁历史本身，而不是执行该变迁的每一段繁杂过程。
复杂系统的从零构建：C 编译器的形成实验
为了验证这种架构的能力边界，研究团队设计了三个阶段的评估，首当其冲的是最为硬核的“系统形成（Formation）”阶段。该实验探讨了一个核心问题：大量生命周期受限的局部智能体片段，能否在一个完全空白的仓库中，累积形成一个高度复杂的相互依赖软件系统？
任务目标是利用 Rust 语言实现一个纯净版的 C 编译器，不仅要求兼容 Clang 的命令行接口、支持标准对象文件和链接器集成、能够导出 LLVM IR，还必须以 C11 为主要语言目标，并强制包含 x86 和 x86-64 后端。整个过程中严禁直接使用或翻译现有的 Clang/LLVM 源码。由于编译器项目涉及极强的上下游依赖——前端的语法解析决策会直接限制类型检查的实现，而中间表示又会强约束后续的代码优化和目标代码生成，这要求系统必须具备极强的跨周期连贯性。
在没有任何初始代码库结构指导的情况下，EvoX Genesis 调用 DeepSeek V4 Flash 模型开始了自主构建。开发过程并非一蹴而就的单次代码生成，而是通过递归的管理者将庞大的目标拆解到不同的仓库路径中，由有限寿命的智能体处理局部代码，再由父节点智能体审查。
经过 123.4 小时的连续运行，系统归档了高达 1019 个智能体执行片段，递归委派深度达到 5 层。最终生成的代码仓库包含了 248989 行物理代码（分布在 750 个被追踪的文本文件中）。在整个浩大的工程中，调用模型的 Token 费用仅为 44.38 美元。令人瞩目的是，这个从零长出的编译器成功通过了完整的 c-testsuite，以及绝大部分 LLVM 测试和由提交工具生成的 Csmith 随机测试用例。
这一结果明确揭示了持久递归机制的有效性：没有任何单一的智能体能够在上下文中装下整个编译器的设计逻辑，但早期被系统接受的架构修改，稳固地成为了后续智能体的工作基线；而后期暴露出的集成错误，又能够在整个项目已经就位的上下文中得到局部修复。
基础模型替换与科学软件重构：连续性与忠诚度测试
如果说构建新系统证明了框架的生成能力，那么接下来的“延续（Continuation）”和“重开发（Redevelopment）”实验，则触及了软件工程更深层的痛点：代码在维护阶段的生存能力。
在编译器项目初步完成后，研究团队进行了一个极具实战意义的测试：强行切断原有的基础模型，将其替换为 GLM 5.2，要求其继续在该编译器仓库中进行开发。结果表明，尽管 GLM 5.2 和 DeepSeek V4 Flash 在后续开发中选择了不同的委派深度、提交历史和代码重构路径，但由于项目的过往历史、约束条件和验证结果被固化在持久层中，新的模型依然能够顺畅接手并维持所有的测试通过率。这证明了在这个范式下，只要项目自身的状态是连贯的，底层提供智能的“模型大脑”完全可以随时被热插拔和替换。
更严苛的挑战来自于针对 MESA（Modules for Experiments in Stellar Astrophysics）天体物理学软件的重开发实验。科研软件的重构与普通互联网产品的迭代不同，其核心不仅在于代码能否正常运行，更在于经历环境和语言更换后，那些关乎科学发现的数值行为是否依然准确无误。近年来业界频繁警告，AI 辅助的弱验证代码修改可能会严重威胁科研软件的质量。
任务要求将超过 10 万行的 MESA 核心 Fortran 模块重写为现代化的 Rust 语言。在经历了 33.22 小时、272 个智能体片段的重构后，EvoX Genesis 生成了一个包含近 9 万行代码的 Rust 工作区。该工作区以零失败率通过了 1052 项测试用例，模型费用仅为 10.64 美元。
在最关键的数值对齐审计中，面对六个高强度的数值计算负载，Rust 版本的 EOS 查找和牛顿求解器实现了与 Fortran 版本的位级完全一致（Bit-exact）；其余四个负载的相对校验和差异也控制在了极其微小的 $5.1\times 10^{-15}$ 到 $3.1\times 10^{-9}$ 之间。不仅科学准确性得到了保留，得益于 Rust 的底层优化，重构后的代码在六个负载上的中位数运行时间全面缩短，实现了 1.55 倍至 6.87 倍的显著性能提升。这意味着，EvoX Genesis 具备在彻底改变系统实现语言和依赖结构的同时，完美继承并保护原始代码科学价值的能力。
软件进化的因果边界与未来范式
研究团队在文中客观地界定了该框架当前的因果边界。虽然在三大实验中，多达数层的递归委派机制在操作层面被高频调用，但现有的观测结果尚未通过控制变量法严格证明，递归结构本身相较于扁平化的组织架构是否具有绝对的因果优越性。此外，在基础模型替换实验中，系统成功维持了开发进展，但这尚不足以精确拆解出究竟是哪些特定的持久化记录（如代码注释、提交历史还是约束文档）对连续性起到了决定性作用。
论文指出，验证特定机制必要性的下一步实验，将是保持可执行代码不变，仅剥离或修改被接受的非代码开发记录，以此观察后续的构建轨迹是否会发生偏离；亦或是使用携带记忆的持久智能体与全新的独立智能体在相同的项目基线上进行严格对照。
值得注意的是，该工作对“软件进化（Software Evolution）”的定义做出了务实的限定。它既不是生物学意义上的达尔文式进化，也不主张开放式的自我修改或在执行中更新大模型的底层参数。其所谓“自主”也是有边界的——人类依然需要设定初始目标、提供可用的工具链并设定算力和时间的控制器限制。
在这些边界之内，EvoX Genesis 证明了一个极其重要的工程命题：驱动超长周期软件开发的核心动力，不需要是一个永远在线、记性极好且永远不会崩溃的超级智能体。只要将状态、约束和历史牢牢锁定在项目维度的递归世界中，哪怕负责写代码的智能体只是朝生暮死、来去匆匆的“计件工人”，整个软件系统依然能够跨越时间的鸿沟，完成从孕育、生长到全面重构的壮阔演进。