Google 研究团队 10 月 1 日在 arXiv 提交论文，公开了一套叫 VeriHarness 的智能体验证框架，代码同步放到 GitHub，采用 Apache 2.0 许可。它要解决的事很具体：智能体跑一个要几十步的长任务，交出来一份表格、一份报告或一个改好的文件，谁来判断这份东西对不对。
VeriHarness 的做法是让生成答案的那个模型自己当复核员。同一道题先让模型独立跑多遍，得到多份结果，再把这些结果摊开比对，按”分歧”和”共识”两类分别处理。
两条复核路线
第一条处理分歧。几份结果在某个结论上说法不一，复核员就回到任务环境里找证据，比如重新打开原始文件、查表格里的具体单元格，用环境里能查到的东西把错误的说法排除掉。
第二条处理共识。几份结果意见一致，框架也不直接放行，会主动去挑刺，专门找能推翻这个结论的证据，同时检查是不是所有结果都漏掉了任务里的某条要求。论文的出发点是，多次运行得出相同答案，并不能保证答案正确，模型完全可能每次都犯同一个错。
两条路线跑完，进入裁决环节：选出一份底子最好的结果作为基础，根据查到的证据提出修订，必要时整体重做，并把仍然没查清的问题单独记下来。框架给复核员配了工作区、取证工具和一组可复用的”验证技能”，论文称这些技能还能根据失败反馈自我改进。
测了什么，提了多少
评测覆盖五个长程工作区基准：APEX-Agents、Workspace-Bench Lite、WorkBuddy Bench、SpreadsheetBench 2 和 JobBench，多数是办公文档、电子表格、求职材料这类要交付文件的任务。生成和复核都用同一款模型，测了两款：Gemini 3.5 Flash 和 Claude Opus 4.8，均通过 Vertex AI 调用。
按论文和 README 的说法，VeriHarness 在五个基准上的”选择分”都排第一，对照组包括单次运行和此前的 LLM-as-a-Verifier 类方法。加上证据驱动的修订后，相比单次生成，Gemini 3.5 Flash 平均提升 6.2 分，Claude Opus 4.8 平均提升 6.4 分。
团队同时在 Hugging Face 公开了约 2.6 万条运行轨迹，两款模型在五个基准上每题各跑 10 次，附带渲染后的执行过程、交付文件和评分。基准的输入和标准答案没有放出。论文提到，产出这批数据花了超过 10 万美元。
和”多跑几遍取多数”差在哪
让模型多跑几遍再投票，是业内常用的提分办法，成本低、好实现，短问答上效果明显。放到长任务上就有两个麻烦：交付物是一份文件，没法简单投票；几份结果一致时，投票会把共同的错误原样保留。VeriHarness 的两条路线，分别对着这两个麻烦去。
另一类常见做法是找一个模型当裁判，读完几份结果直接打分。这种做法依赖裁判的阅读判断，不回环境核对。VeriHarness 把”能不能在环境里找到证据”放在中心位置，代价是复核本身也变成了一段要调用工具、要花 token 的智能体任务。论文没有给出复核环节相对生成环节的额外开销比例，企业要算这笔成本，目前只能自己跑。
站内此前报道过微软的 ThinkingBox 基准，它要求同一任务重复评测 20 次，看的是智能体结果稳不稳。两项工作放在一起看，方向一致：长任务里单次成绩的参考价值有限，多次运行之间的差异本身就是信号，一个拿来衡量稳定性，一个拿来纠错。
能不能直接用
README 写明运行环境为 Linux，需要 Python 3.10 以上、Node.js 22.19 以上、Docker，以及非特权用户命名空间；底层跑在开源的 pi 运行时上，pi 支持的模型服务商都能接。项目页面也写了一句：
“This is not an officially supported Google product.”（这不是 Google 官方支持的产品。）
也就是说，它目前是一份研究代码，Google 不承诺维护。论文测的两款模型都不是各家最新一代，换成 Gemini 4 或 Opus 5.5 之后提升幅度还剩多少，作者没有测，这部分只能等第三方复现。
参考来源：arXiv 论文《VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks》、Google Research GitHub 项目页、CocoLoop、Hugging Face 数据集页；论文与 README 核验五个基准名称、两款模型的平均提升分数、约 2.6 万条轨迹及运行环境要求。