给 Agent 装上 Skill，结果真的变好了吗？用对照评测回答

去年年底我就开始在折腾 Agent，从最早的纯 Prompt 驱动，到后来接 Function Calling，再到今年年初开始密集地给 Agent 叠加各种各样的 Skill。说实话，一开始我对“Skill 能大幅提升 Agent 能力”这件事是半信半疑的——总觉得这玩意儿听着很像给 Prompt 换了个马甲，多挂几个文件、多塞几段描述，能有多大区别？

但等我真正把 Skill 体系搭进自己的 Agent 项目里，跑完几轮对照评测之后，我得说：结果真的变好了，但变好的方式和我一开始想的完全不一样。它不是在“智商”上让你 Agent 突飞猛进，而是在“稳定性和可维护性”上给了你一个质变。这篇文章我就用自己实际跑过的对照实验，把这个问题彻底聊透。

先说清楚我的实验背景，方便你判断我的结论适不适用于你的场景。我自己维护了一个基于 Rust 的轻量 Agent 框架，主要用于内部的知识库问答和自动化任务编排，模型层主要接 API，偶尔本地部署小参数模型做对比。Skill 在这套框架里不是一个独立服务，而是一组结构化的指令包、模板脚本和技能元数据，Agent 在外层通过一个“技能路由”模块决定当前任务要加载哪些技能。

这篇文章适合谁看？如果你是正在做 Agent 开发、想要搞清楚 Skill 到底有没有用、以及该怎么科学评估它的人，那这篇就是给你写的。我会把实验设计、评测指标、对照结果、翻车记录全部摊开来讲。

1. 先搞清楚：我们说的“Skill”到底是个什么东西？

在进入评测之前，有个问题必须先掰扯清楚——就是“Skill”这个词，在不同人嘴里含义完全不一样。如果你去翻社区，会发现有人把 Skill 理解成一段 Prompt 模板，有人把它理解成一个插件系统，还有人把它理解成 MCP 的工具集合，甚至有人直接把一个编码规范 PDF 当成 Skill 注进去。这些理解没有绝对的对错，但它们评测出来的结论肯定完全是两回事。

1.1 我理解的 Skill：一组“可插拔的能力包”

在我自己的框架里，Skill 的定位是这样的：它是一个自包含的“能力模块”，必须具备以下几个要素：

• 技能元数据：名称、描述、适用场景、触发条件、依赖关系。
• 指令文本：当该技能被激活时，要注入给 Agent 的行为指南、约束或思考路径。
• 模板脚本：具体干活用的工具代码、表格模板、提示词模板，甚至是一段可执行的脚本。
• 资源文件：技能运行时可能要读取的本地资料、参考文档、数据文件。

你可以把它理解成“给 Agent 插上的一块能力卡片”。插上之后，Agent 面对某类任务时就知道“哦，这个场景我应该用这套打法”，而不是从零开始靠着通用大模型的“临场发挥”来硬撑。

为了让你直观理解，我拿一个真实案例来说。我现在在跑一个“GIS 空间分析”的 Skill，里面装了什么？它装了一段针对空间数据操作的行为指南，告诉 Agent 在做地理数据处理时应该优先使用哪些投影坐标系、哪些库函数在处理矢量数据时容易踩坑、坐标系转换的校验方法是什么。同时它还带了一个小工具模块，封装了读取 Shapefile、坐标转换、空间查询的代码片段。更重要的是，它的元数据里写明了触发场景——只要用户提问里出现地理空间相关的关键词，技能路由器就会自动把它加载进上下文。

如果没有这个 Skill，Agent 面对“帮我分析这两个图层之间的重叠区域面积”这种任务的时候，可能需要我每一次都在 Prompt 里反复强调投影坐标系的问题，而且即便强调了，它也可能给出完全错误的空间参考。而有了 Skill，这些约束和行为规范就变成了 Agent 的“肌肉记忆”，不需要每次重新教。

1.2 为什么偏偏要叫“Skill”，而不是“Plugin”或“Tool”

这个命名差异其实反映了设计哲学的不同。Plugin（插件）的核心是“扩展功能”，它强调的是给系统增加一个新的处理能力，比如装一个翻译插件、一个图片处理插件。Tool（工具）的核心是“执行动作”，它强调的是让 Agent 能去调用某个具体函数或接口，比如搜索、计算、发请求。

Skill 的核心则是“行为模式的封装”。它不仅可以包含工具调用，还可以包含工作流程、思维范式、输出格式约束、注意事项等更“软”的东西。这是它和 Tool 最大的区别——Tool 告诉 Agent “你能做什么”，Skill 告诉 Agent “这件事你应该怎么做”。

我用一个生活化的类比来解释：Tool 就像给了你一把电钻，Skill 则是教你在不同材质墙壁上应该如何选钻头、钻孔深度应该控制多少、哪些位置要注意避开管线。前者解决“有没有工具”的问题，后者解决“会不会干活”的问题。

所以这篇文章所有评测结论，都是基于“Skill = 行为包 + 工具包 + 元数据”这个定义得出的。如果你只是把一段 Prompt 塞进系统叫它“Skill”，那我的结论可能不完全适用，建议你看完实验设计之后自己再跑一轮。

2. 对照评测怎么设计才科学：别让结论变成玄学

评测 Agent 能力这件事，最大的坑就是“感觉好像变强了”。今天回答得好一点，明天回答得差一点，受模型版本、随机采样、Prompt 微调的影响都很大。所以要想回答“给 Agent 装 Skill 是否真的变好”，必须用对照组做严谨测量，而不是凭印象下结论。

2.1 实验设计：同一套任务，三个对照组

我最终的评测方案是这样设计的——同一批测试任务，跑三组配置：

• 基线组：纯系统 Prompt + Agent 基础框架，不挂任何 Skill。
• 工具组：挂上了基础工具集（搜索、计算、文件读写等），但不挂行为类 Skill，主要用于区分“Skill 提升”和“Tool 提升”的差异。
• 完整组：工具集 + 全套 Skill 包，包括行为指南、模板脚本、场景元数据。

为什么要把工具组单独拎出来？因为很多人在评测 Skill 的时候犯了一个逻辑错误——他们先把工具加上，又把 Skill 加上，然后得出“Skill 很有用”的结论。但实际上，工具本身就是 Agent 能力提升的一大来源，如果不把工具带来的提升剥离干净，Skill 的真实贡献就被高估了。

测试基准任务我自己攒了一套，覆盖了四类典型场景：事实检索问答、多步骤推理任务、格式化输出任务、长文档处理任务。每类任务大概 20 道，总共 80 道题左右。每道题都预设了明确的标准答案或评分要点，方便后续人工打分。

2.2 评测指标：核心指标 + 辅助指标

光有任务还不够，还得想清楚“什么叫变好”。如果你只是看“答对没答对”，那很多场景下 Skill 的优势根本体现不出来。我用了这么几组指标：

核心指标（决定结论走向的）：

• 任务完成率：Agent 是否完成最终目标，并给出可用结果。
• 结果正确率：结果是否准确、符合领域规范，按要点打分，满分 100。
• 稳定一致性：同一任务跑 5 次，结果的方差有多大。方差越小越稳定。

辅助指标（用来解释“为什么好”的）：

• 平均轮次：完成任务需要和 Agent 来回多少轮。轮次少意味着少废话、少绕弯。
• Token 消耗：整体跑完消耗的总 Token 量。这个指标直接关系到成本。
• 人工干预率：有多少次任务需要人工介入纠偏才能完成。

你可能注意到我没用“响应速度”这个指标，因为我实验里发现它对 Skill 的反映基本无意义——多挂几个 Skill 文件，首次加载上下文的时间确实会长一点点，但这个差异在具体任务里往往被网络延迟和推理时间吞噬了，无法形成稳定可测的差异。

2.3 评测流程：控制变量是底线

实际跑评测的时候，我给自己设了几条铁律：

• 所有组别都使用同一个模型版本，API 参数保持一致，不允许一组温度设 0、一组温度设 0.7。
• 每一道任务，都是清空上下文、重新启动会话后再跑，不允许“上一次跑过给了 Agent 记忆优势”。
• 打分的时候只看输出结果，不看是哪个组跑出来的，尽量盲评。虽然是人工打分，但至少要做到“不知道答案来自哪一组”。
• 每道题只跑一轮打分，但对于稳定一致性指标，额外抽 10 道题各跑 5 轮取方差。

这套流程说起来简单，执行起来非常磨人。80 道题，三组配置，等于最少要跑 240 次完整会话。再加上稳定性抽测，我前前后后花了差不多一个星期才跑完。但如果你不做这套控制，后面得出的所有结论都是空中楼阁。

3. 评测结果：Skill 带来的提升到底有多大？

数据出来了，直接看结果。我把三组的总分和关键辅助指标汇总成了下面这个表，方便你对比：

接下来我把每个核心指标单独拆开讲。

3.1 任务完成率：从七成到九成，质的飞跃

基线组的任务完成率是 71.25%，也就是说有接近三成的任务，Agent 压根儿没跑完——要么中途陷入死循环，要么给出的结果是一个半成品，要么干脆直接说“我做不到”。

加了工具之后，任务完成率到了 76.25%，提升是有的，但说实话并不惊艳。工具能解决“Agent 想做但做不了”的问题，但在很多任务上 Agent 的问题是“它不知道怎么做好”，工具帮不上这个忙。

真正的大幅提升出现在完整组——90%。这个数据说明什么呢？说明 Skill 最大的作用，是把那些“本来能完成但完成得磕磕绊绊”的任务，变成了“稳定高质量完成”。它不是拔高了 Agent 的能力上限，而是抬高了下限。

这个我可以举一个非常典型的例子。我有一道测试题是要求 Agent 基于一份数据表格生成月度汇报，包括同比环比计算、异常值标注、结论总结。基线组跑的时候，它连“算环比”这个动作都忘了做，直接给了一堆废话；工具组知道去查数据文件了，但数据口径搞错了，把当月值和上月值比错了顺序；完整组挂上“数据分析汇报”这个 Skill 之后，技能脚本里明确规定了计算口径和输出模板，一次就跑出合格结果。

3.2 任务正确率：同样做到，做得好不好差别极大

任务完成率并不能完全反映质量，所以我还算了平均得分。基线组 63.4 分，工具组 69.8 分，完整组 84.2 分。这个差距比完成率还要大。

我仔细回看了打分记录，发现丢分的主要原因很集中：不是“完全不会”，而是“做得不专业”。什么叫不专业？比如处理 GIS 数据的时候选错了投影坐标系、写代码的时候忘了处理边界条件、输出报告的时候结构混乱让阅读者很难抓重点。这类问题在基线组和工具组里大量出现，而完整组因为挂了 Skill，里面写明了这些任务的坑和规范，错误率大幅下降。

这里我必须要强调一下：Skill 对“正确率”的提升，在专业性越强的领域越明显。通用领域知识问答，挂不挂 Skill 可能差异不大，因为大模型本身就会。但如果是 GIS 分析、法律文书、医疗报告、财务审计这类强规范、强领域约束的场景，没有 Skill 的 Agent 就像是一个读了万卷书但没上过一天班的大学生，知识有，但规范不懂。

3.3 稳定一致性：最容易被忽略却最要命的指标

稳定一致性是我这次评测里最看重的指标之一。同一个任务跑 5 次，结果是每次都不一样，还是基本稳定？这个指标直接决定了 Agent 能不能被应用到生产环境。

实测结果非常有意思。基线组和工具组在不少任务上出现了“五次跑出来五个答案”的情况，有时候甚至第一次答对了，第二次换个说法就错了。而完整组明显稳定得多——对于那些挂上了明确模板和步骤约束的 Skill，5 次跑出来的结构基本一致，只是个别措辞有差异。

为什么会这样？我个人的理解是，大模型的生成过程天然带有随机性，而 Skill 里的结构化指令和约束，起到了“锚定”作用。它把模型输出的空间从“无限发散”压缩到了“规范内的有限排列”，这种压缩不是通过多轮对话的反复纠偏实现的，而是通过上下文的一步到位。

这带来一个很大的好处：终于可以用“少样本验证”来评估 Agent 质量了。以前跑 Agent，你得测很多很多次才能判断它行不行，因为方差太大。现在挂了 Skill，跑两三次结果就基本一致，你可以把精力花在优化 Skill 内容上，而不是和随机性做斗争。

3.4 Token 消耗变贵了，但价值划算

数据里有一个数字你肯定注意到了：完整组的 Token 消耗是基线组的 152%。是的，挂 Skill 是要花钱的——每个 Skill 包里的指令文本、模板脚本、元数据都要作为上下文喂给模型，Token 自然就涨上去了。

这个成本增幅怎么看？我的结论是：值得，但要控制。152% 的 Token 消耗，换来了接近 21 分的正确率提升和 13.8 个百分点的人工干预率下降。如果按人工纠偏成本来折算，这个投入回报比是划算的。尤其在人工干预率从 18.8% 降到 8.8% 这个数字上，每少一次人工介入，省下的时间成本远超那点 Token 费用。

但这里有个大坑我后面会专门讲：如果你不加节制地把几十个 Skill 全挂上去，Token 消耗可能会飙到 200% 甚至 300%，而收益反而会下降。Skill 不是越多越好，正确的姿势是按需加载、精准命中，而不是“全家桶”。

4. Skill 设计中的关键经验：决定成败的往往不是模型，而是细节

前面讲的是评测结果，接下来我想聊一个更实际的问题：既然 Skill 确实有用，那什么样的 Skill 才有用？我在反复调优的过程中总结了一些比较关键的实操经验，这里一并分享出来。

4.1 精准命中比内容全面更重要：让 Agent 学会“选”而非“塞”

最反直觉的一条经验是：你给 Agent 准备好的 Skill 越多，有时候效果反而越差。原因在于，模型面对一堆不相关的技能描述时，会产生选择困难，甚至可能错误地调用一个完全不匹配的技能，带来灾难性后果。

我一开始犯过这个错误。我的框架里挂了大概 15 个 Skill，涉及数据分析、文案生成、代码审查、情绪分析等等，元数据描述也写得比较宽泛。结果评测的时候发现，Agent 在应该用“数据分析”技能的任务上，居然跑去调用了“文案生成”技能，输出的东西完全没法看。

后来我做了两件事，效果立竿见影。第一，把每个 Skill 的“触发条件”写得非常具体，里面明确列出关键词和场景特征，甚至写了“如果没有 XX 特征，不要使用本技能”这样的反向排除条件。第二，在框架层加上了一个技能路由模块，先对任务做一次轻量分类，选出 Top 3 候选技能再加载，而不是把全部技能一次性塞进上下文。这两步做完之后，误调用的现象基本消失。

所以我的建议是：宁可一个 Skill 看起来简单朴素，但触发精准、内容深刻；也不要写一个什么都沾一点、但跑起来驴唇不对马嘴的“全能插件”。Agent 的 Skill 体系设计，应该更像“手术刀”而不是“瑞士军刀”。

4.2 指令要具体到“可执行”，而不是抽象到“正确”

写 Skill 内容时，最容易犯的毛病是写一堆“正确但无用”的话。比如你在技能描述里写“要确保数据分析的准确性”，这句话没有任何问题，但对 Agent 来说毫无指导意义。它需要的是“用什么方法确保准确性”。

我给你看一个典型的反面例子和正面例子。

反面写法：“本技能用于生成月度数据分析报告。生成报告时应仔细核对数据，确保数据准确，条理清晰，结论客观。”

正面写法：“生成月度数据分析报告时，必须执行以下固定步骤：第一步，从数据文件中读取原始数据，按月份字段排序；第二步，用当前月份数值减去上一月份数值，再除以上一月份数值，得出同比增长率，保留两位小数；第三步，当单月变动率超过 20% 时，在报告中标注异常提醒；第四步，使用标题、表格、结论三段式结构输出，表格在前，结论在后。”

看出来差距了吗？反面写法是一段正确的废话，Agent 执行起来没有抓手，怎么做都对，怎么做也都不一定对。正面写法把每一个步骤、每一个判定准则都写死了，Agent 照着做，输出天然就是符合预期的。

我用一个生活化的比喻：这就好比教一个新员工做报表，如果你只说“把报表做好”，他会很迷茫；如果你说“每个月 5 号之前，从系统导出数据，按客户维度汇总，用模板填好，发给部门经理”，那这个新员工第二天就能干活。Skill 就是后者——它是把隐形知识显性化、把个人经验脚本化的过程。

4.3 模板脚本的价值远超预期：把“重复劳动”变成“一次开发，终身复用”

在 Skill 的三个组成部分里，大多数人最看重“指令文本”，最容易忽略“模板脚本”。但我的实测经验告诉我，模板脚本才是 Skill 发挥稳定作用的关键所在。

什么叫模板脚本？就是针对某类任务预先写好的半成品代码片段、输出模板、处理流程。它不一定是完整可运行的软件，而是一段“积木式”的素材片段，Agent 拿到之后稍加修改就能用。

举个例子。我写了一个“代码审查”的 Skill，里面包含了一个固定的审查检查单：内存泄漏风险、输入校验、错误处理、日志记录、并发安全。这个检查单其实就是一个 Markdown 模板，Agent 在审查任何代码时，会把这段模板加载进来，逐项检查并输出结论。有了这个模板，Agent 的审查报告不再是天马行空地写感想，而是像一个真正的资深工程师在过 Code Review 一样，结构清晰、重点突出。

再举个例子。我在处理“项目周报”这类任务的时候，Skill 里预先定义了一种“目标-进展-风险-计划”四段式写作模板。Agent 输出周报时，就算内容简单，但结构永远是合规的，永远不会写成一篇散文。对很多企业场景来说，这个稳定性比“偶然灵光一现”更重要。

4.4 版本管理：Skill 本身也要跟上“迭代”的节奏

这个坑是我后期才意识到的。Skill 不是写一次就完事了，它和代码一样需要版本管理。因为大模型能力在升级，业务需求在变化，领域规范也可能更新，一套写死的 Skill 过几个月可能就成了过时文档。

我现在给自己的 Skill 库做了这样一个约定：每个 Skill 文件头部都带版本号、更新日期、适用模型范围。每次大版本更新之后，我会重新抽十几道代表性题目，跑一遍回归评测，确认新版本没有引入副作用。这样才能保证“装 Skill 带来的变好”不是一个暂时性红利，而是一个可持续的工程能力。

5. 翻车实录：Skill 评测中我踩过的几个大坑

前面把高光时刻讲完了，现在说点得罪人的话——做对照评测过程中，我踩过的坑不比任何人少，甚至有几个坑差点让我得出完全错误的结论。这里如实记录下来，免得你再踩一遍。

5.1 元数据描述“背刺”了我：技能选错，满盘皆输

第一个坑发生在评测早期。我当时给某个 Skill 写的元数据描述是“处理与数据相关的任务”，结果在实际跑任务的时候，Agent 把用户提到的“请帮我整理一下最近的数据”这种极简指令，错误地路由到了“金融数据分析”技能上，而不是更通用的“数据整理”技能。

为什么会这样？因为大模型做技能路由，本质上是语义匹配。你描述得越宽泛，匹配的候选集就越大，命中率就越高，但错误率也越高。后来我把所有元数据的描述都改成了“极端狭窄”的风格，每个技能只面向一种非常具体的情景，同时加上“不使用时”的排除条件。改完之后，路由准确率从大约 80% 提升到了接近 97%，错误调用导致的翻车大幅下降。

这个经验特别重要，因为很多人会把精力花在 Skill 内容本身的编写上，却忽视了这个“门面”——技能描述。实际上，描述写得好不好，直接决定了 Agent 能不能在正确时刻叫出正确的技能。你可以把它想象成一个餐厅菜单里每道菜下的“适合人群”：写清楚“这道菜适合不吃辣的人”，就能尽量避免点错菜的尴尬。

5.2 评测顺序没有打乱，结果带出系统偏差

第二个坑出现在评测流程上。我第一轮评测的时候，是先把基线组全部 80 道题跑完，再跑工具组，最后跑完整组。跑完之后的数据显示工具组比基线组提升巨大，完整组又比工具组提升巨大，一切看起来都很完美。

但后来我复盘的时候发现了一个隐患：因为三组评测在时间上是先后进行的，中间穿插了我在晚上和周末对 Prompt 和 Skill 的微调，也就是说，跑完整组时候的基线模型可能已经被我调过了，或者 API 端的模型虽然版本号没变，但服务端行为可能已经在一天之内发生了变化。

为了排除时间漂移的影响，我又重新设计了一轮“轮转式”评测——三组配置按照 A-B-C / B-C-A / C-A-B 的顺序各跑一遍，然后取平均值。结果出来的数据和第一轮有出入，但趋势完全一致，完整组依然显著领先。这个坑我建议所有做 Agent 评测的人都注意一下，尤其是评测周期长、横跨几天的时候，优先打乱顺序跑，不要图省事一次性跑完一组。

5.3 Token 成本计算漏了“隐藏开销”

第三个坑是成本计算漏项。我一开始算 Token 成本时，只算了输入和输出的总 Token 数，算完发现完整组的成本增幅只有大约 110%，觉得“这 Skill 也太省了吧”。后来仔细看日志才发现，漏算了一个大头的 Token：技能加载失败时，Agent 会反复重新加载同一份技能文件，而这个重载过程的 Token 消耗肉眼可见地堆积了起来。

尤其是有几个大型 Skill，每个 Skill 的来源文件包含了数百行的脚本和示例数据，长度都快赶上一篇论文了。当路由判断失误时，Agent 会反复重试这个技能，单次任务就能多消耗上万 Token。修正方向也很明确：在框架层加了一次技能缓存和重试上限，同一个技能最多加载两次，超时就自动切换其他策略。修完之后，完整组的 Token 消耗从 110% 的账面上浮到了 152% 的真实数字，但总成本依然在可接受范围，而且不会再出现意外失控的情况。

5.4 别把“感觉变好”当成评测结论

最后这个坑严格来说不算技术坑，而是认知坑。我在跑完第一版评测后，有相当长一段时间觉得“Skill 绝对有用”，因为肉眼看到的输出质量确实提升了。但当我真正把任务完成率、正确率这些数据拉出来看的时候，发现提升幅度并没有我“感觉”的那么大，有一些场景甚至几乎没有提升，比如简单的事实问答型任务。

这让我意识到，人对 Agent 输出质量的感知是不可靠的，特别容易被一两个亮眼的案例带偏。你给同事演示的时候，会刻意挑一个 Skill 效果最好的任务，看的人就会觉得“太厉害了”；但如果你把这套演示给做评测的人看，他们会发现一半任务根本没触发技能、一半任务的归类逻辑也可能是错的。

所以一个负责任的 Agent 开发者，一定要建立自己的评测基准集，并且定期回归。不要相信“感觉变好了”，要相信“数据变好了”。这可能是这篇文章里最值钱的一句话。

5.5 Skill 是“未来的入口”，但当前的 Agent 框架还不够成熟

最后再说一个趋势层面的观察。目前各家 Agent 框架对 Skill 的定位其实还比较原始，更多是把“技能脚本”当成“可插拔 prompt”来用。真正成熟的 Skill 体系，应该包含更复杂的条件判断、跨技能协同、技能状态记忆、动态生成技能等能力。这些都是 Agent 走向生产可用的必经之路，也是我认为 Skill 这个方向长期的想象空间所在。

回到我自己的评测结论：Skill 确实让 Agent 变好了，但它的本质是通过工程约束提升了系统下限，而不是赋予模型“魔法”。如果你能精准设计技能、严格评测效果、持续迭代版本，那你大概率会拿到和我类似的正向结果；如果你只是把一堆文档塞进系统然后期待质量暴涨，那很可能会失望。这也就是我为什么反复强调：Skill 的价值，需要靠对照评测来验证，而评测本身，也要做成一个持续迭代的工程。

在整个过程里，我最深的体会是：给 Agent 装上 Skill，真正改变的其实不是 Agent 的智商，而是你作为开发者对它的“控制力”。这种控制力，才是 Agent 从玩具走向生产力的关键一步。