1. 从一次翻车说起为什么我要做这组对照评测给 Agent 加 Skill 这件事最近半年几乎成了默认操作。不管是用 Claude 的 Skills 机制、Codex 的 skill 脚本还是自己搭一套 agent 框架往里塞插件大家嘴上都在说“加了 Skill 之后 Agent 变强了”。但我自己踩过几次坑之后心里一直有个疙瘩它真的变好了吗还是只是看起来变好了起因是一次很普通的任务。我让一个 Agent 帮我处理一批结构化的文本抽取工作原本裸模型跑下来准确率大概七成出头错误集中在几个边界情况上。后来我给它挂了一个自己写的 Skill专门处理这类边界跑完一轮感觉“好像准了不少”。但当我认真做了对照——同一批输入、同一套评分标准、同样的温度参数——结果发现提升只有不到三个百分点而且这三点还落在评分噪声范围内。换句话说我感受到的“变好”很大一部分是心理作用。这件事让我意识到一个问题Skill 这个东西加进去容易验证它有没有用很难。市面上讲“怎么给 Agent 装 Skill”的教程一抓一大把讲“装完之后怎么科学地判断它到底有没有用”的却少得可怜。所以这篇东西我想把“对照评测”这件事从头到尾讲清楚——不是给你一个结论说 Skill 好或者不好而是给你一套可复现的评测方法让你自己回答标题里那个问题。这篇内容适合几类人正在给 Agent 写 Skill 但不确定效果的开发者团队里负责 Agent 质量、需要给出量化结论的人以及单纯好奇“Skill 到底是不是智商税”的从业者。不需要你是评测专家但最好动手跑过至少一个 Agent 项目这样读起来会更有共鸣。2. 先想清楚Skill 到底改变了什么2.1 Skill 不是魔法它改变的是上下文和流程很多人对 Skill 的理解停留在“给 Agent 加了个能力”。这个说法太模糊了。从第一性原理看一个 Skill 对 Agent 的影响无非是三个层面注入上下文、约束行为、扩展工具。注入上下文指的是 Skill 把一段领域知识、格式规范、示例样本塞进了模型的输入里。比如你写一个“合同条款抽取”的 Skill里面可能包含字段定义、几个正例反例、输出格式要求。模型看到这些之后行为会变但变的本质是条件概率分布被这段文本重新加权了。约束行为指的是 Skill 通过提示词或者流程编排限制 Agent 在某些步骤上必须怎么做。比如“先分类再抽取”“输出前必须自检一遍”。这类 Skill 改的是执行路径不是知识。扩展工具指的是 Skill 挂载了外部函数、脚本、检索接口。这是最“实”的一类因为它引入了模型本身不具备的能力比如查数据库、调 GIS 空间分析、跑一段 Rust 写的计算逻辑。搞清楚这三层的区别非常关键因为它们对应的评测方法完全不一样。上下文类 Skill 的收益容易波动工具类 Skill 的收益通常更稳定而流程类 Skill 的收益往往体现在“减少低级错误”而不是“提升上限”。如果你不区分笼统地说“加了 Skill 提升了多少”结论基本没有参考价值。2.2 为什么“感觉变好”不可靠人的直觉在评测这件事上非常不靠谱原因有三个。第一是确认偏误。你花了两小时写 Skill潜意识里希望它有用于是看输出的时候会不自觉地挑好的看。裸模型偶尔答对一次你觉得是运气加了 Skill 偶尔答对一次你觉得是 Skill 的功劳。第二是样本偏差。大多数人测试的时候只会跑几个自己顺手想出来的例子这些例子往往恰好是 Skill 覆盖到的情况。真正难的那些边界反而没被测到。第三是评分漂移。同一段输出你今天看觉得“还行”明天看觉得“不太行”因为你的标准在变。没有固定的评分规则前后两次评测根本不可比。所以对照评测的核心不是“跑一遍看看”而是把主观感受替换成可重复的测量。这件事听起来麻烦但一旦搭好后面每次改 Skill 都能复用长期看是省时间的。2.3 对照评测要回答的三个问题我把评测目标拆成三个层次从易到难有没有用加了 Skill 之后在固定测试集上的指标是否显著高于基线。哪里有用提升集中在哪些类型的样本上是全面变好还是只补了某几个短板。值不值提升的幅度是否值得 Skill 带来的额外成本——token 消耗、延迟、维护复杂度。大部分教程只关心第一个问题但实际做项目的时候第二和第三个问题才是决定你要不要保留这个 Skill 的关键。一个 Skill 如果只提升了 2% 但让延迟翻倍那它大概率不值得留。3. 评测方案设计怎么搭一个能说服自己的对照实验3.1 基线怎么定裸模型不是唯一选项说到对照很多人第一反应是“裸模型 vs 加 Skill”。这个对照当然要做但它不是唯一的甚至不是最有信息量的。我一般会设三组组别配置作用A 组裸模型无 Skill下限基线B 组模型 通用提示词不含 Skill 内容排除“只是多写了提示词”的干扰C 组模型 目标 Skill实验组B 组是最容易被忽略但最重要的一组。因为很多 Skill 本质上就是一段精心写的提示词如果你不设 B 组就无法区分“是 Skill 机制起了作用”还是“只是提示词写得更详细了”。我见过不少案例C 组比 A 组好很多但 C 组和 B 组几乎没差别——这说明 Skill 的封装形式没带来额外价值价值全在那段文字本身。如果条件允许还可以加一个 D 组模型 目标 Skill 但去掉其中某个关键模块用来做消融实验定位到底是 Skill 的哪一部分在起作用。这个在优化阶段特别有用。3.2 测试集怎么选覆盖度比数量重要测试集不是越多越好而是越有代表性越好。我的经验是一个 50 到 100 条的测试集如果设计得当比 1000 条随手抓的数据更能说明问题。选测试集的时候我会按这几个维度分层典型样本Skill 明确要处理的主要场景占 50% 左右。边界样本容易出错、模棱两可的情况占 30% 左右。这部分是 Skill 价值的主要体现区。对抗样本故意设计来诱导模型犯错的输入占 10% 到 20%。无关样本不属于 Skill 处理范围、应该被拒绝或走默认流程的输入占 10% 左右。最后一类特别重要。很多 Skill 的副作用就是“过度触发”——本来不该用它的时候它硬要用结果把简单问题搞复杂。如果你不测这类样本就会漏掉这个坑。测试集一旦定下来在整个评测周期内不要改。改了就没法纵向对比了。如果确实需要扩充就新建一个版本号老版本保留。3.3 评分标准把“好”拆成可打分的维度评分是评测里最容易糊弄的环节。我的做法是把“好”拆成几个正交的维度每个维度单独打分最后加权。以文本抽取类任务为例我会拆成字段准确率抽出来的字段值对不对逐字段比对。格式合规率输出是否符合要求的格式能不能被程序解析。完整性该抽的字段有没有漏。无幻觉率有没有编造原文里不存在的内容。每个维度用 0 到 1 的连续值或者 0/1 二值最后按业务重要性加权。比如格式合规率如果下游要程序解析权重就该高如果只是给人看权重可以低。注意评分标准一定要在跑评测之前定好并且写下来。跑完再定标准等于给自己开后门。如果任务本身比较主观比如文案生成、对话质量那就需要人工评分或者用另一个模型做裁判。用模型做裁判的时候要小心裁判模型本身也有偏好最好用和被测模型不同的模型并且固定裁判的提示词和参数。3.4 控制变量那些容易被忽略的干扰项对照实验最怕的就是变量没控住。下面这些是我踩过坑之后总结的必控项温度参数必须固定。温度不同输出波动可能比 Skill 带来的差异还大。随机种子如果接口支持固定种子。不支持的话每个配置至少跑 3 次取平均。提示词模板除了 Skill 部分其余提示词必须完全一致。模型版本同一个评测周期内不要换模型版本换了就重跑基线。上下文长度Skill 会占用 token如果因此挤掉了其他上下文效果差异可能来自这里而不是 Skill 本身。这些看起来是常识但实际做的时候十有八九会漏掉一两个。我建议直接做成一个检查清单每次评测前过一遍。4. 实操从零跑完一轮对照评测4.1 环境与工具准备我这次用的是一套比较通用的配置你可以按自己的技术栈替换。被测 Agent一个基于主流大模型 API 的对话式 Agent支持挂载 Skill。Skill 内容一个处理结构化信息抽取的 Skill包含字段定义、两个正例、一个反例、输出格式说明。评测脚本Python 写的批处理脚本负责读测试集、调 Agent、收集输出、算指标。评分字段准确率用程序比对格式合规率用正则校验幻觉率人工抽查。脚本的核心逻辑其实很简单伪代码大概是这样for sample in test_set: for config in [A, B, C]: output run_agent(sample.input, config) results[config].append({ sample_id: sample.id, output: output, field_acc: compare_fields(output, sample.gold), format_ok: check_format(output), })关键是要把每次运行的原始输出都存下来不要只存分数。后面分析的时候原始输出才是金矿。4.2 跑基线先知道裸模型的天花板在哪第一步永远是跑基线。这一步的目的是搞清楚在不加任何 Skill 的情况下模型能做到什么程度。我这次跑了 80 条测试样本A 组裸模型的结果是这样的指标A 组得分字段准确率0.71格式合规率0.83完整性0.76无幻觉率0.88这个结果本身就有信息量。格式合规率 0.83 说明裸模型有 17% 的输出没法直接被程序解析这是硬伤。无幻觉率 0.88 说明还有 12% 的情况在编内容。字段准确率 0.71 是最低的也是提升空间最大的。跑基线的时候有个细节要注意多跑几次看方差。我第一次跑完 A 组字段准确率是 0.71第二次跑变成 0.69第三次 0.73。波动在正负 2 个百分点左右。这意味着后面如果 Skill 带来的提升小于这个幅度就不能说“显著提升”。4.3 跑对照组B 组和 C 组的差异才是关键B 组我用的是一段通用提示词内容和 Skill 里的知识基本一致但没有用 Skill 的封装形式就是直接拼在系统提示里。C 组用的是正式的 Skill 挂载。跑完三组结果汇总如下指标A 组B 组C 组字段准确率0.710.790.81格式合规率0.830.940.96完整性0.760.820.83无幻觉率0.880.910.92看到这个表几个结论就出来了。第一B 组相比 A 组的提升是最大的。字段准确率从 0.71 到 0.79涨了 8 个百分点远超噪声范围。这说明那段领域知识确实有用。第二C 组相比 B 组只有微弱提升。字段准确率 0.79 到 0.81格式合规率 0.94 到 0.96都在噪声边缘。也就是说Skill 的封装形式本身带来的额外价值很有限主要价值还是在那段文字内容上。第三格式合规率的提升最明显。从 0.83 到 0.96这是最实在的收益因为它直接决定了输出能不能被下游程序消费。这个结论对我很有启发如果你的 Skill 只是把提示词换个地方放那它大概率不会比直接写提示词好多少。Skill 真正的价值应该体现在流程编排、工具调用、动态上下文管理这些提示词做不到的事情上。4.4 消融实验定位 Skill 里真正起作用的部分C 组和 B 组差异不大让我好奇到底是 Skill 的哪个部分在起作用。于是我做了个简单的消融把 Skill 拆成三个模块——字段定义、示例样本、输出格式说明——分别去掉一个再跑。配置字段准确率格式合规率完整 Skill0.810.96去掉字段定义0.740.95去掉示例样本0.770.94去掉格式说明0.800.85结果很清楚字段定义贡献了大部分准确率提升格式说明贡献了大部分格式合规提升示例样本的贡献最小。这个发现直接指导了我后续的优化方向——把精力花在打磨字段定义上示例样本可以精简省下来的 token 用来放更多边界情况的说明。消融实验是评测里性价比最高的一步。它不需要额外标注数据只需要把 Skill 拆开跑几轮就能告诉你钱该花在哪。5. 常见问题与排查技巧实录5.1 结果不稳定跑两次差很多怎么办这是最常见的问题。原因通常有三个温度没固定、样本量太小、评分标准太粗。温度没固定是最低级的错误但也是最容易犯的。有些 API 默认温度不是 0你不显式设置每次调用都在随机。解决办法就是显式传参把温度设成 0 或者一个固定的小值。样本量太小的话统计波动会掩盖真实差异。我的经验是如果两组差异在 5 个百分点以内样本量至少要 100 条以上才能下结论。样本量不够的时候宁可多跑几轮取平均也不要拿单次结果说事。评分标准太粗指的是用“好/不好”这种二值判断。这种评分对微小差异不敏感两次跑出来都是“好”看不出区别。拆成多维度连续评分之后敏感度会高很多。5.2 Skill 加了之后反而变差是什么原因这种情况我也遇到过通常有几个典型原因。过度触发。Skill 在不该用的时候被激活了把简单任务复杂化。比如一个专门处理长文档的 Skill被用在了短句子上结果模型开始过度分析。解决办法是在 Skill 里加明确的触发条件并且在测试集里加入无关样本验证。上下文挤占。Skill 占用了大量 token导致真正重要的输入被截断或者被稀释。特别是长上下文任务Skill 塞进去几千 token可能把关键信息挤到注意力边缘。解决办法是精简 Skill 内容或者用动态加载只在需要的时候注入。指令冲突。Skill 里的要求和系统提示里的要求矛盾模型不知道该听谁的。比如系统提示说“简洁输出”Skill 说“详细解释每一步”模型就会摇摆。解决办法是统一指令层级明确 Skill 的优先级。格式过拟合。Skill 里的示例格式太具体模型死板照搬遇到稍微不同的输入就套不上。解决办法是示例要有多样性覆盖不同形态的输入。5.3 怎么判断提升是真实的还是噪声这个问题可以用一个简单的经验法则提升幅度要大于基线波动幅度的两倍才算显著。比如你跑基线三次字段准确率分别是 0.69、0.71、0.73波动幅度是正负 0.02。那么 Skill 带来的提升至少要超过 0.04也就是达到 0.75 以上才能说“大概率是真实的”。如果提升幅度刚好在波动范围内那就需要增加样本量或者多跑几轮。别急着下结论更别急着写进汇报里。5.4 评测成本太高怎么压缩完整跑一轮三组加消融如果样本量大token 成本和时间成本都不低。压缩的办法有几个。分层抽样。不用全量跑从每个类别里抽代表性的样本。典型样本抽 30 条边界样本抽 20 条对抗样本抽 10 条总共 60 条就能看出趋势。先粗后细。第一轮用少量样本快速筛如果 C 组和 B 组差异不明显就不用往下做了。只有差异明显的时候才值得扩大样本量做精细评测。缓存基线结果。基线跑一次存下来后面改 Skill 的时候直接复用不用重跑。前提是模型版本和参数没变。自动化评分。能用程序评的绝不人工评。字段比对、格式校验这些都可以脚本化只有幻觉检测这种需要人工抽查。5.5 常见问题速查表现象可能原因排查方向结果波动大温度未固定、样本少固定参数、增加样本Skill 无提升与提示词重复、触发条件模糊做 B 组对照、检查触发逻辑Skill 负提升过度触发、上下文挤占加无关样本、精简内容格式合规率低格式说明不清、示例不足补充格式约束和多样示例幻觉率高缺少“不知道就说不知道”的约束加拒答指令、加对抗样本消融无差异Skill 模块耦合太紧重新拆分模块、单独测试6. 几个我踩过的坑和一点个人体会第一个坑是过早优化。我一开始就想着把 Skill 写得很完美加了一堆规则和示例结果跑评测发现提升还不如一个精简版。后来才明白Skill 的价值不在于写得多而在于写得准。先跑基线找到真正的短板再针对性地写 Skill比一上来就堆内容高效得多。第二个坑是忽略 B 组。有段时间我做的所有评测都是 A 组对 C 组看到提升就高兴。直到有一次同事问我“你这 Skill 和直接写提示词有啥区别”我才意识到自己从来没测过 B 组。补上之后发现很多所谓的“Skill 收益”其实只是“提示词收益”。第三个坑是评分标准事后调整。有一次跑完发现结果不理想我下意识地想改评分标准让它好看点。这个念头一出来我就警觉了——这就是在自欺欺人。后来我给自己定了个规矩评分标准一旦定下跑完之前绝不改要改就重跑。最后一个体会是关于 Skill 的定位。经过这几轮评测我越来越觉得 Skill 的真正价值不在“注入知识”因为知识直接写提示词也能注入。Skill 的价值在于可复用、可组合、可版本管理。一个写好的 Skill 可以在多个项目里复用可以和其他 Skill 组合成流程可以像代码一样做版本控制。这些是散落在提示词里的知识做不到的。所以判断一个 Skill 值不值得做除了看它带来的指标提升还要看它的复用价值。一个只提升 3% 但能被十个项目复用的 Skill可能比一个提升 10% 但只能用一次的 Skill 更值得投入。如果你也在做 Agent 和 Skill 相关的工作我建议至少完整跑一轮对照评测。不用很复杂三组配置、几十条样本、一个下午就能跑完。跑完之后你对 Skill 的理解会比看十篇教程都深。