最近很多做 LLM 训练和 Agent 应用的同学都在讨论一个问题：模型“学会”一个技能，到底应该让它记住一段话，还是把能力直接压进权重里？这篇论文的标题说得非常直白：Distill Skills into Weights, Not Prompts——把技能蒸馏进权重，而不是写进提示词。研究方向是把抽象技能当作特权信号，用 on-policy 自蒸馏的方式，让模型在训练阶段真正把技能内化，而不是推理时依赖那几句 prompt。
先说结论：这个方向最适合三类人，正在做强化学习训练、关心 Agent 长期泛化、或者被 prompt 不稳定折磨到想换思路的工程师。它不是在某个开源库里加一个功能，而是在给“技能如何固化进模型”提供一套训练范式。本文会把论文里的核心概念拆开讲清楚，包括什么叫抽象技能、什么是特权信号、为什么必须是 on-policy 的自蒸馏，以及如果你想复现或迁移这套思路，应该怎么设计训练流程、怎么验证效果、容易踩哪些坑。
1. 核心能力速览
| 能力项 | 说明 |
|---|---|
| 方法类型 | 模型训练范式 / 技能蒸馏方法，不依赖特定模型结构 |
| 核心思想 | 把技能以抽象形式作为特权信号参与训练，最终蒸馏进权重 |
| 主要目标 | 替代 prompt-based 技能，提升技能复用性、稳定性和泛化能力 |
| 关键技术 | On-Policy Self-Distillation、Privileged Signals、Student-Teacher 蒸馏 |
| 训练前提 | 需要可训练的生成模型，且具备一定强化学习或蒸馏基础 |
| 与 PPO 的关系 | 采用类似 on-policy 的训练逻辑，强调当前策略采样 |
| 推理开销 | 训练后推理不需要额外特权信号，也不依赖长 prompt 携带技能 |
| 适合场景 | LLM 能力增强、Agent 技能学习、RLHF/RL 训练、多任务泛化 |
| 不适合场景 | 小规模一次性任务、无训练资源的纯推理应用 |
| 显存与算力 | 取决于基座模型，论文未给出固定数值，需按实际训练配置评估 |
2. 为什么“写进权重”比“写进提示词”更值得关注
现在主流的大模型能力注入方式，本质上都是“说给模型听”。无论是 few-shot、system prompt、还是长篇的 instruction，模型的技能都依赖上下文窗口里的文字。这种方法上手快，效果通常也不错，但它有几个明显的天花板。
第一，提示词不稳定。同样一段说明，换一个模型版本，或者换一种措辞，效果可能完全不同。因为 prompt 是通过 attention 机制间接影响模型行为，模型并不“理解”技能背后的抽象规律，它只是在当前上下文里模仿。
第二，上下文长度限制。技能复杂时，需要写很长很细的说明。而实际业务中还需要塞入用户问题、工具返回结果、历史记录，上下文空间很快就不够用了。技能和业务数据挤在一起，互相干扰。
第三，提示词难以组合。模型如果掌握多个技能，把这些技能全部写进 prompt 会非常臃肿，而且技能之间可能冲突。你没有办法在推理时把“推理能力”和“工具调用能力”像模块一样拼装。
这篇论文的核心判断是：真正可靠的技能，应该沉淀在权重里。权重里的知识是隐式的、参数化的、可组合的。训练时把技能信息通过特权信号注入teacher模型，再用 teacher 的输出去蒸馏 student，student 在推理时完全不依赖 prompt 中携带技能描述，也能稳定表现出该技能。这就是标题里“Distill into Weights”的本质逻辑。
3. 关键概念拆解
3.1 技能（Skill）和提示词（Prompt）到底差在哪
论文里的“技能”是一个抽象能力单元，比如“按步骤拆解复杂问题”“在不确定时主动询问澄清”“根据搜索结果修正结论”。它不是某条具体的指令，而是一种可迁移的行为模式。
提示词则是技能的一种表达形式，把行为模式用自然语言写出来。问题在于，自然语言表达技能有很多信息损耗。同一句话换成不同语言、不同句式，模型的表现可能完全不同。而用权重表达技能，是把这种能力本身作为参数的一部分。反向传播时，损失信号会直接调整到让技能涌现的那部分参数上。
3.2 什么是特权信号（Privileged Signals）
特权信号这个概念来自 teacher-student 训练范式，并非这篇论文首创。核心思路是：训练时给模型看一些推理时看不到的信息，让模型学得更好，推理时再把这类信息移除。
在这篇论文里，抽象技能就是特权信号。训练阶段，模型可以得到技能标签、技能描述、甚至该技能对应的行为模式提示。推理阶段这些信号全部不可用。模型必须依靠训练时学到的权重，自己表现出这个技能。
这个设计非常关键。如果推理时还要输入技能标签，那本质上还是 prompt 方法。只有训练时用、推理时不用，才能逼迫技能真正进入权重。
3.3 自蒸馏（Self-Distillation）在这里的含义
常规蒸馏是强 teacher 教弱 student。自蒸馏的“自”体现在 teacher 和 student 来自同一个基础模型，teacher 是通过特权信号增强后的版本，student 是不依赖特权信号的版本。
换句话说，teacher 和 student 共享大部分参数结构，差异只在训练时的输入信息。Teacher 看到了“当前要调用某个技能”，知道“当前这一步应该这样走”，所以输出更稳定、更准确。Student 看不到这些信号，只能尽量模仿 teacher 的输出。训练结束后，student 就获得了把技能内化的能力。
这种设计比直接用人工标注数据做 SFT 更高效，因为 teacher 的输出是对齐了技能约束的，而不是简单记录某个回答。比纯 RLHF 也更省资源，因为蒸馏本身可以只做监督学习。
3.4 为什么必须是 On-Policy，PPO 为什么是 On-Policy
热搜词里有一条是“为什么说 PPO 是 on-policy”，这篇论文也确实依赖了 on-policy 的性质。
On-policy 的含义是：训练数据必须来自当前策略的采样结果。PPO 中，每一步梯度更新使用的轨迹，都是由“更新前那个策略版本”生成的。策略一旦更新，旧轨迹就不能再直接用于训练，否则就变成 off-policy，需要额外做重要性采样校正。
在自蒸馏场景里，on-policy 的意义在于：student 在蒸馏过程中策略不断变化，输入数据分布也必须跟随当前策略。如果使用旧模型生成的静态数据做蒸馏，student 学到的技能会和自己的实际推理分布不匹配。等到推理时遇到自己生成的状态分布，技能反而无法触发。
具体到本论文的流程，大致是：student 先和环境或任务交互，得到一条轨迹，然后 teacher 基于这条轨迹生成蒸馏目标，student 再在这个分布上做梯度更新。循环往复。每一步都确保 student 学习的是“当前自己会遇到的情况”，而不是“过去的自己遇到的情况”。这种对齐方式对技能巩固非常关键。
4. 训练流程拆解：从抽象技能到权重固化
从一个可复现的角度理解，这套方法可以抽象成五个阶段。
4.1 定义技能库
首先需要有一个技能库。技能不是粗粒度任务，而是可复用、可判定的行为模式。例如在与工具交互的 Agent 场景里，技能可以是“失败后重试前先修改请求参数”“当工具返回空结果时尝试换一个查询词”“在连续失败时主动告知用户并提供备选方案”。
这一步是人工投入最大的地方。技能定义好坏直接决定蒸馏效果。技能太粗，模型学不到具体行为；技能太细，迁移性差，变成死记硬背。
4.2 构造带特权信号的训练语料
对每一条训练样本，需要附带一个特权信号字段。这个字段可以是一个技能标签、一段技能行为描述，甚至可以是 teacher 模型的隐状态。关键是它与当前样本的学习目标直接相关。
训练语料不只有“问题到答案”，还可以有“状态到动作”的决策样本。对于 Agent 任务，一条样本通常是：
- 当前对话历史
- 当前可用工具
- 当前应当激活的技能
- 理想的模型输出（或动作）
其中“应当激活的技能”和“理想的模型输出”都是特权信号，推理时不会出现。
4.3 使用当前策略进行轨迹采样
这是 on-policy 最关键的一步。使用当前 student 策略（注意，不是旧模型）对任务进行采样，得到一批轨迹。轨迹中的错误和偏差是重要财富，因为 student 需要知道自己在真实分布下容易犯什么错。
采样数量需要和训练 batch 匹配。采样太少，分布估计不准；采样太多，训练效率下降。实际训练中，这类 on-policy 自蒸馏通常需要在采样和训练之间做流水线并行。
4.4 Teacher 生成蒸馏目标
得到轨迹后，让 teacher 模型基于轨迹内容和特权信号生成“标准输出”。Teacher 能看到 student 看不到的技能信息，所以输出质量更高。
蒸馏目标可以是：
- Teacher 输出序列的 logits
- Teacher 输出文本用于后续 SFT 式训练
- Teacher 对每个 token 的软标签
使用 logits 做软标签，信息量最大。但如果 teacher 和 student 词表不一致，就退化为文本蒸馏。
4.5 用蒸馏损失更新 Student
训练损失通常由两部分组成：
- 任务目标损失：让 student 输出正确回答或正确动作
- 蒸馏损失：让 student 的输出分布接近 teacher 的输出分布
蒸馏损失可以用 KL 散度或者简单的最小二乘。为了防止 student 过度贴近 teacher 而导致自身探索能力下降，通常会设置蒸馏损失的权重系数，或者使用 temperature 平滑 teacher logits。
一个通用伪代码如下：
# 伪代码：On-Policy Self-Distillation with Privileged Skills # 实际实现需根据模型框架调整 for iteration in range(total_iterations): # 1. On-policy 采样：使用当前 student 策略与环境交互 trajectories = student.sample_trajectories(task_env, num_episodes=batch_size) # 2. 为每条轨迹注入特权信号（技能标签等） privileged_trajectories = add_privileged_signals(trajectories, skill_library) # 3. Teacher 基于特权信息生成蒸馏目标 with torch.no_grad(): teacher_logits = teacher(privileged_trajectories) # 4. Student 基于无特权输入计算出自己的 logits student_logits = student(trajectories) # 5. 任务损失 + 蒸馏损失 task_loss = compute_task_loss(student_logits, trajectories.ground_truth) distill_loss = kl_divergence(student_logits, teacher_logits, temperature=2.0) loss = task_loss + lambda_distill * distill_loss # 6. 更新 student 参数 optimizer.zero_grad() loss.backward() optimizer.step()这个流程里，teacher 本身也可以随训练更新。如果 teacher 一直在进步，蒸馏效果会更好。但要注意 teacher 的更新节奏，否则容易训练不稳定。
5. 与 Prompt-based 技能注入的对比
| 对比维度 | Prompt-Based 技能注入 | Weights-Based 技能蒸馏 |
|---|---|---|
| 技能存储位置 | 上下文中的自然语言 | 模型权重参数 |
| 推理开销 | 大量 token 消耗，计算慢 | 无额外 token，推理与普通模型一致 |
| 技能稳定性 | 依赖措辞、模型版本，波动大 | 固化后相对稳定 |
| 多技能共存 | 互相干扰，上下文拥挤 | 可组合，参数空间更大 |
| 技能可解释性 | 可通过 prompt 直观查看 | 需要额外探针或评估集 |
| 训练成本 | 低，无需训练 | 高，需要训练和采样 |
| 更新单技能 | 直接改 prompt 即可 | 需要重新训练或增量训练 |
| 跨模型迁移 | 基本可迁移，但效果不同 | 无法直接迁移，需要重新蒸馏 |
从这张表看，prompt 方法的核心优势是低成本和灵活性。对于一次性任务、快速demo、需要频繁更换 skill 的场景，prompt 方法依然是首选。但如果你追求长期稳定表现、多个技能组合使用、减少上下文占用，把技能蒸进权重明显是更优解。
6. 效果验证思路：如何判断技能真的进了权重
因为实际训练效果需要看具体数据，这里给一套通用验证方案，适合你在自己的任务上复现。
6.1 定义技能触发评估集
针对每个技能准备一组专门测试样本。样本要覆盖三种情况：
- 需要显式提示该技能才能做对的情况
- 提示词不完整或干扰语境下，本应能触发的情况
- 其他技能叠加时，本技能不应被错误触发的情况
评估集的构造，直接决定你能否判断蒸馏的成败。
6.2 对比三组模型
为了科学验证，至少要训练三组模型：
- 基础模型：什么都不做
- Prompt 增强模型：推理时在 prompt 中写入技能描述
- 蒸馏模型：训练时使用特权信号，推理时不写技能描述
三组模型在同样评估集上对比准确率、稳定性、token 消耗。如果蒸馏模型的准确率接近或超过 prompt 增强模型，并且推理 token 更少，说明技能成功固化。
6.3 做泛化测试
技能蒸馏的一个优势是更好的泛化。可以在训练中刻意排除一类任务变体，蒸馏后测试这一类变体。如果模型仍然表现出该技能的行为模式，说明学到的是抽象技能，而不是死记硬背的任务映射。这类泛化测试在论文中经常被视为衡量技能抽象程度的重要指标。
7. 落地实现的关键细节
7.1 基座模型选择
这套方法要求模型具备较强的行为多样性和上下文跟随能力。基座模型太弱，teacher 的蒸馏目标本身质量就低，无论怎么蒸馏都学不到好技能。建议从 7B 以上通用对话模型开始测试。训练技术栈可选用 PyTorch + HuggingFace Transformers、DeepSpeed、以及常见的强化学习框架。
7.2 Teacher 的设计不能过于完美
Teacher 使用特权信号，但不意味着 teacher 输出要完美。实际上，teacher 只需要比 student 更好一点，就能形成有效的梯度信号。如果 teacher 太强，student 会学到“模仿一个完美老师”，而丢失探索能力，在开放场景泛化反而变差。
7.3 蒸馏损失的权重和温度
蒸馏损失权重过大会导致 student 失去自我创新能力，过小则技能学不进去。温度参数控制 teacher 输出的平滑程度。温度越高，分布越平滑，越能保留 token 之间的相对关系。通常温度范围在 1.0 到 4.0 之间，具体需要小范围扫描。
7.4 On-Policy 采样的稳定性
On-policy 采样有一个天然问题：训练中策略会突变，导致采样分布剧烈变化。建议使用 Small KL Penalty 约束 student 每次更新的步长，减小训练震荡。参考 PPO 的 clip 机制，限制单次更新幅度。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 蒸馏后技能没有触发 | 技能定义过粗，学生没学到行为 | 检查评估集，观察模型输出是否包含技能行为 | 细化技能标签，增加特权信号信息量 |
| 技能触发不稳定 | student 过拟合 teacher 的某些 token 模式 | 对比不同 seed 下的表现 | 增加蒸馏温度，降低蒸馏损失权重 |
| 训练不收敛 | 蒸馏损失权重太大或学习率太高 | 观察训练损失曲线和 KL 值 | 调低学习率，或给 KL 加 clipping |
| 技能迁移到新任务失败 | 训练中任务变体太少 | 检查训练集多样性 | 增加不同场景、不同工具的任务采样 |
| 训练后模型能力下降 | 任务损失和蒸馏损失冲突 | 分别查看两个损失变化 | 调整损失权重，或分阶段训练：先任务后蒸馏 |
| On-policy 采样成本过高 | 每次迭代都重新采样，效率低 | 统计采样耗时占比 | 使用多个环境并行采样，或做采样缓存 |
| Teacher 被 Student 反超 | Student 学到了更多，teacher 不再够格 | 检测两者在某任务上的输出质量 | 定期更新 teacher 的蒸馏目标，或让 teacher 慢速跟随 student |
9. 工程实践建议与合规边界
9.1 工程实践建议
- 先小参数验证完整流程。不要一开始就用 70B 模型做全量 on-policy 自蒸馏，代价太高。先用 1B 或 3B 模型跑通采样、特权信号注入、Teacher 蒸馏和三组评估对比。流程验证没问题再放大。
- 把技能库和代码解耦。技能本身是配置文件，训练代码是通用框架。这样加一个技能不需要改训练代码，只需要新增技能定义和对应评估集。
- 保存训练轨迹和蒸馏目标。这些数据是排查效果问题的关键。如果某个技能蒸馏失败，回查当时 teacher 和 student 在每条轨迹上的表现，能快速定位到底是采样问题还是技能定义问题。
- 采用增量蒸馏。不需要一次把所有技能都灌进去。可以先让模型稳定掌握 1-2 个技能，再增量添加。增量时保留旧技能验证集，防止新技能覆盖旧技能，造成灾难性遗忘。
- 建立技能冲突检测。当两个技能对同一类状态产生相反的指导时，需要提前检测并决策，否则模型输出会在两个模式间震荡。
9.2 合规边界
技能蒸馏是一种模型训练和参数修改行为。使用任何数据集、技能定义、基础模型时，都需要遵守对应开源许可和数据授权范围。如果训练数据涉及真实用户对话、隐私信息、个人偏好，需要先完成匿名化和脱敏处理。如果技能用于生产系统、内容生成或决策辅助，商用前需要人工复核技能触发边界和失败模式。涉及人脸、声音、版权文本或受保护内容的技能，必须严格确认授权后再做蒸馏训练。另一个值得注意的问题是：技能蒸馏会显著增加模型的可复用性和隐蔽性，如果基础模型或数据集禁止二次训练、禁止参数分发，需要额外注意合规边界。
10. 总结与下一步
这篇论文提供的不是一个现成的模型权重，而是一套训练范式。它的核心价值在于：把技能从“推理时通过 prompt 告诉模型”变成“训练时通过特权信号让模型内化”。从长期看，这种思路更适合技能叠加、跨任务泛化和低延迟推理场景，也会是 Agent 模型训练中一个重要的演进方向。
如果你准备尝试，最值得先做的是：选一个小模型，定义 2-3 个非常明确的技能，用 on-policy 自蒸馏把训练流程跑通，再和 prompt 方案在你自己业务评测集上对比 token 消耗、稳定性和准确率。最容易踩的坑有三个：技能定义太模糊、蒸馏损失权重失衡、采样分布和训练分布不一致。建议在做大模型全量训练之前，先把这三个问题用最小实验验证清楚。
后续可以沿着三个方向继续扩展：多技能组合蒸馏、终身学习式的增量技能固化、以及把这套范式接入现有 RLHF 流水线，让技能蒸馏和偏好对齐同时进行。这个方向还处在方法演进阶段，但思路本身足够清晰，值得持续关注。
建议收藏备用。等手头有预算和 GPU 资源时，直接拿小规模任务做对比实验，你就能直观感受到 weights-based 技能比 prompt-based 技能更稳定、更省 token 的差别。
