1. 从一篇论文说起为什么“模仿强模型”这条路走不通Salesforce AI 前段时间放出了一篇挺有意思的研究核心结论用一句话概括就是让一个能力较弱的智能体去模仿 Gemini 这类强模型的输出效果不但没有提升反而会退化而用 on-policy 的方式做修正效果明显更好。这个结论乍一看有点反直觉——我们平时做大模型微调不都是拿强模型的输出当“标准答案”来蒸馏小模型吗怎么到了智能体Agent这个场景里这套逻辑就失灵了我自己在做智能体开发和大模型微调的过程中也踩过类似的坑。最早做销售智能体的时候想着用 GPT-4 级别的模型生成一批高质量的对话轨迹然后拿这些数据去微调一个 7B 的小模型结果训完之后发现模型在简单任务上确实变“聪明”了一点但一遇到需要多步推理、工具调用的场景表现反而比微调前更差甚至出现了大量“幻觉式模仿”——它会模仿强模型的语气和格式但实际的动作决策完全跑偏。这篇研究正好解释了我当时遇到的困惑。它的核心洞察在于智能体和普通的大模型微调不是一回事。普通微调是“输入-输出”的映射学习你给模型看足够多的“问题-答案”对它就能学会这个映射。但智能体是一个序贯决策过程——它要在环境中一步步行动每一步的决策都会影响后续的状态分布。当你用强模型的轨迹去训练弱模型时弱模型学到的其实是“在强模型所处的状态分布下应该怎么做”但弱模型自己跑起来之后它进入的状态分布和强模型完全不一样。这就导致了一个经典的分布偏移distribution shift问题训练时看到的状态和推理时遇到的状态对不上模型自然就崩了。提示这个问题的本质和模仿学习Imitation Learning里的 compounding error 是同一个道理。每一步的小误差会累积最终让智能体偏离到训练数据从未覆盖的状态区域。所以这篇文章我想从从业者的角度把这篇研究的核心逻辑拆开讲清楚为什么弱模型模仿强模型会退化、on-policy 修正到底修正了什么、以及如果你自己正在做智能体微调应该怎么落地这套思路。不管你是刚入门智能体开发还是已经在做 qwen2.5-7b 微调行业大模型的实战这篇内容应该都能给你一些直接的参考。2. 核心问题拆解弱模型模仿强模型到底哪里出了问题2.1 智能体微调和普通大模型微调的本质区别很多人做大模型微调脑子里想的还是那套“喂数据-调参-评估”的流程。这套流程在单轮问答、文本分类、信息抽取这类任务上确实好用因为输入和输出之间是一个相对静态的映射关系。但智能体的工作方式完全不同它是一个感知-决策-行动-再感知的循环。举个具体的例子。假设你有一个销售智能体它的任务是帮用户查询产品库存、对比价格、生成报价单。这个过程中智能体需要调用多个工具库存查询 API、价格数据库、报价单生成器每一步的输出都会成为下一步的输入。如果第一步查库存的时候返回了一个“该商品暂时缺货”的结果那智能体接下来的策略应该是推荐替代品而不是继续走原来的报价流程。强模型比如 Gemini之所以强是因为它在每一步都能做出合理的决策即使遇到意外情况也能灵活调整。而弱模型本身的能力有限它在自己跑的时候很容易在某个中间步骤做出不太好的决策然后整个轨迹就偏了。如果你拿强模型的完整轨迹去训练弱模型弱模型学到的是“在强模型的状态下该怎么做”但它自己根本到不了那些状态。2.2 分布偏移是怎么一步步毁掉训练的我用一个更直观的类比来解释。假设你要教一个新手司机开车你给他看了一堆老司机的驾驶录像。老司机在高速上变道的时候看后视镜、打灯、加速一气呵成。新手看了录像之后理论上“知道”该怎么变道。但问题是新手在实际开车的时候他可能连方向盘都握不稳车速控制也不好等他准备变道的时候他的车已经偏离车道了。这时候录像里教的“看后视镜-打灯-加速”这套动作在他当前的状态下根本不适用。智能体微调也是同样的道理。强模型的轨迹数据里每一步的状态都是“强模型自己走出来的状态”这些状态往往处于一个比较理想的区域。弱模型在推理时由于自身能力不足很容易走到一些“边缘状态”——比如工具调用返回了异常、用户输入了模糊指令、多轮对话中上下文丢失等等。这些状态在训练数据里可能根本没出现过模型自然就不知道该怎么处理。更糟糕的是这种偏移是累积的。第一步偏了一点第二步就在偏了的基础上继续偏到第三步可能已经完全跑偏了。这就是为什么很多团队发现用强模型蒸馏出来的智能体在离线评估用固定数据集测试的时候指标很好看但一上线就拉胯。2.3 为什么“模仿”这个目标函数本身就有问题从目标函数的角度看模仿学习优化的是“在给定状态下我的动作和专家动作的差异最小”。这个目标在单步决策上是合理的但放到多步序贯决策里就有问题了。因为智能体的最终目标是“完成任务”而不是“每一步都像专家”。我举个例子。假设专家在某个状态下选择了动作 A最终任务成功了。但弱模型在这个状态下可能选择动作 B 也能成功甚至动作 B 对它来说更容易执行。如果强行让它模仿动作 A反而可能因为执行不到位导致失败。这就是所谓的因果混淆causal confusion——模型学到了表面上的动作对应关系但没有真正理解“为什么这个动作能导致成功”。Salesforce 这篇研究的价值就在于它没有停留在“蒸馏不行”这个结论上而是进一步提出了 on-policy 修正的方案。简单说就是让弱模型自己跑跑出来的轨迹再由强模型来修正然后用修正后的轨迹去训练弱模型。这样训练数据里的状态分布就和弱模型自己遇到的状态分布一致了分布偏移的问题自然就缓解了。3. on-policy 修正方案的核心机制与实操逻辑3.1 on-policy 和 off-policy 到底差在哪在强化学习和模仿学习的语境里on-policy 和 off-policy 的核心区别在于训练数据是从哪个策略产生的。off-policy 用的是“别人”产生的数据比如强模型的轨迹on-policy 用的是“自己”产生的数据。放到智能体微调的场景里off-policy 方案直接用 Gemini 或其他强模型生成的轨迹数据做监督微调SFT。数据质量高但状态分布和弱模型不匹配。on-policy 方案让弱模型自己在环境里跑收集它自己产生的轨迹然后对这些轨迹进行修正比如用强模型重新标注每一步的最优动作再用修正后的数据做训练。这两种方案的差异用一句话总结就是off-policy 教模型“在别人的状态下该怎么做”on-policy 教模型“在自己的状态下该怎么做”。显然后者更符合智能体实际部署时的需求。3.2 修正信号从哪里来on-policy 修正的关键在于“修正”二字。弱模型自己跑出来的轨迹肯定有很多不完美的地方你需要一个信号来告诉它“这一步应该怎么做更好”。这个信号可以来自几个地方第一种是强模型重标注。让弱模型跑出一条轨迹然后把这条轨迹的每一个状态拿出来让 Gemini 或 GPT-4 级别的模型来判断“在这个状态下最优动作是什么”。这样你就得到了一条“弱模型的状态 强模型的决策”的修正轨迹。第二种是环境反馈。如果任务本身有明确的成功/失败信号比如工具调用是否返回了正确结果、任务是否完成可以用这个信号来做拒绝采样rejection sampling——只保留成功的轨迹或者对失败的轨迹进行回溯修正。第三种是规则引擎或奖励模型。对于一些结构化程度比较高的任务比如 API 调用、表单填写可以用规则来判断每一步的正确性或者训练一个轻量的奖励模型来打分。实际操作中最常见的是第一种和第二种结合先用弱模型跑一批轨迹然后用强模型对失败轨迹进行逐步修正同时保留成功轨迹作为正样本。3.3 为什么这种方式比直接蒸馏更有效从信息论的角度看on-policy 修正提供的是针对弱模型自身错误分布的纠正信号。直接蒸馏提供的是“强模型怎么做”而 on-policy 修正提供的是“你在这种情况下做错了应该这样改”。后者的信息密度更高因为它是针对弱模型的具体缺陷来修正的。我自己的经验也印证了这一点。之前做 qwen2.5-7b 的行业大模型微调时一开始用 GPT-4 生成了一批标准问答对做 SFT效果一般。后来改成让 7B 模型自己先跑把跑错的 case 挑出来再用 GPT-4 重新标注正确答案只对这些错误 case 做微调效果提升非常明显。这和 Salesforce 这篇研究的思路是一致的。注意on-policy 修正的计算成本比直接蒸馏高因为你需要让弱模型先跑一遍再让强模型修正一遍。但从效果提升的幅度来看这个成本是值得的。4. 落地实操从环境配置到效果验证的完整流程4.1 环境准备与工具选型如果你要复现这套 on-policy 修正的方案需要准备几个核心组件基础模型弱模型可以选择 qwen2.5-7b、qwen3-0.6b 这类开源模型根据你的任务复杂度和算力情况来定。如果是做行业大模型微调7B 级别通常是一个比较好的起点既能保证一定的能力又不会对 GPU 资源要求太高。强模型用于修正的强模型可以是 Gemini、GPT-4 或其他闭源模型。如果预算有限也可以考虑用更大的开源模型比如 72B 级别来做修正。微调框架LoRA 微调是目前最主流的选择llamafactory 是一个比较成熟的工程框架支持多种模型和微调方式。如果你需要更灵活的定制也可以用 peft transformers 自己写训练脚本。智能体框架用于定义工具、环境和交互流程。LangChain LangGraph 是目前比较流行的组合适合做多智能体编排和复杂工作流。如果只是简单的工具调用用原生的 function calling 也能搞定。评估工具需要一套自动化的评估流程包括任务成功率、工具调用准确率、多轮对话一致性等指标。环境配置这块我建议先用一个小规模的实验跑通全流程确认方案可行之后再扩大规模。不要一上来就搞全量数据那样调试成本太高。4.2 数据收集让弱模型先跑起来第一步是让弱模型在目标环境中自由探索收集它自己产生的轨迹数据。这一步的关键是多样性——你要尽可能覆盖各种可能的状态包括正常情况和异常情况。具体操作上可以设计一批任务 prompt让弱模型用不同的策略去尝试。比如对于销售智能体可以设计“查询库存”“对比价格”“生成报价”“处理缺货”“处理用户投诉”等多种场景。每个场景跑几十到几百条轨迹记录下每一步的状态、动作和结果。这里有一个实操心得不要只收集成功轨迹。失败轨迹往往包含更有价值的信息因为它们暴露了弱模型的真实缺陷。我一般会按照 7:3 的比例保留成功和失败轨迹失败轨迹用于后续的修正训练。数据格式上建议用 JSON 结构化存储每条轨迹包含{ task_id: sales_001, task_description: 查询商品A的库存并生成报价单, trajectory: [ {step: 1, state: ..., action: call_inventory_api, result: ...}, {step: 2, state: ..., action: call_price_api, result: ...} ], success: true, failure_reason: null }4.3 修正标注用强模型给弱模型“批改作业”收集完轨迹之后下一步是用强模型对轨迹进行修正。具体做法是把弱模型的每一步状态拿出来连同历史上下文一起喂给强模型让强模型输出“在这个状态下应该采取的最优动作”。这里有一个细节需要注意强模型的修正应该是“状态级”的而不是“轨迹级”的。也就是说你不需要让强模型重新生成一整条轨迹只需要让它对弱模型遇到的每一个关键状态给出动作建议。这样做的好处是修正后的数据既保留了弱模型自己的状态分布又引入了强模型的决策能力。实际操作中可以用这样的 prompt 模板你是一个智能体决策专家。当前智能体正在执行任务{task_description} 历史交互记录{history} 当前状态{current_state} 请判断当前状态下最优的动作是什么并简要说明理由。 可选动作{available_actions}强模型返回的结果就是修正后的动作标签。把这些修正后的状态-动作对整理成训练数据就可以用来微调弱模型了。4.4 微调训练LoRA 配置与参数选择数据准备好之后就可以开始微调了。以 qwen2.5-7b 为例用 LoRA 做微调的典型配置如下from peft import LoraConfig, get_peft_model lora_config LoraConfig( r16, # LoRA 秩一般 8-64 之间 lora_alpha32, # 缩放系数通常是 r 的 2 倍 target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM )训练超参方面我一般会用学习率1e-4 到 2e-4 之间LoRA 微调可以比全量微调稍大一些batch size根据显存来定7B 模型 LoRA 在 24G 显存上可以跑到 batch size 4-8epoch2-3 个 epoch 通常就够了太多容易过拟合warmup ratio0.03-0.1提示on-policy 修正的数据量通常比直接蒸馏少因为你是针对性地修正错误而不是从头教模型。所以训练 epoch 可以适当减少避免过拟合到修正数据上。训练过程中要密切关注 loss 曲线和验证集指标。如果发现 loss 下降但验证集效果变差说明可能过拟合了需要减少 epoch 或增加数据多样性。4.5 效果验证怎么判断方案是否有效效果验证是很多人容易忽略的环节。我建议从三个维度来评估任务成功率这是最直接的指标。在相同的测试任务集上对比微调前后的成功率。注意要用弱模型自己跑出来的结果而不是用强模型的结果。工具调用准确率对于需要调用外部工具的智能体工具调用的参数是否正确、调用时机是否合理都是关键指标。轨迹质量可以用强模型对弱模型的轨迹进行打分评估每一步决策的合理性。这个指标比单纯的成功率更能反映模型的真实能力。我自己的经验是on-policy 修正方案在任务成功率上通常能带来 15%-30% 的提升具体幅度取决于任务复杂度和弱模型的初始能力。如果弱模型本身太弱比如 0.6B 级别提升幅度可能有限因为它的基础能力不足以支撑复杂的决策。5. 常见问题与排查技巧实录5.1 修正数据质量不稳定怎么办这是最常见的问题。强模型在修正的时候有时候会给出过于理想化的建议比如“直接调用一个不存在的工具”或者“假设用户会提供额外信息”。这种修正数据如果直接拿来训练反而会引入新的问题。我的处理方式是加一层可行性过滤。具体来说在把修正动作加入训练数据之前先检查这个动作在当前环境下是否可执行。比如工具调用的话检查工具是否存在、参数是否合法如果是文本回复检查是否包含了环境不支持的信息。只有通过可行性检查的修正数据才会被保留。另外可以设置一个置信度阈值。让强模型在给出修正建议的同时输出一个置信度分数只保留高置信度的修正。低置信度的样本可以人工审核或者直接丢弃。5.2 弱模型跑不出有效轨迹怎么办如果弱模型太弱跑出来的轨迹全是失败的那 on-policy 修正就无从谈起了。这种情况下需要先做一个冷启动——用少量强模型的成功轨迹做初步微调让弱模型具备基本的任务执行能力然后再切换到 on-policy 修正。冷启动的数据量不用太大几百条高质量轨迹通常就够了。关键是覆盖核心场景和基本操作。冷启动之后弱模型至少能跑出一些部分成功的轨迹这时候再开始 on-policy 修正就比较可行了。5.3 训练和推理的状态不一致怎么排查这个问题通常表现为训练时 loss 正常下降但推理时模型表现很差。排查思路如下首先检查数据格式是否一致。训练数据的 state 表示和推理时的 state 表示是否用了相同的模板、相同的字段顺序。很多时候问题就出在这里比如训练时用了完整的 JSON 状态推理时只传了部分字段。其次检查动作空间是否一致。训练数据里的动作集合和推理时可选的动作集合是否完全对应。如果有新增或删除的动作模型可能会输出无效动作。最后检查上下文长度。如果推理时的上下文比训练时长很多模型可能会因为位置编码的问题表现下降。这种情况下可以考虑在训练时加入一些长上下文样本或者用滑动窗口的方式截断上下文。5.4 常见问题速查表问题现象可能原因排查方向解决方案微调后效果反而变差分布偏移严重对比训练和推理的状态分布改用 on-policy 修正或加入冷启动工具调用参数错误率高训练数据中工具调用样本不足统计各类动作的样本比例补充工具调用相关的修正数据多轮对话中上下文丢失训练时上下文长度不足检查训练数据的平均长度增加长上下文样本调整位置编码模型输出格式不稳定训练数据格式不统一检查数据模板一致性统一数据格式加入格式约束训练 loss 不下降学习率过低或数据质量差检查数据标注质量提高学习率过滤低质量数据5.5 几个我踩过的坑第一个坑是过度依赖强模型的修正。一开始我让强模型修正所有步骤包括那些弱模型本来做对的步骤。结果训练数据里充满了“强模型风格”的动作弱模型学完之后反而不像自己了。后来改成只修正失败步骤保留成功步骤的原样效果就好多了。第二个坑是忽略了环境反馈。有些任务的成功与否不是由单步动作决定的而是由最终结果决定的。如果只看单步修正可能会错过一些“短期看起来不对但长期正确”的决策。后来我在修正数据里加入了最终结果的标签让模型学习“什么样的动作序列能导致最终成功”。第三个坑是评估集泄漏。有一次我不小心把测试任务的一部分用作了训练数据导致评估指标虚高。后来我严格划分了训练集、验证集和测试集确保三者之间没有重叠。6. 这套方案还能怎么扩展on-policy 修正的思路其实不局限于智能体微调。任何涉及到序贯决策的场景都可以借鉴这套逻辑。比如多轮对话系统、代码生成中的迭代修改、机器人控制中的轨迹优化等等。另外一个值得探索的方向是迭代式 on-policy 修正。也就是说不是只做一轮修正而是让弱模型在修正后的数据上训练然后再跑一遍再修正再训练。这样迭代几轮之后弱模型的能力会逐步逼近强模型。当然迭代次数太多也会有过拟合的风险需要根据实际情况来定。还有一个方向是多智能体协作场景下的 on-policy 修正。当多个智能体需要协同完成任务时每个智能体的状态分布不仅取决于自己的策略还取决于其他智能体的行为。这种情况下修正信号的设计会更复杂但也更有研究价值。我个人在实际操作中的体会是on-policy 修正这套方法的核心价值不在于某个具体的算法而在于它提供了一种以弱模型为中心的训练思路。不要总想着让弱模型去模仿强模型而是要让强模型来帮助弱模型修正自己的错误。这个思路转变过来之后很多之前觉得棘手的问题都会变得清晰很多。