为什么我不会在 SkillsBench 上采取行动
Source: Dev.to
请提供您希望翻译的正文内容，我将为您翻译成简体中文并保留原始的格式、Markdown 语法以及技术术语。谢谢！
概览
我在观看 Theo 时偶然发现了 SkillsBench（论文，2026 年 2 月），感到非常兴奋。它提出了两个关键问题：
- 精心策划的过程文档（“Skills”）真的能帮助编码代理吗？
- 哪个编码代理能够最好地利用它们？
标题数字——来自精心策划的 Skills 的 +16.2 pp——让人立刻觉得可以付诸行动。
初步印象
然后我开始审视方法论，事情逐渐展开。
- Scope – 84 个任务，11 个领域，7 个编码代理，7,308 条轨迹。
- Conditions – 每个任务在三种设置下进行评估：
- No Skills
- Curated (expert‑written) Skills
- Self‑generated Skills
- Skill package – 每个任务都附带一个固定的 Skill package（markdown 指令，有时包含脚本或模板），并与任务一起提供给代理。
排行榜发现
在每个基准测试中，核心结果是排行榜。
发现 2 (§4.1.1) – 最佳原始性能
| 代理 | 模型 | 通过率 |
|---|---|---|
| Gemini CLI + Flash | – | 48.7 % |
| Claude Code + Opus 4.5 | – | – |
| Uplift | – | +23.3 pp (largest) |
这是一个合法的结果——尽管 Flash 超过 Opus 4.5/4.6 有点令人惊讶。
排行榜实际衡量的内容
排行榜显示 哪个代理表现最佳，但它 并未 告诉我们 Skills 机制 是否产生了影响，亦或是将内容直接放入提示中是否也能得到相同的结果。
缺失的实验
在提示中直接注入相同的 Skill 内容（基线） vs. 让 harness 通过其原生发现机制加载 Skills。
该实验在论文中缺失，然而它正是能够为名为 “SkillsBench.” 的基准提供依据的实验。
面向设计的发现
论文中的两个面向设计的发现听起来很实用：
- 技能数量 – 2–3 个技能是最佳的（+18.6 pp）；4 个以上的技能出现递减收益（+5.9 pp）。（Finding 5, §4.2.1）
- 技能长度 – 中等长度的技能优于全面的技能——详细的（+18.8 pp）和紧凑的（+17.1 pp）均优于全面的（–2.9 pp）。（Finding 6, §4.2.2）
为什么这些发现有问题
- 每个任务都附带一个 固定的技能包，因此“技能数量”和“技能复杂度”是 任务的属性，而不是独立变量。
- 因此，实验无法将 技能数量 的影响与 所解决任务 的影响分离。
- 论文事后按技能数量进行分层，并使用因果语言（“最佳”、“递减收益”），但其设计 不支持 这种推断。
同样的问题也适用于复杂度：显示 –2.9 pp 的 N = 140 “全面” 桶可能仅仅包含更难的任务。若不控制任务难度——或者更好地，在同一任务内部 变动技能数量/复杂度——这些仅是相关性观察，却被包装成设计指南。
领域细分（表 4）
| 领域 | Δ 通过率 |
|---|---|
| 医疗保健 | +51.9 pp |
| 制造业 | +41.9 pp |
| 软件工程 | +4.5 pp |
这些数字支撑了论文的论点：在模型预训练中“知识代表性不足”的领域最能从 Skills 中受益（发现 4，§4.1.3）。
领域分析中的问题
- 医疗保健 – 仅 2 个任务。
- 制造业 – 仅 3 个任务。
单个异常任务——以及若干单独任务波动 70–85 pp——就可能主导整个领域的整体结果。样本量如此之小，实际上并不是在测量领域效应，而是在测量少数任务。论文在领域层面报告这些数值时 未给出置信区间，也未标注样本量的限制。
相比之下，软件工程（N = 16）提供了一个更为可靠的估计，尽管其提升幅度远不如前者引人注目。
重新框定发现为提示结果
由于 Skills 是惰性加载的提示片段，请在剩余的发现中将 “Skills” 替换为 “prompt”。
| 原始发现 | 重新框定为提示 |
|---|---|
| 发现 1 (§4.1.1) – 精心策划的 Skills 提升性能 | 精心策划、专家编写的提示提升性能。 |
| 发现 7 (§4.2.3) – 较小模型 + Skills 可超越未使用 Skills 的更大模型 | 较小的模型配合优秀的提示可以超越使用平庸提示的更大模型。 |
| 发现 3 (§4.1.1) – 自生成的 Skills 没有任何收益 | 当模型自行提供上下文时，性能并未提升。 |
这些重新框定并不令人惊讶；提示相关文献已经确立了这两点。
自生成技能
Finding 3 – 自生成的 Skills 没有任何收益 – 之所以稍微有趣，是因为元提示（使用模型生成自己的提示）在某些情况下确实有效。
一个合理的解释：
- 对于模型缺乏领域知识的任务，它无法编写有效的 Skills，因为它缺乏相应的知识。
- 对于模型已经具备领域知识的任务，Skills 的边际贡献很小。
无论哪种情况，当模型自行编写 Skills 时，性能都没有提升，这相当于“当模型提供自己的上下文时，性能没有提升”——这并不令人惊讶。
缺失内容与建议实验
论文提出了正确的问题，但尚未进行相应的实验来回答它们。下面是所需调查的汇总列表。
1. 隔离机制
- 目标： 确定 Skills 机制 是否重要，而不仅仅是 Skills 内容 是否有帮助。
- 实验： 使用相同的 Skill 内容，直接注入到提示中（基线）与让 harness 通过其原生发现机制加载进行比较。
- 若原生加载表现更好 → Skills 架构在发挥实际作用。
- 若结果相当 → Skills 仅是提示内容的包装格式。
2. 隔离内容
- 目标： 测试 过程结构 是否特别驱动了提升。
- 实验： 注入相同 token 数量的主题相关 非过程文本（例如 API 文档、参考材料），并比较性能。
3. 在任务中变更 Skills
- 目标： 将 Skill 数量/复杂度 与 任务难度 解耦。
- 设计： 对同一任务，创建多个仅在数量或长度上不同的 Skill 包，保持底层任务不变。
4. 域级鲁棒性
- 目标： 获得可靠的域级估计。
- 设计： 增加每个域的任务数量（尤其是 Healthcare 和 Manufacturing 等低样本域），并报告 置信区间。
5. 基线提示质量
- 目标： 确保任何观察到的提升并非仅仅因为 更好的提示。
- 设计： 将精心策划的 Skills 与 等长且等 token 预算的专家手工提示 进行比较。
Take‑away
- SkillsBench 对于为编码代理提供策划的过程文档的实用性提出了重要问题。
- 目前的方法将 content 与 mechanism 混为一谈，并且把 correlational 观察与 causal 语言混在一起。
- 需要严格的、受控的实验——尤其是直接将 Skills loading mechanism 与 plain‑prompt baseline 进行比较的实验——才能声称 “Skills” 作为一个独特的基准组件提供了独特价值。
基于技能的代理设计建议
1. 将技能设计发现与任务身份分离
- 进行受控实验：
- 多次执行相同任务，每次改变可用的技能数量。
- 测量每种变化的性能差异。
- 改变技能复杂度：
- 为相同任务提供紧凑的技能集合与完整的技能集合。
- 观察复杂度如何影响结果。
- 目标： 将相关性观察转化为具体的设计指导。
2. 使用固定的技能库进行测试
- 当前设置的局限性： 每个任务都收到手工挑选的技能包，保证完美匹配。
- 提出的实验：
- 创建一个静态库，包含约20–30个技能，在所有任务中保持不变。
- 让代理自行发现并应用合适的技能。
- 重要性：
- 这评估的是技能选择（更困难、更真实的问题），而不仅仅是技能使用。
3. 实际建议
- 不要直接依据论文的发现采取行动。
- 如果你今天正在为代理投资技能，请根据你自己的反复试验来校准该投资，而不是依赖研究的结论。