本文翻译自 SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks，原载于 Hacker News。
背景：为什么需要 SkillsBench？
大语言模型（LLM）已经从文本生成器演变为能够执行复杂多步骤任务的自主 Agent。Claude Code、Gemini CLI、Codex CLI 等工具让开发者可以在终端环境中利用前沿模型作为智能助手。
然而，这里存在一个根本性的矛盾：基础模型提供广泛的能力，但缺乏特定领域工作流程所需的程序性知识；而微调虽然可以解决这个问题，却代价昂贵且会牺牲通用性。
Agent Skills 因此应运而生。一个 Skill 是一个结构化的包，包含指令、代码模板、资源和验证逻辑，可以在推理时增强 Agent 的行为，而无需修改模型本身。Skills 生态系统发展迅速，社区仓库已经托管了数千个用户贡献的 Skills，涵盖软件工程、数据分析和企业工作流程等领域。
但是，没有任何基准测试系统地评估 Skills 何时以及如何提升 Agent 性能。这就是 SkillsBench 要解决的问题。
SkillsBench 是什么？
SkillsBench 是首个将 Skills 作为一等评估对象的基准测试，包含两个核心贡献：
1. 以 Skills 为中心的评估框架
- 涵盖 11 个领域的 84 个任务
- 每个任务在三种条件下执行：无 Skills、有精心策划的 Skills、有自生成 Skills
- 使用确定性验证器和完整的轨迹日志
- 按难度分层任务并进行泄露审计
2. 大规模实证评估
- 评估 7 种 Agent-Model 配置
- 超过 7,308 条执行轨迹
- 产生关于 Skills 效力、方差和失败模式的第一个系统性证据
Agent Skills 的定义
一个 Skill 必须满足四个标准：
- 程序性内容：包含操作指南（流程、工作流、SOP），而非事实检索
- 任务类别适用性：适用于一类问题，而非单个实例
- 结构化组件：包含 SKILL.md 文件加上可选资源（脚本、模板、示例）
- 可移植性：仅基于文件系统，易于编辑、版本控制、共享和跨不同 Agent 使用
这个定义明确排除了：系统提示词（缺乏结构和资源）、少样本示例（声明性而非程序性）、RAG 检索（事实性而非程序性）、工具文档（描述能力而非流程）。
主要发现
发现 1：Skills 提供显著但可变的收益
精心策划的 Skills 在 7 种模型-配置组合中平均提升 +16.2 个百分点，但方差很大（范围：+13.6pp 到 +23.3pp）。这种可变性表明 Skills 效果强烈依赖于特定的 Agent-Model 组合。
发现 2：不同 Harness 表现差异
- Claude Code：Skills 利用率最高；改进范围从 +13.9pp（Opus 4.6）到 +23.3pp（Opus 4.5）
- Gemini CLI：原始性能最高（Gemini 3 Flash 达到 48.7%）；改进范围 +13.6pp 到 +17.4pp
- Codex CLI：竞争力强的原始性能（44.7%），但经常忽略提供的 Skills
发现 3：自生成 Skills 几乎无效
当被提示在解决任务之前生成自己的程序性知识时，模型相比无 Skills 基线平均 下降 1.3pp。只有 Opus 4.6 显示出适度改进（+1.4pp）；Codex + GPT-5.2 大幅下降（-5.6pp）。
这与精心策划的 Skills（+16.2pp）形成鲜明对比，表明有效的 Skills 需要人类策划的领域专业知识，模型无法可靠地自我生成。
发现 4：领域间收益差异巨大
| 领域 | 有 Skills | 无 Skills | Δ |
|---|---|---|---|
| 医疗健康 | 86.1% | 34.2% | +51.9pp |
| 制造业 | 42.9% | 1.0% | +41.9pp |
| 网络安全 | 44.0% | 20.8% | +23.2pp |
| 自然科学 | 44.9% | 23.1% | +21.9pp |
| 软件工程 | 38.9% | 34.4% | +4.5pp |
| 数学 | 47.3% | 41.3% | +6.0pp |
需要模型预训练中代表性不足的专业程序性知识的领域（如临床数据协调、制造工作流程）显示出最大的改进，而预训练覆盖强的领域从外部程序性指导中获益较少。
发现 5：2-3 个 Skills 最优
| Skills 数量 | 有 Skills | 无 Skills | Δ |
|---|---|---|---|
| 1 个 Skill | 42.2% | 24.4% | +17.8pp |
| 2-3 个 Skills | 42.0% | 23.4% | +18.6pp |
| 4+ 个 Skills | 32.7% | 26.9% | +5.9pp |
这种非单调关系表明，过多的 Skills 内容会造成认知负担或冲突的指导。
发现 6：适度长度的 Skills 优于全面的文档
| 复杂度 | 通过率 | Δ |
|---|---|---|
| 详细型 | 42.7% | +18.8pp |
| 紧凑型 | 37.6% | +17.1pp |
| 标准型 | 37.1% | +10.1pp |
| 全面型 | 39.9% | -2.9pp |
专注的程序性指导比详尽的文档更有效——Agent 可能难以从冗长的 Skills 内容中提取相关信息。
发现 7：小模型 + Skills 可以超越无 Skills 的大模型
Claude Haiku 4.5 配合 Skills（27.7%）超过 Haiku 无 Skills（11.0%）+16.7pp。同时，Claude Opus 4.5 无 Skills 只达到 22.0%。这表明 Skills 可以部分补偿模型容量在程序性任务上的限制。
对实践者的启示
Skills 作者
- 简洁、分步骤的指导配合至少一个可工作示例往往比详尽文档更有效
- 过长的 Skills 定义会增加上下文负担而不改善决策
- 模块化 Skills 在多部分任务上组合效果更好
- Skills 应明确匹配 Harness 约束
Skills 使用者
- Skills 效果并非通用，而是依赖于上下文
- 需要评估特定 Agent-Model 组合下的 Skills 效果
- 不要假设模型可以自我生成有效的程序性知识
局限性与未来工作
-
覆盖和泛化：SkillsBench 专注于基于终端的容器化任务，结果可能不能直接转移到 GUI Agent 或非常长期的工作流程
-
因果归因：Skills 注入增加了上下文长度，因此观察到的收益可能部分反映”更多上下文”而非程序性结构
-
确定性：容器化提供状态隔离但不能保证完美的确定性或免疫训练集泄露
总结
SkillsBench 的研究确立了四个关键发现：
- 精心策划的 Skills 提供显著但可变的收益（平均 +16.2pp，在领域和配置间有高方差）
- 自生成 Skills 几乎无效（平均 -1.3pp），有效的 Skills 需要人类策划的领域专业知识
- 少即是多——2-3 个模块的专注 Skills 优于全面文档
- Skills 可以部分替代模型规模，使较小的模型在程序性任务上匹敌较大的模型
这些结果表明 Skills 效果不是通用的而是依赖于上下文的，因此配对评估应该成为 Agent 增强研究的标准实践。
核心要点：如果你正在为 LLM Agent 开发或使用 Skills，记住：质量 > 数量。一个精心设计、专注的 Skill 比冗长的文档更有效；而指望模型自己生成有效的程序性知识是不可靠的。