为什么 Agent 必须做 Evals

一句话理解：Agent 的输出是概率性的，执行路径是动态的。只有拿一套固定的评测集反复跑、用数据做比较，才能回答“它好不好、哪里不好、改完有没有变好”。

大多数团队优化 Agent 的方式是这样的：改一版 Prompt，挑三五个例子试试，“感觉好多了”，上线。一周后，另一类原本处理得好好的案例开始出错，没有人知道是哪次修改导致的。OpenAI 的评估最佳实践文档把这种做法称为 “vibe-based evals”，意思是凭“看起来能用”来判断，并明确列为应该避免的反模式。

验证模块解决的是“这一次运行做对了没有”。Evals 解决的是更上一层的问题：这个 Agent 在一类任务上整体表现如何，以及每次改动带来的是进步还是退步。

为什么传统测试不够用

软件工程里早就有单元测试和集成测试，为什么 Agent 还需要专门的 Evals？因为 Agent 打破了传统测试的几个前提：

维度	传统软件测试	Agent Evals
输出	同样的输入，同样的输出	同样的输入，每次输出可能不同
执行路径	代码写死	模型根据中间结果动态决定
判定方式	精确断言，例如结果等于 42	需要代码断言、模型评审、人工评审组合使用
运行次数	跑一次，通过就是通过	需要多次试验，看统计结果
失败原因	通常在代码里	可能在模型、指令、上下文、工具、数据或规则里
修好之后	通常不会自己再坏	模型升级、数据分布变化都可能让它退化

同一个问题跑 5 次，客服工单处理 Agent 可能走出 5 条不同的路径：

图 1 · 同一道题跑 5 次：路径不同，结论也不同，只试一次无法判断好坏

如果只试一次，你可能恰好看到第 1 次，得出“没问题”的结论；也可能恰好看到第 3 次，得出“完全不行”的结论。两者都不可靠。

这也引出了 Agent 评估中两个重要的指标。Anthropic 在工程文章《Demystifying evals for AI agents》中区分了：

pass@k：k 次尝试中至少有一次成功的概率。适合“允许多试几次、挑一个好的”的场景，例如 Coding Agent 生成多个方案。
pass^k：k 次尝试全部成功的概率。适合“用户每次都期待它靠谱”的场景，例如客服工单处理、财务审核。

pass^k 最早由 τ-bench 论文提出。随着 k 增大，两者会迅速拉开差距：假设单次成功率是 60%（示例），pass@3 约为 94%，而 pass^3 只有约 22%。对面向业务的 Agent，后者往往更接近用户的真实体验。

用单次成功率 60% 画出来，差距更直观：

图 2 · 同样的单次成功率，“至少一次成功”和“每次都成功”差距悬殊

Evals 要回答的三个问题

好不好？ 建立基线。例如在 100 个真实客服工单案例上，正确 87、错误 8、无法判断 5（示例数字）。
哪里不好？ 切片与归因。87% 是平均数，拆开看可能发现“企业客户退款”类案例只有 70% 正确；8 个错误可以归到工具错误、数据缺失、推理错误、规则错误几类。
改完有没有变好？ 回归比较。改了 Prompt 之后变成正确 90 个，但原来对的案例里有 4 个变错了，这 4 个必须逐条看。

没有 Evals，这三个问题只能靠感觉回答。

一套 Agent Evals 由什么组成

Anthropic 在上述文章中给出了一组术语，这里对应到客服工单场景：

术语	含义	客服工单处理 Agent 中的例子
任务（Task）	一道题：输入加上成功标准	“我付完款了，订单还显示未支付”，标准答案是支付回调失败
试验（Trial）	对一道题的一次运行	同一道题跑 3 次，得到 3 次试验
评分器（Grader）	给某个方面打分的逻辑，一道题可以有多个	检查结论字段的代码断言；评审处置建议的 LLM 评审
记录（Transcript）	一次试验的完整记录	所有工具调用、参数、返回、中间输出和最终回答
结果（Outcome）	试验结束时环境的最终状态	工单系统里是否真的按正确的分类更新了工单
评测 Harness	端到端运行评测的基础设施	并发运行任务、记录步骤、调用评分器、汇总结果的脚本或平台
评测套件（Suite）	针对某种能力或行为的一组任务	“支付类工单”套件、“安全与越权”套件

其中“记录”和“结果”的区别特别重要。文章举的例子是：订机票的 Agent 在对话里说“您的机票已预订”，但真正的结果是数据库里有没有这条预订记录。这和上一模块为什么必须验证是同一个道理。

整个流程串起来是这样：

图 3 · Agent Evals 全景：评测集 → 运行 → 评分 → 指标 → 归因 → 修改 → 回归，底部是离线与线上评估的支撑体系

能力评测与回归评测

同一文章还区分了两类评测，它们的目标完全不同：

类型	回答的问题	期望通过率	例子
能力评测	这个 Agent 能把什么做好？	起步时通常较低，用来衡量进步空间	一个工单里夹着多个问题、跨系统的责任归因
回归评测	它还能做好以前能做好的事吗？	应接近 100%，任何下降都是警报	已修复过的历史失败案例、常见工单类型

能力评测的题目被 Agent 做到接近满分后（文章称为“饱和”），就可以转成回归评测，同时再补充新的、更难的能力题。

什么时候开始做

答案是：越早越好，不必等到完美。 Anthropic 的建议是从 20–50 个来自真实失败的简单任务开始，把手工测试过的例子和用户反馈的问题直接转成测试用例。

对产品经理来说，还有一个常被忽视的好处：**写评测题的过程，就是在定义“什么叫做好”。**当你试图为“处置建议合理”写判定标准时，会被迫想清楚“合理”到底指什么。很多需求上的模糊，都是在写评测题时暴露出来的。这也是为什么 Agent PRD 要把 Evals 作为独立章节。

常见误区

等产品做完再做评测。 没有评测，开发过程中的每次修改都在“盲改”。评测集应该和第一版 Prompt 同时出现。
用公开基准分数代替自己的评测。 通用榜单说明模型的一般能力，说明不了它在你的工单数据、你的规则、你的工具上表现如何。
跑一次就下结论。 Agent 的输出有随机性。一次运行的差异可能只是噪声，需要多次试验和足够的样本。
评测集一成不变。 业务在变，线上出现的新失败类型要持续补进评测集，参见持续改进闭环。

产品经理检查清单

这个 Agent 现在有评测集吗？有多少道题？题目从哪里来？
每次修改 Prompt、工具或模型之后，是否会跑一遍评测并比较结果？
评测看的是“Agent 说了什么”，还是“环境里实际发生了什么”？
是否区分了能力评测和回归评测？回归评测是否要求接近全部通过？
对这个场景，用户更在意“至少一次做对”，还是“每次都做对”？
谁对评测集的质量负责？

练习

以实战项目中的「天气 Agent」或「订单售后诊断 Agent」为对象，用 30–60 分钟完成一次最小评测：

写 10 道题，每道题包含输入和明确的成功标准（例如“必须调用天气工具，回答中的温度与工具返回一致”）。
每道题运行 3 次，记录每次是否成功。
计算单次成功率，以及有多少道题 3 次全部成功（即这批题上的 pass^3 情况）。
挑出一道 3 次结果不一致的题，对比它的几次运行记录，写下你认为不一致的原因。

下一步

评测的一切都建立在题目之上。下一课「构建评测集」讲怎样从真实案例出发，出一套覆盖典型、边界与对抗样本的考卷。

为什么 Agent 必须做 Evals