Agent Eval：AI开始替人办事，答案正确只是最表面的一层
系列中讲 Agent 评测的一篇。Agent 和传统问答的本质区别是「过程比结果长」——答案对了不代表事情办对了。这篇的 Outcome→Trace→Output 判断顺序是精华。
核心内容速览
- 五个核心概念：Task（任务）、Case（用例）、Trial（一次运行，Agent 有随机性所以同 Case 要跑多次）、Trace（完整执行轨迹）、Harness（运行与判分的环境）。
- 判断顺序：Outcome → Trace → Output：先看最终状态对不对（文件真的改了吗、订单真的提交了吗），再看过程是否合理（有没有瞎调工具、兜圈子），最后才看输出了什么文字。
- 结果可验的优先用状态检查：数据库状态、文件内容、API 调用记录比「让用户觉得满意」可靠得多。
- 过程评估的价值在定位失败：Trace 分析告诉你失败发生在规划、检索、工具调用还是汇总环节，直接指向该改的组件。
适合谁 · 怎么用
做 Agent / 工作流类产品的人必读。配合 a06（Anthropic 长文）一起读，一中一洋正好互相印证。
闯关自测
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
Q1 Agent 评估的判断顺序是什么？为什么？
Outcome → Trace → Output。先看最终状态（事情真的办成了吗），再看过程轨迹（有没有瞎调工具、兜圈子），最后才看输出了什么文字——文字最容易伪装。
Q2 Task / Case / Trial / Trace / Harness 分别指什么？
Task 任务类型；Case 具体用例；Trial 一次运行（Agent 有随机性，同 Case 要跑多次）；Trace 完整执行轨迹；Harness 运行与判分的环境。
Q3 Agent 评测中「结果可验」优先用什么方式？
状态检查：数据库记录、文件内容、API 调用日志。比「让用户判断满不满意」可靠得多。
以下为原文全文
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
让 AI 回答问题，评测一段答案通常就够了。但当 AI 开始替人办事，答案正确只是最表面的一层：研究 Agent 可能引用了错误资料，编程 Agent 可能改了文件却没通过测试，日程 Agent 可能回复「会议已创建」，后台却什么都没有发生。真正需要验证的是：它有没有在真实约束下，把事情完整、正确、安全地办成。
一、评什么：从回答扩展到一次完整运行
员工只说了一句话：「帮我约王琳下周二下午开一个 30 分钟的复盘会。」要完成它，Agent 至少经历四步：识别是哪位王琳，查询双方忙闲，创建会议，确认会议和邀请确实落地。真实环境不会永远配合：通讯录里可能有两位王琳，双方可能没有共同空档，目标会议可能已存在，创建接口还可能超时。
因此一次运行不能只看最终回复，至少要回答三个问题：① 结果：日历里最终有没有正确的会议？② 过程：Agent 查了什么、调用了什么、遇到异常后做了什么？③ 交付：它告诉用户的，是否与真实结果一致？
一个负责办事，一个负责验收
Agent Harness（办事系统）：接收请求 → 查询状态 → 执行动作 → 确认结果 Eval Harness（验收系统）：准备现场 → 发起运行 → 保存证据 → 判定结果
Agent Harness 是让 Agent 运行的软件底座（模型、系统提示词、工具、权限、上下文和重试策略），不是测试专用组件。Eval Harness 是外部测试系统，负责准备环境、发起测试、保存证据和执行判定，但不代替 Agent 查人、选时间或处理异常。
可以把它理解成驾考：Agent 在车里完成任务，Agent Harness 提供操控车辆的条件；Eval Harness 负责布置考场、发出任务、记录过程并判定是否通过。Agent Harness 负责把事办成，Eval Harness 负责证明它是否办成。
Agent 负责完成任务，Eval 负责证明任务是否完成
二、怎么测：把真实任务变成可重复的 Case
| 组成 | 日程案例中的内容 | 作用 |
|---|---|---|
| Task Instruction | 帮我约王琳下周二下午开会 | 告诉 Agent 要完成什么 |
| Environment Fixture | 测试通讯录、忙闲状态、权限、接口响应 | 还原这次任务发生的现场 |
| Grader | 检查会议、邀请、错邀和回复 | 决定如何验收 |
三部分合在一起，就是一条可反复运行的 Eval Case。每实际运行一次 Case，就产生一条 Trial。同一条 Case 可交给不同版本运行，也可连续运行多次，用于比较版本差异和结果稳定性。
用户任务 + 模拟现场 + 验收规则 = 一条 Eval Case；让某个 Agent 版本实际执行一次 Case = 一条 Trial。
同一句请求，为什么需要多条 Case
| 测试现场 | 重点验证什么 |
|---|---|
| 人员唯一、时间可用 | 能否正常创建会议 |
| 存在两位王琳 | 能否先确认身份，而不是猜 |
| 双方没有共同空档 | 能否说明冲突并提出下一步 |
| 目标会议已经存在 | 能否避免重复创建 |
| 创建接口返回超时 | 能否查询最终状态，再决定是否重试 |
| 当前用户没有权限 | 能否停止操作并准确说明 |
Task Bank 不需要穷举所有工具组合，而要围绕高频任务、关键分支和高后果风险建立代表性场景。对一个任务族，先准备 1 条正常路径和 3—5 条关键异常，通常已能暴露大量问题。
三、怎么判：用三层证据还原一次运行
运行「创建接口超时」这条 Case，运行记录如下：
{
"case_id": "calendar_create_timeout",
"output": "已安排下周二 15:00 的复盘会并发出邀请。",
"trace": [
{"tool": "resolve_person", "status": "ok"},
{"tool": "get_freebusy", "status": "ok"},
{"tool": "create_event", "status": "timeout"}
],
"outcome": {"target_event_count": 0, "invite_sent": false}
}
- Output 是用户看到的回复：Agent 宣称会议已创建；
- Trace 是执行记录：创建接口超时，之后没有再次查询；
- Outcome 是最终状态：评测系统独立检查后发现会议不存在，邀请也没发出。
timeout 本身不等于创建失败，它只代表调用方不知道结果。真正的问题是：Agent 没有回查，却把未知状态说成了成功。这条 Trial 同时暴露两个缺陷：执行闭环没完成，面向用户的回复也不真实。
先用 Outcome 判成败，再用 Trace 找原因
| 检查对象 | 回答的问题 | 本次结论 |
|---|---|---|
| Outcome | 事情最终办成了吗 | 没有，会议不存在 |
| Trace | 为什么成功或失败 | 超时后没有核验 |
| Output | 是否如实告知用户 | 没有，把未知说成成功 |
先看 Outcome，避免「过程看起来很努力」掩盖任务失败；再看 Trace，定位该修 Prompt、工具、权限还是工作流；最后核对 Output，防止系统做错了却说成功。过程评测不应机械要求唯一的工具顺序——Trace 更适合检查三类关键路标：必须发生的核验、绝不能发生的危险动作、异常出现后是否采取了正确措施。
四、怎么落地：从一条 Case 建立 Task Bank
第一次落地不需要先建庞大平台。选一个高频任务族，五步开始：
- 从真实日志或业务流程中选一个重要任务；
- 写成一句自然的用户请求；
- 准备 1 个正常现场和 3—5 个关键异常；
- 为每个现场定义最终状态、红线和必要证据；
- 用真实 Agent Harness 运行，并保存 Output、Trace 和 Outcome。
真实任务与已知风险 → 建立首批 Case → 上线前反复回归 → 从线上 Trace 发现新失败 → 脱敏并复现为新 Case → Task Bank 持续生长
到这里，Agent Eval 的结构就完整了：Task 说明要办什么，Fixture 还原任务现场，Case 保存可重复的测试，Trial 记录一次真实尝试，Output、Trace 和 Outcome 共同回答「有没有办成，以及为什么」。
但 Agent 具有随机性。同一条 Case 这次成功，不代表下次也成功——一条 Case 要跑多少次、怎样比较两个版本，才能相信改进不是偶然？这是下一步要解决的统计问题。