> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI 智能体的验证器
- URL: https://www.hubwiz.com/blog/ai-agent-s-verifier/
- Published: 2026-10-05T03:19:08.000Z
- Updated: 2026-10-05T03:19:08.000Z
- Description: 挑战不仅在于智能体是否成功，还在于我们能否可靠地验证它。
- Author: admin
- Tags: AGENT, #Import 2026-10-14 14:41

在我之前的博文中，我讨论了 AI 智能体如何被评测，以及 SWE-bench 等基准如何在真实软件工程任务上测试编码智能体。但这些评测系统还有另一个重要部分：**我们实际上如何判定智能体是否成功了？**

假设我们给智能体一个任务：

> ***"找到 Rahul 的最新邮件，并把它标记为重要。"***

智能体打开邮件应用，搜索 Rahul，选中一封邮件，标记为重要，最后说："完成。"

但智能体说*完成*并不能告诉我们任务是否真的被正确完成了。

仍然需要有东西去检查是否选中了正确的邮件，以及它的状态是否真的改变了。

这就是我们开始遇到诸如\*\*验证器（verifier）、评估器（evaluator）、评分器（grader）、裁判（judge）、奖励函数（reward function）和测试（test）\*\*这些术语的地方。

智能体评测研究中并没有统一的术语。不同的基准以不同方式实现这一评测层。

例如：

- OSWorld 使用基于执行的自定义评测脚本，从最终环境状态中提取信息，并评估任务目标是否达成。
- τ-bench 把智能体交互后的最终数据库状态与一个带标注的目标状态进行比较。
- SWE-bench 应用智能体的代码更改并执行测试，以判定原始软件问题是否已解决。
- 较新的计算机使用智能体研究还使用基于模型的验证器，它们可以检查来自智能体轨迹的更丰富证据。

因此，与其把**验证器**当作某一种特定技术，不如先思考它在智能体评测系统中扮演的角色：

**任务 → 智能体与环境交互 → 发生了什么的证据 → 评测/验证 → 成功、失败或分数**

那么有趣的问题就变成：

> **我们应该检查什么证据，才能知道智能体确实完成了任务？**

## 1、什么可以被验证？

答案取决于任务和环境。不同的基准关注智能体执行期间或执行后产生的不同证据。

### 1.1 环境的最终状态

对许多智能体任务来说，最强的证据不是智能体说了什么，而是**环境中实际发生了什么变化**。

再看邮件的例子。与其检查智能体是否回答了"完成"，评估器可以在执行后检查邮箱，看这封正确的邮件现在是否已被标记为重要。

这个想法出现在多个智能体基准中。

例如在 **OSWorld** 中，任务在真实计算机环境内执行。该基准使用 getter 函数在执行后从环境检索相关信息，并用 evaluator 函数把该信息与预期结果比较。

类似地，**τ-bench** 部分通过比较交互产生的最终数据库状态与任务的带标注目标状态，来评测使用工具的智能体。

概念上：

> **初始状态 → 智能体动作 → 最终状态 → 检查期望状态**

当成功会留下可以可靠检查的东西时，这种方式尤其有效：数据库记录被更新、文件被创建、邮件状态改变，或某个设置被修改。

### 1.2 可执行的行为

有时仅靠最终状态还不够。我们需要检查智能体创建的东西是否真的**能用**。

编码智能体评测就是一个好例子。

在 **SWE-bench** 中，智能体修改一个真实软件仓库来解决一个 GitHub issue。随后产生的补丁用测试来评估。该基准区分修复后应当开始通过的测试（`FAIL_TO_PASS`）和应当继续通过的既有测试（`PASS_TO_PASS`）。

所以评估可以不问：

> *"这个补丁看起来正确吗？"*

而是问：

> *"当我们真正运行软件测试时，这个补丁是否在不破坏预期既有行为的前提下解决了目标问题？"*

这里的证据来自**执行结果**，而不是只凭外观判断。

### 1.3 智能体的过程或轨迹

还有一些情况，只看最终结果会漏掉重要信息。

智能体可能在一路采取了不可取的动作后仍到达正确结果。它可能在自我纠正前与错误的对象交互、违反任务约束、执行不必要的风险动作，或使用它本不应使用的信息。

这就促成了对\*\*轨迹（trajectory）\*\*的评测：智能体工作时产生的观测序列、与推理相关的上下文、动作、工具调用、截图或其他交互记录。

微软近期关于计算机使用智能体验证的工作明确把**结果验证**与**过程验证**分开。它们的 Universal Verifier 既评估任务结果是否正确，也评估执行过程是否满足相关要求。

这给了我们另一个可能的证据来源：

**任务 → 观测 → 动作 → 观测 → 动作 → … → 结果**

评测不仅可以问\*"智能体是否到达了正确状态？"，还可以问"它到达那个状态的方式是否可接受？"\*

这些方法不一定是互斥的。单次评测可以结合多种形式的证据。

例如，评估器可能检查**最终环境状态**以确认任务成功，同时检查**轨迹**以确定重要约束是否被遵守。

这就引出下一个问题：

**这些证据实际上是如何被检查的？**

一旦知道有哪些证据可用，我们仍然需要某种机制来解读它。视任务而定，这可以从简单的确定性比较，到人类或基于模型的判断。

## 2、程序化检查

当成功可以被精确表达时，评测往往可以用代码完成。

例如，想象一个智能体被要求创建一个名为 `report.txt` 的文件。程序化检查可以简单地查看该文件是否存在于预期位置。

对数据库任务，它可以查询相关记录并把其值与预期状态比较。对编码任务，它可以执行测试。

这就是许多基于执行的评测背后的一般方法。例如 OSWorld 为相关应用状态可被检索和比较的任务定义了程序化的 getter 和 evaluator 函数。SWE-bench 针对智能体的仓库更改执行测试。

这些检查很有用，因为成功条件可以被明确表达并反复执行。

但并非每个任务都能归结为一次精确比较。

考虑：

> *"创建一个总结季度业绩的演示文稿，让它清晰而专业。"*

验证器可以检查演示文稿文件是否存在。它也可以尝试检查必需的文本或幻灯片是否在。

但\*\*"清晰而专业"\*\*很难表示成一条简单的布尔规则。

## 3、基于模型的评测

对于需要更多语义或视觉判断的任务，研究者越来越多地探索基于模型的评估器或验证器。

与其只检查一个精确值，可以把来自智能体执行的证据——例如截图、动作、任务指令或产出的工件——交给模型，并要求它判断要求是否被满足。

微软的 Universal Verifier 工作就是一个例子。它使用多模态模型评测计算机使用智能体的轨迹，并分别推理过程信息与结果信息。

这扩展了可被评测的任务类型，尤其是当成功无法轻易通过固定的数据库查询或断言来表示时。

然而，用另一个模型替换确定性检查引出了另一个问题：

**我们如何知道验证器的判断是正确的？**

## 4、人类评测

因此人类在智能体评测中仍然重要，尤其是当任务含糊、主观、难以用程序编码，或者评测机制本身需要验证时。

人类判断可以直接用来评测智能体行为，但也可以用来评测**自动化评测的质量**。

我们在 SWE-bench Verified 中看到过一个相关例子。专业开发者审查基准任务，以确定问题描述是否足够清晰、测试是否恰当地评估了潜在解决方案。

类似地，关于基于模型验证器的研究可以把验证器的判断与人类标注进行比较，以衡量验证器是否与人类评估一致。例如，微软的 CUAVerifierBench 就是为了评估验证器在计算机使用智能体轨迹上的表现而构建的。

所以人类、程序和模型并不必然代表三种相互竞争的方法。

在实践中，它们可以构成评测系统的不同层次：

**成功精确之处用程序化检查 → 需要解读之处用基于模型的判断 → 模糊案例与验证用人类评测**

这就带我们到一个重要的点：

**验证器本身就是一个评测系统——而评测系统也可能出错。**

## 5、谁来验证验证器？

验证器可能决定一个智能体通过还是失败，但这并不自动意味着验证器正确地代表了任务。

想象一个编码智能体给出了完全合理的修复，但测试套件期望一种非常特定的实现。即使它的方案有效，智能体也可能失败。

反过来也可能发生。测试可能太弱，让一个并没有完全解决底层问题的补丁通过。

这不只是理论。它出现在真实的基准开发中。

SWE-bench Verified 是在研究者和开发者审查了 SWE-bench 任务质量、发现涉及问题描述不充分以及测试无法可靠评估有效解决方案的情况之后创建的。因此专业开发者被引入评测过程来审查任务及其测试。

正如我上一篇关于 SWE-bench 演进的博文所讨论的，后来的审计持续在编码基准中发现评测问题。这个重要教训比 SWE-bench 本身更普遍：

**自动化评测的可靠性，不会超过它所检查条件的可靠性。**

当验证器本身是另一个 AI 模型时，这个问题变得更有趣。

基于模型的验证器可能误解任务、忽略证据、以不同于人类的方式解读含糊的指令，或做出错误的判断。

这就是为什么验证器研究越来越多地包含**对验证器本身的评测**。

例如，CUAVerifierBench 提供带人工标注的计算机使用智能体轨迹，用于评估验证器的预测。研究者现在不仅可以问智能体是否完成了任务，还可以问验证器是否正确识别了成功与失败的执行。

于是我们又得到一个评测循环：

**任务 → 智能体 → 证据 → 验证器 → 判断**

然后：

**验证器判断 ↔ 人类/参考判断**

第二次比较的质量，决定了我们应该对第一次比较有多少信心。

## 6、所以，什么是验证器？

审视完这些系统之后，把*验证器*这个词硬塞进一个狭窄的技术定义其实没什么用。

在智能体评测研究中，实现各不相同。验证可能涉及测试、数据库状态比较、环境状态检查、轨迹分析、基于模型的判断、人工审查，或它们的组合。

相对保持一致的是底层目的：

**我们需要证据，证明智能体确实做了任务所要求的事。**

随着智能体有能力在浏览器、计算机、代码库和外部工具上执行更长的动作序列，只评测它们最终的文本响应变得越来越不够。

挑战不再只是：

**智能体能完成任务吗？**

还包括：

**我们能可靠地验证它完成了吗？**

也许还有更难的问题：

**我们能验证自己的验证是正确的吗？**

---

原文链接: [What does a “Verifier” mean in AI agent evaluation?](https://medium.com/ai-safety-ethics/what-does-a-verifier-mean-in-ai-agent-evaluation-42b8b65e48c6?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处