---
layout: post.njk
source: https://yage.ai/share/skill-checklist-not-textbook-20260823.html
speaker: yage.ai
title: |-
  Skill 不是教材，是检查单：一篇论文拆开了 Agent Skill
  的真实机制
date: '2026-08-23'
summary: 本文基于一项关于 Agent Skill 机制的论文研究，指出 Skill 的核心作用更像是一个检查单，主要提供清晰的步骤指引和检查单，而非补充知识。研究表明，带有明确成败标注的经验才能有效提炼成高质量的指南，而未经验证的经验或缺乏结果反馈的经验是“有毒”的。文章强调了在构建 Skill 库时，必须以真实闭环验证为前提，并建议通过明确验收标准和只纳入经过验证的失败教训来固化经验，以提升工程系统的确定性。
area: tech-engineering
category: ai-application
tags:
  - agent-skill
  - workflow-memory
  - process-anchoring
  - experience-validation
  - skill-library
people: []
companies_orgs: []
products_models: []
media_books: []
draft: true
status: evergreen
---

平时给 AI 写 skill
时，默认直觉往往是教它知识：行业背景、领域事实、产品细节，恨不得把内部
wiki 全部塞进去。但用过一段时间容易发现：背景知识堆得越多，agent
干活却没见变聪明，那些精心准备的领域事实似乎根本没起作用。

普林斯顿、UCSD、Stanford、USC
与约翰霍普金斯五所高校在八月中旬发布的一篇论文（arXiv
2608.14036），给出了机制层面的解释。研究者整理了 8,135 次 agent
干活的完整实验记录，逐一分析其中 skill 发挥作用的案例：65.7%
是在给动作提供清晰的步骤指引和检查单；而真正补上 agent
缺失事实的案例，只有 4.5%。

对比之下，skill
的作用更像检查单，而不是教材。这项研究帮我们澄清了三件事：实验如何证实
skill
真正管用的是规范动作而不是补充事实；没有成败标注的经验为什么会起反作用；以及
skill 库变大之后，为什么不必为检索命中率过度焦虑。

## 三份培训材料

同一批源轨迹做成三种材料的对照：蒸馏指南组 61.9%
比原始记录组 55.9% 高 6.06 分，后者甚至低于裸考的 59.1%

这项研究的实验设计，可以用培训新员工的过程来理解。

研究者先让不带任何先验的裸 agent
独立执行一批复杂的终端与工具调用任务，完整保存操作过程的录像，无论成败均记录在案。第二步，研究者把同一批录像整理成两种不同形态的培训材料：A
材料是清洗后的原始工作记录（论文称为 Workflow
Memory），相当于给新人一份前辈干活的流水账，由新人自行对照；B
材料则由老员工通读录像后，提炼成一页纸的操作指南（一个 SKILL.md
文件），写明环境先装什么依赖、需要提前绕开哪些踩坑点、做完后运行什么验证命令。

A 材料与 B
材料的信息来源完全相同，形成了严格的同源控制：经验总量保持一致，唯一的变量是表达形态。随后，三组
agent（完全不带先验的裸考组、携带原始工作记录的 A 组、携带操作指南的 B
组）在相同任务上各自运行数百次评测。

评测结果呈现出明显的差异。按最终结果统计，裸考组成功率为
59.1%；携带原始工作记录的 A 组不仅没有提升，反而下降到
55.9%；携带操作指南的 B 组则升至 61.9%。B 组相较 A 组高出 6.06
个百分点，这 6 分的优势在统计上站得住（95% 置信区间 +0.76 到
+11.36）。在原始素材完全相同的情况下，这 6
个百分点的优势来自经验加工提炼后的形态，而不是经验的数量。

超时失败率的数据同样说明问题：A 组超时率达 10.6%，裸考组仅为 1.7%，B
组为 4.4%。原因在于原始流水账充斥着试错回溯、环境排错与各种死胡同。agent
读入过多未经筛选的无效信息，不仅稀释了注意力，还在反复消化历史噪音的过程中耗尽了时间预算。经验本身并不等于正向资产，未经提炼和结构化的原始经验，在实际执行中往往会变成负资产。

指南到底如何发挥作用？研究者把 528 组同任务对照（涵盖
SkillsBench、Terminal-Bench 2.0 与 Terminal-Bench-Pro，共 1,584
次判读）的表现放在一起逐一分析，为生效案例做归因：起作用的指南基本都在给
agent
提供一套能照着做的步骤、执行顺序、检查单、工具序列和验证计划，论文里管这个叫程序锚定，检查单是其中最直观的一部分；而靠补上
agent
本来不知道的事实起效的，论文叫知识注入，占比极低。实际统计正是开头的
65.7% 对
4.5%。生效案例绝大多数靠步骤和检查，靠补知识起效的少之又少。

失败模式的分布进一步标出了能力边界。环境搭建与基础设施配置类失败从裸考的
5.3%（原始工作记录组 1.7%）降至指南组的 0.2%，输出格式不匹配错误从 7.4%
降至 3.2%，后台服务管理失败从 2.7% 降至
0.8%。这类明显下降的错误有共同特征：只要发现一次并规范写下，后续就能长期复用。相反，指南难以改善的错误变化不大：算法逻辑错误仅从
8.3% 微调至 7.4%，不做运行时检查的静态验证失误仅从 12.5% 变为
11.7%。

外科医生走上手术台并不缺解剖学知识，手术室里严格执行的检查单，防范的是高负荷下的步骤遗漏。agent
在复杂工程中也是如此：任务失败多源于长链路操作中的执行抖动与注意力漂移。这与我们在今年一月份发表的《从过程确定性到结果确定性》中的判断一致（这是我们的解读，不是论文原话）：运行时的稳定性来自执行与纠错的闭环加上明确的验收标准；skill
中真正关键的是检查单式的步骤指引与验证计划，是这套确定性在工程中的固化存储形态。提炼指南的意义，在于把初次探索消耗的大量
token 成本，压缩成一页高密度的操作指南，让后续任务凭一页纸的 context
开销就能换回大部分确定性。

编写 skill
时不妨对每一段都做一次检查：这究竟是动作流程还是事实陈述。可执行的步骤、环境检查和验证命令走在
65.7% 的高效通道上，而背景事实与概念百科的堆砌则挤在 4.5%
的低效通道里。

## 没有成败标注的经验是有毒的

既然提炼操作指南能带来实质收益，自然会想到自动化：把 agent
过往的所有运行记录交给大模型自动总结，直接沉淀出 skill
库。但论文针对这一做法设计的一组对照小实验，给出了明确的否定结论。

在这组对照小实验中，研究者使用同一批运行记录做提炼，唯一的变量是总结模型在提炼时能否看到每次尝试的成败标签。在
Gemini 的 Terminal-Bench-2
评测中，当运行记录池采用五次尝试中三次成功、两次失败（论文记作
3s2f）的混合配比时，带成败标签生成的指南让模型取得了 0.7462
的得分；一旦隐去成败标签做无差别总结，得分便直接下滑到 0.4000。

全失败的运行记录池（五次尝试全部失败，论文记作
0s5f）进一步说明了问题：即使在提炼时明确标明每次尝试全部失败，最终产出的指南质量依然低于没有任何参考材料的基线。在
Codex 针对 Terminal-Bench-2 的测试中，携带全失败操作指南的得分为
0.5161，携带全失败原始工作记录的得分为
0.2839，而不给任何材料的裸考基线得分有
0.5935。在历史尝试全部失败的情况下，强行提炼操作心得会把失败的探索路径固化下来，实际执行效果甚至不如空白基线。

失败的探索记录并非没有价值，它包含了试错边界，但前提是必须带有明确的负向反馈标记。如果剥离了成败标签，总结模型就无法分辨哪些动作促成了成功，哪些动作导致了失败。最终产出的指南，往往会把死胡同、低效重试甚至调试时的错误操作当成规范，教给后续执行的
agent。

这让培训材料的比喻更完整了一层：干活的新人需要随时对照验收标准来防止动作走形，负责编写培训材料的记录员，更需要在下笔之前明确知道每一次尝试究竟是成功还是失败。如果记录员自己对历史成败一无所知，写出来的培训手册就会变成一份充满误导的材料。

对于尝试搭建自进化 agent
系统的团队来说，这里有一条清晰的工程底线：从运行日志中自动挖掘与沉淀
skill，必须以每条运行记录都携带准确、可信的结果判定为前提。脱离了结果验证闭环的自动化沉淀，不仅无法带来系统能力的提升，反而会持续向系统注入错误的先验偏差。

在构建 skill
资产时，只有经过真实闭环验证的流程才能固化为指南。将未经检验的探索草稿直接写入库中并非中性的积累，它会持续向整个系统注入干扰。

说一件我们自己的事。我们维护着一个公开的工作区 context
infrastructure，里面有一份 skill
写作指南，今年三月底写成，比这篇论文早了将近五个月。它的两条核心要求，现在看正好落在论文的结论上：其一，skill
必须写验收标准，而且要具体到一个没有任何上下文的 agent
拿到就能判断自己做没做完；其二，已知陷阱只允许来自真实发生过的失败、返工、误判或多轮迭代中的教训，明确反对凭空预测可能的坑来凑数。前者对应论文里的验证计划，后者对应论文强调的成败信号。工程直觉和八千多次受控实验走到同一个点上，这大概就是经验先于证据的乐趣。指南在这里：grapeot/context-infrastructure
的 skill 写作指南。

## 命中崩了，成功率没动

skill 池从 5 涨到 100，精准命中率从 29.6%
降到 3.3%，任务成功率却从 36.4% 升到 39.3%

随着 skill
库中的条目不断增加，常会出现一种担忧：库扩大到上百个文件之后，如果 agent
在执行时没能精准调用目标指南，任务会不会直接受阻？针对检索与执行环节的实测数据给出了反直觉的结果。

在实际测试中，候选 skill 池从 5 个扩大到 100 个的过程中，agent
执行时实际查看或调用的 skill 里，恰好命中标准答案那篇的比例从 29.6% 降至
3.3%；但下游任务的最终成功率没有下跌，反而从 36.4% 升到
39.3%，整体基本平稳。

背后的原因在于，agent 使用 skill
库的过程更像逛图书馆，而不是做单选题。在终端操作与工具调用的实际场景中，许多
skill
往往共享底层的工程规范：虚拟环境初始化、后台守护进程拉起、通用错误码排查、输出文件验证。即使检索系统没有挑中预设的标准答案，agent
只要从翻阅到的几篇相近指南中提取出可用的配置、依赖指令或调用格式，就能组合出解决问题所需的关键步骤。因此，精确命中并不是任务成功的必要条件。

反过来，即便 agent
查看或调用了完全匹配的标准操作指南，也可能因为注意力偏差或推理波动而忽略指南中的步骤。精确命中同样不是任务成功的充分条件。

但这并不意味着可以对 skill
库的规模放任不管。离线诊断实验表明，条目总数的增加会带来压力，但大量长相相似的干扰条目才是更重要的压力源。候选池里一旦混入跟目标条目高度相似的干扰项，系统把正确指南排在第一位的比例就从
70.5% 下滑到 53.4%；而在不相关的随机候选池中，这一比例仅从 97.7% 降至
84.1%；不相似候选池更是只从 96.6% 微降到
93.2%。如果库中堆积着大量过时失效、功能重叠、职责混杂的条目，就会在检索层形成严重的语义混淆。

即便找到了指南，执行层同样会付出切实的代价：实验记录显示，误用或忽略指南的模式在配备
skill 的实验组中占了 10.0%，而在完全不带 skill 的裸考组中仅有
0.8%（在原始工作记录组中仅为
0.4%）。常见情形是机械照搬看似合理但不符合当前上下文的步骤。这种因引入不当指南而产生的额外损耗，就是典型的误用税。

维护 skill
库的重点在于保持语义清晰，而不是盲目追求复杂的检索召回算法：及时淘汰过时失效的废弃文件，合并功能重叠的规则，确保每个
skill 保持单一职责。此外，在每个 skill
的描述信息中明确写清何时不应使用该指南，是对冲这 10.0%
误用税成本最低、见效最快的方法。

## skill 的边界，和留下的判断

结合论文的实验证据与工程落地的实际经验，可以为 skill
划出三条清晰的边界：

第一，skill
能够有效减少执行抖动，但无法替代基础的逻辑思考。对于环境搭建、格式对齐、后台服务管理等高频繁琐的工程动作，检查单式的步骤指引切实有效；但对于前置的任务分解、核心算法设计以及定义正确标准的工作，skill
无法代劳。业务判断与验收标准依然必须建立在人类主导的契约层，skill
只是服务于下游执行阶段的动作稳定器。

第二，实验结论的适用范围需要保持审慎。该研究的评测场景主要集中在终端命令与工具调用的具体任务中，没有涉及长周期的复杂网页交互或开放式多
agent 协作；实验采用的模型组合仅覆盖 Codex 与 Gemini CLI 两种体系，Codex
主实验搭配 GPT-5.3-Codex，检索实验因模型下线改用 GPT-5.4，Gemini CLI
搭配 Gemini-3.1-Pro-Preview；人工归类分析只覆盖了约 3%
的整理后运行记录；同时这是一篇发布在 arXiv 上的 preprint
预印本，尚未经过同行评审。引用相关结论和数据时，必须保留这些客观前提。

第三，工程系统的核心价值正在进一步向契约层集中。随着各大平台对 skill
文件规范的标准化以及开源生态的成熟，编写通用操作步骤的门槛正在快速降低，纯粹的执行稳定器会逐步走向标准化与商品化。真正拉开系统表现差距的，始终在于能否清晰定义业务目标、设计出严密的结果验收标准，这也回到了我们关于结果确定性的核心结论。

基于这些发现，在实际工程中可以落实三条具体行动： 1. 审查现有 skill
库，逐段检验写下的是具体执行步骤还是事实陈述，剔除冗余的事实背景堆砌；
2. 仅从携带明确且可信成败标注的运行记录中提炼新
skill，避免未经验证的流程沉淀； 3.
定期清理库内功能重叠与过时的陈旧条目，并在描述信息中明确补充何时不应使用该
skill。