Agent 评测到底在测什么：说「订好了」不算数

Agent 评测到底在测什么：说「订好了」不算数

评测（eval）说穿了就是一句话：给 AI 一个输入，再拿一套打分逻辑去核它的输出。单轮模型时代，一个提示词、一个回答、一条打分规则就够了。Agent 把这件事变难了：它会跨很多轮调用工具、改环境里的状态、根据中间结果改变下一步。错误会顺着轨迹一层层传下去。

这篇讲清楚「测 agent 时到底测什么」，观点整理自 Anthropic 2026 年 1 月 9 日的工程博客 Demystifying evals for AI agents，并链接回原文。本文是我们自己的中文笔记，不是全文翻译。

先分清两个东西：轨迹，和结果

原文给了一组定义，值得逐个记住，因为日常讨论里经常把它们混在一起：

• 任务（task）：一道有输入、有成功标准的题。
• 尝试（trial）：这道题跑了一遍。因为模型输出每次都有波动，同一道题要多跑几遍，结果才稳。
• 打分器（grader）：对表现打分的逻辑。一道题可以挂多个打分器，每个里面可以有多条断言。
• 轨迹（transcript）：这一次尝试的完整记录——输出、工具调用、推理、中间结果全在里面。
• 结果（outcome）：环境在尝试结束时的最终状态。

关键就在最后两条的区别。原文的例子很直白：订票 agent 在轨迹的最后可能说「您的航班已订好」，但结果是环境的 SQL 数据库里到底有没有这条预订记录。它说的和它做的是两回事，打分要打在后者上。

这一条对任何会调工具的 agent 都成立。说「已提交工单」，就去工单系统里查有没有那张单；说「测试全绿」，就去跑一遍测试看退出码。轨迹可以拿来看它为什么错，但不能拿来宣布成功。

评「一个 agent」时，你评的其实是两样东西

原文把 agent harness（脚手架）和模型分开说：harness 是处理输入、编排工具调用、返回结果的那套系统；评测「一个 agent」，评的是 harness 和模型一起工作的表现。

这个区分很实际。同一道题分数掉了，原因可能是模型换了，也可能是 harness 里的提示词、工具定义、上下文管理变了。评测基础设施（evaluation harness）跑题、录轨迹、打分、汇总，把这三样分开记录，你才能定位是哪一层的问题。

为什么静态题会「误伤」好答案

前沿模型有时能找到超出题目设计的解法。原文举的例子：Opus 4.5 在 τ²-bench 的订票题里发现了政策里的一个空子，按题目原文判是「失败」，但它实际给了用户一个更好的方案。

这不是让你把评测写得更严，而是提醒你：失败样本要人工看，不能只看红绿。判「失败」之前先问一句，是 agent 真错了，还是你的题把合法解判成了违规。题集是静态的，模型不是。

评测什么时候开始值得建

原文给的路径很务实：起步阶段靠手工测试、内部试用和直觉，能走得很远。到了产品上线、用户变多，没有评测就开始崩。崩点是用户说「改完之后感觉变差了」，而团队除了猜没有别的验证手段——分不清真回归和噪声，改一处怕碰坏另一处。

评测的复利在于：任务集固定之后，延迟、token 用量、每任务成本、错误率都有基线可追。出新模型时，有评测的团队几天就能决定要不要换；没评测的要人肉测几周。

两个客户的做法可以当参照。Descript 把成功标准收成三条：别弄坏、按我说的做、做得好；从人工打分走到 LLM 打分加定期人工校准。Bolt 起步晚，三个月搭起静态分析、浏览器 agent 测应用、LLM 评审指令跟随的系统。什么时候建都行，但题集越早存在，团队对「什么算成功」的分歧就越早被消灭。

落到你的项目上，四步

1. 写十道题。每题写清输入、允许调的工具、以及环境里什么状态算成功——不是「回答里出现了什么词」。
2. 每题挂打分器，能确定性判定的（文件存在、退出码、数据库行）优先于 LLM 评审。
3. 同一题多跑几遍，波动本身就是信息。
4. 失败的题先人工看轨迹再归类，别急着加题。

材料边界

观点来自 Anthropic 2026-01-09 的工程博客，链接见开头。本文为中文笔记，非翻译，未复制原文段落与配图，图中文字为本篇自己绘制。原文还引用了 Descript、Bolt 的客户案例，细节以原文为准。