给 Agent 装上 Skill，这个话题在 AI 应用圈子里已经热了很久。我每次逛社区都能看到有人晒出自己的 skill 配置，什么“狗头军师 skill”“打斗动作提示词 skill”都有，但很少有人认真问一句：装上之后效果真的变好了吗？带着这个问题，我花了两周时间做了一轮对照评测：同一套模型、同一批任务、唯一变量就是是否启用 Skill。这篇文章不打算说服你 skill 一定有用，而是把评测思路、配置细节、实测数据和踩坑经历全部摊开，你照着做一遍，就知道自己的项目该不该上 Skill。

1. 评测思路：为什么必须用对照实验说话

1.1 Skill 热潮背后的真实需求

先聊一个现状。现在做 Agent 开发，最让人头疼的不是模型能力不够，而是“同一个模型，换个任务就变成另一个模型”。我在生产环境里遇到过太多次：让 Agent 处理客服工单时表现良好，一旦让它按固定格式导出日报，就开始自由发挥，不是漏掉字段，就是把时间范围理解错。这类问题本质上是模型缺少结构化的任务约束。

Skill 被寄予厚望，正是因为它在模型和任务之间加了一层“可插拔的流程知识”。它不像普通 Prompt 只是告诉模型“你要做什么”，而是把任务拆解后的步骤、规则、格式、边界都写进一个独立模块，Agent 可以根据任务自主选择是否加载。听起来很合理，但这里有个关键前提：如果模型本身会推理出正确流程，Skill 就是冗余；如果推理不出来，Skill 真正起作用的前提是——你写对了。

我在评测前见过两类极端观点。一类人把 Skill 当成万能宝典，装上之后连续失败了几次就怀疑人生；另一类人坚决反对 Skill，认为它只会把上下文搞长、把模型的注意力带偏。这两类观点都有一个共同毛病：没有做控制变量的实验。所以我在设计评测时给自己定了底线，不看单次成败，不看“感觉变好了”，只看重复多次后能不能在指标上胜出。

1.2 对照评测的基本原则

这次评测我采用了一个最朴素的思路：控制变量。所有场景都使用同一个模型版本、相同的温度参数、相同的工具集，唯一区别是“是否加载 Skill”。跑一轮不算数，每个任务至少跑 5 次，取中位数和成功率。为了让结果可信，我把评测拆成三层：

第一层是任务层。我选了三种差异足够大的任务，覆盖数据分析、多步骤流程操作、长文本创作。为什么选这种组合？因为 Skill 在不同任务上的收益机制完全不同。数据分析任务是“流程固定但样例少”，多步骤操作是“动作多且依赖前置状态”，长文本创作是“风格和结构隐性”。三种任务恰好代表了 Skill 最容易翻车的三个维度。

第二层是配置层。为了不把 Skill 的效果和模型基础能力混为一谈，我把 Skill 文件统一放在同一个目录下，命名清晰、说明明确，并且在每次评测前清空会话上下文。这样测出来的差异基本可以归因于 Skill 本身。

第三层是指标层。我不只看成功或失败，还看这几个东西：任务成功率、平均消耗 Token、处理时长、需要人工干预的次数。成功率能看出硬效果，Token 能看出成本变化，人工干预能看出稳定性。四类指标合起来，才能判断一个 Skill 到底是“让 Agent 更强了”，还是仅仅“让 Agent 更啰嗦了”。

1.3 评测任务与指标定义

具体指标我定义成下面这张表，方便后续套用到你自己的项目里。

评测任务具体是：销售日报生成、会议纪要归档、品牌文案改写。这三个任务我后续会详细拆解，每个任务都有明确的验收标准。比如销售日报，必须包含截止时间、环比数据、Top5 商品、异常提醒四块，任何一块缺失都算失败；会议纪要归档，必须把行动项提取到指定格式；品牌文案改写，必须在保留事实信息的前提下，把语气切换成指定的“口语化带货风”。

2. Skill 的典型实现与配置细节

2.1 Skill 不是 Plugin，也不是普通 Prompt

在进入实测之前，我觉得有必要把 Skill 和容易混淆的概念掰清楚。现在市面上的名词太多了，Plugin、Tool、Harness、Skill、Workflow，很多人连边界都没搞清，就开始写配置文件，结果自然很混乱。我自己的理解是这样的：

Plugin 和 Tool 偏重“外部能力”，它们解决的是 Agent 能不能执行某个动作的问题，比如访问数据库、调用搜索接口、操作浏览器。Skill 偏重“内部方法”，它解决的是 Agent 知道该怎么执行的问题，比如“给销售数据做日报时，环比是要用昨天的数据算，而不是上周同一天”。两者不能互相替代，但也不矛盾，Skill 可以指导 Agent 怎么用 Tool。

普通 Prompt 和 Skill 的区别更微妙。普通 Prompt 是一次性的、和目标任务强绑定的；而 Skill 是可复用、可组合、按需加载的模块。你可以把 Prompt 理解成“临时给 Agent 开的窍”，把 Skill 理解成“长期保存在仓库里的操作手册”。Agent 没有 Skill 时可以靠推理，有了 Skill 理论上可以少走弯路，前提是它能正确识别什么时候用这份手册。

从实现方式上看，不同 Agent 框架的 Skill 形态差异很大，但核心逻辑基本一致：一个可独立识别的文件或目录，包含指令、示例、规则，以及可选的资源文件。我在这次评测中用的是一种很轻量的 Markdown 形式，不依赖特殊框架，几乎所有支持自定义指令的 Agent 都能用。

2.2 一份可复现的 Skill 配置长什么样

我用的 Skill 目录结构是这样的：

skills/ └── sales-report/ ├── SKILL.md └── examples/ └── sample-report.md

SKILL.md 是核心文件，里面用结构化文本描述这个 Skill 的用途、触发条件、执行步骤和限制。我给销售日报场景写的简化版本大概是这样的：

--- name: sales-daily-report description: 根据销售明细生成日报，包含日期范围、环比、Top5 商品和异常提醒。 trigger: 用户要求生成销售日报、日报、今日销售汇总 version: 1.0 --- ## 执行规则 1. 先确认统计日期：默认是昨天，若用户指定日期则用指定日期。 2. 统计口径：GMV 只统计支付成功订单，退款订单剔除。 3. 环比基准：昨天与前天相比，不是上周同日。 4. 输出格式：按“总体概况 - 商品排行 - 异常提醒”三段输出。 ## 示例 见 examples/sample-report.md，输出格式必须与示例保持一致。

这份配置里，最关键的不是规则本身，而是trigger字段。Agent 拿到任务后，不是无脑加载所有 Skill，而是先根据描述判断当前任务和哪个 Skill 匹配。如果你的 Skill 触发条件写得太宽，模型会在所有任务上都试图套用它，结果反而干扰主流程。我在实测中就遇到过，一个面向“数据分析”的 Skill，把用户请它写欢迎语的请求也拦截了，害得我先花了好几分钟排查才找到原因。

还要补充一个细节：Skill 内的步骤描述不要写成散文，要写成“动作 + 条件 + 期望结果”的结构。例如“确认统计日期：默认是昨天，若用户指定日期则用指定日期”。这种写法方便模型在推理时“抄作业”。如果写成大段背景说明，模型反而会迷失在文本里，等于给上下文塞了一大块噪音。

2.3 装载 Skill 容易踩的坑

说完文件结构，再讲装载过程中的问题。很多人把 Skill 文件放进目录就算完事，我建议你再检查三件事。

第一，命名和目录层级。Agent 扫描 Skill 时通常依赖文件名和元信息里的name字段，如果目录名和name不一致，部分框架会识别失败或加载错误文件。我在项目里强制要求目录名、文件名、name字段保持一致，这个习惯帮我避免了好几次诡异错误。

第二，上下文长度。Skill 文件不是越长越好。我见过有人把一份几百行的操作手册塞进去，结果每次任务都要吃掉好几千 Token，模型反而被罗嗦的规则带偏。我的经验是：一个 Skill 的正文控制在 30 行以内，如果超过，就拆分成两个 Skill。规则越精简，模型越容易遵守。

第三，版本管理。Skill 改了之后，如果是线上项目，要特别注意 Agent 的上下文缓存。有些框架会把已经读过的 Skill 内容缓存进上下文，即使你更新了文件，下一次任务用的仍然是旧版本。那次我更新了报表口径说明，改了三天都没生效，最后发现是沙盒里残留了旧的任务上下文。后来我养成一个习惯，每次改动 Skill 后强制开启新会话测试一次。

2.4 为什么明明配置正确，效果却还是不好

配置正确不代表效果必然变好，这是我这次评测里最扎心的发现。原因其实不复杂：Agent 是一个复杂的概率系统，Skill 只是给它的推理过程增加了一个“脚手架”，并不改变模型内部的决策偏好。

举个例子，同一个销售日报 Skill，在两个不同模型上的表现差别很大。模型 A 的指令遵循能力强，读完规则后能严格执行；模型 B 的指令遵循能力弱，即使规则写在前面，它也习惯性地按自己的训练记忆去理解“环比”。这说明 Skill 的上限由模型能力决定，下线由 Skill 质量决定。如果你的模型本身连 Basic Prompt 都执行不好，别急着加 Skill，先把模型换成更听话的版本，或者提高基础指令的清晰度。

这个现象也提醒我，评测 Skill 时要固定模型版本，不要今天用一个模型，明天换另一个，那样的结果没有参考价值。

3. 三组对照实测：数据与结果

3.1 场景 A：销售日报生成

第一组任务是从模拟销售明细表生成日报。这个任务的典型难点是时间口径和计算逻辑。我故意在测试数据里埋了一个坑：昨天的数据里包含了 15 笔退款订单，模型如果不按规则剔除，算出来的 GMV 就会偏高。同时，我把“环比”字段设计成容易混淆，让模型误以为是与上周同日比较。

没有 Skill 时，Agent 的表现是：5 次任务成功了 3 次，失败原因全部出在口径上，有 2 次把退款订单算进去，有 1 次把环比基准拿错了。平均耗时 48 秒，平均消耗 Token 约 4200。最让我头疼的是，它每次都会先在日历问题上纠缠半天，然后才进入计算环节。

启用 Skill 后，情况明显改善：5 次任务成功了 4 次，失败的那次是因为测试数据里出现了一个极端值，模型没有触发异常提醒逻辑。平均耗时降到 36 秒，平均 Token 消耗反而升到约 5100。Token 变多是因为 Skill 规则本身占用了一部分输入长度，但耗时缩短，人工干预率几乎降为零。

我再强调一下这个对比的意义：Skill 不是让 Agent 变聪明了，而是让它少做了很多无用功。它不再需要每次重新思考“日期取哪天”，因为规则已经写死了。代价是每次任务多吃几百 Token，但对于日报这种高频场景，稳定性的提升远比 Token 成本更有价值。

3.2 场景 B：会议纪要归档

第二组任务模拟的是会议纪要归档。输入是一段高度口语化的会议转写文本，要求提取出决议、行动项、负责人和截止日期，并把结果整理成项目文档。这个任务的关键是长文本理解和信息抽取，没有固定格式能套，非常考验 Agent 是否记住了“行动项必须对应到人”这个业务规则。

不装 Skill 的 Agent，成功率只有 40%。失败集中在一个典型问题上：角色称混乱。比如转写里说“刚才说的那个问题小吴去跟进”，模型无法确定“小吴”到底是负责人还是被通知人，经常行动项分配错误。也有几次把“建议讨论的内容”直接当成已决议事项，逻辑上就错了。

装 Skill 后，我把“行动项识别规则”和“负责人推断顺序”写清楚，包括“未指明负责人时标记为待定，不得自行猜测”。成功率升到 80%，只剩下一次因为转写文本里出现了两个同名“小王”导致分配冲突。Token 消耗从平均 6800 升到 7900，处理时长从 75 秒降到 51 秒。这里能看到，结构化规则确实降低了长文本理解的随机性。

有一点值得注意：会议纪要场景涉及的任务比较开放，Skill 不能写死所有情况，只能规定“遇到冲突怎么做”。我原本想给这个 Skill 加一个“所有不能识别的人名一律标待定”的规则，但实测中发现执行得并不好，因为它和“尽量推断负责人”的默认倾向冲突了。后来我把规则改成两段式，先让模型按顺序推断，再让它在结果末尾标注置信度，明显稳定了。

3.3 场景 C：品牌文案改写

第三组任务考验的是风格控制。我给了 Agent 一批产品卖点文档，要求改成小红书风格的账号文案，需要口语化、有情绪、能带出使用场景，同时不能虚构事实。没有 Skill 的 Agent 会写成“四平八稳”的说明书式文案，风格符合度我用人工打分只有 62 分，结构也偏死板。

给 Agent 装上写作类 Skill 后，我加入了两类内容：一类是风格规则，比如“每段开头可以叙事”、“结尾要引导互动但不是硬广”；另一类是示例，展示同一款产品的两个改写版本，让模型照着语气走。实测风格符合度提升到 85 分，而且输出的开头明显更“有钩子”。

但这个场景也有代价：Token 消耗是三个场景里增幅最大的，从平均 9000 涨到 11400，因为示例文本占据了较多上下文。而且长文本生成时，模型偶尔会把不存在的细节也写进去，幻觉率反而比不装 Skill 时高了 8%。这说明写作类 Skill 的关键在于“示范语气”和“事实边界”之间的平衡。后来我把示例从 2 个精简成 1 个，并在规则里强调“所有数字和功能必须来自原文，不得外推”，幻觉率才压下来。

这类场景给我的最大教训是：Skill 对开放性任务有效，但难度也最高，因为它介入的是模型最核心的“语言品味”层，一旦干预过头，模型会变得僵硬甚至撒谎。

3.4 把三组结果放在一起看

汇总数据用一张表就能看清：

结论不能一刀切。从“任务成功率”看，Skill 确实让流程性任务变好了；从“处理时长”看，结构化 Skill 节省了大量往返时间；但从“Token 成本”看，所有场景都有不同程度的上浮。更微妙的是，写作类 Skill 在质量分上赢了，却在幻觉和成本上输了。所以“给 Agent 装上 Skill 结果真的变好了吗”这个问题，真正的答案是：对确定性的流程任务，变好是大概率事件；对开放性的创造任务，必须严格设计规则和示例，否则副作用大于收益。

4. 装完 Skill 反而更差？排查与避坑实录

4.1 常见症状与根因对照

在实际操作中，很多人反馈装了 Skill 后 Agent 反而变笨了，我自己踩过的坑也不少。先把最常见的几种现象和根因列出来：

这些根因听起来简单，但真正定位的时候往往要花很长时间。我第一次遇到“响应变慢”时，还以为是模型服务端压力大，后来逐字查看输入上下文才发现，是一个 Skill 里塞了一段 4000 字的背景资料。模型每次都要把这 4000 字一起推理，速度怎么可能快。

4.2 一套半小时内的排查流程

如果你遇到 Skill 相关问题，建议按下面的顺序排查，而不是凭感觉乱试。

第一步，完整记录一次失败任务的输入输出。把系统提示、用户输入、Agent 每一步思考、最终输出全保存下来，重点看模型有没有真的读取 Skill 内容。我曾经遇到过一种情况，模型在思考里已经引用了 Skill 的规则，但执行时又被工具返回的报错信息干扰了，没有遵守规则，这说明问题不在 Skill 配置，而在工具调用后的状态处理。

第二步，禁用所有 Skill，跑一遍同样的任务，确认基础模型能力。如果禁用 Skill 后成功率反而更高，那你需要重新审视 Skill 的指令设计。第三步，只启用一个可疑 Skill，其他全部关闭，保持单变量。这一步能定位是不是 Skill 之间的互相干扰。不同 Skill 的触发条件如果重叠，模型会陷入选择困难，比如一个 Skill 说“遇到数据问题先检查数据质量”，另一个说“直接执行任务”，模型就会在两者间摇摆。

第四步，改写 Skill 内容。把可能冲突的规则删除，把长段落改成短句，加入更具体的示例。改完后再做一轮 A/B 测试，对比成功率和耗时。整个流程控制在半小时内是可行的，因为关键不是改得多，而是知道改哪里。

4.3 Skill 场景落地时的最佳实践

经过这轮评测，我把自己的 Skill 使用原则整理成了几条，供你参考。

第一，一个 Skill 只解决一件事。我的销售日报 Skill 绝不会混入客服话术内容，哪怕两者都涉及“用户”，因为混合职责会让模型在触发时无法准确判断。第二，Skill 的说明必须给出明确的触发和禁用条件。比如“本 Skill 仅用于日报，不适用于周报和月报”。第三，把最容易出错的点显式写出来，而不是默认模型会自己注意。比如“环比基准是昨天 vs 前天，不是上周同日”，这种规则宁可重复一遍，也不能留给模型“自由发挥”。

第四，Skill 的示例比规则更有效。我在实际评测中发现，模型很多时候能模仿示例的格式，却不能严格执行文字规则。所以我会在 Skill 里配一个 1 到 3 个示例，大小控制在 2000 Token 以内，让模型照着做。第五，定期复盘 Skill 的使用频率。如果你的 Agent 框架支持调用统计，隔一段时间看看哪些 Skill 从未被触发，直接下线，不必心疼。没有触发的 Skill 不只会增加检索负担，还可能成为“干扰源”。

4.4 一个容易被忽略的细节：Skill 不是越多越好

最后我想专门说一句：Skill 是把双刃剑，凡事都要看收益和成本的比值。我在项目里见过一个“豪华”配置，一套 Agent 里挂了 20 多个 Skill，结果主任务时常卡在“判断该用哪个 Skill”的阶段，每次任务都要消耗额外的思考 token 去选择。这种场景下的 Skill 已经退化成“噪声源”了。

更稳妥的做法是分层管理：高频固定流程、低频但确定流程、无法绕开的创造流程，分别用不同粒度的 Skill。高频固定流程的 Skill 可以详细一点，哪怕多花一点 Token 也值得；高频低确定性的流程尽量控制示例数量，避免模型展开想象；低频流程的 Skill 甚至可以做成按需加载，不常驻在上下文里。

5. 关于这次评测的个人体会

写到这里，我再分享一个自己在整个测试过程中印象最深的结论。很多人以为给 Agent 装上 Skill 就像人学会了新技能，装上就会变好，但从结果看，Skill 更准确的形容是“给模型画了一张路线图”。地图画得好，Agent 高效到达；地图画得差，比没地图更糟，因为它会让模型迷信一条错误的路径。

我个人的判断标准也变得特别简单：如果这个 Skill 能把“每一步都要靠模型现想的隐性流程”变成“可直接遵循的显式规则”，比如销售日报、会议归档这类任务，那就值得启用。如果它只是把常识换了一种说法，比如告诉模型“你要仔细分析数据”，这种 Skill 一定不要装，因为它只会增加成本、干扰判断。

产品同学问我“Skill 上线有没有风险”，我会说：风险不在 Skill 本身，而在你有没有一套快速验证的对照评测体系。像这次用的方法，控制变量、多轮跑、看成功率、看 Token、看人工干预，虽然不能让你一次就找到完美配置，但至少能让你每次修正都有方向。测多了之后你会发现，真正让 Agent 变好的，往往不是那几 KB 的规则文本，而是你愿意把它当做一个需要持续迭代的独立工程来对待。