同一个模型既当选手又当裁判：VeriHarness 用"分歧裁决 + 共识挑战"把长程任务平均分拉高 6 个点

你有没有遇到过这种尴尬：让智能体跑一个复杂任务——比如写一份财务分析报告、改一个多文件代码仓库——跑了十次，得到十份结果，然后你盯着这十份东西发愁：到底哪份是对的？

投票吧，十份里有七份写着同一个错误数字；让模型自己当裁判打分吧，它打的分跟抽签差不多。更扎心的是，你手头已经是最强的模型了，没有更强的"老师"可以请来批改作业。

Google Cloud AI Research 和剑桥大学合作的这篇 VeriHarness（arXiv: 2610.00972），就是冲着这个痛点来的。它给出的答案有点反直觉：不用更强的模型，就把生成答案的那个模型本身，塞进一个带工具、带工作区、带技能库的"验证外壳"里，让它像审计员一样去查自己的作业。结果在五个长程工作区基准上，仅"选对答案"就平均涨 4 个多点，再加上证据驱动的修订，Gemini 3.5 Flash 涨 6.2 分，Claude Opus 4.8 涨 6.4 分。

核心摘要

• 痛点：长程智能体任务（报告、表格、补丁）没有单元测试可用，多数投票和 LLM 打分都依赖"模型已经相信的东西"，而不是环境里的真实证据。
• 核心发现：十次采样里，全体一致的答案有 34% 是错的；而有分歧的答案里，74% 的分歧中藏着正确选项，但投票会把它扔掉。
• 方案：VeriHarness 把验证拆成两路——分歧裁决器（Disagreement Resolver）对有争议的声明查证据，共识挑战器（Consensus Challenger）专门挑全体一致的声明的毛病，最后由一个全新上下文做裁决和修订。
• 我的判断：这不是又一篇"加个 verifier 涨点"的论文，它把验证从"打分"变成了"取证"，而且验证技能还能从失败反馈里自我进化。配套的约 26,000 条 rollout 数据池（成本超 10 万美元）也开源了，这个数据集本身就很值钱。

论文信息

• 标题：VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks
• 作者：Caiqi Zhang, Rujun Han, Zifeng Wang, Zoey CuiZhu, Nigel Collier, Tomas Pfister, Chen-Yu Lee
• 机构：Google Cloud AI Research；University of Cambridge（Nigel Collier）
• 链接：https://arxiv.org/abs/2610.00972 （2026 年 10 月 1 日提交，项目主页 veriharness.com）

🎯 问题动机：为什么投票和打分都不够用

先交代一下设定。这篇论文研究的是一个很苛刻但很现实的场景：测试时验证，且没有更强的裁判。生成器和验证器是同一个模型、同一套工具，验证器看不到标准答案，也看不到评分细则（rubric）。

为什么这个设定重要？因为在真实的前沿应用里，生成器往往已经是最强模型了——你找不到更强的模型来监督它。而且固定基座模型还有个好处：任何提升都只能来自模型自己的 rollout 和环境，不会混入更强模型的知识。

在这个设定下，验证器手里其实只有两张牌：一是候选 rollout 池（同一个任务跑 N 次得到的结果），二是任务环境（源文件、数据、约束）。

现有的方法基本只用了第一张牌。多数投票（self-consistency 那一系）把出现次数最多的答案当正确的；LLM-as-a-judge 让模型读一遍 rollout 然后打分。说实话，这两类方法有个共同的软肋：它们依赖的都是模型"已经相信"的东西。模型要是系统性地把草稿版报告当成了最终版，十次里有七次犯同样的错，投票只会让这个错误更理直气壮。

第二张牌——环境——几乎没人用。但环境里才有真正的证据：源文件的版本历史、表格里缓存的计算值、PDF 里的元数据。验证不该是"再读一遍答案然后拍脑袋"，而应该是"回到案发现场取证"。

📊 一个让我愣了一下的数据

论文第 2 节做了个 claim 级别的统计分析（用 Claude Opus 4.8 在 APEX-Agents 上的十 rollout 池，APEX 的 rubric 支持逐条 claim 打分）。他们把每个任务拆成一条条"声明"（claim）——比如"FY2025 营收是 1.2 亿欧元"就是一个声明——然后按声明在各 rollout 间的经验分布算熵：

熵为零叫共识声明（大家答案一致），熵大于零叫分歧声明。统计结果是：

• 共识声明里，34% 的共识值是错的。全体一致不等于正确，投票救不了你。
• 分歧声明里，74% 包含至少一个正确候选——但出现次数最多的那个值只有 47% 的概率是对的。也就是说，正确答案经常以"少数派"的身份存在，投票会系统性地把它扔掉。

看到 47% 这个数的时候我确实愣了一下。多数投票的隐含假设是"多数即正确"，但在长程任务上这个假设几乎是个硬币翻面。

这两个观察直接催生了 VeriHarness 的双路设计：分歧里藏着正确选项，那就去取证裁决；共识里藏着漏网之鱼，那就主动去挑战。

🏗️ VeriHarness：给验证器造一个"外壳"

图 1：左图是框架——N 个 rollout 进入验证外壳，分歧裁决器查有争议的声明，共识挑战器测全体一致的声明，两路并行检查后由裁决模块汇总，最终选出或修订出交付物；底下是共享的环境证据工具和验证技能。右图是 Gemini 3.5 Flash 上的结果，带修订的 VeriHarness 在全部五个基准上超过单 rollout 基线。

先给一句话的通俗解释：生成器 = 模型 + 生成外壳（工具、记忆、循环），那验证器也可以是 模型 + 验证外壳。论文把它形式化为 \(\mathrm{Verifier} = (M, \mathcal{H}_V)\)，其中外壳 \(\mathcal{H}_V = (\mathcal{W}, \mathcal{T}, \Pi, \mathcal{S})\) 四个部分：

这个分工里我觉得最漂亮的是"工具"和"技能"的区分：工具执行检查，技能告诉你该检查什么。工具能读一张财务表格，但"这个增长率的起止年份跟标签上写的年份对不对得上"这种检查意识，是技能给的。这点后面自进化部分还会回来讲。

分歧裁决器：用信息增益选检查

裁决器找到分歧声明后，不是把所有候选再读一遍，而是主动选择"最能区分候选"的检查——论文里用了 Lindley 的期望信息增益来表述这个偏好：

当然，模型不是真的去算这个值，而是定性地判断"查哪个最能一锤定音"。拿到证据后就消去被证据否定的候选：\(\mathcal{V}_p \leftarrow \{v \in \mathcal{V}_p : v \text{ 与 } e \text{ 一致}\}\)。如果证据把所有候选都否了，只有证据本身确立了新值才记录新值，否则保持开放——不硬编答案，这个克制我很喜欢。

共识挑战器：主动找茬

挑战器面对的是没有竞争选项的共识声明，所以它得先"提出这个共识可能怎么错"，再去环境里验证。它查三类东西：

• 共识值：从原始输入重算数量、拿标签跟源元数据对（比如货币单位）；
• 共识解读：所有人对某个条款、某段时期的理解是不是跟文件实际说的不一样；
• 共识遗漏：任务要求了但所有 rollout 都漏掉的东西——这种最狠，因为遗漏在任何一份候选里都不存在，得先把它"显形"成检查目标。

一个具体的例子

图 3：任务要求从最终财务报告里取 FY2025 营收。两个 rollout 引用了草稿版报 100m，第三个引用最终版报 120m，三者都标了 USD。裁决器（2a）查版本历史，确认最终版取代草稿版，支持 120m；挑战器（2b）在独立上下文里查源文件元数据，发现货币应该是 EUR——这是所有 rollout 都犯的错。最后裁决模块（3）在全新上下文里合并两份证据记录，产出修订计划，交付"EUR 120m"的新报告并附上验证记录。

这个例子把双路设计的价值展示得很清楚：数值上的分歧（100 vs 120）靠裁决器，单位上的集体错误（USD 应为 EUR）只有挑战器能抓。缺任何一路，这份报告都是错的。

还有个工程细节：两路调查跑在独立上下文里，最后由一个不继承任何调查对话历史的全新上下文做裁决，输出基底 rollout、修订计划和未解决声明清单。为什么要分开？消融实验显示把两路合并到一个上下文会掉 0.8 分——争议声明会挤占对共识声明的注意力。这个跟人类审计的直觉是一致的：查争议和查漏洞是两种心态，混在一起容易顾此失彼。

🧪 实验：五个基准、两个前沿模型

评测覆盖五个长程工作区基准，每个任务每模型跑 N=10 个 rollout，所有方法共享同一个冻结的 rollout 池：

主结果（三种子均值，Avg 为五基准无权重平均）：

几个值得停下来看的点：

投票和 Best-of-N 基本无效。在 Flash 上，投票 47.5 vs 单 rollout 47.2，涨 0.3 分——这些长程任务上，"模型已经相信的东西"确实没什么增量信息。

光有环境访问不够。那个"有同样工作区和工具、但没有协议和技能"的对照组只恢复了大约一半的增益。这直接回应了"是不是只要把工具给模型就行了"的疑问——不是，怎么组织检查、查什么，比能不能查更重要。

修订的收益来自证据，不是来自重写。有个"把池子聚合成新交付物"的基线（不做证据检查直接重写），在每个基准上都低于 VeriHarness。也就是说，涨分不是因为"又生成了一遍"，而是因为修订计划是证据撑着的。

单项最大提升出现在 APEX-Agents + Opus：35.8 → 47.5，涨了 11.7 个点。APEX 的 rubric 是专家级的、claim 密度高，正好是证据驱动验证的主场。

顺带一提，协议还能移植：把同一套协议塞进 Gemini CLI、Claude Code、Codex 里跑，大部分增益保留（Opus 在 JobBench 上掉回单 rollout 水平，是例外）。说明协议和技能不绑定特定实现。

🧬 我最感兴趣的部分：验证技能可以自我进化

这是论文第 5 节，也是我觉得最值钱的地方。

技能库 \(\mathcal{S}\) 装的是"该查什么"的可复用知识。主实验用的是人工编写的 18 个技能（涵盖 xlsx/pdf/docx/pptx 取证、答案裁决、补丁修复等）。问题是：这些技能能不能从失败反馈里自己长出来？

设置：每个基准按约 3:1 拆开发集和留出测试集。每轮，验证器模型读开发集上的失败案例和逐条评分反馈，提出候选技能库；开发分更高的候选就替换当前库。留出分数只记录、不参与选择。四个条件对比：A 空库、B 人工库、C 从 A 进化、D 从 B 进化。

结果：

• 从空库进化的 C 反超了人工库 B：C 相对 A 在 APEX 上提升 11.0 分、SpreadsheetBench 2 上提升 5.7 分，且两个基准上都超过 B。
• 从人工库进化的 D 最好：在 B 基础上又加 6.8 分（APEX）和 3.7 分（SB-2），而且更早收敛到 C 的最终水平。

人工对比四个进化库里的 95 条检查：5 条复述了人工检查，48 条把人工检查具体化（加脚本、加常量、限定文档类型），42 条是全新的。说实话这个比例分布很说明问题——模型擅长的不是凭空发明检查思路，而是把通用原则落地成针对具体交付物类型的操作步骤。

还有个细节值得单独拎出来：两个基准上独立进化出的库，都不约而同地加入了一条指令——“重算结果跟池子里一致，不等于确认正确”。这正好命中了第 6 节分析出的验证器盲区：它倾向于在 rollout 停下的地方停下。进化过程相当于从评分反馈里学会了治自己的近视。

🔬 批判性分析

这篇论文的实验做得相当扎实，但有几个地方我觉得值得聊聊。

增益高度依赖池子里的分歧。第 6 节按池子的声明熵分组：154 个全体一致的池子上，选择分数只比池均值高 0.6 分；262 个有分歧的池子上高 6.1 分，且增益随熵增长（低熵 4.5 → 中熵 7.7）。你想想看，这其实暴露了一个边界：如果模型对某个任务系统性地犯同一个错且从不分歧，VeriHarness 的选择阶段基本无计可施，只能靠挑战器和技能库去硬碰。挑战器确实安全（从未推翻过全体正确的声明），但它漏掉的共享错误里，70% 是因为它只查了正确的中间量、而错误在下游步骤。验证器的视野还是被生成器的轨迹"锚定"了。

离 oracle 还有距离。选择 oracle 在 Flash 上是 62.7、Opus 63.1，VeriHarness 带修订也只到 53.4 / 56.1。也就是说池子里明明有好答案，验证器只能捞出来一半多一点。当然这不公平——oracle 偷看了评分器——但这个差距说明"从分歧中识别正确"这件事远没有解决。

成本是绕不开的话题。Flash 下选择阶段每任务 1.44 美元（只有 LLM-as-a-Verifier 的十分之一，增益却是两倍），Opus 下 3.92 美元；修订阶段大约是选择的三倍。便宜的原因之一是 86% 到 91% 的输入 token 走了缓存——如果按全价算，Opus 的选择成本是 13.06 美元/任务。再叠加 N=10 的 rollout 池本身（整个数据池花了超 10 万美元），这套方案的总账单并不便宜。它适合的是"质量优先、不差这几美元"的专业交付场景，论文自己也承认这点——报告、工作簿、补丁这类东西，晚几分钟、多花几块钱换质量是划算的。

baseline 选择总体公道。多数投票、Best-of-N、锦标赛、最新的 LLM-as-a-Verifier（Stanford/Berkeley 那套用 logprob 做细粒度打分的框架）都覆盖了，还加了两个消融式对照（有环境无协议、聚合重写）。所有方法共享同一个冻结 rollout 池，评分器对验证器完全不可见——这个实验卫生做得比很多 test-time scaling 论文都好。

💡 我的判断

这篇论文的定位，我会用一句话概括：它把验证从"判断"升级成了"调查"。

之前的 test-time 验证，无论是投票还是 judge，说到底都是让模型基于已有信念再表一次态。VeriHarness 的关键转变是给验证器一个工作区，让"证据"成为裁决的硬通货——声明对不对，不看谁说得自信，看源文件、重算结果、元数据怎么说。34% 的共识错误率和 74% 的分歧含正确这两个数字，为这种转变提供了坚实的动机。

从工程角度，几个可以直接抄走的思路：

• 如果你在做智能体产品，N 次采样 + 分歧检测几乎是免费的信号——分歧声明值得重点投入验证算力，共识声明要么信要么专门挑战；
• 验证协议比验证模型重要：同一个模型，给环境和工具但不给协议，只能拿一半增益；
• 技能库是验证的复利：人工写一版检查清单当种子，让模型从失败反馈里迭代，比从零开始又快又好；
• 验证记录（每条 claim 对应检查、证据、结论）天然是 claim 级别的监督信号，论文结尾也点了这个方向——拿它当训练数据反哺生成器，可能是长程智能体 RL 的下一个富矿。

至于局限，除了上面说的共识盲区和成本，还有个论文没展开的问题：所有实验都是 N=10 的池子。池子规模缩到 3 或 5 时，分歧暴露正确选项的概率会怎么衰减？这直接决定了这套方案在预算受限场景下的可用性。开源的 26,000 条 rollout 池应该能让社区把这个问题研究清楚。

总的来说，这是今年我看到的把"test-time compute 花在验证上"讲得最清楚、做得最干净的一篇。不是底层突破，但框架设计、实验严谨度和数据开源的诚意都在线，值得细读。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我