持久递归世界实现自主软件演化

TL;DR EvoX Genesis 将软件项目本身持久化为递归世界，让短命 agent 通过递归委派持续演化代码，仅花 44 美元自主构建出通过完整 C 测试套件的 Rust 编译器，证明以项目为中心比以 agent 为中心更适合长期软件开发。

问题

问题背景

长时程软件开发（如编译器、数值库重构）往往跨越多个 coding agent 生命周期。现有 agentic 系统多通过 持久会话、记忆或集中式管理器维持项目连续性，但这类设计常将状态绑定在 agent 或协调器上。

现有方法局限

• 上下文积累：持久会话易使上下文窗口膨胀，历史信息干扰当前决策，且难以清理。
• 状态耦合：记忆/管理器成为单点故障，agent 替换时需迁移大量私有状态。
• 并发冲突：共享上下文下多 agent 并行容易产生不一致写入，缺乏清晰的版本边界。
• 可审计性弱：变更记录往往混在日志中，难以追溯每个决策的来源。

Genesis 反其道而行：让 项目本身持久，agent 保持有限寿命。每个局部世界由 accepted version + repository path 定义，agent 仅提出局部变更，递归委派跨路径推进，只有被接受的后果才进入持久版本历史。这与 git 的工作流相似，但自动化程度更高。

为什么这个问题难/重要

难点在于：如何在 agent 生命有限、可能频繁替换的前提下，保障项目演化的 一致性、可追溯性和可扩展性。业界对 autonomous software engineering 的关注度持续上升，但多数框架仍依赖长寿命 agent 或中心化记忆，难以支撑数天级、数千次提交的工程任务。Genesis 以 120 小时、1000+ agent episodes、仅 US$44 token 成本构建 Rust C 编译器，证明项目为中心的组织方式可行，为后续低资源、长周期自治开发提供了新范式。

行业类比

类似大型开源项目依赖 git 的分支/合并与 PR 评审，贡献者可随时离场，但项目版本史持续演进。Genesis 相当于自动化的 PR 流水线：每个 agent 是一个短命贡献者，代码评审由验证机制完成，项目主线不断前进。

核心洞察

• 将项目状态持久化作为长时程软件开发的连续性核心，而非持久化 agent 记忆或会话。Genesis 把软件项目建模为持久递归世界，每个 agent 只对局部世界提出变更，验证通过后才推进全局版本历史，因此 agent 可以任意替换、失效，甚至更换基础模型（如 DeepSeek V4 Flash 到 GLM 5.2）而不丢失开发累积。这与大多数依赖记忆模块、共享上下文或 session 续接的 agent 系统形成根本差异：后者的上下文随历史膨胀、易漂移，且难以跨模型迁移；而 Genesis 只保留可验证的代码资产，使得长期开发像 git 分支合并一样清晰、可审计且成本可控。
• 递归委派与局部世界划分让大规模代码库的并行开发无需全局共享状态。Genesis 每个局部世界对应一个 repository path 和一个 accepted version，有限寿命 agent 在局部上下文中工作，需要跨模块协调时通过递归委派将子任务派发到其他路径，父世界只接受最终验证通过的变更。这区别于单体 agent 或中心化 orchestrator：后者在超长时程（120 小时）和 25 万行代码规模下会遭遇上下文窗口溢出、任务切换干扰和单点故障。递归世界天然支持水平扩展，且每个局部世界的验证边界清晰，使得失败隔离和恢复更简单，为 AI 驱动的软件演进提供了可工程化的并行范式。

方法

方法：Persistent Recursive Worlds 组织长期软件演化

输入：初始任务规范与任意起点仓库（可为空仓库或已有代码库）。每个局部世界由 accepted version（已接受版本）和 repository path（仓库路径）定义，即项目在某一稳定状态下的子目录或模块。

关键模块

1. 局部软件世界：项目被建模为一棵递归世界树，每个节点对应一个已接受版本 + 路径，形成可独立演化的局部上下文。
2. 有限生命 Agent：每个 agent 仅在有限 episode 内存在，负责对所在局部世界提出局部更改（新增文件、修改代码等），不依赖长期会话、记忆或全局共享上下文；完成后即可终止。
3. 递归委托：当子任务超出当前路径范围时，agent 可将工作委托给其他 agent 到不同路径或子项目，实现跨路径的分治协作；委托结果作为局部更改返回。
4. 验证与持久世系：所有更改必须通过验证（编译、测试套件、外部基准）才会被接受；只有被接受的更改才能推进 accepted version 历史，形成严格可追溯的项目世系。

输出：持续增长的持久版本历史，以及可复现的软件演化轨迹。例如构建 Rust C 编译器、将 MESA Fortran 模块重写为 Rust workspace 均由此推进。

与依赖 persistent sessions、memory、manager 或共享 context 的编码 agent 方法不同，Genesis 把持久性从 agent 转移到项目本身，agent 保持 transient，从而允许跨模型替换和长期连续开发。

实验

实验设计

Genesis 在三个场景下评估：形成（从空仓库构建 C 编译器）、连续性（更换基座模型后继续开发）、再开发（将 MESA Fortran 代码迁移到 Rust）。形成实验使用 DeepSeek V4 Flash 构建 Rust 编译器；连续性使用 GLM 5.2 重复开发并替换代理；再开发选择 13 个 MESA 模块迁移至 Rust workspace，并在六个数值工作负载上验证。

关键发现

• 从零构建的编译器达 250k 行 Rust（tracked lines），运行 120+ 小时，归档 1000+ agent episodes，token 费用仅 US$44。
• 编译器通过完整 c-testsuite，大部分 LLVM 与 Csmith 测试。
• 在 GLM 5.2 世界中，代理多次替换后开发仍能继续，且保持完整测试性能。
• MESA 再开发将 100k+ Fortran 行 迁移为 近 90k Rust 行，六个数值负载中位数加速 1.55–6.87x。

工程启示与对比

与传统以持久 Agent 为核心的方案（如记忆、管理者）不同，Genesis 将项目本身设为持久实体，局部世界具有版本与路径，代理仅做局部变更，通过递归委派与接受后果推进版本历史。这种设计解耦了代理生命周期与项目连续性，适合超长周期、多代理协作的软件开发。对比基线（未明确给出传统 agent 方法），Genesis 在极低 token 成本下完成大规模代码生成，且更换基座模型不影响项目进展，验证了项目中心化的软件演化组织范式。

行业影响

落地场景

长周期软件项目、遗留系统重写、科学计算库迁移是直接可用场景。例如：

• 金融领域：高频交易平台或风控引擎中大量 Fortran/C++ 数值模块可自动迁移到 Rust，Genesis 在 MESA 项目上实现 1.55–6.87x 中位加速，直接改善延迟与吞吐。
• 企业服务：大型单体服务向现代语言栈或微服务拆分时，可按模块递归委派多 agent 并行改造，保留版本历史与可回滚路径。

商业价值

核心降本来自 模型 token 成本与人力监督成本：构建 25 万行 Rust C 编译器仅需 US$44 token 费用，120 小时无人值守，1000 个 agent 生存周期全程自动。相比传统“持久 agent + 外部记忆”方案，Genesis 以项目为持久单元，避免长会话状态漂移与 memory 维护开销，可大规模并行多个局部世界。

与现有工作流接口

Genesis 可视为现有 git + CI/CD 之上的编排层：

• 每个局部世界映射到仓库路径 + 版本号，agent 只提交局部变更，验证通过后合并进主分支。
• 集成方式简单：在 CI 流水线中启动短生命周期 agent 容器，读取/写入指定路径，模型 API 可替换（如 DeepSeek V4 Flash 与 GLM 5.2 互换后测试性能不降），不绑定特定供应商。
• 企业可将 agent 封装为无状态函数，输入为 path + prompt + accepted version，输出为 patch，由现有 code review 系统审批。

这一架构适合需要长期演进、多团队并行、且希望模型可插拔的软件组织。

局限

• 论文未进行**因果测试**来分离**持久递归世界**中各设计要素（持久项目状态、有限寿命 agent、递归委托、版本验收）对最终结果的独立贡献。第 12.2 节明确声明未执行此类消融或对照实验，因此无法判断性能提升主要来自组织范式还是底层模型能力（DeepSeek V4 Flash / GLM 5.2）。对于希望复现或改进该方法的研究者，缺少因果证据会阻碍识别核心机制，也使“递归世界”是否明显优于简单的多会话共享代码仓库 + 版本控制这一基线存疑。
• 实验证据主要依赖**测试套件通过率**和**数值加速比**，但未与人工重写或现有自动迁移工具进行直接对比。例如 MESA 模块从 Fortran 到 Rust 的重实现只覆盖 6 个数值工作负载，未包含完整 MESA 功能，也未评估代码可维护性、可读性或与上游科学社区惯用接口的兼容性。此外，C 编译器通过 c-testsuite 和部分 LLVM/Csmith 测试是重要结果，但不能证明其在真实编译场景下的鲁棒性；外部验证的覆盖面有限，可能掩盖了特定边缘情况下的语义偏差。
• 长时程运行仅各执行一次（formation 和 continuation），缺乏对随机性、模型采样温度、初始规格细节等变量的重复实验；agent 生命周期有限但仍依赖**全局版本历史**作为单一事实来源，这在大型分布式协作中可能成为中心化瓶颈。递归委托的深度和上下文传递策略未系统探索，可能在高复杂度任务中出现上下文漂移或错误累积。模型 token 费用仅 US$44 的结论高度依赖具体模型定价和任务复杂度，不能推广为通用成本指标。