小米开源模型MiMo-V2.6：大规模强化学习如何炼成比肩闭源旗舰的Agent能力

1. 从标题拆解这次开源模型的技术路线

1.1 标题里藏着的三个关键信号

看到“罗福莉押注大规模RL、小米最强开源模型亮相”这个标题，我第一反应不是去看参数表，而是去拆标题里的动词和名词。“押注”这个词很重，说明这不是一次常规的版本迭代，而是把训练资源集中砸在了一条特定路线上。“大规模RL”是路线，“6天烧掉2000多万”是代价，“多个Agent基准比肩闭源旗舰”是结果。三个信号串起来，指向一个很明确的判断：这个模型的核心竞争力不在预训练阶段的堆料，而在后训练阶段用强化学习把Agent能力拉到了接近闭源旗舰的水平。

热词里反复出现MiMo-V2.6、强化学习、Agent、开源模型、MoE，这几个词基本框定了技术讨论的范围。MiMo-V2.6是模型代号，MoE是架构底座，强化学习是训练方法，Agent是能力落点。把这四个词连起来读，就是一句话：一个基于MoE架构的开源模型，通过大规模强化学习训练，在Agent任务上做到了接近闭源旗舰的表现。这个逻辑链条里，每一环都有值得展开的技术细节。

我之所以对这个标题感兴趣，是因为它触及了当前开源模型竞争的一个核心转折点。过去大家比的是预训练loss、比的是benchmark分数，现在开始比后训练的效率、比Agent场景的落地能力。这个转变意味着，模型能力的上限不再只由参数规模和训练数据量决定，训练方法和任务设计同样能拉开差距。对于做Agent开发的团队来说，这意味着开源模型第一次在“能干活”这个维度上有了和闭源旗舰掰手腕的资格。

1.2 为什么是MoE而不是稠密模型

MoE架构在这类模型里几乎是必然选择，原因不复杂。Agent任务对模型的要求很分裂：一方面需要足够大的知识容量来理解复杂指令和工具调用格式，另一方面又需要足够低的推理成本来支撑多轮交互和并行调用。稠密模型很难同时满足这两点，参数大了推理贵，参数小了知识不够。MoE的做法是把参数拆成多个专家，每次推理只激活其中一部分，这样总参数量可以做得很大，但实际计算量控制在可接受范围内。

热词里有人问“moe架构要全部参数进显存吗”，这个问题问到了点子上。MoE的显存占用和稠密模型不一样，虽然总参数量大，但推理时每个token只路由到少数几个专家，所以激活参数量远小于总参数量。不过实际部署时，所有专家的权重还是需要加载到显存里，只是计算时只用到其中一部分。这就带来一个工程上的权衡：显存占用按总参数量算，计算量按激活参数量算。对于显存有限的场景，可以通过专家并行或者量化来缓解，但会牺牲一定的推理速度。

MoE的另一个关键是负载均衡。热词里出现了“moe负载均衡代码”，说明不少人在实际训练中遇到了专家利用率不均的问题。如果路由网络总是把token分配给少数几个专家，其他专家就得不到充分训练，相当于浪费了参数容量。常见的做法是在训练loss里加一个辅助的负载均衡损失，惩罚专家利用率的方差。这个损失的系数需要调，太大了会影响主任务的学习，太小了起不到均衡作用。我在实际项目中试过，系数设在0.01到0.05之间比较稳妥，具体要看专家数量和任务复杂度。

1.3 大规模RL到底“大”在哪里

“大规模RL”这个说法容易让人误解，以为只是训练步数多或者batch size大。实际上，这里的“大”更多体现在三个维度：任务多样性、 rollout 规模和奖励信号密度。Agent任务不像数学题那样有唯一正确答案，同一个指令可能有多种合理的工具调用路径，所以需要大量多样化的任务来覆盖不同的交互模式。rollout规模指的是每次策略更新前采集的轨迹数量，这个数字直接决定了梯度估计的方差。奖励信号密度则决定了学习效率，稀疏奖励下模型很难知道哪一步做对了，需要设计中间奖励或者过程奖励来引导。

6天烧掉2000多万这个数字，拆开来看主要是算力成本。大规模RL的算力消耗主要来自两部分：策略模型的推理（生成轨迹）和奖励模型的推理（打分）。如果奖励模型本身也是大模型，那推理成本会翻倍。再加上Agent任务通常需要多轮交互，每条轨迹的长度可能是普通文本生成的好几倍，整体算力消耗就上去了。这个成本对于中小团队来说确实很高，但考虑到它换来的是Agent基准上比肩闭源旗舰的表现，从商业角度看是划算的。

热词里有人问“现在开源小模型有好用的么”，这个问题和上面的成本讨论直接相关。大规模RL训练出来的模型，如果参数量控制在合理范围内，推理成本是可以接受的。关键是看激活参数量和推理框架的优化程度。如果模型能在消费级显卡上跑起来，那对于Agent开发者来说就是一个很有吸引力的选择。毕竟闭源旗舰的API调用成本也不低，而且有速率限制和数据隐私的顾虑。

2. Agent能力到底是怎么被RL训练出来的

2.1 Agent任务和普通对话任务的区别

普通对话任务的目标是生成流畅、合理的回复，评价标准相对主观。Agent任务的目标是完成一个具体操作，比如查天气、订机票、发邮件，评价标准是任务是否成功。这个区别决定了训练方法的不同。对话任务可以用人类反馈的强化学习来优化，因为人类可以判断回复好不好。Agent任务更适合用可验证的奖励信号，比如任务是否完成、工具调用格式是否正确、中间步骤是否合理。

热词里有人问“harness和agent区别”，这个问题在训练语境下很重要。Harness通常指的是测试框架或者评估工具，负责给Agent提供环境、执行工具调用、记录结果。Agent则是被训练的策略模型，负责决定下一步做什么。在RL训练中，harness的质量直接影响训练效果。如果harness的环境不稳定，或者工具调用的返回格式不一致，模型学到的策略就会有问题。我在实际项目中遇到过harness超时导致轨迹截断的情况，模型会把超时误认为是任务失败，从而学到错误的策略。

Agent任务的另一个特点是状态空间很大。普通对话任务的状态就是对话历史，相对紧凑。Agent任务的状态包括环境状态、工具返回结果、中间文件等，维度高得多。这就要求模型有很强的上下文管理能力，知道哪些信息重要、哪些可以忽略。热词里出现“agent记忆”，说明大家对这个能力很关注。在实际训练中，可以通过设计记忆相关的辅助任务来强化这个能力，比如让模型在长轨迹中检索关键信息。

2.2 奖励设计：从稀疏到密集的工程实践

奖励设计是Agent RL训练中最难的部分。最直接的奖励是任务完成与否，但这是稀疏奖励，模型很难从中学到有效的中间步骤。举个例子，如果任务是“帮我在电商网站上买一双鞋”，模型需要依次完成打开网站、搜索商品、筛选尺码、加入购物车、结算等步骤。如果只在最后给奖励，模型不知道前面哪一步做对了、哪一步做错了。所以需要设计过程奖励，对每个合理的中间步骤给予正向信号。

过程奖励的设计需要领域知识。对于工具调用类任务，可以奖励格式正确的调用、奖励选择了合适的工具、奖励参数填写正确。对于多轮交互任务，可以奖励信息收集的完整性、奖励没有重复询问已知信息。这些奖励信号可以通过规则引擎生成，也可以用一个小模型来打分。规则引擎的优点是稳定、可解释，缺点是覆盖不了所有情况。小模型打分的优点是灵活，缺点是有噪声、可能被策略模型钻空子。

热词里出现“agent evals”，说明评估也是奖励设计的一部分。评估集的质量决定了训练的方向。如果评估集只覆盖简单任务，模型就会在简单任务上过拟合。如果评估集包含对抗性任务，模型就能学到更鲁棒的策略。我在实际项目中会把评估集分成三部分：基础任务、困难任务、对抗任务。基础任务用来监控基本能力，困难任务用来推动能力边界，对抗任务用来发现策略漏洞。

2.3 策略优化：PPO还是其他

策略优化算法的选择直接影响训练稳定性和效率。PPO是目前最常用的算法，优点是稳定、调参相对容易，缺点是样本效率低、需要大量rollout。对于Agent任务，rollout成本很高，所以样本效率很重要。有些团队会尝试GRPO或者DPO的变体，这些算法不需要critic网络，显存占用更低，但稳定性和最终效果需要仔细调。

热词里出现“trl 强化学习”和“iql离线强化学习”，说明大家在探索不同的算法路线。TRL是Hugging Face的强化学习库，封装了PPO、DPO等常用算法，适合快速实验。IQL是离线强化学习算法，适合有大量历史轨迹但无法在线交互的场景。对于Agent训练，在线交互通常更有效，因为模型可以探索新的策略。但如果环境成本很高，离线强化学习也是一个选择。

实际训练中，策略优化的一个关键问题是KL散度的控制。KL散度衡量的是当前策略和参考策略的差异，如果KL太大，模型会偏离预训练知识，导致通用能力下降。如果KL太小，模型学不到新东西。常见的做法是设置一个KL阈值，超过阈值就停止更新或者调整惩罚系数。这个阈值需要根据任务难度和模型规模来调，没有固定值。我在实际项目中会从0.01开始试，根据训练曲线调整。

3. 实操：从零搭建一个Agent RL训练流程

3.1 环境准备和依赖安装

搭建Agent RL训练环境的第一步是确定技术栈。Python是必须的，PyTorch是主流选择。强化学习库可以用TRL或者自己实现，Agent环境可以用Gymnasium或者自定义。热词里出现“gymnasium cartpole 强化学习入门代码”，说明Gymnasium是入门的好选择，但Agent任务通常需要更复杂的环境，可能需要自己写。

依赖安装的顺序很重要。先装PyTorch，再装transformers和trl，最后装环境相关的库。版本兼容性是个坑，不同版本的trl对transformers的版本要求不一样。我建议用conda创建一个独立环境，避免和系统Python冲突。具体命令如下：

conda create -n agent-rl python=3.10 conda activate agent-rl pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 pip install transformers==4.40.0 trl==0.8.6 gymnasium==0.29.1

装完之后跑一个简单的测试，确认GPU可用、模型能加载。这一步看起来简单，但经常出问题。比如CUDA版本和PyTorch版本不匹配，或者显存不够导致模型加载失败。我建议先用一个小模型测试，比如Qwen2.5-0.5B，确认流程跑通后再换大模型。

3.2 定义Agent环境和工具接口

Agent环境的核心是工具接口。每个工具需要定义名称、描述、参数格式和返回值格式。描述要清晰，因为模型会根据描述来决定调用哪个工具。参数格式要严格，因为模型需要生成符合格式的调用。返回值格式要统一，方便模型解析。

举个例子，一个查天气的工具可以这样定义：

tools = [ { "name": "get_weather", "description": "查询指定城市的当前天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"} }, "required": ["city"] } } ]

环境需要实现reset和step方法。reset返回初始状态，step接收动作、返回新状态和奖励。动作可以是工具调用，也可以是文本回复。奖励根据任务完成情况计算。对于多轮任务，需要在环境里维护对话历史，确保模型能看到之前的交互。

热词里出现“agent execution terminated due to error”，这是环境实现中常见的问题。原因可能是工具调用超时、返回格式错误、或者模型生成了无法解析的动作。解决方法是在step方法里加异常处理，把错误信息作为观察返回给模型，让模型有机会纠正。同时要设置最大轮数，防止无限循环。

3.3 配置RL训练参数

RL训练的参数很多，关键的有这几个：学习率、batch size、rollout数量、KL系数、奖励缩放。学习率通常比预训练小一到两个数量级，因为RL训练容易不稳定。batch size和rollout数量决定了每次更新的样本量，越大越稳定但越慢。KL系数控制策略偏离参考模型的程度。奖励缩放影响梯度的幅度。

一个典型的配置如下：

training_args = PPOConfig( learning_rate=1e-6, batch_size=64, mini_batch_size=16, gradient_accumulation_steps=4, ppo_epochs=4, kl_penalty="kl", init_kl_coef=0.01, target_kl=0.1, gamma=0.99, lam=0.95, )

这些参数需要根据任务调整。如果训练不稳定，先降低学习率。如果模型学不到东西，先增加rollout数量。如果通用能力下降太快，先增大KL系数。我建议每次只调一个参数，观察训练曲线的变化。训练曲线主要看三个指标：平均奖励、KL散度、任务成功率。平均奖励应该上升，KL散度应该控制在阈值内，任务成功率应该稳步提升。

3.4 训练过程中的监控和调试

训练过程中的监控很重要，因为RL训练容易出问题。需要监控的指标包括：每个batch的平均奖励、奖励的方差、KL散度、策略熵、价值函数的loss。奖励方差大说明任务难度差异大，可能需要调整奖励缩放。策略熵下降太快说明模型过早收敛，可能需要增加探索。价值函数loss不下降说明critic网络没学好，可能需要调整学习率或者网络结构。

调试的一个常用方法是保存训练轨迹，定期人工检查。看模型在哪些任务上成功、哪些失败、失败的原因是什么。如果模型总是犯同样的错误，说明奖励设计有问题。如果模型在某些任务上表现很好但在另一些任务上很差，说明任务分布不均衡。我在实际项目中会每周做一次轨迹分析，把失败案例分类，然后针对性地调整奖励或者增加训练数据。

热词里出现“agent画图”，说明可视化也是调试的一部分。把训练曲线画出来，把Agent的交互过程画出来，能更直观地发现问题。比如如果Agent在某个步骤反复调用同一个工具，可能是工具描述不清楚或者奖励信号有问题。如果Agent在长轨迹中丢失了关键信息，可能是上下文管理能力不足。

4. 常见问题排查和避坑指南

4.1 训练不收敛的几种典型情况

训练不收敛是RL训练中最常见的问题，表现是奖励不上升或者波动很大。原因可能有几种：学习率太大、奖励信号太稀疏、KL系数太小、rollout数量不够。排查的顺序是先看奖励信号，如果奖励一直是零或者常数，说明奖励设计有问题。如果奖励有变化但波动大，说明rollout数量不够或者奖励方差太大。

学习率太大是新手常犯的错误。RL训练的学习率通常比监督学习小很多，因为策略更新的方差大。如果学习率是1e-5，可以试试降到1e-6。如果还是不稳定，可以试试1e-7。另一个常见问题是KL系数太小，导致模型偏离参考模型太远，通用能力崩溃。如果发现模型在通用任务上表现下降，先增大KL系数。

奖励缩放也容易出问题。如果奖励的绝对值太大，梯度会爆炸。如果奖励的绝对值太小，梯度会消失。常见的做法是把奖励归一化到0到1之间，或者用running mean和std来标准化。我在实际项目中会用奖励的滑动平均来调整缩放系数，确保梯度幅度在合理范围内。

4.2 Agent行为异常的排查思路

Agent行为异常包括：重复调用同一个工具、忽略工具返回结果、生成格式错误的调用、在简单任务上失败。排查的思路是从轨迹入手，看模型在每一步看到了什么、生成了什么、得到了什么奖励。如果模型重复调用同一个工具，可能是工具返回的结果没有包含模型需要的信息，或者奖励没有惩罚重复调用。如果模型忽略工具返回结果，可能是上下文太长导致信息丢失，或者模型没有学会关注工具返回。

格式错误的调用通常是因为模型没有充分理解工具的参数格式。解决方法是在训练数据里增加格式正确的示例，或者在奖励里对格式错误进行惩罚。另一个方法是使用constrained decoding，在生成时限制模型只能生成符合格式的token。这个方法效果很好，但需要额外的工程实现。

热词里出现“agent架构”和“agent框架”，说明大家在架构层面也在探索。不同的架构对训练效果有影响。比如ReAct架构把推理和行动分开，模型先思考再行动，这样更容易调试。Plan-and-Execute架构先制定计划再执行，适合长任务。选择哪种架构取决于任务特点，没有万能方案。

4.3 显存和算力优化的实用技巧

显存不足是训练大模型时的常见问题。MoE模型虽然激活参数量小，但总参数量大，显存占用高。优化显存的方法有几种：梯度检查点、混合精度训练、专家并行、量化。梯度检查点用计算换显存，适合显存紧张但算力充足的情况。混合精度训练用fp16或bf16，能省一半显存。专家并行把不同专家放在不同GPU上，适合多卡场景。量化把权重降到8bit或4bit，能省更多显存但可能影响效果。

算力优化的关键是提高GPU利用率。RL训练中，rollout阶段是推理密集，更新阶段是训练密集。如果rollout和更新串行执行，GPU利用率会很低。解决方法是用异步rollout，让推理和训练并行。另一个方法是增大batch size，提高每次更新的计算量。但batch size太大会导致显存不足，需要权衡。

热词里出现“开源模型量化档排名”，说明量化是大家关注的话题。对于Agent任务，量化可能会影响工具调用的准确性，因为量化会引入噪声。我建议在训练时用全精度，在部署时用量化。如果量化后效果下降明显，可以试试量化感知训练，在训练时就模拟量化的效果。

4.4 常见问题速查表

这个表是我在实际项目中总结的，覆盖了大部分常见问题。但每个项目的情况不同，需要根据具体情况调整。比如如果任务特别复杂，可能需要更长的训练时间和更多的rollout。如果环境特别慢，可能需要优化环境的执行效率。

5. 从这次开源模型看Agent开发的未来方向

5.1 开源模型在Agent场景的竞争力

这次MiMo-V2.6在Agent基准上比肩闭源旗舰，说明开源模型在Agent场景的竞争力已经上来了。过去大家用闭源API做Agent，主要是因为开源模型在工具调用、多轮交互、指令遵循上不够稳定。现在这个差距在缩小，对于成本敏感或者数据隐私要求高的场景，开源模型是一个可行的选择。

但开源模型也有劣势。闭源旗舰通常有更好的基础设施，比如更快的推理速度、更高的并发、更稳定的服务。开源模型需要自己部署、自己优化，工程成本不低。而且闭源旗舰的迭代速度快，开源模型可能刚追上又被拉开。所以选择开源还是闭源，需要综合考虑成本、隐私、性能、工程能力。

热词里出现“开源扣子怎么添加模型”，说明大家在尝试把开源模型集成到现有的Agent平台里。这个集成的关键是接口兼容性。如果平台支持OpenAI格式的API，那开源模型可以通过vLLM或者TGI暴露同样的接口，无缝替换。如果平台有自定义的接口，可能需要写适配层。我在实际项目中会优先选择支持OpenAI格式的推理框架，这样迁移成本最低。

5.2 大规模RL训练的门槛和机会

大规模RL训练的门槛确实高，6天2000多万的成本不是小团队能承受的。但这个门槛也在降低。一方面，开源社区在优化RL训练的效率，比如用LoRA减少可训练参数、用vLLM加速rollout、用FlashAttention减少显存占用。另一方面，云算力的价格在下降，按需租用GPU的成本比自建集群低。

对于中小团队，一个可行的策略是先用小规模RL做实验，验证奖励设计和任务分布，然后再放大规模。小规模实验可以用小模型，比如1B到3B的模型，在单卡或双卡上就能跑。等奖励设计和任务分布调好了，再换大模型、加算力。这样能避免一开始就烧太多钱。

热词里出现“强化学习入门”和“深度强化学习算法列表对比”，说明很多人在学习RL。我的建议是先跑通一个简单的例子，比如Gymnasium的CartPole，理解RL的基本流程。然后再看大语言模型的RL训练，理解PPO、GAE、KL惩罚这些概念。最后再看Agent RL，理解工具调用、多轮交互、奖励设计这些特殊问题。这个学习路径比较平滑，不会一上来就被复杂概念劝退。

5.3 Agent开发者的技能栈建议

从这次开源模型的发布来看，Agent开发者需要具备的技能栈在变化。过去可能只需要会调API、会写prompt就行。现在需要理解模型训练的原理，知道怎么设计奖励、怎么调参、怎么排查训练问题。这不是说每个Agent开发者都要去训练模型，但理解这些原理能帮助你更好地使用模型、更好地设计Agent系统。

具体来说，我建议Agent开发者掌握这几个技能：第一，理解Transformer和MoE的基本原理，知道模型的输入输出是什么、显存和算力怎么算。第二，理解RL的基本概念，知道策略、奖励、价值函数是什么。第三，会使用至少一个RL训练框架，比如TRL或者自己写训练循环。第四，会调试Agent行为，能从轨迹中发现问题、定位原因。第五，会优化推理性能，知道怎么用量化、怎么用vLLM、怎么调batch size。

热词里出现“agent开发学习路线”和“agent项目”，说明大家在找学习路径。我的建议是从小项目开始，比如做一个查天气的Agent、做一个订机票的Agent。先跑通流程，再优化效果。不要一开始就做复杂的多Agent系统，那样容易迷失在细节里。等单个Agent做熟了，再考虑多Agent协作、记忆管理、长期规划这些高级话题。

5.4 多智能体强化学习的挑战

热词里出现“多智能体强化学习”，这是一个更前沿的方向。多智能体RL的挑战在于环境是非平稳的，因为每个智能体的策略都在变化，其他智能体的行为对每个智能体来说都是移动靶。解决方法有几种：集中训练分散执行、对手建模、课程学习。集中训练分散执行是在训练时用全局信息，执行时只用局部信息。对手建模是让每个智能体预测其他智能体的行为。课程学习是从简单场景开始，逐步增加智能体数量和任务难度。

对于Agent开发，多智能体RL的应用场景包括：多个Agent协作完成一个任务、多个Agent竞争资源、多个Agent模拟社会交互。这些场景在游戏、机器人、仿真中很常见。但多智能体RL的训练成本更高，因为需要同时训练多个策略。而且评估更复杂，因为需要评估整个系统的表现，而不只是单个Agent的表现。

我在实际项目中试过多智能体RL，踩过的坑包括：智能体之间通信协议设计不好导致协作失败、奖励设计不合理导致智能体互相拆台、训练不稳定导致策略崩溃。经验是先从两个智能体开始，任务尽量简单，奖励尽量明确。等两个智能体协作稳定了，再增加数量。通信协议要尽量简单，能用共享观察就不用显式通信。奖励设计要确保个体奖励和全局奖励一致，避免出现“个体理性导致集体非理性”的情况。

6. 一些实操中的个人体会

6.1 奖励设计比算法选择更重要

我在多个Agent RL项目中的体会是，奖励设计的重要性远大于算法选择。PPO、GRPO、DPO这些算法之间的差距，在好的奖励设计面前可以忽略。但一个糟糕的奖励设计，用再好的算法也救不回来。奖励设计的关键是让模型知道“什么是好的行为”，而不是“什么是正确的答案”。Agent任务通常没有唯一正确答案，所以奖励应该鼓励合理的过程，而不只是正确的结果。

具体来说，我会把奖励分成几层：格式奖励、工具选择奖励、参数正确性奖励、任务完成奖励。格式奖励确保模型生成可解析的调用。工具选择奖励确保模型选了合适的工具。参数正确性奖励确保模型填了正确的参数。任务完成奖励确保模型最终完成了任务。这几层奖励的权重需要调，通常格式奖励权重最低，任务完成奖励权重最高。但格式奖励不能太低，否则模型会生成无法解析的调用，导致训练中断。

6.2 从小规模实验开始

我见过不少团队一上来就搞大规模RL训练，结果烧了很多钱但效果不好。我的建议是先用小规模实验验证想法。小规模实验可以用小模型、少数据、短训练。比如用1B模型、1000条任务、训练1天。如果小规模实验能看到效果，再放大规模。如果小规模实验都看不到效果，放大规模大概率也看不到。

小规模实验的另一个好处是快速迭代。奖励设计、任务分布、训练参数都需要反复调。小规模实验的迭代周期短，一天可以跑好几轮。大规模实验的迭代周期长，一周可能只能跑一轮。所以小规模实验适合探索，大规模实验适合验证。我在实际项目中会先用小规模实验找到大致方向，再用大规模实验确认效果。

6.3 监控和日志不能省

RL训练的不确定性很高，没有监控和日志就像盲人摸象。我建议至少监控这几个指标：平均奖励、奖励分布、KL散度、策略熵、价值函数loss、任务成功率。这些指标能帮你判断训练是否正常、是否需要调整。日志要记录每个batch的详细信息，包括输入、输出、奖励、KL。这样出问题时可以回溯。

监控的另一个作用是发现异常。比如如果奖励突然下降，可能是环境出了问题。如果KL散度突然上升，可能是学习率太大。如果策略熵突然下降，可能是模型过早收敛。这些异常如果不及时发现，可能会浪费很多算力。我在实际项目中会设置告警，当指标超过阈值时自动通知。这样即使不在电脑前，也能及时处理。

6.4 最后分享一个小技巧

如果你在训练Agent时发现模型总是学不会某个工具，可以试试在训练数据里增加这个工具的调用示例。示例不需要很多，几十条就够。关键是示例要覆盖不同的参数组合和不同的上下文。这样模型能更快地学会这个工具的用法。另一个技巧是把这个工具的奖励权重暂时调高，让模型更关注这个工具的学习。等模型学会了，再把权重调回来。

还有一个技巧是用课程学习。先训练简单任务，再训练困难任务。简单任务让模型快速学会基本格式和基本工具调用。困难任务让模型学会组合工具、处理异常。课程学习的难点是难度评估，需要根据任务的成功率来动态调整。如果某个任务的成功率超过80%，就可以加入更困难的任务。如果某个任务的成功率低于20%，就需要拆解成更简单的子任务。

这些技巧都是我在实际项目中试出来的，不一定适用于所有场景，但希望能给你一些启发。Agent RL训练是一个工程性很强的工作，需要不断试错、不断调整。保持耐心，关注细节，效果会慢慢出来的。