给智能体建评测：三类评分器、pass@k 和 pass^k、从二三十道题起步，以及一套小评测实测出的四个坑

这篇解决一个问题：做了一个智能体，改了提示词、换了模型、加了工具之后，怎么知道它是变好了还是变坏了。

答案是评测。Anthropic 工程博客的《Demystifying evals for AI agents》讲了智能体的评测怎么做，从概念到一条“从零到能信的评测”的八步路线。本文先整理文章，再用一套 8 道题的小评测实测一遍：

26 次试次全部通过。 这说明的是这套题对现在的模型已经饱和，只能当回归评测，测不出改进。
读了记录才发现，问题出在评分器上。 一个太松，Claude 认定的第一名和出题人想的不一样，照样判通过；一个太死，把“¥656.00”判成错。同一批回答换个评分器，通过率从 100% 变成 0。
有一道题本身有歧义。 Claude 两种理解都答了，该改的是题目。

本站另有两篇相关的：按官方文档写的《给 Claude 应用定标准、建评测、加护栏》讲单轮应用的评测；《用 Claude Code 自动建评测并逐步提分》讲官方的 build-eval 和 hillclimb 插件。这篇讲智能体。

几个词先说清

词	意思
任务	一道题：输入和成功的标准
试次	对一道题的一次尝试。模型每次输出不一样，所以同一道题要跑好几次
评分器	给某一方面打分的逻辑。一道题可以有多个评分器，每个评分器里有多条检查
记录	一次试次的完整过程：输出、工具调用、推理、中间结果。用 Claude API 时就是最后那份完整的 messages 数组
结果	试次结束时环境的最终状态。订机票的智能体最后说“已订好”，结果是数据库里到底有没有这张订单
评测 harness	把评测跑起来的那套东西：给指令和工具、并发跑题、记录、打分、汇总
智能体 harness	让模型成为智能体的那套东西。评测“一个智能体”，评的是 harness 和模型合在一起

文章举了一个例子说明智能体的评测比单轮难：Opus 4.5 在一道订机票的题里发现了政策的一个漏洞，按题目原样判是“失败”，但其实给用户找到了更好的办法。

为什么要早点建

刚开始做智能体时，靠手工测试、自己天天用、凭感觉，能走得很远。到了上线、用户多了以后，没有评测就开始失灵：用户说改完之后感觉变差了，团队却没法验证，只能猜。没有评测时调试是被动的：等投诉、手工复现、修好、祈祷别的地方没坏。

文章说 Claude Code 自己也是这样过来的：先靠员工和外部用户的反馈快速迭代，后来才加评测，先是简洁度、改文件这类窄的方面，再到“过度设计”这类复杂的行为。

还有一个常被忽略的好处：有评测的团队换模型快。 新模型出来，没有评测的团队要测好几周，有评测的几天就能确定新模型的长处、调好提示词、完成升级。延迟、token 用量、每道题的成本、出错率，也都能在同一批题上一直跟踪。

三类评分器

类型	方法	长处	短处
代码	字符串匹配（精确、正则、模糊）；测试通过与否；静态分析；检查最终状态；检查调了哪些工具；分析记录（轮数、token）	快、便宜、客观、可重复、好调试	遇到合理但写法不同的答案容易误判；不细腻；主观的任务评不了
模型	按评分细则打分；自然语言的断言；两两比较；对照参考答案；多个评审取共识	灵活、能扩展、细腻、能评开放式的输出	结果不确定；比代码贵；要用人工评分来校准
人	领域专家评审；众包；抽查；A/B 测试；评审间一致性	质量的金标准；用来校准模型评分器	贵、慢、专家难找

每道题可以加权（几个评分器合起来要过线）、二元（全部过才算过），或者混合。

能力评测和回归评测

	问的是	通过率应该
能力评测	它能把什么做好？	起点低，专挑它做不好的题，给团队一座要爬的山
回归评测	以前会的，现在还会吗？	接近 100%，一下降就说明有东西坏了

能力评测爬到很高以后，可以“毕业”成回归评测，一直跑着防倒退。

不同的智能体怎么评

写代码的智能体：软件好验证，代码能不能跑、测试过不过，确定性的评分器很自然。SWE-bench Verified 和 Terminal-Bench 都是这个路子。实际中通常是单元测试验证正确性，加一个模型按细则评代码质量，其余的评分器按需再加。
对话型智能体（客服、销售、辅导）：互动本身的质量也是评的对象。通常看最终状态是否达成，加上评分细则，往往还需要另一个模型来扮演用户。
研究型和电脑操作型：文章也讲了，思路一样，评结果，辅以细则。

不确定性：pass@k 和 pass^k

智能体每次跑的结果不同，同一道题这次过了下次可能不过。两个指标：

pass@k：k 次里至少有一次成功的概率。k 越大越高。写代码时我们通常最关心第一次就对，也就是 pass@1；有些场景只要有一个方案能用就行。
pass^k：k 次全部成功的概率。k 越大越低。每次成功率 75%、跑 3 次，全对的概率是 0.75³ ≈ 42%。面向用户的智能体更该看这个，用户希望每次都靠得住。

k=1 时两者相等；到 k=10，pass@k 接近 100%，pass^k 接近 0，说的是完全相反的事。用哪个看产品要什么。

从零开始的八步

文章把从没有评测到有一套信得过的评测，整理成一条路线：

收集题目

早点开始。 不需要几百道题，从真实的失败里挑二三十道简单的就是很好的起点。早期每次改动的效果都很明显，样本小也看得出来。拖得越久越难建：一开始需求能直接变成测试用例，拖久了就得从一个线上系统倒推什么算成功。
从你已经在手工检查的东西开始。 每次发版前手工验证的行为、用户常做的事；已经上线的，翻 bug 记录和客服工单。
题目要没有歧义，配参考答案。 好题的标准是两个领域专家各自判，会得出同样的结论。评分器检查的每样东西，题目里都要写清楚。文章举了 Terminal-Bench 的例子：题目让写一个脚本但没说放哪，测试却假定在某个路径，智能体就会无辜地失败。对现在的前沿模型，跑一百次都是 0%，多半是题目坏了，不是模型不行。 每道题最好有一份能通过所有评分器的参考答案，证明题目可解、评分器配对了。
正反两面都要测。 只测“该搜索时有没有搜”，会练出一个什么都去搜的智能体。他们做 Claude.ai 的网页搜索评测时，就同时测了该搜的（查天气）和不该搜的（谁创立了苹果）。

设计 harness 和评分器

环境要稳定、隔离。 评测里的智能体要和线上的差不多；每次试次从干净的环境开始。残留的文件、缓存、资源耗尽会造成相关的失败，共享状态还会虚高成绩：他们在内部评测里见过 Claude 翻之前试次的 git 历史占便宜。
认真设计评分器。 能用确定性的就用确定性的，必要时才用模型，人工用来抽查。评结果，不要评路径：检查智能体是否按某个顺序调了某些工具，太死板，它经常找到出题人没想到的合理做法。多步的题给部分分。模型评分器要和人工校准，给它一个说“不确定”的出口，每个维度单独评。还要防止智能体钻评分器的空子。文章举了两个评分器出错的例子：Opus 4.5 在 CORE-Bench 上一开始只有 42%，研究员发现评分太死（期望 96.124991… 时把 96.12 判错）、题目含糊、有些随机任务没法精确复现，修好后成绩到了 95%。

长期维护

读记录。 不读大量试次的记录和打分，就不知道评分器好不好。失败应该看起来公平：清楚它错在哪、为什么错。
留意能力评测饱和。 全部做对的评测只能防倒退，给不出改进的信号；快饱和时，大的能力提升只表现为一点点分数上涨。原则是：分数不能照单全收，要有人深入看过细节、读过记录。
长期维护，大家都能贡献。 Anthropic 的做法是专门的评测团队管基础设施，领域专家和产品团队贡献题目、自己跑评测。产品经理、客户成功、销售也可以用 Claude Code 提交一道题的 PR。他们推荐“评测驱动开发”：先把计划中的能力写成评测，再迭代到智能体能做好。

本站实测：一套 8 道题的小评测

实测环境
日期	2026-10-16
模型	Claude Sonnet 5.5（`claude-sonnet-5-5`），评分用的也是它
接口	Claude API 的 Messages 接口，Python SDK，自己写的循环；通过酷站AI 中转站，不是直连官方
智能体	《给智能体写工具》里按任务设计的那一版工具，数据是同一批虚构的客服数据
次数	前 7 道题每道 3 次，第 8 道 5 次

题目和评分器

按文章的建议：正反两面都有，评结果不评路径，能用代码评的用代码，说原因这类用模型评，模型评分器每个维度单独判、允许答“不确定”。

题	问什么	评分器
1	林晓雯 9 月有几笔退款、合计多少	代码：有“2 笔”，有 144
2	某个邮箱的客户用什么套餐、有没有未解决的工单	代码：有“团队版”，说了没有未解决的工单
3	有没有重复扣款，列出名字	代码：三个名字都在
4	王建国为什么要走、最近三个月付了多少	代码：有 656；模型：两个原因（团队缩编用不满、导出超时）各判一次
5	9 月退款最多的客户是谁	代码：有“林晓雯”（出题时想的是按笔数）
6	按退款金额合计，9 月退款最多的客户是谁	代码：有“唐志强”
7	客户张伟 9 月有没有退款（反向题：没有这个客户）	代码：说明查不到这个客户
8	8 月所有已支付订单合计多少（要翻订单、累加 15 笔）	代码：回答里的金额等于标准答案

评测脚本一百来行：每道题循环跑 k 次，对最后的回答逐条跑评分器，汇总通过率、pass@k、pass^k，同时记下工具调用次数和 token 用量。

结果：全部通过

题	通过	pass@k	pass^k
1 到 7	每道 3/3	全部是	全部是
8	5/5	是	是

26 次试次全部通过，pass@k 和 pass^k 都是 100%。反向题 7 也没有编数字，三次都说查不到这个客户，搜了几种写法，并问用户要客户编号或邮箱。

照文章的说法，这不是好消息，至少不全是：这套题对现在的模型已经饱和，只能当回归评测用，给不出改进的信号。我们本来想用第 8 题造一道难一点的，结果 8 月只有 15 笔订单，一页就翻完了，也是 5 次全对。要做能力评测，得找它真会失败的题，比如从真实用户报过的失败里挑。

读记录发现的四个坑

全部通过之后，我们照第 6 步读了每一次的回答，又拿同样的回答换几种评分器重新打分。问题都出在评测本身：

一、评分器太松，放过了错误的答案。 第 5 题有歧义：“退款最多”可以按笔数（林晓雯 2 笔），也可以按金额（唐志强 299 元）。Claude 三次都先答“按金额是唐志强”，再补一句“按笔数是林晓雯”。我们的评分器只检查回答里有没有“林晓雯”，于是三次都判通过，其实它根本分不出 Claude 认定的第一名是谁。第 6 题同理：一个把两人顺序说反的错误答案，照样能通过“包含唐志强”。

二、评分器太死，会误杀对的答案。 第 4 题的金额，第 2 篇实测里另一版工具的回答写的是“656.00 元”，这次三次都写成“¥656.00”。照着前一个回答写一个“必须出现 656.00 元”的评分器，三次对的答案全部判错。同样的事在第 8 题里也有：同一个模型、同一道题跑 5 次，4 次写“¥2,825.00”，1 次写“2,825.00 元”。

三、同一批回答，换个评分器就从 100% 变成 0。 第 5 题的三个回答：

评分器	通过
回答里有“林晓雯”	3/3
回答里有“最多的是林晓雯”	0/3
回答里有“最多的是唐志强”	3/3
第 4 题：必须出现“656.00 元”	0/3
第 4 题：回答里的金额等于 656.00	3/3

这就是文章说的“分数不能照单全收”：不读记录，100% 和 0% 看起来都像是智能体的成绩。

四、题目有歧义，问题出在出题人。 第 5 题按文章第 2 步的标准就不合格：两个人各自判，会得出不同的结论。Claude 的处理其实很得体，两种理解都答了；该改的是题目，像第 6 题那样写明“按金额合计”。

改法

评分器写成检查结论本身，比如“最多的是唐志强”，或者让模型评分器回答“回答认定的第一名是谁”，不要只查名字有没有出现。
金额、日期这类有多种写法的，先把回答里的数字提取出来再比，不比字符串。
歧义的题改题目，不要靠评分器去猜出题人的意思。
全部通过的题，挪到回归评测里一直跑；另找它会失败的题做能力评测。

花费

26 次试次加起来输入约 9.3 万 token、输出约 8 千 token，加上 3 次模型评分，按 Sonnet 5.5 的官方价（每百万 token 输入 2 美元、输出 10 美元）估算约 0.3 美元。这是估算，不是中转站实际扣的金额。

没有覆盖到的

只评了一个很小的智能体，题目也简单，测不出能力上的差别。
模型评分器没有和人工评分做校准。这次它判的 6 个维度我们逐条看过，都对，但样本太小。
没有用另一个模型扮演用户来评多轮对话。

评测之外

自动评测只是了解智能体的一种办法。文章列了几种，各有各的盲点：

方法	擅长	不足
自动评测	快、可重复、不影响用户、每次提交都能跑	前期投入大，要跟着产品和模型维护，和真实用法对不上时会给人虚假的信心
线上监控	看到真实用户的行为，能抓到合成评测漏掉的问题	被动，用户先碰到问题；信号嘈杂
A/B 测试	衡量真实的用户结果	慢，要几天到几周、要足够的流量；只能测上线了的改动
用户反馈	暴露没想到的问题，带着真实的例子	稀疏、偏向严重问题，用户很少说清为什么
人工读记录	建立对失败模式的直觉，抓到自动检查漏掉的细节	费时间，扩展不了，覆盖不均
系统的人工评审	质量的金标准，能评主观的任务	贵、慢，难以经常做

自动评测最适合上线前和 CI 里，每次改智能体、换模型都跑一遍，当第一道防线；上线后再靠线上监控。

参考

Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe：Demystifying evals for AI agents（Anthropic 工程博客，2026-01-09）
Claude 开发平台文档：Define success criteria and build evaluations