AI 说“搞定了”，怎么验收？

假设一个 agent 接到任务：查资料、做比较、生成报告。几分钟后，它回复：“已完成。”

这句话可以作为交付通知。至于活儿干得怎么样，还得打开文件，检查资料和结论。

任务不能靠一句“搞定了”通关。

这个例子正好引出 LLM 和 LLM agents 的 benchmark——也就是测能力用的那套“考题、考场和判卷规则”。其中两个经常出现的词，是 verifiable 和 unverifiable。

听起来有点绕，其实可以先从“这份作业怎么批”来理解。

Verifiable：有相对明确、可重复的验收办法。

数学题可以核对答案；代码可以跑功能测试；agent 修改了订单，可以检查数据库里的结果。

但要注意验收范围。代码通过已有测试，只说明这些检查通过了，不能保证所有情况都正确。

Unverifiable：在当前时间和预算内，还没有可靠的自动验收办法。

比如，一份报告有没有洞察，一段解释是否适合读者，一个方案是否考虑周全。这些问题可以请人判断，也可以制定评分标准，只是很难像核对数字那样，低成本、稳定地给出整体结论。

这里的“不可验证”，不代表永远无法判断。它描述的是我们目前掌握的验证条件。

而且，题难不难，与卷子好不好批，是两回事。 很难的编程题可以有明确测试；一条很短的文案，是否写得合适却可能有分歧。

同一份作业，还能分开批。“写三段”可以自动检查，“这三段有没有说清楚”需要另一套评价。IFEval 就使用可检查的指令约束来评估模型。字数、格式合格，内容仍然要另看。IFEval

给整个任务贴标签之前，先拆开看看：哪些部分能直接查，哪些需要核对证据，哪些需要专业判断。

近年的几个变化，也都围绕这个问题展开。

首先，验收办法正在变成训练反馈。

DeepSeek-R1-Zero 使用数学答案检查、代码测试等规则奖励。模型可以反复尝试，根据反馈调整行为。这让验证器既能参与评分，也能参与训练。DeepSeek-R1

好的任务和验证机制，有机会同时支持“练习”和“考试”。但练习题与考试题需要分开。

模型在反复练过的原题上拿高分，不能单独证明它会处理没见过的任务。押题很准，和能力能迁移，需要不同的证据。

其次，agent 的表现需要“查现场”。

Agent 说记录更新了，就去查记录；说问题修好了，就看补丁和测试结果。

WebArena 检查网页任务的完成情况；τ-bench 把模拟用户、工具和领域规则放在一起，并比较最终数据库状态与目标状态。这些工作让评分有了可检查的环境结果。WebArena、τ-bench

如果任务还规定了操作边界，就要检查实际操作记录。目标记录改对了，但顺手改坏了其他记录，也应该被评测发现。

这里还有一个容易忽略的问题：agent 的成绩包含模型、工具、提示、记忆和重试策略的共同作用。比较模型时，要尽量控制这些条件；比较完整系统时，要把配置和成本说清楚。

否则，一个系统自带搜索、能跑代码、还能重试很多次，另一个只能回答一次，把分差全算到模型头上，就容易记错功劳。

第三，开放任务的“印象分”，正在变成更具体的评分表。

Rubric 可以简单理解为一张验收清单。例如，给调研报告打分时，分别检查：

• 用户问的关键问题，回答了吗？
• 重要结论，有来源支持吗？
• 来源互相矛盾时，解释了吗？
• 读者能看懂结论和取舍吗？

ICLR 2026 的 QuRL 探索了从网络材料构建问题相关的 rubric，再把它用于开放问答的强化学习反馈。这为开放任务提供了更具体的学习信号。QuRL

不过，清单写漏了，模型可能漏做；裁判看错了，模型也可能拿到不该拿的分。

让大模型给大模型批作业，很方便，但仍需要校准。LLM-as-a-judge 的研究讨论过位置、篇幅等偏差。语言流畅，不能自动换算成事实正确。LLM-as-a-Judge

值得追问的是：换一批任务、换一个裁判，再请人独立检查，提升还在不在。

还有一件事：裁判也得考试。

这个要求同样适用于程序测试。

2026 年，OpenAI 对 SWE-bench Verified 和 SWE-Bench Pro 的审计报告了题目与测试要求不一致等问题。有的测试要求题目没说的功能，有的过度依赖特定实现。也就是说，模型被判错，可能是解法有问题，也可能是验收规则有问题。Verified 审计、Pro 审计

做 benchmark 的第一步，不妨先检查评分器的“判卷能力”。

真正动手构建时，可以按下面这条路线走。

1. 先写验收单，再攒题库。 把“测 agent 会不会做研究”收窄成具体任务，例如“在固定资料和预算内，核对信息并生成比较报告”。输入、工具、交付物和成功条件都要清楚。先做小型试点，让别人独立跑一遍，修完问题再扩大。

2. 一份作业，分项验收。 文件是否生成、格式是否满足，可以自动查；引用是否支持结论，需要核对原文；分析是否充分，可以结合人工校准的评分表。分项结果要保留，别让漂亮排版的加分掩盖关键事实错误。

3. 先考裁判。 给它正确但写法不同的答案，也给它看起来漂亮、实际有错的答案。检查它会不会误拒正确解、放过错误解。参考答案要独立复核，测试要允许合理的不同解法，人工评测者之间的分歧也要记录。

4. 给 agent 准备可复现的考场。 每次从相同初始状态开始，记录工具和资源条件，把隐藏测试与 agent 能修改的工作区隔离。环境故障单独记，别把考场断电算成考生不会做题。

5. 练习题和考试题分开。 同一文档、仓库或模板衍生的近似题，需要根据要测的泛化能力分组。LiveCodeBench 持续收集新题，提供了缓解污染的思路；更新题目仍需配合去重和来源检查。LiveCodeBench

6. 别只发高光集锦。 多跑几次，把成功率、波动、错误类型和总成本一起报告。模型版本、工具配置和重试规则也要公开。一次成功和稳定成功，是两种使用体验。

最后这一点，直接关系到 agent 能否在日常使用中可靠地完成任务。

τ-bench 的 pass^k 关注多次运行能否都成功，和“试很多次，至少成功一次”衡量的是不同事情。高光集锦能展示系统曾经做到什么，日常使用还需要知道它有多稳定。τ-bench

接下来，一个值得探索的问题是：agent 能不能判断自己什么时候需要“再确认一下”？

工具返回含糊时，去查实际状态；来源冲突时，继续核对；证据不够时，明确保留不确定性。这些动作可能提高交付质量，也会多花时间和成本，值不值得需要实测。

一个可行的起点，是在可比预算下，对同一批交付物使用自动检查、模型裁判和结合多种证据的评分，再用独立人工评价与留出任务，检查哪种分数更能预测实际交付质量。

一份有用的 benchmark 应该让大家看清：这个系统做成了什么，有什么证据，能稳定做到几次，又花了多少成本。

这样，agent 下一次说“搞定了”的时候，我们就知道该去哪儿验收。