把Skills蒸馏进权重：让AI真正学会技能，而非依赖提示词

Skills权重蒸馏On-Policy
于 2026-08-28 03:52:28 修改
·本内容遵循CC 4.0 BY-SA版权协议

1. 为什么要把 Skills 蒸馏进权重，而不是塞进 Prompt

最近半年，AI 编程工具圈最热的概念之一就是 Skills。Claude Code 的 Skills、Cursor 的 Rules、OpenAI 的 Agent Skills，各家都在做“把经验打包给模型用”这件事。很多人的第一反应是：Skills 不就是一套写好的 Prompt 模板吗？加几个 Markdown 文件，让模型在对话开始时读一下，不就行了？

这个理解不算错，但只说对了一半。

如果你只是自己用，或者团队里几个人共享一套提示词，那么以 Prompt 方式维护 Skills 完全够用。可一旦你把 Skills 当成一种可复用的资产，希望不同模型、不同项目、不同规模的 Agent 都能稳定地使用它，问题就来了：提示词是不稳定的，它依赖模型的上下文窗口、依赖模型当时的注意力分配、依赖系统提示词的格式，几百行规则塞进去，模型真的能每一条都记住并遵守吗？

答案显然是不能。

这就引出了这篇论文要解决的核心问题：与其把抽象的 Skills 写在 Prompt 里，不如把它蒸馏进模型的权重里。 论文标题叫 “Distill Skills into Weights, Not Prompts: Abstract Skills as Privileged Signals for On-Policy Self-Distillation”，翻译过来是“把技能蒸馏进权重，而不是提示词：抽象技能作为 On-Policy 自蒸馏的特权信号”。

这篇文章会从一个程序员能理解的角度，拆解这篇论文到底做了什么、为什么 On-Policy 是关键、什么是 Privileged Signal、以及这套思路将来会不会改变我们使用 AI 工具的方式。

读完之后，你会知道：

  • 为什么纯 Prompt 方案承载不了复杂技能；
  • 什么是权重蒸馏，为什么它比提示词更稳定；
  • 什么是 On-Policy Self-Distillation，结合 PPO 和 RLHF 怎么理解；
  • 什么是 Privileged Signal，它是怎么在训练时帮助模型、又在推理时完全不出现的；
  • 这套方法对 Agent、编程助手和普通开发者意味着什么。

2. 先理清概念：Prompt、Skills、Weights 到底在说什么

先看一张粗粒度的对比表，后面再展开讲。

对比维度 Prompt / 提示词 Skills / 技能包 Weights / 权重
存在位置 对话上下文 上下文或外部配置 模型参数内部
更新方式 每次对话临时注入 按需加载 通过训练修改
鲁棒性 依赖模型长上下文能力 中等，取决于实现 高，一旦学会就稳定
可复用性 同套提示词换模型效果波动大 跨模型可用但效果不一致 绑定特定模型权重
最适场景 快速实验、少数规则 团队共享工作流 生产级稳定能力

2.1 Prompt：你给模型写的“临时说明书”

Prompt 是用户和模型交互时输入的指令。你可以把它想象成你去一家餐厅，口头告诉厨师“少放盐、多放蒜、不要香菜”。厨师大概率能听懂，但如果要求变成五十条，厨师记不住，做出来的菜一定不稳定。

系统提示词就是一份更正式的“临时说明书”，通常在每次对话开始时注入。它的优点是修改成本低、不需要训练、随时可以改版本。缺点是：

  1. 占用上下文窗口；
  2. 模型不一定严格遵循；
  3. 换一个模型，效果可能断崖式下降；
  4. 当规则之间互相冲突时，模型不知道优先级。

2.2 Skills：可复用的经验包

Skills 的核心思路是把某个领域的操作经验和规则打包成一个文件目录，比如“前端开发技能”“学术论文写作技能”“测试技能”，按需加载到上下文里。

这样做的好处是：不需要每个 Prompt 都写一遍，按项目或任务动态决定加载哪套技能。坏处是：它本质上还是文本。 除非你用的是本地 RAG 或者是类似动态文件注入的方式，否则它进入模型的方式仍然是上下文。

也就是说，Skills 对模型的约束力，和 Prompt 没有本质区别。它只是把“说明书”组织得更好。

2.3 Weights：模型真正“学会”的东西

权重是神经网络里所有可训练参数的总和。如果说 Prompt 是“告诉模型怎么做”，那么权重就是“让模型真的会做”。

一个模型如果只在上下文里见过“遇到 Python 报错要先看堆栈”，那它可能输出类似的建议，但遇到具体报错时表现不一定好。但如果这个知识被写进权重里，那么模型会产生一个非常稳定的条件反射：看到 Traceback，自动定位错误行，自动判断异常类型，自动给出修复方案。

从技术上讲，“蒸馏进权重”就是把某一类能力通过训练内化进参数。它不依赖上下文里有没有那段文本，也不依赖模型注意力机制有没有“看到”那条规则。

这里可以做一个非常直接的类比：

类比 Prompt Weights
学车 教练在旁边说“打方向盘” 你已经练习到肌肉记忆
编程 查文档写代码 不用查文档也能写
模型 告诉它按规则输出 它天然知道按规则输出

很多人误导性地以为“只有提示词才能教模型新技能”，实际上这是不对的。真正稳定的能力一定是在权重层面。

3. 为什么“提示词承载技能”这件事会失效

在继续讲论文之前，需要先把问题背景说透：为什么现在很多团队发现，把技能写成 Prompt 之后效果越来越不稳定？

可以从三个维度来看。

3.1 上下文长度不是无限的

现在的模型动辄支持 128K、200K 甚至 1M 上下文窗口，看起来很大，但真正可用的注意力区间并不等于整个窗口。把一份几千行的 Skill 文档塞进上下文，哪怕模型语法上能接受，它在生成时也未必能把文档关键信息和当前任务真正关联起来。

尤其当一个 Agent 需要连续执行多个步骤，每一步都要“记忆”技能文档中的某条规则时，长上下文带来的注意力稀释问题会非常明显。

3.2 规则之间存在冲突

一套完整的 Skill 通常包含：任务拆解流程、编码规范、测试要求、错误处理、提交信息格式。如果这些规则并行出现在提示词里，模型要自己判断优先级。

比如：技能文档说“优先重构”，而当前任务要求“快速上线修复”，模型到底听谁的？人和人都需要讨论，模型更难稳定处理。

3.3 每次推理都重新“思考”规则，浪费且不稳定

Prompt 方式下，模型每次推理都要重新读一遍技能文档，再决定如何行动。这个过程的本质是：用一个概率模型去复现一套确定性规则。结果当然是概率性的——有时遵守，有时不遵守。

而权重蒸馏之后，规则已经成为模型条件概率分布的一部分。模型“知道”自己应该怎么做，不需要在上下文里反复确认。这是两种完全不同的机制。

这里就要引出论文的核心思路：在训练阶段，把 Skills 作为 Privileged Signals（特权信号）提供给模型；在推理阶段，模型不再需要这些信号，因为它已经学会了技能对应的行为。

4. On-Policy 与 Off-Policy：为什么必须“边做边学”

论文标题里的 On-Policy Self-Distillation 是核心中的核心。要理解它，得先从强化学习里的 On-Policy 和 Off-Policy 讲起。

4.1 什么是 On-Policy

在强化学习中，On-Policy 的意思是：用来更新策略的数据，必须来自当前策略的采样。

举个通俗的例子。你正在学打羽毛球，每次挥拍后，教练根据你这次挥拍的结果给你反馈，你立刻调整动作。这个“反馈-调整”过程里，所有数据都来自你当前的动作，这就是 On-Policy。

如果教练拿的是别人三年前的比赛录像来教你，那你学的是别人的策略，而不是自己当前策略的改进，这是 Off-Policy。

PPO（Proximal Policy Optimization）是目前大语言模型 RLHF 中最常用的算法，它最核心的设计就是 On-Policy：用当前策略生成一批数据，算完优势函数，更新策略，然后丢弃旧数据，重新采样。每一步都保证更新的数据来自“现在的自己”。

4.2 为什么技能蒸馏必须 On-Policy

这里要重点说一个容易踩坑的直觉误区：很多人觉得，那我把训练数据准备好，让模型看一遍技能，再做事，不就行了吗？

问题在于：模型在做任务时，如果只能从最终答案里学到对错，它是学不到“过程中的关键决策点”的。 尤其像写代码、调试、规划任务这类复杂流程，正确的结果可能来自多条路径，而错误的结果也可能只是某一步走偏了。

On-Policy Self-Distillation 的核心是：模型先用当前策略去执行任务，在“执行过程中”记录它看到的场景、做出的决策、遇到的反馈。然后把这些真实交互数据拿回来蒸馏。由于这些数据来自模型自己，分布是匹配的，蒸馏的效果更稳定、更有效。

这里还有一个隐性问题：如果用 Off-Policy，拿别人执行任务的轨迹来蒸馏，模型和目标任务的分布可能不一致。 比如你让一个 DevOps 模型去学会写前端代码，它连 JSX 语法都还生成不对，那它从前端高手轨迹里能学到什么？只能学到“泛泛的经验”，学不到“可执行的技能”。

4.3 论文为什么用 Self-Distillation

Self-Distillation 的意思是：老师是模型自己，学生也是模型自己。不是用一个更大的模型去教小模型，而是同一个模型在执行任务的过程中，自己产生数据，自己又拿这些数据来更新自己。

这在工程上有个明显好处：不需要额外训练一个教师模型，也不需要昂贵的人工标注。你只需要：

  1. 让模型按当前策略跑任务；
  2. 把任务过程中的输入、输出、中间推理保存下来；
  3. 根据某种学习信号做蒸馏更新；
  4. 重复。

整个过程完全自举。

但这里有一个关键点：如果只是把模型自己的输出拿回来再训练一遍，很容易退化成“重复自己”的循环。 所以论文引入了 Privileged Signals，也就是在训练阶段给模型提供额外的、推理阶段不会出现的信息，让蒸馏有真正的“学习信号”可依。

5. Privileged Signal：训练时的“开卷考”，推理时的“闭卷考”

Privileged Signal 是这篇论文里最有意思的设计。它来自 Teacher-Student 范式，也叫 Learning using Privileged Information（LUPI），最早在 SVM 时代就有类似思想。

简单说：训练时模型可以看“标准答案”或“额外提示”，但推理时不提供这些信息。 模型的任务是学会不依赖这些额外信息也能做对。

放到这篇文章的技术语境里，可以这样理解：

  • 任务：让模型学会某种 Skill，比如“前端组件性能优化”。
  • 训练时：我们把 Skill 的抽象规则、专家经验、内部知识作为 Privileged Signal 喂给模型，告诉它“在遇到这类问题时，你应该按这些方法做”。
  • 推理时：Skill 不再出现，模型只能凭自己的权重做推理。
  • 目标：模型在“没有开卷资料”的情况下，也能表现出“看过开卷资料”时的能力。

这就像学生复习时看了一本非常详细的笔记，考试时笔记收走，但解题方法已经内化。

在论文框架里，Privileged Signal 不是出现在上下文里，而是作为一种额外的训练输入，帮助模型在当前动作和最终结果之间建立更细粒度的联系。它不参与推理，因此不会占用上下文，也不需要模型在生成时去“回想规则”。

这里的关键差异是：

方式 训练时 推理时 效果
In-context Skill Skill 文本在上下文 Skill 文本必须在上下文 占用窗口，效果不稳定
Distilled Skill Skill 作为 Privileged Signal 无额外信息 参数内化，效果稳定
纯行为克隆 只克隆专家轨迹 无额外信息 学不到深层决策逻辑

论文主张的是第二种：训练时让 Skill 充当 Privileged Signal，推理时把它完全丢掉。

6. 核心框架拆解：Distill Skills into Weights 的整体流程

前面概念讲了很多，接下来把训练框架完整地拆一遍。整体流程可以分成四个阶段：任务采样、信号注入、策略更新、蒸馏评估。

6.1 阶段一：任务采样与策略执行

先从任务分布中采样一批任务，使用当前模型（策略）生成执行轨迹。

比如任务是“修复一个 Python 单元测试失败”。模型会：

  1. 阅读测试失败日志；
  2. 定位被测代码；
  3. 生成修复建议；
  4. 修改代码；
  5. 重新运行测试。

这一整条轨迹都会被保存下来，作为后续蒸馏的数据。

在这一步，如果模型当前能力比较弱，生成轨迹的质量会比较差。但这并不致命，因为训练的目标不是“完美复制优秀轨迹”，而是“在训练信号引导下，逐步改进自己的轨迹”。

6.2 阶段二：注入 Privileged Skill Signal

在训练阶段，除了把轨迹作为训练数据，还要把抽象技能注入到模型中。

注入方式不是简单拼接到文本里，而是作为一种 Privileged Signal。具体可以理解为：模型在某个状态 s 时，我们会额外给它一个信号 z，这个 z 是对当前任务“应该怎么做”的抽象描述，例如“遇到单元测试失败，先检查断言语句，再检查被测函数返回值”。

这个 z 只有训练时存在，推理时不会提供。模型的优化目标从“学会从状态 s 映射到动作 a”，变成“在信号 z 的辅助下，学会从状态 s 映射到动作 a，并且最终脱离 z”。

这有点像课程学习：先扶着走，再松手。

6.3 阶段三：On-Policy 策略更新

得到新的训练数据后，使用类似 PPO 的目标函数进行策略更新。

关键的一点是，由于数据来自当前策略，更新时不需要担心数据分布偏移的问题。模型当前生成什么，我们就基于当前数据计算梯度并更新。更新完，旧数据直接丢弃，继续采样新数据。

这样做的代价是训练成本较高，因为每一步都要重新采样。但好处是训练信号与模型能力完全匹配，稳定性好很多。

6.4 阶段四：去掉 Privileged Signal 的蒸馏评估

训练完成后进入评估阶段。这时候不再提供任何 Skill 信号，直接让模型面对任务。

判断成功与否，不是看模型能不能复述技能规则，而是看模型能不能在“没有规则可读”的情况下，做出符合规则的行为。

比如：

  • 技能要求“每次提交前运行 pytest”，模型在推理时没有这条规则，但它学会了“改完代码自动想到要跑测试”，这才叫内化。
  • 技能要求“错误处理要用日志而不是直接 print”，模型在推理时能够自然地输出日志代码，而不是打印一堆调试信息，这也叫内化。

这个阶段是整个流程的设计核心：训练时怎么支持不重要，推理时表现好才重要。

7. 与 PPO、RLHF 的关系：不只是蒸馏，而是更高效的对齐

很多人可能已经意识到，这个框架和 RLHF 在流程上有相似之处。这里单独用一节讲清楚它们的关系。

7.1 它们共享 On-Policy 思想

RLHF 中使用的 PPO 是 On-Policy 算法，本文提出的框架也是 On-Policy Self-Distillation。两者都强调数据来自当前策略，都用奖励或信号指导模型更新。

但 RLHF 的奖励通常来自一个独立的奖励模型，而本文的 Privileged Signal 更像是一种“技能提示”，并不是显式打分。它给模型的不是“你做得好不好”，而是“这个场景下应该考虑哪些因素”。

7.2 它们是互补关系，不是替代关系

这篇文章提出的方法，更适合用来内化“过程性技能”，例如：

  • 代码审查规范；
  • 调试流程；
  • 工具调用习惯；
  • 特定领域知识的使用方式。

而 RLHF 更适合对齐“结果偏好”，例如：

  • 回答更安全；
  • 内容更有帮助；
  • 风格更像人。

所以更合理的使用方式是：先用 On-Policy Self-Distillation 把 Skills 蒸馏进模型权重，让模型具备稳定的领域能力，再通过 RLHF 做安全性和偏好对齐。两条路线并不冲突。

7.3 为什么 PPO 的 On-Policy 特性在这里很关键

如果只是用 Off-Policy 的历史数据做蒸馏，模型会很自然地“忘记”某些场景下的正确行为，因为旧数据无法覆盖新策略遇到的输入分布。

而 On-Policy 保证了模型每次更新后，都会重新回到任务环境中采样，数据分布始终与当前策略同步。这个特性，决定了蒸馏出来的技能是“活的”，不是“背下来的死知识”。

8. 这篇论文对 AI 工具开发者意味着什么

如果你不是研究强化学习的，这篇论文对你有什么用？我认为有以下几个实际意义。

8.1 对 Agent 框架开发者

当前很多 Agent 框架把 Skills 做成文本包，统一加载到上下文。短期没问题，但长期一定会遇到稳定性瓶颈。如果能把高频、高价值、低变异的 Skills 通过训练蒸馏成模型权重，Agent 的可靠性会大幅提升。

未来对 Agent 来说，技能的加载方式可能变成：

  • 超高频率、全局通用的技能 → 蒸馏进权重；
  • 中频、按项目使用的技能 → 以轻量文本或向量检索方式注入；
  • 低频、一次性任务 → 直接写 Prompt。

这是一个比较理性的分层方案。

8.2 对企业内部模型定制团队

企业如果打算微调一个领域模型，过去的方法是准备一批“问答对”或“指令对”，但这种数据很难传达“过程性技能”。

论文框架给了一个更实用的思路：让模型先在自己的环境里跑真实任务，记录完整轨迹，再把技能描述作为 Privileged Signal 注入，做 On-Policy 蒸馏。这意味着你不需要穷举所有场景，只需要定义好 Skills，让模型在任务中自己采样并迭代。

更关键的是，训练得到的是一个“在行为上具备该技能”的模型，而不是一个“能回答技能相关问题”的模型。两者的差别，对真实业务场景影响巨大。

8.3 对普通开发者

短期来看，普通开发者可能接触不到这种训练方案，但可以理解一个趋势：Skills 会从“提示词资产”慢慢变成“权重资产”。 未来你购买一个编程模型，可能不再需要自己拼接一堆技巧文档，因为模型本身已经内化了这些技巧。

这也会改变我们对模型能力的评估方式：不再只看基础跑分，还会看“它内置了哪些 Skills”。

9. 实操视角：如何用最小成本验证这套思路

论文训练框架看起来比较重，但我们可以用一个简化版本做思路验证。这里给出一个最小可行的实验设计，适合有微调经验的团队参考。

9.1 实验目标

验证“把技能蒸馏进权重”是否比“把技能写在 Prompt 里”更稳定。选一个边界清晰的技能，例如“Python 单元测试失败时的定位与修复流程”。

9.2 数据集构造

不需要人工构造太多 QA 对，而是准备一批“带测试代码的 Python 仓库”，步骤如下：

  1. 让模型读取一个 Python 仓库；
  2. 人为修改某段代码，使其导致测试失败；
  3. 记录模型观察失败日志、定位问题、生成修复代码的完整对话轨迹；
  4. 对轨迹中每个步骤，人工补充“该步骤的正确理由”，作为 Privileged Signal。

这一步人工成本会比较高，但如果只做一个小规模 Demo，几十条轨迹足够。

9.3 训练方式

如果有条件，用 LoRA 或 QLoRA 做微调即可，不必全量微调。

训练输入可以分为两种：

  • 一种是“无信号”的轨迹数据，代表模型当前的真实行为；
  • 另一种是“有信号”的轨迹数据，即每一步都附带技能信号。

LLM 训练时把它们混合，优化目标就是“模型在无信号时也能模仿有信号时的行为”。

9.4 评估方式

评测建议构造一组模型未见过的仓库。对照组与实验组分别按两种方式运行：

  • 对照组：上下文注入一套 Skill 文档，然后让模型修 bug；
  • 实验组：不给任何 Skill 文档，直接用蒸馏后的模型修 bug。

统计这两个组的修复成功率、平均修复步数、无效尝试次数。

如果实验组在“不读提示词”的情况下能达到甚至超过对照组的水平，就说明技能已经内化进了权重，瓶颈不在提示词，而在于训练覆盖度和信号质量。

10. 常见问题与理解误区

这个方向刚出来，容易产生一堆误解，我按常见程度列出来。

10.1 误区一：Skills 只能是 Prompt 文件

不正确。Skills 的本质是可复用能力，Prompt 只是其中一种载体。它也可以是一段训练数据、一组 reward 规则、或者是模型权重里的参数分布。论文标题就是在强调“别只把 Skills 当成 Prompt”。

10.2 误区二：蒸馏之后就不用写 Prompt 了

不是。蒸馏解决的是高频、稳定技能的泛化问题，但具体任务的意图表达仍然需要 Prompt。模型知道“怎么做 bug 定位”和“你要我定位哪个 bug”是两件事。前者可以内化，后者必须靠上下文。

10.3 误区三：On-Policy 就是在线学习

不完全等价。在线学习强调数据流是连续的，策略持续更新。On-Policy 强调的是“更新数据来自当前策略”，不要求数据流式到达。可以离线采样当前策略的一批数据，再批量更新，也是 On-Policy。

10.4 误区四：Privileged Signal 就是 RAG

区别很大。RAG 是在推理阶段把外部信息注入上下文，模型必须依赖这些信息才能回答。Privileged Signal 是只在训练阶段出现，推理阶段完全去掉，目标是让模型学会不依赖它。两个方向正好相反。

10.5 误区五：蒸馏是拿大模型教小模型

Self-Distillation 不是传统知识蒸馏。教师和学生是同一个模型，只是训练阶段多了 Privileged Signal，推理阶段去掉。更准确地说是“能力继承”或“行为自举”。

11. 深层问题：这种方法的风险和边界

任何技术方法都有局限，这篇论文的框架也存在几个值得观察的边界。

11.1 信号质量决定上限

如果提供的 Skill 信号本身写得不好，或者和真实任务的关联度不够，模型可能学不到任何有价值的东西。这跟写 Prompt 是一样的：你给模型一份烂文档，它不可能学会好行为。

这里的难点在于，Skill 信号不仅要有“正确性”，还要有“时机性”。同样一句话，在任务刚开始说和任务执行到一半说，效果完全不同。论文方法本质上是在解决“如何让模型在正确时机使用技能”，而 Privileged Signal 的设计正是为了提供这种时序辅助。

对实践者来说，这意味着不能简单把技能文档拿来就做蒸馏，必须结合轨迹中每个状态点，把信号放到正确的位置。

11.2 训练成本不低

On-Policy 的核心优势是数据匹配，核心代价就是采样成本高。每一轮更新都要重新采样，对于大模型来说，这比传统 SFT 贵得多。团队在采用这套方案时，需要评估投入产出比。

一个现实的做法是：先用离线数据做 SFT，让模型具备基础能力，再使用 On-Policy 蒸馏做进一步优化。这样能显著减少 On-Policy 阶段的迭代次数。

11.3 技能冲突如何处理

如果一个模型需要同时掌握多套 Skills，且这些技能之间存在矛盾的决策偏好，蒸馏过程如何处理？目前论文没有给出完美答案。

可能的方案是像 MoE（Mixture of Experts）那样，为不同技能分配不同的参数子空间，但在单一 Dense Model 上，冲突的解决更多依赖训练数据的设计。

11.4 可解释性下降

把技能写进 Prompt，用户至少能“看到”模型被灌输了什么规则。把技能蒸馏进权重，用户只能从模型行为上反推它学到了什么。这在需要审计和合规的场景下，可能是个障碍。

12. 给开发者的实践建议与学习路径

如果你对这个方向感兴趣，可以参考以下学习路径，不要一上来就啃完整篇论文。

第一步：跑通一个 PPO 或 GRPO 的 RLHF 最小示例

理解 On-Policy 最好的方法是实践。先找一个开源项目，比如 TRL、DeepSpeedChat 或 LLaMA-Factory，跑通一个最小的 RLHF 示例。这一步重点不是调优，而是理解“采样-更新-再采样”的循环结构。

第二步：理解 PPO 目标函数的关键设计

读 PPO 原文时，重点理解三个点：

  1. 重要性采样比；
  2. Clip 操作的作用；
  3. GAE 估计优势函数。

不需要推导所有公式，但要知道 Q、V、Advantage 之间的关系。

第三步：从 RLHF 迁移到 Skill Distillation

当你理解了 RLHF 的循环后，再回来看本文的框架，会觉得清晰很多：无非是把“奖励模型打分”换成“Privileged Skill Signal 引导”，把“偏好对齐”换成“技能内化”。

第四步：设计一个小规模实验

用 9.2 里的小实验，验证“技能蒸馏”与“Prompt 注入”在稳定性上的差异。这个实验不一定要训练一个很大的模型，LoRA 微调一个 7B 或 14B 模型就够。

第五步：关注工具链发展

随着 Cursor、Claude Code、Codex 等工具都在引入 Skills，未来一定会有更成熟的“Skills 蒸馏工具链”出现。现在深挖原理，后面用工具时才能知道每一步在做什么。

13. 总结：Skills 的终点是“会”，而不是“读”

回到标题：为什么要把 Skills 蒸馏进权重，而不是塞进 Prompt？

核心原因可以归结为三句话：

  1. Prompt 是外部依赖，本质是告诉模型怎么做，但模型不一定会照做；
  2. 权重是内部能力，本质是让模型真正会做，不需要每次推理都临时读规则；
  3. 通过 On-Policy Self-Distillation，可以在训练阶段利用 Privileged Signal 指导模型内化技能，在推理阶段完全不依赖这些外部信号。

这个思路对普通开发者的启示是：不要把所有经验都堆成提示词。 如果是高频、稳定、可复用、定义清晰的经验，更好的方式是寻找一种机制让它变成模型的默认行为。当 Skills 从“输入文本”变成“参数分布”时，Agent 的可靠性才会真正飞跃。

对于想深入研究的读者，建议按以下顺序阅读：先看 PPO 原文，再看 RLHF 的常见实现，然后回到这篇论文的 Self-Distillation 框架，最后可以自己动手设计一个技能蒸馏的小实验。把“技能”从提示词思维转换到权重思维，这一层认知更新，比论文里任何公式都更有价值。