第 01 篇的结论是：Skill 评测和 Agent 评测是同一件事，区别只在于改变的变量是哪一个。这一篇把第 02 篇里的被测 Agent 固定下来，只改变 Skill。
方法和第 02 篇一样：用例、终态、检查点、多次执行。Skill 评测多出来的问题是，Skill 要先被加载，才可能起作用。
Skill 怎么生效
Anthropic 在介绍 Agent Skills 时，把 Skill 的加载方式称为“渐进式披露”，分三层：
- Agent 启动时，所有已安装 Skill 的名称和描述被放进系统提示词；
- Agent 判断某个 Skill 和当前任务相关时，读取它的 SKILL.md 正文；
- SKILL.md 引用的其他文件和脚本，只在需要时读取或执行。
所以一个 Skill 要发挥作用，必须依次经过五个环节。任何一环出问题，最终结果都不会好：
| 环节 | 回答的问题 | 失败的表现 | 要修的地方 |
|---|---|---|---|
| 准入 | 能不能装 | 含恶意脚本、向外发送数据、泄露密钥 | 不引入，或修改后再引入 |
| 触发 | 该用的时候有没有加载 | 没读 SKILL.md；或者不该用的时候读了 | 描述 |
| 遵循 | 加载之后有没有照做 | 读了，但跳过关键步骤 | 指令写法；必须执行的规则移到 Hook |
| 增益 | 照做之后结果有没有变好 | 通过率没涨，甚至下降 | Skill 内容本身 |
| 代价 | 为此多花了多少 | Token 和耗时上升，产生多余产物 | 精简内容、拆分文件 |
通过率只能看到最后的结果。一个 Skill 通过率没涨，可能是没被触发，可能是触发了没照做，也可能是照做了但内容本身有问题。三种情况的修法完全不同，所以 Skill 评测要把每个环节分开测。
固定什么：Harness 和已安装的 Skill 也是变量
评测 Skill 时，只固定模型还不够，Harness 也要固定。SkillsBench 的数据说明了原因：同样是 Claude Opus 4.7 加上 Skill，在 Claude Code 中通过率是 61.2%，在 OpenHands 中是 53.1%；Gemini 3.1 Pro 在 Gemini CLI 中是 60.8%，在 OpenHands 中是 52.8%。论文的结论是，Skill 不只是多出来的一段上下文，Harness 如何发现、提示、执行 Skill，决定了 Skill 实际能带来多少收益。
还有一个容易被忽略的变量：同时安装的其他 Skill。以 Claude Code 为例，官方文档说明，Skill 列表默认只占用上下文窗口的 1%。Skill 一多，列表就放不下，Claude Code 会从最少被调用的 Skill 开始删掉描述，只保留名称。每个 Skill 的描述本身也会在 1,536 个字符处截断。
也就是说，同一个 Skill，在装了 5 个 Skill 的环境里能正常触发，到了装了 50 个 Skill 的环境里可能就不触发了，而 Skill 本身一个字都没改。所以评测环境里安装的 Skill 集合，要和生产环境一致，并且固定版本。
固定：模型、Harness 及其版本、其他已安装的 Skill、工具、知识库、数据集、评分器、执行环境
改变：目标 Skill（无 → 有，或者 旧版本 → 新版本）
用 Harbor 实现时，可以在任务环境里预置生产环境的 Skill 集合，再通过 Job 的 --skill 参数注入目标 Skill。同名的 Skill 会被注入的版本替换，所以同一批任务跑两个 Job，一个注入旧版本，一个注入新版本，就得到了一组对照。Harbor 会把 Skill 放到各个 Agent 原生的位置：Codex 是 $HOME/.agents/skills，Claude Code 是 $CLAUDE_CONFIG_DIR/skills。从 Git 仓库引入的 Skill 会被解析到具体的 commit，版本是确定的。
准入：评测之前先过安全门禁
Skill 是一组会被 Agent 执行的指令和脚本，本质上是软件供应链的一部分。Anthropic 的建议是：只安装来源可信的 Skill；来源不够可信时，使用前要完整审查，重点看代码依赖、附带的脚本和资源，以及要求连接外部网络的指令。
这不是理论风险。Snyk 在 2026 年 2 月扫描了 ClawHub 和 skills.sh 上的 3,984 个 Skill：13.4% 至少有一个严重级别的问题，包括分发恶意软件、提示注入和暴露密钥；人工确认了 76 个恶意载荷。其中一种手法很隐蔽：Skill 里写一句从远程地址下载并执行指令的命令，审查时看不出问题，攻击者之后随时可以修改远程内容。
准入检查可以分三层：
- 静态检查：格式、脚本、密钥、个人信息、许可证。NVIDIA SkillEvaluator 的第一层就是这些确定性检查。
- 重复检测：用向量相似度找出和已有 Skill 内容重叠的 Skill。SkillEvaluator 的第二层做的就是这件事。两个 Skill 描述相似，往往意味着之后会抢同一类任务，触发评测时要重点关注。
- 动态检查：在沙箱里运行，记录网络外联和文件访问范围，判定方式和第 02 篇的安全合规一样。
静态检查替代不了实际运行。NVIDIA 的 ACES 用两种扫描方法检查了 145 个真实 Skill：一种是结构检查，一种是让 LLM 阅读 Skill 文档后打分。两者的通过率分别是 94.5% 和 86.2%，但分数之间的 Spearman 相关系数只有 0.14，两种扫描方法彼此都对不上。更根本的问题是，扫描只读 Skill 文件，不运行它。ACES 列出了几种扫描发现不了的失败：
- 用户问了相关的问题，Agent 却没有发现这个 Skill；
- Agent 读了文档，却调用了错误的脚本或参数；
- Agent 得到了正确的结果，却理解错了，报告也是错的；
- 这个 Skill 和环境中已有的另一个 Skill 冲突；
- 模型更新改变了 Agent 理解文档的方式，Skill 悄悄退化。
这几种失败，分别对应后面要讲的触发、遵循、第 02 篇的虚报完成、已安装 Skill 的干扰，以及模型升级后的复测。静态检查适合当门禁，不适合当效果评价。
增益：成对对照，计算 Skill Lift
Skill 有没有用，要靠对照实验回答：同一条用例，在同一个模型、同一个 Harness、同一个环境、同一套评分器下，有 Skill 和没有 Skill 各跑一遍，两者的差就是 Skill Lift。这是 ACES 给出的定义，SkillsBench 和 NVIDIA SkillEvaluator 也用同样的方法。
对照组怎么选，参考 Anthropic 的 skill-creator：
- 新建 Skill：对照组是不装这个 Skill。
- 修改已有 Skill：对照组是修改前的版本。修改前先把旧版本存一份快照。
skill-creator 还要求把实验组和对照组放在同一批次里同时启动，让它们差不多同时结束。这样做也能避开第 01 篇讲的执行环境噪声：通过率会随时段波动，先跑完旧版本、隔天再跑新版本，差异里就会混进时段的影响。
按用例配对比较
比较两个版本时，不要分别算出两个平均通过率再相减，而要先算每条用例上的差，再对差值做统计。Evan Miller 在 Adding Error Bars to Evals 中说明了原因：两个版本跑的是同一批用例，用例本身的难易对两边影响相同，配对相减可以把这部分波动抵消掉，置信区间因此更窄。怎么计算置信区间，第 06 篇展开。
配对还有一个好处：能看到每条用例的变化方向。平均提升掩盖了退化的用例。SkillsBench 的平均提升是 16.6 个百分点（从 33.9% 到 50.5%），但 87 个任务中有 13 个在加上 Skill 后变差了；ACES 统计的 947 组配对中，只有 72.8% 是正向提升。所以报告里要按用例列出三类结果：
| 结果 | 处理 |
|---|---|
| 提升 | 确认提升来自 Skill，而不是随机波动 |
| 持平 | 检查断言是否有区分度，见下文 |
| 退化 | 逐条对比两组轨迹，找出 Skill 在哪一步把 Agent 带偏了 |
SkillsBench 分析了 Skill 让结果变差的轨迹，总结出三种模式：Skill 规定了一套不必要的重型流程；Skill 替换掉了模型原本更好的做法；Skill 让 Agent 使用一个它无法调试的工具。共同的原因是：Skill 只给了一条“唯一正确”的流程，没有写清适用边界，也没有提供轻量的备选方案。
断言有没有区分度
skill-creator 在汇总结果后，会逐条检查断言：
- 有没有 Skill 都通过：这条断言测不出 Skill 的价值，应该替换；
- 有 Skill 时通过、没有时失败：这条断言证明了 Skill 的价值；
- 结果时好时坏：断言本身不稳定，或者行为有随机性。
最后一点：增益要和代价一起报告。skill-creator 的汇总表同时列出通过率、耗时和 Token 用量的均值、标准差，以及与对照组的差值。
触发：该用的时候用，不该用的时候不用
触发评测要同时测两个方向。skill-creator 的做法是准备大约 20 条查询：
- 应该触发（8–10 条）：同一意图的不同说法，有正式也有口语；包括用户没有提到 Skill 名称、但显然需要它的情况；以及这个 Skill 和其他 Skill 存在竞争、但应该胜出的情况。
- 不应该触发（8–10 条）：最有价值的是“近似但不该触发”的查询，它们和 Skill 共享关键词或概念，实际需要的却是别的东西。“写一个斐波那契函数”作为 PDF Skill 的反例就太容易了，什么也测不出来。
每条查询执行多次，得到触发率。skill-creator 默认每条执行 3 次。还要注意一个前提：模型只在自己不容易直接完成的任务上才会去查阅 Skill。像“读一下这个文件”这种简单的一步任务，描述写得再好也可能不触发。所以触发用例要有一定的复杂度。
从轨迹判定是否触发
- Claude Code：调用了
Skill工具，并且参数是目标 Skill。Claude Code 自带的claude plugin eval就提供tool_used: Skill这种评分器。 - 通用做法：轨迹中出现读取目标 SKILL.md 的操作。skill-creator 的触发检测同时认这两种信号；SkillsBench 也是按“轨迹中读取或调用了该 Skill”来统计调用率的。
据此算出两个指标：应触发集合上的触发率（越高越好），不应触发集合上的误触发率（越低越好）。
优化描述时防止过拟合
描述决定了触发。根据触发评测的结果反复修改描述，很容易把描述改成只对这 20 条查询有效。skill-creator 的描述优化循环是这样防止过拟合的：把查询按 60/40 分成训练集和留出测试集，根据训练集上的失败修改描述，最多迭代 5 轮，最终按测试集分数而不是训练集分数选择版本。
Skill 多了以后，触发会变难
SkillsBench 发现，在它的设置下，“找到 Skill”通常不是瓶颈。但它的每个任务只配了少量 Skill。规模变大后情况就不同了：SkillRouter 在约 8 万个候选 Skill 的场景中发现，如果只看名称和描述、不看 Skill 正文，选对 Skill 的准确率会下降 37 到 44 个百分点。再加上前面提到的 Claude Code 列表预算，企业内的 Skill 越积越多时，触发评测会越来越重要。
遵循：加载了，不等于照做
SkillsBench 还发现，Skill 调用率高并不保证任务成功，很多失败发生在 Agent 已经读到 Skill 之后。论文也观察到，有的 Harness 会“承认” Skill 的内容，但实际执行时并不照做。另一项针对 500 个真实 Skill 的研究发现，不同模型对 Skill 指令的遵循程度差异很大，由此带来的收益差异也很大。这项研究把“是否遵循 Skill 指令”和“是否完成任务目标”分成两个评分维度。
遵循度可以用第 02 篇的检查点方法评估：把 SKILL.md 中的关键步骤变成检查点。比如周报 Skill 要求“用 scripts/calc.py 计算环比”，就检查轨迹里是否执行了这个脚本，而不是让模型自己心算。
Claude Code 的文档还给出了两个和遵循有关的经验，评测时值得专门设计用例：
- 每次都必须执行的规则，不要只写在 Skill 里。模型可能在某一步忽略它，这类规则应该移到 Hook，由 Harness 确定性地执行。
- 长任务中，Skill 可能被“遗忘”。上下文压缩后，Claude Code 可能只保留 Skill 内容的开头，所以重要的指令要写在 SKILL.md 的前面。对应的评测用例是：任务足够长、会触发压缩，检查后半程是否仍然遵循 Skill。
把触发和遵循分开测，失败就能被定位：
| 现象 | 问题所在 | 修什么 |
|---|---|---|
| 没有读取 SKILL.md | 触发 | 描述 |
| 读取了，但关键步骤没做 | 遵循 | 指令写法，或改用 Hook |
| 步骤都做了，结果仍然错 | 内容 | Skill 中的知识和流程本身 |
通过率之外：Skill 改变了什么
即使通过率不变，Skill 也可能大幅改变 Agent 的行为。Counterfactual Trace Auditing 把同一任务上有 Skill 和没有 Skill 的轨迹分段对齐，逐段比较。在 49 个软件工程任务上，通过率平均只变了 0.3 个百分点，却识别出 522 处行为变化，包括：
- 照抄 Skill 中的模板；
- 产出任务没有要求的文件；
- 过度规划；
- 从错误中恢复。
论文还发现，大部分行为变化出现在基线通过率本来就很高的任务上。这些任务的通过率已经饱和，所以变化体现不出来。基线中等的任务提升空间最大，但往往伴随明显更高的 Token 成本。
这些发现可以转成几条具体的检查：
- 模板照抄：SKILL.md 示例中的具体数值和名称，是否原样出现在产物里。
- 多余产物：产物目录中是否出现任务没有要求的文件。
- 执行量差异：同一用例上，有 Skill 和没有 Skill 的工具调用次数、Token 用量相差多少。
- 重复劳动：skill-creator 建议阅读多条用例的轨迹，如果每次执行都在临时编写相似的辅助脚本，说明应该把这个脚本做进 Skill。
模型升级后：Skill 还有没有价值
Skill 的价值取决于模型。SkillsBench 发现，加了 Skill 的小模型可以追上没加 Skill 的大模型；而当模型本身已经很擅长某类任务时，Skill 的收益就会变小，甚至变成负数。
所以模型升级时，要用 2×2 的设计重新测一遍：
| 无 Skill | 有 Skill | |
|---|---|---|
| 旧模型 | A | B |
| 新模型 | C | D |
旧模型上的 Skill Lift 是 B − A，新模型上的是 D − C。比较两者：
- 基本不变：Skill 继续保留。
- 接近 0：新模型已经掌握了这些知识，Skill 可以精简或下线。下线还能省下上下文：Skill 列表里的每个 Skill，都会在每一轮对话中占用上下文，不论它有没有被用到。
- 变成负数：Skill 开始拖后腿。一个常见原因是 Skill 替换掉了新模型更好的默认做法，这正是 SkillsBench 总结的退化模式之一。需要修改或下线。
为每个 Skill 记录它在每个模型版本上最近一次的 Lift 和评测日期，模型升级后的复测就有了依据。
这也给 Skill 的写法提供了数据支持。SkillsBench 的消融实验显示：一个任务配 1 个 Skill 提升 18.0 个百分点，配 2 到 3 个提升 19.0，配 4 个及以上只提升 10.1；简短和标准篇幅的 Skill 分别提升 19.0 和 21.5，写得很详细的提升 14.5，写成大而全的文档只提升 0.7。另一个结论更值得警惕：用 skill-creator 让模型自己生成的 Skill，在三种配置上都比不装 Skill 还低 8.1 到 11.5 个百分点。自动生成的 Skill 必须和人写的 Skill 一样经过成对对照，才能进入生产环境。
一份 Skill 评测报告
把以上环节汇总到一份报告里。下面的数值仅作示意：
Skill：周报生成 v1.3 → v1.4
固定：模型、Harness 及其版本、其他 12 个已安装的 Skill、数据集 v5、评分器 v3、执行环境
对照：v1.3，同一批次交替运行，每条用例 n = 5，共 40 条用例
准入 静态检查通过；与“销售日报”Skill 描述相似度高，已补充区分说明
触发 应触发 19/20（95%），误触发 1/20（5%）
遵循 关键步骤命中率 91%（v1.3 为 84%）
增益 通过率 62% → 74%，Skill Lift +12pp，配对 95% 置信区间 [+5, +19]
提升 8 条，持平 30 条，退化 2 条，每条附轨迹对比
代价 单任务成本 +9%，耗时 +4%
行为 多余产物 0 次，模板照抄 1 次
结论 发布；退化的 2 条用例加入回归集
小结
- Skill 评测是 Agent 评测的特例：固定模型、Harness、其他已安装的 Skill 和整套评测环境，只改变目标 Skill。
- 五个环节分开测：准入、触发、遵循、增益、代价。通过率只反映最后结果，分开测才能知道该修描述、指令还是内容。
- 增益靠成对对照：同一批次运行，按用例配对比较，逐条检查退化的用例，同时报告代价。
- 触发要测两个方向：应触发和不应触发，反例选近似的查询；优化描述时用留出集防止过拟合。
- 模型升级要复测：用 2×2 设计比较 Skill Lift，Lift 消失或变成负数的 Skill 要精简或下线。
下一篇讲评分器：规则、脚本、LLM Judge 和人工评分各适合什么，以及怎样确认评分器本身是可信的。