长程规划智能体Long-Horizon Planning Agent是目前大模型工程里最需要“预训练 蒸馏”配合解决的问题之一。短任务只需要一次生成长任务却要求模型在多步决策、工具调用、状态观察和稀疏奖励之间保持稳定。这篇文章把 OPD 蒸馏这条技术路线拆开讲先定义长程规划为什么难再交代预训练如何给智能体植入规划先验然后给出 OPD这里约定为 Online Policy Distillation在线策略蒸馏的最小可运行实验最后给出评估、排查和生产化清单。适合算法工程师、模型训练工程师和已经在做智能体应用开发的读者。有一点要先说明OPD 这个缩写在不同文献里可能指不同方法本文按“在线策略蒸馏”展开。落地时以你们团队的术语表为准关键是理解“在线”和“蒸馏”分别承担什么作用。1. 先定义问题长程规划智能体到底难在哪里1.1 一个可执行的场景定义长程规划智能体可以通俗地理解为给定一个最终目标智能体需要自主执行一串连续的决策步骤每一步都可能调用工具、查询数据、改写内容或向外部系统发请求最后把目标完成。典型例子有三种月度经营分析报告先拉取销售数据再清洗异常值然后生成图表最后写结论并发送邮件。电商售后流程验证订单是否在售后期内检查物流轨迹确认退货地址再发起退款。嵌入式设备配置读取设备型号查询固件版本匹配依赖生成配置脚本并执行。这类任务的共同点是“步骤多、目标单一、状态变化快”。一个步骤出错后续所有决策都可能建立在错误状态上。1.2 长任务与短任务的关键差异短任务和长程规划任务在技术难度上不是同一个量级。这里用表格做一个直观对比维度短任务单轮问答长程规划任务输出形态一次生成文本多次决策与工具调用上下文长度几百 token累计几千甚至几万 token错误成本答错可以重试错误状态会持续传播反馈时机立即评估奖励稀疏中间缺少明确信号上下文管理简单需要截断、摘要、记忆主要失败模式答错中途跑偏后无法恢复从表格能看出长程规划真正的问题不是“模型不会答”而是“模型不会在长链路上做决策”。这决定了它不能只用提示词解决必须把规划能力写进模型权重里。1.3 为什么“预训练 OPD 蒸馏”是一条可行路线提示词工程改善的是推理时的行为它无法补充模型权重里没有的知识。模型如果不知道“先验证输入再调用工具”这种顺序关系提示词写得再细也会在执行中失效。预训练解决的是“先验”问题让模型在海量轨迹数据上见过足够多的“计划 - 行动 - 观察 - 再计划”形态从而知道执行链路大致应该长什么样。OPD 蒸馏解决的是“对齐”问题用一个能力更强的教师策略在线纠正学生策略在真实状态下的动作分布。这两者配合正好覆盖了“模型会规划”和“部署模型能稳定执行”两个层面。2. 预训练阶段给智能体植入规划先验2.1 不要从零开始先做领域继续预训练从随机初始化训练一个大模型需要几十万 GPU 小时和无法估量的数据预算绝大多数团队不具备这个条件。在实际研究项目中“预训练”通常指的是基于开源底座做领域继续预训练continue pretraining。继续预训练的目标不是让模型重新学语言而是让模型增加对智能体轨迹的分布理解。训练语料应以“任务描述 多轮动作 环境观察”为主辅以少量通用语料防止通用能力退化。需要提醒的是如果原始材料没有给出明确的底座模型和版本落地前一定要先确认依赖的模型权重、tokenizer 和框架版本能对上不同版本之间的注意力实现和对话模板差异可能直接导致训练结果不一致。2.2 轨迹数据长什么样ReAct 格式与序列构造智能体轨迹数据最常见的组织方式参考 ReAct 模式Thought 记录推理Action 记录动作Observation 记录环境返回。下面是一个简化的轨迹片段task 帮用户预订周五下午从上海到北京的高铁并把确认信息发送到邮箱 /task thought 用户需求包含两个子目标订票和发邮件。先查询周五下午的车次。/thought action search_train(departure上海, arrival北京, date周五, time下午) /action observation 上海虹桥-北京南G14 次15:00 出发18:28 到达 /observation thought 查询结果只有一班车直接选择 G14并继续获取座位余量。/thought action check_seat(trainG14, seat二等座) /action observation 余票充足 /observation ...预处理时建议做四件事使用统一的特殊 token 区分任务、思考、动作和观察四类内容避免模型混淆角色。把超长轨迹截断或做摘要最大长度需要根据学生模型的窗口大小设置。打乱任务顺序防止模型依赖相邻样本的连贯性。对 Observation 部分做 loss mask让模型只学习“根据观察选择下一步动作”而不是去预测环境会返回什么。ReAct 格式只是其中一种实际操作中只要保持每条样本的语义结构一致即可格式混乱会比数据量不足更容易拖垮训练效果。2.3 预训练阶段的工程注意点继续预训练的工程风险主要集中在灾难性遗忘和过拟合上。学习率要比 SFT 更低常见区间在 1e-5 到 5e-5。如果学习率过高模型会在轨迹数据上快速收敛但通用能力明显退化。建议在训练数据里混合 20% 到 50% 的通用语料比例取决于你的底座模型原先的通用能力余量。另一个容易被忽略的问题是数据污染。轨迹数据如果来自模型生成必须做去重并且评估任务不能与训练轨迹来自同一批生成过程否则评估结果会虚高。建议从第一步就建立数据质量规则每条轨迹必须至少包含一次 Action 和一次 Observation必须以终止状态结束不能有空的工具调用参数。3. OPD 蒸馏在线策略蒸馏的原理和设计3.1 先区分三种蒸馏路线模型蒸馏在大模型领域里经常被提到但做法差异很大。这里先做一个简单分类方便对照离线日志蒸馏从静态轨迹数据集直接学习教师不参与实时交互。成本最低但静态数据分布和部署时学生探索出的状态分布不一致容易出现“训练时见过上线后没见过”的问题。在线策略蒸馏OPD教师和学生都在线交互于同一个环境。学生探索时产生的状态教师实时给出建议动作再用任务奖励和验证器计算优势最后加权更新学生。偏好对齐DPO / RLHF需要成对偏好数据适合回答层面的好坏判断但对步骤级工具调用的细粒度纠错能力偏弱。方法数据来源是否在线反馈信号典型风险离线蒸馏静态轨迹否无或弱分布偏移OPD在线 rollout是任务奖励 / 验证器成本高、方差大DPO / RLHF偏好对否人工或模型偏好步骤级信号弱3.2 OPD 的核心循环教师在线采样学生在线学习OPD 的核心是“教师看得到学生所在的状态”。流程可以抽象成以下循环从任务分布中采样一个任务。学生策略在环境中 rollout记录每一步的状态序列。在每个状态处教师以较低温度生成建议动作。环境执行动作返回观察任务结束时得到最终奖励。计算优势优势 最终奖励 - 基线基线可以是任务平均奖励或价值网络输出。用优势加权的教师动作来更新学生策略。反复进行直到评估指标稳定。这里的“在线”价值在于状态分布是实时产生的。离线蒸馏只能让教师去教静态数据里的状态而 OPD 能让教师去教学生真正会遇到的错误状态这是它和离线蒸馏最本质的区别。3.3 损失函数怎么写KL 与优势加权的组合OPD 的损失函数可以拆成三项L E_t[ -A_t * log π_s(a_t^T | s_t) β * KL(π_s(·|s_t) || π_t(·|s_t)) - γ * H(π_s(·|s_t)) ]第一项让学生的动作概率向“教师选择且优势较高”的动作靠拢第二项让学生整体的动作分布不要偏离教师分布太远第三项是熵正则防止学生把动作坍缩到某一个选项上。β 调大会让学生更贴近教师但也可能掩盖任务奖励信号γ 调大能增加探索但收敛会变慢。实际项目中第一次实验建议先把 β 和 γ 设小优先观察优势加权项是否生效再逐步调。如果教师是闭源 API拿不到动作概率分布KL 项可以省掉只用教师采样动作的 NLL 和优势加权。如果教师是本地开源模型可以拿到 logits用 KL 项做分布约束会更稳。下面给出一段用于说明 OPD 循环结构的伪代码真正落地时需要按框架和模型接口调整# 伪代码说明 OPD 循环结构 for step in range(total_steps): task sample_task() history env.reset(task) # 学生先在当前策略下探索得到真实分布的状态 student_action student_policy.sample(history, temperature0.8) obs, done, reward env.step(student_action) # 教师基于同一段历史给出建议动作 with torch.no_grad(): teacher_action teacher_policy.sample(history, temperature0.3) # 任务结束后计算优势简化版用最终奖励减平均奖励 advantage compute_advantage(reward, baseline) # 蒸馏损失优势加权教师动作 log_prob再加熵正则 log_prob student_policy.log_prob(teacher_action, history) entropy student_policy.entropy(history) loss -(advantage * log_prob).mean() 0.01 * entropy.mean() loss.backward() optimizer.step()代码里的sample、log_prob、entropy都是策略模型的标准接口。如果学生模型没有显式策略头就需要先改造成能输出动作分布的形式这一点在下一章会具体说明。4. 最小可运行实验用玩具环境验证 OPD 流水线4.1 实验目标与环境准备这个实验的目标不是超过 SOTA而是验证三件事教师能在给定任务上给出稳定动作建议。学生能在 OPD 循环里正常采样和更新。蒸馏后学生在冻结评估集上的成功率相比蒸馏前有提升。环境准备建议如下python -c import torch; print(torch.__version__, torch.cuda.is_available())推荐使用 Python 3.10 或更高版本PyTorch 2.xtransformers 或 vLLM 负责模型推理。学生模型建议选择 1B 到 3B 的开源模型教师可以选择 7B 到 72B 的模型或 API。显存 16G 以上可以把 1.5B 学生和 7B 教师同时放在本地如果教师更大建议统一走推理服务接口。注意本文出现的模型名称只是示例不构成版本建议。实际项目必须以你能申请到的权重权限、显存大小和框架兼容性为准。4.2 玩具环境一个多步任务调度器为了让 OPD 流程可复现这里设计一个极其简化的多步任务调度环境。任务由 3 个动作组成环境只返回“已完成哪些步骤”的观察成功完成全部步骤才拿到最终奖励。# toy_env.py class ScheduleEnv: 多步任务调度器的简化实现用于验证 OPD 蒸馏流程。 VALID_TASKS [ [send_mail, create_event, backup], [query_report, send_summary, archive], ] def __init__(self, max_steps8): self.max_steps max_steps self.step_count 0 self.task None self.done_steps set() def reset(self, task_idx0): self.task self.VALID_TASKS[task_idx % len(self.VALID_TASKS)] self.step_count 0 self.done_steps set() return f任务目标: {self.task} def step(self, action): self.step_count 1 if action not in self.task: reward, done -0.1, False elif action not in self.done_steps: self.done_steps.add(action) reward, done 0.2, False else: reward, done -0.05, False done len(self.done_steps) len(self.task) if done: reward 1.0 if self.step_count self.max_steps: done True obs f已完成: {list(self.done_steps)} return obs, done, reward, {step_count: self.step_count}这个环境把长程任务的难点缩小成了三个特征部分可观察状态、动作副作用、最终奖励稀疏。因为动作空间只有少数几个学生可以直接用离散动作头输出概率方便验证蒸馏逻辑。4.3 配置文件把超参数外置训练超参数不建议写死在代码里。下面是一份config.yaml示例task: max_steps: 8 total_rollout_steps: 5000 teacher: model: qwen2.5-72b-instruct api_base: http://127.0.0.1:8000/v1 temperature: 0.3 max_tokens: 128 student: model_name: Qwen/Qwen2.5-1.5B-Instruct lr: 5.0e-6 batch_size: 8 grad_accum: 4 distill: kl_coef: 0.1 ent_coef: 0.01 advantage_scale: 1.0 eval_every: 200参数含义如下参数作用调大影响调小影响teacher.temperature教师采样随机性建议多样但噪声大稳定但探索少student.lr学生更新步长收敛快但易震荡稳定但耗时长kl_coef学生贴教师分布的程度更贴教师更自由ent_coef学生动作熵约束探索多容易坍缩advantage_scale优势项缩放奖励信号强更新慢配置里最容易错的是模型名和 API 地址不匹配。如果教师走本地推理服务先用 curl 或一个简单请求验证/v1路径能正常返回再开始训练否则 rollout 会一直卡在超时上。4.4 核心代码教师采样与学生更新教师侧代码负责把“历史上下文”转换成动作建议。为了方便这里假设教师是兼容 OpenAI 协议的推理服务# teacher_rollout.py def teacher_recommendation(client, history, teacher_cfg): prompt build_prompt(history) # 拼接任务、观察、已完成动作 response client.chat.completions.create( modelteacher_cfg.model, messages[{role: user, content: prompt}], temperatureteacher_cfg.temperature, max_tokensteacher_cfg.max_tokens, ) return parse_action(response.choices[0].message.content)parse_action需要严格做 schema 校验解析失败要当作非法动作处理而不是直接跳过。这一步是 OPD 稳定性的关键教师偶尔输出不规范内容属于正常现象。学生侧需要把语言模型改造成离散动作策略。最简单的方式是在语言模型最后一层隐藏状态上接一个动作分类头# student_policy.py import torch import torch.nn as nn import torch.nn.functional as F class StudentPolicy(nn.Module): def __init__(self, base_lm, num_actions): super().__init__() self.base base_lm self.action_head nn.Linear(base_lm.config.hidden_size, num_actions) def forward(self, input_ids, attention_mask): hidden self.base( input_ids, attention_maskattention_mask ).last_hidden_state[:, -1, :] # 取最后一个 token 的隐藏状态 logits self.action_head(hidden) return logits def log_prob(self, input_ids, attention_mask, action_id): logits self.forward(input_ids, attention_mask) log_probs F.log_softmax(logits, dim-1) return log_probs[0, action_id] def entropy(self, input_ids, attention_mask): logits self.forward(input_ids, attention_mask) probs F.softmax(logits, dim-1) return -(probs * F.log_softmax(logits, dim-1)).sum(dim-1)训练更新循环# train_opd.py for batch in rollout_buffer: logits student(input_ids, attention_mask) log_probs F.log_softmax(logits, dim-1) # teacher_action_ids 是教师建议动作对应的 id chosen_log_prob log_probs.gather( 1, teacher_action_ids.unsqueeze(1) ).squeeze(1) # 优势加权 熵正则 loss -(advantage * chosen_log_prob).mean() loss loss ent_coef * student.entropy(input_ids, attention_mask).mean() loss.backward() optimizer.step()这段代码刻意省略了 advantage 的归一化和 KL 项目的是先把主循环跑通。第一次实验务必在 500 步以内看到评估指标上升再逐步加入 KL 约束。5. 运行验证从四个维度判断蒸馏是否有效5.1 在线训练曲线训练过程中需要至少记录四条曲线每个 batch 的平均蒸馏 loss。每个 rollout 的实际任务奖励。学生动作分布的熵。每隔固定步数在冻结评估集上的任务成功率。正常情况是蒸馏 loss 缓慢下降任务奖励波动上升熵维持在中等水平。如果熵快速趋近于 0说明策略坍缩需要增大ent_coef或降低教师 temperature。5.2 冻结评估集与三种基线对比评估不能复用训练环境。要专门准备一组与训练任务同分布但不参与训练的冻结任务并且固定 seed保证每次评估看到的是同一批任务 长程规划智能体：预训练与OPD在线策略蒸馏实战解析
长程规划智能体Long-Horizon Planning Agent是目前大模型工程里最需要“预训练 蒸馏”配合解决的问题之一。短任务只需要一次生成长任务却要求模型在多步决策、工具调用、状态观察和稀疏奖励之间保持稳定。这篇文章把 OPD 蒸馏这条技术路线拆开讲先定义长程规划为什么难再交代预训练如何给智能体植入规划先验然后给出 OPD这里约定为 Online Policy Distillation在线策略蒸馏的最小可运行实验最后给出评估、排查和生产化清单。适合算法工程师、模型训练工程师和已经在做智能体应用开发的读者。有一点要先说明OPD 这个缩写在不同文献里可能指不同方法本文按“在线策略蒸馏”展开。落地时以你们团队的术语表为准关键是理解“在线”和“蒸馏”分别承担什么作用。1. 先定义问题长程规划智能体到底难在哪里1.1 一个可执行的场景定义长程规划智能体可以通俗地理解为给定一个最终目标智能体需要自主执行一串连续的决策步骤每一步都可能调用工具、查询数据、改写内容或向外部系统发请求最后把目标完成。典型例子有三种月度经营分析报告先拉取销售数据再清洗异常值然后生成图表最后写结论并发送邮件。电商售后流程验证订单是否在售后期内检查物流轨迹确认退货地址再发起退款。嵌入式设备配置读取设备型号查询固件版本匹配依赖生成配置脚本并执行。这类任务的共同点是“步骤多、目标单一、状态变化快”。一个步骤出错后续所有决策都可能建立在错误状态上。1.2 长任务与短任务的关键差异短任务和长程规划任务在技术难度上不是同一个量级。这里用表格做一个直观对比维度短任务单轮问答长程规划任务输出形态一次生成文本多次决策与工具调用上下文长度几百 token累计几千甚至几万 token错误成本答错可以重试错误状态会持续传播反馈时机立即评估奖励稀疏中间缺少明确信号上下文管理简单需要截断、摘要、记忆主要失败模式答错中途跑偏后无法恢复从表格能看出长程规划真正的问题不是“模型不会答”而是“模型不会在长链路上做决策”。这决定了它不能只用提示词解决必须把规划能力写进模型权重里。1.3 为什么“预训练 OPD 蒸馏”是一条可行路线提示词工程改善的是推理时的行为它无法补充模型权重里没有的知识。模型如果不知道“先验证输入再调用工具”这种顺序关系提示词写得再细也会在执行中失效。预训练解决的是“先验”问题让模型在海量轨迹数据上见过足够多的“计划 - 行动 - 观察 - 再计划”形态从而知道执行链路大致应该长什么样。OPD 蒸馏解决的是“对齐”问题用一个能力更强的教师策略在线纠正学生策略在真实状态下的动作分布。这两者配合正好覆盖了“模型会规划”和“部署模型能稳定执行”两个层面。2. 预训练阶段给智能体植入规划先验2.1 不要从零开始先做领域继续预训练从随机初始化训练一个大模型需要几十万 GPU 小时和无法估量的数据预算绝大多数团队不具备这个条件。在实际研究项目中“预训练”通常指的是基于开源底座做领域继续预训练continue pretraining。继续预训练的目标不是让模型重新学语言而是让模型增加对智能体轨迹的分布理解。训练语料应以“任务描述 多轮动作 环境观察”为主辅以少量通用语料防止通用能力退化。需要提醒的是如果原始材料没有给出明确的底座模型和版本落地前一定要先确认依赖的模型权重、tokenizer 和框架版本能对上不同版本之间的注意力实现和对话模板差异可能直接导致训练结果不一致。2.2 轨迹数据长什么样ReAct 格式与序列构造智能体轨迹数据最常见的组织方式参考 ReAct 模式Thought 记录推理Action 记录动作Observation 记录环境返回。下面是一个简化的轨迹片段task 帮用户预订周五下午从上海到北京的高铁并把确认信息发送到邮箱 /task thought 用户需求包含两个子目标订票和发邮件。先查询周五下午的车次。/thought action search_train(departure上海, arrival北京, date周五, time下午) /action observation 上海虹桥-北京南G14 次15:00 出发18:28 到达 /observation thought 查询结果只有一班车直接选择 G14并继续获取座位余量。/thought action check_seat(trainG14, seat二等座) /action observation 余票充足 /observation ...预处理时建议做四件事使用统一的特殊 token 区分任务、思考、动作和观察四类内容避免模型混淆角色。把超长轨迹截断或做摘要最大长度需要根据学生模型的窗口大小设置。打乱任务顺序防止模型依赖相邻样本的连贯性。对 Observation 部分做 loss mask让模型只学习“根据观察选择下一步动作”而不是去预测环境会返回什么。ReAct 格式只是其中一种实际操作中只要保持每条样本的语义结构一致即可格式混乱会比数据量不足更容易拖垮训练效果。2.3 预训练阶段的工程注意点继续预训练的工程风险主要集中在灾难性遗忘和过拟合上。学习率要比 SFT 更低常见区间在 1e-5 到 5e-5。如果学习率过高模型会在轨迹数据上快速收敛但通用能力明显退化。建议在训练数据里混合 20% 到 50% 的通用语料比例取决于你的底座模型原先的通用能力余量。另一个容易被忽略的问题是数据污染。轨迹数据如果来自模型生成必须做去重并且评估任务不能与训练轨迹来自同一批生成过程否则评估结果会虚高。建议从第一步就建立数据质量规则每条轨迹必须至少包含一次 Action 和一次 Observation必须以终止状态结束不能有空的工具调用参数。3. OPD 蒸馏在线策略蒸馏的原理和设计3.1 先区分三种蒸馏路线模型蒸馏在大模型领域里经常被提到但做法差异很大。这里先做一个简单分类方便对照离线日志蒸馏从静态轨迹数据集直接学习教师不参与实时交互。成本最低但静态数据分布和部署时学生探索出的状态分布不一致容易出现“训练时见过上线后没见过”的问题。在线策略蒸馏OPD教师和学生都在线交互于同一个环境。学生探索时产生的状态教师实时给出建议动作再用任务奖励和验证器计算优势最后加权更新学生。偏好对齐DPO / RLHF需要成对偏好数据适合回答层面的好坏判断但对步骤级工具调用的细粒度纠错能力偏弱。方法数据来源是否在线反馈信号典型风险离线蒸馏静态轨迹否无或弱分布偏移OPD在线 rollout是任务奖励 / 验证器成本高、方差大DPO / RLHF偏好对否人工或模型偏好步骤级信号弱3.2 OPD 的核心循环教师在线采样学生在线学习OPD 的核心是“教师看得到学生所在的状态”。流程可以抽象成以下循环从任务分布中采样一个任务。学生策略在环境中 rollout记录每一步的状态序列。在每个状态处教师以较低温度生成建议动作。环境执行动作返回观察任务结束时得到最终奖励。计算优势优势 最终奖励 - 基线基线可以是任务平均奖励或价值网络输出。用优势加权的教师动作来更新学生策略。反复进行直到评估指标稳定。这里的“在线”价值在于状态分布是实时产生的。离线蒸馏只能让教师去教静态数据里的状态而 OPD 能让教师去教学生真正会遇到的错误状态这是它和离线蒸馏最本质的区别。3.3 损失函数怎么写KL 与优势加权的组合OPD 的损失函数可以拆成三项L E_t[ -A_t * log π_s(a_t^T | s_t) β * KL(π_s(·|s_t) || π_t(·|s_t)) - γ * H(π_s(·|s_t)) ]第一项让学生的动作概率向“教师选择且优势较高”的动作靠拢第二项让学生整体的动作分布不要偏离教师分布太远第三项是熵正则防止学生把动作坍缩到某一个选项上。β 调大会让学生更贴近教师但也可能掩盖任务奖励信号γ 调大能增加探索但收敛会变慢。实际项目中第一次实验建议先把 β 和 γ 设小优先观察优势加权项是否生效再逐步调。如果教师是闭源 API拿不到动作概率分布KL 项可以省掉只用教师采样动作的 NLL 和优势加权。如果教师是本地开源模型可以拿到 logits用 KL 项做分布约束会更稳。下面给出一段用于说明 OPD 循环结构的伪代码真正落地时需要按框架和模型接口调整# 伪代码说明 OPD 循环结构 for step in range(total_steps): task sample_task() history env.reset(task) # 学生先在当前策略下探索得到真实分布的状态 student_action student_policy.sample(history, temperature0.8) obs, done, reward env.step(student_action) # 教师基于同一段历史给出建议动作 with torch.no_grad(): teacher_action teacher_policy.sample(history, temperature0.3) # 任务结束后计算优势简化版用最终奖励减平均奖励 advantage compute_advantage(reward, baseline) # 蒸馏损失优势加权教师动作 log_prob再加熵正则 log_prob student_policy.log_prob(teacher_action, history) entropy student_policy.entropy(history) loss -(advantage * log_prob).mean() 0.01 * entropy.mean() loss.backward() optimizer.step()代码里的sample、log_prob、entropy都是策略模型的标准接口。如果学生模型没有显式策略头就需要先改造成能输出动作分布的形式这一点在下一章会具体说明。4. 最小可运行实验用玩具环境验证 OPD 流水线4.1 实验目标与环境准备这个实验的目标不是超过 SOTA而是验证三件事教师能在给定任务上给出稳定动作建议。学生能在 OPD 循环里正常采样和更新。蒸馏后学生在冻结评估集上的成功率相比蒸馏前有提升。环境准备建议如下python -c import torch; print(torch.__version__, torch.cuda.is_available())推荐使用 Python 3.10 或更高版本PyTorch 2.xtransformers 或 vLLM 负责模型推理。学生模型建议选择 1B 到 3B 的开源模型教师可以选择 7B 到 72B 的模型或 API。显存 16G 以上可以把 1.5B 学生和 7B 教师同时放在本地如果教师更大建议统一走推理服务接口。注意本文出现的模型名称只是示例不构成版本建议。实际项目必须以你能申请到的权重权限、显存大小和框架兼容性为准。4.2 玩具环境一个多步任务调度器为了让 OPD 流程可复现这里设计一个极其简化的多步任务调度环境。任务由 3 个动作组成环境只返回“已完成哪些步骤”的观察成功完成全部步骤才拿到最终奖励。# toy_env.py class ScheduleEnv: 多步任务调度器的简化实现用于验证 OPD 蒸馏流程。 VALID_TASKS [ [send_mail, create_event, backup], [query_report, send_summary, archive], ] def __init__(self, max_steps8): self.max_steps max_steps self.step_count 0 self.task None self.done_steps set() def reset(self, task_idx0): self.task self.VALID_TASKS[task_idx % len(self.VALID_TASKS)] self.step_count 0 self.done_steps set() return f任务目标: {self.task} def step(self, action): self.step_count 1 if action not in self.task: reward, done -0.1, False elif action not in self.done_steps: self.done_steps.add(action) reward, done 0.2, False else: reward, done -0.05, False done len(self.done_steps) len(self.task) if done: reward 1.0 if self.step_count self.max_steps: done True obs f已完成: {list(self.done_steps)} return obs, done, reward, {step_count: self.step_count}这个环境把长程任务的难点缩小成了三个特征部分可观察状态、动作副作用、最终奖励稀疏。因为动作空间只有少数几个学生可以直接用离散动作头输出概率方便验证蒸馏逻辑。4.3 配置文件把超参数外置训练超参数不建议写死在代码里。下面是一份config.yaml示例task: max_steps: 8 total_rollout_steps: 5000 teacher: model: qwen2.5-72b-instruct api_base: http://127.0.0.1:8000/v1 temperature: 0.3 max_tokens: 128 student: model_name: Qwen/Qwen2.5-1.5B-Instruct lr: 5.0e-6 batch_size: 8 grad_accum: 4 distill: kl_coef: 0.1 ent_coef: 0.01 advantage_scale: 1.0 eval_every: 200参数含义如下参数作用调大影响调小影响teacher.temperature教师采样随机性建议多样但噪声大稳定但探索少student.lr学生更新步长收敛快但易震荡稳定但耗时长kl_coef学生贴教师分布的程度更贴教师更自由ent_coef学生动作熵约束探索多容易坍缩advantage_scale优势项缩放奖励信号强更新慢配置里最容易错的是模型名和 API 地址不匹配。如果教师走本地推理服务先用 curl 或一个简单请求验证/v1路径能正常返回再开始训练否则 rollout 会一直卡在超时上。4.4 核心代码教师采样与学生更新教师侧代码负责把“历史上下文”转换成动作建议。为了方便这里假设教师是兼容 OpenAI 协议的推理服务# teacher_rollout.py def teacher_recommendation(client, history, teacher_cfg): prompt build_prompt(history) # 拼接任务、观察、已完成动作 response client.chat.completions.create( modelteacher_cfg.model, messages[{role: user, content: prompt}], temperatureteacher_cfg.temperature, max_tokensteacher_cfg.max_tokens, ) return parse_action(response.choices[0].message.content)parse_action需要严格做 schema 校验解析失败要当作非法动作处理而不是直接跳过。这一步是 OPD 稳定性的关键教师偶尔输出不规范内容属于正常现象。学生侧需要把语言模型改造成离散动作策略。最简单的方式是在语言模型最后一层隐藏状态上接一个动作分类头# student_policy.py import torch import torch.nn as nn import torch.nn.functional as F class StudentPolicy(nn.Module): def __init__(self, base_lm, num_actions): super().__init__() self.base base_lm self.action_head nn.Linear(base_lm.config.hidden_size, num_actions) def forward(self, input_ids, attention_mask): hidden self.base( input_ids, attention_maskattention_mask ).last_hidden_state[:, -1, :] # 取最后一个 token 的隐藏状态 logits self.action_head(hidden) return logits def log_prob(self, input_ids, attention_mask, action_id): logits self.forward(input_ids, attention_mask) log_probs F.log_softmax(logits, dim-1) return log_probs[0, action_id] def entropy(self, input_ids, attention_mask): logits self.forward(input_ids, attention_mask) probs F.softmax(logits, dim-1) return -(probs * F.log_softmax(logits, dim-1)).sum(dim-1)训练更新循环# train_opd.py for batch in rollout_buffer: logits student(input_ids, attention_mask) log_probs F.log_softmax(logits, dim-1) # teacher_action_ids 是教师建议动作对应的 id chosen_log_prob log_probs.gather( 1, teacher_action_ids.unsqueeze(1) ).squeeze(1) # 优势加权 熵正则 loss -(advantage * chosen_log_prob).mean() loss loss ent_coef * student.entropy(input_ids, attention_mask).mean() loss.backward() optimizer.step()这段代码刻意省略了 advantage 的归一化和 KL 项目的是先把主循环跑通。第一次实验务必在 500 步以内看到评估指标上升再逐步加入 KL 约束。5. 运行验证从四个维度判断蒸馏是否有效5.1 在线训练曲线训练过程中需要至少记录四条曲线每个 batch 的平均蒸馏 loss。每个 rollout 的实际任务奖励。学生动作分布的熵。每隔固定步数在冻结评估集上的任务成功率。正常情况是蒸馏 loss 缓慢下降任务奖励波动上升熵维持在中等水平。如果熵快速趋近于 0说明策略坍缩需要增大ent_coef或降低教师 temperature。5.2 冻结评估集与三种基线对比评估不能复用训练环境。要专门准备一组与训练任务同分布但不参与训练的冻结任务并且固定 seed保证每次评估看到的是同一批任务