评测智能体与能力

智能体不只会生成回答。它会观察环境、选择动作、调用工具并改变状态。因此，评测智能体不能只读它的最终消息。评测必须在受控环境中运行完整系统，并检查实际发生了什么。

这个区别很容易被忽略。智能体可能声称已经退款，但客户数据库没有任何变化；也可能读取秘密测试文件后提交一个能通过测试的补丁；还可能跳过政策要求的身份核验，直接打开正确页面。最终消息只能证明智能体声称自己做了什么。环境状态和保留下来的动作日志，才是它实际做过什么的证据。

可靠的评测遵循一条原则：

评测有版本的系统，核验最终状态，只在任务确有真正的流程约束时检查轨迹。

从回合回报到工具型智能体

这个测量问题早于语言模型。强化学习把智能体形式化为一项策略：策略在一个回合内与环境交互，并用交互产生的奖励衡量表现 (Sutton and Barto 2018)。现代语言模型智能体保留了这种回合式交互，却把紧凑的模拟器换成了浏览器、代码仓库、数据库、API 和人类对话。难点不再只是收集一个数值奖励，而是规定什么现实状态才算成功、恢复可重复的初始状态，并区分智能体出错与工具或评测器故障。

智能体基准把这种转变具体化了。AgentBench 汇集了多种交互式环境 (Liu et al. 2024)；WebArena 使用自托管网站和功能性任务检查 (Zhou et al. 2024)；SWE-bench 要求系统修改代码仓库，使针对具体问题的测试框架通过 (Jimenez et al. 2024)；OSWorld 配置真实桌面状态，并评测 GUI 操作结束后留下的状态 (Xie et al. 2024)；GAIA 则提出简短答案的问题，但求解过程可能需要浏览网页、处理文件、编写代码或进行多模态推理 (Mialon et al. 2024)。这些基准测量的不是一种可以互换的量，而是展示了几种把交互转化为可核查证据的方法。

定义受测系统

智能体分数属于一套配置，而不只属于模型权重。配置至少包括：

• 模型版本、服务路由、解码设置和推理预算；
• 系统提示、工具说明、编排循环和上下文政策；
• 工具实现、凭据、权限和网络政策；
• 沙箱镜像、依赖版本、初始数据和重置流程；
• 任务、可能存在的模拟用户、时间或轮数预算，以及评分器版本。

前两组构成模型及其 第 41 章，其余配置决定系统能够观察和改变什么。即使模型没有变化，新的提示、浏览器控制器、上下文压缩器或超时设置也可能改变分数。因此，这类结果应报告为系统结果。只有其余配置保持不变时，模型比较才有依据；即便如此，固定的运行框架也可能偏向某个模型的 API 约定。Harness-Bench 对模型与运行框架的配对进行了受控实验，说明配置才是站得住的报告单位，任何单独组件都不是 (Yao et al. 2026)。

一份实用的任务契约会把评测条件写成可执行记录：

AgentTask:
  task_id, task_revision, source, slice_labels
  initial_state_fixture, reset_check
  user_request, available_tools, permissions
  hard_process_constraints
  terminal_conditions, step_limit, time_limit
  outcome_assertions, partial_credit_rubric
  grader_revision, grader_test_manifest

AgentRun:
  task_id, system_spec_hash, attempt, seed
  initial_state_hash, observation_action_log
  final_state_hash, terminal_reason
  outcome_assertion_results, constraint_results
  partial_score, cost, latency
  infrastructure_status, artifact_locations

这份记录把任务定义与一次随机尝试分开，也能防止环境或评分器的无声变化被误报成模型进步。

模拟用户也是测量工具的一部分，不是中立背景。它的模型、提示、人设、可用信息和停止行为都会改变对话，进而改变分数。固定这些选择，同时采样接近生产环境的变化；在把结果当作人机交互证据之前，还应抽取一部分模拟交互，与具有代表性的人类用户比较。

分开评测状态与约束

设任务 $i$ 的一次运行产生轨迹

$$\tau_{ir}=(s_0,o_0,a_1,o_1,\ldots,a_T,s_T).$$

其中，$i$ 表示任务，$r$ 表示一次重复尝试，$s_0$ 和 $s_T$ 是环境的初始状态和最终状态，$o_t$ 是第 $t$ 步可用的观测，$a_t$ 是看到该观测后选择的动作，$T$ 是运行终止时的步数。智能体未必能看到完整状态；但评测器声称核验某项状态时，该状态就必须对评测器可见。

定义 $G_i(s_0,s_T)\in\{0,1\}$ 为任务的结果检查。对于退款任务，它可以核验数据库中新增的记录、退款金额和预期账户余额。再用 $C_{ij}(\tau_{ir})\in\{0,1\}$ 检查第 $j$ 项硬性流程约束，例如是否先取得授权再执行退款。如果任务 $i$ 有 $J_i$ 项硬性约束，则达到要求的成功为

$$Y_{ir}=G_i(s_0,s_T)\prod_{j=1}^{J_i} C_{ij}(\tau_{ir}).$$

其中，只有结果和所有硬性约束都通过时，$Y_{ir}$ 才等于 1。当 $J_i=0$ 时，空乘积为 1，成功与否只取决于结果。这个定义不要求智能体遵循作者偏好的路线。它检查最终状态，也只检查真正属于任务要求的中间事实。

两类信号的区别很重要：

结果检查通常应独立于智能体的输出通道。可以用评测器自己的凭据读取数据库，从干净的代码检出中运行测试，或查询浏览器后端。若只有模型评判者能评估工件，就应遵循 第 50 章 的验证与确认规范。一个模型用不同提示给另一个模型评分，不能因此成为独立的状态检查。

让每项任务有效且可重置

能运行的任务不一定是有效的任务。正式使用前，需要核查四件事。

第一，任务必须能够用给定信息和权限完成。在可行的情况下，让胜任的人类从相同初始状态出发，在相同政策和预算下完成任务。第二，结果检查必须接受参考路径之外的有效做法。测试应描述必要行为，而不是复现原开发者的补丁。第三，已知错误方案必须失败。可以植入错误账户的退款、不完整补丁、禁止动作，以及表面正确的最终消息。第四，重置必须恢复下一次运行能够观察到的所有状态，包括数据库记录、文件、浏览器会话、依赖时钟的数据、速率限制和缓存。

SWE-bench 提供了一个值得重视的警示。原始任务把真实问题与代码仓库测试配对，但后来的专业审查发现，一些问题描述不充分，或使用了不合适的测试，因此整理出 500 个案例的 Verified 子集 (OpenAI 2024)。再后来的审计仍在经常失败的 Verified 案例中发现了实质性问题 (OpenAI 2026)。这并不说明可执行评分的思路有错，而是说明评分器也是软件，需要测试、版本管理和持续审查，标准应与其他关键组件相同。

长任务往往需要部分得分，但准则必须描述可观察的工作。PaperBench 把研究复现拆成分层、可评分的要求，并单独评估其自动评分器 (Starace et al. 2025)。这种做法也适用于研究之外：保留端到端二元完成率，增加组件得分来辅助诊断，并验证组件评分器。不能用更容易计算的里程碑平均分取代困难的端到端结果。

区分智能体失败与评测失败

每次运行都应记录终止原因，而不只是记一个零分。实用的分类如下：

• **成功：**结果和所有硬性约束均通过；
• **智能体失败：**评测设施正常，但智能体主动停止、超时、执行禁止动作，或留下错误状态；
• **运行框架兼容性失败：**所选模型无法按当前配置使用运行框架或工具协议；
• **环境失败：**服务、依赖、网络路由或重置机制发生故障，且故障并非由智能体的决策引起；
• **评分器失败：**运行已经结束，但评测器崩溃、无法读取状态，或不能给出确定结论。

这些类别对应不同决策。智能体失败应计入受测系统的失败。环境失败和评分器失败通常使尝试无效，应在修复后重跑，并报告这两类故障的比例。兼容性失败属于系统配置，不能悄悄删掉；它说明这套模型与运行框架的组合无法按部署方式完成任务。

必须预先声明处理政策。否则，团队可能在读过轨迹后，把表现不佳的运行改称基础设施问题，从而抬高分数。保留能够证明每次排除合理的服务日志和健康探针。昂贵的批量评测开始前先运行廉价的冒烟任务；重置检查或金丝雀断言失败时终止整批评测。

一次尝试不代表可靠性

智能体既有随机性，又会与环境交互。同一配置在每次尝试中都可能选择不同路径，模拟用户或可变服务还会引入更多变化。令

$$p_i=\Pr_R(Y_{ir}=1)$$

表示任务 $i$ 在声明的运行分布 $R$ 下达到要求的成功概率。其中，$Y_{ir}$ 是前文定义的二元结果，$R$ 包括解码、用户、工具和环境条件中接近生产场景的随机性。在每次尝试相互独立且成功概率同为 $p_i$ 时，

$$\operatorname{pass@}k_i = 1-(1-p_i)^k.$$

$$\operatorname{pass}^k_i = p_i^k.$$

第一个量是 至少一次成功率（pass@k），表示 $k$ 次尝试中至少一次成功的概率，回答允许重试时系统能否成功。第二个量表示所有 $k$ 次尝试都成功的概率，用来衡量重复可靠性。$k$ 是尝试次数；这两个指标都不会凭空增加新任务。$\tau$-bench 在评测动态对话中的工具型智能体时引入了 pass$^k$，并把最终数据库状态与标注目标进行核对 (Yao et al. 2025)。

设定单次尝试的成功概率，就能直观看到这两个问题如何分化。

import numpy as np
import matplotlib.pyplot as plt

p = 0.6
k = np.arange(1, 11)
at_least_one = 1 - (1 - p) ** k
every_attempt = p ** k

plt.figure(figsize=(5, 3))
plt.plot(k, at_least_one, "o-", label="pass@k：至少一次成功")
plt.plot(k, every_attempt, "s-", label="pass^k：每次都成功")
plt.xlabel("尝试次数 k")
plt.ylabel("概率")
plt.ylim(0, 1)
plt.legend()
plt.tight_layout()
plt.show()

上述闭式公式假设各次尝试独立同分布，而且 $p_i$ 已知。真实评测通常只能通过少量重复来估计 $p_i$，共享服务或用户模拟器还可能让失败彼此相关。若任务 $i$ 有 $n$ 次有效尝试，其中观测到 $c_i$ 次成功，下面第一个有限样本公式估计至少一次成功的概率，第二个估计连续 $k$ 次成功的概率。这也是 $\tau$-bench 使用的逐任务估计量。

$$\widehat{\operatorname{pass@}k}_i =1-\frac{\binom{n-c_i}{k}}{\binom{n}{k}}.$$

$$\widehat{\operatorname{pass}^k}_i =\frac{\binom{c_i}{k}}{\binom{n}{k}}, \quad k\le n.$$

这里，$\binom{a}{k}$ 表示从 $a$ 次尝试中选出 $k$ 次的子集数量。汇总时，应按测试套件声明的任务权重对逐任务估计取平均。让重复尝试嵌套在任务内，报告有效尝试次数，并采用 第 48 章 介绍的配对方法和聚类感知方法。如果任务的成功概率不同，就不能把整个测试套件的汇总准确率直接取 $k$ 次方来计算 pass$^k$。

任务长度也会改变可靠性。步骤越多，工具、规划、上下文和恢复发生故障的机会就越多。因此，测试套件应按有意义的长度或难度切片报告成功率，避免许多短任务掩盖长任务上的崩溃。不过，长度本身并不是因果解释，因为工具质量、可观测性和任务构成也可能随长度变化。

用轨迹诊断，而不是事后编故事

结果评分完成后，轨迹可以帮助定位系统在哪一步失败。应保存观测、工具请求与响应、改变状态的事件、模型用量、终止原因和评分器证据，再套用固定的失败分类，例如感知、规划、工具选择、无效参数、政策违规、状态核验或恢复失败。

不能只凭最终结果指定根因。退款缺失可能源于规划错误、API 拒绝、凭据过期，也可能是评分器读错了数据库。抽样失败案例交给独立人员裁决，允许标注多个共同原因，衡量标签一致性，并把确认过的评测器缺陷变成回归测试。轨迹的用途是改进系统及其测量方法，不是用有说服力的事后解释挽救偏好的分数。

运行契约

一套达到发布标准的智能体评测，可以归纳为九项承诺：

1. 说明要支持的部署决策和目标任务群体。
2. 把模型、运行框架、工具、权限、环境、预算、用户模拟器和评分器作为一份系统规范统一版本管理。
3. 证明每项任务都能完成，并确认重置会恢复经过检查的初始状态。
4. 从环境状态核验完成情况；轨迹只用于检查已声明的约束和诊断问题。
5. 用已知成功、已知失败和对抗性近似案例测试评分器。
6. 预先声明终止原因、无效运行的处理办法、重试规则和部分得分方式。
7. 对随机任务做重复尝试，同时报告能力指标和可靠性指标，并附上分母与不确定性。
8. 保留每次运行的工件，使每个汇总结果都能重建。
9. 保留锁定的确认测试套件，并遵循 第 53 章，把验证过的生产故障带回回归案例。

延伸阅读