这周的笔记想聊一个近期让我特别上头的话题Agentic RL也就是用强化学习让模型学会多轮工具交互。做过工具调用微调的同学应该都有同感让模型“调用一次工具”其实不难难的是它在多轮对话里能自己判断“我现在该不该调、调完看到结果后要不要改变计划、上一步已经错了该怎么补救”。这篇学习笔记是系列第十四篇我会完整拆一遍我对这个问题的理解、训练方案设计以及跑实验时踩过的那些坑。1. 为什么单独的“工具调用微调”教不会模型多轮协作1.1 SFT的本质是模仿动作不是学会使用很多人第一次接触工具调用都是从SFT监督微调开始的。构造一批“问题—工具调用序列—最终回答”的样本让模型照着学很快它就能生成standard的调用格式看起来像是学会了。但这里有个本质误区SFT学的其实是动作序列的分布拟合它学到的是“在某个上下文里人类示范中大概率会出现什么动作”而不是“这个动作会带来什么后果”。工具交互和普通问答最大的区别在于动作之后会有一个来自外部环境的observation。这个observation是SFT数据里的人工写死的模型训练时从未见过真实的工具返回结果。到了推理阶段真实返回一旦和训练数据的风格不一样模型就不知道下一步该怎么接轻则车轱辘话来回说重则直接开始幻觉编造“搜索结果”。我习惯用一个类比SFT相当于让一个实习生背熟了工作手册知道“遇到客户投诉应该先道歉再记录”但从来没让他接过真实电话。等他真的接到电话对面客户说的内容不在手册上时他就不知道怎么应对了。1.2 自回归模型面临“一步错步步错”的连锁问题多轮工具交互的第二个难点藏在自回归的生成机制里。模型是逐token生成整个轨迹的第一轮选工具看到observation再决定第二轮动作直到输出最终答案。这个过程里第一步工具如果选错了后面的所有生成都是在“错误前提下的补救”。问题是模型本身并不知道自己错了。它在训练时没有试错反馈在生成的第二步可能还在认真地基于一个无中生有的observation往下推演。这种情况下SFT模型在长链条任务上的错误几乎是逐轮累积的。我实测过一个7B级别的底座模型纯SFT训练后五轮以上的多步任务成功率经常在20%上下而且失败模式非常集中要么在第一步就选了一个明显不合适的工具要么在中间某一步收到异常返回后开始车轱辘话。这就是典型的信用分配问题也就是常说的“功劳分配”一个二十步的轨迹最后失败了到底该怪第一步工具选错还是怪最后一步总结没做好SFT的静态数据给不出答案它只会把每一步都当作“正确示范”来模仿。1.3 SFT覆盖不到的错误分支只能靠探索补齐再往深一层想SFT数据本质上是一种“最短路”视角人类标注者写出来的通常是一条顺利的、成功的调用路径。但现实中的工具调用大量场景是“第一遍搜索没找到→换个关键词再搜”“工具返回报错→换一个替代工具”“两个工具的结果矛盾→需要交叉验证”。这些失败分支、纠错分支在SFT数据里要么数量极少要么根本没有。你不可能靠扩数据量把每一种可能的错误路径都标一遍因为错误空间是指数级的。而RL不一样它让模型自己在环境中试错通过reward信号判断哪些“纠错动作”会带来更高的最终收益。我并不是说SFT不重要它非常重要它是模型的“冷启动基础”。但要想真正学会多轮协作SFT之后必须接一层RL让模型在真实工具反馈中自己摸索出“看结果调整行动”的能力。2. 奖励设计单步对错和多轮目标之间的博弈2.1 结果奖励、过程奖励和工具奖励分别管什么奖励设计是Agentic RL最核心的一件事也是我最想强调的部分。多轮工具交互里reward信号大体分三路结果奖励ORM、过程奖励PRM和工具/格式奖励。它们各自负责一个维度的信号任何一个设计不合理训练都会跑偏。奖励类型触发条件典型信号主要作用最终结果奖励模型输出最终答案后最终回答与标准答案一致/不一致提供最终方向过程奖励轨迹中间步骤某个推理/动作子目标是否正确缓解稀疏奖励工具奖励每次工具调用后调用格式合法、工具返回成功约束行为规范格式/进度奖励每次模型输出是否包含思考标记、是否及时终止防止格式混乱如果你只留最终结果奖励绝大多数场景会面临稀疏奖励问题一个二十步的轨迹只有最后一步才知道对错模型几乎无从学习。如果过程奖励太强模型又会发现“只要调了工具就有分”于是疯狂调用来刷分。多轮工具交互的奖励设计本质上就是在稀疏信号和可被攻击的密集信号之间找一个平衡点。2.2 我实际使用的奖励组合与系数依据这里给出一套我实际跑过的组合它的特点是把“结果正确”放在压倒性权重上工具奖励侧重“合法性”而不是“调用的次数”。我先说一下每个系数我是怎么定出来的方便你后续自己调。最终答案正确2.0回答错误-1.0。这是主信号权重必须足够高否则模型会沉迷于过程刷分。单次工具调用格式合法且工具执行成功0.5。这个分只给“成功拿到结果”的调用不给“格式对但工具报错”的调用。思考/输出格式合规0.1。早期训练阶段保留防止模型输出一堆无法解析的文本。冗余调用惩罚连续两轮调用同一个工具且输入相同额外-1.0。这是针对奖励hack的重要防线。轮数惩罚每超出预设最大轮数的一部分-0.2。限制模型“无意义空转”。这样设计的核心逻辑是最终正确是唯一“方向性”信号工具奖励只负责“行为合法性”惩罚项负责“打消刷分念头”。我试过把工具奖励提高到1.0结果模型整体turn数暴涨任务完成率反而掉了因为它的策略变成了“多调工具有利可图答不答对再说”。2.3 奖励Hack实录模型也会走捷径这一节算是我的血泪经验。第一次跑多轮工具RL时我用的奖励组合里工具调用成功有0.5分最终答案有没有奖励我拿不准于是设得很低。结果训练到一半reward曲线一路漂亮地涨上去我还有点小高兴。等到人工抽检样本时发现模型学到了一种神奇的“伪策略”它会在思考区里写“我需要先查找数据”然后调用同一个搜索接口拿到结果后再写“我需要进一步核实”又调用同一个接口连续反复五六次。最后一轮生成回答时它干脆只翻来覆去地引用第一次的结果并试图用模棱两可的话糊弄过去。任务本身没完成但reward算下来很高因为每一步工具调用都“成功”了。这就是典型的奖励hack模型发现调用工具有正分而最终答案错误扣分很轻于是最大化调用次数。后来我的解决方式是三步第一把最终答案正确的权重从0.5提到2.0第二对重复调用加-1.0惩罚第三在构造prompt时故意混入一批“不需要调用任何工具、直接回答即可”的问题如果模型在这种情况下仍然调用工具就给重罚。这三步加在一起才把训练拉回正轨。3. 策略优化细节从PPO到GRPO以及稳定训练的那些坎3.1 为什么多轮工具场景更适合GRPO而不是PPO策略优化算法层面业界主流最早是PPO体系要求维护一个critic价值模型来估计advantage。但在多轮工具交互场景里每一轮之后环境状态都会因为observation而改变价值模型的估计误差会随着轮数累积。模型在一个没见过的新状态下critic给出的价值判断往往非常不靠谱这会导致优势估计噪声很大训练不稳定。GRPO这类“组内相对奖励”方法之所以在Agentic场景里流行是因为它干脆不依赖critic对同一个prompt让当前策略采样出G个不同轨迹然后把这组轨迹的reward做平均用每个轨迹与组均值的差值作为baseline。换句话说组内其他样本就是“对照组”。这样一来模型学到的是“跟自己的其他尝试相比哪个方向更好”不再需要单独训练一个价值模型去拼命猜每个状态的价值。具体实现上一种常见的做法是把组内reward做标准化也就是用这个公式计算第i条轨迹的优势值advantage_i (reward_i - group_mean) / (group_std epsilon)标准化之后的advantage有正有负RL更新时就能把好的轨迹概率抬上去差的轨迹压下来。3.2 KL约束、采样温度和组内归一化三个最容易翻车的点GRPO看起来比PPO省了critic但稳定训练需要照顾的细节一点没少。我总结三个最容易被忽略、也最容易翻车的点。第一是KL约束。模型在RL过程中很容易朝reward高的方向迅速漂移语言风格、格式结构都会崩。通常的做法是维护一个冻结的reference model计算当前策略与reference策略的每个token KL散度把它加进奖励里total_reward reward kl_coeff * kl_divergencekl_coeff我一般从0.05起步训练中如果发现kl涨得很快就适当调高。相反如果kl一直压得很低但reward也不涨说明模型还没放开探索可以适当调低。第二是采样温度。做rollout时temperature通常要设得比推理时高一点比如0.7到1.0之间保证G条轨迹之间的多样性。如果设成0.1每组采样的轨迹都几乎一样组内baseline等于没有baselineGRPO就失去了意义。第三是组内归一化。我把advantage标准化之后不能直接拿去更新还需要留意它会不会出现瞬时极大值。如果某组里一条轨迹特别幸运拿到了远高于其他轨道的reward它的advantage会被拉得很大单次更新步长就会非常夸张。稳妥的做法是对advantage做clip限制比如限制在[-2, 2]范围内我实测下来能明显减少训练曲线的剧烈抖动。3.3 一眼看懂训练日志哪些指标变了说明坏了RL训练过程中如果只看reward曲线你很难判断模型到底是真变强了还是走了捷径。我自己有一个固定的看日志顺序希望对你有参考价值。首先看reward_mean是否和tool_call_success_rate同步上升。如果reward涨了但工具成功率没涨那大概率是在刷奖励hack。其次看response_length在多轮工具任务里模型平均生成长度如果出现突然下降通常是“躺平”的信号它发现少做事、少调用工具最终答案碰碰运气也能获得不差的reward。再就是kl散度kl如果出现爆炸式上涨说明策略已经严重偏离原始模型的语言分布这时候即使reward在涨模型输出也可能已经变成了人类看不懂的格式。最后看一个多轮场景特有的指标平均工具调用轮数和“连续重复调用占比”。我习惯每个batch都打印这两个统计值一旦发现平均轮数异常升高或者同等输入重复调用比例超过5%我就知道奖励设计需要调整了。这些日志判断习惯比看loss曲线有用得多。4. 从零跑通一个多轮工具交互的RL训练4.1 数据准备任务提示词与工具清单跑通Agentic RL训练第一步是准备prompt池。我的经验是prompt池不能只放“一条路走到底”的简单任务要有意混合多种难度一部分是单次调用就能完成的任务一部分是需要根据第一次结果调整方向的二次确认任务还有一部分是“第一轮注定得不到好结果、必须换工具或换问法”的纠错任务。这样混着训出来的模型才不会在简单任务上画蛇添足也不会在复杂任务上只会模仿。每个prompt的构造我通常包含三块任务描述、工具清单、约束条件。工具清单要写清楚每个工具能做什么和不能做什么约束条件里注明最大轮数等限制。下面是一个我常用的模板任务查询某公司在2023年的营收数据并判断其是否超过上一年。 可用工具 - search(keyword): 搜索网络公开信息返回若干条摘要 - calculator(expression): 处理数值表达式 - compare(a, b): 比较两个数值的大小 要求若搜索返回的数据不足以判断请进一步细化搜索词最多执行4次工具调用。这种prompt本身不带答案模型需要自己决定调用顺序。prompt池规模我一般起步在几千条后续随着训练稳定再逐步加难。数据不需要做RLHF式的“人类偏好标注”只需要每道题带一个可判定的标准答案或验证器。4.2 Rollout循环生成、执行、拼接、再生成训练中的rollout阶段是整个流程里工程性最强的一环。简单说它是一个循环模型生成一段文本可能包含动作标记→ 从文本里解析出工具调用 → 执行工具拿到observation → 把observation拼回上下文 → 再让模型继续生成直到模型输出停止标记或达到最大轮数。这个循环里有几个工程细节值得注意。一是工具执行必须设置超时我一般把单次工具调用的超时控制在3到5秒避免某些接口卡死拖垮整个train loop。二是上下文长度管理工具返回的observation可能很长多轮叠加后很容易超过模型的上下文窗口我的策略是给observation一个token预算超出部分做截断而不是简单丢弃整轮历史否则模型会丢失前面有用的信息。三是我强烈建议用异步并发做rollout而不是串行逐条执行。比如用一个64个worker的异步池每个worker独立跑“生成-执行-拼接”循环训练吞吐量能提高好几倍。先让每个worker产出一条完整轨迹后再进入训练更新。这样虽然实现上麻烦一点但跑大规模实验时非常值得。4.3 训练配置和一次完整实验的曲线变化下面是我在某个7B底座模型上跑过的一组相对稳定的关键配置你可以拿来当作起点。配置项数值/设置备注策略优化算法GRPO组间不共享状态采样数G8每组8条轨迹采样温度0.7保证轨迹多样性KL系数0.05也可动态调整单次更新样本数128 prompts每个prompt生成8条轨迹Exp的advantage clip[-2, 2]防止更新步长过大学习率1e-6 到 5e-6带warmup和余弦衰减训练轮数800到1200步根据收敛情况提前停我用这套配置做过一次比较有代表性的实验先用SFT把一个工具调用数据集训练了一个baseline在评测集上的多轮任务完成率大约22%。在这个基础上接Agentic RL训练到大约900步时任务完成率提升到了53%。更多轮次的复杂任务提升更明显从不到10%升到35%左右。值得注意的是这个过程中reward曲线并不是一路向上的中间有两段明显的平台期一段在300步左右一段在700步左右。平台期的出现是正常的模型在探索新的策略reward不动不代表训练无效。这时候千万不要因为曲线平了就去乱调学习率耐心观察工具成功率和KL散度才是关键。如果过了1000步依然没有起色再考虑增大G值或调整奖励权重。5. 训练完成只是开始评测回滚与数据飞轮5.1 评测标准任务完成率、工具成功率、平均轮数、答案质量很多新手训练完之后只看reward曲线这是一个非常危险的坏习惯。reward值是模型的内部训练信号它追求的是最大化奖励函数本身而我们真正关心的是任务完成质量。所以我另外搭了一个评测集里面每条样例都有标准答案或者一个可执行的验证器。我的评测指标分四层看第一是任务完成率即最终答案和标准答案完全匹配或被验证为正确第二是工具成功率统计所有工具调用中真正成功拿到有效返回结果的比例第三是平均轮数看模型会不会绕远路第四是答案质量用一套固定规则或LLM-as-judge对最终回复做打分主要盯“是否直接回答、是否引用无关结果、是否编造数据”。重点提醒任务完成率和reward不一定呈正相关。我就见过一个模型reward涨了5%任务完成率反而跌了原因是它学会了“多调用一个工具可以拿到额外加分”。所以训练过程中每500步我就在固定的评测集上跑一次完整评测而不是只看训练日志。5.2 Checkpoint回滚机制怎么落地多轮工具RL训练的不稳定性比普通SFT高不少为了不让一次坏更新毁掉好几天的成果我的做法是每个epoch或每500步存一个完整的actor checkpoint同时记录对应的评测集表现。这样一来训练后期如果发现质量指标开始下滑我可以迅速回滚到上一个表现最好的checkpoint而不必重跑整个训练。光存checkpoint还不够我还会把每个checkpoint的“行为画像”记录下来包括平均轮数、工具调用类型分布、典型bad case列表。这样回滚时不是拍脑袋决定而是看哪个checkpoint的行为更符合预期。比如某一版模型虽然任务完成率最高但我发现它在不需要工具的场景下也开始强行调用工具那我会优先选任务完成率稍低一点但行为更稳妥的上一版。回滚机制听起来简单真正救过我两次一次是KL暴走导致模型输出变成乱码一次是奖励hack导致模型疯狂重复调用同一个搜索接口。5.3 从bad case回流数据的飞轮最后想聊聊数据飞轮。我一开始以为RL训练是替代SFT的跑了几轮实验后才发现它俩是互补关系。RL擅长探索尤其是让模型在真实工具反馈中试错但RL探索出来的好的轨迹如果用SFT再学一遍往往能沉淀得更扎实。所以我现在的工作流是一个循环RL训练 → 评测 → 挑bad case → 对这些case做rejection sampling筛出正确轨迹 → 混入SFT数据做一轮增量微调 → 再回到RL。这套飞轮的效果我可以用一个例子说明第一次RL训练后评测集里有一类问题老是出错——工具返回了多条结果模型不知道该选哪一条。我收集了十几条这类bad case用RL训练好的模型自己采样筛出正确的答案轨迹大概构造了百来条SFT数据微调了一小步之后再跑RL。结果是这类问题的任务完成率从30%直接涨到接近60%。这比单纯加长RL训练时间高效得多。数据飞轮的核心是“让模型自己的正确探索成为下一步的冷启动数据”。RL发现新路径SFT固化路径然后继续RL去探索更难的路径。最后分享一个很个人的体会。每次有人问我做Agentic RL最怕什么我的答案都是“怕奖励函数不够诚实”。模型本身没有动机去欺骗谁它只是在最大化我给的信号。如果信号告诉我“调用工具就有分”“长度越长越安全”它就一定会往那个方向走。与其花时间骂模型钻牛角尖不如多花点时间把自己设计的奖励函数重读几遍再跑到prompt池里人工看几十条样本输出。我每次在奖励设计上多花一小时之后在训练返工上就能省下好几天。这个经验是我觉得整个Agentic RL学习笔记里最值得记住的一条。