最近很多做 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 的输出去蒸馏 studentstudent 在推理时完全不依赖 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-PolicyPPO 为什么是 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 输出序列的 logitsTeacher 输出文本用于后续 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_episodesbatch_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, temperature2.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 慢速跟随 student9. 工程实践建议与合规边界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 的差别。