基础概念

为什么 Agent Eval 不能只看分数：从静态 Benchmark 到可执行任务

2026年8月18日 · 约 10 分钟阅读

#agent-eval#benchmark#学习记录#HELM#AgentBench#SWE-bench#tau-bench

为什么 Agent Eval 不能只看分数：从静态 Benchmark 到可执行任务

本文把 Agent Eval 用作一个工作词：评估会调用工具、读取或改变环境状态并完成任务的 Agent system。刚开始读 Agent Eval 时，我以为它只是把传统 benchmark 的输入变长、输出从一段文字变成多轮对话。读完几份相关材料后，我发现这不够准确。

当评测对象从语言模型的一次输出，变成会调用工具、修改环境状态、生成代码补丁的 Agent 时，评测要回答三个问题：什么记录能作为评分依据，谁有资格判定成功，以及这个分数到底支持什么结论。

而从一篇较早的拓展阅读中，我又补上了另一半问题：就算一个分数解释正确，它也不会自动让系统变好。评测还需要把真实失败变成下一轮可以验证的改进。

术语约定：英文优先，中文解释角色

这些概念来自不同的论文和 framework，中文译法还没有形成稳定统一的规范。本文保留 English term，并在第一次出现时用中文解释它在本文中的角色；这样读者可以回到原始定义，也不会把相近的中文翻译误当成同一个概念。中文在这里负责解释，不给术语另造“标准名”。

先把六个对象拆开

术语这里指什么容易混淆成什么
System Under Evaluation (SUT)性能结论真正归属的系统，例如语言模型或完整 Agentresponse、trajectory 或某次运行日志
task environment持有 state、接受 action、发生 transition 并返回 observation 的任务世界runner、sandbox、scheduler 或全部基础设施
scoring evidence单次 trial 留下、可被检查的原始记录，例如 patch、test log、final stateoutcome、metric 或根因解释
oracle / verifier根据任务规则判定单次结果的准则或可执行实现所有 scorer、grader 的统称
evaluation protocoltask、调用方式、环境、工具、预算、oracle、重复和聚合等条件只是一份测试集
metric跨多个 trial 或 task 聚合 outcome 的可报告数值单次 reward 或 evidence

把这些对象分开，才能把“某系统得了多少分”读成合理的工程结论。

要点

分数不是一个独立事实。它是某个 SUT 在特定 evaluation protocol 下，留下特定 scoring evidence，再由特定 oracle 判定和聚合后的结果。脱离这些条件，分数的解释会被放大。

一个分数是怎样产生的

把这些材料放在一起，可以看到一条共同链路：SUT → task / environment → trial → scoring evidence → oracle → metric。每一层回答的不是同一个问题。把它们压成一个总分之后，很容易忘记这个分数由哪些条件共同产生。

先确认：系统在什么条件下被评

静态语言模型评测已经提醒我们，结果不能脱离调用条件来读。HELM 把 scenario（要评的 task、domain 和 language）、adaptation（如何调用通用语言模型，例如 few-shot prompting）和 metrics（如何量输出）分开。它关注的是如何在明确场景下观察语言模型输出。[1]

当 SUT 变成会行动的 Agent，条件里还多了一个 task environment。AgentBench 用 POMDP (S, A, T, R, U, O) 描述 LLM-as-Agent 的交互；其中 U 是 task instruction space，例如“查询并修改指定数据库记录”，它既不是 action，也不是 observation。Database environment 的 state 是底层数据库，action 是经 SQL 或 interface 发出的 operation，observation 是执行返回；Web Browsing 则以页面和 HTML 等作为可见 observation。[2]

这也划出一个容易被抹平的边界：HELM 的 scenario 不等于具有 state、action 和 observation 的 task environment；后者也不等于运行日志，更不自动包含 rollback、resume 或完整生产 runtime。它们服务于不同层级的结论。[1][2]

再看：一次 trial 留下了什么证据

以代码任务为例，SWE-bench 中从已合并 PR 提取的 patch 是 reference / gold solution；当前 SUT 真正被评估的产物是它针对 task 生成的 candidate patch。一次离线 trial 可以写成：[3]

problem_statement + repo@base_commit
→ candidate patch
→ apply patch
→ run tests
→ grading result

在这条链路里，candidate patch、apply / build / test logs 和 test result 都是 scoring evidence；可执行 tests 与 grading rule 才是该 task 的 oracle。因此它判定的是候选补丁能否在指定 repository state 和测试规则下通过，而不是 GitHub issue 是否关闭，更不是代码是否已经上线。[3]

τ-bench 把 evidence 和判定结果的区别写得更直接：single-trial reward 为 r = r_action × r_output。r_action = 1 要求 episode 结束时 final database 等于标注的 target database；r_output = 1 要求面向用户的回复包含任务要求的 necessary information。final state 和最终回复在这里都是 evidence，reward 则是 oracle 对这些 evidence 的判定结果。[4]

最后问：这个 oracle 究竟覆盖了什么

如果 τ-bench 的两项都为 1，该 trial 就在这套 rule-based oracle 下成功；但这不自动推出完整的 policy compliance。例如，Agent 没有取得用户明确确认就执行操作，final DB 和最终回复仍可能都正确。因此 r=1 对完整 policy compliance 是必要、但非充分的条件。[4]

这带来一个限制：分数可以严格、可执行、可复现，同时仍有覆盖盲区。完整地说，它表示的是：

在这组 task、这套调用和环境条件、这份 evidence、这个 oracle 与这条聚合规则下，该 SUT 得到了这个结果。

分数当然有价值，但不能顺手延伸成“模型已经可靠”“Agent 理解了业务”或“系统可以直接上线”。这些额外结论要有对应的 task、证据与验证规则；它们不会从一个总分里自动长出来。

结果可解释，还不等于系统会学习

这条链路解决的是结果可解释性：先界定 SUT，固定 task 和环境，保存 evidence，明确 oracle，再谈 metric。否则数字即使可复现，也可能被错误地解释为模型能力、产品可靠性或 policy compliance。[1][2][3][4]

拓展阅读讨论的是另一层：失败学习闭环。对于实际运行的 Agent，评测不应只在上线前给一次判定；一次可能改变失败分布的重要改动之后，团队要能从 trace 中复核具体 case，理解失败，再决定下一轮验证什么。[5]

这个闭环可以写成六步：

  1. 一次会改变系统行为的重要改动发生，例如模型、prompt、检索、工具链或业务规则变化。
  2. 从生产或准生产的 trace 中抽取有代表性的 case。
  3. 由理解业务质量标准的人 review 完整会话，先判断任务是否达成，再记录最早的上游失败点。
  4. 把零散观察逐渐整理成 failure taxonomy，而不是停留在“这个回答感觉不对”。
  5. 将高优先级、可定义的失败转成具体的 rule-based eval、人工 rubric 或 regression case。
  6. 下一次重要改动后，用更新后的数据和规则重新验证。

这里同样有一条边界：trace 是复核失败的证据，不是对根因的自动证明；failure taxonomy 是工作中的分类决策，不是天然的客观真相。正因为如此，人工的领域判断和可追溯 evidence 都不能省略。[5]

把两层工作接起来，第一层防止误读分数，第二层避免把评测做成一次性的验收。对我来说，Agent Eval 包括一条持续更新的链路：task → trial → evidence → oracle → failure analysis → regression。

四个agent eval工作动作

  1. 看到结果前，先问 SUT 是谁。模型、agent harness 和完整 Agent system 的结论不能随意互换。[1][2]
  2. 看到“通过”前，先找 evidence 和 oracle。尤其在代码任务中，reference patch、candidate patch、tests 与 logs 不是一回事。[3][4]
  3. 看到环境前，先问它是不是 task environment。它不天然包含 runner、sandbox、scheduler，更不自动证明生产可靠性。[2]
  4. 看到一个失败 case 后，不急着把它变成总分变化；先保留 trace、确认失败点，再判断它是否值得成为长期 regression case。[5]

我把这个边界带进了 VeriRun 的 M0/M1：先确认 candidate、verifier、manifest 和 replay 的关系能被复查。M0/M1 解决的是可复放 protocol 与有界执行的一部分问题；它们不等于已经完成上述生产 trace、人工 review 与 regression 的完整闭环。

下一篇工程文章会展开什么

这些材料给我一套先拆对象、再谈结论的起点。下一篇我会把问题推进到可复放的 Code Eval protocol：当 dataset、candidate、verifier 或运行环境变动时，哪一项变化足以让两个分数不再可以直接比较？

先读清楚分数产生的条件，再讨论分数高低。

参考资料

  1. HELM: Holistic Evaluation of Language Models
  2. AgentBench: Evaluating LLMs as Agents
  3. SWE-bench Overview 与 SWE-bench paper
  4. τ-bench: A Benchmark for Tool-Agent-User Interaction
  5. 拓展阅读：What’s a Minimum Viable Evaluation Setup?