OpenRSI把“AI改进AI”落成了怎样一套工程系统

OpenRSI没有宣称解决通用递归自我改进，而是把机器学习工程拆成可执行任务、可训练算子与长程搜索。本文结合仓库结构和关键代码，分析其闭环机制、实验结果与复现边界。

“AI 改进 AI”很容易被写成一个宏大叙事：模型自动研究、自动训练、自动迭代，最终形成递归自我改进。但工程上真正困难的，并不是让模型生成一段看起来像研究方案的文字，而是回答下面几个具体问题：

• 它改进的对象到底是什么？

• 改进结果能不能执行？

• 执行之后如何得到可信反馈？

• 哪一步带来了收益？

• 搜索产生的经验能不能进入训练？

• 换一个任务后，能力还能不能保留？

OpenRSI 值得关注的地方，不是它使用了 RSI 这个标签，而是它主动把问题收缩到了机器学习工程，也就是 MLE。这里的产物是程序，程序可以进入隔离环境执行，结果可以由评估器打分，失败可以留下日志，多个候选之间也能进行比较。

说白了，它把一个难以验证的“AI 自我改进”命题，改写成了一个更具体的工程问题：

能否让模型学习一组程序演化操作，再通过长程搜索持续产生、执行、筛选和改进机器学习方案，并把这些可验证轨迹重新用于训练？

这依然不是通用递归自我改进，但已经具备了讨论 AI4AI 所需要的几个关键条件：可执行、可测量、可复现，以及尽可能可归因。

OpenRSI的克制之处：先研究受限领域里的Meta-Evolution

OpenRSI 给出的机制层级是 Evolution、Self-Evolution、Meta-Evolution，再到最终的 RSI。项目当前从 Meta-Evolution 切入，也就是在一个有边界、可执行的领域中训练“负责改进的系统”，而不是宣称已经解决了通用 RSI。

这个定位很重要。

如果任务没有稳定环境和量化反馈，那么所谓“改进”很容易退化成模型对自己输出的主观评价。模型生成一个新方案，再由模型判断新方案更好，最终得到的往往只是语言层面的自洽。

机器学习工程相对适合作为切入口，因为它天然提供了一条执行链：

1. 根据任务描述生成训练或推理程序。

2. 在指定环境中执行代码。

3. 收集分数、运行日志和错误反馈。

4. 对程序进行修复、改进或重组。

5. 再次执行并比较结果。

6. 保存有效轨迹，用于后续训练或搜索。

这条链路把“思考得更好”替换成了“在评估器上得到更好的可执行结果”。评价未必完美，但至少不再完全依赖语言模型自评。

OpenRSI 将“改进速度本身”作为优化对象，其含义也不是让模型修改自己的全部参数和系统结构，而是让搜索产生经验、经验进入训练、训练后的模型再返回搜索。它试图优化的是 AI 研发循环，而不是证明一个模型已经获得了无限递归升级能力。

因此，更准确的理解是：OpenRSI 是一套面向可执行 AI4AI 研究的实验栈，Frontis-MA1 则是建立在这套栈上的 MLE Meta-Evolution Agent。

OpenMLE不是单个Agent，而是一条闭环工程链

从仓库结构看，OpenMLE 被拆成三层：

层级	组件	主要职责
任务与环境	OpenMLE-Gym	构造任务包、提取元数据、执行程序并进行自动评估
算子训练	OpenMLE-RL	通过执行反馈进行 SFT 和在线强化学习
测试时搜索	OpenMLE-Evo	将原子算子组合成长程程序搜索

Frontis-MA1 位于这三层之间：它是经过后训练的模型，负责执行程序演化操作；OpenMLE-Evo 则决定这些操作如何被调度、组合和反复执行。

这种拆分比“一个 Agent 调用若干工具”更有研究价值。因为模型、搜索框架、任务环境和评估器被分开之后，才能做控制变量实验：究竟是模型变好了，还是搜索策略投入了更多计算，或者只是评估环境发生了变化。

OpenMLE-Gym：先把研究问题变成可验证任务

OpenMLE-Gym 负责构造、描述、执行和检查 MLE 任务包。它还包含 OpenMLE Sandbox，用于给 OpenMLE-Evo 和 OpenMLE-RL 提供分布式代码执行与自动评估，并支持 CPU/GPU 作业调度和可选的多控制器路由。

这一层解决的是整个闭环的地基问题：模型生成的代码必须在确定的环境里运行，结果必须由明确的指标判断。

这类系统真正困难的部分，往往不是“让模型写代码”，而是任务封装：

• 数据如何准备；

• 依赖如何隔离；

• 运行资源如何限制；

• 指标方向是越大越好还是越小越好；

• 失败与无效提交如何处理；

• 训练任务与评估基准如何去重；

• 上游数据无法重新分发时如何提供重建脚本。

根据项目发布文档，技术报告涉及 5758 个 OpenMLE-Gym 环境。其中 1415 个任务发布完整任务包，另外 4343 个任务由于源数据许可证和版权限制，只发布 prepare.py、metric.py 等重建脚本。

这说明 OpenMLE 的“开放”并不等于把所有运行材料塞进一个仓库。它更接近代码、任务清单、可重建流程和部分完整任务包的组合发布。

OpenMLE-RL：训练的不是笼统“Agent能力”，而是四类操作

OpenMLE 将模型的程序演化行为拆成四个原子算子：

• Draft：从零生成程序。

• Improve：结合执行反馈改进一个父程序。

• Debug：修复无法正常运行的程序。

• Crossover：重组两个父程序中的方案。

这四类算子的设计并不复杂，但它解决了训练和推理之间一个常见的不一致问题。

很多 Agent 系统在训练阶段优化的是单轮回答，推理阶段却要求模型在长程循环中调用工具、修改代码和利用历史反馈。OpenMLE 选择让训练与搜索共享同一套动作空间：SFT 和在线 RL 学习的是 Draft、Improve、Debug、Crossover，测试时搜索组合的还是这四类操作。

本质上，OpenMLE 没有要求模型一次生成最终答案，而是训练它成为一个更合适的“局部程序变换器”。长程能力则由模型算子与外部搜索系统共同实现。

OpenMLE-Evo：把局部算子组合成长程搜索

单次 Improve 能带来的增益通常有限。OpenMLE-Evo 的作用，是把程序视为搜索节点，通过反复生成、执行、评分和选择，让后续改进建立在已有候选之上。

这里需要区分两件事：

• 模型决定一次 Draft、Improve、Debug 或 Crossover 的质量；

• 搜索系统决定选择哪个父节点、保留哪些候选、何时执行哪种操作，以及并发资源如何分配。

因此，Frontis-MA1 的最终成绩从一开始就是“模型与搜索框架共同作用”的结果，而不是普通意义上的单模型一次性生成分数。

从源码看，程序演化如何变成可追踪状态

OpenMLE-Evo 中的 ProgramDatabase 很能说明这套系统的工程思路。

每个候选程序不只是保存一段 code，还会记录：

• score：沙箱执行得到的原始分数；

• reward：根据分数计算出的奖励；

• fitness：搜索选择使用的适应度；

• base_reward：未考虑父节点等因素前的基础奖励；

• run_log：执行日志；

• feedback：评估器或搜索策略提供的反馈；

• parent_id 与 parent_code：父程序及其代码；

• generation_mode：Draft、Improve、Debug 或 Crossover；

• raw_text：模型原始输出；

• metadata：附加运行信息。

这组字段意味着搜索过程不是一串相互独立的代码生成，而是一棵可以追踪父子关系的程序演化树。一个候选为什么出现、通过什么操作产生、执行结果如何，都可以被保存下来。

数据库使用 SQLite 做持久化。每个线程维护自己的连接，同时通过写锁串行化数据库写入。表中还为任务名和按适应度排序的查询建立了索引。

更关键的是，每个任务可以设置 max_per_task，数据库会按照 fitness 保留 Top-K 程序，删除排名之外的候选。其逻辑大致是：


SELECT id FROM programs
WHERE task_name = ?
ORDER BY fitness DESC
LIMIT ?

这实际上承担了一个简化的“精英保留”机制。搜索不会无限累积所有候选，而是维护一个有限的高质量程序池，后续 Improve 或 Crossover 再从这些候选上继续推进。

项目还定义了 ROLLOUT、STEP 和 TASK 三种数据库生命周期模式。仅从给出的代码片段不能完整判断每种模式在所有运行配置中的调用方式，但可以确认数据库边界被设计成可按 rollout、训练步骤或任务管理，而不是只能使用一个全局状态。

这里还有一个值得注意的细节：score、reward 和 fitness 被明确分开。默认情况下 fitness 会对齐 reward，但字段层面保留了独立性。这为搜索选择与训练奖励使用不同变换留下了空间，也避免把评估器原始分数直接等同于所有优化目标。

两类昂贵资源必须分别限流

长程程序搜索会同时消耗两种资源：

1. LLM 推理资源，用于生成和修改代码；

2. 沙箱资源，用于运行程序、训练模型和评估结果。

这两类资源的容量通常不同。如果只设置一个统一并发数，很容易出现模型服务空闲但 GPU 沙箱拥堵，或者沙箱空闲但 LLM 请求排队的情况。

airaevo_concurrency.py 为 LLM 和 Sandbox 分别建立共享信号量：

• acquire_llm_slot

• acquire_sandbox_slot

• acquire_llm_slot_async

• acquire_sandbox_slot_async

共享并发服务通过 multiprocessing 的 Manager 暴露信号量，子进程从环境变量中读取地址、端口和认证信息，再连接到同一组并发限制。

同步和异步调用都会统计获取资源前的排队时间。异步版本使用非阻塞获取加轮询，避免直接阻塞事件循环。

这类实现看起来不像算法创新，却直接决定系统能不能稳定运行。OpenMLE-Evo-Max 引入异步多 GPU 搜索后，真正需要处理的不是简单“把并发开大”，而是限制不同阶段的在途任务，防止 LLM 服务或执行沙箱被瞬时请求淹没。

代码中的 resolve_task_concurrency_per_epoch 还会根据 LLM 并发、沙箱并发、epoch 数量和异步 worker 数量推导每个 epoch 的任务并发。它试图让总任务 worker 数与资源上限匹配，而不是让每个训练进程各自假设自己独占全部资源。

异步Rollout不是批量等待，而是持续生产轨迹

OpenMLE-RL 中的 fully_async_rollout.py 实现了一个常驻异步 Rollout Worker。

它不是每次训练需要数据时才临时启动一批生成任务，而是在独立线程中运行事件循环，持续从 data_buffer 取出样本组，调用 generate_and_rm_group 生成轨迹，并把完成结果放入输出队列。

这种设计的目的，是让轨迹生成与训练消费不必严格同步。生成速度存在波动时，缓冲区可以吸收一部分差异。

不过异步并不等于无限并发。代码明确将最大在途任务数限制为 rollout_batch_size，并特别注明不使用“服务并发数乘引擎数”作为上限，因为那样会让 SGLang 被大量长轨迹请求淹没。

失败处理也不是简单丢弃。只要一组样本中存在生成中止状态，系统就会：

1. 将样本状态恢复为 PENDING；

2. 清空响应、Token、loss mask 和 rollout log probability；

3. 删除生成中止相关的 metadata；

4. 把整个 group 放回数据缓冲区等待重试；

5. 不把这组异常数据送进训练引擎。

这里选择“整组重试”而不是只保留部分成功样本，是因为组内奖励与优势计算通常要求候选来自同一个比较上下文。混入残缺 group，可能会破坏后续组内归一化。

评估阶段则会暂停新的训练 Rollout 提交，等待当前在途任务清空，再执行 eval_rollout。评估结束后恢复异步 worker。这样做避免训练轨迹生成与评估同时争抢推理资源，也让评估过程更容易维持一致的资源边界。

动态奖励边界：不同任务的原始分数不能直接比较

机器学习任务的指标尺度差异很大。有的使用准确率，有的使用误差，有的指标越高越好，有的越低越好。直接把原始 score 当作强化学习奖励，很容易让不同任务产生不稳定的奖励尺度。

adaptive_reward_advantage_utils.py 先通过 signed_score 统一指标方向，再从历史分数和当前 group 分数中估计动态边界。

代码支持多种边界模式：

• 最优值与 Top-8 候选；

• 最优值与 Top-16 候选；

• 最优值与全部候选均值；

• 最优值与全部候选中位数；

• 理论上下界。

动态边界还会与任务元数据中的静态理论边界进行约束。如果动态边界缺失或不是有限值，就回退到静态边界；如果上下界重合或顺序异常，则通过最小跨度修正。

这类设计要解决的不是让奖励“更聪明”，而是避免早期候选、异常分数或不同量纲让奖励映射失真。

在优势计算上，代码提供了两类实现。

第一类是组内中心化与标准差归一化：

第二类是基于目标 KL 求解温度参数的 entropic advantage。实现会通过二分搜索找到满足目标 KL 的，再根据指数权重计算每个候选相对于 leave-one-out 基线的优势。

材料不足以确认这些模式在所有公开训练配置中的具体占比和最终消融结果，但从源码可以确定，OpenMLE-RL 并不是简单把执行分数原样送入训练，而是在处理任务方向、动态尺度、组内比较和异常边界。

为什么一定要区分模型收益与搜索收益

OpenRSI 的结果最容易被误读的地方，是把 OpenMLE-Evo-Max 的端到端成绩直接当作 Frontis-MA1 的模型提升。

项目文档对此给出了明确边界。

MLE-Bench Lite 的主要评估使用官方 22 个任务，进行三次独立运行。每个任务的沙箱计算预算为 12 小时，硬件是单张 NVIDIA RTX 4090，并限制在 12 GB 显存。

在固定 OpenMLE-Evo 搜索框架时，35B 模型的结果如下：

模型	搜索框架	Valid Rate	Medal Average	Human Rank
Qwen3.6-35B-A3B	OpenMLE-Evo	19.67/22	39.39%	0.5828
Frontis-MA1-35B	OpenMLE-Evo	21.67/22	60.61%	0.7647

由于搜索框架保持不变，39.39% 到 60.61% 的 Medal Average 提升可以归因于后训练模型在该框架下的收益。差值是 21.22 个百分点。

而 71.21% 来自另一个配置：

模型	搜索框架	Valid Rate	Medal Average	Human Rank
Frontis-MA1-35B	OpenMLE-Evo-Max	22.00/22	71.21%	0.8126

OpenMLE-Evo-Max 增加了与 MLE-Bench 不重叠的经验先验，并使用异步多 GPU 搜索。虽然总沙箱计算量保持固定，但搜索系统已经发生变化。因此 71.21% 是端到端系统结果，不能被描述为纯模型分数。

同样的边界也适用于其他模型。文档中 GLM-5.2 和 MiniMax M3 在 OpenMLE-Evo 或 OpenMLE-Evo-Max 下也获得了相对各自通用 Coding Harness 更高的部分指标。这支持的是“领域化演化搜索可以改善固定模型的 MLE 系统表现”，而不是证明底层模型在脱离 Harness 后一定更强。

搜索效率不等于墙钟速度

项目还比较了 OpenMLE-Evo 与原始 AIRA-Evo。比较使用相同的 Frontis-MA1-35B checkpoint、随机种子和 12 小时任务预算，共覆盖 66 个匹配的 task-run。

指标	原始 AIRA-Evo	OpenMLE-Evo	变化
总模型 Token	129.3M	75.3M	-41.7%
Prompt Token	83.5M	41.5M	-50.3%
评估节点数	3430	3004	-12.4%
验证集新最优更新	229	246	+7.4%
每百万 Token 新最优更新	1.77	3.27	+84.3%
Improve 产生新最优的比例	4.73%	9.36%	+4.63 个百分点

这些数字说明 OpenMLE-Evo 在匹配实验中使用了更短上下文和更少 Token，同时获得了更多新最优更新。但项目文档没有把它表述为墙钟时间上的加速，因此不能从这些结果继续推导“运行速度提高了多少”。

NatureBench提供的是有限迁移证据

在 NatureBench Lite 上，实验使用覆盖六个科学领域的固定 10 个任务，关闭 Web 搜索，采用隐藏评估器和四小时搜索预算。

结果如下：

模型	框架	Surpass-SOTA	Match-SOTA
Frontis-MA1-35B	OpenMLE-Evo NatureBench Adapter	30%，3/10	70%，7/10
Qwen3.6-35B-A3B	OpenMLE-Evo NatureBench Adapter	20%，2/10	50%，5/10
Qwen3.6-35B-A3B	原始 AIRA-Evo	10%，1/10	20%，2/10

固定 Adapter 时，替换成后训练模型，Match-SOTA 从 50% 提升到 70%；固定基础模型时，替换搜索框架，Match-SOTA 从 20% 提升到 50%。

这个实验至少说明模型训练和搜索框架的收益并非完全局限于 MLE-Bench Lite。但样本只有 10 个任务，所以它只能被视为定向迁移证据，不能外推为对完整 90 任务 NatureBench 的结论，更不能据此宣称已经具备通用科学研究自治能力。

这套系统真正提供了什么

从工程角度看，OpenRSI 最有价值的不是某一个榜单数字，而是把 AI4AI 拆成了几个可以分别研究的对象：

• 任务能否被封装成可执行环境；

• 执行反馈能否转化为稳定奖励；

• 模型能否学会局部程序演化算子；

• 搜索能否有效组合这些算子；

• 程序谱系与收益能否被持久化；

• 模型收益和 Harness 收益能否通过控制变量区分；

• 搜索产生的经验能否重新进入训练。

这套拆分也让失败更容易被定位。

如果代码大量无法运行，问题可能在 Draft 或 Debug；如果候选都能运行但无法持续提升，问题可能在 Improve、Crossover 或父节点选择；如果模型调用正常但沙箱拥堵，问题在资源调度；如果训练不稳定，则需要检查奖励尺度、group 完整性和优势计算。

相比把所有能力封装进一个难以解释的 Agent，这种结构更接近可实验的 Infra。

不过，它的边界也同样明确。

首先，整个闭环依赖可执行程序和可量化评估器。对于目标含糊、反馈稀疏、难以自动验证的研究活动，这套方法不能直接照搬。

其次，搜索仍然需要显著计算预算。MLE-Bench Lite 使用每任务 12 小时沙箱预算，NatureBench Lite 使用四小时搜索预算。OpenMLE-Evo-Max 还涉及异步多 GPU 搜索。它优化的是单位预算内的搜索过程，不代表长程搜索已经变得廉价。

再次，训练与推理效果依赖任务分布和评估器质量。如果评估指标无法覆盖真正目标，系统也可能只是在优化代理指标。OpenRSI 通过隐藏评估器、Held-out Benchmark 和去重降低这类风险，但没有从根本上消除它。

所以，更合适的结论不是“OpenRSI 实现了递归自我改进”，而是：

它给出了一套可以运行、训练、搜索和做控制变量实验的 MLE Meta-Evolution 系统，并把通向更一般 AI4AI 的部分问题暴露成了具体工程接口。

复现之前，需要先看清公开边界

OpenRSI 仓库不是一个安装依赖后即可完整复现实验的单体项目。OpenMLE-Gym、SFT、RL 和 Evo 分别维护自己的环境与入口，仓库没有提供一个合成式顶层命令。

公开仓库包含：

• OpenMLE-Gym 的任务构建和评估工具；

• SFT 的 Rollout 收集、数据选择和训练启动代码；

• OpenMLE-RL 的在线强化学习实现；

• OpenMLE-Evo 的标准与异步搜索运行时；

• MLE-Bench 和 NatureBench 的部分 Adapter、配置及运行文档；

• 三个公开 Smoke 任务包。

但以下材料被单独分发，或者不在代码仓库中：

• Frontis-MA1 模型权重；

• OpenMLE Tasks 任务产物；

• SFT 训练轨迹；

• 外部 Benchmark 环境与数据；

• 沙箱服务；

• 服务凭据与推理 Endpoint；

• 训练 checkpoint；

• 私有基础设施配置；

• 已生成的运行输出。

README 给出的 NatureBench 本地快速开始，也需要额外克隆 NatureBench、创建独立 Conda 环境，并配置模型服务地址和 API Key。Smoke 模式只生成并评估一个候选；移除 --smoke 才会进入完整的单任务搜索配置。

此外，公开文档明确说明，35B 仓库保留了上游视觉和 MTP 组件，但 OpenMLE 后训练与报告的评估覆盖的是文本和代码行为，不能据此扩展出未验证的多模态结论。

许可证方面，仓库原创 OpenRSI 和 OpenMLE 材料使用 CC BY-NC 4.0，要求署名且仅允许非商业使用，商业使用并未获得授权。第三方组件和依赖仍受各自许可证约束。这对希望将代码直接接入商业训练或 Agent 平台的团队来说，是必须提前确认的限制。

最后的判断

OpenRSI 没有解决通用递归自我改进，而且项目自己也没有这样宣称。

它完成的是一件更实际的事：选择机器学习工程这个可执行领域，把“AI 改进 AI”拆成任务环境、程序算子、执行反馈、奖励转换、异步训练和长程搜索，再通过控制变量实验区分模型后训练与搜索系统带来的收益。

真正值得借鉴的，是这种问题收缩方式。

当“自我改进”被约束为程序可以执行、结果可以评分、轨迹可以保存、父子关系可以追踪、收益可以归因之后，它才从概念叙事变成工程系统。至于能否从 MLE Meta-Evolution 继续走向更一般的 AI4AI，现有材料还不足以给出答案。

但至少，OpenRSI 把这个问题推进到了可以读代码、跑任务、查日志、看消融和讨论复现边界的阶段。对于当前大量停留在 Prompt 和 Agent Loop 层面的“自进化”项目来说，这一点比 RSI 这个名字本身更重要。

原始链接

• https://github.com/FrontisAI/OpenRSI

• https://frontisai.github.io/OpenRSI/

• https://arxiv.org/abs/2607.28568

• https://huggingface.co/FrontisAI/Frontis-MA1-35B

• https://huggingface.co/FrontisAI/Frontis-MA1-30B

• https://huggingface.co/datasets/FrontisAI/OpenMLE-Tasks

• https://huggingface.co/datasets/FrontisAI/OpenMLE-SFT-Traces

• https://github.com/FrontisAI/NatureBench