1. 先搞清楚给 Agent 加 Skill 到底在加什么这两年 Agent 开发圈子里最热闹的话题之一就是给 Agent 装 Skill。从 SKILL.md 到 skill-creator从 codex skill 到 claude agent skills各种概念满天飞。但真正动手做过对照评测的人其实不多大部分人停留在“看别人演示很惊艳自己上手就翻车”的阶段。我前后花了三周时间用同一套任务集、同一个基座模型、同一套评测脚本跑了“裸 Agent”和“加装 Skill 的 Agent”两组对照实验样本量 240 条任务覆盖代码生成、文档处理、多步推理、工具调用四类场景。这篇文章就是把整个评测过程、数据、踩过的坑以及我对“Skill 到底有没有用”的真实判断完整摊开来讲。先说结论方向免得你看到一半才发现跟预期不符Skill 不是万能药它在特定类型的任务上有明显增益在另一些任务上几乎无感甚至在某些边界条件下会拖后腿。这个判断不是拍脑袋是 240 条任务跑出来的。如果你正在纠结要不要给自己的 Agent 项目引入 Skill 机制或者已经在用但不确定效果这篇对照评测的思路和结论应该能帮你省下不少试错成本。适合谁看三类人一是正在做 Agent 开发、考虑引入 Skill 架构的工程师二是已经用了 Skill 但没做过系统评测、想补上这一课的团队三是对 Agent 框架与编排感兴趣、想了解 Skill 机制底层逻辑的技术爱好者。不需要你是 Agent 专家但至少要跑通过一个最简单的 Agent demo否则部分实操细节会有点吃力。2. 评测方案设计怎么让对照实验真正可信2.1 为什么必须做对照评测而不是看 demo我见过太多团队评估 Skill 的方式就是拿几个精心挑选的 case 跑一遍看到输出变好了就拍板上线。这种做法的问题在于你根本不知道增益来自 Skill 本身还是来自 case 挑选的偏差还是来自模型本身的随机性。Agent 的输出方差本来就大同一个 prompt 跑三次可能三个结果不做对照根本分不清是 Skill 起了作用还是运气好。对照评测的核心逻辑很简单控制变量。同一套任务、同一个模型版本、同一套工具链、同一个评测脚本唯一变量就是“有没有装 Skill”。听起来简单实操里有一堆细节要抠下面逐个拆。2.2 任务集怎么选才有代表性我最终用的 240 条任务是从四个场景里各抽 60 条场景类别任务示例为什么选它代码生成写一个带重试的 HTTP 客户端考察结构化输出能力文档处理从长文档提取指定字段并格式化考察信息抽取与格式遵循多步推理根据多条约束推导可行方案考察链式思考稳定性工具调用调用指定 API 完成数据查询与汇总考察工具使用准确率选这四个场景的理由是它们分别对应了 Skill 可能发挥作用的四种机制格式约束、流程固化、知识注入、工具封装。如果只测代码生成你只能看到 Skill 在格式约束上的效果看不到它在工具调用上的表现结论就会偏。任务难度也做了分层每个场景里简单、中等、困难各 20 条。简单任务的定义是“裸 Agent 大概率能一次做对”困难任务是“裸 Agent 大概率翻车”。这样设计是为了看 Skill 的增益是否随任务难度变化。2.3 评测指标怎么定才不糊弄光看“输出对不对”太粗了。我用了四个指标任务完成率任务是否达成预期目标二值判定格式合规率输出是否符合要求的格式规范二值判定平均交互轮次完成任务平均需要几轮对话越低越好人工修正成本从输出到可用需要人工改多少1-5 分制前两个是硬指标后两个是效率指标。只看完成率会忽略效率差异有些 Skill 确实能让 Agent 做对但要多花三四轮对话实际体验反而更差。判定方式上完成率和格式合规率用脚本自动判定加人工抽检抽检比例 20%一致率要求 95% 以上。交互轮次和修正成本由两名评测者独立打分分歧超过 1 分的 case 拉出来讨论定稿。2.4 Skill 的写法SKILL.md 到底怎么写才有效这次评测用的 Skill 全部基于 SKILL.md 格式编写一共写了 12 个 Skill覆盖四个场景。写 Skill 这件事本身就有讲究我踩过的坑后面会细说这里先讲结构。一个有效的 SKILL.md 通常包含四块# Skill 名称 ## 适用场景 明确说明这个 Skill 在什么情况下触发 ## 执行步骤 分步骤描述 Agent 应该怎么做 ## 输出格式 给出明确的输出模板或示例 ## 边界与禁忌 说明什么情况下不应该用这个 Skill关键点是“边界与禁忌”这块很多人写 Skill 只写“该怎么做”不写“什么时候不该做”结果 Agent 在不该用的时候也硬套反而出错。这个细节在后面的问题排查部分会展开。3. 核心细节解析Skill 起作用的底层机制3.1 Skill 本质上是在改什么要理解 Skill 为什么有用或没用得先搞清楚它在 Agent 执行链路里改了什么。一个典型的 Agent 执行流程是接收任务 → 规划步骤 → 调用工具 → 生成输出。Skill 的介入点主要有三个第一改规划。Skill 里写死的执行步骤相当于给 Agent 提供了一条预设路径减少了它在规划阶段的探索成本。对于流程固定的任务这个增益很明显。第二改上下文。Skill 的内容会被注入到 prompt 里相当于给模型补充了领域知识或格式要求。对于需要特定格式输出的任务这个增益直接体现在格式合规率上。第三改工具调用。Skill 可以封装一组工具调用序列Agent 不用自己决定调哪个工具、按什么顺序调。对于工具链复杂的任务这个增益体现在调用准确率上。理解了这三个介入点你就能预判一个 Skill 在什么任务上可能有用。如果一个任务既不需要固定流程也不需要特定格式还只调一个工具那 Skill 大概率帮不上忙。3.2 对照实验里最容易忽略的变量做对照评测时有几个变量特别容易被忽略导致结论失真模型版本漂移。如果你今天跑对照组明天跑实验组中间模型服务商更新了版本结论就不可比。我的做法是两组实验在同一天内跑完中间不隔夜。温度参数。Agent 任务通常用较低温度保证稳定性但如果你对照组用 0.2实验组忘了改也是 0.2那没问题如果实验组不小心用了默认的 0.7输出方差会变大看起来像是 Skill 让结果不稳定其实是参数问题。工具链版本。如果 Skill 里封装了工具调用而工具本身的 API 有变动实验组的表现会受影响。评测期间锁定工具版本不要中途升级。评测脚本的判定逻辑。自动判定脚本如果对格式要求过严实验组因为格式更规范反而可能被判“不合规”比如多了一个换行。判定脚本要在两组实验前用同一批样本校准过。3.3 Skill 粒度写多大才合适Skill 的粒度是个很容易走极端的点。写得太细一个 Skill 只管一件事Agent 要装十几个 Skill上下文被撑爆规划阶段反而更乱。写得太粗一个 Skill 管一大类任务内部逻辑复杂Agent 执行时容易在中途迷失。我这次评测试了三种粒度细粒度每个 Skill 只覆盖一个具体操作平均 200 字中粒度每个 Skill 覆盖一类任务平均 600 字粗粒度每个 Skill 覆盖一个场景平均 1500 字实测下来中粒度在大多数场景下表现最好。细粒度的问题是 Skill 数量多Agent 选择困难粗粒度的问题是 Skill 内部步骤多Agent 执行到后半段容易偏离。这个结论和社区里一些 skill-creator 工具的默认建议是一致的它们通常也推荐单个 Skill 控制在 500-800 字。3.4 触发机制Skill 什么时候该被激活Skill 的触发方式直接影响评测结果。常见的有三种关键词触发任务描述里出现特定词就激活语义匹配用向量相似度判断任务是否匹配 Skill显式指定在任务里直接写明用哪个 Skill关键词触发最简单但最不准容易误触发。语义匹配准确率高一些但需要额外的匹配开销。显式指定最准但失去了自动化的意义。我这次评测用的是语义匹配加阈值过滤阈值设在 0.75。这个阈值是调出来的太低会误触发太高会漏触发。调阈值的过程本身就是一个小的对照实验用 50 条标注好的任务跑不同阈值看准确率和召回率的平衡点。4. 实操过程240 条任务是怎么跑完的4.1 环境搭建与基线确认环境这块没什么特别的一台 16 核 64G 的机器Agent 框架用的是自己搭的轻量编排层模型走 API 调用。关键是基线确认在装 Skill 之前先跑一遍全部 240 条任务记录裸 Agent 的表现。这一步不能省因为你的基线数据是后面所有对比的参照系。基线跑完后的数据大致是这样简单任务完成率 92%中等任务 71%困难任务 38%。格式合规率整体偏低只有 64%说明裸 Agent 在格式遵循上确实弱。平均交互轮次 3.2 轮人工修正成本平均 2.8 分。这个基线数据本身就有信息量。困难任务完成率只有 38%说明有大量任务裸 Agent 搞不定这正是 Skill 可能发挥空间的地方。格式合规率 64% 也说明如果 Skill 能在格式约束上起作用提升空间很大。4.2 Skill 编写与调试12 个 Skill 的编写花了大概五天其中调试占了大头。写 Skill 最反直觉的一点是你以为写得越详细越好实际上写太详细反而会让 Agent 僵化。比如我在一个代码生成的 Skill 里把每一步都写死了结果 Agent 遇到稍微变形的任务就不知道变通完成率反而比裸 Agent 低。调试 Skill 的方法是小步快跑先写一个最小版本用 10 条任务测看触发是否准确、执行是否顺畅再逐步补充细节。不要一次写完 800 字再测那样出了问题你都不知道是哪句话导致的。这里有个实操技巧在 Skill 里加一段“如果遇到 X 情况参考 Y 原则处理”比直接写死“遇到 X 就做 Y”更有效。前者给 Agent 留了变通空间后者容易僵化。4.3 实验组运行与数据采集实验组跑起来后数据采集要注意几点。每条任务的完整执行日志都要存下来包括触发的是哪个 Skill、执行了几轮、每轮的输入输出、最终结果。这些日志是后面分析的原材料丢了就补不回来。采集过程中我发现一个现象Skill 触发准确率本身就是一个变量。有些任务明明该触发某个 Skill但语义匹配没匹配上Agent 就按裸奔的方式做了。这类 case 要单独标记分析时区分“Skill 没触发”和“Skill 触发了但没起作用”否则结论会混。240 条任务跑完大概用了六个小时中间因为 API 限流中断过两次重跑时注意把已完成的任务结果缓存下来不要全部重跑。4.4 数据对比与显著性判断数据出来后先看整体对比指标裸 Agent加 Skill变化任务完成率67%78%11pp格式合规率64%89%25pp平均交互轮次3.22.6-0.6人工修正成本2.82.1-0.7整体看是正向的但拆到场景层面差异很大。代码生成场景完成率提升 18pp文档处理提升 15pp多步推理只提升 4pp工具调用提升 7pp。格式合规率的提升主要集中在文档处理和代码生成多步推理场景几乎没变。这个拆分结果说明Skill 的增益高度依赖任务类型。流程固定、格式要求明确的任务Skill 增益大开放式推理任务Skill 增益有限。这个结论比“Skill 有没有用”这种笼统问题有价值得多。显著性方面我用的是配对样本的检验方法完成率和格式合规率的提升在 p0.05 水平上显著交互轮次的减少也显著。多步推理场景的提升不显著说明那个 4pp 可能在噪声范围内。5. 常见问题与排查技巧实录5.1 Skill 装了但没触发怎么排查这是最高频的问题。Agent 装了 Skill但任务跑起来发现根本没走 Skill 的逻辑。排查顺序先看触发日志确认语义匹配的相似度分数是多少。如果分数低于阈值说明 Skill 的描述和任务描述语义距离太远。解决办法是改 Skill 的“适用场景”描述让它更贴近真实任务的表达方式。我试过把一个 Skill 的适用场景从“处理结构化文档”改成“从 PDF 或 Word 里提取表格数据”触发率从 40% 涨到 85%。如果分数高于阈值但没触发检查是不是有多个 Skill 同时匹配Agent 选择困难。这种情况要么合并 Skill要么在 Skill 里加优先级标记。5.2 Skill 触发了但输出反而变差这个比不触发更麻烦。常见原因有三个一是 Skill 里的步骤和任务实际需求不匹配Agent 硬套流程导致跑偏。解决办法是在 Skill 里加“如果任务不符合以下特征请忽略本 Skill”的兜底说明。二是 Skill 注入的上下文太长挤占了模型处理任务本身的注意力。我遇到过一个 Skill 写了 2000 字装上后 Agent 在简单任务上的表现反而下降。后来精简到 600 字问题消失。三是 Skill 里的输出格式和任务要求的格式冲突。比如 Skill 要求输出 JSON但任务要求输出 Markdown 表格Agent 在两者之间摇摆。这种情况要在 Skill 里明确“输出格式以任务要求为准本 Skill 的格式仅作参考”。5.3 多个 Skill 冲突怎么办当 Agent 装了多个 Skill任务可能同时匹配好几个这时候冲突就来了。我的处理原则是如果两个 Skill 覆盖的任务范围有重叠合并成一个如果确实需要分开在 Skill 里写明优先级和互斥条件在编排层加一层 Skill 选择逻辑不要让模型自己选实测下来Skill 数量控制在 5-8 个比较舒服超过 10 个之后选择准确率明显下降。这个数字和上下文窗口大小、模型能力都有关系不是绝对的但可以作为起步参考。5.4 评测数据看起来好但实际体验差这种情况通常是评测指标和真实体验脱节。比如完成率上去了但 Agent 的输出变得很啰嗦用户要花更多时间读。或者格式合规率上去了但内容质量下降了。解决办法是在评测指标里加入“输出长度”和“内容质量评分”。内容质量评分可以人工抽检也可以用一个独立的评判模型来打分。我这次评测后期补了这两个指标发现有些 Skill 确实存在“为了格式牺牲内容”的问题。5.5 常见问题速查表问题现象可能原因排查动作Skill 不触发语义距离远改适用场景描述Skill 不触发多 Skill 竞争合并或加优先级触发后变差流程不匹配加兜底说明触发后变差上下文过长精简 Skill 字数触发后变差格式冲突明确格式优先级多 Skill 冲突覆盖范围重叠合并 Skill数据好体验差指标脱节补输出长度和质量指标6. 几个反直觉的发现和我的判断6.1 Skill 不是越多越好但也不是越少越好社区里有一种声音说“Skill 要少而精”另一种说“Skill 要覆盖全面”。我的实测数据不支持任何一种极端。Skill 数量在 5-8 个时综合表现最好少于 5 个覆盖不足多于 10 个选择困难。这个区间和任务集的复杂度有关任务类型越多需要的 Skill 越多但边际收益递减很快。6.2 困难任务上 Skill 的增益反而不如中等任务这个发现有点反直觉。我原本以为困难任务裸 Agent 搞不定Skill 应该帮助最大。实际数据是中等任务完成率提升 14pp困难任务只提升 6pp。原因是困难任务往往需要灵活变通而 Skill 提供的固定流程反而限制了 Agent 的发挥空间。中等任务流程相对固定Skill 的增益最明显。这个结论对实践的指导是优先给中等难度的、流程相对固定的任务写 Skill不要一上来就啃最难的骨头。6.3 格式合规率的提升最稳定也最容易被低估四个场景里格式合规率的提升是最稳定的几乎在所有任务类型上都有正向效果。这个增益看起来不如完成率提升那么“性感”但在实际生产环境里格式合规意味着下游系统能直接消费输出省掉大量后处理工作。如果你的 Agent 输出要对接其他系统Skill 在格式约束上的价值可能比完成率提升更实在。6.4 我的整体判断给 Agent 装 Skill在流程相对固定、格式要求明确的任务上确实能带来可测量的提升尤其是格式合规率和交互效率。但在开放式推理任务上Skill 的增益有限甚至可能因为限制灵活性而拖后腿。Skill 的价值不在于“让 Agent 变聪明”而在于“让 Agent 变稳定、变规范”。想清楚这一点你就知道该在什么场景下用它不该在什么场景下用它。最后分享一个实操中的小技巧写 Skill 的时候先别急着写“该怎么做”先写“什么时候不该用这个 Skill”。把边界条件想清楚Skill 的触发准确率和执行稳定性都会好很多。这个习惯我是在踩了无数次“Skill 误触发导致输出跑偏”的坑之后才养成的希望对你有用。 
长河君 · 2026/10/28 10:04:32 · 阅读 1.2k Agent Skill 对照评测：240条任务实测，Skill到底有没有用？
1. 先搞清楚给 Agent 加 Skill 到底在加什么这两年 Agent 开发圈子里最热闹的话题之一就是给 Agent 装 Skill。从 SKILL.md 到 skill-creator从 codex skill 到 claude agent skills各种概念满天飞。但真正动手做过对照评测的人其实不多大部分人停留在“看别人演示很惊艳自己上手就翻车”的阶段。我前后花了三周时间用同一套任务集、同一个基座模型、同一套评测脚本跑了“裸 Agent”和“加装 Skill 的 Agent”两组对照实验样本量 240 条任务覆盖代码生成、文档处理、多步推理、工具调用四类场景。这篇文章就是把整个评测过程、数据、踩过的坑以及我对“Skill 到底有没有用”的真实判断完整摊开来讲。先说结论方向免得你看到一半才发现跟预期不符Skill 不是万能药它在特定类型的任务上有明显增益在另一些任务上几乎无感甚至在某些边界条件下会拖后腿。这个判断不是拍脑袋是 240 条任务跑出来的。如果你正在纠结要不要给自己的 Agent 项目引入 Skill 机制或者已经在用但不确定效果这篇对照评测的思路和结论应该能帮你省下不少试错成本。适合谁看三类人一是正在做 Agent 开发、考虑引入 Skill 架构的工程师二是已经用了 Skill 但没做过系统评测、想补上这一课的团队三是对 Agent 框架与编排感兴趣、想了解 Skill 机制底层逻辑的技术爱好者。不需要你是 Agent 专家但至少要跑通过一个最简单的 Agent demo否则部分实操细节会有点吃力。2. 评测方案设计怎么让对照实验真正可信2.1 为什么必须做对照评测而不是看 demo我见过太多团队评估 Skill 的方式就是拿几个精心挑选的 case 跑一遍看到输出变好了就拍板上线。这种做法的问题在于你根本不知道增益来自 Skill 本身还是来自 case 挑选的偏差还是来自模型本身的随机性。Agent 的输出方差本来就大同一个 prompt 跑三次可能三个结果不做对照根本分不清是 Skill 起了作用还是运气好。对照评测的核心逻辑很简单控制变量。同一套任务、同一个模型版本、同一套工具链、同一个评测脚本唯一变量就是“有没有装 Skill”。听起来简单实操里有一堆细节要抠下面逐个拆。2.2 任务集怎么选才有代表性我最终用的 240 条任务是从四个场景里各抽 60 条场景类别任务示例为什么选它代码生成写一个带重试的 HTTP 客户端考察结构化输出能力文档处理从长文档提取指定字段并格式化考察信息抽取与格式遵循多步推理根据多条约束推导可行方案考察链式思考稳定性工具调用调用指定 API 完成数据查询与汇总考察工具使用准确率选这四个场景的理由是它们分别对应了 Skill 可能发挥作用的四种机制格式约束、流程固化、知识注入、工具封装。如果只测代码生成你只能看到 Skill 在格式约束上的效果看不到它在工具调用上的表现结论就会偏。任务难度也做了分层每个场景里简单、中等、困难各 20 条。简单任务的定义是“裸 Agent 大概率能一次做对”困难任务是“裸 Agent 大概率翻车”。这样设计是为了看 Skill 的增益是否随任务难度变化。2.3 评测指标怎么定才不糊弄光看“输出对不对”太粗了。我用了四个指标任务完成率任务是否达成预期目标二值判定格式合规率输出是否符合要求的格式规范二值判定平均交互轮次完成任务平均需要几轮对话越低越好人工修正成本从输出到可用需要人工改多少1-5 分制前两个是硬指标后两个是效率指标。只看完成率会忽略效率差异有些 Skill 确实能让 Agent 做对但要多花三四轮对话实际体验反而更差。判定方式上完成率和格式合规率用脚本自动判定加人工抽检抽检比例 20%一致率要求 95% 以上。交互轮次和修正成本由两名评测者独立打分分歧超过 1 分的 case 拉出来讨论定稿。2.4 Skill 的写法SKILL.md 到底怎么写才有效这次评测用的 Skill 全部基于 SKILL.md 格式编写一共写了 12 个 Skill覆盖四个场景。写 Skill 这件事本身就有讲究我踩过的坑后面会细说这里先讲结构。一个有效的 SKILL.md 通常包含四块# Skill 名称 ## 适用场景 明确说明这个 Skill 在什么情况下触发 ## 执行步骤 分步骤描述 Agent 应该怎么做 ## 输出格式 给出明确的输出模板或示例 ## 边界与禁忌 说明什么情况下不应该用这个 Skill关键点是“边界与禁忌”这块很多人写 Skill 只写“该怎么做”不写“什么时候不该做”结果 Agent 在不该用的时候也硬套反而出错。这个细节在后面的问题排查部分会展开。3. 核心细节解析Skill 起作用的底层机制3.1 Skill 本质上是在改什么要理解 Skill 为什么有用或没用得先搞清楚它在 Agent 执行链路里改了什么。一个典型的 Agent 执行流程是接收任务 → 规划步骤 → 调用工具 → 生成输出。Skill 的介入点主要有三个第一改规划。Skill 里写死的执行步骤相当于给 Agent 提供了一条预设路径减少了它在规划阶段的探索成本。对于流程固定的任务这个增益很明显。第二改上下文。Skill 的内容会被注入到 prompt 里相当于给模型补充了领域知识或格式要求。对于需要特定格式输出的任务这个增益直接体现在格式合规率上。第三改工具调用。Skill 可以封装一组工具调用序列Agent 不用自己决定调哪个工具、按什么顺序调。对于工具链复杂的任务这个增益体现在调用准确率上。理解了这三个介入点你就能预判一个 Skill 在什么任务上可能有用。如果一个任务既不需要固定流程也不需要特定格式还只调一个工具那 Skill 大概率帮不上忙。3.2 对照实验里最容易忽略的变量做对照评测时有几个变量特别容易被忽略导致结论失真模型版本漂移。如果你今天跑对照组明天跑实验组中间模型服务商更新了版本结论就不可比。我的做法是两组实验在同一天内跑完中间不隔夜。温度参数。Agent 任务通常用较低温度保证稳定性但如果你对照组用 0.2实验组忘了改也是 0.2那没问题如果实验组不小心用了默认的 0.7输出方差会变大看起来像是 Skill 让结果不稳定其实是参数问题。工具链版本。如果 Skill 里封装了工具调用而工具本身的 API 有变动实验组的表现会受影响。评测期间锁定工具版本不要中途升级。评测脚本的判定逻辑。自动判定脚本如果对格式要求过严实验组因为格式更规范反而可能被判“不合规”比如多了一个换行。判定脚本要在两组实验前用同一批样本校准过。3.3 Skill 粒度写多大才合适Skill 的粒度是个很容易走极端的点。写得太细一个 Skill 只管一件事Agent 要装十几个 Skill上下文被撑爆规划阶段反而更乱。写得太粗一个 Skill 管一大类任务内部逻辑复杂Agent 执行时容易在中途迷失。我这次评测试了三种粒度细粒度每个 Skill 只覆盖一个具体操作平均 200 字中粒度每个 Skill 覆盖一类任务平均 600 字粗粒度每个 Skill 覆盖一个场景平均 1500 字实测下来中粒度在大多数场景下表现最好。细粒度的问题是 Skill 数量多Agent 选择困难粗粒度的问题是 Skill 内部步骤多Agent 执行到后半段容易偏离。这个结论和社区里一些 skill-creator 工具的默认建议是一致的它们通常也推荐单个 Skill 控制在 500-800 字。3.4 触发机制Skill 什么时候该被激活Skill 的触发方式直接影响评测结果。常见的有三种关键词触发任务描述里出现特定词就激活语义匹配用向量相似度判断任务是否匹配 Skill显式指定在任务里直接写明用哪个 Skill关键词触发最简单但最不准容易误触发。语义匹配准确率高一些但需要额外的匹配开销。显式指定最准但失去了自动化的意义。我这次评测用的是语义匹配加阈值过滤阈值设在 0.75。这个阈值是调出来的太低会误触发太高会漏触发。调阈值的过程本身就是一个小的对照实验用 50 条标注好的任务跑不同阈值看准确率和召回率的平衡点。4. 实操过程240 条任务是怎么跑完的4.1 环境搭建与基线确认环境这块没什么特别的一台 16 核 64G 的机器Agent 框架用的是自己搭的轻量编排层模型走 API 调用。关键是基线确认在装 Skill 之前先跑一遍全部 240 条任务记录裸 Agent 的表现。这一步不能省因为你的基线数据是后面所有对比的参照系。基线跑完后的数据大致是这样简单任务完成率 92%中等任务 71%困难任务 38%。格式合规率整体偏低只有 64%说明裸 Agent 在格式遵循上确实弱。平均交互轮次 3.2 轮人工修正成本平均 2.8 分。这个基线数据本身就有信息量。困难任务完成率只有 38%说明有大量任务裸 Agent 搞不定这正是 Skill 可能发挥空间的地方。格式合规率 64% 也说明如果 Skill 能在格式约束上起作用提升空间很大。4.2 Skill 编写与调试12 个 Skill 的编写花了大概五天其中调试占了大头。写 Skill 最反直觉的一点是你以为写得越详细越好实际上写太详细反而会让 Agent 僵化。比如我在一个代码生成的 Skill 里把每一步都写死了结果 Agent 遇到稍微变形的任务就不知道变通完成率反而比裸 Agent 低。调试 Skill 的方法是小步快跑先写一个最小版本用 10 条任务测看触发是否准确、执行是否顺畅再逐步补充细节。不要一次写完 800 字再测那样出了问题你都不知道是哪句话导致的。这里有个实操技巧在 Skill 里加一段“如果遇到 X 情况参考 Y 原则处理”比直接写死“遇到 X 就做 Y”更有效。前者给 Agent 留了变通空间后者容易僵化。4.3 实验组运行与数据采集实验组跑起来后数据采集要注意几点。每条任务的完整执行日志都要存下来包括触发的是哪个 Skill、执行了几轮、每轮的输入输出、最终结果。这些日志是后面分析的原材料丢了就补不回来。采集过程中我发现一个现象Skill 触发准确率本身就是一个变量。有些任务明明该触发某个 Skill但语义匹配没匹配上Agent 就按裸奔的方式做了。这类 case 要单独标记分析时区分“Skill 没触发”和“Skill 触发了但没起作用”否则结论会混。240 条任务跑完大概用了六个小时中间因为 API 限流中断过两次重跑时注意把已完成的任务结果缓存下来不要全部重跑。4.4 数据对比与显著性判断数据出来后先看整体对比指标裸 Agent加 Skill变化任务完成率67%78%11pp格式合规率64%89%25pp平均交互轮次3.22.6-0.6人工修正成本2.82.1-0.7整体看是正向的但拆到场景层面差异很大。代码生成场景完成率提升 18pp文档处理提升 15pp多步推理只提升 4pp工具调用提升 7pp。格式合规率的提升主要集中在文档处理和代码生成多步推理场景几乎没变。这个拆分结果说明Skill 的增益高度依赖任务类型。流程固定、格式要求明确的任务Skill 增益大开放式推理任务Skill 增益有限。这个结论比“Skill 有没有用”这种笼统问题有价值得多。显著性方面我用的是配对样本的检验方法完成率和格式合规率的提升在 p0.05 水平上显著交互轮次的减少也显著。多步推理场景的提升不显著说明那个 4pp 可能在噪声范围内。5. 常见问题与排查技巧实录5.1 Skill 装了但没触发怎么排查这是最高频的问题。Agent 装了 Skill但任务跑起来发现根本没走 Skill 的逻辑。排查顺序先看触发日志确认语义匹配的相似度分数是多少。如果分数低于阈值说明 Skill 的描述和任务描述语义距离太远。解决办法是改 Skill 的“适用场景”描述让它更贴近真实任务的表达方式。我试过把一个 Skill 的适用场景从“处理结构化文档”改成“从 PDF 或 Word 里提取表格数据”触发率从 40% 涨到 85%。如果分数高于阈值但没触发检查是不是有多个 Skill 同时匹配Agent 选择困难。这种情况要么合并 Skill要么在 Skill 里加优先级标记。5.2 Skill 触发了但输出反而变差这个比不触发更麻烦。常见原因有三个一是 Skill 里的步骤和任务实际需求不匹配Agent 硬套流程导致跑偏。解决办法是在 Skill 里加“如果任务不符合以下特征请忽略本 Skill”的兜底说明。二是 Skill 注入的上下文太长挤占了模型处理任务本身的注意力。我遇到过一个 Skill 写了 2000 字装上后 Agent 在简单任务上的表现反而下降。后来精简到 600 字问题消失。三是 Skill 里的输出格式和任务要求的格式冲突。比如 Skill 要求输出 JSON但任务要求输出 Markdown 表格Agent 在两者之间摇摆。这种情况要在 Skill 里明确“输出格式以任务要求为准本 Skill 的格式仅作参考”。5.3 多个 Skill 冲突怎么办当 Agent 装了多个 Skill任务可能同时匹配好几个这时候冲突就来了。我的处理原则是如果两个 Skill 覆盖的任务范围有重叠合并成一个如果确实需要分开在 Skill 里写明优先级和互斥条件在编排层加一层 Skill 选择逻辑不要让模型自己选实测下来Skill 数量控制在 5-8 个比较舒服超过 10 个之后选择准确率明显下降。这个数字和上下文窗口大小、模型能力都有关系不是绝对的但可以作为起步参考。5.4 评测数据看起来好但实际体验差这种情况通常是评测指标和真实体验脱节。比如完成率上去了但 Agent 的输出变得很啰嗦用户要花更多时间读。或者格式合规率上去了但内容质量下降了。解决办法是在评测指标里加入“输出长度”和“内容质量评分”。内容质量评分可以人工抽检也可以用一个独立的评判模型来打分。我这次评测后期补了这两个指标发现有些 Skill 确实存在“为了格式牺牲内容”的问题。5.5 常见问题速查表问题现象可能原因排查动作Skill 不触发语义距离远改适用场景描述Skill 不触发多 Skill 竞争合并或加优先级触发后变差流程不匹配加兜底说明触发后变差上下文过长精简 Skill 字数触发后变差格式冲突明确格式优先级多 Skill 冲突覆盖范围重叠合并 Skill数据好体验差指标脱节补输出长度和质量指标6. 几个反直觉的发现和我的判断6.1 Skill 不是越多越好但也不是越少越好社区里有一种声音说“Skill 要少而精”另一种说“Skill 要覆盖全面”。我的实测数据不支持任何一种极端。Skill 数量在 5-8 个时综合表现最好少于 5 个覆盖不足多于 10 个选择困难。这个区间和任务集的复杂度有关任务类型越多需要的 Skill 越多但边际收益递减很快。6.2 困难任务上 Skill 的增益反而不如中等任务这个发现有点反直觉。我原本以为困难任务裸 Agent 搞不定Skill 应该帮助最大。实际数据是中等任务完成率提升 14pp困难任务只提升 6pp。原因是困难任务往往需要灵活变通而 Skill 提供的固定流程反而限制了 Agent 的发挥空间。中等任务流程相对固定Skill 的增益最明显。这个结论对实践的指导是优先给中等难度的、流程相对固定的任务写 Skill不要一上来就啃最难的骨头。6.3 格式合规率的提升最稳定也最容易被低估四个场景里格式合规率的提升是最稳定的几乎在所有任务类型上都有正向效果。这个增益看起来不如完成率提升那么“性感”但在实际生产环境里格式合规意味着下游系统能直接消费输出省掉大量后处理工作。如果你的 Agent 输出要对接其他系统Skill 在格式约束上的价值可能比完成率提升更实在。6.4 我的整体判断给 Agent 装 Skill在流程相对固定、格式要求明确的任务上确实能带来可测量的提升尤其是格式合规率和交互效率。但在开放式推理任务上Skill 的增益有限甚至可能因为限制灵活性而拖后腿。Skill 的价值不在于“让 Agent 变聪明”而在于“让 Agent 变稳定、变规范”。想清楚这一点你就知道该在什么场景下用它不该在什么场景下用它。最后分享一个实操中的小技巧写 Skill 的时候先别急着写“该怎么做”先写“什么时候不该用这个 Skill”。把边界条件想清楚Skill 的触发准确率和执行稳定性都会好很多。这个习惯我是在踩了无数次“Skill 误触发导致输出跑偏”的坑之后才养成的希望对你有用。