Agent 不是缺更多候选，而是缺一个会看过程的裁判：LLM-as-a-Verifier

假设一个代码 Agent 接到「修复 CI」的任务。它一次跑出 8 条轨迹：有人改对了测试，却顺手删掉了边界检查；有人日志写得漂亮，但根本没跑测试；有人中途绕了很远，最后碰巧成功。你可以继续把候选从 8 条扩到 80 条，可这只是在增加待批改的卷子。真正决定收益的，是有没有一位能读过程、能分细微差异、还能给出稳定排序的裁判。

这正是 LLM-as-a-Verifier: A General-Purpose Verification Framework 要解决的问题。它并不主张「再训练一个万能裁判」，而是换了一种读取已有 LLM 判断能力的方式：不把模型压成一个离散标签，而是读出评分 token 的概率分布，形成连续分数；再沿着粒度、重复评估、评估维度三个轴扩展验证计算。

先把名字讲清楚：Judge 和 Verifier 不是一回事

行业里「LLM-as-a-Judge」是个大伞：让语言模型按 rubric 判断回答好坏，都可以这么叫。论文并没有否定这件事。它瞄准的是最常见的一种实现：模型最后从 1～5 分、A/B 或 pass/fail 中挑一个离散标签，然后我们把这个标签当作全部信息。

问题出在长轨迹选择。两条 agent 轨迹都得到「4 分」，不代表它们同样好：一条可能是 4 分概率 0.91，另一条可能是 4 分概率 0.31、3 分概率 0.30、5 分概率 0.28。离散读取把这两种犹豫程度都压扁了，候选越多，平局越多。论文的 Query 优化例子里，传统 1～5 Judge 在 100 个比较中出现了 88 次并列；改为连续读取后不再产生 tie，且选择正确数随粒度增加而提升。

一个好比喻是驾校考试。Judge 像考官在最后盖「通过 / 不通过」；Verifier 像行车记录仪加教练，除了总评，还知道你是在哪一个路口开始频繁急刹、哪一段其实已经稳定。前者非常有价值，但不足以反复指导一辆自动驾驶车如何纠偏。

核心机制：把离散标签还原成连续证据

对输入 x、候选轨迹 τ、第 c 个评价标准，模型会对评分 token 给出概率。论文把可选评分 token 映射成数值，再取期望：R(x,τ)=平均[ Σ p(v|x,c,τ)·φ(v) ]。这里的平均可以跨评分粒度 G、重复次数 K 与标准数 C；最后归一化到 0～1。比较两条轨迹时，使用 sigmoid(R_i−R_j) 转成 Bradley–Terry 偏好概率。

注意，它不是让模型凭空报一个小数，也不是让一个外部模型「想一想再打分」。连续性来自score token 的 logprob。官方实现会要求兼容后端返回 top logprobs，或对开源模型用受约束的 A～T 评分 token 读取分布；随后在 fine_grained_reward.py 中计算期望分。这个细节很重要：没有概率接口的闭源 API，不能直接复现原论文的核心读法。

三根验证计算的旋钮

论文的漂亮之处，在于没有把 verifier 包装成某个领域专用 reward model，而是给出三根可调旋钮：更细地读、重复地读、从更多角度读。它们分别解决分辨率、噪声和偏见。

这三项不要被误读成「永远开到最大」。它们都是测试时计算：更细的 token 集、更高的重复次数、更多 rubric 都要付推理费。一个成熟系统会先做消融：是分数粒度不够，还是采样方差太大，抑或 rubric 本身漏掉了关键失败模式？再把预算压到最值得的轴上。

为什么 Agent 更需要过程验证？

单轮 QA 的最终答案通常已包含主要证据；Agent 不一样。它的轨迹有工具调用、环境反馈、文件改动与中间假设。最终任务恰好成功，可能只是偶然；最终任务暂未成功，也可能离正确路径只有一步。只看 terminal reward，就像只看一场足球赛的最终比分，完全不知道哪支队伍在第 70 分钟后已经失去组织。

论文把轨迹截成多个 prefix，对每个 prefix 重复计算连续验证分，称为进度信号，并用 Value-Order Correlation（VOC）衡量它与真实步骤顺序的相关性。官方 progress 模块的提示词还明确要求模型相信已经观察到的工具输出，而不是 agent 自己的叙述；因此它不是把「我快做完了」当进度，而是看测试、命令结果和环境状态是否真的支持这句话。

论文在 Terminal 轨迹上报告：成功轨迹 VOC 为 0.848±0.012，失败轨迹仍为 0.769±0.016；在机器人 benchmark 上，验证器的 VOC 也高于对比 reward 模型。这里应当克制地解读：这些数字说明该框架在论文基准中给出了更单调、更贴近过程的信号，不等于它能在任何生产 Agent 上可靠预测「还剩几步完成」。真实环境里，长期停滞、环境延迟、隐藏约束都会让进度曲线失真。

候选不是越多越好：PPT 怎样用更少比较选更好答案？

有了连续偏好，仍会遇到一个朴素的成本问题：N 条候选两两比较需要 O(N²) 次。N=20 时已经是 190 对；在长轨迹 agent 上，每一对都是贵的。论文提出 Probabilistic Pivot Tournament（PPT）：先用一圈轻量比较挑出 k 个代表性「pivot」，再让其它候选只和 pivot 比，复杂度变成 O(Nk)。

这像招聘。全员两两面试既慢又不必要；先用一轮统一题挑出几位「标杆候选」，再让其他人和标杆对照，更容易用有限面试官时间做出排序。PPT 的巧思是 ring pass：所有候选都平等地轮到左右位置，避免「先展示的方案总被偏好」这类 position bias。

这里的「查询对数」来自论文 Appendix 的具体设置，不能直接搬到你的系统。更值得带走的是实验设计：先固定候选池，画出 quality vs. verifier cost 曲线，再选 k；不要只因为 O(Nk) 看起来漂亮，就默认 k=5 在任何任务上都够用。

从选答案到训练：验证器怎样成为稠密奖励

终局奖励的难处是稀疏：一条 50 步轨迹最终失败，训练只拿到一个低分，根本不知道第 7 步的工具选错和第 42 步的参数写错哪个更该修。Verifier 能为每个 prefix 给出连续值，于是相邻 prefix 的差值就能形成密集奖励：r_t=r_env+λ·ρ_t。它让策略在还没到终局时，就获得「这一动作把事情推向更好 / 更坏」的信号。

论文在 LIBERO 机器人任务的 DSRL 实验中报告，加入验证器的过程奖励后，达到相近表现所需样本约下降到原先的 1/1.8，最终成功率为 0.76 对 0.69；在 MATH 的 GRPO 设置中也报告了约 1.1× 的样本效率改善。它们值得关注，但同样不是「验证器 = 免费 RL 加速器」：论文也承认 RL 实验主要是单轮设置，多轮 agent rollout 的稳定性仍是未来工作。

三组数字给我们一个很健康的提醒：Verifier 通常把结果从 pass@1 往 oracle 推近，但并不会神奇地达到 oracle。前者受生成能力限制，后者是假设「候选池里已经存在正确轨迹」。所以系统优化顺序应是：先确认生成池有足够多样性和质量，再升级 verifier；若池里全是坏候选，再会看过程的裁判也选不出好答案。

面试题：Judge 为什么不够用，什么时候反而更合适？

落地清单：别先买一个 Verifier，先定义你要验证什么

1. 先拿到可验证的事实。代码任务保留 test、diff、命令输出；工具 Agent 记录 input/output、时间线与环境状态。没有过程证据，模型只能相信 agent 自述。
2. 写可区分的 rubric。不要只写「质量好不好」；像论文一样拆为规范是否满足、输出是否可信、错误是否处理。每一项都要有正反例与失败模式。
3. 做校准而非只看平均分。检查 verifier 高分轨迹的真实成功率、不同长度和不同任务上的偏差、是否偏好啰嗦或格式漂亮的回答。
4. 从 rerank 开始。先在固定候选池上比较 pass@1、oracle gap、成本与延迟；确认它能选对，再尝试过程监控或接入 RL。
5. 保留反证与回放。每次选择记录 rubric、版本、logprob 摘要和被淘汰候选；否则出了问题只能得到一句「模型觉得这条更好」。

论文的官方仓库已经提供 Python 包和 TurboAgent 代理等实现入口，见 llm-as-a-verifier/llm-as-a-verifier。但落地前应先确认后端是否支持所需 logprobs、哪些数据会离开你的执行环境，以及 rubric 是否会泄漏业务规则。开源包解决了调用和计算问题，解决不了「你到底该相信什么」这个产品问题。

边界：最好的裁判也会误判

作者在论文里列出了几条很实在的限制：不是所有前沿 API 都开放 score token 的 logprob；criteria 分解依然需要人工；固定 K 次重复并不一定比按不确定性自适应分配算力更划算；RL 部分还没有覆盖完整的多轮 agent rollout。除此之外，生产中还要警惕 reward hacking：Agent 学会写出更像「正在进展」的日志，却没有真的推进环境状态。

因此，我会把它定位成一套验证计算框架，不是一个真相机。可执行测试、外部事实、权限边界这些确定性证据应当优先；Verifier 的长处是把难以完全规则化的过程判断，变成更细、更稳、可被系统消费的信号。

Agent 的上限不只由「一次能想出多少条路」决定，也由「能否分辨哪条路真的在往前走」决定。生成负责扩张搜索空间；验证负责把搜索变成决策。

参考资料

1. LLM-as-a-Verifier: A General-Purpose Verification Framework，2026。本文的主要来源；连续验证、PPT、进度信号、实验数据与局限均以该论文为准。
2. 论文 HTML 正文与附录。用于核对 G/K/C 消融、PPT 的查询成本与基准设置。
3. 官方实现仓库。包含 fine-grained reward、pivot tournament 与 progress tracker 的实现入口。
4. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena，2023。理解 LLM-as-a-Judge 作为通用评估范式的早期代表工作。