CodeMidas:直接从源码里挖出可训练的编码智能体环境

训练一个真正能干活的编码智能体,靠的从来不只是更大的模型或更多的GPU。强化学习需要的是任务,而且是那种一旦智能体给出输出,就能被自动、可靠地判定「对」还是「错」的任务——也就是需要有验证器。

没有验证器,再多的训练轨迹也只是噪音。这正是新论文《CodeMidas: Scaling Agentic Coding RL Environments from Code Itself》(arXiv:2609.22068)瞄准的核心瓶颈:不是算力不够,而是「可验证的编码任务」这种资源本身太稀缺。

为什么issue和commit不够用

在CodeMidas之前,把开源代码库转成RL训练任务的主流做法,是去挖issue、commit和PR这些「开发过程留下的痕迹」——比如把一个被修复的bug对应的issue和commit配成一对任务和验证条件。这套方法能用,但天花板很低:全球绝大多数已经写好、能跑起来的代码,根本没有对应的issue或PR记录在案。

只盯着开发者留下的元数据,等于把一座矿山里九成以上的矿石直接丢弃。CodeMidas的做法是反过来:完全不依赖issue、commit或PR,只用代码本身作为输入。任何一段已经实现了某个功能的代码,原则上都能被转成一个任务,这把可提取任务的候选池从「有工单记录的那一小撮」扩大到「所有能跑起来的开源代码」。

每一步都交给智能体去做

CodeMidas把智能体计算力用在了环境构建的每一个阶段,而不只是最后的训练阶段。

首先,智能体去探索代码库里已经实现的功能,归纳出「这段代码应该做什么」的行为规格说明;接着,基于对原始代码的实际执行结果,构造出真正扎根于代码行为的测试用例,而不是凭空猜测的断言;最后,通过执行检查和反复的解题轨迹(rollout)对候选任务做验证和过滤,把那些描述模糊、测试不可靠或者根本无法稳定复现的任务筛掉。这种「用执行结果反过来验证任务本身是否可靠」的思路,是整套流程能规模化又不牺牲质量的关键。

广度决定泛化能力

最终产出的数据集包含5545个训练任务,取自3185个开源代码库,横跨23种编程语言和15个技术领域。

这种广度不是锦上添花,而是直接决定了训练出来的智能体是「只会应付某个特定基准的样子货」,还是真正具备可迁移的编码能力。窄基准训练出来的模型很容易过拟合到某种语言、某类项目结构或某种bug模式上;而横跨23种语言、15个领域的任务分布,逼着模型学到的是更通用的「如何理解一个陌生代码库、如何验证自己的修改」这类底层能力。

基准测试提升说明了什么

研究团队用GRPO算法在这些任务上训练了MiMo-V2.5模型,并在五个不同基准上做了评估,其中三项有明确数字:issue修复类基准DeepSWE提升11.7%,整程序构建类基准ProgramBench提升17%,终端操作类基准Terminal-Bench v2.1提升8.5%。ProgramBench的提升幅度最大,这与CodeMidas从「理解并复现完整功能」而非「修补局部bug」出发构造任务的方式相吻合——当训练任务本身就要求智能体理解一段代码的整体行为规格,模型在「从零构建功能」这类任务上进步最明显也就顺理成章。

消融实验进一步显示,训练任务数量的增加会带来性能的持续提升,说明这套「从代码本身规模化生产验证器」的方法还有继续扩展的空间。轨迹分析还发现,经过RL训练的智能体表现出更多的代码库探索行为和更丰富的自我验证方式——换句话说,模型学会的不只是「答对题」,还有更像人类工程师那种「先摸清情况再动手、动手后再检查」的工作习惯。

值得继续关注的地方

这项工作也暗示了一条值得留意的发展路径:如果「从代码本身规模化生产可验证任务」这条路走得通,那么下一步的竞争焦点很可能不再是谁家的基础模型参数更多,而是谁能把「探索代码库—写出规格—构造测试—用执行结果验证」这套流水线跑得更稳、更便宜。消融实验已经显示任务数量和性能之间存在正相关,这意味着谁能先把这套管线铺到更多代码库、更多语言生态上,谁就更可能在下一轮编码智能体的能力竞赛里占到先机。

同时也要留意反面风险:当验证器本身是由智能体自动构造出来的,如何持续审计这些自动生成的规格和测试用例是否真的可靠,会是这条路线能否长期规模化的关键前提。此外,这一思路也可能外溢到编码之外的领域:只要一个任务领域存在大量已完成的成品、又存在可以执行来核验对错的手段,同样的从成品反推规格、再用执行结果验证的方法论未必局限于软件工程本身。这提醒我们,评判一条RL训练路线是否有前途,首先要问的往往不是模型架构或参数规模,而是这个领域里到底有多少可以被自动、可靠验证的任务存量。