[控场AI]
· 5 分钟阅读· 2,706 字

OPRD:让代码智能体摆脱"提醒依赖"的新训练法

OPRD:让代码智能体摆脱"提醒依赖"的新训练法

OPRD 用训练期提醒、推理期撤除的蒸馏范式,提升长周期编码智能体表现。

OPRD(On-Policy Reminder Distillation)针对长周期编码智能体的核心痛点展开:诊断发现智能体失败往往不是信息缺失,而是上下文里已有信息却未被采纳,加之 SWE-bench 类基准的最终 Pass/Fail 信号过于稀疏,难以定位具体失误步骤。OPRD 的做法是在训练时引入 Turn-local 与 Global 两种粒度的 Reminder 作为特权信息,但推理阶段完全移除,迫使学生模型学会独立完成任务。监督路径由结果路由:成功的 rollout 走自模仿,失败的 rollout 则在学生自生成前缀上接受教师带提醒的反向 KL 蒸馏,避免 off-policy 分布偏移。在三个 SWE-bench 基准上,相对 Qwen3.5-4B 平均任务解决率提升 11.3 个百分点,错误事件从 446 降至 222,减少 50.2%。

长周期编码任务一直是AI智能体的软肋:模型能在单轮对话里写出漂亮的代码片段,一旦进入仓库级、多轮工具调用的真实开发场景,就开始丢约束、忽略上下文。新提出的OPRD(On-Policy Reminder Distillation)试图从训练机制层面解决这个问题。

rss source: OPRD: On-Policy Reminder Distillation for Long-Horizon Coding Agents

问题诊断:上下文里有答案,智能体却看不见

论文的起点是一份诊断分析,结论相当扎心:编码智能体失败的原因,往往不是缺少信息,而是已有的相关信息就在上下文里,模型却没有据此行动。

同时,SWE-bench类基准的最终Pass/Fail信号过于稀疏——它只告诉你整条轨迹成功了还是失败了,无法指出哪一步决策出了问题。这种"结果导向"的监督在长交互中几乎无法提供有效的梯度信号。

作者把两类失败模式归结为:一是模型没有对工具反馈做出正确响应,二是模型没有保持住早期轮次中设定的约束条件。这两种错误都会随着交互轮数增加而累积。

On-Policy 与 Off-Policy 蒸馏:在知识蒸馏中,"策略(policy)"指生成训练数据所用的分布。Off-policy 蒸馏使用教师模型生成的轨迹作为训练样本,学生只能被动模仿教师走过的状态;问题是教师访问过的状态分布与学生自己会遇到的状态分布并不一致,一旦学生偏离教师轨迹,就缺少对应的监督信号——这就是分布偏移。On-policy 蒸馏则要求学生先生成自己的轨迹(即 prefix),再由教师在学生实际到达的这些状态上给出指导。两者状态分布对齐,学生每一步都能获得"针对自己当前位置"的纠偏,因此在长周期、误差易累积的任务上通常更稳定,代价是需要频繁调用教师做前向推理。

OPRD的核心机制:提醒只是训练期的脚手架

OPRD的设计思路可以用一句话概括:训练时给提醒,推理时全撤掉。

具体来说,它引入了两种粒度的"提醒"信号:

  • Turn-local Reminder:只作用于紧跟在某条环境观察之后的下一步决策。相当于告诉模型"刚才这个工具返回意味着你应该做X"。
  • Global Reminder:把最终测试的诊断结果转化为整条轨迹级别的指导,让模型理解全局意图。

关键在于,这些提醒不会进入推理阶段的输入。它们是训练期的临时脚手架,学生模型最终要学会在没有提醒的条件下独立完成长周期任务。

基于结果的路由:成功自模仿,失败看老师

OPRD的另一个设计亮点是outcome-based routing——用最终结果来决定每条rollout走哪条监督路径:

成功的rollout走自回归自模仿路径。模型直接学习自己产生的好轨迹,相当于自我强化。

失败的rollout则接受"提醒条件化的反向KL监督"。具体做法是:让一个教师模型在同一段学生生成的前缀上重新评估(此时带上Reminder),然后通过reverse-KL把教师的分布知识蒸馏回学生。

这里的关键细节是on-policy——学生用自己生成的prefix,而不是教师生成的数据。这避免了off-policy蒸馏中常见的分布偏移问题。

教师和学生共享同一套两阶段初始化:先做Coding SFT,再做Instruction-Following SFT。这保证了教师的知识"接得上"学生的参数空间。

反向 KL(Reverse KL):KL 散度不对称,正向 KL 会惩罚"教师分布高、学生分布低"的区域,倾向于让学生覆盖教师的全部模式(mass-covering),结果可能是过度平滑、生成分散;反向 KL 惩罚的是"学生分布高、教师分布低"的区域,倾向于让学生聚焦到教师的少数高概率模式上(mode-seeking)。在蒸馏场景中,当教师因携带 Reminder 而拥有更尖锐、更可信的分布时,反向 KL 能把这种"高置信决策"精准压进学生网络,而不是让学生去模仿教师尾部那些无意义的低概率噪声,因此更适合作为失败 rollout 的纠偏目标。

两阶段初始化(Coding SFT + Instruction-Following SFT):教师与学生共享同一套初始参数,是为了保证蒸馏的"接口兼容"。第一阶段 Coding SFT 让模型习得代码语法、仓库结构与工具调用格式等基础能力;第二阶段 Instruction-Following SFT 则对齐指令理解与多步约束保持能力。若教师与学生来自不同初始化,教师分布可能落在学生参数空间根本表达不出的区域,反向 KL 会把学生拉向不可达的目标,蒸馏反而退化。共享初始化确保了教师的"提醒条件化分布"只是学生已有分布的一次定向偏移,学生有能力拟合。

基准测试:平均提升11.3个点

在三个主流基准上,OPRD取得了明确的效果提升:

基准提升幅度
SWE-bench Verified纳入平均
SWE-bench Pro纳入平均
SWE-bench Multilingual纳入平均

相对开源基座模型Qwen3.5-4B,OPRD在三个基准上的平均任务解决率提升了11.3个百分点。

更有说服力的是误差事件分析:在同样的诊断协议下,聚合错误事件数从446降到222,减少了50.2%。这说明提升不只是"碰巧做对了更多题",而是系统性地减少了特定类型的决策错误。

方法论的启示

OPRD的价值可能超出编码智能体本身。它提出了一种通用的训练范式:把人类或系统提供的"提示"视为训练期的特权信息,而非推理期的依赖。

这跟传统的prompt engineering思路正好相反——后者试图在推理时塞入更多上下文来改善表现,OPRD则把上下文辅助内化到模型参数里。对于任何需要长周期、多轮交互的智能体任务(不只是编码,还有网页操作、机器人规划等),这套思路都有迁移潜力。

"提醒依赖"本质上是当前智能体的一个通病:给它足够详细的步骤它就表现不错,一旦撤掉提示就原形毕露。OPRD的做法是承认这种依赖的存在,但在训练中逐步脱敏,最终产出不需要拐杖也能走路的模型。

#OPRD#编码智能体#On-Policy蒸馏#长周期任务#SWE-bench#知识蒸馏#代码生成#强化学习
分享:

相关推荐