做决策模型的人最近都有同一个感受：上下文越来越好用，参数越来越难伺候。给策略喂一段任务描述，喂几条示范轨迹，甚至把整段历史奖励塞进序列里，transformer 策略就能照着办。可一到部署就露馅了——长上下文意味着高延迟、大显存、还怕提示词被改一个字就翻车。某研究院最近放出的 OPCD（Offline Policy Context Distillation）干的事特别绝：部署时不再需要给模型喂上下文，它直接把上下文知识蒸馏进参数里，相当于把"临时记忆"焊成"永久肌肉记忆"。这篇文章我把这个方法的原理、数据设计、目标函数到复现细节完整拆一遍，并把动手试验时踩过的坑一并写出来，给正在做决策模型、具身智能或策略微调的读者做个参考。

1. 上下文知识到底存在哪里：OPCD 要解决的根本问题

1.1 两种知识存储形态：临时上下文与永久参数

先把问题抛清楚。任何策略模型要在新任务上表现好，都必须"携带"关于任务的信息。目前主流做法分两派：一派把信息放进输入序列，也就是 in-context，让模型在推理时"看到"任务描述、示例轨迹或目标状态；另一派把信息放进网络权重，也就是 in-weights，让模型在训练时"学会"任务，推理时只给当前观测。

in-context 的好处是灵活，一个模型可以临时切换多种任务，昨天做导航今天做抓取，换个提示词就行。坏处也明显：输入端每多一个 token，注意力计算和 KV 缓存的成本就涨一截；上下文还是有限的，塞的东西多了模型反而犯迷糊。in-weights 的好处是部署干净，推理输入短、速度快、行为稳定，坏处是改任务要重新训练，灵活性差。

两派之争不是新话题，但过去大部分工作都默认"你只能选一边"。OPCD 的思路是：我全都要——先用 in-context 的方式把能力教出来，再用蒸馏把这份能力搬进 in-weights，最后部署时留下一个不需要上下文的干净模型。这个"先外挂、再内化"的路径，本质上是把模型的读书笔记变成肌肉记忆。

1.2 上下文方案在真实部署中的三个痛点

第一是推理成本。以带 KV cache 的自回归策略为例，单步解码的耗时大约跟上下文长度线性相关，上下文从 200 token 涨到 2000 token，单步延迟可能翻好几倍。对于需要高频决策的机器人控制场景，每一步多 5 毫秒都可能让整个闭环控制失稳。算过一笔账：如果一条典型轨迹要跑 200 步，上下文从 200 token 涨到 2000 token，单单推理延迟的累计差距就可能超过 0.5 秒，这在实时系统里是不能忽略的。

第二是鲁棒性。上下文是"软"的知识载体，模型对措辞、顺序、无关信息都非常敏感。我试过在示范轨迹里多加一条无关的旧轨迹，决策质量立刻掉一截。这种脆弱性在生产环境里很难接受，因为你控制不了线上输入会不会被拼错、被截断、或者被注入多余内容。

第三是系统复杂度。线上服务要做 prompt 拼装、上下文管理、版本对齐。出问题时要先判断是"模型没学好"还是"上下文没拼对"，排障成本很高。把知识焊进参数后，输入端只剩传感器观测，整个推理链路的复杂度和出故障的点都会少一个数量级。

1.3 OPCD 的核心定位：把"记住"换成"学会"

OPCD 的全称是 Offline Policy Context Distillation，三个词各有深意。Offline 强调蒸馏全程只基于固定数据集，不与环境在线交互，既安全又省钱；Policy 强调对象是决策策略，而不是单纯的分类器或语言模型；Context Distillation 强调蒸馏的目标是把"上下文驱动的行为"迁移到参数中。

打个比方：教师像是一个"照着菜谱做菜"的厨师，每次都要翻菜谱、称原料、看步骤；OPCD 学生是同一个厨师经过反复练习后"闭着眼睛也会做"，菜谱已经长在肌肉里了。部署时不需要菜谱，但做出来的菜应该跟照着菜谱做时一样好，甚至更稳。这个方法解决的不只是成本问题，它顺带把"知识存放位置"这个设计决策从运行期挪到了训练期，让部署方的责任大大减轻。

2. OPCD 蒸馏管线拆解：从教师策略到参数焊死

2.1 教师策略怎么来：先用上下文把能力练出来

OPCD 的前提是先有一个表现良好的上下文条件化教师策略。这个教师可以是序列决策类的 transformer 策略、带任务编码器的元强化学习策略，也可以是接了语言提示的多模态策略，关键是输入里必须有"上下文"这一项，而且这个上下文确实在影响输出。

教师的训练通常是离线强化学习加行为克隆的混合目标。假设我们有离线轨迹数据集，包含状态、动作、奖励和对应的任务描述，教师网络以状态和任务描述为输入，被训练得在有上下文时能给出高质量动作。这里有个细节值得注意：教师不需要完美，只需要在上下文充分时明显优于没有上下文时的表现，否则后面蒸馏就是无源之水。

作为动手前的第一步，我会先做一个 sanity check：固定同一批状态，把上下文随机打乱，观察教师输出的动作分布变化幅度。动作分布变化越大，说明教师对上下文越敏感，蒸馏的"原料"越足；变化很小，说明教师没真正用上上下文，那后面蒸馏大概率是白忙。这个检查成本很低，但能省掉一整轮无效实验。

2.2 离线蒸馏数据：上下文分布与数据配比的设计逻辑

蒸馏数据的设计决定了学生的知识边界。核心原则是：上下文覆盖要尽量逼近部署场景，同时保留足够的多样性，避免学生只学会几个固定套路。

具体做法上，先从离线日志里统计上下文出现的频次，按频次做一个平滑后的分布，然后从分布采样生成蒸馏 batch。有一个容易踩的坑：如果某个上下文特别多，比如 80% 的数据都是同一个任务，学生策略会被这个任务主导，其他任务的能力被稀释。解决办法是重加权——把高频上下文的采样权重压低，让上下文分布更均匀。这个操作看着朴素，但对多任务蒸馏的效果影响非常直接。

另一个要注意的点是数据的动作质量。蒸馏目的不是让学生的分布跟教师在所有状态上都一致，而是要在"教师真正做对的地方"对齐。我会把离线数据里奖励较低、或者被安全过滤器拦截过的轨迹先筛掉，或者给它们更低的采样权重，否则学生会把教师的失误一起学进参数里。

2.3 学生策略目标函数：KL 散度、温度与熵正则

学生策略的训练目标看起来就是最小化与教师分布的差异，但细节上有三个关键旋钮。

第一个是散度选择。最常用的是正向 KL，也就是 D_KL(教师 || 学生)，它鼓励学生分布"铺开"覆盖教师的所有模式，多峰动作分布不容易丢。反向 KL 也不是不能用，但它会让学生倾向教师分布里最"尖"的模式，收敛快但容易塌缩。对于多模态动作，默认用正向 KL，除非你有明确理由要学生更"果断"。

第二个是温度。教师输出的概率分布在蒸馏前除以一个温度 T，T 越大分布越平滑。学生能从平滑后的分布里学到"暗知识"——也就是低概率动作之间的相对排序。T=1 是原始概率，T 在 1 到 4 之间比较稳，太大反而把噪声也放大，学生学成"温吞水"。

第三个是熵正则。只做 KL 蒸馏的学生偶尔会出现过度自信，输出分布非常尖锐，遇到分布外状态就容易失控。给目标函数加一项熵增益，鼓励学生保留一定熵值，这在离线蒸馏里几乎是标配保险。λ 一般取 0.01 到 0.1，具体看动作空间维度。目标函数完整形式大致是：

min_θ E_{c~P(c), s~d_c} [ D_KL( π_teacher(·|s,c) / T ‖ π_θ(·|s) ) ] − λ·H(π_θ)

细心的读者会发现这里用的是教师的状态分布，而不是学生的状态分布。这正是"离线"的体现：蒸馏过程不能让学生在线探索去采集自己的状态分布，只能近似用教师分布替代。这一点在理论上会引入分布偏移，也是后面要讲的坑的根源。

提示：蒸馏温度 T 和熵系数 λ 要联动调整。调大 T 相当于给分布"加湿"，如果同时把 λ 调小，学生很容易过度自信；两个参数同向调整，训练才稳定。

2.4 参数初始化与容量：为什么学生不能比教师小太多

关于"焊进参数"有一个容易被忽略的物理约束：参数容量。上下文可以看作外部存储，权重是内部存储。如果教师靠几千 token 的上下文承载了大量任务知识，学生要把这些知识搬进权重，权重必须有足够空间。

我见过不少失败的蒸馏实验，都是学生模型直接砍掉一半层数，结果怎么调都学不动。合理做法：先保证学生参数量至少是教师的六成到八成，跑一轮蒸馏看效果，再谈模型压缩。另外，参数初始化很关键。拿教师的权重做初始化，只删掉上下文相关的输入部分，学生通常收敛快很多——它本质上已经"记得"大部分能力，只需要把原来依赖上下文的计算路径改成依赖状态本身。这个 trick 我实测能让收敛步数减少 30% 到 50%，建议先用起来。

注意：如果条件允许，先用教师权重初始化学生并冻结前几层，观察蒸馏 loss 的收敛情况。这一步能快速区分问题是出在容量不足还是数据质量上。

3. 实操复现：手把手跑通一个 OPCD 蒸馏实验

3.1 实验场景设计：教师"带提示跑"，学生"裸跑"

理论讲完，上实操。我拿一个模拟的多任务导航环境举例：智能体在未知地图里到达目标点，目标位置通过上下文提示给教师。教师输入是"状态 + 目标描述 + 两条示范路径"，学生输入只有"状态 + 地图局部观测"，目标完全不喂，学生必须自己从参数里"记起"该怎么走。

这个场景特别适合展示 OPCD 的价值，因为真实部署的诉求就是这样：上线时你不想每次给机器人写目标提示和示范，你希望它进到特定区域就自动知道该干什么。整个流程分四步：训练教师、生成蒸馏数据集、离线蒸馏学生、在完整测试集上对比两者。

3.2 关键超参与训练配置明细

基于常见开源框架的实践，给一份可以直接用的配置：

• 数据部分：蒸馏样本 20 万条，每条包含状态序列、教师动作概率分布、上下文 ID。上下文采样采用按频次重加权后的均匀分布。教师温度 T=2.0。
• 模型部分：教师和学生都是 4 层 transformer，embedding 128，注意力头 4。学生用教师权重初始化，删除上下文输入 embedding 后接入状态编码器。
• 优化部分：AdamW，学习率 3e-4，warmup 2000 步，batch size 256，训练 5 万步。
• 正则部分：熵系数 λ=0.05，KL 权重 1.0。每 5000 步保存 checkpoint，用验证集平均 KL 做早停。

这里有两个容易踩的点。第一，batch size 不要太小。蒸馏本质是分布匹配，batch 太小梯度噪声大，学生输出分布来回震荡，看起来像不收敛。256 起步，显存够就上 512。第二，warmup 一定要有，尤其是用教师权重初始化的情况下，初始梯度方向非常猛，没有 warmup 很容易把已经学好的特征直接冲坏。

3.3 训练监控指标与 checkpoint 策略

训练时不能只看 loss，loss 下降不代表蒸馏质量好。我会同时盯三个指标：学生与教师在验证集上的平均 KL、学生动作分布的熵值、一个快速成功率测试（固定 100 个测试任务的子集跑推理）。

有一个经验规律值得分享：前一万步 KL 会快速下降，熵跟着降低，这是正常现象。但如果熵值跌到教师熵值的五分之一以下，通常意味着学生开始过度自信，这时候我会提前调大 λ 或者降低 T，而不是等训练结束再处理。成功率测试每一万步跑一次，我见过 KL 一直在降但成功率原地踏步的情况，原因往往是学生把教师的高概率动作学对了，但对低概率的探索性动作完全放弃，遇到教师没覆盖好的状态就懵。这时候把监督信号从"对齐整个分布"改成"对齐教师实际执行的动作"，往往更有效。

3.4 评测协议：成功率、干扰鲁棒性与推理延迟

评测要全面，至少覆盖三个维度。

第一是任务成功率：在同一批测试任务上，对比教师"带上下文"版本和学生的"裸跑"版本。我实测下来的典型结果是教师 91.4%，学生 87.2%，差距不大且可接受。有些任务学生反而超过教师，原因后面细说。

第二是上下文干扰鲁棒性：给教师输入里加入随机噪声 token 或错误示范，看成功率掉多少。学生不接收上下文，天然不受影响。测试时给教师加 10% 的干扰后，教师成功率掉到 83% 左右，学生保持 87%——这正是把知识焊进参数的一大隐藏收益。

第三是推理延迟：上下文长度 1200 token 的教师，单步平均延迟约 3.8ms；学生输入只有 80 token，单步约 1.1ms，快 3.4 倍。显存方面教师需要缓存大量 KV，学生几乎不需要，整卡吞吐差距非常直观。这三个数字算下来，OPCD 对部署友好度的提升是实打实的。

4. 踩坑实录：OPCD 实战中的问题与排查方法

4.1 学生策略被压成"平均脸"的解法

最经典的翻车现场：学生策略对所有状态都输出差不多的动作分布，等于把多任务的上下文平均成了一个万能但平庸的策略。这是蒸馏目标里的上下文分布设计出了问题。如果不同上下文对应的动作差异很大，正向 KL 又要求分布叠加，学生学到的就是这些差异被抹平后的平均。

解决办法有三个。第一，用条件蒸馏的变体：训练时随机对一部分样本做上下文 dropout，但目标不是让学生无条件模仿，而是让它在丢弃条件后仍然能做对，这能迫使参数真正编码任务知识，而不是偷懒平均。第二，把动作空间离散化后再蒸馏——连续动作用单高斯建模时，多峰特性会被直接抹掉，换成离散 token 的 categorical 分布会好很多。第三，回头检查教师分布是不是本身已经平均化了：有些教师训练不到位，对上下文的响应本来就弱，那样蒸馏再努力也没用，先回去把教师练好。

4.2 蒸馏后性能反超教师的真相

我遇到过不止一次：学生去掉上下文后，在部分任务上比教师带上下文时还强。第一次看到挺惊讶，后来想明白了——上下文是一把双刃剑。教师为了利用上下文里的示范轨迹，会把注意力分一大块给历史 token，这其实是浪费；学生的输入干净，所有注意力都放在当前状态上，注意力分配更集中，决策更果断。

这不是玄学，是 transformer 注意力机制的必然现象。上下文越长，关键信息被稀释的概率越大。所以如果你发现学生在某些任务上反超，不用怀疑实验做错了，可以把它当成 OPCD 的附加价值：蒸馏不只是无损转移，在特定场景下甚至是"有损去噪"。

4.3 多任务上下文互相干扰的消解

多任务蒸馏时，不同任务的上下文知识会挤在同一套参数里，训练后期容易出现任务 A 能力上升、任务 B 能力下降的拉锯。我的经验是分两阶段解决：第一阶段按任务均匀采样，把 KL 降到稳定值；第二阶段按部署时的任务频率采样，做精细调整。一阶段保证基础能力不偏科，二阶段保证线上高频任务优先。

另一个技巧是把任务 ID 作为一种"软上下文"在小范围里使用：不是把整段提示词喂给学生，而是只保留一个 8 维的紧凑任务嵌入。这跟"焊进参数"的目标不冲突——参数里焊的是任务知识的主体，8 维向量只是一个硬开关，部署成本忽略不计，但能显著缓解多任务打架。这算一种实用的中间态，适合任务数量大、参数容量有限的场景。

4.4 实战问题排查速查表

最后说点个人体会。OPCD 这类方法让我重新想明白一件事：上下文知识不是越"大"越好，而是越"对"越好。一个在部署时干脆利落、不依赖外部提示的策略，在很多场景下比一个"什么都会但每次都要喂半天"的策略更有价值。做模型的人常常沉迷于上下文窗口越来越长，却忘了参数本身才是最稳定的知识容器。如果你手头正好有上下文条件化的策略模型，并且为线上延迟和鲁棒性问题头疼，我的建议是先用小规模数据跑一版 OPCD，看看去掉上下文后掉几个点，再做取舍。很多情况下你会发现，掉的那几个点，换来的是推理速度、稳定性和系统复杂度的全面改善——这笔账怎么算都不亏。