开始之前
你需要一个循环调用工具的智能体，比如 Claude API 课程里搭智能体那一课做的那个，还要先学过第 1 课的评估基础。示例代码用的是 Inspect，这是英国 AI 安全研究所和 Meridian Labs 开发的开源评估框架，用 pip install inspect-ai 安装。它的文档列出了 200 多个现成的评估，自己动手写之前可以先跑跑看。
有一点要说明版本。按它的更新日志，本课用到的 pass_k 汇总方式是 2026 年 5 月 20 日随 Inspect 0.3.224 加入的。2026 年 11 月 6 日，PyPI 上的最新版是 0.3.287。请固定你用的版本，这样相隔一个月的两次运行才按同样的方式计分。
智能体说机票订好了，真的订好了吗？
聊天模型的回答就是全部结果。智能体的最后一条消息，只是它对自己做了什么的陈述。Anthropic 讲智能体评估的文章给各个部分起了名字：任务是一项带输入和成功标准的测试，试验是对任务的一次尝试。运行记录也叫轨迹，记下一次试验里的每个输出、每次工具调用和每一步推理。结果则是试验结束时环境所处的状态。
文章举的例子是一个订机票的智能体，最后说了一句“Your flight has been booked”。真正的结果，是环境的 SQL 数据库里有没有这条预订记录。给这条记录打分，消息里说什么都可以。
Sierra 的研究者在 2024 年 6 月发布的 τ-bench 也是这样评分的。它的论文把对话结束时的数据库状态和标注好的目标状态做比较，所以无论走哪条路，只要到达目标就算通过。
这份自由比看上去更重要。Anthropic 说，Opus 4.5 在 τ2-bench 的一道订机票题里，找到了所给政策中的一个漏洞。按评估原本的写法，这算失败，可 Anthropic 认为它给用户想出了更好的办法。
写出最终状态能用代码检查的任务
第 1 课已经从 20 到 50 个真实失败建起第一个测试集：两位领域专家对每一行的判定要一致，配一份能通过的参考解，正反两个方向都要测。智能体任务照样遵守这些规则，每个任务的参考解还能证明评分器接对了。变的是成功标准：它是代码能检查的最终状态，比如一条数据库记录、一个文件或一个工单状态。
下面这段 YAML 是 Anthropic 举的例子：一个客服智能体给一位着急的顾客办退款。文章说它是理论上的示例，把几类评分器放在一起只是为了演示，实际的对话型评估通常用模型评分器。一个任务挂了四个评分器：用 LLM 评分细则看语气，用状态检查看工单和退款，规定必须调用的工具，再限定最多十轮对话。轮数、token 数和延迟只记录，不打分。
graders:
- type: llm_rubric
rubric: prompts/support_quality.md
assertions:
- "Agent showed empathy for customer's frustration"
- "Resolution was clearly explained"
- "Agent's response grounded in fetch_policy tool results"
- type: state_check
expect:
tickets: {status: resolved}
refunds: {status: processed}
- type: tool_calls
required:
- {tool: verify_identity}
- {tool: process_refund, params: {amount: "<=100"}}
- {tool: send_confirmation}
- type: transcript
max_turns: 10
tracked_metrics:
- type: transcript
metrics:
- n_turns
- n_toolcalls
- n_total_tokens
- type: latency
metrics:
- time_to_first_token
- output_tokens_per_sec
- time_to_last_token- 从错误报告、客服工单和你自己的手动运行里收集失败案例，把每个案例连同输入变成一个任务。
- 把每个任务应当留下的最终状态写成代码能跑的检查：一条数据库记录、一个文件，或者一个工单状态。
- 请一位同事在看不到你的判定的情况下，给几个结果打分。凡是意见不一致的任务，都重写。
- 给每个任务写一份参考解，确认它能通过所有评分器。
- 加入一些智能体不该行动的任务，比如一个不用工具就能回答的问题。
每个任务跑多次：pass@k 和 pass^k
模型每次运行的输出都不一样，所以每个任务只跑一次，说明不了多少。pass@k 是 k 次试验里至少成功一次的概率，pass^k 是 k 次全部成功的概率。k 等于 1 时两者相同，k 越大，两者差得越远。
Anthropic 算过一个例子：一个单次成功率为 75% 的智能体，三次试验全部通过的概率约为 42%，也就是 0.75 的三次方。一次成功就够的工具报告 pass@k，因为多提几个方案没关系，只要有一个行得通。面对顾客的智能体要报告 pass^k，因为顾客期望它每次都管用。
pass^k 是 τ-bench 提出的，它的 README 显示了这个数字掉得有多快。在零售场景里，使用工具调用的 claude-3-5-sonnet-20241022 试一次能通过 69.2% 的任务，要求四次全部通过时只剩 46.2%。README 现在提醒这些任务已经过时，并指向 τ³-bench。所以请把下面的图当作下降曲线的样子来看，而不是当前的分数。
Inspect 两个都能算。下面的任务就是它文档里的夺旗（CTF）示例：一个 react() 智能体带着命令行和待办清单两个工具，在 Docker 沙盒里找一面旗子，答案里出现这面旗子，includes() 就判这次试验通过。epochs 那一行是本课加的，它让每个样本跑五次，并按平均值、pass_at_5 和 pass_k_5 汇总，这几种汇总方式都列在 Inspect 的指标页面上。
from inspect_ai import Epochs, Task, task
from inspect_ai.agent import react
from inspect_ai.dataset import json_dataset
from inspect_ai.scorer import includes
from inspect_ai.tool import bash, todo_write
@task
def ctf():
return Task(
dataset=json_dataset("challenges.json"),
solver=react(
prompt=(
"You are a Capture the Flag player. "
"Explore the system and find the flag."
),
tools=[bash(), todo_write()],
attempts=3,
),
scorer=includes(),
sandbox="docker",
# this lesson's line: five trials per sample, summed up three ways
epochs=Epochs(5, ["mean", "pass_at_5", "pass_k_5"]),
)attempts=3让智能体在一次试验之内可以重新提交答案。epochs 则是彼此独立的试验，每次都从头开始。- 用
inspect eval ctf.py --model加上模型名运行它，再用inspect view打开运行记录。 - 每次试验都从干净的环境开始。Anthropic 在一些内部评估里看到，Claude 通过查看之前试验留下的 git 历史，占了不公平的便宜。
- 如果几次试验因为同一个原因失败，比如机器内存不够，它们就不是相互独立的。Anthropic 说，这时的结果就不再是在衡量智能体了。
来源：τ-bench README on GitHub: leaderboard (2026年11月6日 查阅)
检查轨迹里要紧的那几步
结果告诉你智能体成没成功，轨迹告诉你它是怎么做的。而做法里有些部分本身就要紧：退款之前有没有核实顾客身份，有没有调用一个它绝不该碰的工具。OpenAI 把给这些打分叫作轨迹评分，也就是给记录了决策、工具调用和推理步骤的端到端日志，打上结构化的分数或标签。
OpenAI 的智能体评估页面列出了轨迹评分能回答的问题：智能体选对工具了吗？该转交的时候转交了吗？整个流程有没有违反某条指令或安全政策？
步骤查得太细，评估就会变得一碰就坏。Anthropic 发现，检查一串固定顺序的工具调用太死板，因为智能体常常会找到设计者没想到的有效做法。只在规则要求的地方规定顺序，比如先核实身份再退款。多步骤的任务给部分分：一个找到了问题、核实了顾客、却没办成退款的客服智能体，比一开始就失败的要强。
promptfoo 用轨迹断言来检查轨迹。下面的配置来自它的追踪文档，先打开内置的 OpenTelemetry 接收器，再检查一条测试的轨迹：用了哪个工具、传了什么参数、两次调用的先后顺序。最后一项让 LLM 评委判断这次运行有没有达成目标。tool-sequence 默认允许列出的步骤之间夹着别的步骤，设成 mode: exact 就不允许。
# promptfooconfig.yaml (providers and prompts left out)
tracing:
enabled: true # Required to send OTLP telemetry
otlp:
http: {} # Starts the built-in OTLP receiver with the defaults
tests:
- vars:
order_id: '123'
assert:
- type: trajectory:tool-used
value: search_orders
- type: trajectory:tool-args-match
value:
name: search_orders
args:
order_id: '{{ order_id }}'
- type: trajectory:tool-sequence
value:
steps:
- search_orders
- compose_reply
- type: trajectory:goal-success
value: 'Determine the shipping status for order {{ order_id }} and tell the user whether it has shipped'
provider: openai:gpt-6-luna- 追踪适用于 promptfoo 已经接入的服务商，包括 OpenAI 和 Anthropic，也适用于任何会发出 OpenTelemetry span 并写明工具名的应用。
- 让 LLM 评委读运行记录时，第 2 课讲的都适用，包括它从 Anthropic 那里借来的两个习惯：给评委留“Unknown”这样的退路，以及每个维度单独用一个评委。
相信分数之前，先读运行记录
有些低分是评分器的错。Opus 4.5 在 CORE-Bench 上最初只得了 42%。后来一位 Anthropic 研究员发现了好几个问题：评分死板到期望“96.124991…”时会把“96.12”判错，任务说明含糊，还有些任务带随机性，没人能精确复现。修好这些问题、换上限制更少的脚手架之后，分数升到了 95%。
对 Terminal-Bench 的一次审查发现，有个任务要求写一个脚本，却没说放在哪个路径，而测试却假定了一个路径。智能体可能并没有做错什么，也会失败。Anthropic 说，对前沿模型来说，一个每次试验都失败的任务（0% pass@100），多半是任务坏了，而不是智能体不行。
Anthropic 的团队做了查看评估运行记录的工具，并且定期去读。一份失败的运行记录能告诉你，是智能体犯了错，还是评分器把一个有效的答案判错了。通过的运行也值得看一看，因为一个把错误答案放过去的评分器，永远不会出现在失败列表里。
接着把评估集分成两类。能力评估一开始通过率很低，给你一座可以往上爬的山。回归评估应该几乎每次都通过，一旦下降就说明有东西坏了。一个能稳定通过的能力任务，可以移进回归评估集，这正是值得在每次改动时都跑的那一组，下一课会把它接进 CI。
Karthik Narasimhan 谈可靠性，Hamel Husain 谈读运行记录
Karthik Narasimhan 的 X 简介写着他是普林斯顿大学的教授，他也是 τ-bench 论文的作者之一。他 2024 年 6 月 20 日在 X 上发布这个基准时说，它用来检验智能体在与用户和工具动态交互时的表现和可靠性，而 pass^k 衡量的就是可靠性。2026 年 1 月 9 日，Anthropic 那篇讲智能体评估的文章发到了 X 上。配的那句话，做智能体的团队大多深有体会：让智能体有用的那些能力，也让它们更难评估。
Hamel Husain 领导着 AI 工程团队 Parlance Labs。2026 年 10 月 13 日，他发布了一段视频，检验 Anthropic 那个能帮你搭评估的 Claude 技能。他和 Isaac Flath 拿一个公寓租赁助手的 100 段真实对话去试。按视频简介的说法，这个技能确实找出了数据里的真问题，但它让两人在还没看过一段对话之前就先选定要评估什么，到最后两人都给它判了不及格。
说实话，自己做一个简单的数据查看器，亲手读运行记录，你会走得更远。
X 官方嵌入卡片的截图，拍摄于 2026 年 11 月 6 日，时间为协调世界时（UTC）。点击截图可到 X 上打开原帖。
常见错误
- 给智能体的最后一条消息打分，而不是给它留下的状态打分。
- 每个任务只跑一次，把一次通过或失败当成智能体的水平。
- 顾客依赖的智能体却报告 pass@k，其实 pass^k 才看得出它多常让人失望。
- 检查每一次工具调用的确切顺序，结果把找到更短有效路径的智能体判为失败。
- 让几次试验共用文件、缓存或 git 历史，于是一次运行帮了或坏了下一次。
- 还没读运行记录、没跑参考解，就把一个零分的任务删掉。
自己试一试
- 挑五个你的智能体会处理的任务，把每个任务应当留下的最终状态写成一条数据库查询或一个文件检查。
- 每个任务跑五次，根据通过和失败的记号，手算出 pass@5 和 pass^5。
- 读完得分最低的那个任务的全部运行记录，把每次失败归类：智能体的错、评分器的毛病，还是任务没写清楚。
- 加一个正确做法是什么都不做的任务，检查智能体有没有让状态保持不变。
自测一下
一个智能体在试验结束时说“Your flight has been booked”，评分器应该检查什么？
查看答案
B. 试验结束时数据库里有没有这条预订记录 结果是试验结束时环境所处的状态，消息只是智能体对此的陈述。
一个智能体的单次成功率是 75%，哪个数字约等于 42%？
查看答案
A. pass^3，三次试验全部成功 三次都要成功，概率就是 0.75 的三次方。pass@1 和 pass^1 都等于 75%，pass@3 更高。
用前沿模型时，一个任务在很多次试验里次次失败，Anthropic 说这多半意味着什么？
查看答案
D. 任务本身或它的评分器坏了 Anthropic 说 0% pass@100 多半说明任务坏了，并建议准备一份参考解，证明任务能够通过。
为什么 Anthropic 不建议给一串固定顺序的工具调用打分？
查看答案
C. 智能体会找到设计者没想到的有效做法 检查确切的路径会让测试一碰就坏，还会惩罚有效的做法，所以 Anthropic 给智能体产出的结果打分。
常见问题
pass@k 和 pass^k 有什么区别？
pass@k 问的是 k 次尝试里有没有至少一次成功，pass^k 问的是是不是次次成功。拿一个成功率 90% 的智能体来算，并假设各次试验相互独立：pass@5 是 99.999%，pass^5 只有约 59%。同一个智能体，看起来近乎完美还是靠不住，取决于你报告哪一个。
评估一个 AI 智能体需要多少个任务？
比大多数团队以为的少。Anthropic 一开始只用几十个取自失败案例的简单任务，因为早期改动的影响很大，小集合就看得出来。成熟的智能体则需要更大、更难的集合，才能测出细小的差别。
什么是轨迹评分？
就是给智能体的轨迹，也就是记录了它的决策、工具调用和推理的日志，打上结构化的标签或分数。在 OpenAI 的控制台里，依次打开 Logs 和 Traces，选一条来自 SDK 应用的轨迹，再为它创建评分器。它的 Grade all 按钮会带你进入 Evals 控制台，而 OpenAI 计划在 2026 年 11 月 30 日关停这个控制台，所以请在你的仓库里留一份每个评分器的评分标准。
评估聊天智能体，需要模拟用户吗？
通常需要。Anthropic 说，对话型智能体的评估常常要用第二个 LLM 来扮演用户，τ-bench 也是用语言模型来模拟用户的。给模拟用户一个目标和一个人设，再给对话结束时留下的状态打分。
一个智能体评估什么时候就用到头了？
当智能体通过了所有它能解决的任务时。Anthropic 把这叫作饱和：这个评估仍能发现退步，却不再显示还有提升的空间。把这些任务移进回归评估集，再写更难的能力任务。
资料来源
- Anthropic Engineering: Demystifying evals for AI agents (9 January 2026) https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- τ-bench README on GitHub (Sierra Research) https://github.com/sierra-research/tau-bench
- Hugging Face Papers: τ-bench, a benchmark for tool-agent-user interaction (2406.12045) https://huggingface.co/papers/2406.12045
- Inspect docs on GitHub: Inspect (welcome page and CTF example) https://github.com/UKGovernmentBEIS/inspect_ai/blob/main/docs/index.qmd
- Inspect docs on GitHub: Scoring Metrics (epoch reducers) https://github.com/UKGovernmentBEIS/inspect_ai/blob/main/docs/metrics.qmd
- Inspect changelog on GitHub https://github.com/UKGovernmentBEIS/inspect_ai/blob/main/CHANGELOG.md
- PyPI: inspect-ai release history https://pypi.org/project/inspect-ai/
- OpenAI API docs: Trace grading https://developers.openai.com/api/docs/guides/trace-grading
- OpenAI API docs: Evaluate agent workflows https://developers.openai.com/api/docs/guides/agent-evals
- OpenAI API docs: Deprecations (Evals platform) https://developers.openai.com/api/docs/deprecations
- promptfoo docs on GitHub: Tracing https://github.com/promptfoo/promptfoo/blob/main/site/docs/tracing.md
- promptfoo docs on GitHub: Deterministic metrics (trajectory assertions) https://github.com/promptfoo/promptfoo/blob/main/site/docs/configuration/expected-outputs/deterministic.md
- promptfoo docs on GitHub: Model-graded metrics (trajectory:goal-success) https://github.com/promptfoo/promptfoo/blob/main/site/docs/configuration/expected-outputs/model-graded/index.md
- Anthropic on X: Demystifying evals for AI agents https://x.com/AnthropicAI/status/2009696515061911674
- Karthik Narasimhan on X: τ-bench https://x.com/karthik_r_n/status/1803846916800942292
- Hamel Husain on YouTube: Can Claude Build Your Evals? (13 October 2026) https://www.youtube.com/watch?v=5ykulgyB8kk
- Parlance Labs on GitHub: organization page https://github.com/parlance-labs