GAGAR 处理的是 code-agent RL 里一个很具体的问题：同一道任务生成 16 条 trajectories，几条都通过测试时，binary reward 会给它们相同的训练信号。论文增加一个 agentic grader，让它联合查看 repository、完整轨迹、patch 与 test output，再把正 advantage 从质量较差的 passing trajectory 转给更好的实现。
Q1. 为什么 executable tests 还不够？
测试能验证结果，却不会自动评价实现质量。
同一个 test suite 可能同时接受两种 patch：一种修复 root cause，只改必要文件；另一种增加特殊分支、修改无关模块，甚至写出只针对已知测试的 workaround。它们的 binary reward 都是 1。训练继续强化这两条 trajectory 时，policy 得不到“应该更像第一种实现”的信号。
GAGAR 要求 grader 比较同一任务的 passing candidates。这样的比较比独立打分多了一层上下文：grader 能看到不同 Agent 如何理解同一个 bug，哪些改动是必要的，哪些只是掩盖症状。failed trajectories 也会放进共享 workspace，帮助 grader 识别已经试过但无效的路线，不过失败样本不参加质量排序。
Q2. 它和 outcome reward、process reward、LLM judge 有什么区别？
GAGAR 的边界是：保留测试作为 correctness gate，再让一个能操作 repository 的 grader 比较多条完整 trajectory。
| 路线 | 输入 | 输出信号 | 与 GAGAR 的区别 |
|---|---|---|---|
| Binary outcome RL / GRPO | 最终 test result | pass / fail | 同一 group 内的所有 passing trajectories 得到相同 advantage。 |
| Process reward / step-level credit | 中间步骤或匹配后的 state | 逐步 reward 或 token credit | code-agent trajectories 很长且 repository state 各自分叉，跨 rollout 对齐中间状态很难。 |
| Static LLM-as-a-judge | prompt、answer 或 patch 摘要 | 分数或偏好 | GAGAR 的 grader 可以继续读代码、测试日志，并运行 targeted checks。 |
| Agent-as-a-Judge | task environment 与 candidate artifacts | agentic evaluation | GAGAR 把相似思想放进 online RL，并把排序转成 advantage redistribution。 |
论文的贡献主要在 credit assignment 组合方式，不是发明了新的 code benchmark，也不是用 grader 覆盖 executable tests。评测仍使用 DeepSWE v1.1 与 SWE-bench Pro。
Q3. 一组 trajectories 怎样变成新的训练信号？
流程包含 test filtering、agentic grading、tier-to-factor、redistribution 和 training 五步。
- 1 · VERIFY先运行任务测试。infrastructure-invalid trajectories 会被 mask；确认的 hack 被改成 reward 0。
- 2 · GRADEgrader 读取 task、repo、trajectories、patches 与 test outputs，只排序有效的 passing candidates。
- 3 · MAPT1 factor 为 1.0 或 0.9；T2 从 0.85 降至 0.4；T3 为 0.2。
- 4 · RESCALE对 passing advantages 乘 factor，再用共同的 λ 恢复原有 positive sum。
- 5 · TRAIN结果作为 sequence-level advantage，广播到该 trajectory 的 model-generated tokens。
grader 使用五项 1-5 分标准：Approach Suitability、Implementation Precision、Minimality of Changes、Unintended Side Effects 与 Codebase Consistency。初始加权分数为：
它随后根据严重问题划分 T1、T2、T3，并允许在 tier 内调整排序或保留 ties。论文要求负面判断引用具体 patch location、trajectory event 或 execution result。
一个明确标注的 constructed example
这个例子只解释公式，不是论文公开的真实训练样本
- 四条 rollout 中两条 pass、两条 fail，因此 `R̄=0.5`。两个 passes 的初始 advantage 都是 `+0.5`。
- 假设 grader 把第一个 patch 归为 T1，factor 为 `1.0`；第二个归为 T3，factor 为 `0.2`。
- 简单降权后，positive sum 从 `1.0` 变成 `0.6`。GAGAR 计算 `λ=1/0.6≈1.667`。
- 两个 passes 的新 advantage 分别为 `0.833` 与 `0.167`，总和仍为 `1.0`；两个 failures 仍为 `-0.5`。
论文没有发布真实 task、candidate patches、grader reasoning 或最终 tier assignment，所以无法从公开材料复原一个真实 GAGAR grading case。这里宁可保留这个缺口，也不把合理猜测写成事实。
正文公式和 bounded implementation 的差别
正文 Equation 2 的 rescaling factor 可以精确保持 positive-advantage sum。Appendix A.2 说明训练实现还会使用 λ_max=1.5：
当上面的 constructed example 需要 λ≈1.667 时，上限会触发。实现随后重新减去 group mean，因此 ranking 仍在，但 positive sum 和 failed-trajectory advantages 不再严格等于原值。论文附录明确承认这一点；解读时不能只引用正文的 exact conservation。
Q4. 实验怎样做，结果具体说明了什么？
最可靠的结论来自 MiMo-V2.6-Flash 的 code-only controlled run，而不是最终 mixed-task 模型与外部模型的横向比较。
主要对照从同一个 pre-RL SFT checkpoint 出发。训练 batch 为 128 prompts，每个 prompt 生成 16 条 rollouts。评测使用 DeepSWE v1.1 与 SWE-bench Pro，每题生成 3 个 samples，报告 avg@3。binary baseline 在 step 28 因性能快速下降而停止，因此共同训练区间只到 step 28。
| DeepSWE v1.1 · step 28 | Binary baseline | GAGAR | 差值 |
|---|---|---|---|
| Pass rate avg@3 | 50.2% | 62.2% | +12.0 displayed points |
| Mean main-agent turns | 132.3 | 111.6 | -15.6% |
| Mean total token length | 191.9k | 172.9k | -9.9% |
只降权、不重新分配的 ablation 在 step 28 得到 56.2%，低于完整方法的 62.2%；mean turns 为 143.5 对 111.6，tokens 为 236.0k 对 172.9k。这个对照支持“保持正负 credit 的量级有助于稳定训练”。
另一个结果是 30 个随机 DeepSWE tasks 的质量审计。Claude Opus 5 同时查看两种方法的匿名 trajectories、patches 与 test outcomes。在两组都训练到的最后一个 checkpoint 上，GAGAR 的 rubric-weighted quality 为 4.03，对照为 3.70；passing candidates 的平均 win rate 为 69.8%。样本量较小，而且 judge 仍是 LLM，不能把它等同于真实工程师的 code review。
Q5. 这套方法下一步最值得验证什么？
下一步应该把 grader 变成可重复评测的公开对象，并把质量收益连接到真实开发成本。
第一项需要公开匿名化的 task + repository snapshot + trajectories + patches + tests + grade bundle。这样才能检验不同 grader model、prompt 与 temperature 是否产生稳定排序，也能让人类 reviewer 测量 agreement。
第二项需要把 λ_max 单独做 ablation。当前论文把 exact sum-preserving method 与 bounded implementation 放在正文和附录两个位置，却没有报告上限触发频率。这个频率决定训练过程中有多少 groups 真正满足正文的守恒性质。
第三项是把“质量”落到开发者成本。比如让 reviewer 在不知道模型来源的情况下记录发现问题所需时间、requested changes 数量，以及 patch 是否能直接 merge。这样的指标比另一个 LLM 的 1-5 分更接近论文声称的 maintainability。
Q6. 最终应该怎样评价 GAGAR？
方法抓住了 code-agent RL 中真实存在的盲点，受控实验也有一致信号；公开证据尚不足以判断 grader 是否可靠地识别了好代码。
如果研究目标是 Claude Code、Codex 一类完整 software-agent harness，这篇值得读。它提供了一种把 repository-aware review 接进 RL 的方式。复现门槛目前很高；接下来的研究需要公开 grader 的输入和判据，并测量排序稳定性以及它与人工 code review 的一致程度。
主要来源：论文 v1 Sections 1-5、Appendix A、Figures 1-4、Tables 1-2。公开 artifact 检查日期：2026-10-06。未发现官方代码仓库、grader prompt、训练任务或逐组 grading records。
留言