CodeMidas

自动研究时间：2026-09-22 09:05（Asia/Shanghai）
来源日期：Hugging Face Daily Papers 页面实际显示 Sep 21，列表最顶部为 CodeMidas: Scaling Agentic Coding RL Environments from Code Itself。¹
研究路径：Daily Papers 列表 -> Hugging Face 详情页 -> arXiv 摘要页 -> arXiv v1 完整 HTML、PDF、LaTeX 正文与附录。本文不以列表摘要代替论文正文。

执行摘要

编码智能体强化学习的真正瓶颈，越来越不像“缺少代码”，而像“缺少同时具备任务说明、可运行开发环境和可信 verifier 的训练单元”。以 issue、pull request、commit 或既有测试为种子的流水线能获得真实任务，却被项目历史记录的覆盖范围限制。大量已经实现、但从未对应一个清晰 issue 或独立测试的功能，仍然沉睡在源码中。

CodeMidas 的核心主张是：源码本身就可以成为可扩展的编码 RL 环境原料。它让智能体识别具有公共入口和可观察行为的已实现功能，移除核心实现并保留原始版本作为 reference solution；随后从原实现的执行结果构造行为测试，清理泄漏，检查空实现必败、参考实现必过，再用多轮 agent rollout 过滤 verifier 缺陷和难度不合适的任务。最终流水线从 22,575 个候选中保留 5,545 个任务，来自 3,185 个开源代码库，覆盖 23 种语言和 15 个技术领域。²

作者用这些任务对 MiMo-V2.5 做 GRPO，奖励只有隐藏 verifier 的二元通过结果。训练后模型在五个外部基准上全部提升：SWE-bench Pro 从 50.3% 到 54.4%，DeepSWE 从 10.0% 到 21.7%，ProgramBench 的 Almost Solved 从 4.5% 到 21.5%，RepoZero C2Rust 从 40.5% 到 51.8%，Terminal-Bench v2.1 从 63.7% 到 72.2%。³ 这组跨 issue repair、从零构建、代码翻译和终端操作的迁移结果，是论文最强的证据。

更重要的消融结论是“质量优先于粗放规模”：经过完整清洗和过滤的 3k 子集，在 SWE-bench Pro、DeepSWE 和 CodeMidas Val 上都超过约 8k 个未清洗候选。轨迹分析还观察到，RL 后的智能体在首次编辑前读取和搜索更多代码，写入代码与先前推理的重合度更高，最终编辑后执行的验证命令更多；其中 agent 自己编写并执行检查，与同任务、同 checkpoint 下高 4.2 个百分点的通过率相关。⁴

但这篇论文并未证明“自动生成的测试已经等价于真实软件需求”。任务保留与难度判断依赖特定筛选模型和预算；主实验只训练一个基础模型、使用一种 RL 算法；没有报告环境构造总成本、不同阶段的模型调用成本或多随机种子训练方差。自验证与成功率的关系也是观察性关联，不是因果结论。CodeMidas 更准确的定位，是一套证据充分的训练环境工厂设计：它证明源码能被系统地转化为有效 RL 信号，也把真正难题从“有没有数据”推进到“如何以可承受成本持续证明 verifier 可靠”。

1. 论文基本信息

核心链接：

• Hugging Face 详情页：https://huggingface.co/papers/2609.22068
• arXiv 摘要页：https://arxiv.org/abs/2609.22068
• arXiv 完整 HTML：https://arxiv.org/html/2609.22068v1
• arXiv PDF：https://arxiv.org/pdf/2609.22068
• 官方项目页：https://mimo.xiaomi.com/rl/

2. 背景与动机：代码很多，可靠的 RL 环境仍然稀缺

2.1 一个训练任务不只是自然语言题目

对编码智能体做可验证强化学习，至少要同时拥有三样东西：

1. 任务说明：明确输入、公共接口和外部可观察行为，同时不过度规定内部实现；
2. 开发环境：包含真实项目结构、依赖、构建工具与待实现代码，但不能泄露答案；
3. 可执行 verifier：能拒绝错误实现，也能接受与参考补丁不同的正确实现。

只从 issue 抽一句需求不够，只保留原项目测试也不够。issue 可能省略关键边界，既有测试可能依赖私有实现，删除目标代码后还可能留下编译产物、缓存或安装副本，让智能体直接找回答案。环境构造因此同时是 specification、program transformation、test oracle 和 sandbox hygiene 问题。

2.2 现有流水线依赖开发痕迹

SWE-bench、SWE-rebench V2、SWE-Universe、R2E-Gym 等路线从 issue、PR 或 commit 提取任务；SWE-smith、SWE-Flow、SWE-Hub 依赖既有测试或围绕测试合成修改；R2E 与 MindForge 则依赖文档、docstring 或已编译参考程序。它们各自有效，但能生成什么任务，取决于仓库是否留下相应的历史痕迹。

源码覆盖面更广：一个公共函数、CLI 或有状态 API 即使没有 issue，也已经把某种行为固化在实现里。原实现还能充当候选解和执行 oracle。CodeMidas 要解决的问题，就是如何把这种“隐含规格”显式化，同时避免把实现细节误写成唯一正确答案。

2.3 为什么不能直接删除函数再补几个断言

朴素做法有三个典型失败点：

• 规格不足：测试检查了任务说明没有承诺的顺序、错误文本或内部结构；
• 验证不足：少量 happy path 让投机实现也能通过；
• 环境泄漏：编译文件、缓存、Git 历史、已安装包或构造日志暴露原实现。

因此，CodeMidas 把 agentic compute 分配到整个流水线，而不是只让一个模型生成最终题目。它的创新重点不在某个单独 prompt，而在多阶段生成、执行、对抗和复核组成的质量控制闭环。

3. 核心贡献

3.1 把“任务特定输入”压缩到源码

CodeMidas 不要求候选功能必须有 issue、PR、commit、已有测试或人工书面描述。仓库元数据和统一容器当然仍属于基础设施，但针对某个任务所需的语义起点只有源码。与“没有任何外部工具或模型先验”不同，这里的 source-only 指无需额外任务痕迹。

3.2 建立从已实现功能到可执行环境的端到端流水线

流水线把任务设计、测试构造、环境准备与 rollout 后过滤连成一体。每个最终任务都包含 statement、containerized development environment 和隐藏 verifier；求解智能体看不到 verifier，评分时才将其注入环境，返回 0 或 1 的执行奖励。

3.3 用执行证据而非语言判断单独约束 verifier

测试期望来自原代码实际执行；任务在六个全新容器中重复验证；agent 生成解还要经过独立 reviewer 与 verifier 判定的一致性审查。这并不能消除 test oracle 问题，但比单次 LLM judge 或仅验证参考答案通过，多了几层互补证据。

3.4 同时验证任务规模、质量和行为变化

论文不仅报告最终分数，还比较 1k、3k、5,545 个高质量任务与约 8k 个未清洗候选，并分析训练前后 rollout 行为。这样可以把“更多任务”“更可靠任务”和“模型学到什么行为”三类问题部分拆开。

4. 方法：CodeMidas 如何把源码变成 RL 环境

4.1 任务设计与代码库改造

构造智能体先检查项目结构和构建元数据，寻找具有公共入口和可观察结果的功能。论文支持三类接口：

• CLI：通过进程输出、退出状态和外部副作用评测；
• 纯函数：通过输入—返回值映射评测；
• 有状态 API：通过多次调用之间的状态变化、顺序和清理行为评测。

智能体沿公共入口追踪共享依赖，确定功能边界，移除核心实现，并同步修改剩余代码与题面，使起始仓库仍是连贯的开发现场。原实现被单独保留为 reference solution。题面只规定输入、可观察行为和公共接口，求解者仍可自由选择内部算法与辅助结构。

这一阶段的关键不是“把函数体清空”，而是选择需要跨文件推理、又能通过公共行为验证的任务。如果范围太小，RL 只会学习局部补全；如果范围太大，规格和 verifier 都更难可靠。

4.2 基于参考执行构造测试

测试智能体把题面的每条行为要求映射到输入与边界案例，然后在 reference copy 上调用公共入口并记录结果：

• CLI 测命令执行；
• 纯函数测 input-output cases；
• 有状态 API 测调用序列和跨调用依赖。

若题面固定了输出，断言可用参考执行得到精确期望；若题面只约束某种性质，断言只能检查该性质。例如题目要求抛出某类异常，但未规定 message，就不能把参考实现的错误文本写死。

随后另一个智能体逐条审查 assertion，移除题面不支持的精确措辞、偶然顺序和内部结构约束。依赖私有符号且找不到行为替代的任务直接拒绝。修订后的测试还要重新在 reference solution 上执行。

4.3 环境清理与六次一致性检查

环境以统一基础容器为起点，按项目声明安装依赖和构建资源。清理阶段移除可能泄露答案的编译输出、缓存副本、构造智能体残留文件，以及与目标功能有关的原测试；同时保留完成任务所需的包、fixture 和 build wrapper。

每个任务在训练时相同的 runtime setting 下启动六个新容器：

• 起始代码运行 2 次，必须全部失败；
• 放回参考实现运行 4 次，必须全部通过。

这一步同时检查 fail-to-pass 转换和基本稳定性。它排除了“空实现也过”“参考实现偶发失败”这两类明显无效环境，但还不能证明 verifier 对所有替代实现都正确。

4.4 三层 rollout 后过滤

泄漏过滤要求对抗智能体主动搜索整个 solver-visible environment，包括编译产物、缓存、残留文件和已安装的目标项目。它记录命令与输出，另一个 reviewer 再与 reference solution、verifier 对照；确认能绕过预期开发工作的任务被拒绝。

agent solution 一致性审查让编码智能体对每个任务尝试 4 次。reviewer 同时查看题面、提交代码、轨迹、测试输出、verifier 和参考实现，判断代码是否真的满足要求，再检查 verifier 是否出现 false positive 或 false negative。发现验证缺陷的任务被拒绝。

rollout outcome filtering再让 frontier model 多次作答，只保留同一预算下既有成功、又有失败的任务。all-pass 可能过于简单或测试过弱，all-fail 可能过难或题面、环境仍有缺陷；论文不声称能区分原因，而是保守丢弃两端。

4.5 数据漏斗

最终保留率约为初始候选的 24.6%。这组数字说明，“从代码合成任务”本身不是最昂贵的质量门槛；约四分之三候选在后续验证中被淘汰，可靠环境主要是筛出来的。

5. 数据集与训练配置

5.1 覆盖面与任务复杂度

5,545 个训练任务来自 3,185 个代码库。Python 占 21.4%，TypeScript 18.3%，Go 16.2%，C++ 12.5%，JavaScript 11.3%；前十种语言覆盖 98.2% 的任务。最大的三个领域是系统软件 17.4%、Web 技术 14.6% 和开发者工具 13.6%，合计 45.6%。²

参考补丁的中位规模为 142 行，四分位区间 66–305 行；65.9% 的任务至少改动两个源文件。它们因此不同于单函数算法题，但参考补丁行数仍只是粗粒度代理，不能直接等价于推理难度。

5.2 强化学习设置

32 个 task batch、每任务 32 条 rollout，意味着一个 batch 可产生 1,024 条轨迹。超长 response 上限和 500 轮上限也表明，这不是短代码生成训练，而是允许长时程工具交互的 agent RL。

5.3 评测隔离

CodeMidas Val 从训练集之外随机抽取 200 个任务，每任务评测 3 次。作者声明训练集与 CodeMidas Val 及五个外部 benchmark 的任务集合互不重叠。ProgramBench 使用 Almost Solved，即至少通过 95% 测试的任务比例；其余评测报告 pass rate。

这里应注意，“任务不重叠”没有自动回答仓库级重叠、相似功能或预训练记忆问题。论文展示的是 RL 训练集与评测 task set 的形式隔离，不是对所有语义污染路径的完整审计。

6. 实验结果

6.1 五项外部基准全部提升

最值得关注的不是某个最大数字，而是任务形态跨度。训练任务来自“删除已有功能再重建”，外部评测却包含修复 issue、从零构建、C 到 Rust 翻译和通用终端操作。若训练只教会模型猜测合成测试，迁移很难同时出现在五种场景。

不过，论文只比较同一个初始策略训练前后，没有与等计算量的其他 RL 数据集、混合训练集或随机任务池做完整横向对照。因此可以说 CodeMidas 数据有效，不能仅凭这组实验断言它是同等预算下最优的数据来源。

6.2 CodeMidas Val 的学习曲线

验证集 pass rate 从初始策略的 35.0% 升至 44.7%。从 step 40 起，各评测 checkpoint 大致保持比初始值高 8–10 个百分点。与此同时，平均轨迹 token 长度增加，说明模型更多地使用可用交互预算。

更长轨迹本身不是质量指标：它可能代表更充分探索，也可能代表冗余尝试。论文后续通过读写与验证行为拆解，才给“预算被用于什么”提供了更细证据。

6.3 高质量规模扩张具有单调收益

作者分别用随机 1k、3k 和完整 5,545 个高质量任务训练，并加入约 8k 个未做环境清理、执行一致性检查和三层 rollout 后过滤的 vanilla 候选作对照。

完整 5k 数据相对 vanilla 8k，在 SWE-bench Pro、DeepSWE、CodeMidas Val 上分别高 0.59、4.59、4.49 个百分点；甚至 3k 高质量子集也在三项评测上全部超过 8k。⁴

这项消融支持“质量门控有用”，但不能把贡献精确分摊给某一个过滤阶段。vanilla 8k 同时缺少清理、六次执行检查和三种 post-rollout filtering，所以实验测到的是整套质量流程的联合效应。

6.4 行为变化：先看更多，再写，再验证

作者为 rollout 定义三类行为指标：

• 代码库探索：第一次编辑前，不重复的 read/search 请求数；
• 代码草拟：Write/Edit 内容中的 16 字符片段，有多少已在此前 reasoning 中出现；
• 自验证：最后一次代码编辑后，不重复的测试、临时程序或本地运行命令数。

在 CodeMidas Val 的同一任务、同一 checkpoint 内，编写并执行自有检查的 rollout，平均 pass rate 比没有这类检查的 rollout 高 4.2 个百分点，95% 置信区间为 1.8–6.6。以 checkpoint 中位数切分探索与草拟后，差异分别只有 +0.7 pp（95% CI -1.9–3.7）和 +1.95 pp（-0.04–3.96），置信区间跨过或接近 0。⁴

因此，论文对 self-verification 的关联证据较强，对“更多探索或更多先写推理必然提高成功率”的证据较弱。RL 可能同时提升能力和这些行为，不能从相关性直接推出行为是增益原因。

6.5 行为变化迁移到 held-out 任务

三项外部任务都出现更多代码库探索，但总交互长度并非统一增加。ProgramBench 中探索更多、总轮数反而从 155.1 降到 122.8，可能意味着前期信息收集减少了后续试错；SWE-bench Pro 和 Terminal-Bench 则使用更多总轮次。合理结论是模型学到了一组可迁移的工作习惯，而不是固定的“把轨迹拉长”策略。

7. 如何理解这篇论文的关键机制

7.1 源码是“行为证据”，不是天然规格

原实现可以告诉构造系统某个输入实际产生什么输出，但实现中的每个细节都不一定是需求。CodeMidas 的 assertion review 正是在源码事实与用户可见契约之间做切割。它的技术难点不是读取代码，而是决定哪些观察应该成为约束。

7.2 reference solution 同时扮演三个角色

原实现既是候选任务的来源，也是 test oracle 的执行对象，还是检查 agent solution 与 verifier 判定时的对照。这带来规模优势，也形成共同失效点：如果任务说明错误地抽象了原实现，后续多个阶段可能共享同一偏差。因此，多 agent review 能降低错误率，却不等于独立 ground truth。

7.3 mixed-outcome filtering 是实用启发式，不是难度真值

只保留有成有败的任务，能排除明显过易、过难或可疑样本，并为 GRPO 提供组内奖励差异。但“同一个 frontier model 在固定预算下恰好有成有败”是模型相关、预算相关的条件。换一个更强模型后，今天的优质任务可能变成 all-pass；换一个弱模型则可能变成 all-fail。生产流水线因此需要持续重估，而不是一次生成永久有效的数据集。

7.4 二元奖励把复杂性前移到 verifier

训练阶段不需要 learned reward model，也不需要对过程逐步打分，优化信号很干净。但代价是所有信用分配都压缩到最终 0/1。CodeMidas 的路线不是让奖励更复杂，而是投入更多计算把环境和 verifier 做得足够可靠，再通过大量 rollout 从稀疏终局奖励学习。

8. 局限与证据边界

8.1 只验证了一个基础模型和一种 RL 配方

主结论来自 MiMo-V2.5 + GRPO。不同模型的代码先验、工具调用能力、上下文管理和探索策略不同，数据收益不一定等比例迁移。论文也没有把相同数据用于 SFT、DPO 或其他 RL 算法作系统比较。

8.2 构造成本没有形成闭环

每个候选要经历多个构造 agent、六个新容器、对抗泄漏搜索、四次 coding attempt、reviewer 审查和额外 frontier-model rollouts。论文报告了数据漏斗，却没有给出每个保留任务的 token、GPU、容器时长、失败重试和美元成本。对准备复现的团队，这可能比最终任务数更决定可行性。

8.3 过滤阶段被打包评估

5k 对 vanilla 8k 的对照同时改变了环境清理、执行一致性和三类 post-rollout filtering，无法判断收益主要来自哪一层，也无法计算各阶段的边际性价比。一个更强的实验应逐层加入过滤并报告质量、成本与下游收益曲线。

8.4 verifier 可靠性仍是有限样本判断

参考实现 4 次通过、起始状态 2 次失败，只覆盖两个代码状态；四条 agent 解与 reviewer 审查也只采样很小的解空间。隐藏测试仍可能接受未见过的投机实现，或拒绝结构不同但正确的实现。论文显著降低了风险，没有从形式上消除 specification gap。

8.5 难度分布受筛选模型塑形

all-pass/all-fail 过滤会把数据集中到筛选模型的能力边界附近。这对 on-policy 学习很有用，却可能牺牲技能覆盖：极难但有效的长时程任务和极易但能补基础短板的任务都会被丢弃。数据集的“高质量”同时包含可靠性与训练适配性，二者没有被完全分开。

8.6 外部评测缺少不确定性报告

论文给出单组分数和绝对增益，但没有在主结果中报告多训练随机种子方差或各 benchmark 的置信区间。ProgramBench +17.0 pp、DeepSWE +11.7 pp 很大，结论较稳健；SWE-bench Pro +4.1 pp 则更需要重复训练和统计区间帮助判断稳定性。

8.7 行为指标是代理量

更多 read/search 可能是认真探索，也可能是效率下降；更高 drafting ratio 表示最终代码片段更常出现在 reasoning 中，不等价于推理更正确；更多验证命令也可能重复覆盖同一逻辑。论文通过去重定义和 held-out 分析提高了可信度，但这些指标仍不能完整表示软件工程质量。

8.8 供应链、许可与安全问题需要额外治理

从数千个开源仓库抽取代码、构造 reference patch 和容器，会遇到许可证兼容、依赖漏洞、恶意构建脚本、网络访问和 secrets 清理问题。论文重点处理答案泄漏，没有给出完整的软件供应链治理框架。将方法迁移到企业私有仓库时，还需要代码权限、日志脱敏与训练数据留存策略。

9. 应用影响

9.1 编码 RL 数据生产可以摆脱 issue 密度

成熟仓库往往有大量实现，却只有一部分功能对应结构化 issue 和可复用测试。CodeMidas 允许从实现本身反向生成任务，尤其适合历史记录不完整、多语言或内部工具占比较高的代码资产。

9.2 企业私有代码可以变成域内训练环境

在严格隔离的基础设施中，企业可以把内部 SDK、数据管道、CLI 和业务库转成域内任务，让模型学习真实依赖、编码规范和工具链。这比把私有代码直接做 next-token pretraining 更接近实际 agent 工作，但 verifier 与环境构造过程本身也必须留在受控边界内。

9.3 环境工厂可兼作持续评测与回归测试生成器

同一流水线生成的 statement、starting state、reference solution 和 hidden tests，不只可用于 RL，也可用于模型回归评测、agent harness 对比和长时程执行可靠性测试。随着模型能力提升，mixed-outcome filter 还可以周期性刷新任务难度。

9.4 训练目标开始包含“工作方式”

轨迹结果表明，终局执行奖励可能间接强化先探索、再编辑、最后自验证的工作模式。未来数据设计可以进一步显式控制这些行为，例如区分盲目多读与目标导向探索、衡量验证覆盖而非命令数量，并对高价值中间状态提供过程反馈。

9.5 质量控制计算会成为新的规模轴

过去谈训练数据规模，常只数 token 或样本。CodeMidas 暗示编码 RL 的有效规模至少有两条轴：候选任务数量，以及每个任务投入多少构造与验证计算。较小但经过多层执行审计的数据可以超过更大的粗糙数据；数据中心的预算分配因而要在“生成更多”和“证明更可靠”之间优化。

10. 相关工作与定位

10.1 基于开发记录的真实任务

SWE-bench 开创了 repository-level issue resolution 的可执行评测；SWE-rebench V2、SWE-Universe、daVinci-Env、Scale-SWE、SWE-Next 等扩大 issue 和 PR 数据；R2E-Gym 从 commit 生成题面和测试。这些方法的优势是真实开发意图更直接，限制是任务供给受历史记录约束。

CodeMidas 的差异不是“比真实 issue 更真实”，而是从另一条轴扩展覆盖：只要功能已经实现，就可能成为候选，不必等待一次带完整 issue、commit 和测试的历史事件。

10.2 基于测试或文档的任务合成

SWE-smith 合成会破坏现有测试的修改，SWE-Flow 从单元测试及运行依赖构造增量任务，SWE-Hub 结合测试验证的 bug synthesis；R2E 从 docstring 提炼规格，MindForge 使用文档和编译参考程序支持从零实现。

CodeMidas 同时生成题面与测试，原实现只作为执行证据，不要求仓库已有可用测试或书面描述。其风险也正来自这里：规格与 verifier 都由同一源码抽象而来，需要更多独立审查抵消共同偏差。

10.3 编码 RL 的奖励与验证

CodeRL 把单元测试反馈与 learned critic 结合，SWE-RL 使用 reference-patch similarity，SWE-Universe 在可执行环境中训练；SWE-Shepherd、Agentic Rubrics、R2E-Gym 分别使用过程奖励、代码库 grounding rubric 或学习型与执行型 verifier 的组合。

CodeMidas 选择了更简单的训练奖励：隐藏测试通过为 1，否则为 0，不训练 reward model。复杂性全部投入数据生产前的 verifier 构造和筛选。这让奖励语义清晰，但也让测试可靠性成为单点关键基础设施。

10.4 测试 oracle 与错误接受

EvalPlus 表明扩展测试能发现原测试漏掉的错误程序；PatchDiff 展示 SWE-bench 测试可能接受错误 patch；SWE-bench Pro 与 SWE-rebench V2 也讨论规格缺口和过严测试。CodeMidas 的 adversarial leakage、solution audit 和 mixed-outcome filtering，可以看作对这些问题的工程化回应。

11. 综合评价

CodeMidas 最有价值的地方，不是把“让 LLM 出题”包装成新数据集，而是把编码 RL 环境生产拆成可审计的工程流程：规格来自哪里、断言为何成立、环境是否泄漏、参考实现是否稳定、替代实现是否被 verifier 正确判断、任务是否处在可学习区间，每一步都有明确检查。

论文的实验也形成了较完整的证据链：五项外部 benchmark 证明迁移，1k/3k/5k 与 vanilla 8k 对照证明质量门控和规模都重要，轨迹分析则说明模型变化不只体现在终局分数。尤其是高质量 3k 超过未清洗 8k，为“验证计算也是数据规模的一部分”提供了直接支持。

同时，这仍是一篇由强工程系统支撑、但复现成本和归因粒度不足的工作。我们知道整套漏斗有效，却不知道哪一层最划算；知道模型更常自验证，却不知道干预这一行为能否因果提升结果；知道五个基准都涨，却不知道换模型、换 RL 算法或换筛选器后是否保持同样收益。

对研究者，下一步应是逐层消融、成本核算、多模型迁移和 verifier 可靠性测量。对工程团队，最可立即采用的原则则很清楚：不要把仓库中的测试数量当作训练环境数量；从源码挖掘候选后，把主要精力放在行为规格、环境清理、对抗泄漏和替代实现审查上。CodeMidas 证明了代码可以变成 RL 环境，但真正点石成金的是验证流水线。

参考资料