尧图网站建设 
一个没有答案 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%分歧恰恰暴露了正确选项是信息而不是噪音。需要注意的是这些是主张级百分比不等于整份交付物的准确率。原理把验证本身也做成一个 AgentVeriHarness 的做法是把生成器用的那个底层模型套上另一套 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 LiteWSB、WorkBuddy Bench、SpreadsheetBench 2SB-2、JobBench生成和验证用同一款模型测了 Gemini 3.5 Flash 与 Claude Opus 4.8。所有方法共享同一份冻结的十条 rollout 池。以 Gemini 3.5 Flash 为例各基准原生量表基准单次 rolloutLLM-as-a-VerifierVeriHarness含修订相对单次增益APEX-Agents48.149.854.86.7Workspace-Bench Lite56.560.465.48.9WorkBuddy73.275.378.25.0SB-227.330.232.24.9JobBench30.931.936.25.3五基准未加权平均VeriHarness 选择 51.6LLM-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 支持的模型服务商都能接。典型流程exportVERIHARNESS_BENCH_ROOT/path/to/benchmarks-root harness/scripts/setup_benchmarks.sh sb2 jb# 只装需要的基准python3-mharness.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 Facecaiqizh/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.00972Google Research, veriharnessApache 2.0 代码与 README— https://github.com/google-research/veriharnessalphaXiv 论文页与主张级分析数据 — https://www.alphaxiv.org/abs/2610.00972DAIR.AI Academy 论文摘要页 — https://academy.dair.ai/papers/veriharness-scaling-agentic-verification-for-long-horizon-tasks-2610.00972Hugging Face 数据集 caiqizh/veriharness约 2.6 万条 rollout— https://huggingface.co/datasets/caiqizh/veriharnessThe 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–9fa74d87Verifying Long-Horizon Agents Without an Answer Key开发者讨论— https://kiranramanna.github.io/thinkit/2026/10/05/verifying-long-horizon-agents-without-an-answer-key.htmlEnvisioning: VeriHarness 词条含与同名论文的区分— https://www.envisioning.com/vocab/veriharness 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%分歧恰恰暴露了正确选项是信息而不是噪音。需要注意的是这些是主张级百分比不等于整份交付物的准确率。原理把验证本身也做成一个 AgentVeriHarness 的做法是把生成器用的那个底层模型套上另一套 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 LiteWSB、WorkBuddy Bench、SpreadsheetBench 2SB-2、JobBench生成和验证用同一款模型测了 Gemini 3.5 Flash 与 Claude Opus 4.8。所有方法共享同一份冻结的十条 rollout 池。以 Gemini 3.5 Flash 为例各基准原生量表基准单次 rolloutLLM-as-a-VerifierVeriHarness含修订相对单次增益APEX-Agents48.149.854.86.7Workspace-Bench Lite56.560.465.48.9WorkBuddy73.275.378.25.0SB-227.330.232.24.9JobBench30.931.936.25.3五基准未加权平均VeriHarness 选择 51.6LLM-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 支持的模型服务商都能接。典型流程exportVERIHARNESS_BENCH_ROOT/path/to/benchmarks-root harness/scripts/setup_benchmarks.sh sb2 jb# 只装需要的基准python3-mharness.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 Facecaiqizh/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.00972Google Research, veriharnessApache 2.0 代码与 README— https://github.com/google-research/veriharnessalphaXiv 论文页与主张级分析数据 — https://www.alphaxiv.org/abs/2610.00972DAIR.AI Academy 论文摘要页 — https://academy.dair.ai/papers/veriharness-scaling-agentic-verification-for-long-horizon-tasks-2610.00972Hugging Face 数据集 caiqizh/veriharness约 2.6 万条 rollout— https://huggingface.co/datasets/caiqizh/veriharnessThe 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–9fa74d87Verifying Long-Horizon Agents Without an Answer Key开发者讨论— https://kiranramanna.github.io/thinkit/2026/10/05/verifying-long-horizon-agents-without-an-answer-key.htmlEnvisioning: VeriHarness 词条含与同名论文的区分— https://www.envisioning.com/vocab/veriharness