Demystifying Agent Skills

自动研究时间：2026-08-20 09:02（Asia/Shanghai）
来源日期：Hugging Face Daily Papers 页面实际显示 Aug 19，列表最顶部为 Demystifying Agent Skills: Why They Work—Until They Don’t。
研究路径：Daily Papers 列表 -> Hugging Face 详情页 -> arXiv 摘要页 -> arXiv v1 HTML、PDF 与完整 TeX 源码 -> 官方项目页与代码仓库。

执行摘要

Agent Skills 常被描述为给智能体外挂知识：把一份 SKILL.md 放进执行环境，模型就能调用过去积累的方法。然而这篇论文用受控实验给出了更精确的解释：技能真正的主要价值不是补充模型不知道的事实，而是把含有探索、失败分支和偶然细节的历史轨迹压缩成稳定的操作程序，让智能体更少在环境配置、工具顺序、输出格式和验证步骤上漂移。

作者把同一批成功与失败轨迹分别表示为直接的 Workflow Memory 和标准化 Skill，在相同任务上比较。对 528 个 Raw / Workflow Memory / Skill 配对三元组，Skill 的 oracle-status 成功率为 61.9%，Workflow Memory 为 55.9%，配对差值为 +6.06 个百分点，95% bootstrap 置信区间为 [+0.76, +11.36]。机制分类中，65.7% 的 Skill 案例被归为程序性锚定，只有 4.5% 属于显式知识注入。环境与基础设施失败从 Raw 的 5.3% 降至 Skill 的 0.2%，输出格式错误从 7.4% 降至 3.2%。这些结果支持“表示方式本身会改变经验是否可用”，而不是“只要给更多历史就会更好”。

但技能不是自执行程序。Skill 需要被找到、判断适用、正确调用、按当前上下文调整，并经过运行时验证。论文中的 skill_guidance_misapplied_or_ignored 在 Skill 组占 10.0%，明显高于 Raw 的 0.8% 和 Workflow Memory 的 0.4%；算法逻辑错误和只做静态检查而不运行验证，也没有因 Skill 而消失。换言之，技能将一部分失败从“忘了步骤”转移成了“选错程序、照搬程序或没有验证程序”。

检索实验进一步揭示了一个反直觉现象。候选池从 5 个扩大到 100 个时，平均实际使用精确率从 29.6% 跌到 3.3%，但下游成功率仍大致维持在 36%–39%。这不代表检索无关紧要，而是说明 SkillsBench 的精确 ground-truth 匹配与任务完成不是同一个变量：智能体可能同时查看多个技能，非标注但相关的技能也可能提供帮助；反过来，找到标注技能也不能解决超时、数值精度、缺失依赖或错误实现。

论文最值得保留的工程结论是：Agent Skills 应被当作一条“经验表示 -> 检索 -> 调用 -> 适配 -> 验证”的生命周期，而不是一个装入上下文即可生效的提示文件。 更可靠的技能系统需要同时优化压缩质量、结果标注、适用条件、检索精度、运行时观测和失败退出机制。

1. 论文基本信息

核心链接：

• Hugging Face 详情页：https://huggingface.co/papers/2608.14036
• arXiv 摘要页：https://arxiv.org/abs/2608.14036
• arXiv HTML 全文：https://arxiv.org/html/2608.14036v1
• arXiv PDF：https://arxiv.org/pdf/2608.14036
• arXiv TeX 源码：https://arxiv.org/e-print/2608.14036
• 官方项目页：https://zhiyuanjiang04.github.io/demystify-agent-skills/
• 官方代码仓库：https://github.com/zhiyuanjiang04/demystify-agent-skills

2. 背景与动机：从“技能是否有效”追问“技能改变了什么”

2.1 汇总成功率隐藏了因果机制

现有 Agent Skills 研究常用最终任务成功率判断价值：加载技能后成功率上升，就认为技能有用。这种口径能回答“是否可能有增益”，却无法区分至少五种完全不同的原因：

1. 技能提供了模型原本缺少的事实知识；
2. 技能把已知步骤排成更稳定的顺序；
3. 技能提醒了过去踩过的坑；
4. 技能只是碰巧与一次成功相关，实际没有被使用；
5. 技能内容合理，但被检索、解释或调用错了。

如果这些机制混在一个平均分里，技能生成器只能靠经验调 prompt，技能库也容易变成“多积累总会有用”的文件堆。作者因此把研究对象从文件本身扩展为完整的技能使用链路。

2.2 原始轨迹有证据，也有噪声

过去的执行轨迹包含真正有用的信息：依赖如何安装、服务如何启动、参数如何组合、失败如何修复、最后如何验证。但轨迹同时保留大量试错、死路、任务特有路径和冗长上下文。如果直接把它们作为 Workflow Memory 注入，智能体可能获得更多证据，也可能复制无关探索、耗尽预算或偏离当前任务。

标准化 Skill 的假设是：将“发生了什么”提炼成“应该怎么做、检查什么、何时停止”，可以保留程序性价值并减少轨迹噪声。论文的 RQ1 正是要在同源轨迹条件下隔离这种表示差异。

2.3 技能库扩大后，存在不等于可用

单技能实验默认正确技能已经送到智能体面前，实际系统则要从不断增长的库中选择。候选越多，相似但不完全适用的技能也越多。此时失败可能发生在三个不同位置：

• 语义检索器没有把正确技能排到前面；
• 智能体看到了候选，却选得过多、过少或选错；
• 技能已在执行环境中被查看，仍没有转化为正确操作。

作者把这三个问题设计为独立实验，而不是把离线检索结果直接传给后续执行。这样可以避免把某一阶段的输出污染成下一阶段的输入，也能观察“选对”和“做对”之间的断裂。

2.4 成败标签可能是经验蒸馏的关键监督

失败轨迹并不天然有害。它可能包含正确的前半段、关键反例和宝贵的坑点；问题在于技能生成器是否知道这条轨迹最终失败。如果移除 success / failure 标签，生成器可能把失败路径当成可复用方案。RQ2 通过 normal 与 no-hint 对照，检验技能收益来自轨迹内容本身，还是来自对结果的显式标注。

3. 核心贡献

3.1 用同源经验隔离 Skill 与 Workflow Memory 的表示效应

作者不是拿任意技能与任意记忆比较，而是先收集同一任务的成功和失败轨迹，再从完全相同的轨迹组合生成两种产物：

• Workflow Memory：清洗和结构化轨迹，但保留较直接的过程流；
• Skill：将轨迹蒸馏成标准化、可复用的 SKILL.md。

二者在同一任务、同一 agent-model、同一 harness 和相同试验预算下评测。这个控制使“Skill 优于 Workflow Memory”更接近表示差异，而不是经验来源差异。

3.2 建立三大类、十二种模式的技能使用分类

论文把行为分为三类 Skill-use Category（SC）：

这一分类的价值不只是描述“失败是什么”，还用于配对回答“加入 Workflow Memory 或 Skill 后，哪个模式被修复、哪个模式被引入”。

3.3 将开放编码与配对轨迹分析结合

作者先把 8,135 条异构 trial 归一化，其中 7,837 条有 agent transcript；再对分层抽样的 240 条轨迹开放编码，保留 238 个有效唯一标签，归并为 12 种规范模式。随后构造 528 个 Raw / Workflow Memory / Skill 配对三元组，形成 1,584 个 arm-level 模式分配。

分类过程由 LLM 辅助，但不是完全无审计：人类标注者检查了 238 个原始标签各自的三条支持轨迹，共 714 次轨迹—标签核对，并独立把 238 个标签映射到 12 种规范模式；与 LLM 聚合的精确一致率为 95.8%，Cohen’s $\kappa=0.952$。

3.4 分离离线识别、显式选择与真实执行

检索研究包含三个互不串联的实验臂：

三个实验使用匹配的候选池，但 Arm 1 / 2 的结果不会送进 Arm 3。这一设计让“识别困难”和“执行困难”保持可分。

3.5 补充跨框架迁移、结果标签消融与 token 成本分析

论文不只比较成功率，还测试：Codex 轨迹生成的固定产物是否能迁移到 Gemini CLI；隐藏成败标签是否影响 Skill 构造；Skill 是否只是任意短计划都能替代；以及不同表示在相同任务交集上的 token 成本。这些补充实验为主结论建立了更完整的边界。

4. 方法：如何把经验表示、行为变化和检索拆开测量

4.1 四个研究问题

论文围绕四个 RQ 组织：

1. RQ1 表示：同一经验写成 Workflow Memory 或 Skill，是否改变下游行为？
2. RQ2 结果信号：显式 success / failure 标签对技能蒸馏有多重要？
3. RQ3 跨框架迁移：一个框架产生的程序指导换到另一个框架后是否仍有用？
4. RQ4 检索与使用：技能池规模和混淆度如何影响识别、选择与真实执行？

4.2 RQ1–RQ2：固定五条来源轨迹，改变成功与失败配比

作者选择能形成平衡轨迹池的任务，在固定经验预算下构造 5s0f、4s1f、3s2f、2s3f、1s4f、0s5f 六种组合，其中 s 是成功轨迹，f 是失败轨迹。每一种组合都从同源轨迹生成 Workflow Memory 和 Skill，并重新运行相同任务。

Raw 组不接收历史经验。Workflow Memory 获得清洗后的过程记忆；Skill 组在执行环境中获得标准化技能资源，而不是把全文预先内联进初始上下文。下游执行默认每题 $n=5$ 个唯一 trial，并使用 Harbor 的容器化评测流程。

normal / no-hint 消融保持轨迹与执行协议不变，只在技能创建阶段隐藏结果标签。这样能检验失败轨迹进入后，生成器是否需要知道哪些行为不应被总结成正向规则。

4.3 RQ3：固定产物，只替换 agent framework

跨框架实验用 Codex + GPT-5.3-Codex 产生 Workflow Memory 和 Skill，然后把这些固定产物交给 Gemini CLI + Gemini-3.1-Pro-Preview。任务和来源经验不变，变化的是 prompt 风格、工具接口和执行循环。

这比“在目标框架重新生成一个技能”更严格，因为重新生成会混入目标模型能力。固定产物下的差异更接近表示本身的可移植性。论文报告的整体趋势是蒸馏后的 Skill 比直接 Workflow Memory 更能跨框架保留作用，但正文没有给出一个单一汇总效应量，应该结合各 benchmark 和轨迹配比图解读。

4.4 RQ4：控制候选池大小与干扰类型

SkillsBench 原生提供 task-to-skill 标注。每个任务的候选池由 ground-truth 技能集合与干扰技能组成，池大小依次为 5、10、20、50、100。干扰项有三类：

• random：随机无关技能；
• similar：embedding 空间中的近邻技能；
• dissimilar：embedding 空间中的远邻技能。

预测集合与 ground-truth 以规范技能 ID 求交，重复调用同一技能只计一次。空预测集合的 precision 和 recall 都记为 0。Arm 3 另记录 verifier 的二元任务成功结果。

这里有一个重要的评测假设：SkillsBench 标注被当作唯一 ground truth。一个未标注技能即使实际有帮助，在 precision 中仍然是假阳性。论文正是通过“precision 大跌但成功率稳定”暴露这种精确匹配指标与实际效用之间的差异。

4.5 轨迹分类如何形成

原始开放编码由 Claude Sonnet 4.6 以禁用工具、禁用会话持久化的方式完成，使用固定随机种子和分层采样。单轨迹提示保留任务说明、Skill 产物，以及 transcript 的头尾片段；尾部预算更大，因为最终错误、验证决策和超时通常发生在末端。

规范分类通过两轮归并产生：先按约 60 条记录分批形成局部模式，再把局部模式合并为全局 12 类。配对阶段针对相同 benchmark、setting 和 task 选取 Raw / Workflow Memory / Skill 各一条代表轨迹，要求 LLM judge 给出模式、证据片段、两两变化和机制标签。

这种方法让行为差异可审查，但也意味着统计单元不是对所有重复 trial 的人工穷举分类。后文的局限部分需要对此保持谨慎。

5. 核心实验结果

5.1 Skill 相对 Workflow Memory 的差异得到配对支持

配对差值如下：

最强的统计结论是 Skill 优于 Workflow Memory，因为置信区间没有跨零。Skill 相对 Raw 的 +2.84 点置信区间跨零，不能写成已得到同等强度确认的总体提升。论文的主张因此应准确表述为：把同一经验蒸馏成 Skill，比直接保留为 Workflow Memory 更稳定；它并没有在这组配对数据上证明对 Raw 的总体增益必然显著。

主表也显示增益依赖经验质量。以 Codex 的 Terminal-Bench 2.0 为例，Raw 为 59.35%；Skill 在 5s0f 到 1s4f 均高于 Raw，3s2f 达 78.06%，但 0s5f 降至 51.61%。Gemini 上也大体呈现成功轨迹越多、Skill 越强的趋势。失败经验有价值，但如果没有足够正确路径约束，蒸馏可能把失败模式结构化。

5.2 技能的主要机制是程序性锚定

机制标签中，Skill 的 procedural_anchor 占 65.7%，显式 knowledge_injection 只有 4.5%。这意味着典型增益来自：

• 固定环境准备与依赖处理顺序；
• 保持工具调用和实现步骤连贯；
• 在关键节点执行中间检查；
• 记住输出 schema、服务生命周期和常见坑点；
• 将冗长试错压缩为可操作清单。

Skill 组的 skill_guided_success 占 61.6%，Workflow Memory 组的 workflow_guided_success 占 54.5%。Workflow Memory 并非没有价值，但它更接近原始轨迹，容易保留与目标任务无关的探索和失败分支。

5.3 Skill 更擅长减少操作性失败，而非修复深层推理

SC2 整体从 Raw 的 37.3%、Workflow Memory 的 33.3% 降到 Skill 的 23.5%。下降最明显的是能被程序化复用的操作约束；算法逻辑和 runtime verification 只小幅变化。这一边界对技能设计很实用：适合写进 Skill 的是可重复程序、检查顺序和失败预防，而不是期待文档自动替代问题重构和真实执行验证。

5.4 抽象越可复用，越需要适用性判断

Skill 组的 skill_guidance_misapplied_or_ignored 为 10.0%，Raw 和 Workflow Memory 分别只有 0.8% 和 0.4%。常见情形包括：

• 只执行 Skill 的部分步骤，却遗漏决定正确性的检查；
• 源任务假设已变化，仍机械照搬；
• 当前计划与 Skill 冲突时，忽略本来有用的指导；
• Skill 过于具体，迁移到相似任务后参数或环境不兼容；
• Skill 过于抽象，无法突破当前实现瓶颈。

Workflow Memory 的特有弱点则是上下文与过程负担：timeout_budget_exhaustion 在 Workflow Memory 组占 10.6%，高于 Raw 的 1.7% 和 Skill 的 4.4%。蒸馏减少了过程噪声，却把风险转移到抽象是否合适以及调用是否正确。

5.5 成败标签在失败轨迹进入后变得重要

只含成功轨迹时，隐藏 outcome label 的影响较小；随着失败轨迹加入，normal Skill 通常明显强于 no-hint。最突出案例是 Gemini + Terminal-Bench 2.0 的 3s2f：

这说明高质量技能蒸馏不只是摘要任务，还需要结果监督。失败轨迹应该作为“避免什么、在哪一步转向”的带标签反例，而不是与成功轨迹无差别拼接。

5.6 相似干扰项比纯规模更难，真实使用精度下降最快

Arm 1 的 embedding top-1 平均精确率从候选池 5 的 88.3% 降到候选池 100 的 76.9%；Arm 2 的显式 agent selection 平均精确率从 70.0% 降到 63.7%。按干扰类型看，similar pool 的 Arm 1 精确率从 70.5% 降到 53.4%，而 dissimilar pool 从 96.6% 仍只降到 93.2%。

这说明“语义相近但程序边界不同”比纯粹多几个无关文件更危险。一个检索系统如果只优化主题相似度，很容易返回同领域却不适用于当前环境、工具或验证条件的技能。

Arm 3 的行为更极端：

Gemini 的实际使用精确率从 16.9% 降至 0.7%，成功率仍约 36%–39%；Codex 从 42.3% 降至 5.9%，成功率反而从 35.4% 升至 42.0%。在 $k=100$ 时，Arm 3 recall 仍有 54.3%–73.6%，表明智能体往往不是完全没看到 ground-truth，而是同时查看了大量候选。

不能据此得出“检索质量不重要”。更稳妥的解释有三点：ground-truth 标注不是实际效用的完备集合；多技能浏览使 precision 天然下降；成功还被实现、依赖、超时与验证等变量控制。部署指标应同时记录候选数、实际读取数、适用性判断、最终引用步骤和任务结果。

5.7 任意短提示不能完全替代结构化 Skill

作者在 26 个 Terminal-Bench 2.0 任务、每题 5 个 trial 上增加两个轻量基线：

Skill 显著高于两个短文本基线，说明结果不能简单归因为“多给一段简短计划”。但这仍是特定任务子集上的补充实验，不能推出标准化文件格式本身是全部因果来源；Skill 的构建提示、内容质量、加载协议和 agent 原生支持可能共同作用。

5.8 Skill 更有效，Workflow Memory 更节省 token

在 Raw、Workflow Memory、Skill 都有完整 token 元数据的 83 个相同任务交集上，作者先按任务平均，再在任务间等权平均：

Workflow Memory 相比 Raw 每任务少 129.5K token，成功率几乎不变；Skill 相比 Raw 少 34.2K token，并提高 5.5 点；但 Skill 相比 Workflow Memory 多 95.3K token，只换来 4.8 点成功率。论文据此把 Skill 定位为更有效的表示，把 Workflow Memory 定位为更高效的表示。

需要注意，这个结果中的 token 数非常高，且只覆盖元数据完整的 83 题交集。它能说明同一交集内的相对权衡，不能直接外推为任意生产 agent 的绝对成本。

6. 局限与证据边界

6.1 Skill 相对 Raw 的总体差值仍有统计不确定性

528 个配对三元组上，Skill 相对 Workflow Memory 的置信区间为正，但 Skill 相对 Raw 的 95% CI 跨零。文章标题与摘要容易让人形成“技能必然提升基线”的印象，更准确的证据是“结构化蒸馏优于直接过程记忆”，而不是“任何 Skill 都显著优于不用 Skill”。

6.2 一个任务—设置只选一条代表轨迹做配对分类

分类阶段从每个 arm 的重复 trial 中按稳定 ID 选一条代表轨迹，没有对所有重复运行做完整人工标签或求平均。虽然固定规则提高了可复现性，但某条轨迹的偶然路径可能影响模式分配。成功率使用 verifier 结果，行为机制则依赖代表轨迹，二者证据强度不同。

6.3 全量配对分类仍由 LLM 辅助

开放标签与规范映射有较强人工复核，95.8% 一致率也很高；但 528 个三元组并未全部由多人独立人工编码。judge 看到截断后的任务、Skill 和 transcript 头尾，可能漏掉中段的关键因果步骤。证据 quote 增强了可审计性，不等于消除了模型判断偏差。

6.4 开放编码样本只约占归一化记录的 3%

240 条开放编码记录用于从 8,135 条 trial 中诱导分类，分层抽样避免了大 benchmark 或单一 arm 主导，但罕见模式可能仍未进入 12 类 taxonomy。分类适合解释主要失败面，不应被视为 Agent Skills 的完备故障枚举。

6.5 任务域集中在终端、工具调用和可验证执行

Terminal-Bench 与 SkillsBench 强调文件、命令、服务、调试和 verifier。这类任务尤其适合程序性锚定，结论未必同样适用于长程网页交互、开放式协作、谈判、创意工作或缺少明确 oracle 的任务。

6.6 agent-model 配置数量有限，且 RQ4 更换了 Codex 模型

RQ1–RQ3 的 Codex 使用 GPT-5.3-Codex，RQ4 因可用性改为 GPT-5.4。作者明确要求 RQ4 只做实验内比较，不把绝对数值与前面 RQ 直接横比。Gemini 与 Codex 两套结果也不足以代表所有模型家族、工具协议和 Skill 加载方式。

6.7 Ground truth 只描述“标注相关”，不等于“唯一有用”

SkillsBench 的 task-to-skill annotation 是计算 precision / recall 的必要标准，但相似技能可能贡献部分程序帮助。实际使用 precision 的极低数值既可能表示检索噪声，也可能表示标注集合无法覆盖可替代程序。下一步应引入因果消融：移除被调用技能后重新运行，或记录某个具体步骤是否可归因于该技能。

6.8 迁移与成本结果还缺少更完整统计报告

跨框架图支持 Skill 更可移植的趋势，但主文没有为 RQ3 提供一个类似 +6.06 点及置信区间的汇总统计。token 分析也受部分 Skill 运行元数据不完整影响，只能在匹配交集上报告。两者适合作为支持性证据，不宜凌驾于配对成功率和 taxonomy 主结果之上。

7. 应用影响与工程启示

7.1 Skill 应写成“程序 + 适用条件 + 验证”，而不只是教程

论文结果支持一种更严格的 Skill 结构：

• 明确适用前提和不适用条件；
• 给出操作顺序，而不是只讲概念；
• 标出高风险失败点和恢复分支；
• 定义中间检查与最终 runtime verification；
• 对环境、工具版本、输入 schema 做可见约束；
• 当假设不成立时允许退出或重新规划。

这直接针对 10.0% 的误用 / 忽略模式。一个没有适用边界的“最佳实践”文件越清晰，反而越可能被机械照搬。

7.2 技能生成器需要保留 outcome provenance

从失败轨迹学习时，至少应记录最终 verifier 结果、失败阶段、修复是否成功和哪些步骤仍可复用。把成功与失败 transcript 混成无标签语料，会让生成器无法区分方案与反例。工程上可以把每条抽取规则追溯到来源轨迹和结果，支持后续删除错误归纳。

7.3 检索应从主题相似升级为程序兼容性

similar distractor 是最难的离线压力源，说明只看任务描述 embedding 不够。更好的检索键应包含：

• 工具与运行环境；
• 输入 / 输出契约；
• 前置状态与预期副作用；
• 验证器或成功标准；
• 失败模式与恢复策略；
• Skill 的适用范围和反例。

检索后还应有轻量 applicability check，而不是把 top-1 文件直接当作权威指令。

7.4 观测指标不能只看最终成功率

生产系统至少应记录：检索候选数、读取技能数、实际采用的步骤、被跳过的步骤、适用性判断、验证结果、因 Skill 引入的回退以及 token / 延迟成本。否则成功时无法知道 Skill 是否真正起作用，失败时也无法区分检索错、调用错和执行能力不足。

7.5 技能库需要治理，而不只是增长

候选池扩大使实际使用 precision 急剧下降。技能库应该支持版本、去重、合并、废弃、冲突检测与使用反馈。对于语义相近但环境不同的技能，可以显式建立变体关系或共享父 Skill，避免把十个近似文件平铺给 agent。

7.6 Skill 不能替代外部验证

Skill 对 static_verification_without_runtime 的改善有限，说明“提醒要测试”与“系统强制运行正确测试”不同。高风险流程应把验证器接入 harness，让完成状态依赖可重放证据，而不是只依赖模型阅读 Skill 后的自我声明。

8. 与相关工作的关系

8.1 从 episodic memory 转向 procedural memory

Reflexion、Voyager 等工作强调保存反思、经验或可复用行为；Agent Workflow Memory 则直接把历史轨迹总结为工作流。本文沿着“记住如何行动”的路线前进，但进一步控制来源经验，比较直接过程记忆与标准化 Skill，并用配对轨迹解释表示差异。

• Agent Workflow Memory：https://arxiv.org/abs/2409.07429
• Managing Procedural Memory in LLM Agents：https://arxiv.org/abs/2606.23127

8.2 从“技能能否提升”转向“技能在哪一环失效”

SkillsBench 与 SWE-Skills-Bench 提供了结构化技能的下游评测环境，主要回答技能文档是否能改善任务结果。本文复用了 SkillsBench 的任务—技能标注，同时指出 final success 会混合检索、调用和执行问题，因此加入三臂检索研究与十二模式行为分类。

• SkillsBench：https://arxiv.org/abs/2602.12670
• SWE-Skills-Bench：https://arxiv.org/abs/2603.15401

8.3 与自动技能演化和路由互补

SkillRL、EvoSkill、AutoSkill 等路线关注如何自动发现、修改和积累技能，SkillRouter 关注规模化选择。本文的贡献不是另一个生成算法，而是一组诊断标准：新技能是否只是注入知识，是否形成程序锚点，是否在相似干扰下可检索，是否因错误适用反而伤害执行。

• SkillRL：https://arxiv.org/abs/2602.08234
• EvoSkill：https://arxiv.org/abs/2603.02766
• SkillRouter：https://arxiv.org/abs/2603.22455
• SoK: Agentic Skills：https://arxiv.org/abs/2602.20867

8.4 与 Anthropic Agent Skills 规范的关系

论文把标准化 SKILL.md 作为一种可复用程序产物，并遵循把 Skill 放在执行环境、由 agent 按需使用的协议。这与 Anthropic 公开 Agent Skills 仓库所代表的工程抽象一致。本文提供的增量是机制层证据：格式的价值主要在把噪声经验变成可调用程序，但格式不会自动解决适用性和验证。

• Anthropic Agent Skills 公共仓库：https://github.com/anthropics/skills

9. 结论

这篇论文把 Agent Skills 从“有效的提示技巧”推进为可分阶段研究的程序性记忆系统。它最有说服力的证据来自同源经验控制：Skill 相比 Workflow Memory 提高 6.06 个百分点，且配对置信区间为正；轨迹分类显示增益主要来自程序性锚定，而不是知识注入。它也清楚展示了代价：技能会引入新的误用和适用性失败，算法错误与真实验证不足依然存在，候选库扩大后精确 ground-truth 使用迅速恶化。

因此，可靠的技能系统不应以“仓库里有多少 SKILL.md”衡量成熟度。更关键的是：经验是否带有可信结果标签，程序是否被压缩到合适抽象层，检索是否检查环境与契约兼容性，agent 是否能拒绝不适用技能，以及 harness 是否用外部证据验证最终状态。

对构建自进化智能体的团队而言，下一阶段的重点不是无限写更多技能，而是建立可审计的技能生命周期：从带来源的轨迹蒸馏，到可解释检索、适用性门禁、运行时观测、失败归因，再到版本化修订和废弃。只有这条链路闭合，过去经验才会从上下文负担变成稳定能力。

参考资料

1. Hugging Face Daily Papers：https://huggingface.co/papers
2. Hugging Face 论文详情：https://huggingface.co/papers/2608.14036
3. arXiv 摘要与完整论文：https://arxiv.org/abs/2608.14036
4. arXiv HTML 全文：https://arxiv.org/html/2608.14036v1
5. 官方项目页：https://zhiyuanjiang04.github.io/demystify-agent-skills/
6. 官方代码与研究产物：https://github.com/zhiyuanjiang04/demystify-agent-skills
7. Agent Workflow Memory：https://arxiv.org/abs/2409.07429
8. SkillsBench：https://arxiv.org/abs/2602.12670
9. SWE-Skills-Bench：https://arxiv.org/abs/2603.15401
10. Anthropic Agent Skills：https://github.com/anthropics/skills