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 应该能显著变稳。我最终选了四类任务覆盖不同的能力维度任务类型具体例子考察维度结构化输出把非结构化文本转成固定 JSON schema格式稳定性多步骤流程按固定 SOP 处理一份工单流程遵循度领域知识特定行业的术语和规则应用知识准确性长上下文一致性跨多轮对话保持设定不变记忆与一致性每类任务准备 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 就会乱用或者不用。前置检查动手前要确认哪些信息齐了缺了怎么办。执行步骤分步骤写每步说清楚输入输出。输出规范格式、字段、示例越具体越好。异常处理遇到边界情况怎么退。反例明确写出“不要做什么”这条最容易被忽略但最有用。我实测下来加了反例的 SkillAgent 跑偏的概率明显下降。因为模型很擅长模仿你给它一个“错误示范”它反而更清楚边界在哪。3.3 挂载方式对结果的影响同样是挂 Skill挂法不同结果差很多。我试过三种全量常驻所有 Skill 一次性塞进上下文。结果是上下文被撑爆Agent 注意力被稀释表现最差。关键词触发靠匹配关键词决定加载哪个 Skill。问题是关键词匹配太脆稍微换个说法就触发不了。语义路由先用一个轻量判断决定该加载哪个 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, repeat3): results [] for i in range(repeat): out run_agent( prompttask[input], skillsskills, temperature0.0, max_tokens2048 ) 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(fout/{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 数据汇总把四类任务的评分汇总成表趋势就很清楚了任务类型A 组均分B 组均分C 组均分结构化输出3.24.64.1多步骤流程2.84.53.7领域知识3.04.44.2长上下文一致性4.04.23.8B 组在每一类任务上都是最优或接近最优。C 组只在领域知识上接近 B 组其余都明显回落。这个数据基本回答了我最初的疑问。5. 常见问题与排查技巧实录5.1 挂了 Skill 反而变差先查这三处遇到“装了 Skill 结果更糟”的情况按这个顺序排查触发条件是否过宽Skill 在不该触发的时候触发了Agent 用错了指导书。是否多个 Skill 指令冲突两个 Skill 对同一件事给了不同要求Agent 无所适从。Skill 内容是否本身有错前面说过错误会被放大。我踩过最深的坑是第二类。当时挂了三个 Skill其中两个都定义了输出格式格式还不一样Agent 每次输出都在两种格式之间摇摆稳定性直接崩了。5.2 常见问题速查表现象可能原因处理方式Skill 不触发触发条件太窄或措辞不匹配放宽条件增加同义表述输出格式飘多 Skill 格式定义冲突统一格式定义只保留一处步骤被跳过Skill 步骤描述不够强制用“必须”“禁止跳过”等硬约束上下文变慢变贵Skill 全量常驻改动态加载结果不稳定温度过高或 Skill 描述模糊降温度细化 Skill5.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 质量闭环比单纯堆数量有意义得多。