Agent Eval 的核心对象：Task、Environment、Trajectory 与 Grader

系列：开源模型评测

来源公众号：智能大时代

发布时间：2026-09-10 22:24

原文链接：阅读公众号原文

如果说传统 LLM Eval 是在做“答题评分”，那么 Agent Eval 更像是在观察一个人进入真实工作环境后，能不能把事情做成。

比如给一个办公 Agent 一条指令：

根据 Alice 邮件中提供的 Q4 销售数据，更新季度预测表，并为本周五的 Review Meeting 创建会议草稿。更新时保留已有的历史实际数据；会议仅创建草稿，未经确认不要发送邀请。

这时候，我们就不能只盯着最终回复。Agent 可能说“任务已完成”，但真正重要的是：它读了哪封邮件？更新的是不是正确表格？有没有改坏公式？会议是否创建在正确时间？有没有越权发送邀请？

也就是说，一次 Agent Eval 关注的不只是“输入 → 输出”，而是一条完整链路：

Task + Environment         ↓    Agent Rollout         ↓     Trajectory         ↓       Outcome         ↓       Grader

理解这条链路，基本就理解了 Agent Eval 最重要的一组基础概念。

1. Task：到底让 Agent 做什么

Task 不应该只是一段自然语言 Prompt。一个真正可评测的任务，至少要回答四件事：

用户要求 Instruction、任务开始时的世界状态 Initial State、成功条件 Goal、不能违反的约束 Constraints。

对于上面的例子：

• • Instruction：根据邮件更新 forecast，并创建会议草稿；

• • Initial State：邮箱里有多封邮件，表格里已有 actual 和 forecast，日历里已有其他会议；

• • Goal：正确的 Q4 forecast 被更新，会议草稿被创建；

• • Constraints：不能覆盖历史 actual，不能邀请错误的人，不能未经确认直接发送。

这里要区分 Instruction 和 Goal：Instruction 是 Agent 收到的任务描述，Goal 是 Eval 系统判断任务是否完成的标准。

如果两者没有定义清楚，那么后面的 Grader 再精确，也可能只是在“精确地评错题”。

2. Environment：Agent 操作的“世界”

LLM 通常是在文本空间里回答问题，而 Agent 会操作一个有状态的环境。

这个环境可能是代码仓库、Linux 容器、浏览器，也可能是 Email、Calendar、Spreadsheet、CRM。

可以把 Environment 简化理解为四部分：E=(S,O,A,P)

S 是环境状态，O 是 Agent 能看到的 Observation，A 是允许执行的 Action 或 Tool，P 是动作之后状态如何变化。

例如，Agent 调用 update_cell() 后，表格状态发生变化；调用 create_event() 后，日历里多了一个会议对象。

这也是 Agent Eval 和普通 LLM Eval 最本质的区别之一：

传统 LLM Eval 更多关注模型生成了什么；Agent Eval 则进一步关注 Agent 实际做了什么，以及环境状态是否被正确改变。

换句话说，LLM Eval 更多是在评“说得对不对”，而 Agent Eval 还要进一步评“事情有没有真的做对”。

3. Trajectory：Agent 到底做了什么

Agent 执行任务时，会产生一条连续的行为轨迹，也就是不断重复“观察环境 → 执行动作 → 获得反馈”的过程。

例如下面是文章开头例子的一条 Trajectory：

搜索 Alice 的邮件 → 打开附件 → 读取 Q4 数据 → 找到 forecast 表格 → 更新数据 → 检查日历 → 创建 meeting draft

Trajectory 非常有价值，因为它能帮助我们分析 Agent 为什么失败、是否出现循环和无效步骤、是否调用了错误工具、是否发生越权，以及成本和延迟花在了哪里。

但是也要说明：

记录 Trajectory，不等于必须按照 Trajectory 评分。

同一个任务通常存在多条合法路径。不同模型、不同 Scaffold，甚至同一个 Agent 的不同 Rollout，都可能采用不同的工具和执行顺序。只要最终结果正确，并且没有违反过程约束，就不应该因为路径不同而判错。

一个实用原则是：

Outcome First，Process When Necessary。

默认优先检查结果 Outcome；只有当安全、权限、不可逆操作、成本或业务规则与过程有关时，才需要评过程 Process。

例如，最终会议虽然创建正确，但 Agent 中途曾把机密附件发送给外部邮箱，仅检查最终状态显然是不够的。

4. Verifier、Grader、Metric、Reward 到底有什么区别

这几个词经常混在一起，其实可以顺着一次 Eval 的数据流理解。

Verifier 负责验证具体事实，例如：

assert spreadsheet["Q4 Forecast"] == expected assert calendar.has_event("Q4 Review")

回答的是：“这个事实成立吗？”

Grader 是把多个 Verifier、规则或语义判断组合起来，对一次 Trial 给出评价，例如：

{  "goal_completed": true,  "actual_overwritten": false,  "unauthorized_send": false,  "pass": true }

它回答的是：“这次任务完成得怎么样？”

Metric 是我们希望量化的评测指标，例如成功率、平均成本、P95 延迟、权限违规率、Pass@k。它可以来自 Grader，也可以直接来自运行数据。

它回答的是：“我们用什么数字来描述系统表现？”

而 Reward 属于另一条链路。

当一个评价信号进入训练过程，用来推动模型改变策略，它就不再只是“测量工具”，而变成了“优化目标”。

Eval Grader 和 Training Reward 可以共享某些机制，但不能简单视为同一个东西。两者最大的区别不在于“是不是一个数字”，而在于系统是否开始主动优化这个信号。

一旦评价信号成为优化目标，就需要进一步警惕 Goodhart、reward hacking 等问题。

5. 一次失败，不一定是模型失败

Agent Eval 还有一个很重要的基础认识：

Fail ≠ Model Failure。

一次任务失败，可能来自很多层：

Model Scaffold Tool Environment Task Grader Infrastructure

例如 Agent 没有完成任务，可能是模型不会规划，也可能是 Tool Schema 写得含糊、环境发生异常、任务本身无解，甚至是 Grader 把正确结果判错了。

所以 Trajectory 不仅可以帮助我们“看 Agent 做了什么”，还可以帮助形成 Failure Attribution 的假设：到底是谁出了问题？

但仅仅查看 Trajectory，通常还不能完成真正的归因。要进一步判断问题究竟来自哪一层，还需要进行干预实验：例如固定模型更换 Scaffold、固定 Agent 更换 Tool 实现、重跑同一任务，或者用新的 Grader 对已有轨迹重新评分。

这样，我们就能把 Eval 从“给模型打分”，进一步升级成“定位系统瓶颈”。

结语

把一次 Agent Eval 拆开来看，其实并不复杂：

Task：要做什么 Environment：在哪个世界里做 Trajectory：具体做了什么 Outcome：世界最终变成了什么 Verifier：某个事实是否成立 Grader：这次任务完成得怎么样 Metric：用什么指标描述系统表现 Reward：如何把评价变成优化信号

Agent Eval 的核心，不是找一个更聪明的 Judge，而是建立一条完整、可信的证据链：

任务定义 → 环境执行 → 轨迹记录 → Outcome 检查 → Grader 评价 → Metric 汇总

当这条链路成立之后，我们才有基础继续讨论成功率、排行榜和模型比较，也才有可能进一步把 Eval 数据用于系统优化和模型后训练。