平时给 AI 写 skill 时，默认直觉往往是教它知识：行业背景、领域事实、产品细节，恨不得把内部 wiki 全部塞进去。但用过一段时间容易发现：背景知识堆得越多，agent 干活却没见变聪明，那些精心准备的领域事实似乎根本没起作用。
普林斯顿、UCSD、Stanford、USC 与约翰霍普金斯五所高校在八月中旬发布的一篇论文（arXiv 2608.14036），给出了机制层面的解释。研究者整理了 8,135 次 agent 干活的完整实验记录，逐一分析其中 skill 发挥作用的案例：65.7% 是在给动作提供清晰的步骤指引和检查单；而真正补上 agent 缺失事实的案例，只有 4.5%。
对比之下，skill 的作用更像检查单，而不是教材。这项研究帮我们澄清了三件事：实验如何证实 skill 真正管用的是规范动作而不是补充事实；没有成败标注的经验为什么会起反作用；以及 skill 库变大之后，为什么不必为检索命中率过度焦虑。
这项研究的实验设计，可以用培训新员工的过程来理解。
研究者先让不带任何先验的裸 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 库中的条目不断增加，常会出现一种担忧：库扩大到上百个文件之后，如果 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 只是服务于下游执行阶段的动作稳定器。
第二，实验结论的适用范围需要保持审慎。该研究的评测场景主要集中在终端命令与工具调用的具体任务中，没有涉及长周期的复杂网页交互或开放式多 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。