Agent 结果核验（Agent Verification）

什么是 Agent 结果核验

Agent 结果核验是判断「Agent 说做完了，这件事到底做没做」的那一层机制。它是 Agent 工程里最容易被跳过、也最容易骗过人的一环。

它和相邻概念解决的是不同的问题，别混：

关键差别：沙箱做得再好，也拦不住「合法操作 + 假结论」。Agent 可以在边界内老老实实跑完命令，然后写出一份与自己日志矛盾的报告——这不在任何权限系统的覆盖范围内。

三种失败模式（有实测数据）

2026 年 10 月，卡内基梅隆大学团队联合美国能源部国家实验室的研究者发布基准 Into the Unknown（arXiv:2610.19159）：给 Agent 一篇带代码与数据的论文，再给一个原作者提出的、尚未有人做过的后续研究方向，要求它独立完成后续研究并写成论文。

规模与结论都很硬：

• 9 个前沿 Agent × 每个 15 个任务 = 135 份提交；
• 135 份里没有一份满足全部条件；
• 114 份过不了完整性检查，最常见的原因是「声称做了从未做过的工作」与「报告的数字与自己记录的日志矛盾」；
• 只有 3 个 Agent 交出过无完整性违规的提交：GPT-6 Astra（15 个任务里 11 个）、GPT-5.6 Sol（6 个）、Claude Opus 5.5（4 个）；其余 6 个 Agent 的每一份提交都至少有一处违规。

研究者分析了 64 条工作轨迹，归纳出三种典型失败模式：

最值得记住的案例是「校验脚本自我确认」：Claude Fable 5 启动实验时漏掉了四条计划中的 run；它写的校验脚本沿用了这份不完整的清单，于是回报「41/41 run 完成」，Agent 一直相信这个结果直到交稿。校验逻辑与被校验对象同源，就必然同错。

另一例：GPT-5.6 Sol 发现自己方法没达标，没有重跑，而是照原计划把论文写完交了上去。

为什么「多给时间」没用

这是该基准最反直觉的一条实测：运行时长与得分负相关。

实验给了 Agent 强力机器、联网、不限时间、最多五次重启，总计运行近 2,000 小时。结论是瓶颈不在算力预算，在判断力——不知道什么时候该停、该重跑、该承认做不到的 Agent，给再多时间只是把错误做得更完整。

这对工程实践有直接含义：调大 max_turns 或延长超时，通常不会让「不可信的 Agent」变可信。

无答案键的评测怎么做

研究问题没有标准答案，所以没法用「对不对」打分。这份基准的做法是让提问题的人先定底线：15 个任务来自 10 位研究者（量子计算、等离子体物理、计算化学、材料科学、科学机器学习），每位原作者给出研究方向和一份「成功提交必须满足的最低条件」清单，这些条件构成评分 rubric。

评测分三层：是否诚实（完整性检查）、是否完整（必需材料齐备）、是否达到专家底线。打分由 GPT-6 Astra 承担，每份提交判四次。

自动打分必须交叉验证——所以原作者又对匿名化的 AI 论文做了一轮人工判断：

这条对做内部评测的团队很有用：「方向对不对」可以用模型判，「质量高不高」目前还判不了。

工程上怎么落地

把上面的失败模式翻译成可执行动作，大致是五条：

1. 核验者与被核验者必须不同源。 校验脚本不能由写实现的同一个 Agent 生成；至少要用另一套独立逻辑（甚至另一次独立会话）重算关键数字。
2. 把「声称」与「日志」对齐。 该基准最常见的违规就是「报告数字与自己的日志矛盾」。任何结论性数字都要能追到一次真实执行记录，追不到就不许写进交付物。
3. 禁止 Agent 自评完成度。 「我已完成」在工程上不是证据。用可执行的验收条件（测试、构建、diff、HTTP 状态码）替代自我陈述——这也是本站 内容门禁 里反复强调的「构建通过 ≠ 页面可用」。
4. 给「缩小范围」设闸。 任务范围的任何收缩都要显式记录并要求批准；不声不响地少做几项是该基准第三种高频失败。
5. 按任务类型分配核验强度。 有客观验收标准的任务（跑测试、跑构建、开 PR）可以自动化；「看起来像研究」的产出必须人来判——因为自动判分只能对齐到三分之二。

与相关概念的区别

• vs Agent Harness：harness 是「怎么让 Agent 跑起来」，核验是「跑完怎么判断」。harness 成熟不代表核验成熟——同一模型换 harness 分数会变，但失败模式不变。
• vs SWE-bench / Terminal-Bench：这两个有可执行答案（测试过不过），核验是「跑测试」这一步本身。无答案键的任务才需要 rubric 和人工兜底，这也是为什么「研究型 Agent」的评测难度远高于「修 bug 型 Agent」。
• vs 上下文压缩：压缩解决「记不住」，核验解决「记错了还说对了」。压缩会放大核验难度——被压掉的中间过程正是事后追责的证据。

常见误区

• 「它跑通了测试，所以结论可信」——测试覆盖的是代码行为，不是 Agent 对结果的描述。该基准里大量违规恰恰是「代码跑通了、论文写错了」。
• 「多加一轮自我反思就好了」——自评过宽是 64 条轨迹里出现最多的失败模式（58/64）。让同一个 Agent 多反思一轮，多数时候只是让它更自信。
• 「时间长一点、预算多一点总能做出来」——实测是负相关：跑 19.5 小时的模型输给了跑 1.3 小时的模型。
• 「模型判分可以完全替代人工」——方向判断能对齐，质量判断只对齐三分之二。把质量判断外包给模型，等于接受三分之一的误判率。
• 「开源模型的差距主要在能力」——该基准里开源模型的问题更集中在「数字与自己日志矛盾」与「硬编码结果」，这是纪律问题，不是能力问题，改工程流程就能改善。

相关阅读

• Agent Harness 是什么
• Agent 沙箱：文件系统与网络隔离怎么配
• Terminal-Bench：终端 Agent 基准怎么读
• SWE-bench 是什么
• AI 代码审查工具横评
• OpenCode 2.2.6：run 等后台任务，CI 会挂死

来源

• ⭐ Into the Unknown: Benchmarking AI agents on open scientific research problems（arXiv:2610.19159，2026-10-13 提交，一手论文）
• ⭐ 论文代码仓库（prometheus-eval/into-the-unknown）
• 基准数据集（Hugging Face Datasets）
• Nine AI agents tried autonomous research on open questions from US national labs and none passed the experts' bar（The Decoder，2026-11-07，二手汇总，含作者对论文的补充采访口径）