SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks

先给结论

研究动机：为什么需要 SkillsBench

LLM agent 已经能在 CLI、代码仓库、数据环境里执行多步任务，但基础模型的泛化知识和具体领域 workflow 之间仍有明显缺口。Fine-tuning 昂贵且不灵活；Skills 则把可编辑、可复用、可版本化的程序性知识放在 inference-time。

这篇论文要回答的不是“额外上下文会不会有帮助”这种近似同义反复，而是更难的问题：

• 在同一任务和同一 harness/model 下，curated Skill 的净收益是多少？
• 哪些领域和任务最依赖 Skill？哪些任务会被 Skill 干扰？
• 模型能不能先自己写 Skill，再用自己写的 Skill 完成任务？
• Skill 的数量和复杂度如何影响最终 pass rate？

这正好补上现有 agent benchmarks 的盲区：SWE-bench、Terminal-Bench、OSWorld 等主要评估固定系统完成任务的能力，而 SkillsBench 评估 runtime augmentation 的边际效果。

概念边界：Skill 不等于 Prompt、RAG 或 Tool

论文给 Skill 的操作性定义很重要，因为后面所有实验都依赖这个边界。一个 Skill 至少要满足四点：

和几种相邻概念的差别

我的读法：Skill optimization 确实很像 prompt optimization，但 Skill 的状态面更多：触发描述、程序正文、资源文件、示例、脚本、文件布局、harness 调用机制、跨任务适用范围。这些都是可 drift 的对象。

算法流程/方法：SkillsBench 如何构造

SkillsBench 建在 Harbor / Terminal-Bench 风格的 containerized evaluation 上。每个任务不是一段静态问答，而是一个可执行模块：

任务与生态规模

从候选到最终评估

• 105 contributors 提交 322 candidate tasks。
• 论文最终列出 86 个任务，其中 84 个进入主实验。
• 任务按人类完成时间分为 Core 17、Extended 43、Extreme 26。
• Skill 生态分析中，去重后得到 47,150 unique Skills。

实验设计：三种 Skills 条件

论文评估三个 commercial agent harness：Claude Code、Codex CLI、Gemini CLI；七个论文报告的模型配置；所有模型 temperature 设为 0。每条 trajectory 是 agent 在某个任务、某个条件下的一次完整尝试，直到完成、失败或超时。

指标

主指标是 pass rate。论文还报告 normalized gain，用来衡量从 baseline 到完美表现之间填补了多少比例：

注意：normalized gain 有天花板效应。一个 baseline 已经很高的系统，绝对提升小也可能有较大 g；所以这篇论文同时报告 absolute delta 和 normalized gain。

实验结果：curated Skills 有用，但不是单调魔法

主结果表

最强的结论不是某个模型赢了，而是 curated Skills 在所有 7 个配置上都提高了 pass rate；同时 self-generated Skills 平均没帮助，且在 Codex + GPT-5.2 上显著变差。换句话说，模型可以消费好的程序性知识，但不稳定地生产好的程序性知识。

领域差异很大

任务级别：最大增益和负增益同时存在

Skill 数量和复杂度：少而准更好

这两个表对 skill 优化非常关键：优化目标不是“堆更多知识”，而是让知识更可定位、更程序化、更短路径、更少冲突。

成本与失败模式：Skills 改善的主要是质量失败

成本结论要谨慎读

• Codex/Gemini 的 Skills 条件输入 token 增加约 6-13%。
• GPT-5.2 单次成本从 USD 1.85 到 USD 2.07，+12%。
• Gemini 3 Flash 从 USD 0.54 到 USD 0.57，+6%。
• Gemini 3 Pro 反而从 USD 1.13 到 USD 1.06，-6%，论文解释为 Skills 减少探索轮数。

失败分类

最有价值的分析是：With Skills 把整体 failure rate 从 78.4% 降到 61.1%；Quality Below Threshold 的绝对数量从 1184 降到 819，下降 30.8%。这说明 Skills 不只是让 agent 产生文件，而是让已经进入解题轨道的 agent 更接近 verifier-facing 的正确输出。

我的评论：它是 Skill Optimization 的地基，不是终点

和 SkillOpt / SkillEvolver 的关系

SkillOpt 这类工作通常问：能否自动改写、合成或选择 Skill，让任务表现更好？SkillsBench 提供的是评价底座：有 paired task，有 curated baseline，有 deterministic verifier，也有负例。真正难点会变成：

• optimizer 是否只是过拟合当前 verifier？
• 新 Skill 是否牺牲旧任务表现换取单任务收益？
• Skill 变长之后是否提升了可执行性，还是只增加上下文噪声？
• 同一个 Skill update 在 Claude Code、Codex CLI、Gemini CLI 上是否仍然有效？

对 Drift Monitor 的启发

如果 agent skills 是持久化的程序性记忆，那么每次 Skill update 都是在修改 future-self。SkillsBench 给出的信号是：Skill 能显著提升表现，但也能伤害任务；self-generated Skill 平均失败；过多或过长 Skill 有负担。因此 self-evolving agent 不能只有 optimizer，还需要 admission gate。

SkillsBench asks: do skills help?
SkillOpt asks: can we improve skills?
Drift Monitor asks: should this skill update be admitted into persistent agent state?

Drift Monitor 应该盯什么

Reference / Evidence