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 的输出天然带随机性。同一个 prompttemperature 不为零时每次结果都可能不同就算 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 次先把流程跑通。数据不用多漂亮能复现、能解释就比感觉变好了强一百倍。