奖励、验证器与长期信用分配

“拿到满分”可能完全没有完成任务

代码 Agent 可以修复 bug，也可能删掉测试、伪造 stdout 或改动评分器读取的文件。浏览器 Agent 可以真正完成表单，也可能只制造看起来像成功的截图。奖励是观测到的代理目标；只有它与用户意图足够一致，持续优化才有意义。

课程分析：先画信任边界。策略能修改的工作目录、训练时可见测试、最终隐藏检查器和评分日志不应含混共享权限。测试通过是一个证据，而不是绝对正确性的定义。对环境、测试与 grader 的审计和对模型的审计同样重要。

三个名词，三个层次

Verifier 检查明确断言，例如测试是否通过、形式化证明是否被接受。Grader 可以按 rubric 给出多个维度的分数，可能是规则、人工或模型。Reward 则是送进优化器的数值，可由多个检查结果聚合。三者在代码里可以合并部署，概念上仍应分开。

真实源码：修复与回归要一起检查

读取 SWE-bench/SWE-bench 固定版本 02e7a74ffd0b707aab73d203fe87bdc7c76afc8e 的 swebench/harness/grading.py。get_eval_report 接收 TestSpec、包含 patch 的 prediction 和测试日志；get_resolution_status 根据 FAIL_TO_PASS 与 PASS_TO_PASS 两组测试决定状态。完全解决要求修复目标测试且保持原有通过测试。固定源码

该版本还记录诸如 patch 是否存在、是否成功应用、是否可能是基础设施错误等字段。源码观察：无法解析测试日志时不会直接视为通过；infra_failure 是诊断字段，resolved 仍保持 false。这个细节提醒我们“评测计分”与“训练数据剔除规则”应独立定义，不能擅自删除困难失败来提高分数。字段依据

课程分析：把其思想迁移到训练：奖励记录保留每项测试证据，而不是只保存 0/1。否则 reward 突变时无法区分修复率提升、回归测试被绕过、镜像变化或日志解析器故障。

稀疏结果奖励与过程奖励

对长轨迹 $\tau=(s_0,a_0,\ldots,s_T)$，如果只在终点得到 $R$，策略梯度使用类似：

晚到的结果要影响许多早期动作，因此方差与归因难度上升。降低方差的 baseline 不应依赖当前被评估动作，否则可能引入偏差；实际的组内 baseline 也有自身有限样本效应。把同一个终态优势广播给所有动作是一种可执行近似，不是解释每步贡献的答案。结果优势实现

过程奖励希望提供更密集反馈，但错误的局部指标可以鼓励反复调用工具、打印貌似正确的计划或生成冗长证明。数学过程监督论文提供特定任务中对过程/结果奖励的比较，并公开逐步标注数据；它没有证明任意网页或软件环境中的每一步都能可靠判分。论文边界

数学旁注：势函数塑形可写为 $r'_t=r_t+\gamma\Phi(s_{t+1})-\Phi(s_t)$。在固定 MDP、匹配折扣以及适当终止势函数条件下，沿轨迹求和会望远镜式消去中间项，因此可保留最优策略的排序。随意给“每次搜索 +0.1”没有这种保证；部分可观测状态、可变 grader 与不正确终止处理会破坏前提。这是课程数学推导，不是某个模型团队已采用的公开事实。

多 Grader 聚合是目标设计

一种可审计的课程方案是：先用协议有效、环境完整、关键测试等硬门槛，再对质量、成本、覆盖度等软指标加权：

这只是教学设计，系数没有通用最优值。若可通过少做任务节省成本，就可能“学会立即退出”；若 partial credit 过高，模型会停在容易拿分的局部目标。先检查每个极端策略的奖励：空操作、重复调用、永不提交、修改测试、正确但昂贵的方案。

Kimi K2 报告将可验证反馈与 self-critique rubric 纳入其后训练路线，说明开放式任务需要不同反馈来源；这属于报告公开事实。具体生产 grader 的完整提示、训练语料和长期校准过程并不由这一概括自动公开，不能照此宣称已完整复现。报告案例

新案例：把 Grader 算力也纳入 Scaling

MiMo-V2.6-Flash-RL 模型卡将 RL 算力、环境多样性和 grader 算力共同扩展，描述在通过轨迹内进行质量排序，并以环境加固、对抗筛选和 verifier 交叉检查约束奖励投机。查阅日的新案例

课程分析：这使 grader 从末端廉价函数变成关键算力消费者。若每条候选都要多轮比较，评分延迟会形成 rollout 长尾；如果候选数为 $G$ 而做所有两两比较，比较数为 $G(G-1)/2$。可采用采样配对、锦标赛或 listwise 评价降低成本，但排序稳定性需单独验证。这些替代方案是本站工程分析，不是宣称 MiMo 采用了其中某一项。

Judge 的误判如何测量

课程分析：准备独立、分层抽样的人工或可信执行审计集，覆盖正确、错误、边界与对抗样本。计算 false positive、false negative，并按任务类型、语言、长度和模型来源分桶。对于 pairwise judge，交换答案顺序可测位置偏差；隐藏模型身份可减少品牌偏差；长度匹配可以揭示表面文风偏好。

将策略输出交给模型 grader 时，输出文本应作为待评估数据，避免其内容改变评分指令。这里的关键不是一句“请忽略提示注入”，而是独立规则核验、格式约束、权限隔离与审计样本共同构成证据。

多个 grader 若共享训练数据或提示模板，错误可能强相关。多数投票只能降低部分独立噪声，不能抵消共同偏差。保留各项原始分数和分歧，不要只保存加权总分。grader 更新后，用固定轨迹重新评分，分离“策略变了”与“尺子变了”。

可运行实验：检查奖励信任边界

python3 -m labs.run --experiment agent --seed 7

课程环境用有限工具动作解决加/减任务，独立逻辑 verifier 根据终态判断成功。环境和 verifier 在同一个 Python 进程内，它提供逻辑边界教学，并没有 OS 沙箱隔离。预期策略更新影响成功率；查看失败轨迹时应确认是没读数据、选错运算还是未正确提交。

与生产软件环境相比，这里没有隐藏测试泄漏、恶意文件修改或非确定依赖。将它扩展到真实代码执行前，应设计独立只读 grader 与资源隔离；这也是本章工程任务，而非实验已具备的能力。

故障树与工程任务

奖励均值上涨但独立成功率不涨，先检查 grader 误判与任务采样；奖励方差突然归零，检查验证服务故障、解析失败默认值与任务变容易；平均回合数暴涨，检查 dense reward 是否奖励无效动作；总分稳定但回归率上升，检查加权聚合是否掩盖关键约束。

工程任务：为代码修复设计 12 个 grader 对抗用例，至少覆盖修改测试、伪造日志、超时、只修一个测试引发回归、空 patch、依赖安装失败。对每种情况规定终止状态、奖励、是否入训练、评测如何记分。最后给 grader 建立版本回归测试，并报告一组假阳性/假阴性，而不是只提交一个奖励函数。