Skill 到底为什么有效，又在哪失效
论文信息
- 论文：《Demystifying Agent Skills: Why They Work—Until They Don't》
- 机构：Princeton / UCSD / Stanford / USC / Johns Hopkins
- 版本：arXiv:2608.14036v1，2026 年 8 月预印本
- 阅读时长：约 20 分钟
- 前置知识：SKILL.md / workflow memory 概念、Agent 主循环、RAG / 记忆检索
一、为什么 skill 的评判要不止看成功率
逐个任务加个 skill、跑一下、看成功率高不高，是评估 skill 价值最常用的方式。这个做法存在一个通行已久的痛点：它只能回答"有没有用"，说不清它在哪一步有效、什么时候反而有害。
同一个 skill 能成全一个任务，却可能在另一个任务上适得其反。缺了机制层面的理解，"怎么写好 skill"就只能靠玄学式反复调参，这正是 skill 概念长期被视为黑盒的根源。
论文借此换了个问法：与其问 "whether a skill works"，不如问 "when / why / where a skill works"。前者是给 skill 打分，后者是给 skill 建生命周期，答案落在"什么条件下有效"。
这也正和本站源码专栏互补：源码能讲清 skill 怎么挂载、怎么注入、怎么检索，"该不该写这一层、什么情况下才管用"则由这篇论文来答。
二、论文怎么证明
要回答"skill 为什么有效"，首要问题是把"skill 改变了 agent"变成可观测的证据。论文的做法分几步：拆管线、成对轨迹分析、四组受控实验加人工验证。
skill 的使用被拆成一条生命周期管线：表示 representation → 检索 retrieval → 调用 invocation → 跨框架迁移 transfer，每个环节单独隔离验证。
| RQ | 问什么 | 怎么隔离 |
|---|---|---|
| RQ1 | 同一轨迹，塞 workflow memory 还是蒸馏成 skill 有没有差别 | 只改表示形式 |
| RQ2 | 成败标注显式与否，作用多大 | 拿掉标注（no-hint） |
| RQ3 | 跨框架迁移：Codex 生成、跑在 Gemini CLI | 换执行框架 |
| RQ4 | 检索难度：pool size 5→100、distractor 随机/相似/不相似 | 控制候选池 |
数据侧，论文把 8135 条 trial 记录归一化，对 240 条采样轨迹做开编码，得到 238 条有效标签，归成 3 大类（SC1 成功 / SC2 执行层失败 / SC3 调用边界失败）、12 种模式。
人工验证相当扎实：238 个标签各配 3 条轨迹，共 714 次检查；聚合映射与 LLM 一致性 95.8%、Cohen's κ=0.952，分类并非单模型自说自话。
实验用两套 agent–model 配对：Codex + GPT-5.3-Codex、Gemini CLI + Gemini-3.1-Pro-Preview；RQ4 因模型可用性改用 Codex + GPT-5.4，只能做同配对内部比较。
benchmark 包括 Terminal-Bench 2.0（89 任务）、Terminal-Bench Pro（200/8 域）、SkillsBench（86 任务/11 域，带原生 task–skill 标注）。skill 放置遵循 Anthropic 规范，放执行环境作可复用资源，而非内联初始上下文。
三、核心发现
3.1 过程锚 vs 知识注入
skill 整体成功率为 61.9%，基线 raw 59.1%、workflow memory 55.9%（后者反而略低于 raw）。skill 相对 workflow 高 6.06pp（bootstrap 95% CI [+0.76, +11.36]）。
因为 workflow 与 skill 出自同一份源轨迹，这差距只能归因于"表示形式"，而非"给了更多经验"——这是全文最有解释力的一组对比。
机制标签直接揭了底牌：procedural_anchor（过程锚）占 65.7%，而 knowledge_injection（知识注入）仅 4.5%。结论明确：skill 主要在稳定动作，而非注入知识。
它稳定的是"跑哪些 setup、走哪条工具序列、做什么中间验证、避开哪个坑"，把"其实会做的流程"回构成不跑偏的标准动作。综上，skill 降低的是流程的过程不确定性，不是知识的稀缺性。
3.2 它修执行层失败，不修算法与推理
把 12 种 mode 归到三类后，"skill 修什么、不修什么"排得很清楚。最显著的是 SC2 执行层失败：raw 37.3% → skill 23.5%。
| 失败模式 | Raw | Workflow | Skill |
|---|---|---|---|
| 环境基础设施失败 | 5.3% | 1.7% | 0.2% |
| 输出格式 / schema 不符 | 7.4% | 3.8% | 3.2% |
| 后台服务生命周期失败 | 2.7% | 2.5% | 0.8% |
| Shell 命令交付 | 1.1% | 1.9% | 0.2% |
这些都是"更可被编码"的失败：setup 顺序、依赖 workaround、路径约定，一经发现就能固定进 skill，收益立竿见影。
边界同样清楚：算法逻辑错误从 raw 8.3% 到 skill 7.4%，静态验证不使用运行时则从 12.5% → 12.5% → 11.7%。skill 不自动帮 agent 重想算法，也不强制对齐 oracle 验证，提升的是执行健壮性，不是问题重构能力。
3.3 skill 也引入新的失败面
抽象既是优势，也会带来新失败：skill_guidance_misapplied_or_ignored 占 10.0%（raw 0.8%、workflow 0.4%），agent 拿着看似合理的 skill 机械套用、错认前提、配上不成立的假设。
workflow 的软肋则是 timeout_budget_exhaustion 10.6%（raw 1.7%），因为原始轨迹留下的探索分支与噪音太多。skill 的一次失败，往往不是内容写错，而是 agent 判断错"此刻该不该由 skill 主事"。
3.4 outcome 标注的作用
no-hint 消融给出反直觉结论：只喂成功样本时，加不加成败标注差别不大；一旦混入失败轨迹就拉开距离。典型例子 Gemini 在 TB2 的 3s2f 任务：normal 0.7462 vs no-hint 0.4000。
工程启示：写 skill 时，失败样本的"可识别性"最可贵，它教 agent"该避什么、踩坑怎么爬出来"；没有失败样本，防御性知识便无从谈起。
3.5 检索是独立瓶颈
RQ4 用同一候选池（真 skill + k−1 个 distractor）跑三套评测，pool 从 5 增到 100：
| 指标 | k=5 → k=100 |
|---|---|
| 实际使用的 precision | 29.6% → 3.3% |
| 下游成功率 | 36.4% → 39.3% |
| Embedding top-1 precision | 88.3% → 76.9% |
| Agent 显式选择 precision | 70.0% → 63.7% |
三个教训都击碎"精确命中等于成功"的直觉：pool 越大实际 use precision 崩到 3.3%，但下游成功率几乎持平；相似 distractor 压力最大（embedding top-1 从 70.5 掉到 53.4），但 k=100 的 recall 仍达 54.3–73.6%；精确 ground-truth 调用既不充分也不必要，相关而非 ground-truth 的 skill 也能提供程序性支撑。
四、对本站读者与 SKILL.md 写法的启发
结合源码专栏，给三条可落地的经验：
4.1 少堆知识，多堆步骤
论文 65.7% 的 label 在稳定动作而非注入知识。最有价值的是可执行步骤、验证清单、常见坑，而不是业务背景解释。想"什么能让流程不易跑偏"，就从那写起。
4.2 多写 avoidance（该避的坑）
no-hint 实验说明，价值最贵的是失败经验里的防御性知识。优先把"曾经踩过的具体坑"写进 skill，它只能从失败里长出来——这也是失败样本显得珍贵的原因。
4.3 检索大库要特别设计
RQ4 提示：库越大、skill 越相近，自动检索越难命中。库大时别只靠 description 检索，配合召回策略、命名收敛、显式规则一起设计，否则真实命中率会让人失望。
五、局限速写
- 只测了终端/工具型任务（Terminal-Bench / SkillsBench），不含 web 或开环协作，别类任务结论要额外验证
- agent–model 只有两套，RQ4 换了 Codex + GPT-5.4，只能做同配对内部比较
- taxonomy 来自约 3% 的抽样轨迹，低频失败模式未必覆盖完全
六、深度理解问答
Q1 为什么"技能检索到"不等于"任务成功"
因为"找到正确 skill"与"把它执行到位"是两步独立能力。RQ4 里最直观的反差：实际 use precision 崩到 3.3%，下游成功率却升到 39.3%。agent 可能在干扰中选中了却在错误 context，也可能选了相关但非 ground-truth 的那份却照样成事。命中是必要前提，但不是充分条件。
Q2 那是不是该把 workflow memory 全砍掉
不该二取一。两者是替换方案，取舍如下：workflow memory token 最省（83 任务交集比 raw 少 129.5K token）；skill 成功率最高（比 raw +5.5pp），但每任务多花约 95.3K token，且更强制的表示。strings 上省 token 的进 workflow，需要稳定动作的写成 skill。
Q3 为什么失败样本那么关键
因为"避免踩坑"的价值主要藏在失败样本里。只喂成功轨迹时，成败标签可有可无；一旦混入失败样本又被拿掉标签，skill 的防御半径就塌掉了。原因在于 skill 里最值钱的防御性内容，只能从失败里长出来。
Q4 与源码专栏如何互补
源码专栏解释 skill "怎么实现"（怎么挂载、怎么注入、怎么检索），本篇论文给定"什么值得被写成 skill"（稳定流程、避开坑、检索抗混淆）。源码讲机制，论文讲价值与边界，两者叠加才能判断一份 SKILL.md 写得好不好。
七、结论
一句打包，但拆成三句：skill 是过程锚，不是知识库——稳定的是动作而非补充知识，6.06pp 来自表示形态而非多次训练；检索是独立瓶颈——命中与成功松耦合，池越大越相似越难，精确 ground-truth 既不充分也不必要；失效来自边界——修执行层而不修算法推理，且会带来误用，关键不在"写没写"而在"何时用、用哪个、怎么适配"。
本篇为论文解读，与本站源码专栏互为补充。数据均取自论文正文与附录 A 各表（表 1/2/3/11/15/16），无杜撰。