给智能体写的 Skill 到底哪里在起作用？8135 条执行记录解剖出一个反直觉答案
你有没有这种感觉：给智能体挂上一堆精心整理的 Skill 文档，成功率确实涨了，但你说不清到底涨在哪。是 Skill 里那条命令救了场，还是模型本来就会做？更糟的是，有时候同一个 Skill 在这个任务上是神助攻，换个任务反而把智能体带沟里了。
上周刷到一篇普林斯顿、斯坦福、UCSD、USC、JHU 五校联合的论文，干的事情特别对我胃口：他们没有再去刷一个"挂 Skill 涨 X 个点"的新榜单，而是把 Skill 从生成、检索到执行的整条链路拆开，用 8135 条受控实验记录加 240 条人工开放编码的轨迹，回答一个更根本的问题——Skill 什么时候有用、为什么有用、在哪里翻车。
核心摘要：这篇论文发现，Skill 起作用的主因不是"注入知识"，而是"程序化锚定"（procedural anchoring）——把 noisy 的历史轨迹蒸馏成稳定的操作步骤，65.7% 的有效案例属于这类，而真正的知识注入只占 4.5%。同样的经验，蒸馏成 SKILL.md 比直接塞 Workflow Memory 高 6.06 个点。但 Skill 也不是银弹：检索池从 5 扩到 100，实际调用精度从 29.6% 崩到 3.3%，而任务成功率居然基本不动——说明"选对 Skill"和"做成任务"根本是两码事。这篇论文不提供新方法，它提供的是一副解剖刀，对任何在搞技能库、记忆系统的人来说都值得细读。
📄 论文信息 - 标题：Demystifying Agent Skills: Why They Work—Until They Don't - 链接：https://arxiv.org/abs/2608.14036 （arXiv:2608.14036，2026 年 8 月 14 日提交） - 作者：Zhiyuan Jiang、Fangrui Huang（共同一作）、Hanwen Xing、Xander Wu、Yipeng Gao、Rui Cao、Mengdi Wang、Shilong Liu、Yijiang Li - 机构：Princeton University、UC San Diego、Stanford University、University of Southern California、Johns Hopkins University
🎯 为什么这个问题值得一篇论文
先交代一下背景。2025 年 10 月 Anthropic 推出 Agent Skills 之后，"给智能体写 SKILL.md"几乎成了工程标配：一个带 frontmatter 的 Markdown 文件，配上脚本和资源，按需加载。思路确实漂亮——不把所有经验糊进上下文，而是渐进式披露，用到才加载。
但紧接着大家都在闷头写 Skill、攒 Skill 库，一个问题被绕过去了：我们评估 Skill 的方式，基本就是"挂了 Skill 成功率涨没涨"。这种聚合指标掩盖了太多东西。我之前在调内部技能库的时候就碰到过：某个 Skill 挂了之后成功率涨了 3 个点，但你翻轨迹会发现有一半的case里智能体根本没读那个文件，还有几个case是它读了但被带偏了方向。涨分和"Skill 在起作用"，中间隔着一条鸿沟。
论文把这个问题拆成四个研究问题，我用自己的话转述一下：
| 研究问题 | 大白话版本 |
|---|---|
| RQ1：程序性表征如何影响经验复用？ | 同样的历史轨迹，做成 Skill 和直接塞原始 Workflow 有区别吗？ |
| RQ2：成功/失败标注起什么作用？ | Skill 有用是因为内容本身，还是因为告诉了你哪条轨迹成功了？ |
| RQ3：蒸馏后的经验能跨框架迁移吗？ | 从 Codex 轨迹里提炼的 Skill，给 Gemini CLI 用还灵吗？ |
| RQ4：技能池变大变像之后，检索会怎样？ | 池子里 5 个 Skill 和 100 个 Skill、干扰项长得很像的时候，找得对还用得好吗？ |
🏗️ 实验怎么搭的：两条流水线
说实话，这篇论文的实验设计比结论本身更值钱。它搭了两条受控流水线。
第一条是 Skill 对 Workflow Memory 的对照流水线：每个任务在固定 Docker 环境里跑出成功和失败的原始轨迹，然后按固定预算做组合网格——5 成功 0 失败（5s0f）到 0 成功 5 失败（0s5f）共六种配比。同一批轨迹，一份蒸馏成 Workflow Memory（保留轨迹级细节），一份蒸馏成标准化 SKILL.md，然后在同一协议下评测。这就把"经验本身"和"经验的表征形式"干净地解耦了。
图 1（上）：从原始执行收集成功/失败轨迹，按六种配比组合后分别蒸馏成 Workflow Memory 和 SKILL.md，在同一评测协议下对照。注意右侧的 skill-creator.md——Skill 的生成本身也是一个受控过程。
第二条是 技能检索的三臂评估：每个任务配一个候选池，里面是 1 个真命 Skill 加 k−1 个真实干扰项（随机、相似、不相似三种采样），k 从 5 到 100。三个独立实验：Arm 1 用 Qwen3-Embedding-0.6B 做 embedding 排序（不执行任务）；Arm 2 让智能体显式挑选 Skill（不进 Docker、不做验证）；Arm 3 把整个池子丢给智能体真实执行，事后解析它实际用了哪些 Skill。关键设计是三个臂互不传结果——它们是独立测量，不是流水线的三个阶段。
图 1（下）：检索评估的三个独立臂。这个"互不传结果"的设计很讲究——它允许作者分别测量"离线识别能力"和"执行时使用行为"，然后发现这俩根本对不上。
评测基准用的是 Terminal-Bench 2.0、SkillsBench 和 Terminal-Bench-Pro，智能体配对是 Codex + GPT-5.3-Codex 和 Gemini CLI + Gemini-3.1-Pro-Preview（RQ4 因为模型可用性问题换成了 Codex + GPT-5.4，作者也很坦诚地说明 RQ4 只能做组内比较，不能和 RQ1–RQ3 的绝对值直接对比）。
🧠 核心方法：一个 12 模式的分类法
这篇论文的分析单元设计得挺巧妙：配对三元组（paired triple）。同一个任务、同一设定下，比较 raw 执行、Workflow Memory 注入、Skill 注入三个臂。一共构造了 528 个三元组（SkillsBench 144、Terminal-Bench 2.0 186、Terminal-Bench-Pro 198），得到 1584 个臂级标注。LLM judge 对每个臂标注模式，并记录臂与臂之间的行为变化。
标注体系从 240 条采样轨迹的开放编码开始，238 个有效标签归并成 3 个大类、12 个模式。为了防止"LLM 自己造分类法自娱自乐"，作者做了人工校验：238 个标签每个抽 3 条支撑轨迹，共 714 次检查，全部确认有据；再让人独立把 238 个标签映射到 12 个模式，与 LLM 归并结果的一致率是 95.8%，Cohen's κ 达到 0.952。这个校验流程本身就很扎实。
三大类是这么分的：
- SC1 引导成功：智能体自主成功，或者先验经验提供了有效引导
- SC2 执行层与验证失败：环境搭建、输出格式、服务管理、shell 执行、算法实现、运行时验证这些"动手"环节翻车
- SC3 调用、适用性与边界失败：引导存在但被误用、过度套用、忽略，或者撞上外部限制
图 2：三个臂在六种轨迹配比下的标签分布堆叠图。一眼就能看到：Skill 臂（右）的绿色 SC1 区域明显比另外两个臂大，但同时也多出了橙红色的 SC3 块——这是 Skill 独有的失败面。而 Workflow Memory（中）的深红色 timeout/budget 块在 Skill 臂上明显缩小了。这张图基本把论文的核心故事讲完了。
📊 发现一：Skill 是程序锚，不是知识包
主结果先摆出来：Skill 臂的 oracle 成功率 61.9%，raw 59.1%，Workflow Memory 55.9%。最值得咀嚼的对比不是 Skill 对 raw，而是 Skill 对 Workflow Memory——两者来自同一批轨迹，唯一差别是表征形式，结果 Skill 高 6.06 个点，95% bootstrap 置信区间 [+0.76, +11.36]。
6.06 个点。这个数的含义是：同样一坨经验，压缩成标准化程序文档比原样塞进去更能打。提升不来自"给了更多经验"，而来自"经验的包装方式"。
机制标签进一步确认了这一点：
| 机制 | 占比 | 含义 |
|---|---|---|
| procedural_anchor | 65.7% | 提供可用的步骤、顺序、检查清单、工具链 |
| knowledge_injection | 4.5% | 补充智能体本来不知道的事实性知识 |
| failure_warning | 其余部分 | 提示要避开的坑 |
| none / counterproductive | 其余部分 | 没用上 / 反而带偏 |
看到这个 65.7% 对 4.5% 的时候我愣了一下，然后想了想又觉得完全合理。智能体翻车的典型姿势从来不是"不知道某个事实"，而是"重复踩同一个程序性的坑"——环境没装好、依赖漏了、输出格式跑偏、后台服务没起对。Skill 的价值在于把这些"上次已经趟出来的操作纪律"固化下来。这跟人机工程里的检查清单（checklist）思路一脉相承：不是教飞行员新知识，是确保他每次都按同样的顺序做同样的事。
还有个佐证：在 skill 臂里 skill_guided_success 占 61.6%，workflow 臂里 workflow_guided_success 占 54.5%——Workflow Memory 也有用，原始轨迹里的命令、参数、调试证据都是宝贝，但它裹着太多无关探索、失败分支和过程噪声。作为额外检查，作者在 26 个 Terminal-Bench-2 任务上测了两个轻量 baseline：从指令直接生成的简短计划只有 47.7%，从 workflow 提取的 test-first 模板 59.2%，都明显低于 Skill 注入的 79.2%。说明不是随便给个程序性提示就能达到 Skill 的效果，蒸馏质量本身是重要的。
🔧 发现二：执行层毛病能治，算法层毛病治不了
Skill 最亮眼的疗效在 SC2 执行层失败上：raw 臂 37.3%、workflow 臂 33.3%，Skill 臂直接压到 23.5%。
几个具体的失败模式特别有说服力：
- 环境基础设施失败：raw 5.3% → workflow 1.7% → Skill 0.2%。几乎清零。环境问题是"最可被 Skill 化"的——一旦趟出可靠的安装序列、依赖绕法、路径约定，写成文档就能反复复用。
- 输出格式/schema 不匹配：7.4% → 3.2%。
- 后台服务生命周期失败：2.7% → 0.8%。
但分类法也画出了边界。algorithmic_logic_error 在三个臂上是 8.3%、11.0%、7.4%——基本纹丝不动。static_verification_without_runtime 也是，12.5%、12.5%、11.7%。Skill 不会自动修好一个错误的算法，也逼不出与 oracle 对齐的运行时验证。它需要"动手纪律"的地方管用，需要"重新想问题"的地方就鞭长莫及了。
这个分界对工程实践的指导很直接：写 Skill 就写环境、流程、格式、命令模式这类东西，别指望 Skill 文档能教会模型怎么设计算法。
⚠️ 发现三：Skill 引入了新的失败面
事情当然没这么美好。让 Skill 有用的那个抽象层，同时也制造了新的翻车姿势。
skill_guidance_misapplied_or_ignored 这个模式在 Skill 臂占 10.0%，raw 臂只有 0.8%、workflow 臂 0.4%。这些失败不是"Skill 不存在或不相关"——往往 Skill 内容看着挺合理，但智能体机械照搬、漏看前提条件、把不再成立的假设带进了新任务。
Workflow Memory 的病是另一种：过程过载。timeout_budget_exhaustion 在 workflow 臂占 10.6%，raw 只有 1.7%，Skill 4.4%。原始轨迹里那些长长的探索、失败尝试、底层调试路径，会拖着智能体在无关细节上耗尽预算。
我的总结是：Workflow Memory 死于"信息太多"，Skill 死于"判断不够"。一次 Skill 运行失败，不一定是 Skill 写得烂，也可能是智能体没判断对"这个 Skill 该不该管这件事"。
🧪 发现四：成功/失败标注是 Skill 蒸馏的关键信号
RQ2 的 no-hint 实验做得很有意思：同样的轨迹池，一组让 Skill 创建者看到每条轨迹的成功/失败标注，另一组把标注抹掉。
图 5：normal（蓝）对 no-hint（橙）在 TB2、SB、TB-Pro 三个基准、两个智能体配对上的对比。注意看：当轨迹池全是成功轨迹（5s0f）时两者几乎没差；但失败轨迹一旦进池，差距急剧拉开。
结果相当干净：池子里只有成功轨迹时，有没有标注几乎无所谓；但失败轨迹混进来之后，标注的价值暴涨。Gemini 在 Terminal-Bench-2 的 3s2f 配比下，normal 是 0.7462，no-hint 直接掉到 0.4000——差了快一倍。
你想想看这是为什么：没有标注，蒸馏器分不清一条失败轨迹里的操作哪些是导致失败的、哪些是无关的，很容易把"踩坑实录"当成"操作指南"写进 Skill。失败轨迹是金矿（坑都标在那），但前提是有人告诉你"这条是失败轨迹"。这对自动化 Skill 生成流水线是个非常实用的警告：丢弃结果标注等于主动致盲蒸馏器。
🌉 发现五：跨框架迁移比预想的好
RQ3 是我最担心会翻车的部分——直觉上，从 Codex 轨迹里提炼的经验，应该带着浓浓的 Codex 提示风格和工具接口烙印，搬到 Gemini CLI 里大概率水土不服。
图 4：在 Codex 侧构建的 Skill 和 Workflow Memory，搬到 Gemini CLI + Gemini-3.1-Pro-Preview 上评测。虚线是目标框架的 Raw 基线 56%。
结果有点打我的脸。Skill 在所有六种轨迹配比下都显著超过 56% 的 Raw 基线，从 62% 到 84%，相对基线提升 +16 到 +30 个点；而 Workflow Memory 基本贴着基线晃悠（54%–70%），好几组甚至低于基线。
这说明蒸馏这个动作本身在"去框架化"：把轨迹里的执行细节抽象成程序性步骤之后，那些 Codex 特有的噪声被洗掉了，留下的是更普适的操作知识。对想建"一处生产、多处消费"技能库的团队来说，这是最振奋的一张图。
🔍 发现六：检索是个独立的瓶颈，而且"选对"和"做成"是两码事
RQ4 是全文信息密度最高的部分。先把三个臂的精度曲线放一起看：
图 3（左）：Arm 1 embedding 排序（蓝）从 88.3% 缓降到 76.9%，Arm 2 智能体显式选择（橙）从 70.0% 降到 63.7%，而 Arm 3 真实执行中的实际使用精度（绿）从 29.6% 崩到 3.3%。三条线根本不在一个量级上。
离线诊断看着还行——embedding top-1 在池子 100 时还有 76.9%，智能体显式选择也守住 63.7%。但真实执行里，智能体实际调用的 Skill 与真命 Skill 的重合度惨不忍睹：池子 5 的时候 29.6%，池子 100 的时候只剩 3.3%。
真正反直觉的在右图：
图 3（右）：实线是实际使用精度，虚线是任务成功率。Gemini 的精度从 16.9% 跌到 0.7%，成功率却在 36–39% 躺平；Codex 精度从 42.3% 跌到 5.9%，成功率反而从 35.4% 涨到 42.0%。精度在崩盘，成功率在涨——这俩指标彻底脱钩。
说实话看到 Codex 那条"精度跌、成功率涨"的曲线时我第一反应是数据画错了。但作者的解释站得住脚：k=100 时 Arm 3 的召回率仍然有 54.3–73.6%，智能体不是没看 Skill，而是看了一堆候选但不把真命 Skill 当唯一依据；而且语义相近的非真命 Skill 也能提供部分程序性支持。结论是：精确调用真命 Skill 对任务成功既不充分也不必要。
干扰项类型的分解也很有意思。Arm 1 在相似干扰池上 top-1 精度从 70.5% 掉到 53.4%，而随机池（97.7%→84.1%）和不相似池（96.6%→93.2%）都稳得多。池子变大是压力，但语义可混淆性才是真正的杀手。这对技能库工程的提示是：与其担心库变大，不如担心库里一堆名字和描述长得很像的 Skill——该合并的合并，该改名 differentiation 的趁早改。
完整的尺寸趋势表（百分比）：
| 池类型 | 指标 | k=5 | k=10 | k=20 | k=50 | k=100 |
|---|---|---|---|---|---|---|
| Random | Arm 1 P | 97.7 | 95.5 | 95.5 | 92.0 | 84.1 |
| Random | Arm 3 P | 25.9 | 23.2 | 19.5 | 8.6 | 4.4 |
| Random | Arm 3 成功率 | 31.8 | 36.8 | 40.1 | 36.3 | 41.9 |
| Similar | Arm 1 P | 70.5 | 63.6 | 60.2 | 56.8 | 53.4 |
| Similar | Arm 3 P | 34.5 | 22.3 | 15.7 | 7.3 | 3.7 |
| Similar | Arm 3 成功率 | 41.7 | 39.6 | 39.2 | 39.5 | 39.6 |
| Dissimilar | Arm 1 P | 96.6 | 96.6 | 96.6 | 94.3 | 93.2 |
| Dissimilar | Arm 3 P | 28.6 | 19.2 | 9.0 | 4.4 | 1.7 |
| Dissimilar | Arm 3 成功率 | 35.7 | 36.9 | 33.7 | 38.8 | 36.4 |
🤔 我的判断
这篇论文的定位很清楚：它不是新方法论文，是一篇测量学论文。但它的价值恰恰在这——在所有人都在闷头攒 Skill 的 2026 年，有人停下来问"这玩意儿到底哪里在起作用"，并且用 8135 条受控记录和一套经人工校验（95.8% 一致率、κ=0.952）的分类法给出了可信的答案。
我觉得最值钱的三个 take-away：
第一，写 Skill 就写程序纪律，别写知识百科。65.7% 对 4.5% 这组数字基本宣判了"把领域知识塞进 Skill"这条路收益甚微。环境搭建序列、验证步骤、输出格式约束、避坑清单——这些才是 Skill 的主场。
第二，别把检索精度和下游成功混为一谈。如果你在做技能库，离线检索指标涨了你别太高兴，它可能跟任务成功率一点关系都没有。评估要端到端做，而且要解析"智能体实际用了什么"，而不是只看"它做成了没有"。
第三，失败轨迹必须带标注进蒸馏器。no-hint 实验里 0.7462 对 0.4000 的差距足够说明问题。
也有几个我想挑刺的地方。一是整个研究集中在终端和工具类基准上，长程网页交互、开放式协作这些场景完全没覆盖，作者自己在 Limitations 里也承认了。二是开放编码只覆盖了约 3% 的归一化记录，稀有行为模式可能被漏掉。三是 GPT-5.3-Codex 在 RQ4 期间不可用导致换模型——虽然作者处理得很诚实，但 RQ4 的结论强度确实受限。还有个小遗憾：taxonomy 构建高度依赖 LLM judge，虽然有人工校验兜底，但 judge 模型本身的偏好在论文里讨论得不多。
对工程落地的启发，一句话版本：Skill 生命周期是个完整 pipeline——生成（带标注蒸馏）、检索（警惕相似干扰）、调用（防止机械套用）、适配（允许偏离脚本）——任何一环断了，Skill 都可能从资产变成负债。如果你也在做自进化智能体或者技能库，这篇论文的 12 模式分类法可以直接拿来当你自己的失败分析 checklist。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我