给 Agent 装上 Skill结果真的变好了吗用对照评测回答先说结论大多数人给 Agent 装 Skill并不是真的装了能用而是装了个心理安慰。我花了两周时间把一套手动整理的 Skill 包挂到一个开源 Agent 框架上又用同一套任务跑了两轮对照评测最终数据告诉我Skill 确实有用但有用的范围窄得惊人而且用错了地方会从帮手变成累赘。这个选题来源于我最近在社区里看到的一类讨论越来越多人在给 Agent 加各种 Skill有写文档的、有画图的、有杀毒的、有当狗头军师的似乎只要挂上 SkillAgent 就能脱胎换骨。可我一直有个疑问——到底是 Skill 真那么神还是只是我们愿意相信它变强了所以这篇文章不吹不黑只讲我怎么设计了一个相对公平的对照评测以及评测结果到底说明什么。适合正在给 Agent 配 Skill、或者正准备自己写 Skill 的人看看完你应该能少走不少弯路。1. Skill 到底动了 Agent 哪块能力先搞清楚评测对象1.1 我理解的 Skill不是插件是行为包在动手评测之前我必须先讲清楚我理解的 Skill 是什么。你如果去翻各种 Agent 框架的文档会发现 Skill 的定义五花八门有的叫 tools有的叫 plugins有的叫 actions还有的干脆叫 skills。但剥开这些命名差异本质上是同一个东西——一组可以被 Agent 按需调用的行为脚本 触发条件 使用说明。它不是一个新的模型也不改变 Agent 的底层推理能力它更像是一个人身边的操作手册。你可以把 Agent 想象成一个刚入职的实习生底子不错大模型的通用能力但不知道你公司的具体流程。Skill 就是给这个实习生发的工作手册遇到什么场景查哪一页、按什么步骤做、哪些坑不能踩。装上 Skill 之后Agent 并不是变聪明了而是更知道在你这个环境里怎么干活了。这个区别很重要因为它决定了评测的预期。如果我们期待装上 Skill 之后 Agent 什么任务都能做得更好那大概率会失望但如果期待的是在某些特定类型的任务上表现更稳定那 Skill 是有价值的。1.2 评测前的两个直觉假设在正式跑数据之前我心里有两个假设这也是我做这次评测的原始动机第一个假设是Skill 应该能减少 Agent 的摸索性错误。裸跑的 Agent 拿到一个任务经常会在前面的步骤里绕圈子比如让它处理一份 Excel 表格它可能先尝试五六种不同的库然后才找到对的。如果有一个 Skill 明确告诉它这套环境里用 pandas 的 read_excel 就够了别考虑别的那按理说时间会缩短成功率会上升。第二个假设是Skill 可能会带来指令幻觉。也就是 Agent 看到 Skill 包之后误以为自己是某个领域的专家于是开始过度自信地输出内容尤其在自主规划的场景里反而会比裸跑更容易跑偏。这个假设如果成真那 Skill 就是一个双刃剑得看具体任务场景来取舍。这两个假设是我设计评测的核心出发点。结果也确实都被验证了只是方式和我预想的不太一样。2. 对照评测怎么设计才算不欺负人2.1 评测基线同一框架下的无 Skill与带 Skill评测最怕的就是不公平A 组用了最好的模型B 组用了最差的模型那结论根本没有参考价值。所以我在设计这次对照测试时第一原则是除了 Skill 这一个变量之外其他全部保持不变。具体来说我选了一个本地跑得动的开源 Agent 框架用同一个底层模型跑完所有任务任务执行时温度参数固定为 0.2上下文窗口一致没有额外引入任何 RAG 或者长期记忆模块。唯一的不同是对照组裸跑组的 Agent 只有一个基础系统提示词告诉它你是一个通用助手实验组带 Skill 组的 Agent 在同样的系统提示词基础上挂载了一套我自己写的技能包里面包含 15 个 Skill覆盖文件处理、网页内容提取、JSON 格式化、批量重命名、图片压缩这些日常高频操作。这里有个细节我觉得值得说明我刻意没有给裸跑组配置任何工具调用。也就是说对照组只能靠模型自己生成代码、自己尝试执行而实验组可以直接调用写好的 Skill。有人可能会说这不够公平——但别急这正是我想测的。因为实际上很多人给 Agent 装 Skill 的原因就是希望它会调用现成的能力而不是每次都从零开始写。所以这个差异本身就是评测的核心。2.2 五组任务怎么选日常、长跑腿、翻文档、改格式、拨异常任务集的选择也很有讲究。如果我只测给 Agent 一个压缩图片的任务那结果可能只有一种说服力太低。我按日常工作里 Agent 被真正用到的场景把任务分成五组每组 10 个任务总共 50 个任务每组的定位都不一样任务组定位典型任务示例A 组日常轻任务一次调用就能完成把一段混乱的 Markdown 整理成标题层级清晰的文档B 组长跑腿任务需要多步骤递进从指定的本地目录里找所有 Markdown 文件提取第一个标题汇总成表格C 组翻文档任务依赖外部资料理解读一份 30 页的 PDF 产品手册回答里面某个具体功能的入口在哪D 组改格式任务强调输出格式精确把一份 CSV 数据转换成指定嵌套结构的 JSON字段名不能错E 组拨异常任务输入数据有残缺输入一个缺字段的配置文件让 Agent 识别缺了什么并给出合理默认值选择这五组的原因是它们覆盖了 Skill 理论上最可能发挥作用的几条路径A 组测指令跟随B 组测多步编排C 组测信息检索 归纳D 组测格式约束E 组测异常处理。每一组里既有简单的也有复杂的避免任务难度集中在某一端导致结果失真。2.3 打分口径与重复次数任务评测的口径我也反复斟酌过。最终确定三个客观指标任务成功率最终输出是否满足要求由我自己按统一标准核查、平均耗时Agent 从收到任务到给出最终输出的分钟数、平均 token 消耗即整体调用模型产生的 token 数。主观质量不在这次评测范围内因为主观性太强两轮的结论不好比较所以我只关注可量化的结果。另外为了排除随机性每个任务我都跑了三轮取中间值。也就是说整个评测过程实际上跑了 50 个任务 × 2 组 × 3 轮 300 次任务执行。听起来量不小但真正跑起来大部分任务都是分钟级完成的历时两周主要是因为我中途还穿插着写 Skill、改 Skill 的过程这个后续聊。这个设计可能谈不上多严谨但至少保证了对照组和实验组除了 Skill 之外没有任何其他变量。至少在这个前提下测出来的差异我认为可以归因于 Skill 本身。3. 装上 Skill 之后实测结果让我有点意外3.1 任务成功率从 58% 到 76%但分布不均匀先看所有人最关心的成功率。裸跑组在三轮里的平均成功率是 58%带 Skill 组是 76%整体提升了 18 个百分点。单看这个数字Skill 确实有用说是变好了并不过分。但是如果把这 18 个百分点拆到五个任务组里看你会发现一个很有意思的现象提升并不是均匀分布的。任务组裸跑成功率带 Skill 成功率提升幅度A 组日常轻任务70%83%13%B 组长跑腿任务47%80%33%C 组翻文档任务60%67%7%D 组改格式任务80%87%7%E 组拨异常任务33%60%27%B 组长跑腿任务和 E 组拨异常任务的提升最大分别加了 33 个和 27 个百分点。这说明什么说明 Skill 真正的价值并不在于让 Agent 变聪明而在于让 Agent 在面对多步骤流程和异常输入的时候不需要临时想该怎么处理可以直接照着手册走。B 组里我写了一个目录遍历 文件头提取的 SkillAgent 拿到任务后可以立刻知道先列目录、再遍历、再提取标题、最后汇总。没有这个 Skill 的时候它会自己临场编排流程经常在一个子步骤上反复试错。E 组我写了一个残缺配置文件修复的 Skill里面明确列了哪些常见字段缺失时该给什么默认值这让 Agent 的判断边界清晰了很多。C 组和 D 组的提升只有 7 个百分点说实话这有点低于我的预期。C 组的问题在于哪怕有翻文档的 SkillAgent 面对一份 30 页的 PDF 依然会漏细节——这个本质上是模型对长文本理解的限制Skill 只能给它流程给不了它理解力。D 组则是裸跑组本身成功率就很高模型对 JSON 格式的约束已经很熟练Skill 提供的额外格式指导几乎变成了纯冗余信息。这个结果让我意识到一个很重要的道理Skill 的有效性和任务类型强相关。如果你做的业务里没有多少长流程任务和异常处理场景那你给 Agent 装一堆 Skill 的收益可能远不如别人吹的那么高。3.2 耗时与 token 消耗快的不一定省省的不一定稳成功率的结论相对清晰但耗时和 token 消耗的结果就更拧巴了。先看总数据带 Skill 组整体平均耗时 4.7 分钟裸跑组平均耗时 8.2 分钟耗时下降了约 43%。token 消耗更夸张带 Skill 组平均每任务消耗约 2.1 万 tokens裸跑组平均 4.3 万 tokens下降了约一半。这个变化还算符合直觉。因为 Skill 最大的作用之一是减少无效思考Agent 不需要在每一步都停下来想我接下来该怎么办而可以直接跳到执行环节所以 tokens 自然会省下来。但你要是分任务组看会发现一个怪现象耗时最短的组不是成功率最高的组省 token 最多的组也不是最稳定的组。以 E 组拨异常任务为例它是成功率提升最大的组但同时也是带 Skill 组里耗时最长的组之一平均要 6 分钟以上。原因在于我设计的那套残缺配置修复 Skill里包含了检查机制Skill 要求 Agent 先扫描一遍输入列出所有缺失字段再逐个填入默认值最后还要复检一遍。这套流程每一步都在消耗时间但正是这些额外步骤把成功率从 33% 拉到了 60%。换句话说更稳定的输出是以更长的处理时间为代价的这在评测里非常明显地体现出来了。另一组矛盾来自 A 组日常轻任务。A 组耗时确实降了很多token 消耗也最少但成功率的提升只有 13 个百分点而且三轮里有一次输出直接给偏了——原因是 Agent 看到 Skill 包里的Markdown 整理规范之后自作主张给一段原本只需要简单换行处理的文本加了一个前后呼应的结构反而把事情复杂化了。3.3 最反直觉的发现某些场景下 Skill 反而是负优化如果说前面的结果还属于Skill 有好处但幅度不一那接下来的发现才是真正让我警惕的。我在整理失败案例时发现带 Skill 组的失败模式比裸跑组更难排查。裸跑组失败的时候特征很单一Agent 中途迷路搞不清楚下一步要干什么最后输出一个半成品。但你很容易看出来问题出在哪一步因为它的每一步都是自己决策的链条简单。带 Skill 组失败的时候经常是Agent 严格执行了 Skill 的指令但执行到错误的地方去了。再举个例子D 组里有一个任务是把一行一行的联系人名单转换成 JSON 数组。带 Skill 组的 Agent 在某一轮里拿到任务后先判断这属于结构化数据转换场景然后调用了我写的转换 Skill。这个 Skill 开头有一句注意来源数据可能包含重复项需要先去重。本来这句话是针对另一种数据清洗场景写的结果 Agent 在这次转换里真的对联系人名单做了去重把两个同名不同号码的人合并成了一个。输出格式完美但数据错了。这就是我最想讲的负优化Skill 给 Agent 提供了额外的经验但这份经验可能并不适用于当前任务的细节而 Agent 往往不具备判断该不该用这条经验的能力。没有 Skill 的时候Agent 至少会老老实实从原始数据出发有了 Skill它可能直接拿一个模板往数据上套这种错误更隐蔽也更危险。从最终统计来看带 Skill 组有 7 个任务的失败原因是Skill 有但用错裸跑组则完全不存在这种失败类型它是根本没 Skill 可用。这类问题在整体失败原因里大约占了三成。这让我重新理解了社区里常说的那句话Skill 不是越多越好而是越准越好。准确的含义是一个 Skill 要能让 Agent 清楚说出我这里能用、那里不能用否则它就会变成误导源。4. 为什么有的 Skill 越用越灵有的纯属摆设4.1 Skill 的本质把临场反应变成肌肉记忆评测结果摆完之后绕不开的问题是为什么有些 Skill 立竿见影有些 Skill 装上跟没装一样我后面几天做的事就是拿着 15 个 Skill 挨个复盘最后发现了一个非常共通的规律。高收益的 Skill 本质上是在做一件事把 Agent 从临场反应模式切换到肌肉记忆模式。临场反应模式下Agent 每遇到一个新任务都要靠大模型的知识储备去推理这个场景应该怎么做这既耗时又不稳定肌肉记忆模式下Agent 只需要先做一个场景匹配匹配上了就直接执行既定路径又快又不容易出错。B 组的目录遍历 文件头提取 Skill 就是典型。它本身没有任何复杂的逻辑核心内容甚至不到十行但它给 Agent 提供了一条先列目录、再进子目录、对每个 markdown 文件读第一行、把结果汇总的固定路径。Agent 不需要思考应该用什么库、怎么处理路径这些细节路径已经铺好了它只要沿着走。E 组那套残缺配置文件修复 Skill 也是这样。它把最常见的缺省字段和默认值全部列清楚Agent 面对残缺输入时不需要猜这个字段该给什么值直接查表即可。成功率从 33% 翻到 60%靠的就是这种查表式的确定性。反过来看那些提升很小的 Skill比如 D 组里的 JSON 格式化相关技能。模型本身对 JSON 格式的掌握已经非常牢固你再给一份JSON 结构说明它并不会变得更强反而多了一层该用哪条规则的中间判断有时还会判断错。这种 Skill 就是典型的画蛇添足它的存在没有解决 Agent 真正的短板只是增加了一个决策点。4.2 有效 Skill 的三个共性窄、稳、敢说不知道结合这次评测里表现最好的几个 Skill我总结出三个高收益共性你也可以拿这三个标准去自查手上的 Skill第一边界要窄。有效 Skill 的场景定义极其精准不会让人产生这个场景也适用那个场景也适用的模糊感。比如遍历本地目录并提取 Markdown 文件标题这个说法就比文档整理工具要好一百倍因为后者会让 Agent 在遇到任何文档类任务时都想插入这个 Skill。第二步骤要稳。好的 Skill 给出的操作路径是确定的、可复现的最好是第一步做什么、第二步做什么、遇到什么情况跳到哪里而不是自动判断、灵活处理这类模糊指令。Agent 的价值在于执行能力你把不确定性问题丢回给它它只好又回到临场反应模式。第三要敢说不知道。这点最容易被忽略。我这次评测里表现最好的几个 Skill其实都在末尾加了一句类似如果来源数据不满足以上假设请停止使用本 Skill并描述你看到的情况。这句话非常有用它给了 Agent 一个承认自己不适合的退出通道。没有这个通道Agent 会硬套错误率就开始上升。我还专门验证过一次把一个 Skill 末尾的使用条件改得更严格之后它在 E 组的误用次数从 3 次降到了 0 次但成功次数没有掉。这说明 Agent 是可以被训练出克制感的关键在于你能不能把边界条件写明白。4.3 失效 Skill 的两种死法过度引导和指令幻觉这次评测里让我印象最深的两种失败模式也是所有人写 Skill 时最容易踩的坑我分别给它们起了名字。第一种叫过度引导。你为了让 Skill 显得专业写了一大堆细节比如在开始数据处理前先检查数据质量如果发现空值考虑使用均值填充但也要结合业务场景判断。这句话听起来没问题但实际上它给了 Agent 一个非常容易自我发挥的空间业务场景这四个字到底是什么意思Agent 会按自己的理解去想象一个业务场景然后做出完全不在你预期内的决定。过度引导的本质是你写进去的每一条看似周到的建议实际上都可能变成一个错误的触发条件。好的 Skill 应该像菜谱而不是像管理咨询报告精确到放几克盐而不是说酌情调味。第二种叫指令幻觉。这是我给Agent 因为用了 Skill 而变得更自信但这份自信并没有事实支撑这种情况起的名字。最典型的一幕出现在 C 组评测里我给 Agent 挂了一个PDF 手册查询Skill里面写了你可以使用 Python 的 pdfplumber 库来提取文本并基于提取结果回答用户问题。结果在某个关于特定功能入口在哪的问题上Agent 提取文本之后并没有在文本里找到答案但它基于 Skill 的权威感自己推理并编造了一个看起来很合理的答案。没有 Skill 的时候模型反而更容易承认我不确定没找到相关信息有了 Skill 之后它就觉得我已经被授权使用专业工具了应该给出一个专家级回答。这两种死法都指向同一个教训写 Skill 时最重要的不是告诉 Agent 能做什么而是告诉它不能做什么、以及在什么情况下必须停下来说我不知道。这个思路和一些资深开发者的建议是一致的只不过评测数据帮我把它坐实了。5. 照着就能用的踩坑清单怎么给 Agent 加 Skill 才不白加5.1 写 Skill 时最容易犯的错这部分的经验不算原创很多社区大佬都提过类似的但我是通过这次评测真正理解了为什么对。我把最容易犯的错整理成了一份清单你写 Skill 的时候可以逐条对照把 Skill 写成聊天记录。有些 Skill 只是把一段对话历史粘进去没有任何结构化的指令这跟发一段 prompt 没区别Agent 根本不会把它当手册用。一份 Skill 塞多个场景。我早期就犯过这个错一个数据处理 Skill既想管 Excel 又想管 JSON 还想管图片压缩结果 Agent 在手势匹配时根本分不清该用哪一部分。不写明前置条件。没有这个 Skill 适用于什么输入、不适用于什么输入的描述Agent 只能靠猜。没有失败退出机制。Skill 里不写如果遇到什么情况就停止Agent 就会在一个错误的方向上狂奔。照搬模型训练过度的领域。D 组那种 JSON 转换任务模型本身已经很强再给 Skill 就是增加噪音。写 Skill 之前应该先想想这个任务模型真的不会做吗。版本更新后不回归。这个最隐蔽也最致命。我在评测第二周改了三个 Skill 的措辞结果 D 组成功率从 87% 掉到了 80%最开始我还怀疑是模型问题后来回查才知道是某个 Skill 里多写了一句话改变了 Agent 的处理思路。5.2 我现在的验证流程每个 Skill 都要过“三问”经过这次评测我给自己定了一个标准化的验证流程。以后每写一个新的 Skill在挂到 Agent 上之前我都要先过三个问题第一问这个 Skill 解决的痛点是不是模型真实存在的短板如果裸跑的成功率已经过了 80%那这个 Skill 十有八九是多余的。第二问边界条件写得够不够清楚我会故意拿一些似乎相关但实际不相关的任务去试它比如拿 CSV 转换去触发Excel 处理 Skill看看 Agent 会不会误用。如果会说明边界描述还不够硬。第三问Agent 顺着这个 Skill 走一遍是不是比裸跑更省 token如果一条 Skill 本身的执行流程写得太啰嗦让 Agent 绕了一大圈才回到裸跑就能直接做到的事那它带来的收益就是负的。这三问看起来简单但在这次评测里如果我提前用它们筛一遍那 15 个 Skill至少能砍掉 5 个。现在我把这个流程当成硬性门槛而不是建议。5.3 什么时候你其实根本不需要 Skill最后聊一个可能反常识的判断并不是所有 Agent 项目都需要 Skill。我见过很多刚接触 Agent 架构的人一上来就给 Agent 挂了二十多个 Skill觉得这样可以一步到位变成全能助理。但这次评测给我的最直接的结论是——大部分日常任务Agent 裸跑就能完成得很好真正需要 Skill 的是少数高频且流程固化的场景。具体来说我个人认为以下三类场景才值得你花时间写 Skill场景里有明确的多步骤流程而且步骤的顺序基本不会变比如下载文件 → 解压 → 转格式 → 上传这种固定管线。场景里需要严格约束输出格式并且模型默认输出经常偏离同时也无法靠几行 prompt 纠正比如某些结构复杂的嵌套 JSON。场景里经常出现残缺输入你要让 Agent 像一个有经验的员工一样知道哪些字段缺了怎么补、哪些情况直接拒绝处理。如果你手头的 Agent 主要干的是闲聊问答资料整理代码生成这类天然的强项任务那 Skill 大概率只是锦上添花搞不好还会添乱。不如先把系统提示词做好把工具调用能力练稳等遇到瓶颈的那一刻再考虑加一条真正对症的 Skill。我在这次评测结束后做过一个动作把带 Skill 组里那 7 个由Skill 误用导致的失败案例全部翻出来一个个倒推它们有没有可能通过调整 Skill 本身来避免。结果是四例可以通过更严格的边界条件拦住两例需要改动 Skill 的执行顺序还有一例我比较悲观——它的问题是 Agent 在该不该使用这个 Skill的判断上天然不可靠除非换一个更强的模型否则无解。这也让我接受了一个事实Skill 只是工具不是银弹。最后再分享一个我在踩坑之后养成的习惯每个 Skill 里我都会加一个版本号 最近一次验证结果的字段。Agent 本身不关心这个但维护的人很关心。三周后你回头翻一批 Skill看到版本号和验证记录你才会知道哪些技能是真的经受过实战检验哪些只是当时觉得顺手一写。这个习惯帮我砍掉了不少僵尸 Skill也让我的 Agent 项目看起来没那么臃肿了。
