这是「Agent 与 Skill 评测」系列的第一篇。系列按“为什么做、怎么做、怎么做好”的顺序展开，共七篇：
- 评测在回答什么问题（本文）
- Agent 评测：如何判定完成、评估过程，以及处理耗时、成本和波动
- Skill 评测：固定 Agent，只评 Skill
- 评分器：规则、脚本、LLM Judge 与人工评分
- 数据集与用例：用例从哪里来，怎样维护
- 评测链路：从隔离执行到版本对比的落地方案
- 误区与推进路线
团队内部的 Agent 投入使用后，很快会遇到两个问题：
- 这个 Agent 能不能在规定时间和成本内完成任务？
- 我们改了知识库、改了 Skill，它到底有没有变强？
没有评测时，回答这两个问题的方式通常是：找几个问题手动试一下，看看结果顺不顺眼。这种方式有三个缺陷：
- 样本太少：试五个问题都通过，不代表第六个也能通过。
- 不可复现：同一个问题今天能过、明天不能过，说不清是改动造成的还是模型本身的随机波动。
- 没有对照：不知道改动前的表现，就无法判断改动后是变好还是变坏。
Anthropic 在 Demystifying evals for AI agents 中把这种状态形容为 “flying blind”：用户反馈 Agent 变差了，团队只能猜测、复现、修复，然后祈祷别处没有退化。评测要解决的就是这个问题：把“感觉变好了”变成可以复现、可以比较的数据。
评测是一次控制变量实验
讨论评测之前，先把 Agent 拆成几个会被单独修改的部分：
Agent
├── 模型 Claude、GPT、Qwen 等，以及具体版本
├── Harness System Prompt、上下文管理、工具编排、执行循环
├── Skill 可按需加载的指令、脚本和资源
├── 知识库 Agent 检索和引用的领域资料
└── 工具 MCP Server、API、命令行等外部能力
广义上 Skill 和工具也属于 Harness。这里把它们单独列出，是因为它们由不同的人维护、按不同的节奏更新，评测时需要分别控制。
评测哪一部分，就只改变那一部分，其余全部固定：
| 评测目标 | 改变的部分 | 固定的部分 |
|---|---|---|
| 模型选型或升级 | 模型 | Harness、Skill、知识库、工具 |
| Harness 优化 | Prompt、上下文策略、工具编排 | 模型、Skill、知识库、工具 |
| Skill 迭代 | Skill 版本 | 模型、Harness、知识库、工具 |
| 知识库更新 | 知识库内容 | 模型、Harness、Skill、工具 |
| 整体验收 | 整个 Agent | 无，直接和验收标准比较 |
只有一个变量在变化时，分数的变化才能归因到这个变量上。
Skill 评测和 Agent 评测是同一件事
从这张表可以看出，Skill 评测和 Agent 评测本质上是同一件事，只是粒度不同。
Skill 本身不能执行。它只是一组指令和资源，必须装进 Claude Code、Codex 或自研 Agent 里，由模型读取并执行，才会产生结果。所以 Skill 评测测到的永远是“这个 Skill 在这个模型、这个 Harness 下的表现”。
这带来一个容易被忽略的要求：评测 Skill 时，只固定模型还不够，Harness 也必须固定。同一个 Skill 放进 Claude Code 和放进 Codex，加载方式、上下文组织和工具调用都不同，分数自然不同。如果评测期间 Harness 升级了版本，分数变化就分不清来自 Skill 还是来自 Harness。
Anthropic 在定义 Agent Harness 时也明确了这一点：评测“一个 Agent”，评测的是 Harness 和模型共同工作的结果。
评测本身也是变量
除了 Agent 的组成部分，评测本身也有三个会变化的部分：
- 数据集：用例增加、删除或修改后，通过率就不再可比。
- 评分器：评分规则或 Judge Prompt 改了，同一份结果可能得到不同的分数。
- 执行环境：依赖版本、初始文件、网络条件不同，同一个 Agent 的表现也会不同。
所以对比两个版本的 Agent 时，数据集、评分器和执行环境都要固定在同一个版本。前后两次评测只要有一项不同，分数就不能直接比较。
执行环境的影响比直觉更大。Anthropic 在 Quantifying infrastructure noise in agentic coding evals 中做过一组实验：在 Terminal-Bench 2.0 上，模型、Harness 和用例全部不变，只调整容器的 CPU 和内存配额，资源最宽松和最严格的两种配置之间，分数相差 6 个百分点，超过了排行榜上不少头部模型之间的差距。他们还观察到，通过率会随一天中的时段波动，原因可能是 API 延迟随流量变化。
落到团队内部的评测上，就是两条做法：
- 资源配额、超时时间、并发数要写进评测配置，和数据集一起固定版本；
- 对比两个版本时，在同一时段内交替运行，而不是今天跑旧版、明天跑新版。
评测要回答的六个问题
回到开头的需求：“能不能在规定时间和成本内完成任务”。这句话已经给出了成功的定义：
任务成功 = 目标达成 且 耗时 ≤ 时间预算 且 成本 ≤ 成本预算 且 没有违规操作
只看目标是否达成是不够的。一个 Agent 花了 40 分钟、消耗了 200 万 Token 才完成一个原本 2 分钟能完成的任务，在生产中等同于失败。同样，任务完成了，但中途删掉了不该删的文件，也是失败。
在此基础上，评测需要回答六个问题：
| 维度 | 回答的问题 | 典型指标 | 数据来源 |
|---|---|---|---|
| 完成度 | 任务目标达成了吗 | 通过率、部分得分 | 终态 + 评分器 |
| 过程准确率 | 执行过程对吗 | 关键检查点命中率、工具调用正确率、无效调用次数 | 轨迹 |
| 耗时 | 在时间预算内吗 | 端到端耗时、耗时分布 | 执行记录 |
| 成本 | 在成本预算内吗 | 输入/输出 Token、单任务成本 | 轨迹中的用量统计 |
| 稳定性 | 每次都能做到吗 | 多次运行通过率、pass@k、pass^k | 同一用例的多次执行 |
| 安全合规 | 有没有越权或违反规则 | 越权调用次数、敏感操作是否经过确认 | 轨迹 + 终态 |
完成度：看终态，不看 Agent 怎么说
Agent 在最后说“已完成”，不代表任务真的完成。Anthropic 用订机票举例：Agent 在对话结尾说“您的航班已预订”，但真正的结果是数据库里有没有这条预订记录。
判断完成度，要检查 Agent 执行结束后环境里的真实状态：文件有没有生成、内容对不对、外部系统里有没有预期的记录。
过程准确率：结果对了，过程也可能有问题
结果正确不代表过程正确。常见的过程问题包括：
- 调用了与任务无关的工具；
- 重复查询同一份数据；
- 绕远路，用十步完成两步就能完成的事；
- 没有读取必要的资料，结果碰巧是对的。
前三类会推高 Token 和耗时，最后一类会以稳定性问题的形式暴露出来：碰巧对的结果，下次很可能就错了。
需要注意的是，评估过程不等于规定一条固定路径。Anthropic 的经验是，检查工具调用顺序的测试往往过于脆弱，因为 Agent 经常找到设计者没有预想到的合理做法。更稳妥的方式是把过程拆成几个关键检查点，比如“读取了销售数据”“计算了环比”“生成了报告文件”，检查每个检查点是否达成，并允许部分得分，而不是逐步比对。这部分在下一篇展开。
耗时和成本：记录每一次，看分布
耗时和 Token 用量要按每次执行记录，而不是只看汇总后的平均值。平均耗时 30 秒，可能是大部分 10 秒加上少数几次超时 5 分钟。汇总时至少同时看中位数和较高分位数，才能发现长尾。
稳定性：同一个用例要跑多次
模型的输出有随机性，同一个用例这次通过，下次可能失败。只跑一次得到的通过率，混合了 Agent 的真实能力和随机波动。
因此每个用例要执行多次，再用两个指标描述稳定性：
- pass@k：k 次执行中至少成功一次的概率。k 越大，这个值越高。
- pass^k：k 次执行全部成功的概率。k 越大，这个值越低。
Anthropic 给出的例子是：单次成功率 75% 的 Agent，连续三次都成功的概率只有 0.75³ ≈ 42%。pass^k 最早由 τ-bench 提出，它的实验更直观：GPT-4o 在零售客服任务上单次成功率约 60%，要求 8 次全部成功时（pass^8）不到 25%。
两个指标适用于不同场景：允许多次尝试、只要有一次成功就行的任务看 pass@k；用户期望每次都可靠的任务看 pass^k。团队内部每天重复使用的 Agent 属于后者，单次通过率 75% 意味着同事每用四次就会遇到一次失败。
安全合规：做成了，但不能这样做
前五个维度来自团队最初的需求。对照业界框架后，还需要补上第六个。
CLEAR 是一个面向企业 Agent 的评测框架，五个字母分别代表成本（Cost）、耗时（Latency）、完成度（Efficacy）、安全合规（Assurance）和稳定性（Reliability）。它和本文的维度基本重合，区别在于：本文多了过程准确率，CLEAR 多了安全合规。
安全合规要单独成为一个维度，是因为它的判定方式和其他维度不同。其他维度可以加权，也可以给部分分；安全合规是一票否决。只要出现下面任何一种情况，即使任务完成，这次执行也判为失败：
- 越权调用，比如只读任务里执行了写操作；
- 未经确认执行敏感操作，比如删除文件、对外发送数据；
- 被输入中夹带的恶意指令诱导，调用了高权限工具。
基础概念
上面的讨论用到了几个概念。这里统一给出定义，后续文章都按这个口径使用：
| 概念 | 含义 |
|---|---|
| 用例（Task / Case） | 一条测试，包含输入和成功标准 |
| 试次（Trial） | 对一个用例的一次执行。因为输出有随机性，一个用例通常执行多次 |
| 轨迹（Transcript / Trace） | 一次试次的完整记录：输出、工具调用、推理、中间结果、Token 用量 |
| 终态（Outcome） | 试次结束时环境中的真实状态 |
| 评分器（Grader） | 评估某一方面表现的逻辑。一个用例可以有多个评分器 |
| 数据集（Eval Suite） | 一组服务于同一评测目标的用例 |
| 评测执行框架（Eval Harness） | 端到端运行评测的基础设施：下发用例、并发执行、记录轨迹、评分、汇总 |
| Agent Harness | 让模型作为 Agent 工作的系统：处理输入、编排工具调用、返回结果 |
它们之间的关系：
数据集
└── 用例 × N
└── 试次 × k
├── 轨迹 → 过程准确率、耗时、成本、安全合规
└── 终态 → 完成度
↓
评分器 × M → 每个试次的分数
↓
汇总：通过率、pass@k / pass^k、耗时分布、成本
注意 Eval Harness 和 Agent Harness 是两个东西。Agent Harness 是被测对象的一部分，Eval Harness 是运行评测的工具。用 Claude Code 作为被测 Agent 时，Claude Code 是 Agent Harness；负责启动它、喂给它用例、收集轨迹和打分的那套系统，是 Eval Harness。
一个具体例子
假设要评测一个生成销售周报的 Skill。用户提供本周销售额、上周销售额和销售目标，Skill 应该生成一份 Markdown 周报，包含环比变化和目标完成率。
用例
输入：本周销售额 120 万，上周 100 万，目标 150 万，请生成周报
成功标准：生成 report.md，环比为 +20%，目标完成率为 80%，结构完整
试次
同一个输入执行 5 次
轨迹（每次）
是否加载了周报 Skill
调用了哪些工具，各调用几次
耗时 18 秒，消耗 1.2 万 Token
终态（每次）
工作目录中是否存在 report.md，以及文件内容
评分器
规则评分器：检查 report.md 存在，且包含 “+20%” 和 “80%”
LLM 评分器：按评分标准判断结构是否完整、表述是否清楚
5 次试次中，如果 4 次两个评分器都通过、1 次环比算错，那么这个用例的单次通过率估计为 80%，按此估算 pass^5 约为 0.8⁵ ≈ 33%。如果只跑一次，有 80% 的概率会恰好通过，从而误以为这个 Skill 没有问题。
能力评测和回归评测
开头的第二个问题，“改了 Skill 之后有没有变强”，其实包含两层：
- 新的改动有没有让 Agent 做到以前做不到的事？
- 新的改动有没有让 Agent 做不好以前能做好的事？
这对应两类数据集：
| 类型 | 回答的问题 | 期望通过率 | 作用 |
|---|---|---|---|
| 能力评测 | Agent 能做好什么 | 从低开始 | 给改进提供目标，看能力是否提升 |
| 回归评测 | Agent 是否还能做好以前的事 | 接近 100% | 防止退化，分数下降就说明有东西坏了 |
能力评测里的用例，一开始应该是 Agent 做不好的任务，否则它无法反映提升。当某些用例长期稳定通过后，可以把它们移入回归评测，从衡量“能不能做到”转为衡量“还能不能稳定做到”。
每次修改 Skill 或知识库，两类评测都要跑：能力评测的分数上升说明改动有效，回归评测的分数不变说明改动没有破坏已有能力。只跑其中一类，结论都不完整。
小结
评测是一次控制变量实验：固定模型、Harness、数据集、评分器和执行环境，只改变要评测的那一部分，然后回答六个问题：任务完成了吗，过程对吗，耗时和成本在预算内吗，每次都能做到吗，有没有越权或违规。
Skill 评测和 Agent 评测遵循同一套方法，区别只在于改变的变量是哪一个。下一篇从更通用的 Agent 评测开始，讨论如何判定任务完成、如何评估过程，以及如何在评测中处理耗时、成本和随机波动。