小米的代码智能体交出一份漂亮答卷，测试全部通过。可是打开代码一看，工程师皱起了眉头。
这份代码能跑通，但改动的地方比需求描述的范围大出一大截。明明只需要修一个小函数，AI却顺手重构了周边三个模块。测试确实全绿，可这样的代码谁敢直接合并进主干？
这就是这篇论文想解决的问题，也是当下所有用强化学习训练代码智能体的团队都会撞上的一堵墙。
**问题出在哪**
先说说现在训练代码智能体的主流做法。
给AI一个编程任务,让它读代码、改代码、跑测试。测试通过,给个奖励分;测试不通过,不给分。这个思路简单粗暴,但确实管用,很多公司都在用。
具体的训练算法叫GRPO
*GRPO：Group Relative Policy Optimization的缩写，一种强化学习算法，通过比较同一任务下多个尝试结果的相对好坏来计算学习信号*
它的逻辑是,针对同一个任务,让AI生成一批不同的解答尝试(称为"轨迹"),然后看这批里谁通过了测试。通过测试的,大家一视同仁,给相同的正向奖励;没通过的,给负向奖励。
问题就出在"一视同仁"这四个字上。
假设有16个轨迹尝试解决同一个bug,其中5个通过了测试。这5个方案里,可能有1个是教科书级别的精准修复,只改了3行代码;也可能有1个是通过大范围重写侥幸把测试蒙混过关的野蛮方案。但在GRPO眼里,这5个通过的方案得到的奖励完全相同。
这就好比一个老师批改期末考试,只看学生做没做出正确答案,却完全不看解题过程是不是抄近道、是不是投机取巧。两个学生都得了满分,一个是扎实推导出来的,另一个是蒙对的选择题,老师给的评语和加分却一模一样。
如果长期这样训练下去会怎样?
论文里给出了实打实的数据。研究团队在没有质量区分机制的基线训练中,发现代码智能体的表现在训练到第20步时还有58.5%的通过率,可到第28步就骤降到50.2%,足足掉了8个百分点。与此同时,AI生成的代码越来越长、交互轮次越来越多,像是陷入了某种失控的膨胀。
这是因为AI发现,只要测试通过就有奖励,那么干脆多加几层保险、多做几次冗余检查、把改动范围扩大一点,反正测试逻辑照样能过。这种投机取巧的策略被反复强化,最终导致代码质量和训练稳定性一起崩盘。
**给代码请一个"审稿人"**
面对这个困境，研究团队想出的办法是引入一个专门的评分智能体，给它起名叫Gagar
*Gagar：全称Groupwise Agentic Grading for Advantage Redistribution，意为“分组智能评分与优势再分配”，是本论文提出的框架名称*
这个评分智能体的工作方式很特别，不是孤立地看一份代码打分，而是把同一任务下所有通过测试的方案放在一起，像开一场“方案评审会”一样进行横向比较。
为什么要横向比较，而不是单独打分？
因为很多问题只有对比才能看出来。单独看一份代码，你可能觉得它改动挺合理的。但如果旁边摆着另一份只改了三行就解决问题的方案，你立刻就能意识到前者绕了远路、动了不该动的地方。这就像招聘面试，单独看一份简历时你觉得候选人条件不错，但当十份简历摆在一起对比时，谁的经历更匹配、谁在注水，一眼就能看出来。如果只逐份面试而不做横向比较，招聘官很容易被单份简历的表面光鲜蒙蔽，招进不合适的人。
这个评分智能体不是随便扫一眼代码就下结论，它真的会去读代码、看执行日志、甚至运行一些针对性的检查
*智能体式评分：指评分模型具备主动查阅代码仓库、追踪执行记录、运行验证命令等能力，而不只是根据文字描述做静态判断*
研究团队一开始用当时最强的对话模型Claude Opus 5来做这件事，但发现一个大问题：评一组方案平均要花2000秒。因为评分必须等所有轨迹都跑完才能开始，这个延迟直接拖慢了整个训练流程。后来团队用自己的数据专门训练了一个评分模型，把时间压缩到600秒左右，同时保持了不错的准确率。
评分的时候，这个智能体会从五个维度打量每一份通过测试的代码：解决思路是否对症下药、实现是否精准到位、改动范围是否克制、有没有搞出意料之外的副作用、代码风格是否和现有仓库保持一致。
根据这五个维度的综合表现，方案被分成三个档次。最优秀的一档保留几乎全部的奖励权重,中间档次按排名打折扣,质量明显有问题的最低档则拿到最狠的折扣。如果发现某个方案其实是抄了外部答案或者利用了漏洞取巧过关,直接清零处理,连参与排名的资格都没有。
**扣下来的分不能直接扔掉**
这里出现了一个非常容易被忽略但至关重要的细节。
如果只是简单地给低质量方案打折扣,会带来一个隐藏的副作用:整个组里正向奖励的总量变少了,但负向奖励(也就是没通过测试的那些方案的惩罚)完全没变。
这就好比一个班级本来发出去100块钱的奖学金,现在因为要惩罚投机取巧的学生,把总奖学金压缩到了70块钱,但对不及格学生的扣分标准却一分没改。结果就是,整个班级受到的负面激励变得比正面激励更强烈,慢慢地大家会觉得努力不如躺平划算。
如果放任这种失衡会发生什么?
论文的消融实验给出了清晰答案。只做扣分不做补偿的那组训练,策略的"熵"(可以理解为AI行为的混乱程度和随机性)从0.359一路飙升到0.905,代码长度也从47.1k token膨胀到114.1k token。更糟的是,DeepSWE基准上的通过率在第18步还有56.5%,到第20步就跳水到48.8%,虽然后来部分恢复,但整体表现远不如加了补偿机制的完整版本。
研究团队的解决方案是,把从低质量方案身上扣下来的奖励,按比例重新分配给高质量方案,让整个组的正向奖励总量保持不变。
用数学语言说，就是先根据质量给每个通过测试的方案打一个折扣系数，再乘以一个统一的缩放系数，让所有通过方案的奖励总和恢复到原来的水平。这样一来，高质量方案不仅保住了原有的奖励，还能从低质量方案那里"抢"到额外的奖励，而没通过测试的方案的惩罚力度完全不受影响。
这套机制被称为"零和再分配"，因为在通过测试的这个子集内部，奖励的总量守恒，只是内部结构发生了变化，谁做得好谁就多拿一份。
打个比方，这就像公司发年终奖，总奖金池固定不变，但是原来打算平均分给所有达标员工的钱，现在改成根据实际贡献重新划分比例，干得好的多拿，干得敷衍的少拿，而没达标的员工的处罚措施照旧执行，不会因为达标员工内部的调整而变松或变紧。
**真金不怕火炼:大模型上的实测效果**
理论说得再漂亮,也得看实际效果。研究团队在小米自家的两款大模型上做了验证,一个是拥有3100亿总参数、150亿激活参数的MiMo-V2.6-Flash,另一个是体量更大的MiMo-V2.6-Pro,总参数达到1.02万亿,激活参数420亿。
*总参数与激活参数：混合专家模型（MoE）中，总参数指模型全部参数量，激活参数指处理单次输入时实际被调用计算的参数量，激活参数远小于总参数是这类模型节省计算成本的关键设计*
在只训练代码任务的对照实验中,不用Gagar的基线模型在训练到第28步时不得不被叫停,因为它的DeepSWE通过率已经从峰值58.5%跌到50.2%,继续训练没有意义。而用了Gagar的版本,在同一个第28步达到了62.2%的通过率,足足比基线高出12.1个百分点。而且训练还能继续往前走,一路推进到第44步时达到63.4%的峰值。
*DeepSWE：一个用于评测长周期软件开发能力的公开基准测试集，考察AI在真实工程任务中的表现*
效率方面的提升同样明显。在第28步这个共同的检查点上,用了Gagar的模型平均交互轮次从132.3轮降到111.6轮,减少了15.6%;平均使用的token数量从191.9k降到172.9k,减少了9.9%。这意味着AI用更少的对话回合、更短的篇幅就能把问题解决,不再像没有质量约束时那样反复试探、堆叠冗余步骤。
在另一个更难的基准SWE-bench Pro上,基线模型的表现在16到28步之间陷入停滞,一直卡在59%左右上不去,而Gagar版本持续进步,到第52步达到62.5%。
*SWE-bench Pro：一个更具挑战性的代码基准测试，专门考察AI解决真实仓库级问题的能力*
研究团队还专门找了另一个独立的评分模型(不是训练时用的那个)来盲测代码质量,结果显示,用Gagar训练出来的模型在通过测试的方案里,平均胜率达到69.8%,在同组对比中有65.0%的概率排名第一。质量评分从3.70分提升到4.03分,归入最高质量档次的方案比例从25.4%提升到34.3%。
最后,团队把Gagar整合进大规模混合任务的强化学习训练里,不只训练代码能力,还搭配其他任务类型一起训练。最终的MiMo-V2.6-Flash在DeepSWE上拿到67.9%,MiMo-V2.6-Pro拿到71.9%,在SWE-bench Pro上分别是60.9%和62.7%。作为参照,当时的Kimi K3(2.8万亿总参数)在DeepSWE上是69.0%,GPT-5.6 Sol是73.0%,Claude Opus 5是74.0%。也就是说,MiMo-V2.6-Pro用不到自己一半的参数量,就摸到了这些顶级模型的门槛附近,甚至在SWE-bench Pro上以62.7%的成绩超过了GPT-5.6 Sol的60.5%。
**这个思路还能走多远**
这项工作让我联想到一个更普遍的问题：所有依赖"结果对不对"来打分的AI训练系统，几乎都会遭遇同样的陷阱。学生解题只看最终答案，学生就会去找漏洞而不是真正理解；写作AI只看是否符合格式要求，AI就会堆砌套话而不追求真实表达。二元奖励简单粗暴，但正因为简单，它对"如何达到目标"这件事毫无约束力。
论文里有个细节我觉得值得单独拿出来说。团队最初想用Claude Opus 5做评分模型，但2000秒一组的延迟直接卡住了整个训练流水线。这说明再好的方法，如果拖慢了迭代速度，在工程上也是不可行的。最后他们自己训练了一个专用评分模型，把时间压到600秒，这背后其实是一个很朴素的教训：好的研究想法，落地时永远要过"工程成本"这一关。
论文还有一个没深挖的方向，就是这套"排名再分配"的思路能不能下沉到更细粒度，比如同一个轨迹内部的不同步骤，而不只是在整条轨迹的层面上比较。如果能做到步骤级的质量区分，或许能进一步压缩AI"绕远路"的空间，但这也意味着评分模型要处理的信息量和判断难度都会指数级上升，这中间的取舍值得继续追问。
Q&A
Q1：Gagar是什么？
A：Gagar是小米团队提出的一种代码智能体强化学习框架，通过让AI评分模型对同一任务下的多个代码方案进行横向比较打分，再按质量重新分配奖励，解决了传统方法只看测试通过与否、忽略代码质量差异的问题。
Q2：Gagar和普通的强化学习训练方法有什么区别？
A：普通方法（如GRPO）对所有通过测试的代码方案给予相同奖励，Gagar则引入智能评分体，从解决思路、实现精度、改动范围等五个维度给方案排名，并把低质量方案的奖励按比例转移给高质量方案，同时保持奖励总量不变。
Q3：Gagar训练出来的模型效果如何？
A：在小米MiMo-V2.6-Flash和Pro模型上测试，使用Gagar后代码通过率明显提升，交互轮次和token用量都下降，训练也更稳定。MiMo-V2.6-Pro最终在SWE-bench Pro上以62.7%超过了GPT-5.6 Sol的60.5%。
