10 月 9 日提交到 arXiv 的 SWE-Critix（编号 2610.13356），处理的是一个很具体的空缺：编码智能体被部署去做端到端软件工程任务时，往往没有可以直接拿来判成败的评测器，而它的轨迹动辄包含数百轮与代码仓库、外部工具的迭代交互。
已有的两条路都不够用。直接用通用大模型判，缺少专门训练；训练专用 critic，则大多只产出一个标量奖励，对「长程轨迹到底哪里错了」这件事探索得很有限。SWE-Critix 给出的目标是能判、并且能解释。
三段后训练流水线
流水线分三步。头一步用教师模型对同一道题的成功轨迹与失败轨迹做对比分析，生成少量带推理链的监督数据。第二步改用不含推理链的轨迹做监督微调，让模型直接学会判定并说明理由。第三步在 SFT 基础上做强化学习，继续优化判定与自然语言解释的准确性。
全程训练的是 30B 量级的一系列验证器模型，轨迹来自 CodeForge-Preview，留出测试集有 4.3 万余条长轨迹。关键数字是三个：基线 Qwen3-30B-A3B 推理模型分类准确率 57%，SFT 后 66%，RL 后 78%。三个数出自同一份留出测试集，可以直接横向比。
输出形态是验证器最有意思的设计：它给的不只是一个标签，而是一段解释判断依据的自然语言分析。论文强调「会解释」和只会打标分数是两回事——只有解释得出来，人才能复核。模型、数据集与训练代码均已开源。
78% 该被当成什么来用
这个数字最直接的含义是：五次里仍会有一次判错。论文同时提到，对失败轨迹的识别比成功轨迹更弱——而漏判往往正是团队最需要它说话的时候。所以更稳妥的用法是当裁判助理而不是主裁判：先筛出可疑轨迹，再让人看结论，把它的解释当成排查线索而不是证据本身。能跑测试的任务，测试优先；没有测试可跑的，才轮到它上场。
还要提醒一句，这些数字出自论文自己的留出测试集，评测依赖裁判模型，长答案对比里的裁判偏置始终是个变量。另外 78% 是分类准确率，不等于「说对了原因」的概率，后者论文没有单独给分。
更大的行业含义
把这篇论文放回评测链条里看，它补的是一块长期空着的地基：在没有现成 oracle 的任务上，成功标准本身需要被学出来。
这一点对正在自建智能体评测体系的团队尤其现实。代码类任务还能靠测试兜底，但很多智能体任务——客服对话、运维排查、研究助理——根本没有可自动判定的成功标准。团队要么退回到人工抽检，要么干脆以「没报错」为成功，而后者恰恰是上线后静默质量回归最难被发现的原因。
训练式验证器给出的思路是：既然判分标准写不出来，就从历史成功与失败轨迹的对比里把它学出来，并且要求学出来的东西自带理由。它离「可信」还有距离——78% 不是 100%，失败轨迹识别更弱——但把这条路走通，评测就有机会从「靠人抽检」变成「可回归、可自动跑、可解释」。
对多数团队来说，短期内更实用的做法或许是：先把它当排序器用，按可疑度给轨迹排队，人只看排在前面的那部分。这样即便准确率停在 78%，也能把最贵的人工注意力放在最可能有问题的样本上。