1. 从一次失败的Skill上线说起去年年底我给团队内部的一个文档处理Agent加了个合同条款抽取的Skill。逻辑很简单读PDF、定位关键条款、结构化输出。本地测试跑了二十来条样本准确率看着还行我就直接推到了线上。结果第一周就翻车了。用户反馈说Agent在处理某些合同时会把违约责任和争议解决两个条款搞混输出结构也偶尔错位。我一开始以为是模型能力问题换了更强的底座模型情况好转了一点但没根治。后来我把加Skill前后的日志拉出来做了逐条对比才发现问题根本不在模型——是我加Skill的方式有问题。Skill本身引入了新的指令层级和Agent原有的系统提示产生了冲突导致模型在听谁的这件事上摇摆不定。这件事让我意识到一个很现实的问题给Agent装上Skill结果真的变好了吗这个问题不能靠感觉回答得靠对照评测。今天这篇文章我就把这段时间做Agent Skill对照评测的完整方法论、踩过的坑、以及一套可复现的评测流程分享出来。不管你是刚接触Agent开发的新手还是已经在做Skill编排的老手应该都能从中找到能直接用的东西。先明确一下本文的讨论范围这里说的Skill指的是给Agent挂载的可复用能力单元它可能是一段提示词模板、一个工具调用封装、一段脚本逻辑或者几者的组合。对照评测指的是在控制变量的前提下对比有Skill和无Skill或者Skill A和Skill B两种配置下Agent的表现差异。核心关键词包括Agent、Skill、对照评测、Claude Skills、skill-creator这些概念我会在正文里逐一拆解。2. Skill到底给Agent加了什么先搞清楚变量2.1 Skill不是插件它改的是决策路径很多人把Skill理解成插件觉得装上就多一个功能。这个理解在简单场景下没错但在复杂Agent里会误导你。插件通常是被调用时才生效的被动能力而Skill往往会改变Agent的决策路径——它会影响模型在每一步要不要用这个能力怎么用用完怎么继续的判断。举个具体例子。一个没有Skill的Agent处理帮我总结这份财报时它的路径可能是读文件→分段→总结→输出。你给它加一个财务指标提取Skill之后路径可能变成读文件→判断是否财报→调用指标提取→判断是否需要对比→总结→输出。注意这里多出来的不只是提取这个动作还有两个判断节点。判断节点越多出错概率越高这就是为什么加了Skill反而可能变差。所以做对照评测时你要控制的变量不只是有没有Skill还包括Skill引入的判断节点数量、指令优先级、以及它和原有系统提示的关系。2.2 三类Skill的评测重点完全不同我在实操中把Skill分成三类每类的评测重点不一样Skill类型典型形态评测重点常见翻车点提示词型一段角色/流程指令指令遵循度、风格一致性和系统提示冲突工具型封装API或脚本调用准确率、参数正确率该调不调、不该调乱调混合型提示词工具后处理端到端任务完成率中间环节误差累积提示词型Skill最容易做也最容易出隐性冲突。工具型Skill的评测要看调用决策而不只是调用结果。混合型Skill的评测必须做端到端因为中间任何一环的偏差都会放大。提示如果你刚开始做Skill评测建议从提示词型入手因为它的变量最少最容易定位问题。等这套流程跑顺了再上工具型和混合型。2.3 为什么感觉变好了是最危险的信号我见过太多团队用感觉来评估Skill效果。测试几个case觉得输出更专业了就上线。这种做法的问题在于你测试的case往往是你精心挑选的而线上遇到的是长尾分布。更隐蔽的问题是Skill带来的提升可能集中在某几个维度而损害出现在你没关注的维度。比如一个专业术语增强Skill可能让术语准确率从70%提到90%但同时让回答长度增加了40%用户阅读成本上升。如果你只盯着术语准确率就会得出变好了的错误结论。对照评测的价值就在于它强迫你把好拆解成可测量的维度并且在每个维度上做有Skill和无Skill的对比。没有对照就没有真相。3. 搭建一套能复现的对照评测流程3.1 评测集怎么建别用你自己造的题这是我最想强调的一点。很多人的评测集是自己手写的几十条case这些case天然偏向于Skill擅长的场景因为你在写题时脑子里想的就是这个Skill能解决什么。这样的评测集测出来的结果必然好看但没有参考价值。正确的做法是从真实流量里采样。具体步骤从线上日志里随机抽取最近两周的用户请求去掉重复和明显无效的。按任务类型分层确保每类任务都有足够样本建议每类至少30条。对每条请求标注期望输出或可接受输出范围这一步最费时间但省不得。把评测集分成两组调优集用来改Skill和留出集只用来最终验证。如果实在没有线上流量退而求其次的做法是找3个以上不参与Skill开发的人让他们按真实使用场景提需求你只负责记录不引导。这样能最大程度避免自己出题自己答的偏差。3.2 控制变量除了Skill其他都得一样对照评测的核心是控制变量。我列一下必须锁死的项底座模型同一个模型、同一个版本、同一组采样参数temperature、top_p等。系统提示除了Skill引入的部分其余系统提示必须完全一致。上下文长度输入的历史对话轮数、检索到的文档数量要一致。运行环境同一台机器、同一批次运行避免网络和负载波动影响。评测脚本评分逻辑、评分模型如果用模型打分必须一致。我踩过的一个坑是第一次做对照时有Skill组用了新版的系统提示无Skill组还是旧版结果差异里混进了系统提示的贡献白测了一轮。后来我养成了一个习惯——每次评测前把两组的完整输入系统提示Skill用户请求打印出来逐字对比确认只有Skill这一处不同。3.3 评分维度别只算一个准确率单一准确率会掩盖很多问题。我建议至少覆盖以下维度维度说明评分方式任务完成率是否完成了用户的核心诉求人工或模型二分类输出正确性内容事实、逻辑是否正确人工或模型打分1-5格式合规性是否符合约定的输出结构脚本自动校验指令遵循度是否遵守了Skill和系统提示的约束人工抽查响应长度输出token数脚本统计延迟端到端耗时脚本统计调用次数工具调用/判断节点次数日志统计注意响应长度和延迟这两个维度。Skill经常会让输出变长、变慢如果你的产品对这两项敏感它们就是硬指标。我见过一个Skill把任务完成率提了8个点但延迟翻了一倍最后被产品否掉了。3.4 用模型打分时怎么避免自己评自己如果用模型做自动评分有个陷阱评分模型可能和被测模型是同一个它会偏向于自己风格的输出。规避方法有两个一是用不同的模型做评分比如被测用A模型评分用B模型。二是设计评分提示时把评分标准写得极其具体比如输出中必须包含X、Y、Z三个字段缺一个扣一分而不是请评价输出质量。越具体的标准模型的主观偏差越小。还有一个实操技巧让评分模型先输出理由再输出分数。这样你能抽查理由是否合理也能发现评分标准里模糊的地方。4. 实测数据Skill到底在哪些场景下真的有用4.1 一个反直觉的结论Skill对简单任务可能是负收益我拿一个文档问答Agent做了对照实验评测集按任务复杂度分了三层。结果如下数值为任务完成率任务复杂度无Skill有Skill差值简单单轮事实问答94%91%-3%中等多轮信息整合78%85%7%复杂跨文档推理结构化输出61%79%18%简单任务上加Skill反而掉了3个点。原因不难理解简单任务本来就不需要额外能力Skill引入的判断节点反而增加了出错机会。这3个点的差距在统计上不算显著但方向是明确的。这个结论对我的启发是Skill不是越多越好也不是所有任务都该挂Skill。正确的做法是在Agent的路由层做判断简单任务走轻量路径复杂任务才加载Skill。这也是后来我调整架构的主要方向。4.2 工具型Skill的该调不调问题工具型Skill最典型的失败模式不是调用出错而是该调用的时候没调用。我统计过一个数据提取Skill的调用情况应该调用且调用了72%应该调用但没调用21%不该调用却调用了7%那21%的漏调用大部分发生在用户表述比较口语化的时候。比如用户说帮我看看这份材料里有没有提到钱的事Skill的触发条件写的是提取财务数据模型就没触发。解决办法是在Skill描述里补充口语化的触发示例或者降低触发阈值让模型更倾向于先调用再说。但降低阈值会带来7%那部分的上升。这里有个权衡漏调用的代价通常是任务失败误调用的代价通常只是多花一点token。所以在大多数场景下我倾向于让Skill更容易被触发然后通过后处理过滤掉误调用的结果。4.3 提示词型Skill的冲突检测提示词型Skill最隐蔽的问题是和你原有的系统提示冲突。我做过一个实验系统提示里写回答要简洁不超过三句话然后加了一个详细解释Skill。结果模型在两者之间摇摆有时简洁有时详细一致性很差。检测这种冲突有个笨办法但很有效把系统提示和Skill提示拼在一起逐句找矛盾。凡是出现要A和不要A这种对立表述的就是冲突点。找到之后要么在Skill里显式声明优先级比如当与系统提示冲突时以本Skill为准要么修改系统提示给Skill留出空间。Claude Skills的设计里有个值得借鉴的点它把Skill的元信息名称、描述、触发条件和Skill正文分开元信息常驻上下文正文按需加载。这样既保证了Skill能被正确触发又不会让所有Skill正文都挤占上下文。如果你在做自己的Skill系统这个分层思路值得抄。5. 那些评测报告不会告诉你的坑5.1 评测集泄露你的Skill可能背题了如果你在调优过程中反复用同一个评测集Skill会逐渐过拟合到这个评测集上。表现是调优集分数一路涨留出集分数不动甚至下降。这就是评测集泄露。我的做法是调优集可以反复用但每次改完Skill必须在留出集上跑一遍。留出集只在两个时刻打开——最终验证以及你怀疑过拟合的时候。另外留出集要定期更新从新的线上流量里补充样本淘汰旧样本。5.2 评分者偏差人工评分的一致性怎么保证如果用人做评分不同评分者的标准会不一致。我试过一个办法先让所有评分者独立评20条然后对比结果把分歧大的case拿出来讨论统一标准后再正式评。这个过程大概花半天但能让后续评分的信度提升很多。还有一个细节评分时不要告诉评分者哪组是实验组。如果评分者知道哪组加了Skill潜意识里会倾向于给实验组高分。盲评是基本要求。5.3 统计显著性别被小样本骗了我见过有人用10条case的对比结果就下结论说Skill有效。10条样本的随机波动可能就有10个点这种结论没有意义。经验法则是每个维度至少30条样本如果要做分层分析每层至少30条。如果资源有限宁可减少维度也不要减少样本量。对于比例类指标如完成率可以用简单的显著性检验判断差异是否可信。如果两组差异在5个点以内样本量又不到100基本可以认为是噪声。5.4 长尾case平均值好看不代表没问题平均值会掩盖长尾问题。我建议在评测报告里专门列一节最差case分析把两组里表现最差的各10条拿出来对比。很多时候Skill带来的最大价值不是提升平均值而是消灭了某些灾难性失败。反过来Skill也可能引入新的灾难性失败这些只有看长尾才能发现。6. 从评测到迭代Skill该怎么改6.1 先定位问题层级再动手改Skill效果不好时别急着改提示词。先定位问题出在哪一层触发层Skill该触发没触发或不该触发乱触发。执行层Skill触发了但执行逻辑有问题。集成层Skill执行没问题但结果和Agent其他部分衔接有问题。表达层结果都对但输出格式或风格不符合要求。不同层级的修法完全不同。触发层问题改Skill描述和触发条件执行层问题改Skill正文逻辑集成层问题改Agent的编排逻辑表达层问题改输出约束。我见过有人明明是触发层问题却一直在改执行层提示词改了半天没效果。6.2 小步迭代 回归测试每次只改一个变量改完立刻在调优集上跑确认方向对了再继续。同时维护一个回归测试集包含那些已经修好的case确保新改动不会把它们弄坏。这个流程听起来笨但比大改一版再看靠谱得多。6.3 什么时候该放弃一个Skill不是所有Skill都值得保留。我的判断标准是如果连续三轮迭代Skill在留出集上的核心指标都没有显著提升或者提升的代价延迟、成本、复杂度超过了收益就该考虑放弃。沉没成本不是理由一个拖后腿的Skill比没有Skill更糟。7. 我现在的Skill评测清单最后把我现在每次做Skill对照评测都会过一遍的清单分享出来你可以直接拿去用评测集是否来自真实流量是否分层是否有留出集。两组输入是否逐字对比过确认只有Skill一处不同。评分维度是否覆盖完成率、正确性、格式、长度、延迟。评分是否盲评评分者标准是否统一。样本量是否足够差异是否做过显著性判断。是否分析了最差case是否检查了长尾。是否在留出集上验证过是否检查了过拟合。迭代是否小步进行是否有回归测试。这套流程跑下来一轮评测大概需要两到三天比我早期拍脑袋上线慢得多。但慢有慢的价值——它让我在Skill上线前就知道它到底行不行而不是等用户来告诉我。回到标题那个问题给Agent装上Skill结果真的变好了吗我的答案是只有当你用对照评测把好量化出来这个问题才有意义。否则你只是在赌。