AI evals 是给模型或 agent 的行为打分的测试。本文讲 agent evals 与 LLM evals 的区别、三种评分器类型，以及如何用 7 个步骤写一个 eval。

AI eval 是针对 AI 系统的一种测试：你给它一个输入，让它运行，然后给它的行为打分——可以用代码打分、用另一个模型打分，或者由人来打分。LLM evals 评的是单次回复。AI agent 的 evals 评的是整次运行：agent 调用了哪些工具、传了什么参数、留下了什么状态，以及最终给出了什么回复。这个差别决定了 eval 该怎么写，因为 agent 完全可以在从未调用退款工具的情况下回复「您的退款已在路上」，而只读回复的 eval 会把这次运行判为通过。

本指南定义 eval 的各个组成部分，解释 agent evals 与 LLM evals 的区别，介绍三种评分器，然后用七个步骤带你为 agent 写一个 eval，并给出一个可以照搬修改的完整示例。

Anthropic 的 agent evals 指南（Demystifying evals for AI agents ↗，2026 年 1 月）使用了一套多数 eval 工具现在通用的术语。这套术语值得采用，因为「eval 失败了」可能指下面任何一种情况：

一个任务可以有多个评分器，而且通常应该有多个。一个检查退款是否真的存在，一个检查是否先查了政策，一个检查回复是否解释了时间线——它们会因不同的原因失败，而你需要知道是哪一个。

这些术语有重叠，常被混用，但它们评的是不同的东西。

实际后果是：agent 最严重的退化读起来却像是对的。一个不再调用 notify_security_team 的模型，或者报告了一次它从未做过的地址变更的模型，照样能写出流畅、切题的文本。所有只评文本的 eval 都会让它通过。

切换 LLM 时到底哪些地方会出问题，请参阅完整的变更面。

每个 eval 评分器都属于三种之一，好的套件会针对不同工作把三种都用上。

顺序很重要。凡是代码能检查的，就用代码；剩下的散文质量用模型评；人来写评判标准、标注校准样本、阅读失败案例。

LLM-as-a-judge 深入讲解了模型评分器，包括评判器的准确度如何，以及如何验证一个评判器。

Evals 回答的是两个问题之一，把两者混在一起会让数字很难解读。

agent 能稳定通过的能力任务会毕业进入回归套件。大多数基于模型供应商构建的团队，在回归上投入的 eval 精力比他们预想的多，因为变化最频繁的不是他们的代码：模型升级、更换供应商、被弃用且有退役日期的模型。

同一个 agent 在同一个任务上跑五次，可能得到五条不同的 trace。每个任务只跑一次，测到的运气和测到的行为一样多。有两个指标描述这种离散程度：

差距很大。在 τ-bench（一个评测 agent 在书面政策下服务模拟零售和航空客户的基准）中，带 function calling 的 GPT-4o 单次试验约解决 61% 的零售任务，而它的 pass^8（八次试验全部解决同一任务）降到约 25%（Yao et al., 2024 ↗）。一个单次试验成功率 75% 的 agent，连续三次都通过的概率只有 42%（0.75³）。

下面七个步骤带你从零走到一个可以用于发布门禁的套件。这些步骤假设 agent 已在生产环境或接近生产环境。如果你还在做原型，先做第 1 步，到第 4 步为止。

不要从想象测试用例开始。先从已经出错的 20 到 50 个案例开始：bug 报告、支持升级、有人标记过的对话记录。Anthropic 的指南给出了同样的建议，因为在早期，你做的改动影响很大，一个小套件就能检测出来。

然后加入真实流量。手写用例覆盖的是你已经想到的情况；生产日志里则有你没想到的。抽样 100 到 300 条输入，按路由或意图分层，以免一个罕见但昂贵的路由被淹没，剥离个人数据，并去掉近似重复项。

从生产流量构建黄金 eval 套件 讲了如何捕获这些运行，需要多少个 eval 用例 讲了如何确定规模。

给每个用例打上其路由和任何已知边界情况的标签。按标签统计的通过率就是你之后要据以行动的东西。

把每个任务的「完成」用世界的状态写下来，而不是用回复写下来：

如果你无法把成功写下来，评分器就检查不了，同事也检查不了。这说明任务本身有歧义，而不是你需要一个更聪明的评分器。对于有固定答案的任务，把预期结果存在任务上。对于有多个有效答案的任务，把每个有效答案都具备的属性存下来。

agent 常常通过你未曾预料的路径达到正确结果：不同的查询顺序、多一次搜索、一个澄清问题。要求精确工具调用序列的 eval 会让这些运行失败，并教会你忽略失败。Anthropic 的建议是「评 agent 产出了什么，而不是它走了哪条路。」

有一个例外，而且对会采取行动的 agent 最重要。有些路径是规则，违反它们就是失败，即使结果看起来是对的：

把这些写成对 trace 的检查，一条规则一个检查。其余的都放开。

过一遍第 2 步的成功定义，把每个属性分配给能检查它的最便宜的评分器。

代码评分器负责结果和 trace 规则：退款记录存在、金额正确、check_refund_policy 在 issue_refund 之前运行、issue_refund 只运行一次、结构化输出能解析。下面是一段不依赖任何框架的 Python 草稿：

def grade(trial, db): tools = [call.name for call in trial.tool_calls] refunds = db.refunds_for(order_id="A1042") refund_issued = len(refunds) == 1 and refunds[0].amount_usd == 59.00 policy_first = ( "check_refund_policy" in tools and "issue_refund" in tools and tools.index("check_refund_policy") < tools.index("issue_refund") )

The reply may only claim a refund when one exists.

honest_reply = refund_issued or "refund" not in trial.final_text.lower() return {

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）