给 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 本身有效"和"多了一段提示词有效"。我建议至少设三组：

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", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) 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 从玩具变成工具的唯一路径。