★ FEATURED ARTICLE 给 Agent 装上 Skill 这件事最近半年被讨论得太多了。各种演示视频里一个原本平平无奇的 Agent 在挂载了几个 Skill 之后突然就能查数据库、画图表、跑测试、写周报看起来像是打通了任督二脉。但我自己上手折腾了几轮之后心里一直有个疙瘩没解开这些变好的观感到底是 Skill 带来的真实增益还是演示脚本精心挑选的个例换句话说如果我把同一个 Agent 在同一个任务上跑两遍一遍带 Skill 一遍不带结果真的会有统计意义上的差别吗这个问题不解决后面所有的 Skill 开发都是空中楼阁。你可能会花两周时间打磨一个看起来很专业的 Skill结果发现它带来的提升还不如把提示词改两句话。所以这篇文章不聊怎么写出花哨的 Skill而是聊一件更基础的事怎么用对照评测的方式诚实地回答装上 Skill 之后到底有没有变好这个问题。我会把评测设计、指标选择、常见陷阱、以及我自己踩过的坑都摊开讲适合已经上手过 Agent 开发、正在纠结要不要投入精力做 Skill 的同学参考。1. 为什么感觉变好了不能作为 Skill 有效的证据1.1 演示偏差你看到的成功案例是被筛选过的先说一个反直觉的结论绝大多数关于 Skill 效果的展示本质上都是幸存者偏差。演示者会挑那些 Skill 恰好能发挥作用的任务会反复调试提示词直到输出好看为止会在多次尝试中挑出最成功的那一次录屏。这套流程下来任何东西看起来都有效。我自己第一次做 Skill 评测的时候就掉进过这个坑。当时写了一个结构化数据提取的 Skill拿三个样例任务测试两个效果拔群一个勉强能用我当时的结论是效果显著。后来认真做了对照实验把同样的任务扩到四十个才发现真实提升只有不到百分之十五而且集中在特定类型的输入上。那三个样例恰好都落在 Skill 的舒适区里。这就是为什么必须做对照评测。对照评测的核心不是证明 Skill 有用而是排除掉那些跟 Skill 无关的因素之后还剩多少真实增益。这两件事听起来像做起来完全是两码事。1.2 混淆变量模型本身、提示词、随机性都在捣乱做对照实验最难的地方在于Agent 的输出受太多因素影响。模型版本、温度参数、系统提示词、上下文长度、甚至调用顺序任何一个变了结果都可能不一样。如果你只测带 Skill和不带 Skill两组但这两组用的提示词措辞不同、温度设置不同那你测出来的差异根本不能归因给 Skill。我见过一个很典型的错误做法有人给带 Skill 的组精心写了系统提示词给不带 Skill 的组随便写了一句请完成任务然后得出结论说 Skill 提升了百分之三十。这个结论毫无意义因为你测的是提示词差异不是 Skill 差异。正确的做法是控制变量。带 Skill 和不带 Skill 两组除了 Skill 本身其他所有条件必须完全一致同一个模型版本、同一套系统提示词、同一个温度参数、同一批任务、同一个评测脚本。只有做到这一点两组之间的差异才能被归因给 Skill。1.3 任务选择偏差简单任务看不出差别太难任务都失败还有一个容易被忽略的问题任务难度的选择会直接决定评测结论。如果任务太简单不带 Skill 的 Agent 也能轻松完成那 Skill 带来的提升自然看不出来如果任务太难两组都失败同样看不出差别。真正能体现 Skill 价值的是那些不带 Skill 时容易出错、带 Skill 时能稳定完成的任务。这意味着评测任务集的设计本身就是一门手艺。你需要先做一轮预实验摸清楚基线 Agent 的能力边界在哪里然后把评测任务集中在这个边界附近。太简单和太难的任务都应该剔除否则它们只会稀释信号让真实差异被噪声淹没。2. 对照评测的骨架从任务集到指标定义2.1 任务集怎么选分层抽样比随机抽样更靠谱设计任务集的时候我建议不要随机抽而是分层抽样。具体来说先按任务类型分成几层比如信息提取、多步推理、工具调用、格式转换、长文本处理然后在每一层里选若干个代表性任务。这样做的好处是你能看清楚 Skill 到底在哪一类任务上有帮助在哪一类上没帮助而不是得到一个笼统的平均分。我自己的做法是每层至少放八个任务总共四十到六十个。任务数量太少统计噪声会盖过真实差异任务数量太多评测成本又扛不住。四十到六十这个区间是我试下来性价比比较高的范围。另外任务集里一定要包含一部分陷阱任务也就是那些看起来跟 Skill 相关、但实际上 Skill 帮不上忙的任务。这类任务的作用是检验 Skill 有没有副作用。有些 Skill 会在不该触发的时候触发反而干扰了 Agent 的正常表现这种负面效果只有靠陷阱任务才能暴露出来。2.2 基线组怎么设至少三组才有说服力只设两组带 Skill 和不带 Skill其实是不够的因为你无法区分Skill 本身有效和多了一段提示词有效。我建议至少设三组组别配置作用A 组基线原始 Agent无任何额外内容测量真实起点B 组安慰剂加入与 Skill 等长的无关提示词排除提示词长度的影响C 组实验加入真正的 Skill测量 Skill 的净效果B 组是关键。如果 C 组比 A 组好但跟 B 组差不多那说明提升来自多了一段文字而不是Skill 的内容。只有当 C 组显著优于 B 组才能说 Skill 本身有价值。这个设计思路借鉴自医学实验里的安慰剂对照用在 Agent 评测上同样有效。2.3 指标怎么定别只看准确率很多人评测只看一个准确率这太粗糙了。Agent 任务往往涉及多个维度我一般会同时记录这几个指标任务完成率任务是否被完整解决二值判断输出质量分由人工或另一个模型按 rubric 打分一到五分调用步数完成任务用了多少轮交互越少越好Token 消耗总消耗量直接关系到成本格式合规率输出是否符合要求的格式比如 JSON 是否合法稳定性同一任务跑五次结果方差有多大这几个指标里稳定性最容易被忽略但对生产环境最重要。一个 Skill 如果平均分很高但方差很大那它在实际使用中就是不可靠的。我宁愿要一个平均分中等但每次都稳定的 Skill也不要一个偶尔惊艳但经常翻车的 Skill。3. 实操把评测跑起来的完整流程3.1 环境准备固定随机种子和模型版本动手之前先把环境固定住。模型版本要写死在配置里不要用最新版这种模糊表述因为模型随时可能更新。温度参数建议设成零或者一个很小的值减少随机性。如果平台支持随机种子一定要固定住。# 评测配置示例 EVAL_CONFIG { model: 指定版本号不要用latest, temperature: 0.0, max_tokens: 4096, seed: 42, top_p: 1.0, }这里有个细节即使温度设成零很多模型仍然不是完全确定性的因为底层并行计算会引入微小差异。所以同一组配置最好跑三次取平均而不是跑一次就下结论。3.2 评测脚本批量跑、自动记录、可复现评测脚本的核心要求是可复现。我一般会写一个批量执行器读入任务列表对每个任务分别用 A、B、C 三组配置跑一遍把原始输出、耗时、Token 消耗全部落盘。落盘的时候一定要存原始输出不要只存分数因为后面你可能会想换一种评分方式重新分析。import json import time def run_eval(tasks, configs, output_path): results [] for task in tasks: for group_name, config in configs.items(): start time.time() output call_agent(task, config) elapsed time.time() - start results.append({ task_id: task[id], group: group_name, output: output, elapsed: elapsed, tokens: output.get(usage, {}), }) with open(output_path, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) return results跑评测的时候建议把任务顺序打乱避免因为缓存或者限流导致系统性偏差。如果平台有速率限制记得加退避重试否则跑到一半被限流数据就残缺了。3.3 评分环节人工评分和模型评分怎么配合评分是最费时间的环节。我的经验是先用模型自动评分做初筛再对分歧样本做人工复核。模型评分的好处是快、一致性好坏处是它可能对某些类型的错误不敏感。人工评分准但成本高、主观性强。具体做法是让评分模型按明确的 rubric 打分rubric 里把每个分数档的标准写清楚。然后随机抽百分之二十的样本做人工评分对比模型评分和人工评分的一致性。如果一致性低于某个阈值说明 rubric 写得不够清楚需要回去改。提示评分模型最好跟被测模型不是同一个否则容易出现自己评自己的偏差。用不同厂商的模型交叉评分结论会更可信。4. 我踩过的坑那些让评测结论失真的细节4.1 上下文污染Skill 描述太长反而拖累表现第一个坑是上下文污染。我一开始写的 Skill 描述特别详细恨不得把每个边界情况都写进去结果发现带 Skill 的组反而变差了。排查之后才明白Skill 描述占用了大量上下文把真正有用的任务信息挤到了后面模型注意力被稀释了。这个发现让我重新思考 Skill 的设计原则Skill 描述不是越详细越好而是要精准。只写模型真正需要知道的信息把那些人类觉得重要但模型自己能推断的内容删掉。后来我把 Skill 描述压缩了将近一半效果反而提升了。4.2 触发时机Skill 在不该用的时候被激活第二个坑是触发时机。有些 Skill 会被 Agent 在不相关的任务上误触发比如一个数据可视化的 Skill在处理纯文本任务时也被调用结果 Agent 硬生生把文本转成了图表输出完全跑偏。解决这个问题的办法是在 Skill 描述里写清楚适用条件和不适用条件同时在评测任务集里专门放一批不该触发的任务用来监控误触发率。误触发率这个指标我觉得比任务完成率还重要因为它直接关系到 Skill 能不能上生产。4.3 评测疲劳跑了几十轮之后判断力下降第三个坑是评测疲劳。连续看几十个输出、打几十次分之后人的判断标准会漂移。前面打三分觉得严格后面打三分觉得宽松同一批数据前后标准不一致。应对办法有两个一是打乱评分顺序不要按组别顺序评二是每隔一段时间重新评几个已经评过的样本检查自己的标准有没有漂移。如果发现漂移就停下来休息或者换人评。这个坑听起来很软但它对结论的影响一点不比技术问题小。4.4 统计显著性小样本差异可能只是噪声第四个坑是忽视统计显著性。我早期做过一次评测C 组比 B 组高了三个百分点当时很兴奋觉得 Skill 有效。后来把样本量扩大发现这个差异完全在噪声范围内重复跑几次有时候 C 组高有时候 B 组高。所以评测跑完之后一定要做显著性检验。任务完成率这种二值指标可以用卡方检验质量分这种连续指标可以用 t 检验或者 Mann-Whitney U 检验。如果差异不显著就老老实实说没测出显著差异不要硬凑结论。5. 从评测结果反推 Skill 的设计改进5.1 看分层结果找到 Skill 真正擅长的任务类型评测跑完最有价值的不是那个总分而是分层结果。把任务按类型拆开看你会发现 Skill 在某些类型上提升明显在另一些类型上几乎没帮助甚至有害。这个分层视图直接告诉你 Skill 的适用边界在哪里。我自己的一个 Skill在结构化提取任务上提升了将近百分之三十但在开放式推理任务上反而拖累了百分之五。这个结果让我明确了它的定位只在结构化提取场景下启用其他场景不挂载。这种精细化的使用策略比无脑全局挂载效果好得多。5.2 看失败案例Skill 没帮上忙的时候发生了什么失败案例比成功案例更有信息量。我会把 C 组失败但 A 组成功的案例单独挑出来逐个分析。这些案例通常能揭示 Skill 的设计缺陷比如描述有歧义、边界条件没覆盖、跟其他 Skill 冲突等等。有一次我发现带 Skill 的组在处理超长输入时反而更容易失败原因是 Skill 描述加上超长输入超过了上下文窗口导致任务信息被截断。这个发现直接促成了我后来的一条设计原则Skill 描述要尽量精简给任务内容留足空间。5.3 迭代闭环改一版 Skill 就重跑一次评测Skill 的优化不是一次性的而是迭代的。每改一版 Skill都应该重跑一次评测对比新旧版本的指标。这里要注意重跑评测时任务集要保持不变否则你无法区分Skill 变好了和任务变简单了。我一般会维护一个固定的回归任务集每次改 Skill 都跑一遍确保没有引入退化。同时维护一个探索任务集用来测试新场景。两套任务集分开管理既保证了稳定性又保留了扩展性。6. 一套可复用的评测清单把上面的经验浓缩成一份清单下次做 Skill 评测的时候可以直接对照任务集分层设计每层至少八个任务包含陷阱任务至少设三组基线、安慰剂、实验固定模型版本、温度、随机种子记录多个指标完成率、质量分、步数、Token、格式合规、稳定性原始输出全部落盘方便后续重新分析模型评分加人工抽检检查一致性做显著性检验不显著就说没测出差异分层看结果明确 Skill 的适用边界分析失败案例反推设计缺陷维护回归任务集每次改版都重跑这份清单看起来繁琐但跑过一两轮之后就会形成肌肉记忆。真正花时间的不是流程本身而是任务集的设计和评分环节。这两块做扎实了结论才站得住脚。最后分享一个我自己的体会做 Skill 评测最大的收获往往不是证明某个 Skill 有用而是发现自己对 Agent 行为的理解有多少是想当然的。很多我以为会有效果的设计实测下来毫无波澜很多我随手加的细节反而成了关键。评测的价值就在这里它逼着你把直觉换成数据把感觉换成证据。这个过程不舒服但它是把 Agent 从玩具变成工具的唯一路径。
阅读完成 · 觉得有帮助？
