VeriHarness 拆解：多数投票为何会掩盖错误

一个没有答案 key 的难题

智能体跑完一个几十步的长任务，交出一份表格、一份报告或改好的文件，谁来判定它对不对？短问答可以靠标准答案或单元测试，但长任务的交付物往往没法写成断言：一个财务比率可能取错了年份，一份报告可能引用了已失效的来源，而且这些错误通常藏在"看起来很正常"的成品里。

谷歌云 AI 研究与剑桥大学的团队在 2026 年 10 月 1 日提交的论文《VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks》（arXiv:2610.00972）针对的正是这一点。它的前提很克制：测试时没有参考答案，也没有评分标准（rubric），只能靠模型自己查。

核心发现：共识可能是"共同犯错"

论文先做了一次主张级（claim-level）的统计分析，用的是 Claude Opus 4.8 在 APEX-Agents 上每题 10 条 rollout 的记录池，共 917 条共识主张、775 条争议主张，正确与否用该基准自己的 rubric 判定。结果很反直觉：

共识值里有 34% 被判为错误------所有 rollout 都同意，但同意的是错的。
争议主张里，74% 至少包含一个正确答案；出现频率最高的那个值，只有 47% 是对的。

这两条分别打脸两种常见直觉。第一种是"多数投票/自一致性"：既然 34% 的共识本身是错的，把它当作可信信号就等于把共享错误原样保留下来------模型完全可能每次都犯同一个错（例如所有 rollout 都用了同一个过时来源、同一个错误单位）。第二种是"分歧等于噪音"：争议主张里正确答案出现率高达 74%，分歧恰恰暴露了正确选项，是信息而不是噪音。需要注意的是，这些是主张级百分比，不等于整份交付物的准确率。

原理：把验证本身也做成一个 Agent

VeriHarness 的做法是把生成器用的那个底层模型，套上另一套 harness 变成验证器：

复制代码

Verifier = (M, H_V),  H_V = (W, T, Π, S)

其中 M 是冻结的基础模型（不训练、不微调），W 是工作区，T 是取证工具，Π 是验证协议，S 是技能库。工作区把每条 rollout 的产物、最终状态和执行轨迹以文件形式暴露出来，连同任务描述和环境文件；工具让验证器能追溯来源、重算数值、检查元数据、执行代码来取证据。

协议把两个检查任务分派给彼此独立的上下文：

分歧解决器：先比对各份产物定位争议主张 p 及其候选值集合，把候选追溯到来源或计算过程，再选择最有区分力的检查。论文用期望信息增益（Lindley, 1956）来刻画这个选择------增益大的检查优先。跑完一个检查后，被证据否定的候选值从信念集合中被剔除。关键点是：它允许"所有候选都可能错"。

共识挑战器 ：对全体一致的取值、解释或遗漏，先提出"它可能怎么错"，再去环境里验证这些假设，并搜索被所有 rollout 一起漏掉的需求。论文指出，光看结果池是想不出失败模式的，必须主动构造证伪假设。

两个上下文各自产出证据记录后，进入裁决：一个全新上下文同时审阅两份记录，挑出一份底子最好的产物作为基础，只做有证据支持的修订，仍没查清的条目在验证记录里标记为 unresolved。这最后一步很重要------它把验证从"打分"变成"选 + 改"。

技能库：工具负责查，技能负责"查什么"

VeriHarness 把可复用的失败模式写成短文本（可带脚本），按阶段组织：evidence-*（读写比对产物的通用工具，所有阶段可用）、resolve-*（什么证据能了结分歧，给解决器）、falsify-*（共识怎么可能是错的，给挑战器）、repair-*（如何修订产物而不弄坏它，给交付阶段）。裁决阶段只拿到 evidence-*。论文强调一条红线：技能里不含任务专属答案。举例来说，工具能读一张财务表，而技能会指示验证器去检验"某个增长率是否覆盖了它标注的那些年份"。

论文还展示了技能可以从失败反馈中自我进化 。README 补充了发布后的实情：resolve-*、evidence-patch、repair-patch 以及两个 xlsx 扫描器是在论文跑完之后、根据 harness 在这些基准上的失败分析补写的，包括 SpreadsheetBench 2 上自进化实验的教训；作者保留了无参考、与基准无关的流程，剔除了"自动填单元格或编码了某基准参考约定"的脚本。他们也坦白：这些补充来自同一批评测基准的失败模式（不是答案），所以不构成对技能库的留出测试。

结果：选择分最高，修订再加一档

五个长程工作区基准：APEX-Agents、Workspace-Bench Lite（WSB）、WorkBuddy Bench、SpreadsheetBench 2（SB-2）、JobBench；生成和验证用同一款模型，测了 Gemini 3.5 Flash 与 Claude Opus 4.8。所有方法共享同一份冻结的十条 rollout 池。

以 Gemini 3.5 Flash 为例（各基准原生量表）：

基准	单次 rollout	LLM-as-a-Verifier	VeriHarness（含修订）	相对单次增益
APEX-Agents	48.1	49.8	54.8	+6.7
Workspace-Bench Lite	56.5	60.4	65.4	+8.9
WorkBuddy	73.2	75.3	78.2	+5.0
SB-2	27.3	30.2	32.2	+4.9
JobBench	30.9	31.9	36.2	+5.3

五基准未加权平均：VeriHarness 选择 51.6 ，LLM-as-a-Verifier 49.5，只给同样的工作区与取证工具但去掉协议和技能的 "agentic verifier" 49.4，单次 rollout 47.2。这组消融值得留意------单给工具还不够，协议与技能才是把 49.4 推到 51.6 的那部分。加上证据驱动的修订后，相对单次 rollout 平均增益为 Flash 6.2 分、Opus 6.4 分；论文称修订在全部十组"模型 × 基准"设置上都有提升。作者还报告协议可以迁移到现有的智能体命令行工具上，且大部分增益得以保留。

需要说明的是，这些是基准分数增益，不是更少 token、更少尝试次数或更短耗时。

和已有方案的取舍

对比多数投票/自一致性：便宜、好实现，在短问答上有效。但长任务有两个硬伤------交付物是一个文件，没法简单投票；多个结果一致时投票会保留共同错误。VeriHarness 的两条路线分别针对这两点，代价是验证变成一段要调工具、烧 token 的 agentic 流程。

对比 LLM-as-a-Judge ：裁判只读产物就打分，不回环境核对，容易给"看起来漂亮"的答案高分。VeriHarness 把"能不能在环境里找到证据"放在中心，换来更硬的结论，但把验证成本抬高了。论文没有给出验证相对生成的额外开销比例，想算这笔账只能自己跑。

适合谁用、怎么上手

适合那些交付物是文件、且无法用单元测试判定的场景：办公文档与电子表格流水线、数据核对、多步工作流，以及任何"多跑几遍取多数"已经在用、但担心共享错误的团队。如果你的任务本身能用确定性断言判定，直接写测试比这套便宜得多。

仓库 google-research/veriharness 以 Apache 2.0 放出，运行环境为 Linux，需要 Python 3.10+、Node.js 22.19+、Docker 及非特权用户命名空间，底层跑在开源的 pi 运行时上，pi 支持的模型服务商都能接。典型流程：

bash 复制代码

export VERIHARNESS_BENCH_ROOT=/path/to/benchmarks-root
harness/scripts/setup_benchmarks.sh sb2 jb   # 只装需要的基准
python3 -m harness.materialize               # 构建任务工作区
# 评分：--select-only 只用归档分数；否则重评修订版与未修订底本
python3 score.py --select-only

两个工程细节体现了它的取舍。其一，评分公式是 final = select + (revised − base_regraded)，即修订版和未修订底本在同一次 里重评，让 grader 漂移与裁判噪声在差分中相消。其二，验证会话跑在 jail_run.sh 挂载命名空间隔离里（unshare -r -m -p，无需特权）：工作区是唯一可见的项目状态，spec/、workspace/、rollouts/ 只读，$HOME 其余部分、数据根、/tmp、/var/tmp 全部隐藏，容器运行时被 mask，因此归档分数和答案 key 在会话中不可达 ；评分器在验证批次结束后于宿主机运行，从不进入 jail。论文还把约 2.6 万条 rollout（两款模型 × 五个基准，每题 10 次）放到 Hugging Face（caiqizh/veriharness），据论文称生产成本超过 10 万美元。

局限与提醒

项目页明确写着 "This is not an officially supported Google product"，目前是研究代码，谷歌不承诺维护。论文测的 Gemini 3.5 Flash 与 Claude Opus 4.8 都不是各家最新一代，换成更新的模型后增益还剩多少，作者没测，只能等第三方复现。验证器与生成器同源，也可能共享盲点------共识挑战器正是为缓解这点而设，但它能否真的跳出模型自身的先验，仍取决于它是否愿意构造证伪。另外，jail 里没有网络命名空间，模型端点可达但网络环境是受限的，部署时要留意。

对工程实践最有价值的一条经验或许比那 6 分更大：验证器需要和生成器一样的工具与环境访问权，否则它只是在批改一份自己没法核对的答卷。

参考链接

VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks --- https://arxiv.org/abs/2610.00972
Google Research, veriharness（Apache 2.0 代码与 README）--- https://github.com/google-research/veriharness
alphaXiv 论文页与主张级分析数据 --- https://www.alphaxiv.org/abs/2610.00972
DAIR.AI Academy 论文摘要页 --- https://academy.dair.ai/papers/veriharness-scaling-agentic-verification-for-long-horizon-tasks-2610.00972
Hugging Face 数据集 caiqizh/veriharness（约 2.6 万条 rollout）--- https://huggingface.co/datasets/caiqizh/veriharness
The Agent Times: Google Researchers Ship VeriHarness to Verify Agent Outputs Across Long-Horizon Tasks --- https://theagenttimes.com/articles/google-researchers-ship-veriharness-to-verify-agent-outputs--9fa74d87
Verifying Long-Horizon Agents Without an Answer Key（开发者讨论）--- https://kiranramanna.github.io/thinkit/2026/10/05/verifying-long-horizon-agents-without-an-answer-key.html
Envisioning: VeriHarness 词条（含与同名论文的区分）--- https://www.envisioning.com/vocab/veriharness