一、题目：把"不死"还给项目，而不是 Agent
论文原名 Persistent Recursive Worlds Enable Autonomous Software Evolution，中文可译为《持久递归世界使自主软件演化成为可能》，系统代号 EvoX Genesis（下文简称 Genesis），来自香港理工大学的 Beichen Huang、Zhenyu Liang、Bowen Zheng 与 Ran Cheng，2026 年 8 月发表于 arXiv（2608.10450）。
题目里的三个关键词构成了全文的骨架：
- Persistent（持久化）：研究的对象是谁能"活得比单次 agent 更久"。Genesis 给出的答案是——项目，而不是 agent。
- Recursive（递归）：工作如何在项目内部被拆解、下沉、再汇合。 Genesis 用"路径级委托"把一个庞大目标切成一棵临时任务树。
- World（世界）：每一个 agent 都不在"全局代码库"里工作，而是在一个有版本、有路径、有边界的"局部世界"里工作，做完就走。
一句话总结这篇论文做了什么：它把"软件项目"本身变成了一个不死的世界，agent 只是需要被这个世界"接待"的短期访客；只要世界还在，软件就能持续演化。
这篇精读面向有一定 Agent/编译器/科学计算背景的读者，我会按"背景 → 定位 → 问题定义 → 解法 → 三大实验 → 知识反推 → 通用灵感"的结构，把 Genesis 的设计选择、关键数据和局限都讲清楚。
二、背景：长周期软件开发撞上了"Agent 寿命墙"
2.1 真实软件的时间尺度，远超单次 Agent 会话
一个能用的 C 编译器，几十万行起步；一个像 MESA（Modules for Experiments in Stellar Astrophysics）这样的恒星物理计算库，动辄十万行量级的 Fortran。这类"复杂软件系统"的开发周期，通常以天甚至周为单位。
而当前的 coding agent，无论多强，本质上都是一个有限生命周期的会话实体：
- 上下文窗口有限（哪怕百万 token 也会被压缩）；
- 单次 episode 的轮次有限；
- 模型权重在运行期间不变（不会自己"练功"升级）；
- 长时间运行会出现注意力衰减、目标漂移、重复犯同类错误。
当一个任务的合理周期是 120 小时，而任何一个 agent 都活不到这么久、或在这么久之后已经"疲态尽显"时，就会出现一道Agent 寿命墙：不是模型不够聪明，而是"单个智能体连续在线"这种组织方式本身撑不起长周期工程。
2.2 已有路线：让 Agent 不死，或者让记忆不死
为了越过这堵墙，主流做法几乎都在沿着"让 agent 侧的东西持久化"这条思路走：
- 持久化会话/上下文：把对话历史、工具调用记录长期保存，让下一次 agent 能"接着说"；
- 持久化记忆：向量库、知识图谱、摘要库，把过往经验沉淀为可检索的记忆；
- 持久化管理器（manager）：一个长期在线的"领导 agent"持续分解任务、派活、收活；
- 持久化共享状态：团队 agent 共享一个黑板/工作区，谁来了都能读写。
这些做法都有用，但它们共同的隐含假设是：连续性 = 某种"智能体侧的持久性"。也就是说，要让开发不停，就得让"那个负责思考的东西"不停，或者至少让它记得自己停之前发生了什么。
Genesis 的作者敏锐地指出：这个假设把问题复杂化了。agent 侧的持久化带来一堆工程难题——记忆怎么压缩、manager 怎么不腐化、共享状态怎么并发一致、长上下文怎么不污染决策。而且它仍然没有解决一个根本问题：如果模型本身被换掉了，之前那个"持久的 agent"到底还是不是同一个 agent？
2.3 另一条路：让软件自己成为"活着的那一方"
论文用一句话点破了范式差异：
Most agentic software systems preserve continuity through persistent sessions, memories, managers or shared context. We introduce EvoX Genesis, which instead makes the software project persistent while allowing local agents to remain finite-lived.
与其让 agent 活下去，不如让软件项目活下去。Agent 来来去去，但项目——它的代码、它的版本历史、它积累的上下文与约束、它的测试与技能——始终在那里，并且在每一次 agent 造访时，都能把自己"完整地交代清楚"。
这是一个视角的切换：从"给 agent 续命"切换到"给项目筑巢"。巢在，鸟换了一茬又一茬，林子依然在长大。
三、定位：Genesis 在 Agent 软件工程版图里的坐标
为了把 Genesis 的定位说准，我们先看它不是什么：
- 它不是一个"更强的单 agent"：Genesis 不声称自己的基础模型比别人强，实验里用的是 DeepSeek V4 Flash 和 GLM 5.2 这种公开模型。
- 它不是一个"多 agent 框架 SDK"：它有明确的的形式化模型、版本语义和接受机制，不是单纯的角色分工。
- 它不是"记忆系统"或"RAG"：积累的不是向量记忆，而是被接受的项目历史以及附带的上下文/约束/技能。
- 它不是"自我进化的种群模型"：论文明确声明基础模型在运行期间不学习新参数，积累的是项目状态，不是模型能力。
它是什么：
- 一个组织范式：定义"持久的项目状态 + 有限生命的 agent + 递归委托 + 接受事件"如何拼在一起；
- 一个已实现的系统：作者真的跑出了 25 万行的 C 编译器、9 万行的 Rust MESA，并做了跨模型延续实验；
- 一个最小但完整的形式化模型：用"版本 + 路径"两个坐标就把整个系统的运行规则讲清楚了。
用一个粗略的二维定位：横轴是"持久化的对象"（agent 侧 vs 项目侧），纵轴是"工作组织方式"（扁平 vs 递归）。Genesis 稳稳地落在**“项目侧持久化 + 递归组织”**这个象限，而且在这个象限里，它提供了目前最完整的实证。
它的学科归属也反映了这种跨界：arXiv 同时给了 cs.SE（软件工程）、cs.AI（人工智能）、cs.MA（多智能体系统）和 cs.NE（神经与进化计算）四个类别。这正是一篇"用进化计算的思想重组软件工程流程"的论文该有的样子。
四、问题定义：持久化项目 vs 持久化 Agent
这一节是全文的"胜负手"。Genesis 的所有设计都建立在一个干净的问题定义之上。
4.1 把"连续性"从 agent 身上剥离
作者提出一个极其清晰的对立：
| 维度 | 持久化 Agent 路线 | 持久化项目路线（Genesis） |
|---|---|---|
| 谁活得久 | Agent（会话/记忆/管理者） | 项目（版本历史 + 上下文） |
| Agent 角色 | 长期在线、持续决策 | 短期到访、完成有限任务 |
| 知识载体 | Agent 的记忆/状态 | 被接受的项目记录 |
| 模型更换的代价 | 高（“那个人"没了） | 低（换一批访客而已） |
| 工程复杂度 | 记忆压缩、上下文污染、并发一致 | 版本管理、路径上下文、接受机制 |
这个对立不是为了说"持久 agent 不好”，而是为了把问题分离：长周期的连续性，应该由项目状态承载；agent 只需要在被需要的那一小段时间里，足够聪明地把局部工作做好。
4.2 形式化的最小模型：四个要素
Genesis 用一个极简但形式化的模型定义了整个系统。完整模型只有四个要素：
- 接受的软件版本 v（accepted version）：一个被认可的项目状态，连同它的历史、上下文、约束、测试、技能、溯源记录。注意它不是裸 Git SHA，而是"可继承的全部项目遗产"。
- 仓库相对路径 p（repository-relative path）：agent 的工作"座位"，定义它的起始位置和责任范围。
- 有限生命周期 agent 计算 $A_i$：一个 episode 内的 agent，接收目标 $g_i$，在局部世界 $(v, p)$ 里工作，产出候选变更 $\Delta_i = A_i((v,p), g_i)$。它的私有对话和草稿状态不会作为后续 agent 的身份被携带。
- 接受事件 $(v, p) \rightarrow (v', p')$：候选变更只有通过"接受"才能进入持久版本历史，把版本从 v 推进到 v’。
这四个要素构成了一个封闭的运行规则：agent 在版本 v 的路径 p 上工作，提出变更；变更被接受，版本前进；下一个 agent 在新版本上重新实例化。没有任何"agent 的灵魂"需要在 episode 之间传递。
4.3 局部世界：$w = (v, p)$
把版本和路径组合起来，就是一个本地软件世界：
$$w = (v, p)$$这里有几个极易误解的点，论文讲得很严谨：
- 路径 p 不是"仓库的部分副本"。agent 可以检查版本 v 所代表的完整项目，p 只是规定它的"责任座位"和起始视角，不是给它一个残缺的代码库。
- 路径 p 也不是"额外的软件状态"。它只是坐标，不引入新的待维护数据。
- 接受的项目包含的远不止源码：源文件、路径特定上下文、约束、验证结果、可复用技能、溯源记录都在里面。这意味着下一个 agent 拿到的不是一个"裸仓库"，而是一本"带着注释和验收单的工程档案"。
4.4 递归委托 vs 接受事件：两个最容易混的操作
Genesis 里有两个看似都在"换路径"的操作，区分它们是理解全文的关键：
| 操作 | 记号 | 版本变化 | 路径变化 | 说明 |
|---|---|---|---|---|
| 递归委托 | $(v, p) \rightsquigarrow (v, q)$ | 不变 | p → q | 父 agent 在同一版本上，从路径 p 派生一个负责路径 q 的子 agent |
| 接受事件 | $(v, p) \rightarrow (v', p')$ | v → v’ | p → p’（通常 p’=p） | 一个候选变更被接受，版本历史前进一格 |
递归委托是"在同一时刻、把活儿分给不同工位"，它不改变版本；接受事件是"一个工位的成果被认可，写进史册"，它才推动版本。被拒绝的变更永远不会推进接受版本——这是系统能保持"干净血统"的根本机制。
4.5 谁来决定接受？
这是持久项目路线必须回答的问题：既然没有"永生的领导 agent"，谁来判断一个变更该不该接受？
Genesis 的答案是责任父 agent：递归委托链中，派出子 agent 的那个父 agent 负责审查子 agent 的返回结果，决定接受、拒绝或要求返工。这是一种"分布式、就地化"的验收机制——验收权力下放给直接委托者，而不是集中到一个永生的总控。
这个设计有一个非常漂亮的性质：整个系统的"记忆"和"判断"都被外化到了项目结构和版本历史里，而不是塞在某个 agent 的脑子里。即使所有 agent 明天全部下线，后天换一批全新的 agent 来，它们读到的项目状态、路径上下文、约束、测试结果完全一样，能接着干。
五、解法：持久递归世界架构详解
问题定义清楚了，解法就呼之欲出。Genesis 的系统由四块构成：持久递归世界架构、局部世界、递归委托、版本历史，并用 formation / continuation / redevelopment 三个阶段来验证。
5.1 持久递归世界架构总览
把前面的模型装配起来，整个架构可以这样描述：
- 唯一持久的东西：接受的项目版本历史（Git commits + 受保护的归档引用），以及附着在版本上的上下文/约束/技能/溯源。
- 短暂的东西：所有 agent、它们的私有对话、草稿、临时工作树、调度器进程。
- 连接两者的桥梁：每个 agent 都在一个局部世界 $(v, p)$ 里工作，它的产出只有经过"接受事件"才会沉淀进持久历史。
实现上有几个值得点出的工程细节：
- 上下文组装：目录范围节点从版本控制的
CONTEXT.md记录中组装上下文，确保不同路径的 agent 拿到的是"该路径该知道的事"。 - 变更隔离：提议的变更隔离在 agent 特定的分支和工作树里，互不污染；只有被接受的才合并进主干。
- 执行基础设施：调度器状态、监督式 BEAM 进程、临时工作树共同提供并发执行与故障隔离。
- 归档：接受的变更通过 Git commits 和受保护的归档引用存储，形成可追溯的版本谱系。
5.2 局部世界：让 agent"坐在正确的工位上"
局部世界的精髓是路径上下文。想象一个巨大的代码库，如果一个 agent 每次都要"重新理解整个库"，那再多上下文窗口也不够用。Genesis 的做法是：
- 给每个 agent 分配一个路径 p，作为它的责任座位；
- 该路径的
CONTEXT.md（随版本一起演化）告诉 agent “你这个模块是什么、和谁对接、有哪些约束”； - agent 可以查看整个项目（版本 v 是完整的），但它的修改权和责任范围集中在 p；
- agent 之间的协调通过递归委托和接受机制完成，而不是通过共享一个巨大的对话历史。
这相当于把一个"超长会议"切成了无数个"短小站会"，每个站会只讨论自己工位的事，但所有工位共用同一份不断更新的图纸。
5.3 递归委托：让工作"长"成一棵临时任务树
一个根目标（比如"造一个 C 编译器"）太大，根 agent 会把它拆成子目标，通过递归委托派给子 agent：
$$(v, p) \rightsquigarrow (v, q)$$子 agent 在路径 q 上工作，做完把结果返回给父 agent。父 agent 审查后决定接受/拒绝/返工。如果子目标还是太大，子 agent 可以继续递归委托给孙 agent，于是工作就"长"成了一棵临时任务树。
实验中观察到的委托深度：C 编译器 formation 阶段最大观察深度 5，MESA 重开发阶段最大深度 4，而系统配置的最大委托深度是 8。这意味着实际任务树并不需要无限深，几层就够把一个大目标落到可执行的叶子任务。
递归委托的关键性质是版本不变：无论委托多深，所有子 agent 都在同一个接受版本 v 上工作。只有当某个子 agent 的成果被父 agent 接受，版本才会前进到 v’。这保证了"分而治之"不会导致"版本分裂"。
5.4 版本历史：唯一可信的"组织记忆"
版本历史是 Genesis 的"组织记忆"，它有几个重要性质：
- 线性可追溯：每一次接受都是一次提交，形成一条干净的 first-parent 线（实验里有 327 个 first-parent 提交）。
- 只记接受：被拒绝的候选、agent 的草稿、临时工作树都不会进入版本历史。这避免了"记忆污染"。
- 富信息：每个版本不只是代码快照，还携带路径上下文、约束、测试结果、技能、溯源。
- 可继承：任何后续 agent 都能从某个版本重新实例化，获得完整的"工程档案"。
这种设计让"知识"以一种结构化、可验证、可回放的方式沉淀，而不是以"某个 agent 当年说过什么"的模糊方式沉淀。后者是大多数记忆系统的通病，前者是工程系统的常态。
5.5 Agent 角色与生命周期
Genesis 区分了模型角色和运行时标签：
| 类型 | 角色 | 说明 |
|---|---|---|
| 模型角色 | 管理者（Manager） | 在根节点和中间节点分解目标、委托工作、审查结果 |
| 模型角色 | 叶子执行器（Leaf executor） | 直接修改软件 |
| 运行时标签 | 代码库负责人（Repo lead） | 实现标签，非模型角色 |
| 运行时标签 | 代码库调查员（Repo investigator） | 实现标签，非模型角色 |
| 运行时标签 | 任务调度器（Task scheduler） | 实现标签，非模型角色 |
一个 agent 在一次监督 episode 中可以执行多个模型-工具轮次，但它的私有对话和草稿状态不会被携带给后续 agent。后续工作总是从接受版本和路径重新实例化。这是"agent 有限生命"的严格实现。
5.6 三阶段验证：Formation / Continuation / Redevelopment
论文用三个阶段系统地验证了这个架构，每个阶段考察一个不同的问题：
- Formation（形成）：从空仓库出发，能不能长出一个复杂系统？验证"有界 episode 可累积成复杂系统"。
- Continuation（延续）：已经长成的世界，在 agent 被反复替换、甚至基础模型被更换后，还能不能继续开发？验证"持久项目能在 agent 替换下存活"。
- Redevelopment（重开发）：能不能在保持数值行为的前提下，把一种语言的科学代码库重写成另一种语言？验证"科学软件可在保测试的同时转换实现语言"。
这三个阶段合在一起，构成了对"持久项目路线"的完整证据链：能从无到有、能跨 agent/模型延续、能做实质性的工程重写。下面三节分别展开。
六、Formation：120 小时、44 美元，从空仓库长出 25 万行 C 编译器
这是全文最震撼的实验，也是"持久递归世界"能不能成立的决定性证据。
6.1 任务设定：故意设难的"绿地形成"
任务是：从一个没有任何编译器实现的仓库出发，构建一个 Rust 写的 C 编译器。
初始仓库里只有 .gitignore 和 genesis.toml，相当于一张白纸。对编译器的技术要求相当硬核：
- Clang 兼容的命令行界面；
- 标准目标文件和链接器集成；
- LLVM IR 导出；
- C11 为主要语言目标，C23 为扩展目标；
- x86 和 x86-64 为必需后端，AArch64 为可选；
- 禁止直接使用或翻译 Clang/LLVM 源码（必须从零实现）；
- 使用自定义的类型化 CIR（Compiler IR），基于 arena/index 存储。
“禁止用 Clang/LLVM 源码"这一条，意味着 agent 不能走"翻译现有编译器"的捷径，必须真的理解 C 语言和目标平台，自己造轮子。这让实验结果更具说服力——不是"搬运”，是"创造"。
6.2 运行配置
| 配置项 | 值 |
|---|---|
| 基础模型 | DeepSeek V4 Flash |
| 推理强度 | xhigh |
| 上下文压缩阈值 | 150,000 tokens |
| 最大委托深度 | 8 |
| 最大重试次数 | 15 |
| 轮次限制 | 2,048 root turns；128 delegated turns |
| 运行时间 | 2026 年 8 月 2 日至 7 日（UTC），约 5 天 |
| 硬件 | AMD Ryzen 7 PRO 6850HS，8 核 16 线程，64GB 内存，ArchLinux + ZFS |
注意这是一台工作站级的机器，不是集群。整个实验在本地跑完，进一步压低了成本。
6.3 核心结果：四张表看清"有多夸张"
总览指标：
| 指标 | 数值 |
|---|---|
| 总壁钟时间 | 123.402 小时（约 5.14 天） |
| 归档 agent episodes | 1,019 |
| 顶层 spawned agents | 1,065 |
| 最大观察委托深度 | 5 |
| 峰值活跃 episodes | 29 |
| 模型 token 费用 | US$44.3760 |
| 原始 agent 小时 | 666.385 小时 |
| 中位 episode 持续时间 | 12.76 分钟 |
最终代码库规模：
| 文件类型 | 文件数 | 物理行数 | 占比 |
|---|---|---|---|
| Rust | 354 | 219,676 | 88.23% |
| Markdown | 77 | 17,005 | 6.83% |
| C 源码 | 130 | 5,036 | 2.02% |
| Python | 14 | 3,265 | 1.31% |
| C 头文件 | 49 | 3,163 | 1.27% |
| 其他 | 126 | 4,844 | 1.34% |
| 总计 | 750 | 248,989 | 100% |
约 25 万行，其中 Rust 约 22 万行，这是从一张白纸、5 天长出来的。
Token 与成本明细：
| Token 类别 | 数量 | 备注 |
|---|---|---|
| 输入 tokens | 4,134,593,954 | 约 41.3 亿 |
| 缓存输入 tokens | 4,026,336,896 | 缓存命中率 97.382% |
| 输出 tokens | 64,092,688 | 约 6400 万 |
| 总 tokens | 4,198,686,642 | 约 42 亿 |
| 总费用 | US$44.3760 | — |
97% 以上的输入 token 命中了缓存，这是成本能压到 44 美元的关键工程因素之一——持久版本 + 路径上下文天然具备良好的缓存友好性，因为大量 agent 在读取相同的项目基线。
分阶段资源使用：
| 阶段 | 记录数 | 壁钟时间(h) | Agent-hours | 总 tokens | 费用(US$) |
|---|---|---|---|---|---|
| 初始化 | 312 | 23.905 | 163.925 | 1,052,907,912 | 13.5715 |
| 优化 | 707 | 99.497 | 502.460 | 3,145,778,730 | 30.8045 |
| 总计 | 1,019 | 123.402 | 666.385 | 4,198,686,642 | 44.3760 |
可以看到"优化"阶段（让编译器真正能通过测试）比"初始化"阶段（先把骨架搭起来）花了更多的资源和时间，这符合软件工程的常识——把东西跑起来是一回事，把它跑对、跑稳是另一回事。
6.4 测试结果：不是"能编译"，是"真的对"
这是最让我意外的部分。Genesis 长出来的编译器不只是"能跑"，它在多个权威测试套件上表现优异：
| 测试套件 | 结果 | 通过率 | 备注 |
|---|---|---|---|
| c-testsuite | 220/220 | 100.0% | 完整报告集合，全部通过 |
| Csmith | 93/93 | 100.0% | 100 个种子跳过 7 个，执行部分零失败 |
| LLVM test suite | 32/36 | 88.9% | 4 个报告用例未通过 |
| LZ4 | 8/8 | 100.0% | 所有基本检查通过 |
| SQLite | 2/2 | 100.0% | 编译/链接和确定性 SQL 检查 |
| Rust 工作区测试 | 2,904 passed | — | 仅 1 个故意忽略 |
| 内部编译器语料库 | 106/106 | 100.0% | 86 个编译运行 + 20 个编译失败用例 |
c-testsuite 完整通过，Csmith 零失败，SQLite 能编译链接并跑确定性 SQL——这意味着这个编译器不仅能编译"玩具 C"，还能编译真实的、复杂的 C 项目。而这一切是从一个空仓库、在 5 天里、花 44 美元自动长出来的。
这组数据是整篇论文最有"杀伤力"的证据：它直接回答了"持久递归世界长出来的东西，质量到底行不行"——不仅行，而且在多个公开 benchmark 上达到了可发表的水平。
6.5 集成统计：接受机制的健康度
| 统计项 | 数值 |
|---|---|
| 保留的记录（贡献进入最终仓库祖先） | 929 |
| 无变更记录 | 78 |
| 未集成 | 5 |
| Git 对象不可用 | 3 |
| 第一父提交 | 327 |
1019 个 episode 里，929 个的提交最终成为仓库祖先，只有极少数未集成或对象不可用。这说明接受机制运行稳定，“被拒绝的变更不进入版本历史"这条规则在实践中被可靠执行。
6.6 Formation 阶段小结
Formation 证明了一件事：有界的、有限生命的 agent episode，可以通过持久递归世界累积成一个复杂系统。它不是"一个超长会话硬扛 120 小时”，而是"1019 个短命 episode 接力、在一个不死的项目世界里累积"。这两个描述对应的工程难度和鲁棒性，完全不在一个量级。
七、Continuation：换掉基础模型，开发还能继续
Formation 回答了"能不能从零长出来"，Continuation 回答了"长出来之后，agent 换了、模型换了，还能不能接着干"。这是"持久项目 vs 持久 agent"分歧最尖锐的检验。
7.1 实验设计：同一份遗产，两条延续路线
从一个由 GLM 5.2 生成的已完成编译器（commit 37216cfa254a）出发，分两条分支继续开发：
- GLM 延续：继续用 GLM 5.2 开发；
- DeepSeek 延续：切换到 DeepSeek V4 Flash 开发。
延续指令统一为：“Continue and finish all remaining work, achieve 100% pass rate, excluding csmith as it is not installed.”
这个设计的精妙之处在于：模型是被"硬替换"的。如果是持久 agent 路线，换模型往往意味着"换了一个灵魂"，之前的记忆、风格、判断偏好都可能失配。而在持久项目路线下，换模型只是"换了一批新访客"，项目遗产原封不动。
7.2 运行摘要对比
| 指标 | 初始 GLM 开发 | GLM 延续 | DeepSeek 延续 |
|---|---|---|---|
| 耗时(h) | 136.56 | 21.99 | 17.10 |
| Spawned agents | 562 | 98 | 178 |
| 归档记录 | 504 | 97 | 168 |
| 最大观察深度 | 5 | 4 | 8 |
| 峰值活跃 agents | 21 | 9 | 19 |
| 平均活跃 agents | 2.86 | 2.94 | 5.70 |
| Agent-hours | 390.57 | 64.65 | 97.57 |
| 中位持续时间(min) | 14.4 | 16.1 | 17.0 |
| 代码变更记录 | 479 | 90 | 160 |
两个延续分支都成功推进了开发。值得注意的是 DeepSeek 延伸到了最大委托深度 8，且平均活跃 agents 更高（5.70），说明跨模型延续时系统仍然能正常组织复杂委托结构。
7.3 成本对比
| 指标 | 初始 GLM | GLM 延续 | DeepSeek 延续 |
|---|---|---|---|
| 总 tokens | 2,265,206,812 | 547,266,580 | 911,480,477 |
| 缓存输入占比 | 96.34% | 98.27% | 97.96% |
| 总费用(US$) | 762.59 | 168.35 | 7.49 |
DeepSeek 延续的费用只有 7.49 美元，这再次体现了不同模型的成本差异，以及持久项目路线对"换便宜模型"的天然友好——因为项目不挑访客。
7.4 延续后的测试结果：关键证据
| 测试目标 | 初始开发 | GLM 延续 | DeepSeek 延续 |
|---|---|---|---|
| Rust 单元测试 | 1,136 | 1,226 (+90) | 1,350 (+214) |
| LLVM SingleSource | 1,558/1,870 (83.3%) | 1,445/1,448 (99.79%) | 1,820/1,820 (100%) |
| c-testsuite | 220/220 | 220/220 | 220/220 |
| LZ4 | 4/4 文件 | 4/4 文件 | 4/4 文件 |
| SQLite -O0 | 基本运行通过 | 编译 | 编译、链接并运行 |
核心结论：在基础模型被替换（GLM 5.2 → DeepSeek V4 Flash）之后，开发不仅继续了，而且 c-testsuite 保持 220/220 全通过，LLVM SingleSource 甚至在 DeepSeek 延续中达到了 1820/1820 = 100%。
注：论文提醒，保留的 LLVM 测试集在不同快照间不同，因此这些通过率描述的是各自完成快照，而非在固定测试集上的直接比较。但 c-testsuite 是固定的 220 个，全通过这一事实具有直接可比性。
7.5 代码库持续增长
| 文件类型 | 初始 GLM 5.2 | GLM 延续 | DeepSeek 延续 |
|---|---|---|---|
| Rust | 94,253 | 104,264 | 117,409 |
| Markdown | 10,325 | 11,876 | 14,718 |
| 总计 | 105,420 | 116,991 | 133,154 |
两条延续路线都让代码库实质性增长，DeepSeek 延续把 Rust 行数从 9.4 万推到了 11.7 万。
7.6 Continuation 阶段小结
这个阶段直接击中了"持久 agent"路线的软肋：模型一旦更换，持久 agent 的"人格连续性"就断了。而 Genesis 用数据证明：只要项目持久、上下文外化、验收机制健全，换模型就像换班工人，工程进度不会断，测试性能不会掉。这是"项目侧持久化"最有力的背书。
八、Redevelopment：10 万行 Fortran → 9 万行 Rust，1.55–6.87× 加速
第三个阶段把战场从"编译器"挪到了"科学计算"，验证持久递归世界能不能做实质性的跨语言重写，而不仅仅是"新写一个东西"。
8.1 任务设定：MESA 数值模块的 Fortran→Rust 迁移
MESA（Modules for Experiments in Stellar Astrophysics）是天体物理领域广泛使用的恒星演化计算库，核心是大量 Fortran 数值代码。Genesis 的任务是：
- 以一个轻度修改的 MESA fork 为参考系统；
- 重新实现 13 个映射模块目录为对应的 Rust crates；
- 参考范围覆盖基本数值和物理模块（高级引擎 star、astero、binary 不在范围内）；
- 参考代码量：139,414 物理 Fortran 行（含模块级测试）。
这是一个"翻译 + 重写 + 验证"三位一体的任务，难度在于：科学代码对数值一致性极其敏感，浮点误差累积可能导致物理结果失真，因此不能只追求"能编译"，必须追求"数值对得上"。
8.2 运行配置与结果
| 配置项 | 值 |
|---|---|
| 模型 | DeepSeek V4 Flash, xhigh |
| 运行日期 | 2026 年 8 月 3-5 日（UTC） |
| 最大深度 | 8 |
| 最大重试 | 15 |
| 根 agent 交接 | 31.720 小时 |
| 指标 | 数值 |
|---|---|
| 总耗时 | 33.219 小时 |
| Spawned agents | 272 |
| 归档记录 | 260 |
| 归档覆盖率 | 95.6% |
| 最大观察深度 | 4 |
| 缓存输入占比 | 96.4168% |
| 模型 token 费用 | US$10.636892 |
| 输出 Rust 工作区物理行数 | 89,946 行 |
| 通过测试 | 1,052 |
| 失败测试 | 0 |
| 忽略测试 | 18 |
约 10 万行 Fortran 被重写为约 9 万行 Rust，1052 个测试全部通过，0 失败，花费约 10.6 美元，耗时约 33 小时。
8.3 数值验证：六个审计工作负载
这是科学计算迁移最关键的指标。论文用六个审计工作负载对比了原 Fortran 实现和 Rust 实现：
| 工作负载 | 数值一致性 | Rust 加速比 |
|---|---|---|
| EOS 查找 | 位精确（bit-exact） | 有加速 |
| Newton 求解 | 位精确（bit-exact） | 有加速 |
| 端到端 burn | 相对校验和差异 < 3.1×10⁻⁹ | 有加速 |
| 不透明度查找 | 相对校验和差异在范围内 | 有加速 |
| 二维插值 | 相对校验和差异在范围内 | 有加速 |
| ROS2 积分 | 相对校验和差异在范围内 | 有加速 |
- 相对校验和差异范围：5.1×10⁻¹⁵ 到 3.1×10⁻⁹；
- 所有 6 个工作负载中 Rust 的中位运行时间都更低；
- 加速比范围：1.55× 到 6.87×。
其中两个工作负载达到了位精确一致（即结果每一位都和 Fortran 一模一样），其余四个的数值差异也在极小的范围内（远低于科学计算通常接受的容差）。而且 Rust 版本全部更快，最高加速近 7 倍。
8.4 构建配置与基准环境
| 配置 | Fortran | Rust |
|---|---|---|
| 编译器 | gfortran 12.2.0 | Rust stable |
| 优化级别 | -O3 | opt-level=3 |
| 其他标志 | -march=native -ffp-contract=fast -std=f2008 | fat LTO; codegen-units=1; panic=abort |
基准测试在 Intel Xeon Platinum 8336C（64 核 128 线程）上，把基准进程绑定到 CPU 0-3，每个工作负载预热后取 25 次直接二进制运行的中位数。这是一套相当严谨的微基准流程，并额外用独立的 40 轮 burn 代理检查做了交叉验证。
8.5 Redevelopment 阶段小结
这个阶段证明：持久递归世界不仅能"写新东西"，还能"重写老东西"，并且能在保持科学数值行为的前提下完成跨语言迁移，甚至顺便拿到了显著的性能提升。这对整个科学计算社区（大量遗留 Fortran 代码）是一个极具吸引力的信号。
九、知识反推：从 Genesis 的成功，能反推出哪些"被验证的信念"
一篇好的系统论文，价值不止于"它做了什么"，更在于"它的成功反推了哪些普遍成立的工程信念"。我把 Genesis 三大实验的成功反推出的几条关键信念梳理如下。
9.1 信念一：项目状态足以承载长周期连续性
Formation 120 小时、Continuation 跨模型、Redevelopment 跨语言，三件事都不依赖"持久 agent"。这反推出：只要项目状态（版本 + 上下文 + 约束 + 测试 + 溯源）组织得当，它本身就足以承载跨 episode、跨 agent、跨模型的连续性。
这等于在说：我们过去为了"让 agent 记得"而做的大量记忆工程，可能有一部分是在解决一个被错误定义的问题。真正需要持久的，是工程对象本身。
9.2 信念二：接受机制比"一直想"更重要
Genesis 里，被拒绝的变更不进入版本历史。这个看似简单的规则，实际上是一种强大的防退化机制。长周期开发最大的敌人不是"不会做"，而是"做错了还把错误沉淀下来"，导致后续 agent 在错误地基上越走越偏。
接受机制 + 责任父 agent 审查，构成了一个分布式、就地化的质量门。它不需要一个"永生的总控"，却能让 1019 个 episode 的产出保持干净血统。这反推出：长周期系统的鲁棒性，更多来自"如何拒绝错误"，而不是"如何永远正确"。
9.3 信念三：路径上下文是可扩展性的钥匙
把 agent 绑定到路径 p，看起来是个小设计，但它是整个系统能扩展到 25 万行代码的关键。如果每个 agent 都要"理解整个库"，上下文窗口会瞬间爆炸；而路径上下文让每个 agent 只需要深度理解自己负责的那一块，同时仍然可以查看整体。
这反推出：超大规模 agent 工程的可扩展性，取决于能否把"全局理解"切成"局部理解 + 协调协议"。这和人类大型工程组织（模块化、职责划分、接口契约）的规律高度一致——AI 系统并没有逃过这条规律，反而验证了它。
9.4 信念四：缓存友好性是成本的隐形决定因素
Formation 阶段缓存命中率 97.382%，Continuation 的 GLM 延续高达 98.27%，Redevelopment 96.42%。这不是巧合：持久版本 + 路径上下文天然让大量 agent 读取相同的项目基线，而相同的输入前缀才能命中提示缓存。
这反推出：agent 系统的成本，不只由模型定价决定，还由"系统的缓存友好性"决定。一个把上下文组织得高度可复用的系统，能在同等智能水平下把成本压一个数量级。Genesis 的 44 美元、7.49 美元、10.64 美元，是这种工程红利的直接体现。
9.5 信念五：模型可替换性是工程弹性的核心
Continuation 实验最硬核的结论是：模型被换掉了，项目还能继续，测试还能全通过。这反推出：一个稳健的长周期 agent 系统，应该把"模型"视为可替换的零件，而不是系统的身份。谁能更好地外化状态、谁对模型更换更不敏感，谁就更能在模型快速迭代的时代稳健运行。
这一点对产业实践意义极大——模型每几个月就迭代一轮，如果一个系统强绑定某个模型，它的工程价值会随模型更迭快速衰减；而 Genesis 这种"项目持久、模型可换"的架构，天然具备抗模型迭代的能力。
9.6 信念六：递归委托是"用空间换时间"的正确姿势
长周期开发如果用"单 agent 长会话"来做，是在"用时间换确定性"——越来越长、越来越慢、越来越容易跑偏。Genesis 的递归委托是反过来"用空间（并行/多 agent）换时间（缩短单 episode）"：把一个大目标切成一棵临时任务树，叶子任务足够小、足够短、足够好验证。
观察到的委托深度（4-5 层为主，偶尔到 8）说明：大多数复杂目标并不需要无限递归，几层下去就够"降解"成 agent 能一次性做好的粒度。这和软件工程里"分而治之"的经验阈值惊人一致。
十、通用灵感：Genesis 给其他领域的启发
Genesis 的贡献虽然是软件工程，但它的核心思想——“让世界持久，让访客有限”——具有很强的可迁移性。这一节谈几条对其他领域的通用灵感。
10.1 灵感一：重新审视"持久化什么"这个元问题
任何需要长周期运行的智能系统，都应该先问一个问题：我到底需要让什么持久？是智能体本身，还是智能体所操作的对象？
- 科研 agent：应该让"研究项目"（问题、文献、实验、结论、待办）持久，而不是让"那个 agent"持久；
- 运维 agent：应该让"系统拓扑 + 故障历史 + 变更预案"持久，而不是让"值班 agent"持久；
- 写作 agent：应该让"文稿 + 大纲 + 风格约束"持久，而不是让"写作 agent"持久。
一旦把持久化对象从"agent"挪到"对象"，很多复杂度（记忆压缩、人格漂移、上下文污染）会自动消失，因为它们本来就是"持久 agent"带来的次生问题。
10.2 灵感二：用"接受事件"设计所有 agent 流程
无论做什么领域的 agent 系统，都可以借鉴 Genesis 的"接受事件"思想：agent 的产出默认是"草稿"，只有经过明确的验收才能沉淀进持久状态。
- 研究结论：agent 提出的假设默认是草稿，需要"验证 episode"（复现实验、交叉引用）通过后才进入"已接受结论"；
- 代码变更：默认是草稿，测试通过 + 审查通过才合并；
- 文档：默认是草稿，校对 + 事实核查后才发布。
这种"默认拒绝、显式接受"的哲学，能极大降低长周期系统被错误污染的风险。
10.3 灵感三：把"记忆"从向量库换成"结构化工程档案"
大量 agent 系统把"记忆"做成向量库：把过往对话 embed，需要时检索。这种方式的问题在于：检索出来的碎片缺乏结构、难以验证、容易被带偏。
Genesis 示范了另一种做法：把记忆做成结构化的工程档案——版本化的代码、路径绑定的 CONTEXT.md、测试结果、约束、溯源。这种记忆是结构化的（有明确 schema）、可验证的（有测试）、可回放的（有版本），远比向量记忆可靠。
对任何需要"长期积累知识"的 agent 系统，这都是一个值得借鉴的升级方向：能结构化的，就别向量化。
10.4 灵感四：用"路径 + 版本"给 agent 分工，而不是用"角色"
很多多 agent 系统用"角色"分工：研究 agent、写作 agent、审查 agent。Genesis 暗示了另一种可能：用"路径 + 版本"分工。每个 agent 负责对象的一个局部区域（路径），在某个时间点的快照（版本）上工作。
这种方式的好处是：分工边界由对象结构决定，而不是由角色定义决定。它天然避免了"两个 agent 改了同一块代码却互不知道"的并发问题，因为路径就是并发单元。
这对任何需要多个 agent 协作修改同一份复杂产物（文档、设计图、知识库）的场景都适用。
10.5 灵感五：把"成本"当作一等公民来优化
Genesis 全程把成本放在显眼位置：44 美元、7.49 美元、10.64 美元，以及 97%+ 的缓存命中率。这不是炫技，而是把"每个 agent episode 的边际成本"作为系统设计的一等约束。
这对产业落地极其重要：一个能跑出 25 万行代码但花 4400 美元的系统，和一个花 44 美元的系统，商业意义完全不同。Genesis 示范了"通过架构设计（缓存友好、路径隔离、接受机制）压低成本"是一条可行路径，而不是单纯依赖模型降价。
10.6 灵感六：诚实地划定证据边界
最后一条灵感是学术品格上的：Genesis 论文非常明确地划定了"自己证明了什么"和"自己没证明什么"。它列出了三项未执行的因果测试：
- 递归优越性：虽然递归被广泛使用，但并未在因果上证明递归优于扁平或替代组织；
- 必要持久记录：延续实验表明开发能在模型替换后继续，但没确定哪些持久记录是"必要"的；
- 建议的消融实验：保持代码固定改变非代码记录、比较新 agent 与持久 agent、扁平 vs 层次接受等消融，都还没做。
这种"证据边界"的诚实标注，反而让论文更可信。它告诉读者：这些结果是"持久项目路线可行"的充分证据，但还不是"哪些机制必要"的因果证据。后续工作有明确的接力点。
十一、结语：把"不死"还给工程对象
EvoX Genesis 最大的思想冲击，不是它跑出了多惊人的数字（虽然数字确实惊人），而是它用一个干净的范式转换重新定义了"长周期智能系统"的设计方向：
与其让智能体不死，不如让智能体所服务的对象不死。
这个转换的深远意义在于：它把"连续性"从一个智能体侧的难题（怎么让 agent 记得、怎么让 agent 不漂移），变成了一个工程侧的常态（怎么做版本管理、怎么写上下文、怎么设接受门）。前者是 AI 难题，后者是工程纪律。Genesis 用 25 万行 C 编译器、跨模型延续、10 万行 Fortran 迁移三组实证，证明了工程纪律足以在当前模型能力下支撑起跨天的复杂软件开发。
当然，它也留下了大量开放问题：递归是不是必需的？哪些持久记录是必要的？扁平组织会不会一样好？这些消融实验是下一篇论文的靶心。但即便如此，Genesis 已经把"持久项目路线"从"一个有趣的想法"推进到了"一个有完整实证支撑的可行范式"——这本身就是罕见的贡献。
对于正在做长周期 agent 系统的工程师和研究者，这篇论文值得精读的不只是它的架构，更是它如何用一个极简的形式化模型（版本 + 路径 + 有限 agent + 接受事件）把一个看似无解的问题拆解得清清楚楚。这种"把复杂问题定义简单"的能力，比任何具体技巧都更值得学习。
当模型还在以季度为单位迭代的时候，Genesis 提醒我们：真正能穿越模型世代的，不是某个不朽的 agent，而是一个把每一次短暂的智能都妥善接住、认真验收、安静积累的不死世界。
论文信息
- 标题：Persistent Recursive Worlds Enable Autonomous Software Evolution
- 作者：Beichen Huang, Zhenyu Liang, Bowen Zheng, Ran Cheng
- 机构：The Hong Kong Polytechnic University（香港理工大学）
- arXiv：2608.10450（v1 提交于 2026-08-11，v2 修订于 2026-08-12）
- 学科分类：cs.SE; cs.AI; cs.MA; cs.NE
- DOI：10.48550/arXiv.2608.10450
核心数据速查
| 实验 | 模型 | 耗时 | 费用 | 产出 | 关键结果 |
|---|---|---|---|---|---|
| Formation | DeepSeek V4 Flash | 123.4 h | $44.38 | 248,989 行 C 编译器 | c-testsuite 220/220，Csmith 93/93 |
| Continuation (DeepSeek) | GLM→DeepSeek | 17.1 h | $7.49 | 编译器 +33k 行 | c-testsuite 保持 220/220 |
| Redevelopment | DeepSeek V4 Flash | 33.2 h | $10.64 | 89,946 行 Rust | 1052 测试全过，1.55–6.87× 加速 |