1. 从一次翻车说起：为什么我要做这组对照评测

去年年底我开始密集地把各种 Skill 往自己的 Agent 工作流里塞。起因很简单，那阵子 Claude Skills 的概念刚火起来，skill-creator 这类工具也冒出来了，社区里到处都在说“给 Agent 装上 Skill 之后能力起飞”。我当时的反应和大多数人一样：既然能增强，那就装呗。

结果装了两周，我发现自己陷入了一种很尴尬的状态。表面上我的 Agent 能做的事情变多了，但实际交付质量并没有肉眼可见的提升，有些场景甚至变差了。最典型的一次，我让 Agent 帮我处理一份结构化的数据清洗任务，没挂 Skill 之前它老老实实按步骤走，挂了某个“数据处理 Skill”之后，它反而开始自作主张地跳步骤，输出格式也变得飘忽不定。那一刻我意识到一个问题：Skill 到底有没有用，不能靠感觉，得靠对照评测。

这个项目就是干这件事的。我搭了一套最小可用的对照评测框架，把同一个 Agent 在“无 Skill”“挂单个 Skill”“挂多个 Skill”三种状态下的表现拉出来横向比。目标读者是那些已经在用 Agent、正在纠结要不要上 Skill、或者上了 Skill 但心里没底的人。不管你是刚接触 agent skill 概念的新手，还是已经在折腾 agent 框架与编排的老手，这套评测思路都能直接抄。

先说结论方向，免得你看到一半觉得我在绕：Skill 不是越多越好，也不是装上就变强，它的收益高度依赖任务类型、Skill 质量和挂载方式。下面我把整个评测的设计、执行、踩坑和结论完整拆开讲。

2. 评测框架的整体设计与思路拆解

2.1 为什么必须做对照，而不是单组测试

单组测试最大的问题是没有基线。你让 Agent 挂上 Skill 跑一个任务，它跑出来了，你说“不错”，但你没见过它不挂 Skill 时跑成什么样。也许不挂的时候它跑得更好，也许一样好，你根本不知道 Skill 贡献了多少。

这在实验设计里叫缺少对照组。我见过太多 agent 开发的分享，通篇在讲“我加了这个 Skill 之后 Agent 能干嘛了”，但从来不提基线表现。这种分享参考价值很低，因为你无法判断那个能力是 Skill 带来的，还是模型本身就会。

所以我坚持三组对照：

• A 组（基线组）：Agent 不挂任何 Skill，纯靠系统提示词和自身能力。
• B 组（单 Skill 组）：只挂一个和目标任务直接相关的 Skill。
• C 组（多 Skill 组）：挂上目标 Skill 加上若干通用 Skill，模拟真实使用中“装了一堆”的状态。

三组跑同一批任务，用同一套评分标准，这样才能把 Skill 的净效应剥离出来。

2.2 任务集怎么选才有区分度

任务集是评测的命根子。如果任务太简单，三组都能满分，测了等于没测；如果任务太难，三组都零分，也测不出差异。我选任务的原则是卡在模型能力边界附近——不挂 Skill 时能做但做得不稳，挂了合适的 Skill 应该能显著变稳。

我最终选了四类任务，覆盖不同的能力维度：

每类任务准备 5 个变体，总共 20 个任务。每个任务在三组下各跑 3 次，取平均，减少随机性带来的噪声。这样一共是 180 次运行，量不算大，但足够看出趋势。

2.3 评分标准：把“感觉变好了”变成数字

“变好了”这种话在评测里是废话。我把它拆成四个可打分的维度，每个维度 1 到 5 分：

• 正确性：结果对不对，有没有事实错误。
• 格式合规：输出是否符合要求的格式，字段有没有缺漏。
• 流程遵循：多步骤任务里，步骤有没有跳、有没有乱序。
• 稳定性：同一任务多次运行，结果方差大不大。

正确性和格式合规可以半自动判，我写了个简单的校验脚本比对 schema 和关键字段。流程遵循和稳定性靠人工看，因为这两个维度很难自动化，而且恰恰是 Skill 影响最大的地方。

提示：评分维度不要贪多，四个已经够用。维度越多，人工评分的一致性越差，最后数据反而不可信。

2.4 为什么选这套 Agent 配置

我用的是一个支持 Skill 挂载的 Agent 框架，模型侧固定用同一个版本，避免模型升级带来的干扰。Skill 来源分两类：一类是官方或社区现成的，比如 skill-creator 生成的；一类是我自己按 skill 脚本规范手写的。

这里有个关键决策：所有 Skill 在评测期间版本冻结。因为 Skill 本身会迭代，如果评测中途某个 Skill 更新了，前后数据就不可比了。我把每个 Skill 的版本号记在评测日志里，这点后面排查问题时特别有用。

3. 核心细节解析与实操要点

3.1 Skill 到底是什么，别被概念绕晕

很多人一上来就被 skill 编码、skill 插件这些词搞懵。我用一句话说清楚：Skill 就是给 Agent 的一份“专项作业指导书”，里面写清楚了在什么场景下、按什么步骤、用什么工具、输出什么格式。

它和系统提示词的区别在于：系统提示词是常驻的、全局的，Skill 是按需加载的、场景化的。你可以把它理解成公司里的岗位手册——平时不占你脑子，遇到对应岗位的活儿才翻出来看。

它和 harness 的区别也常被混淆。harness 更像是“测试台”或者“运行外壳”，负责把 Agent 跑起来、把工具接进去、把结果收回来；Skill 是跑在里面的内容。一个是跑道，一个是跑法，别搞混。

3.2 一个合格 Skill 的解剖结构

我拆过几十个 Skill，好的和烂的差别非常明显。一个能真正提升表现的 Skill，通常包含这几块：

• 触发条件：什么情况下该用这个 Skill。写不清楚，Agent 就会乱用或者不用。
• 前置检查：动手前要确认哪些信息齐了，缺了怎么办。
• 执行步骤：分步骤写，每步说清楚输入输出。
• 输出规范：格式、字段、示例，越具体越好。
• 异常处理：遇到边界情况怎么退。
• 反例：明确写出“不要做什么”，这条最容易被忽略但最有用。

我实测下来，加了反例的 Skill，Agent 跑偏的概率明显下降。因为模型很擅长模仿，你给它一个“错误示范”，它反而更清楚边界在哪。

3.3 挂载方式对结果的影响

同样是挂 Skill，挂法不同结果差很多。我试过三种：

1. 全量常驻：所有 Skill 一次性塞进上下文。结果是上下文被撑爆，Agent 注意力被稀释，表现最差。
2. 关键词触发：靠匹配关键词决定加载哪个 Skill。问题是关键词匹配太脆，稍微换个说法就触发不了。
3. 语义路由：先用一个轻量判断决定该加载哪个 Skill，再动态注入。这个方式表现最好，但实现成本高一点。

我的建议是，Skill 数量少于 5 个时可以用全量常驻图省事，超过 5 个就必须上动态加载，否则上下文污染会吃掉所有收益。

3.4 评测前必须固定的变量

评测最怕变量失控。我固定了这些：

• 模型版本、温度参数、最大输出长度全部锁死。
• 每个任务的输入文本完全一致，不做任何改写。
• 运行顺序打乱，避免“越跑越熟”的顺序效应。
• 评分由同一个人完成，且评分时不知道这组是 A/B/C（盲评）。

注意：盲评这一步很多人省掉，但它极其重要。如果你知道这是挂了 Skill 的组，你会不自觉地给高分，这是人性。

4. 实操过程与核心环节实现

4.1 搭建评测脚手架

我没有用重型框架，就写了个 Python 脚本把流程串起来。核心逻辑是：读任务清单，对每个任务依次跑 A/B/C 三组，把原始输出存下来，再跑校验脚本。

import json from agent_client import run_agent def run_trial(task, skills, repeat=3): results = [] for i in range(repeat): out = run_agent( prompt=task["input"], skills=skills, temperature=0.0, max_tokens=2048 ) results.append(out) return results tasks = json.load(open("tasks.json")) groups = { "A_baseline": [], "B_single": ["target_skill"], "C_multi": ["target_skill", "general_skill_1", "general_skill_2"] } for task in tasks: for gname, skills in groups.items(): res = run_trial(task, skills) json.dump(res, open(f"out/{task['id']}_{gname}.json", "w"))

温度设成 0 是为了减少随机性，但即便如此，同一组多次运行还是会有差异，所以取 3 次平均是必要的。

4.2 结构化输出任务的实测记录

拿“非结构化文本转 JSON”这个任务举例。A 组基线跑下来，5 个变体里有 2 个出现了字段缺失，1 个把嵌套结构拍平了。B 组挂了专门的格式化 Skill 后，5 个全部通过 schema 校验。C 组挂了格式化 Skill 加两个通用 Skill，结果反而有 1 个变体多输出了几个 schema 里没定义的字段。

这个现象很有意思：通用 Skill 会引入“额外发挥”的倾向。因为通用 Skill 往往写得比较宽泛，鼓励 Agent 灵活处理，而结构化任务恰恰最怕灵活。

4.3 多步骤流程任务的实测记录

这类任务差异最大。A 组基线在 5 个变体里平均跳了 1.4 个步骤，尤其是中间那些“看起来不重要”的确认步骤最容易被跳过。B 组挂了 SOP Skill 后，跳步骤降到平均 0.2 个。C 组表现介于两者之间，平均 0.6 个。

为什么 C 组比 B 组差？我分析是多个 Skill 的步骤指令互相干扰。通用 Skill 里可能也写了流程，和目标 SOP 的步骤顺序不完全一致，Agent 在两者之间做了折中，结果两边都没完全遵守。

4.4 领域知识任务的实测记录

这类任务 Skill 的收益最直接。A 组基线在专业术语上错误率约 30%，B 组挂了领域 Skill 后降到 8%。因为领域知识很难靠模型自身覆盖，Skill 相当于把外部知识注入了。

但这里有个坑：Skill 里的知识如果本身过时或错误，Agent 会非常自信地照搬。我在测试中故意放了一个含错误规则的 Skill，结果 Agent 100% 复现了那个错误，比不挂 Skill 时还糟。这说明 Skill 是放大器，好的放大，坏的也放大。

4.5 长上下文一致性任务的实测记录

这类任务三组差异最小。A 组基线在跨轮一致性上表现已经不错，B 组略好，C 组因为上下文更长，反而偶尔出现前后矛盾。这印证了一个判断：Skill 对“记忆类”能力的提升有限，它更擅长规范“怎么做”，不擅长“记住什么”。记忆问题得靠 agent 记忆机制单独解决，别指望 Skill。

4.6 数据汇总

把四类任务的评分汇总成表，趋势就很清楚了：

B 组在每一类任务上都是最优或接近最优。C 组只在领域知识上接近 B 组，其余都明显回落。这个数据基本回答了我最初的疑问。

5. 常见问题与排查技巧实录

5.1 挂了 Skill 反而变差，先查这三处

遇到“装了 Skill 结果更糟”的情况，按这个顺序排查：

1. 触发条件是否过宽：Skill 在不该触发的时候触发了，Agent 用错了指导书。
2. 是否多个 Skill 指令冲突：两个 Skill 对同一件事给了不同要求，Agent 无所适从。
3. Skill 内容是否本身有错：前面说过，错误会被放大。

我踩过最深的坑是第二类。当时挂了三个 Skill，其中两个都定义了输出格式，格式还不一样，Agent 每次输出都在两种格式之间摇摆，稳定性直接崩了。

5.2 常见问题速查表

5.3 独家避坑技巧

几个我实测有效的做法：

• Skill 写完先单测：别直接扔进复杂工作流，先单独跑几个边界用例，确认触发和输出都对。
• 给 Skill 加版本号：改一次记一次，出问题能快速回滚。
• 反例比正例重要：写清楚“不要做什么”，比写十遍“要做什么”管用。
• 定期清理僵尸 Skill：装了不用的 Skill 就是上下文里的垃圾，该删就删。

提示：如果你在用 skill-creator 这类工具自动生成 Skill，生成完一定要人工过一遍。自动生成的 Skill 往往触发条件写得含糊，反例基本没有，直接上生产容易翻车。

5.4 关于“去 AI 味”的一点观察

社区里有个热词叫“去 AI 味的 Skill”，我理解是指让 Agent 输出更像人写的。我测过几个这类 Skill，效果参差。核心问题是“像人”这个标准太主观，Skill 里如果只写“要自然、要口语化”，Agent 基本无感。真正有效的做法是给出具体的句式示例和禁用词清单，把主观标准变成可执行的规则。这其实又回到了前面说的：Skill 的价值在于把模糊要求变成明确指令。

6. 我的最终判断与后续可扩展方向

跑完这 180 次评测，我对“给 Agent 装上 Skill 结果真的变好了吗”这个问题有了比较确定的答案：在合适的任务上、用合适的 Skill、以合适的方式挂载，确实会变好，而且提升幅度不小；但一旦条件不满足，Skill 不仅无益，还会拖后腿。

具体来说，结构化输出和多步骤流程这两类任务，Skill 的收益最大，因为它们本质上是“规范执行”问题，而 Skill 最擅长的就是把规范写死。领域知识类任务收益也很直接，但前提是 Skill 里的知识本身可靠。长上下文一致性这类偏记忆的任务，Skill 帮不上太多忙，别在这上面浪费精力。

至于挂载策略，我的经验是：宁可少挂，不要乱挂。单 Skill 组在几乎所有任务上都优于多 Skill 组，这个结论有点反直觉，但数据摆在那。Skill 之间会互相干扰，上下文会被稀释，Agent 的注意力是有限资源。与其装十个半吊子 Skill，不如打磨两三个真正高质量的。

后续我打算把这套评测框架再扩展两个方向。一是加入成本维度，把 token 消耗和响应时间也纳入评分，因为 Skill 带来的上下文膨胀是有真金白银代价的。二是做 Skill 的 A/B 迭代测试，同一个 Skill 的两个版本对照跑，用数据驱动 Skill 的优化，而不是靠拍脑袋改。这套东西跑顺了，其实就形成了一个小型的 Skill 质量闭环，比单纯堆数量有意义得多。