Agent为什么都在疯狂外挂“Skills”？首个SkillsBench来了，讲透性能暴涨的底层逻辑

在2026当下的智能体（Agent）开发体系中，“为LLM加Skills”已经成为事实上的行业标准。您的Agent表现不好，是因为底层的LLM参数量不够，还是因为您喂给它的“Skills”写得一塌糊涂？无论是日常使用的各类CLI工具，还是最近的Openclaw，其底层能力的跃升很大程度上都依赖于这些特定领域的Agent Skills。

但是，整个工程界正处于一种知其然而不知其所以然的盲目调试状态。大家在一个没有精确度量衡的黑盒子里盲目堆砌Markdown文件、代码模板和标准操作流程（SOP），却没有任何标准方法来测量这些外挂内容到底提供了多少真实的性能增益。

《SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks》这项研究终结了这种系统性盲目。研究者剥离了对基础模型原生能力的过度关注，在业界首次将“技能”本身定义为可被量化测试的独立工件。该论文的背书阵容极其强悍，研究者团队由BenchFlow领衔，汇集了来自亚马逊（Amazon）、字节跳动（ByteDance）、富士康（Foxconn）等工业界巨头，以及斯坦福大学（Stanford）、卡内基梅隆大学（CMU）、加州大学伯克利分校（UC Berkeley）、哥伦比亚大学（Columbia）、牛津大学（Oxford）等数十所顶尖学术机构的联合力量 。研究者剥离了对基础模型原生能力的过度关注，在业界首次将“技能”本身定义为可被量化测试的独立工件 。通过7,308次执行轨迹的严格测试 ，研究者强行拆解了三个被业界广泛忽视的硬核问题：

• 有效性检验：Skills真的能提升表现吗？ 注入Skills后，任务的成功率绝对差值（Delta）究竟是多少？是否存在输入干扰导致模型表现倒退的负增益现象？
• 人类智慧vs. 模型自生：模型能不能自己生成Skills？ 如果Skills的本质是程序性知识（Procedural Knowledge），已经吸收了海量数据的旗舰级大模型，能否在执行任务前“自己给自己写一份小抄”？
• 设计原则摸底：好Skill的标准是什么？ 到底是一份事无巨细的“全面教科书”管用，还是由2-3个核心模块组成的“速查表”更受模型青睐？

本文将依据该论文提供的实证数据，从底层架构、增益差值、Token经济学以及5,171次真实崩溃日志，为您系统性解答上述拷问。

剥离测试环境噪音与重塑架构认知

到底什么是Skills？（与RAG、Tools的正面对比）

在深入测试环境之前，必须在架构层面上明确定义我们到底在向内存里注入什么。许多开发者常常将系统提示词（Prompts）、检索增强（RAG）和工具调用（Tools）与Skills混为一谈。研究者在论文中给出了极其精辟的技术边界划分：

• RAG 提供的是“事实性知识（Factual）”，它具备模块化特征，但缺乏程序性指导和可执行资源。
• Tools（工具调用） 提供的是“能力描述（Capabilities）”，它告诉模型某个API的功能，但同样缺乏针对复杂业务的程序性指导和可移植性。
• Skills（智能体技能） 则是唯一同时兼具“模块化复用”、“程序性指导（Procedural）”、“携带可执行资源”以及“跨模型可移植”的技术范式。

为了确保测试基础的现实代表性，研究者对GitHub、社区市场以及企业库中的生态数据进行了扫描，去重后提取了47,150个真实技能。统计显示，这些技能文件极度轻量，中位数大小仅为2.3 KB（约1500 Tokens），且主要以Markdown格式存在。这为后续设定的8K上下文滑动窗口限制提供了直接的工程依据。

构建100%确定性的基准沙盒

为了证明任务成功归功于注入的技能而非测评系统的偏见，研究者彻底抛弃了主流基准测试中泛滥的LLM-as-a-judge主观评估机制，构建了基于容器的、100%确定性验证的沙盒环境。

在SkillsBench中，包含86个候选任务（最终评估84个），覆盖11个专业领域。每一个任务必须作为一个自包含的目录结构运行，其内部严格规定了以下组件：

• 资源强隔离：通过 task.toml 声明容器的物理资源限制，例如设定1-4个CPU核心、2-10 GB内存，并强制限定600-1200秒的严格超时预算。
• 基准参考实现（Oracle）：每个任务必须包含一个 solve.sh 脚本，该参考实现必须在隔离的Ubuntu 24.04容器中实现100%的测试通过率。
• 确定性断言：测试逻辑全部交由 pytest 处理，并通过CTRF（通用测试报告格式）输出JSON结果。任务仅产生二进制的0或1奖励（Pass/Fail），不存在任何部分得分（Partial credit）的模糊地带。
• 反泄漏审查：为防止技能演变成针对测试题的硬编码答案，研究者使用了GPTZero结合人工审查，确保任务指令 instruction.md 绝非由AI生成。同时，技能文件内被禁止包含特定测试案例的值、常量或确切的解答命令序列。

拷问一的解答：增益差值与负向溢出

实验矩阵涵盖了Claude Code、Gemini CLI和Codex CLI三种商业外壳，搭配GPT-5.2、Claude 3家族（Opus/Sonnet/Haiku 4.5及Opus 4.6）以及Gemini 3家族（Pro/Flash）等7种模型组合。

1.绝对增益的量化数据

实证数据显示，人工策划的技能带来了明确的正向收益。在7种配置下，外挂技能使得平均绝对通过率提升了16.2个百分点（从24.3%提升至40.6%）。

• 最大提升幅度：Claude Code搭配Opus 4.5获得了全场最大的增益，通过率增加了23.3个百分点（规范化增益达29.9%）。这与Claude模型家族本身对Agent Skills规范的底层感知能力存在关联。
• 最高能力上限：Gemini CLI搭配Gemini 3 Flash在技能加持下，拿下了48.7%的全场最高绝对通过率。

在数据处理层面，研究者还引入了物理学教育领域的规范化增益（Normalized Gain）公式来排除天花板效应：

其中Opus 4.5的规范化增益达到了29.9%。

2.领域差异的颗粒度下钻

增益并非均匀分布，而是呈现出极其严重的领域异质性。

• 在需要生僻工作流规范的领域，增益呈现出统治力。医疗保健领域（如临床实验室数据单位协调任务）获得了高达+51.9个百分点的提升。制造业排在第二，获得了+41.9个百分点的增益。
• 相反，在模型预训练语料极度丰富的领域，如软件工程（Software Engineering）和数学（Mathematics），注入技能的提升分别仅+4.5个百分点和+6.0个百分点。

3.反常识剖析：为什么注入技能会引发崩溃？

数据中最具技术价值的发现是：在评估的84个任务中，有16个任务在引入人工技能后，模型的表现反而出现了负增益（Negative Deltas）。

• 例如，在 taxonomy-tree-merge 任务中，通过率暴跌了39.3个百分点。
• 在 energy-ac-optimal-power-flow 任务中，通过率下降了14.3个百分点。 研究者的日志审查揭示了其背后的机理：当基础模型已经对某类任务拥有强大的先验知识时，强制注入的外部程序性知识如果不完全对齐模型的内部逻辑，就会引入“冲突的指导（conflicting guidance）”。此外，额外的复杂规范消耗了有限的上下文预算，导致模型在处理原本能够直接解决的问题时产生过度设计或认知过载。

Harness的底层调度差异与“模型傲慢”

资深工程师深知，技能的效用不仅取决于模型智商，还取决于外壳（Harness）的调度实现。研究者在论文中揭示了深水区的技术差异：

• 隐式扫描vs. 显式调用：Claude Code和Codex是通过将技能文件放置于隐藏目录（如 /root/.claude/skills），让模型隐式读取 SKILL.md 的前置元数据来发现技能；而Gemini CLI则暴露出一个名为 activate_skill 的明确工具，要求模型必须主动执行显式调用。
• 模型的执行傲慢：测试表明，Codex CLI搭配GPT-5.2会频繁出现一种行为模式：智能体在对话中确认并知晓了技能文件的存在，但在实际编写代码时却常常忽略提供的SOP，执意自行实现解决方案。

这也直接说明为什么同一个模型在不同的框架下是两种效果，对于这方面的研究感兴趣您还可以看下：

不用争CC、Codex哪个更好了，斯坦福众包设计了229个“变态”脏活已给出

拷问二的解答：“自我拔高”的工程错觉

既然大语言模型已经学习了GitHub上几乎所有的公开代码和StackOverflow上的工作流，开发者能否通过巧妙的系统提示词（System Prompt），让模型在执行具体任务前，先自己生成一套SOP，然后再照着执行？

研究者设置了“自生成技能（Self-Generated Skills）”条件来验证这一假设。在沙盒启动时，不提供任何人工技能，而是向模型下达明确指令要求其自行生成：

• “分析任务需求，识别所需的领域知识、API或技术。”
• “编写1-5个模块化的技能文档，聚焦特定工具库，提供代码示例和用法模式。”
• “将这些文档保存为Markdown文件放入skills目录，然后再利用这些技能来解决任务。” 实证数据击碎了这一幻想。 在支持此测试的5种配置中，自生成技能导致的平均表现比“什么都不给（No Skills）”的盲考基线还要低1.3个百分点。
• 只有Opus 4.6勉强获得了微弱的 +1.4个百分点提升。
• Codex搭配GPT-5.2的表现遭受重创，通过率急剧下降了5.6个百分点。

深入执行轨迹的分析表明，模型在试图输出自身所需的程序性知识时，会陷入两种致命的执行泥潭：

• 不精确的过程提取：模型能够意识到任务涉及某个特定领域（例如知道需要用pandas处理数据），但它生成的文档往往停留在概念层面，缺少至关重要的确切API调用模式和参数配置规则。
• 未知领域盲区（Unknown Unknowns）：对于包含密集专业知识的任务（如制造业排期或高度定制的金融报表），模型根本无法识别出自身需要补充特定的技能文件，转而试图用通用计算逻辑去硬解领域特定的格式约束，最终导致全盘崩溃。
• 时间预算消耗：模型花费了大量的时间在环境内生成和读取这些充满瑕疵的自创文档，严重挤占了真正用于解决问题的执行时间，导致超时失败率攀升。

结论非常清晰：有效的技能必须来源于人类策划的领域专长，模型目前无法可靠地编写出它自己受益的程序性知识。

拷问三的解答：反直觉的设计原则与Token

如果必须由人类工程师来编写技能包，那么其物理结构应该遵循什么规范？研究者通过量化分析，打破了“文档写得越全越好”的直觉错误。

1.数量控制与复杂度边界

• 数量阈值：针对单个任务，当环境中只挂载2到3个技能模块时，智能体的增益达到最优峰值（提升+18.6个百分点）。当挂载的技能数量达到4个或更多时，收益出现断崖式下跌，仅剩 +5.9个百分点的增益。非单调的关系表明，冗余的技能包会形成噪音并诱发幻觉。

• 复杂度倒挂：研究者根据技能文档的复杂度进行分层统计。被评定为“详细（Detailed）”和“紧凑（Compact）”的技能包，分别提供了 +18.8和 +17.1个百分点的最强增益。相反，试图涵盖所有边缘情况的“全面（Comprehensive）”型文档，实际上损害了系统表现，导致通过率下降了2.9个百分点。过度阐释的技能占用了宝贵的上下文预算，却未能提供简明直接的操作引导。

2.Token经济学与算力代偿（Token Economics） 技能的注入会显著改变模型的推理成本结构。在实际工业部署中，性能与API调用的成本权衡是不可回避的命题。

• 跨级超越：通过精确的技能注入，较小规模的模型可以逆袭。实验证明，挂载技能的Claude Haiku 4.5获得了27.7%的通过率，跨级击败了在无技能状态下裸跑的旗舰级Claude Opus 4.5（22.0%）。
• Token体积换取智能：在Gemini产品线中，研究者观察到了极端代偿策略。在挂载技能的情况下，Gemini 3 Flash单次任务消耗了高达 1.08 M（百万） 的输入Token，是更强大的Gemini 3 Pro消耗量（0.47 M）的2.3倍。较小的模型必须依赖更多的迭代探索轮数和重试机制，不断重复读取上下文来弥补推理深度的不足。
• 反向剪枝效应：高级模型Gemini 3 Pro在接入技能后，其输入Token消耗量反而下降了6%。这说明结构化的程序性知识直接阻断了高智商模型的无效探索路径，使其能够更直接地命中目标。

系统性报告（5,171次真实崩溃的底层溯源）

为了回答“在拥有人类高质量技能指导下，智能体为何依然失败”的问题，研究者对不涉及基础设施错误的5,171次智能体崩溃轨迹进行了详细的分类学尸检（Autopsy）。通过解析 pytest 日志和容器状态，失败被精确归入五个类别。

1.验证阈值失败（Quality Below Threshold） 占比49.8%这是智能体最主要的死因。模型完全遵循了指示，执行了完整的逻辑闭环，生成了目标文件，但其中的工程计算或数据抽取存在难以容忍的偏差。

2.执行超时（Agent Timeout）占比17.8%在严格限定的时间（例如900秒）内未能输出最终结果并退出。

• 反常理的副作用：数据表明，在挂载技能后，总体失败率大幅降低（从78.4%降至61.1%），但超时的相对占比却不降反升（从16.1%增加至18.6%）。这是因为人工技能帮模型绕过了早期简单的环境配置崩溃，使得模型有能力涉足任务深水区。模型在更深层的代码调试或复杂数据处理中耗尽了时间预算，未能实现“快速失败（fail fast）”。例如在处理 gravitational-wave-detection（引力波探测）时，由于需要构建复杂的带通滤波和信噪比计算管线，多数模型直接耗尽了计算窗口被强行终止。

3.相干性断裂（Incomplete Solution）占比10.2%模型过早地宣告任务完成，提交了结构正确但内容残缺的工程产物。

• 现场还原：在 shock-analysis-supply 任务中，模型成功构建了目标Excel的基础结构，甚至完成了部分数据导入（通过了9个测试中的6个）。但它遗漏了三个计算负荷最大的步骤：加载宾州世界表（PWT）的劳动力数据、运行HP滤波优化求解器，以及计算折旧率。这反映了长上下文任务中模型规划能力的阶段性衰退。

4.早期流产（No Output Produced）占比7.9%要求输出的文件完全不存在，测试断言在第一步就触发了断点。

• 现场还原：在 gh-repo-analytics 任务中，测试桩提示“Missing /app/report.json”。因为该任务要求与本地Gitea服务器交互并拉取仓库，智能体在最基础的Git凭证处理或依赖环境配置上失败，导致整个工作流被彻底卡死，未执行任何实质性逻辑。

5.规范违规（Specification Violation）占比3.3%模型抗拒或忽视了绝对硬性的输出格式要求。

• 现场还原：在 latex-formula-extraction 任务中，指令明确要求逐行输出由 $$ 包裹的纯净LaTeX公式。然而，模型“画蛇添足”地在最终的文本文件里加上了Markdown标题和序号解释，导致基于正则表达式的测试脚本直接判零。这种自作聪明的输出习惯展示了指令微调（Instruction Tuning）中讨好人类视觉输出与严格机读约束之间的冲突。

6.成功的反例证明

作为对比，能够大幅逆转局面的成功案例则清晰展现了技能的运作机理。在 sales-pivot-analysis 任务中，无技能干预时，所有测试模型（包括GPT-5.2等）全部获得了0%的通过率。模型试图使用笨拙的DataFrame变形逻辑去手写透视表逻辑，引发大面积数组越界异常。而一旦挂载了关于 openpyxl 库特定透视表创建API的技能文档，6种模型立刻获得了超过80%的通过率（平均增益达 +85.7个百分点），展现了精准挂载API规范的强大杠杆效应。

AI的绝对算力边界：“零分俱乐部”

论文最有工程参考价值的界限在于，在全部84个评估任务中，有16个任务（占比19%）在挂载了完美人工技能、使用最高阶大模型的情况下，依然维持着0%的全局通关率。这揭示了当前智能体体系无法跨越的三个物理断层：

1. 计算不可行（Computationally intractable）：引力波信号的匹配滤波探测（gravitational-wave-detection）以及量子数值模拟等任务，彻底耗尽了当前的迭代时间预算。
2. 脆弱的多步流水线（Complex multi-step pipelines）：例如异构企业内部信息的交叉检索，流水线链路过长，链条上任何一步的微小幻觉都会阻断后续进展。
3. 极度严苛的规范死穴（Strict specification tasks）：输出格式几乎不存在任何冗余容错空间的自动化脚本调试或特定单元格复原任务。

最后

《SkillsBench》的实证结果向所有构建下一代智能体的工程师传递了不容忽视的信号：

1. 摒弃零样本神话：在专业级工作流中，不要寄希望于大模型能自发组合出完美的底层API调用。模型需要结构化的领域知识指导，而且它无法可靠地自己生成这些指导。
2. 约束输入冗余：将垂域的Agent的Skills库维持在最小可用状态。每个任务挂载的技能模块应当严格限制在2-3个以内。
3. 精简为王：拒绝将其写成详尽的技术文档。使用短小精悍的结构，直接提供具备强约束力的分步指南和一个高信息密度的可执行用例，这比千言万语更具通过率转换价值。

当我们在内存中向智能体注入SOP规范时，本质上是在进行一种低成本、即插即用的微调。在这个没有主观法官的确定性测试场里，数据已经证明：精准的工艺手册，依然是驾驭庞大算力野兽的最佳缰绳。

文章来自于微信公众号 "AI修猫Prompt"，作者 "AI修猫Prompt"