1. 从一次"感觉变好了"的争论说起
给 Agent 挂上 Skill 之后，它到底有没有变强？这个问题在团队里几乎每隔两周就要吵一次。支持派说加了 Skill 之后任务完成率肉眼可见地上升，反对派说那只是心理作用，模型本身没变，多塞几段提示词而已。两边都拿不出硬证据，最后往往靠"谁嗓门大"收场。
我最初也是凭感觉站队的那一批。直到有一次，同一个任务在加了 Skill 之后连续三次跑出完全不同的结果，我才意识到："感觉变好了"是评测里最危险的信号。它既可能来自真实的能力提升，也可能来自任务采样偏差、随机种子波动，甚至只是我记住了成功的那几次、忘掉了失败的那几次。
所以这篇东西不聊"Skill 有多神"，只聊一件事：怎么用对照评测，把"变好了吗"这个问题变成一个能被数字回答的问题。适合正在做 Agent 开发、已经上手过 Claude Skills 或类似 skill-creator 流程、但还没建立起评测习惯的人。如果你只是想知道 Skill 是什么，网上教程一抓一大把；但如果你已经挂了一堆 Skill，却说不清它们到底贡献了多少，那接下来的内容应该对你有用。
我会按"先定义清楚要测什么 → 再设计对照 → 然后处理那些让评测失真的坑 → 最后看数据怎么读"的顺序展开。中间会穿插我自己踩过的坑，包括一次因为评测集泄漏导致结论完全反过来的事故。
2. 先搞清楚：Skill 到底改变了 Agent 的哪一层
2.1 Skill 不是模型能力，是上下文与流程的注入
很多人评测 Skill 时犯的第一个错误，是把 Skill 当成"给模型升级"。不是的。Skill 本质上是一段被结构化组织的指令、知识或工具调用范式，它在运行时被注入到 Agent 的上下文里，改变的是模型看到什么、按什么顺序做事、在什么条件下调用什么工具。
理解这一点非常关键，因为它直接决定了你该测什么。模型权重没变，所以纯知识问答类任务（比如"法国的首都是哪"）加不加 Skill 基本没差别——这类任务不该进你的评测集，它们只会稀释信号。真正该测的是那些依赖流程编排、依赖领域约束、依赖工具调用时机的任务。
我一般把 Skill 的影响拆成三层来看：
- 知识层：Skill 里塞了模型原本不知道或记不准的领域事实。测法是问那些"没有 Skill 必错、有 Skill 才对"的问题。
- 流程层：Skill 规定了做事步骤，比如"先查再算再校验"。测法是看多步任务的中间步骤是否合规。
- 工具层：Skill 定义了何时调用哪个工具、参数怎么填。测法是看工具调用的准确率和冗余率。
三层混在一起测，你就永远说不清是哪里起了作用。我建议评测集按这三层分别打标签，后面分析时才能定位。
2.2 为什么"对照"是唯一能排除噪声的手段
Agent 的输出天然带随机性。同一个 prompt，temperature 不为零时每次结果都可能不同；就算 temperature 设为零，工具返回的网络内容、时间戳、检索结果也可能变。这意味着单次对比毫无意义——你加 Skill 跑一次成功，不加跑一次失败，什么都证明不了。
对照评测的核心逻辑是：控制变量，重复采样，比较分布而不是比较单点。具体来说，同一批任务，一组挂 Skill（实验组），一组不挂（对照组），每组每个任务跑 N 次，然后比较两组的成功率、平均步数、工具调用次数等指标的分布差异。
这里有个容易被忽略的点：对照组不是"什么都不加"，而是"加一个等量的占位内容"。如果你实验组多塞了 2000 token 的 Skill，对照组却是空的，那你测出来的差异里混进了"上下文长度"这个变量。严谨的做法是给对照组也塞 2000 token 的无关但通顺的文本，让两组在 token 量级上对齐。这个细节我在第三次评测时才补上，之前两轮的结论都得打问号。
2.3 一个常被混淆的概念：Skill 与 harness 的分工
热词里经常出现 harness 和 agent 的区别、deepseek harness 附带 skill 怎么部署这类问题，说明很多人对这两者的边界是模糊的。简单说，harness 是承载 Agent 运行的外壳——它负责调度、上下文管理、工具注册、循环控制；Skill 是挂在这个外壳上的可插拔能力包。
这个区分对评测很重要：如果 harness 本身在两次评测之间改过（比如升级了上下文压缩策略），那 Skill 的效果就被污染了。所以评测期间要冻结 harness 版本，把它当成不变的底座。我吃过这个亏——有一次中途更新了 harness 的工具重试逻辑，结果实验组的成功率涨了 8 个百分点，我差点以为是 Skill 的功劳，回头一查日志才发现是重试次数从 1 次变成了 3 次。
3. 设计一份不会骗自己的对照评测
3.1 评测集怎么选：从真实失败案例倒推
最省事也最没用的做法，是让模型自己生成评测题。那样选出来的题往往偏简单、偏模板化，区分度极低。我的做法是从线上真实的失败案例里倒推：把过去两周 Agent 跑挂的任务捞出来，人工归类，每类挑 5 到 10 个有代表性的，改写成可复现的评测用例。
这样选出来的题有两个好处：一是贴近真实分布，二是天然有区分度——毕竟它们本来就是失败过的。我一般会控制评测集在 30 到 50 题之间，太少统计不稳，太多跑一轮成本吃不消。每题要记录：任务描述、期望输出、判定标准、所属层级（知识/流程/工具）、难度分级。
判定标准这块要特别小心。能用精确匹配或规则判定的绝不用模型打分，因为模型打分本身就有方差，会把 Skill 的效果淹没在评分噪声里。实在需要主观判断的（比如文案质量），我会用两个不同模型交叉打分，取一致性高的部分，分歧大的样本直接剔除。
3.2 采样次数与统计口径：别用一次结果下结论
每个任务每组跑几次？我的经验是至少 5 次，理想 10 次。跑 1 次你测的是运气，跑 3 次勉强能看出趋势，跑 5 次以上分布才开始稳定。成本敏感的话，可以先用 5 次做粗筛，对差异接近阈值的任务再补到 10 次。
统计口径上，我关注四个指标：
| 指标 | 含义 | 为什么重要 |
|---|---|---|
| 任务成功率 | 通过判定的比例 | 最直观，但会被简单任务拉高 |
| 平均交互步数 | 完成任务用的轮次 | 反映流程效率，Skill 常在这里见效 |
| 工具调用准确率 | 正确调用/总调用 | 定位工具层问题 |
| 失败模式分布 | 各类失败占比 | 比成功率更能说明问题在哪 |
只看成功率是不够的。我遇到过一种情况：加 Skill 后成功率没变，但平均步数从 12 步降到 7 步，工具调用冗余大幅减少。这说明 Skill 没让它"更对"，但让它"更省"。如果只盯成功率，这个价值就被漏掉了。
3.3 控制变量的清单：那些偷偷影响结果的家伙
设计对照时，下面这些变量必须锁死，否则结论不可信：
- 模型版本与参数：同一个模型快照，temperature、top_p、max_tokens 全部固定。
- harness 版本：评测期间不升级，工具重试、超时、上下文压缩策略全部冻结。
- 工具集：两组用完全相同的工具，包括工具的返回内容（网络类工具最好用录制的固定响应，避免实时数据波动）。
- 上下文长度：实验组和对照组的注入内容 token 量对齐。
- 随机种子：能设就设，不能设就靠多次采样平均掉。
- 运行环境：同一台机器、同一时段，避免负载差异影响超时判定。
提示：把这份清单做成一个 checklist，每轮评测前逐项打勾。我见过太多"结论反转"的事故，最后追根溯源都是某个变量没锁住。
4. 那些让评测结果失真的坑，我一个个踩过
4.1 评测集泄漏：一次让结论完全反过来的事故
这是我最惨的一次。第一轮评测，实验组成功率比对照组高 15 个百分点，我兴冲冲准备写结论文档。结果同事随口问了句："你的评测题是不是从 Skill 文档里抄的？"我一查，傻眼了——评测集里有将近三分之一的题，其标准答案的表述方式和 Skill 里的示例几乎一字不差。
这就是典型的评测集泄漏：评测内容与 Skill 内容高度重叠，模型不是"学会了"，而是"背过了"。修正方法是把评测题改写成与 Skill 表述完全不同的措辞，甚至换一批场景。重跑之后，成功率差距从 15 个百分点缩到 4 个百分点，而且集中在流程层任务上。这个真实数字才有参考价值。
教训很直接：评测集和 Skill 内容必须来自不同来源、不同措辞。写完评测集后，拿它和 Skill 文本做一次相似度检查，重叠度高的题直接换掉。
4.2 判定器的偏差：规则太严和太松都会骗你
判定标准的设计比想象中难。规则太严，实验组明明做对了但因为格式差一个标点被判失败；规则太松，对照组瞎蒙也能过。我一般会先用一批"已知正确"和"已知错误"的样本去校准判定器，确保它能正确区分这两类，再拿去评 Agent 输出。
还有一个隐蔽的坑：判定器对某一种输出风格有偏好。比如用模型打分时，如果 Skill 让输出变得更结构化、更像"标准答案"，打分模型可能因为风格相似而给高分，而不是因为内容真的更对。规避办法是让打分模型只看内容要点，不看格式，或者干脆用规则抽取要点再比对。
4.3 任务难度分布：简单题会掩盖真实差异
如果评测集里 80% 是简单题，两组都能轻松通过，那 Skill 的效果就被天花板效应盖住了。反过来，如果全是难题，两组都挂，也看不出差异。理想分布是简单、中等、困难各占三分之一左右，并且分层统计。
我习惯在报告里按难度分层给结果，而不是只给一个总分。因为 Skill 往往在中等和困难任务上见效明显，在简单任务上几乎无差别。只报总分，等于把这个规律抹平了。
4.4 成本与延迟：被忽略的"负向指标"
Skill 不是免费的。它占用上下文、增加 token 消耗、可能拖慢响应。如果加 Skill 让成功率涨了 3 个百分点，但 token 成本翻了一倍、延迟增加 40%，这笔账要算清楚。我在评测报告里一定会附上每任务平均 token 消耗和端到端延迟，作为负向指标一起看。
有时候结论是"Skill 在核心任务上值得，在边缘任务上不划算"，这种精细结论比"Skill 有用/没用"有价值得多。
5. 数据出来之后，怎么读才不被自己骗
5.1 看分布，不看均值：方差往往比均值更有信息
两组成功率 70% 对 65%，听起来实验组赢了。但如果实验组的方差极大——有的任务 100% 通过，有的 0%——那这个 70% 是"平均"出来的假象，实际表现极不稳定。我会同时看成功率的中位数、四分位距和极值。
一个实用技巧：把每个任务两组的成功率画成散点图（横轴对照组、纵轴实验组），落在对角线上方的点是"Skill 帮上忙的"，下方是"帮倒忙的"。我做过一次，发现有 6 个任务加 Skill 后反而变差，追查发现是 Skill 里的某条约束和这些任务的场景冲突，导致模型过度遵守规则而忽略了任务本身。这种"负向任务"是优化 Skill 的金矿。
5.2 失败模式分析：比成功率更能指导下一步
成功率告诉你"有没有变好"，失败模式告诉你"为什么"。我会把两组的失败案例都人工过一遍，归类成：知识缺失、流程跳步、工具误用、格式错误、超时等。然后对比两组的失败模式分布。
如果实验组的"流程跳步"大幅减少但"工具误用"增加，说明 Skill 在流程层有效，但工具层的指令可能写得太模糊或太死板。这种定位是单纯看成功率得不到的。我一般会为每个失败模式建一个计数表，评测跑完直接出分布对比。
5.3 显著性：小样本下的差异可能只是噪声
30 题、每组跑 5 次，总共 150 个样本。这个量级下，几个百分点的差异很可能不显著。我一般会用简单的比例检验（比如两比例 z 检验）粗筛一下，p 值大于 0.05 的差异先不当结论，标记为"需扩大样本"。
不是要搞得多学术，而是避免把噪声当成果。我见过团队因为一次 3 个百分点的"提升"就大改 Skill 架构，结果下一轮评测发现是随机波动，白折腾两周。
5.4 一个可复用的评测报告模板
跑了几轮之后，我固定下来一个报告结构，分享出来可以直接抄：
- 评测配置：模型、harness 版本、采样次数、评测集规模与难度分布。
- 总体结果：成功率、平均步数、token 消耗、延迟，两组对照。
- 分层结果：按知识/流程/工具三层，按简单/中等/困难三档分别给。
- 失败模式对比：两组的失败类型分布表。
- 负向任务清单：加 Skill 后变差的任务，附初步归因。
- 结论与下一步：哪些 Skill 保留、哪些改写、哪些删除。
这份模板的价值在于，它逼你把"感觉"翻译成"证据"，也逼你在下结论前先看全貌。
6. 关于 Skill 评测，我最后想说的几句实在话
评测这件事，投入产出比在前期是负的——你要花时间建评测集、锁变量、跑多轮、做分析，短期内看不到"功能上线"的快感。但它是唯一能让你在 Skill 越挂越多、系统越来越复杂之后，还说得清"到底哪个有用"的手段。我现在的习惯是：每新增一个 Skill，先跑一轮小规模对照（10 题、每组 5 次），通过了再进正式评测集。这样能把明显无效的 Skill 挡在门外，省下大量后续维护成本。
还有一个反直觉的体会：很多 Skill 的价值不在"提升上限"，而在"稳定下限"。它可能没让 Agent 做出更惊艳的结果，但让它在边界场景下不再乱来。这种价值用成功率不一定测得出来，得看失败模式的收敛程度。所以别只盯着"变好了吗"，也问问"变稳了吗"。
如果你现在手上正好有一堆 Skill 说不清效果，我的建议是从最小的对照开始——挑 10 个真实失败过的任务，跑一轮两组各 5 次，先把流程跑通。数据不用多漂亮，能复现、能解释，就比"感觉变好了"强一百倍。
