同一批任务，加入 Skill 后通过率提高了。这个结果很容易让人想立即扩大技能库。但如果新配置多用了几轮模型调用、额外读取了任务相关文档，或者只有本来就容易成功的请求被统计进去，涨分究竟说明了什么？
我关心的不是给技能寻找一个好看的平均分，而是判断它在什么任务上补足了能力，在什么任务上引入了干扰，以及为此付出了多少成本。一次评测首先要说清楚自己改变了什么，然后才有资格解释分数。
本文结合 SkillsBench、SWE-Skills-Bench、Skill-Usage 和 Skill Coverage，整理一套适合 Agent 框架的评测思路。论文数字均为作者在各自配置下报告的结果，不跨模型、跨任务直接排名；协议、算例与工程判断由本文提出，未独立重跑这些实验。
1. 用“可用条件”定义实验
先看一个简单问题：如果统计所有“真正读取过技能”的请求，通过率会不会比没读的更高？这个比较看似直观，却可能把任务难度混进来。困难任务更容易触发搜索，也更容易失败；简单任务不读技能也能完成。
因此，部署实验更适合比较“分配到技能可用条件”与“分配到技能不可用条件”的结果。两组使用相同任务分布、模型、工具与预算。Agent 是否选择读取、是否实际收到材料、是否遵循指令，再作为中间过程分析。
这里的预算也要具体：最大步数相同，并不保证模型调用数和 token 相同；工具调用不算环境步数，也不表示没有成本。先固定允许使用的资源，再记录实际消耗，才能区分同预算下质量提高和增加计算后的质量提高。
图 1：配对评测的基本结构。每个条件从干净环境开始，不能继承另一条件生成的产物或记忆。
实验记录至少包含四个快照：任务与验收器、模型与执行框架、技能包与资源、索引与选择策略。若技能不变但索引变了，或者工具在两轮之间升级，就需要明确标注。一个技能版本号不足以描述整个实验条件。
2. 三类基准回答三个不同问题
SkillsBench v4 将 87 个任务、8 个领域与确定性验证器配对，在 18 种模型—Harness 配置中比较有无整理好的技能。作者报告平均通过率从 33.9% 提高到 50.5%，增加 16.6 个百分点。1 这说明技能在该基准上具有总体价值，也提醒我们：结果依赖具体任务、技能质量与宿主，不能当作任何产品的默认增益。
确定性验证器的意义是同一产物可以按固定规则判定，它并不保证规则覆盖了所有用户需求。表格数字算对了，但用户要求的透视表对象没有创建，仍然可能不合格。评测设计必须将需求落到最终产物，而不是只检查 Agent 的完成声明。
SWE-Skills-Bench 则研究软件工程需求验收。其 Claude Code 与 Haiku 4.5 设置下，49 项技能的平均通过率从 89.8% 到 91.0%，输入输出 token 均值从 303K 到 335K；39 项技能的净通过率不变、7 项上升、3 项下降。2 这是另一种任务与基线水平，不能拿 1.2 个百分点直接否定前一个基准的价值。
“净通过率不变”也不等于没有任何影响。某些任务可能被修复，同时另一些任务发生回归；只有逐题配对结果能分清这些情况。基线已经接近天花板时，技能的主要价值还可能体现为降低成本，或提高某个关键子群体的可靠性。
Skill-Usage 进一步移除“有人已经替 Agent 挑好技能”的理想前提。论文从整理好的技能出发，逐步引入自主选择、干扰项与全库检索，观察能力收益如何在现实选择链中损失。3 这类实验帮助区分：技能内容不够好，还是系统无法稳定地找到并使用它。
| 评测问题 | 代表工作 | 能支持的判断 | 仍需额外验证 |
|---|---|---|---|
| 高质量技能有没有边际价值 | SkillsBench | 固定任务中的有无技能差异 | 真实大库的选择与维护 |
| 能否满足具体工程需求 | SWE-Skills-Bench | 需求映射的产物验收 | 其他模型、任务与接口 |
| 收益在哪个选择环节丢失 | Skill-Usage | 不同可见性与检索条件的变化 | 各环节独立作用及全部成本 |
| 技能要求是否被充分测试 | Skill Coverage | 行为约束的覆盖与满足情况 | 未抽取的要求和真实业务完整性 |
这张表不提供统一排行榜。不同基准的价值，是让我们看到不同的缺口。上线前仍需用自己的任务分布、权限边界与失败代价重新定义验收。
3. 保留一个负例，比多报一个总分更有用
SWE-Skills-Bench 展示了一个 Linkerd 配置案例：任务需要特定版本下的 gRPC 与 mTLS 配置，近似技能模板却引入了旧版本、其他协议和不适用字段。2 它说明技能可能把模型已有的正确知识带偏，而不仅是“没有提供帮助”。
这类问题很适合继续做有边界的对照：完整模板、只保留任务匹配模板、显式标注版本与协议前置条件。模型、任务和预算保持一致，观察改善来自删掉干扰还是补足缺失知识。这个三条件实验是本文建议，不是原论文已经报告的结果。
对应到 C 端产品，类似失败经常发生在相近意图上：用户只要导出静态报表，技能坚持保留复杂编辑结构；用户要求保留公式，示例却默认转值。评测集需要主动包含“看起来相似，但关键约束相反”的成对任务，否则无法检验触发边界。
负例还应描述系统本来可以做到什么。只有展示无技能和有技能条件下的差异，才能发现新增材料带来的回归。单独展示技能条件的错误轨迹，无法判断它是新引入的问题，还是模型一直存在的弱点。
4. 用事件链定位收益为什么没有兑现
最终任务失败后，仅增加一条“技能未遵循”的标签通常不够。需要检查失败最早出现在哪一层：候选没有覆盖能力，选择了错误版本，正文读取失败，关键条件没被执行，还是验收器漏掉了要求。
| 事件 | 证据 | 常见误判 |
|---|---|---|
| 候选覆盖 | 标注能力与候选集合 | 名称相近就算召回正确 |
| 选择 | 已采用技能及理由 | Top K 出现过就算选中 |
| 成功披露 | 对应调用的真实读取结果 | 发起 Read 就算读到了 |
| 行为遵循 | 动作与产物满足适用约束 | 模型提到规则就算遵循 |
| 任务验收 | 最终结果覆盖用户需求 | 自报完成就算成功 |
Skill Coverage 将技能说明中的行为要求转成可检查约束，再分析轨迹是否覆盖、是否满足。4 这个思路能帮助我们找到“有规则，却没有被测试”的区域。但约束抽取和轨迹判断都可能遗漏，因此覆盖率应该作为诊断指标，不能替代任务验收。
同样，Skill-Usage 的公开读取检测实现提醒我们，工具名、路径匹配和文本解析只是读取信号的近似。5 如果日志无法关联调用与结果，应保留未知，而不是强行归为已读取或未读取。否则，下一轮优化可能在修复一个由监控误差制造的问题。
图 2：本文建议的诊断路径。它用于安排检查顺序，不能单凭一次轨迹证明因果。
5. 同时报告修复、回归和成本
设共有 N 个配对任务，原版本失败、技能版本成功的数量是 repairs；原版本成功、技能版本失败的数量是 regressions。净通过率变化就是 (repairs - regressions) / N。这是配对计数关系，不是新提出的算法指标。
例如 100 个任务中修复 15 个、回归 12 个，与修复 3 个、回归 0 个，净变化同为 3 个百分点。但两种配置对用户的影响明显不同：前者需要更仔细地看哪些任务退化，以及错误是否集中在关键需求上。这个数字例子仅用于解释，不来自真实实验。
成本至少区分离线构建与在线执行。离线包括技能生成、选择评测、索引构建与维护；在线包括模型 token、工具调用、环境交互、重试、时延和人工干预。若一个候选只能通过大量重试达到高分，应同时展示首次成功率和全部搜索成本。
我更倾向于先用质量—成本二维比较，再讨论具体产品的权重。质量不降、成本下降的方案比较容易判断；质量上升、成本也上升则需要业务决策。把质量变化除以相对成本变化，在分母接近零时会非常不稳定，成本下降时符号也容易误导。
上线门槛也不应只有一个总体平均数。一个配置即使总体更好，只要在不可接受的约束上退化，就不能直接推广。对重要任务分片、拒绝与澄清行为，以及严重错误，应单列报告，而不是让多数简单任务冲淡它们。
6. 一套最小而有解释力的实验
对于“编辑表格并保留公式”这样的能力，可以从四个条件开始。它们用来拆分技能内容与选择系统的作用，不要求所有项目同时实现完整矩阵。
| 条件 | 给 Agent 什么 | 主要比较目的 |
|---|---|---|
| A | 无技能，原有工具与预算 | 建立基线 |
| B | 人工确认适用的技能可用 | 估计内容在较理想条件下的价值 |
| C | 真实候选库与当前路由 | 估计真实部署效果 |
| D | 与 C 相同，只改变一个待验证环节 | 判断路由、披露或规则修改的贡献 |
每个条件在独立环境中执行同一组任务。外部资源尽量冻结；无法冻结的服务记录版本、时间与变更。对随机系统采用重复运行，并报告不确定性。重复次数应由波动程度与决策风险决定，不存在“跑一次过了就足够”的通用门槛。
任务集除了典型成功路径，还应包含公式与静态值要求相反的样本、缺失输入、格式异常、旧版本文件、读写权限限制，以及无须使用技能的简单任务。后者能检查技能是否过度触发，防止“凡是表格都走复杂流程”。
开发集用于诊断与生成候选，选择集用于接受或拒绝，最终测试集用于报告。相近模板、同源文档和同一用户的连续轨迹可能造成泄漏，切分时应按数据来源或任务族考虑，而不只是随机按行分三份。
验收器同样需要测试。可以主动制造公式丢失、文件路径正确但内容过期、伪造完成说明等坏结果，确认检查器会拒绝。一个从未拒绝过坏产物的验收器，即使输出完全确定，也不足以支撑可靠性结论。
最后，将报告写成可以用于决策的几句话：在哪个任务范围内，哪项变化修复了多少问题、引入了哪些回归，成本如何改变，还有哪些结论无法从当前证据推出。这样评测才能反过来指导经验优化与版本发布。
Skill 的价值不是“用了之后分数更高”这一句话，而是一个有条件的判断：对这些任务，在这些资源与约束下，它带来了可重复、可解释的改善。 一份好的评测报告也应允许得出结论：此处暂时不用技能更合适。
参考资料
- SkillsBench，arXiv:2602.12670v4：87 任务、8 领域、18 种模型—Harness 配置；作者仓库。
- SWE-Skills-Bench，arXiv:2603.15401v1：Table 2 的总体与逐技能结果，Figure 5 的 Linkerd 案例。
- How Well Do Agentic Skills Work in the Wild，arXiv:2604.04323v1：真实选择与检索条件。
- Skill Coverage，arXiv:2606.20659v2：技能行为约束的测试充分性。
- Skill-Usage 官方实现：
scripts/prepare_experiment.py与check_skill_usage.py。底稿为 2026-09-27 的静态代码观察，main 后续变化需重新核对。
2026-10-07 合并修订。上述不同论文的模型、环境、任务与验收口径不同，本文只作方法比较，不给跨基准性能排名。
