智能体跑完几十步的长任务，交出一份表格、一份报告或改好的文件，谁来判定对不对？短问答能靠标准答案或单元测试，长任务的交付物往往没法写成断言：财务比率可能取错年份，报告可能引用失效来源，而这些错误通常藏在看起来很正常的成品里。谷歌云 AI 研究与剑桥大学的论文 VeriHarness（arXiv:2610.00972）针对的正是这个场景，前提很克制：测试时没有参考答案，也没有评分标准，只能靠模型自己查。
先看一组反直觉的统计
论文先做主张级分析，用某旗舰模型在长任务基准上每题 10 条 rollout 的记录池，以基准自带的评分标准判定对错。结果两条都打脸直觉。其一，共识值里有 34% 被判为错误——所有 rollout 都同意，但同意的是错的：模型完全可能每次都犯同一个错，比如全部用了同一个过时来源或同一个错误单位，多数投票把共享错误原样保留。其二，争议主张里 74% 至少包含一个正确答案，而出现频率最高的值只有 47% 是对的——分歧不是噪音，是信息，恰恰暴露了正确选项的位置。要注意这是主张级百分比，不等价于整份交付物的准确率。
把验证本身做成一个智能体
框架的做法是把生成器的底层模型套上另一套运行环境变成验证器：冻结的基础模型不训练，配一个暴露产物、最终状态和执行轨迹的工作区，一批取证工具负责追溯来源、重算数值、检查元数据，再由验证协议把检查任务分派给两个彼此独立的上下文。
分歧解决器：比对各份产物定位争议主张，把候选值追溯到来源或计算过程，按期望信息增益挑区分力最强的检查，跑完把被证据否定的候选从信念集合剔除——关键设计是允许"所有候选都可能错"。
共识挑战器：对全体一致的取值主动构造证伪假设——"它可能怎么错"，再去环境里验证，并搜索所有 rollout 一起漏掉的需求。论文点明，光看结果池想不出失败模式，必须主动出击。
两个上下文各自产出证据记录后进入裁决：一个全新上下文审阅两份记录，挑底子最好的产物，只做有证据支持的修订，没查清的条目标记为未决。验证从"打分"变成了"选加改"。
技能库：工具负责查，技能负责查什么
可复用的失败模式被写成短文本技能，按阶段组织：证据读写类通用、分歧解决类给解决器、证伪类给挑战器、修订类给交付阶段。红线是技能不含任务专属答案——工具能读财务表，技能只指示去检验"增长率是否覆盖它标注的年份"。技能还能从失败反馈中进化，但作者坦白：这些补充来自同一批评测基准的失败模式，不构成留出测试。
数据与取舍
五个长程工作区基准、生成与验证同款模型的设置下，验证框架相对单次 rollout 平均提升 6 分上下，比纯 LLM 裁判高一档。最值得看的是消融：只给同样的工作区和取证工具但去掉协议与技能，分数与普通 LLM 裁判几乎持平——协议和技能才是拉开差距的部分。要说明的是，这些是分数增益，不是更少 token 或更短耗时，论文没给验证相对生成的额外开销比例，这笔账要自己跑。
与多数投票比：投票便宜、短问答有效，但长任务交付物没法投票，且共识保留共同错误。与 LLM 裁判比：裁判只读产物不回环境核对，容易给"看起来漂亮"的答案高分。
工程细节与上手
开源仓库以宽松协议放出，环境要求 Linux、Python 3.10 以上、Node 22 以上加 Docker。两个工程细节体现取舍：评分公式把修订版与未修订底本在同一次里重评，让裁判漂移在差分中相消；验证会话跑在非特权命名空间隔离里，工作区只读、答案不可达、评分器在宿主机运行。上手按仓库脚本装基准、构建工作区、先用只选模式评分再开修订。
局限也要心里有数：研究代码不受官方维护承诺，测试用的模型非最新一代，增益能否迁移待第三方复现；验证器与生成器同源可能共享盲点。但有一条经验比分数更有价值——验证器需要和生成器同等的工具与环境访问权，否则它只是在批改一份自己没法核对的答卷。自己的团队可以直接借用这个思路：给验收环节配足取证手段，验收质量才有下限。
评论0