#On-Policy Distillation：从模型压缩到 Agent 自我进化的蒸馏范式

#一句话核心结论

On-Policy Distillation（OPD）最重要的变化不是“蒸馏对象变了”，而是“蒸馏发生的位置变了”：它不再只让学生模型模仿教师模型预先生成的静态数据，而是让学生先在自己的行为分布上暴露错误，再由教师、奖励模型、验证器或人类反馈提供密集监督，最后把这些纠正重新蒸馏回模型。

因此，OPD 可以被看作几条路线的交汇点：

1. 它继承了传统知识蒸馏的稳定性和工程可控性；
2. 它继承了 on-policy RL 贴近真实部署分布的优点；
3. 它避免了 RL 只提供稀疏 reward 的低效问题；
4. 它天然适合 personal agent / self-evolving agent 中的真实用户反馈闭环。

换句话说，OPD 不只是一个“小模型学大模型”的技巧，而是一个更一般的机制：把模型在真实使用中获得的经验、错误和反馈，转化为可训练的密集监督信号。

#1. 为什么这个方向突然重要？

过去“蒸馏”通常被理解为模型压缩：用一个更大的 teacher 生成标签或 soft logits，让一个更小的 student 模仿。这个视角在分类模型时代很自然，在 LLM 时代也延续到了 instruction tuning、rationale distillation、CoT distillation 等工作中。

但 LLM 和 Agent 带来了一个更严重的问题：模型不是一次性分类器，而是自回归地生成长序列，并且在生成过程中不断进入自己制造出来的上下文状态。

这导致传统 off-policy distillation 有一个结构性缺陷：

学生模型在训练时看到的是 teacher 常去的状态；但在推理时，它进入的是自己会去的状态。

如果学生前面犯了一个小错，后续上下文就会偏离 teacher 轨迹。越是长链推理、长上下文、工具调用、多轮 agent 任务，这个分布偏移就越严重。

Thinking Machines Lab 在 2025 年的博客《On-Policy Distillation》中用一个很清晰的二维框架总结了这个问题：

这张表基本解释了 OPD 为什么会重新变热：它试图结合两边的优点——既像 RL 一样在学生自己的行为分布上训练，又像蒸馏/SFT 一样提供 token-level 或 step-level 的密集反馈。

#2. 从传统蒸馏到 on-policy distillation：问题是如何一步步被逼出来的

#2.1 第一阶段：传统知识蒸馏——压缩 teacher 的输出分布

经典知识蒸馏可以追溯到 Hinton 等人的 Distilling the Knowledge in a Neural Network。核心思想是：teacher 的 soft distribution 比 hard label 包含更多信息，student 学这个分布可以比只学 one-hot 标签更有效。

在 LLM 时代，这个思想自然扩展为：

• teacher 生成指令数据；
• teacher 生成 reasoning rationale；
• teacher 生成多轮对话；
• student 对这些 teacher trajectories 做 SFT。

代表工作包括：

• Sequence-Level Knowledge Distillation（Kim & Rush, 2016）：从 token/class-level 蒸馏走向 sequence-level 蒸馏；
• Distilling Step-by-Step：让小模型同时学习答案和 reasoning rationale；
• 各类 instruction distillation / CoT distillation 数据集。

这一阶段解决的是：如何把大模型能力迁移到小模型，或者把昂贵模型的行为变成便宜模型的训练数据。

但它暴露出新问题：学生学到的是 teacher 分布，而不一定是自己推理时真正会遇到的分布。

#2.2 第二阶段：off-policy distillation 的分布错配

在自回归生成里，早期 token 的小偏差会改变后续所有条件分布。teacher 轨迹通常是高质量、干净、连贯的，而 student 推理时可能生成不完整、错误、跑偏的中间状态。

如果训练数据永远来自 teacher，那么 student 很少学到：

• 自己算错一步后怎么恢复；
• 自己输出格式偏了后怎么纠正；
• 自己进入低质量 reasoning branch 后怎么回到正确路径；
• 自己工具调用失败后该如何修复。

这和 imitation learning 中的经典问题非常相似：只在专家轨迹上行为克隆，会导致 learner 一旦偏离专家轨迹就不知所措。DAgger 的解法是：让 learner 自己访问状态，再请 expert 给这些状态打标签。

OPD 在 LLM 中做的事情，本质上就是一种 DAgger 化的蒸馏：

student rollout → teacher / verifier / human evaluates or corrects → student trains on its own visited states

这也是 Agarwal 等人在 On-Policy Distillation of Language Models: Learning from Self-Generated Mistakes 中提出 Generalized Knowledge Distillation（GKD）的核心动机：不要只在固定输出序列上蒸馏，而要让学生在自生成序列上获得 teacher feedback。

#2.3 第三阶段：RL 的 on-policy 优点与 sparse feedback 问题

如果说 off-policy distillation 的问题是“不够贴近学生自己的分布”，那么 RL 的优势恰好在于 on-policy：模型采样自己的答案，环境或 reward model 给反馈，模型据此更新。

但 RL 在 LLM 上的问题也很明显：reward 通常是稀疏的。

例如一个数学推理题，模型生成了 2000 个 token，最后答案错了。RL 只告诉它：这条 trajectory 不好。可是模型真正需要知道的是：

• 是哪一步 algebra 错了？
• 是理解题意错了？
• 是计算错了？
• 是最后格式错了？
• 还是中间某个分支选择错了？

Thinking Machines Lab 的说法是：RL 每个 episode 大致只提供 bits 的反馈，而 distillation 可以在每个 token 上提供 bits 的密集监督。也就是说，RL 更贴近真实分布，但监督太稀疏；SFT/蒸馏监督密集，但又不贴近 student distribution。

OPD 的位置就很自然：在 student 自己生成的 trajectory 上，由 teacher 提供密集监督。

#3. On-Policy Distillation 的基本闭环

一个典型 OPD loop 可以写成：

当前 student policy π_t
  ↓
在任务分布上采样 student trajectories
  ↓
teacher / verifier / reward model / human 对这些 trajectories 提供反馈
  ↓
构造 token-level、step-level、sequence-level 或 preference-level 监督
  ↓
用 SFT / KL / DPO / rejection sampling 等方式更新 student
  ↓
得到 π_{t+1}，继续迭代

其中“teacher”不一定是一个大模型，也可能是：

• 更强 LLM；
• reward model；
• verifier；
• 单元测试；
• 搜索算法；
• 人类 verbal feedback；
• 带 privileged information 的同一个模型；
• agent 自己成功完成任务后的轨迹。

因此 OPD 不是单一算法，而是一类训练范式。

#4. 技术谱系：OPD 可以有几种不同形态

#4.1 Token-level teacher distillation

这是最接近传统 KD 的形式：student 先生成序列，然后 teacher 在 student 的 prefix 上给出 next-token distribution，student 最小化与 teacher 的 KL。

x ~ task distribution
ŷ ~ π_student(.|x)
teacher gives p_teacher(token | x, ŷ_{<t})
student minimizes KL / reverse KL / JS on visited prefixes

优点是反馈细粒度，能告诉 student “在你自己走到的这个上下文里，teacher 会怎么走”。缺点是 teacher logits 成本高，闭源模型通常拿不到完整分布。

Agarwal 等人的 GKD 就是这一类的重要代表。它明确指出 autoregressive sequence models 中的 KD 存在训练-推理分布错配，因此引入 student-generated outputs，并允许不同 KL 方向与混合策略。

#4.2 Sequence-level correction distillation

更工程化的方式是：让 student 生成答案，再让 teacher 改写、纠错或给出更优答案，然后 student 对 corrected answer 做 SFT。

student answer → teacher correction / rewrite → SFT on corrected answer

它的优点是简单，不需要 teacher logits，适合闭源 API。缺点是监督不如 token-level 精细，而且 teacher 可能过度改写，使训练信号偏离原始任务。

很多实际系统会使用这种形式，因为它便宜、直观、容易落地。

#4.3 Preference-based on-policy distillation

如果任务没有唯一正确答案，可以让 student 采样多个候选，然后由人类、judge model 或 reward model 排序，再用 DPO/IPO/SimPO/KTO 等 preference objective 更新。

student samples y1, y2, ..., yn
judge ranks / selects
student learns preference pairs

DPO 本身不必然是 on-policy；如果 preference pairs 来自固定数据集，它就是 offline preference learning。但如果候选回答来自当前 student policy，就变成了 online / on-policy preference distillation。

这类方法是 OPD 和 RLHF 之间的重要桥梁：它使用 on-policy 数据和偏好反馈，但避免了 PPO 式 policy gradient 的复杂性。

#4.4 Verifier / reward-filtered SFT

在数学、代码、工具调用等任务里，我们经常有 verifier：

• 数学题可以检查答案；
• 代码题可以跑单元测试；
• tool-use 可以看最终状态；
• browser agent 可以看任务是否完成。

这时可以采用：

sample many trajectories → verifier filters successful ones → SFT on successful trajectories

ReST（Reinforced Self-Training）就是这一范式的重要代表：模型生成样本，用 reward 过滤/排序，再通过离线训练改进 policy。它不像 PPO 那样直接用 reward gradient，而是把 reward 信号转化成训练数据。

这也是很多人把 OPD/OPSD 看作“RL 平替”的原因：它保留了 reward-guided improvement，但更新方式更像监督学习。

#4.5 Agent trajectory distillation

对 Agent 来说，训练对象不只是最终回答，而是完整 trajectory：

observation → thought → action/tool call → result → reflection → next action

如果一个 coding agent 或 browser agent 在真实任务中失败，teacher/human 可以指出：

• 哪一步工具调用错了；
• 哪个假设不该做；
• 哪个文件不该改；
• 哪个测试应该先跑；
• 哪个用户意图被误解了。

这些反馈可以转化为：

• 更好的 trajectory；
• preference pair；
• critique + revision；
• reusable rule；
• personal adapter 的训练样本。

这也是 OPD 与 personal agent / self-evolving agent 的连接点。

#5. 从 OPD 到 OPSD：为什么“自蒸馏”开始变热

OPD 中 teacher 往往是外部更强模型；OPSD（On-Policy Self-Distillation）则进一步问：能不能不依赖一个固定外部 teacher，而让模型利用自己的能力、privileged information、短上下文优势、验证器或成功轨迹来指导自己？

2026 年初出现了一批直接以 OPSD 为关键词的工作：

这批工作共同说明：OPSD 的核心不只是“自己教自己”，而是在学生当前能力边界附近构造更密集、更贴合自身分布的训练信号。

如果说 OPD 解决的是 teacher-student 分布错配，那么 OPSD 进一步试图解决 teacher 依赖、训练成本和持续学习的问题。

#6. 为什么 OPD 被看作 RL 平替？

很多 LLM 后训练场景中的 RL 目标可以抽象为：

让模型在自己会生成的东西里面，多生成好的，少生成坏的。

RLHF/PPO 的方式是：

policy samples → reward → policy gradient update

OPD/OPSD 的方式是：

policy samples → reward / teacher / human feedback
→ construct better targets / rankings / corrections
→ supervised or preference update

这不是严格意义上的 RL 替代，因为它不一定做 credit assignment，也不一定有真正探索。但它在很多 LLM 任务中非常有吸引力：

1. 训练更稳定：SFT/DPO/KL distillation 比 PPO 更容易调；
2. 反馈更密集：teacher 可以逐 token、逐步骤提供信号；
3. 数据可复用：同一批 prompt 可以多次采样、多次蒸馏；
4. 工程链路更简单：采样、打分、筛选、训练都容易模块化；
5. 适合强 verifier 任务：math/code/tool-use 中 reward 可以变成监督数据。

Thinking Machines Lab 的实验也给了一个直观判断：在他们的数学推理设置中，从 RL-trained teacher 回蒸馏到 base student 时，on-policy distillation 可以用明显更少的梯度步数恢复 teacher policy，博客中称其带来数量级的 compute efficiency 提升。

但这并不意味着 RL 不再重要。OPD 更像是：当我们已经有可靠 teacher/verifier/reward，可以把“好坏”转成密集监督时，它是比 RL 更便宜、更稳定的 policy improvement 方法。

对于真正需要探索、长期信用分配、环境交互发现新策略的场景，RL 仍然不可替代。

#7. OPD 与“模型合版”：从参数合并到行为合并

推文里提到 OPD 已经成为“大厂模型合版”的流行方式，这个判断很有意思。

所谓“模型合版”，可以理解为把多个模型、多个版本、多个专家能力整合进一个模型。常见路线有：

1. 参数合并：model soup、task arithmetic、TIES、DARE 等；
2. 路由/MoE：不同任务调用不同 expert；
3. 数据混合再训练：把各领域数据混起来继续训练；
4. 蒸馏合版：用多个 teacher / judge / expert 生成反馈，让一个 student 学综合行为。

OPD 在这里的优势是：它合并的是行为，而不是参数。

这很重要，因为现实中的 teacher 可能：

• 来自不同架构；
• 有些是闭源 API；
• 有些是 specialist model；
• 有些是 reward model/verifier；
• 有些是旧版本模型；
• 有些是内部专家系统。

参数合并要求模型结构和参数空间兼容，但 OPD 不需要。student 自己先生成答案，然后不同 expert 在 student 的行为分布上打分、纠错、改写或投票，最后 student 吸收这些反馈。

这让模型合版变成一个持续过程：

new model / new expert / new product feedback
→ evaluate current student behavior
→ generate corrections/preferences
→ distill into next version

当然风险也很明显：

• 多 teacher 之间可能冲突；
• 不同 expert 的风格和价值观不一致；
• student 容量不足时会出现能力坍缩；
• 数据选择会决定最终模型的能力边界；
• 如果只蒸馏表面风格，可能复制 confidence 而不是复制 correctness。

这也是为什么 OPD 不是简单“把几个模型输出混起来 SFT”，而需要仔细设计 teacher routing、反馈类型、冲突解决和 evaluation。

#8. Verbal Feedback：OPD 在 personal agent 中最自然的入口

personal agent 的核心目标是：越用越懂用户。

真实用户反馈往往不是 reward number，而是自然语言：

• “下次先给结论。”
• “这个格式我不喜欢。”
• “你刚才误解了我的意思。”
• “这个项目里不要这么做。”
• “以后遇到这种情况直接执行，不要再问我。”

这些反馈有三个特点：

1. 它发生在 agent 自己真实产生的行为之后，因此天然 on-policy；
2. 它通常是 dense 的，能指出具体问题；
3. 它既可能是偏好，也可能是事实纠错、工作流约定或安全边界。

因此，verbal feedback 可以被看作 personal agent 场景下最重要的 OPD 信号来源。

一个可能的闭环是：

agent action / answer
→ user verbal feedback
→ classify feedback type
→ produce corrected response / preference pair / rule memory
→ update memory or train adapter
→ regression test
→ deploy back to user's agent

这里有三层学习：

Reflexion 和 Self-Refine 代表了“不更新参数”的 verbal feedback 路线：模型通过反思和自我修改在 inference-time 改进。OPD/OPSD 则进一步问：能不能把这些反思和用户反馈固化进模型或个人 adapter？

这对个人 AI 很关键。否则 agent 每次都只是把反馈塞进上下文，长期来看会受到 context length、检索质量和记忆污染的限制。真正的 self-evolution 需要把一部分稳定反馈压缩进行为参数或更结构化的技能库。

#9. Self-evolution：OPD 是“从经验到参数”的桥

许多 self-evolving agent 都有类似闭环：

generate → evaluate → reflect → improve → store

但如果只 store 到 memory，系统更像“有笔记的 agent”；如果能 distill 回模型、adapter 或可执行技能库，才更接近“会成长的 agent”。OPD 在这里承担的是最后一步：

experience / feedback / successful trajectory → training signal → updated policy

这可以解释为什么最近 personal agent、self-evolution、agentic RL 的讨论会重新带火 OPD/OPSD：

• Agent 真实部署会产生大量 on-policy trajectories；
• 用户和环境会给出自然反馈；
• 这些反馈不一定适合直接做 RL；
• 但很适合转成纠错样本、偏好对、成功轨迹和过程监督；
• 再通过 OPD/OPSD 蒸馏进模型、adapter 或技能库。

关键在于区分四个层级：

因此，memory 让 agent 记得发生过什么，skill 让 agent 显式复用流程，而 distillation 改变的是模型下次行动时的默认行为分布。对于长期 agent 来说，这三者不是替代关系，而是分工关系：memory 存事实，skill 存流程，distillation 改行为习惯。

对 coding agent 来说，一个典型例子是：

agent 修改代码 → 测试失败 → 读取日志 → 定位原因 → 修复成功
→ 总结失败原因
→ 形成“错误轨迹 vs 修复轨迹”训练样本
→ 未来遇到类似 repo / bug / 工具链时更少犯同样错误

这比传统 RL 更符合软件工程任务的反馈形态。测试结果、编译错误、lint 报告、用户 review、代码 diff 都是结构化但不连续的反馈；它们很难直接压缩成一个稳定标量 reward，却很适合通过 distillation 被吸收。

一次成功/失败轨迹可以被拆成多种训练信号：

1. 成功轨迹 SFT：把最终成功路径清洗成“问题 → 正确分析 → 正确 patch / action sequence”；
2. 偏好对：把失败轨迹作为 rejected，把修复轨迹作为 chosen；
3. 过程监督：把“复现错误 → 读 stack trace → 定位 schema → 最小修改 → 回归测试”作为 step-level target；
4. 工具调用蒸馏：学习何时搜索、何时读文件、何时跑最小测试、何时跑全量测试；
5. 反事实纠错样本：学习“不要为了测试通过而吞异常 / 删除断言 / 大范围重构”。

所以 self-evolving coding agent 的完整学习闭环不是简单的：

成功 +1，失败 0

而更像：

1. Agent 执行真实任务
2. 保存完整轨迹：prompt、tool calls、diff、测试输出、用户反馈
3. 自动评价 outcome：测试是否通过、CI 是否通过、review 是否接受
4. 轨迹切分：定位关键失败点、关键修复点、关键决策点
5. 生成训练样本：SFT、preference pair、process supervision、tool-use correction
6. 过滤低质量样本，避免 reward hacking
7. 微调模型、adapter 或更新技能库
8. 在 held-out repos / regression tasks 上验证
9. 部署新 policy，继续收集 on-policy trajectories

用公式化语言写，就是：

π_t executes tasks
→ trajectories τ_t
→ evaluator filters and diagnoses τ_t
→ distiller constructs D_sft, D_pref, D_proc
→ train π_{t+1}
→ evaluate and deploy

这也是为什么 OPD/OPSD 对 personal agent 和 coding agent 尤其重要：真实部署不只是产生“数据”，而是产生当前模型自己的错误分布。互联网预训练数据告诉模型“别人怎么写代码”，而 on-policy agent trajectories 告诉我们“这个模型自己会在哪里犯错”。后者对持续改进更直接。

#10. 现有工作是怎么做的：从写笔记到蒸馏参数

如果把现有 self-evolving agent / OPD 相关工作放在一条演化线上，可以分成三类。

#10.1 第一类：经验外化，agent 会写笔记，但不更新参数

这一类工作的形式是：

agent 做任务
→ 失败/成功
→ 反思或归纳
→ 写入 memory / lesson / skill library
→ 下次检索使用

代表工作包括 Reflexion、ExpeL 和 Voyager。

Reflexion 把失败经验写成 verbal memory。它的流程是：

Actor 执行任务
→ Evaluator 判断成功/失败
→ Self-reflection 生成自然语言反思
→ 存入 memory
→ 下一次尝试时放进 prompt

例如模型失败后总结：“我之前失败是因为没有检查边界条件，下次应该先验证输入格式。”这能改善后续尝试，但本质上是：

experience → verbal reflection → context

不是：

experience → training signal → parameter update

ExpeL 更进一步，从多个任务经验中归纳 reusable lessons。它不是只为单个任务写 reflection，而是比较成功和失败案例，总结出跨任务经验。例如在 WebShop 或 ALFWorld 环境里总结“不要只根据标题判断商品”“找不到物体时系统性搜索所有房间”。它证明了 agent experience 可以自动结构化，但仍然是外部 lesson memory。

Voyager 则把经验固化成可执行 skill library。它在 Minecraft 中不断生成、验证并保存代码技能，例如 mineDiamond()、craftIronPickaxe()、exploreCave()。这比纯语言 memory 更强，因为 skill 是可执行的；但它仍然是外部能力库，不是模型参数成长。

所以这一阶段的贡献是：证明 agent 的经验可以被自动总结和复用。 局限是：经验没有进入模型参数，模型默认行为没有真正改变。

#10.2 第二类：self-training / distillation，把模型自己的输出筛选后重新训练

第二条线更接近 OPD。核心流程是：

模型生成候选
→ evaluator / verifier / reward 过滤
→ 保留正确或高质量样本
→ 用这些样本继续训练模型

代表工作包括 STaR、ReST、ReFT。

STaR 的做法是：模型先生成 reasoning rationale 和答案，如果答案正确，就保留 rationale；如果答案错误，则给正确答案让模型重新生成 rationale。然后用这些 rationale fine-tune 模型，迭代进行。抽象成：

current model → generated reasoning traces
→ correctness filter
→ supervised fine-tuning
→ improved model

这已经非常像 OPD：数据来自当前模型，正确性过滤提供反馈，最终更新参数。只是 STaR 主要处理短轨迹 reasoning，而不是复杂 agent 环境。

ReST 的模板更通用：

Grow: 当前 policy 生成很多样本
Improve: 用 reward model 或 evaluator 过滤高质量样本，再 fine-tune policy

也就是：

π_t 生成数据 → reward/filter 选择 → SFT 更新得到 π_{t+1}

它不是直接 PPO，而是把 reward 用作筛选器，再做监督学习。这种 generate-filter-train 正是许多 OPD/OPSD 系统的工程核心。

ReFT 则强调多路径 reasoning：对同一个问题采样多个 reasoning paths，根据最终答案筛选正确路径，再做 reinforced fine-tuning。对应到 agent，就是同一个任务可以采样多条 trajectory，有些失败、有些成功，成功轨迹用于训练，失败/成功对用于 preference optimization。

这一阶段的贡献是：证明模型自生成数据经过筛选，可以反过来提升模型本身。 局限是：多数任务仍是短轨迹、答案可验证、环境简单，和真实 agent 的长工具链交互还有距离。

#10.3 第三类：coding/software agent，把环境反馈变成训练信号

coding agent 是目前最适合 OPD/OPSD 的场景，因为软件工程天然有 verifier：

unit tests
compiler
type checker
lint
CI
benchmark
code review

现有工作大致做三件事。

第一，构建可交互软件工程环境。SWE-agent 的重点不是训练算法，而是 agent-computer interface：如何让语言模型稳定地搜索文件、查看代码、编辑、运行测试、提交 patch。它提供的是 trajectory generation infrastructure。

第二，把软件工程 benchmark 变成可训练环境。SWE-Gym、R2E-Gym 这类方向关注如何快速启动 repo、隔离任务、运行测试、记录轨迹、判断 patch 是否正确。它们为 OPD 提供数据源：

真实/半真实 repo issue → agent trajectory → test/CI outcome

第三，用环境反馈训练 agent。SWE-RL、long-context multi-turn SWE agent RL 等工作把软件工程任务视作多轮 MDP：

state: repo、文件内容、测试结果、历史操作
action: 工具调用、代码编辑、测试命令
reward: 最终测试是否通过 / patch 是否正确
policy: LLM agent

这条路线是：

agent trajectory → reward → RL update

它比 OPD 更“硬 RL”。问题也明显：轨迹很长、reward 稀疏、credit assignment 难、训练成本高、容易 reward hacking。于是另一条更稳的路线就是：

agent trajectory
→ 自动筛选/诊断
→ 构造 SFT / preference / process samples
→ OPD/OPSD

此外，SWE-RM 这类 execution-free reward model 尝试用模型评价 patch 或 trajectory 质量，弥补真实测试慢、稀疏、覆盖不全的问题。它可以区分：

这个 patch 虽然测试过了，但改动过大；
这个 patch 虽然没完全过，但方向正确；
这个 trajectory 的定位过程更合理。

这类 reward model / judge 对 OPD 很重要，因为 OPD 需要把原始 outcome 转成更细粒度的监督信号。

#10.4 现有工作与 OPD pipeline 的对应关系

可以把 OPD pipeline 拆成六环：

当前真正薄弱的是中间两环：trajectory diagnosis 和 sample construction。我们不缺 agent 轨迹，也不缺最终测试结果；缺的是把长轨迹中的关键错误、关键修复和可学习策略自动抽出来。

#11. DeepSeek-V4：OPD 作为“多专家能力合版”的具体例子

DeepSeek-R1 和 DeepSeek-V4 的 OPD 语境不一样。R1 公开路线更接近：

RLVR / GRPO → rejection sampling → reasoning trace distillation

而 V4 明确把 OPD 用作 多专家能力整合机制。

DeepSeek-V4 官方 model card 中的核心描述是：

post-training features a two-stage paradigm: independent cultivation of domain-specific experts through SFT and RL with GRPO, followed by unified model consolidation via on-policy distillation, integrating distinct proficiencies across diverse domains into a single model.

也就是说，V4 后训练分两阶段：

第一阶段：独立培养 domain-specific experts
第二阶段：通过 OPD 把这些专家能力整合进一个统一模型

#11.1 第一阶段：先分别训练领域专家

V4 想让一个模型同时具备数学推理、代码能力、agentic coding、长上下文、通用问答、指令跟随和世界知识。朴素做法是把所有数据混在一起做 SFT + RL，但这样不同领域的 reward、行为风格和能力目标会互相干扰。

所以 V4 采用：

base / post-pretrained model
→ domain-specific SFT
→ domain-specific GRPO / RL
→ domain expert

可以想象有数学专家、代码专家、agentic coding 专家、指令跟随专家、长上下文专家等。每个专家在自己的数据和 reward 上优化，避免所有能力在一个混合 RL stage 中抢梯度。

#11.2 第二阶段：multi-teacher OPD 合并专家行为

有了多个专家后，问题变成：如何把它们放进一个统一模型？

直接 weight merging 会遇到参数空间不兼容和 capability conflict；混合数据再训又可能稀释专家能力；多 reward 混合 RL 则 reward 设计复杂、尺度不一致。

V4 的选择是 OPD：让统一 student 自己生成 rollout，然后让多个 expert teacher 在 student 走到的 prefix 上提供 token-level 分布监督。

简化流程是：

student model 采样自己的输出
→ 根据样本所属任务/领域，选择一个或多个 expert teacher
→ teacher 在 student prefix 上给 target distribution
→ student 更新，使自己在这些 on-policy states 上更接近 expert mixture

关键点是：trajectory 来自 student，而不是 teacher。 这避免了普通 teacher-generated SFT 的 exposure bias：student 部署时会进入自己的状态分布，所以训练时也应该在自己的状态分布上接受专家监督。

如果写成公式，student 在 prompt x 上生成：

y = (y_1, y_2, ..., y_T) ~ π_θ(. | x)

每个 prefix 是：

s_t = (x, y_<t)

多个 expert 给出分布：

π_E1(. | s_t), π_E2(. | s_t), ..., π_EN(. | s_t)

再构造 teacher mixture：

π_T(. | s_t) = Σ_i w_i(x,t) π_Ei(. | s_t)

student 最小化类似：

Σ_t D_KL(π_T(. | s_t) || π_θ(. | s_t))

或根据具体实现使用 reverse KL / weighted KL。核心不是 KL 方向，而是：

student 自己生成状态 → 多专家在这些状态上给分布 → student 对齐多专家行为

#11.3 Full-vocabulary logit distillation：为什么比只学答案更强

公开解读中提到，V4 OPD 不是只监督 sampled token，而是更偏向 full-vocabulary logit distillation。普通 SFT 给的是 one-hot target：

下一个 token 是 x

full-vocabulary distillation 给的是整个词表分布：

在这个状态下，哪些 token 合理，哪些 token 不合理，概率质量如何分配

这对多专家合版非常关键。专家不仅告诉 student 最终答案，还告诉它在每个中间状态下的行为偏好。对于 agentic coding，这种中间状态分布比最终 patch 更重要，因为任务成败常常取决于中间工具调用、错误恢复和测试策略。

#11.4 为什么 V4 OPD 对 agent 很有启发

V4 的做法说明 OPD 不只是“小模型模仿大模型”，更是一种 行为级能力整合机制。它把“不同专家在不同环境反馈中学到的局部最优策略”压回一个统一 policy。

这对 self-evolving coding agent 很有启发。真实部署中，我们可能会逐渐训练出：

bug-fix expert
test-debug expert
code-review expert
repo-navigation expert
tool-use expert

如果直接合并参数或混合 reward，能力可能冲突；但可以让统一 agent 自己 rollout，再在不同 trajectory segment 上调用不同专家给 token-level、step-level 或 preference-level 监督，通过 OPD 合成一个更强的统一策略。

换句话说，DeepSeek-V4 给出的不是 personal agent 持续在线学习的完整答案，但它提供了一个非常重要的范式：

先让不同专家从各自反馈中变强；
再让统一模型在自己的行为分布上接受多专家蒸馏。

这正是 agent 时代“从经验到参数”的一种可扩展实现。

#12. 当前瓶颈：OPD 不是银弹

#12.1 On-policy 数据质量问题

如果 student 初始能力太弱，它生成的 trajectories 可能全是垃圾。此时即使 teacher 能纠正，也会非常昂贵，且容易让训练集中充满低质量状态。

因此许多 OPD 工作都会先做 mid-training / SFT，把 student 拉到一个基本能力区间，再做 on-policy distillation。PACED 进一步强调：训练最有效的区域往往是 student pass rate 中等的题，也就是它“差一点会”的地方。

这和教育中的 zone of proximal development 很像：太简单的题没梯度，太难的题没信号，最值得训练的是能力边界附近。

#12.2 Teacher / judge 可靠性问题

OPD 的上限强烈依赖反馈源。如果 teacher 错了、judge 偏了、verifier 可被 hack，student 会稳定地学坏。

特别是在 self-distillation 中，如果 policy 和 judge 同源，就容易形成回音室：模型把自己喜欢的答案当成更好答案，逐轮强化偏见。

缓解方式包括：

• 多 teacher 交叉评审；
• 引入外部 verifier；
• 保留 human data mixture；
• 定期做 held-out eval；
• 对 self-generated data 控制比例；
• 允许 rollback。

#12.3 分布坍缩与多样性下降

反复对 self-generated samples 做筛选和训练，可能导致模型越来越模式化：

• 输出风格变窄；
• reasoning 模板化；
• 不确定性表达减少；
• 少数错误被反复强化；
• benchmark-specific overfitting。

这在 personal agent 中尤其危险，因为用户反馈往往是局部的、情境化的。一次偏好不应该被过度泛化成所有场景规则。

#12.4 Verbal feedback 的语义解析

用户一句“下次别这样”可能意味着：

• 格式偏好；
• 事实纠错；
• 情绪不满；
• 当前任务约束；
• 长期工作流规则；
• 一次性例外。

如果系统无法区分这些类型，就会把临时反馈错误地蒸馏成长期行为。

所以 personal agent 中的 OPD 不只是训练问题，也是 memory governance 问题：

• 什么反馈值得长期记？
• 什么反馈只在当前任务有效？
• 什么反馈需要用户确认？
• 什么反馈不能进入参数？
• 用户如何查看、编辑、撤销模型学到的东西？

#12.5 长轨迹 credit assignment 与样本去噪

对 agent 尤其是 coding agent 来说，最大的难点不是没有反馈，而是反馈太粗、轨迹太长。一次任务可能包含几十到几百步：搜索、阅读、编辑、测试、回滚、再测试。最终测试通过只能说明“整条轨迹最后成功”，不能说明：

• 哪一步定位真正关键；
• 哪个 edit 是有效修复；
• 哪些搜索只是无效绕路；
• 哪个测试失败暴露了真实问题；
• 哪些行为虽然导致当前成功，但会在长期形成坏习惯。

如果直接把完整成功轨迹 SFT 进去，模型会学到很多噪声；如果只用最终 reward 做 RL，credit assignment 又太难。因此 OPD/OPSD 真正需要的是轨迹诊断和轨迹重写：

messy on-policy trajectory
→ identify key decisions and failure points
→ rewrite into clean expert-like trajectory
→ construct SFT / preference / process samples

这也是当前研究空间最大的地方：如何从真实 agent logs 中自动抽取“值得进入参数”的经验，而不是把所有历史都压进模型。

#12.6 隐私与控制权

personal agent 的 on-policy data 往往来自真实用户任务，可能包含隐私、代码、邮件、研究想法、组织信息。把这些数据用于全局模型训练非常敏感。

更合理的路线可能是：

• 原始交互只保存在用户侧；
• 蒸馏到 personal adapter，而不是全局模型；
• 训练样本可审计、可删除；
• 用户可以导出自己的 memory / adapter；
• 敏感信息先做过滤和摘要化。

换句话说，OPD 在 personal agent 中不仅是技术机制，也需要产品和治理机制配套。

#13. 我的判断：OPD 的真正价值在于“把反馈密度做高”

如果只把 OPD 理解成“另一种蒸馏”，会低估它的意义。

它真正重要的地方在于：它为 LLM/Agent 提供了一种把真实交互反馈变成高密度训练信号的通用框架。

对模型合版，它是行为级合并机制；

对 RL 平替，它是把 reward-guided improvement 监督学习化；

对 personal agent，它是把用户 feedback 从 prompt/memory 层推进到 adapter/parameter 层；

对 self-evolution，它是把成功经验和失败修正固化为长期能力的桥。

但它也有清晰边界：

• 如果没有可靠 teacher/verifier，它会自我污染；
• 如果没有探索，它不能替代真正的 RL；
• 如果没有 memory governance，它会过拟合局部反馈；
• 如果没有 evaluation 和 rollback，它会持续漂移。

因此我更愿意把 OPD 看成 agent 时代的后训练基础设施，而不是某个单独算法。

未来真正有价值的问题可能不是“OPD 能不能比 PPO 分数高”，而是：

1. 如何从真实 agent 轨迹中自动抽取可蒸馏的反馈？
2. 如何把 verbal feedback 稳定转成 preference / correction / rule / skill？
3. 如何决定哪些反馈进入 memory，哪些进入 adapter，哪些进入全局模型？
4. 如何在个人持续学习中做安全、隐私和可撤销？
5. 如何把 long-horizon agent 的稀疏失败转化成局部密集监督？
6. 如何避免 self-distillation 的分布坍缩和 judge 回音室？

这些问题和 model-based RL、latent reasoning、agentic RL、自演化代码 agent 都高度相关。因为本质上，它们都在问同一个问题：

一个智能体如何把自己的经验变成下一轮更好的行为策略？

OPD/OPSD 给出的答案是：不要只等最终 reward，也不要只背 teacher 的标准答案；让模型在自己真实会到达的状态上，获得尽可能密集、可训练、可复用的反馈。

#参考资料

• Kevin Lu and Thinking Machines Lab, On-Policy Distillation, 2025.
• Rishabh Agarwal et al., On-Policy Distillation of Language Models: Learning from Self-Generated Mistakes, 2023.
• Caglar Gulcehre et al., Reinforced Self-Training (ReST) for Language Modeling, 2023.
• Rafael Rafailov et al., Direct Preference Optimization: Your Language Model is Secretly a Reward Model, 2023.
• Siyan Zhao et al., Self-Distilled Reasoner: On-Policy Self-Distillation for Large Language Models, 2026.
• Xinsen Zhang et al., OPSDL: On-Policy Self-Distillation for Long-Context Language Models, 2026.
• Yuanda Xu et al., PACED: Distillation and On-Policy Self-Distillation at the Frontier of Student Competence, 2026.
• Hao Wang et al., Skill-SD: Skill-Conditioned Self-Distillation for Multi-turn LLM Agents, 2026.
• DeepSeek-AI, DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence, 2026.
• Yecheng Wu, Song Han, Han Cai, Lightning OPD: Efficient Post-Training for Large Reasoning Models with Offline On-Policy Distillation, 2026.
• Hebo Xu et al., Rethinking On-Policy Distillation of Large Language Models: Phenomenology, Mechanism, and Recipe, 2026.
• Noah Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, 2023.
• Aman Madaan et al., Self-Refine: Iterative Refinement with Self-Feedback, 2023.
• Guanzhi Wang et al., Voyager: An Open-Ended Embodied Agent with Large Language Models, 2023.
• John Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering, 2024.
• Weizhe Yuan et al., Self-Rewarding Language Models, 2024.
• Eric Zelikman et al., STaR: Bootstrapping Reasoning With Reasoning, 2022.