GAGAR 处理的是代码 Agent 强化学习里的一个具体问题。这里的代码 Agent 是能读取代码仓库、修改文件并运行工具的模型系统。同一道任务让它尝试 16 次，其中若有多次都通过测试，普通的 0/1 奖励会给这些成功尝试完全相同的训练权重。论文增加一个能主动检查代码的判分 Agent，让它同时查看代码仓库、完整执行过程、最终代码改动与测试输出，再把一部分训练权重从质量较差的成功实现转给更好的实现。
Q1. 为什么可执行测试还不够？
测试能验证结果，却不会自动评价实现质量。
同一套测试可能同时接受两份代码：一份修复了根本原因，只改必要文件；另一份增加特殊分支、修改无关模块，甚至只对已知测试生效。它们的二元奖励都是 1。训练继续强化这两条轨迹时，策略模型得不到“应该更像第一份实现”的信号。
GAGAR 要求 grader（判分 Agent） 比较同一任务中已经通过测试的候选实现。这样的比较比逐份独立打分多了一层上下文：判分 Agent 能看到不同 Agent 如何理解同一个缺陷，哪些改动是必要的，哪些只是掩盖症状。失败轨迹也会放进同一个工作区，帮助它识别已经试过但无效的路线，不过失败样本不参加质量排序。
Q2. 它和结果奖励、过程奖励、大语言模型判分有什么区别？
GAGAR 保留测试作为正确性门槛，再让一个能读取并运行代码仓库的判分 Agent 比较多条完整轨迹。
| 路线 | 输入 | 输出信号 | 与 GAGAR 的区别 |
|---|---|---|---|
| 二元结果奖励 / GRPO | 最终测试结果 | 通过 / 失败 | 同一尝试组内的所有成功轨迹得到相同 advantage。 |
| 过程奖励 / 逐步归因 | 中间步骤或已经对齐的中间状态 | 每一步或每个 token 的训练权重 | 代码 Agent 的轨迹很长，各次尝试又会把仓库改成不同状态，很难逐步对齐。 |
| 大语言模型（LLM）静态判分 | 提示词、回答或代码改动摘要 | 分数或偏好 | GAGAR 的判分 Agent 可以继续读取代码和测试日志，还能运行有针对性的检查。 |
| 让 Agent 担任判分者（Agent-as-a-Judge） | 任务环境与候选产物 | 由 Agent 主动调查后给出评价 | GAGAR 把相似思想用于在线强化学习，再把排序转成 advantage 的重新分配。 |
论文的贡献主要在 credit assignment（训练权重如何归给不同样本），没有发明新的代码评测基准（benchmark），也没有用判分 Agent 取代可执行测试。评测仍使用 DeepSWE v1.1 与 SWE-bench Pro。
Q3. 一组执行轨迹怎样变成新的训练信号？
流程分成测试筛选、Agent 判分、等级映射、权重重分配和模型训练五步。
- 1 · 验证先运行任务测试。因基础设施故障而无效的轨迹不参与训练；确认利用测试漏洞的实现，其奖励改为 0。
- 2 · 判分判分 Agent 读取任务、仓库、执行轨迹、代码改动与测试输出，只排序有效且通过测试的候选实现。
- 3 · 映射T1 的质量系数为 1.0 或 0.9；T2 从 0.85 降至 0.4；T3 为 0.2。
- 4 · 重缩放成功样本的正 advantage 先乘质量系数，再统一乘 λ，把正权重总量恢复到原来的大小。
- 5 · 训练每条轨迹得到一个序列级 advantage，该权重应用到这条轨迹中由模型生成的全部 token。
判分 Agent 使用五项 1-5 分标准：方案是否合理（Approach Suitability）、实现是否准确（Implementation Precision）、改动是否精简（Minimality of Changes）、是否引入副作用（Unintended Side Effects），以及是否符合现有代码风格（Codebase Consistency）。初始加权分数为：
它随后根据严重问题划分 T1、T2、T3 三档，并允许在同一档内调整排序或并列。论文要求负面判断引用具体的代码位置、轨迹事件或执行结果。
一个明确标注的公式构造例子
这个例子只解释公式，不是论文公开的真实训练样本
- 四次尝试中两次通过、两次失败，因此 `R̄=0.5`。两个成功样本的初始 advantage 都是 `+0.5`。
- 假设判分 Agent 把第一份代码归为 T1，质量系数为 `1.0`；第二份归为 T3，质量系数为 `0.2`。
- 简单降权后，正 advantage 总量从 `1.0` 变成 `0.6`。GAGAR 计算 `λ=1/0.6≈1.667`。
- 两个成功样本的新 advantage 分别为 `0.833` 与 `0.167`，总和仍为 `1.0`；两个失败样本仍为 `-0.5`。
论文没有发布真实任务、候选代码改动、判分过程或最终档位，所以无法从公开材料复原一个真实的 GAGAR 判分案例。这里保留这个证据缺口，不用合理猜测补齐未公开内容。
正文公式和带上限实现的差别
正文公式 2 的重缩放系数可以精确保持正 advantage 总量。附录 A.2 说明训练实现还会使用 λ_max=1.5：
上面的构造例需要 λ≈1.667，因此会触发上限。实现随后重新减去组内平均值，所以质量排序仍然保留，但正权重总量和失败轨迹的 advantage 不再严格等于原值。论文附录明确承认这一点；解读时不能只引用正文的“精确守恒”。
Q4. 实验怎样做，结果具体说明了什么？
最可靠的结论来自 MiMo-V2.6-Flash 上只训练代码任务的受控对照，不是最终混合任务模型与外部模型的横向比较。
主要对照从同一个强化学习前的监督微调（SFT）模型存档出发。每个训练批次包含 128 道任务，每题生成 16 次完整尝试。评测使用 DeepSWE v1.1 与 SWE-bench Pro，每题独立生成 3 次；avg@3 指这三次结果的平均通过率。只用二元奖励的基线在第 28 步因性能快速下降而停止，因此公平的共同训练区间只到第 28 步。
| DeepSWE v1.1 · 第 28 步 | 二元奖励基线 | GAGAR | 差值 |
|---|---|---|---|
| 三次采样平均通过率 `avg@3` | 50.2% | 62.2% | 图中相差 12.0 个百分点 |
| 主 Agent 平均交互轮数 | 132.3 | 111.6 | -15.6% |
| 平均总 token 数 | 191.9k | 172.9k | -9.9% |
只降低差样本权重、不重新分配的消融实验在第 28 步得到 56.2%，低于完整方法的 62.2%；平均交互轮数为 143.5 对 111.6，总 token 数为 236.0k 对 172.9k。这个对照支持“保持正负训练信号的量级有助于稳定训练”。
另一个结果是对 30 个随机 DeepSWE 任务进行质量审计。Claude Opus 5 同时查看两种方法匿名后的执行轨迹、代码改动与测试结果。在两组都训练到的最后一个模型存档上，GAGAR 按评分表加权后的质量分为 4.03，对照为 3.70；成功候选的平均胜率为 69.8%。样本量较小，而且判分者仍是大语言模型（LLM），不能把它等同于真实工程师的代码审查。
Q5. 这套方法下一步最值得验证什么？
下一步应该让判分 Agent 本身可以被重复评测，并把质量收益连接到真实开发成本。
第一项需要公开匿名化的“任务、仓库快照、执行轨迹、代码改动、测试和评分”数据包。这样才能检验不同判分模型、提示词和生成温度是否产生稳定排序，也能让人类审查者测量彼此的一致程度。
第二项需要单独做 λ_max 的消融实验。当前论文把精确保持正权重总量的方法和带上限的实现分别写在正文、附录，却没有报告上限触发频率。这个频率决定训练过程中有多少尝试组真正满足正文的守恒性质。
第三项是把“质量”落到开发者成本。比如让审查者在不知道模型来源的情况下记录发现问题所需时间、要求修改的次数，以及代码能否直接合并。这样的指标比另一个大语言模型给出的 1-5 分更接近论文声称的可维护性。
Q6. 最终应该怎样评价 GAGAR？
方法抓住了代码 Agent 强化学习中真实存在的盲点，受控实验也给出一致信号；公开证据尚不足以判断判分 Agent 能否可靠识别好代码。
如果研究目标是 Claude Code、Codex 一类完整的软件 Agent 运行框架（harness），这篇值得读。它提供了一种把“能读取整个代码仓库的审查”接进强化学习的方法。复现门槛目前很高；接下来的研究需要公开判分 Agent 的输入和判据，并测量排序稳定性以及它与人工代码审查的一致程度。
主要来源：论文 v1 第 1-5 节、附录 A、图 1-4、表 1-2。公开材料检查日期：2026-10-06。未发现官方代码仓库、判分提示词、训练任务或逐组评分记录。
留言