小米 MiMo-V2.6 诊断并修复工具调用重复问题，用 MOPD 将修复成本降至 MixRL 方案的 4%

在 MiMo-V2.6 发布之后，工具调用重复成为影响用户体验的最显著问题之一。在 MiMo Desktop、MiMo Code、OpenCode 以及其他 agentic 场景中，模型有时会反复发出相同或高度相似的工具调用，消耗大量时间和上下文，却无法取得有意义的进展。

我们的内部评估证实了这一模式：响应级别的重复率超过了 0.05%。下表列出了 MiMo-V2.6-Flash-RL 和 MiMo-V2.6-Pro-RL 在不同 agent harness 下的重复率。

MiMo-V2.6-Flash-RL 和 MiMo-V2.6-Pro-RL 在不同 agent harness 下的工具调用重复率

追溯工具调用重复的根源

为了理解这一问题，我们首先区分正常的并行工具调用、工具调用泛滥和工具调用重复。

并行工具调用是提升 agent 效率的标准方式。例如，agent 可以一次性读取多个相关文件，或并行运行多个独立查询。即使是对同一工具的调用，只要服务于不同的信息需求，也不算重复。工具调用泛滥是指模型发出的调用数量远超任务所需，或超出执行环境能够有效处理的范围，从而造成执行队列和待处理工具结果的积压。

相比之下，工具调用重复指的是没有合理理由的重复动作。即使可用信息或环境状态都没有实质性变化，也没有正当理由重试或验证结果，模型仍持续生成语义相同或高度相似的调用。这可能发生在单次响应内、工具反馈后的多轮对话中，或表现为对同一操作序列的循环。失败后的合理重试、必要的状态轮询，以及修改代码后重新运行测试，在此都不算作重复。

泛滥和重复可以独立发生，但也可能相互强化。模型可能在一次响应中发出大量重复调用，并在后续轮次中延续同样的行为，叠加浪费的计算和上下文使用，却几乎没有进展。从用户的角度看，工具一直在运行，但 agent 却停滞不前，导致等待时间变长、体验无响应，甚至任务失败。

以上描述是从行为层面定义重复。由于语义等价在大规模场景下难以可靠检测，我们在本文中使用一个更窄但可复现的指标：轮次内精确重复。我们将一次 assistant 轮次中在任何工具反馈之前发出的整批调用视为一个单元。当两次调用调用同一工具，且其参数在 JSON 规范化后完全相同时，即计为重复。如果一个轮次包含 N 次调用和 U 次唯一调用，其轮次内精确重复率为：

(N − U) / N

这个指标有两个优点。第一，由于同一轮内的调用之间没有工具反馈到达，重复通常无法被解释为结果驱动的重试。第二，该判断可以直接从单轮中重放和复现。然而，它只是可观测重复的下界，而不是完整的重复率或泛滥程度的度量。它排除了三种重要情况：工具反馈后的跨轮重复；参数略有不同但服务于同一信息需求的近似重复；以及在代码模式执行框架内发起的调用，此时模型只暴露一个 exec 调用，而底层工具调用仍嵌入在其脚本中。

为了确定该问题何时出现，我们将一组固定的、曾表现出重复的内部示例，针对 RL 训练不同阶段的检查点（第 0、5、10、15 和 20 步）进行了重放。在每个检查点评估相同的示例，使我们能够追踪该行为在训练过程中如何演变。

对于 MiMo-V2.6-Flash-RL，重放示例中仍表现出泛滥（单轮超过十次工具调用）的比例在 RL 第 0 步时已经达到 11.1%，到第 20 步时泛滥率上升至 24.6%。这一趋势在 MiMo Code 下尤为明显，其泛滥比例在开始时已经达到 30.6%，并在训练后期增长至 41.7%。

尽管我们的 RL 流程中已存在工具调用泛滥惩罚，这一增长仍然发生了。在 rollout 期间，如果模型在单轮中发起超过 32 次工具调用，我们会提前停止该 rollout 并将其奖励设为零。在随后的梯度更新中，之前的轮次被掩码屏蔽，惩罚仅应用于触发该规则的那一轮。该轮中的每个 token，包括思维链 token，都被纳入惩罚。

随后我们检查了相应的训练指标。模型在训练早期几乎从未触发泛滥惩罚。然而，从大约第 15 步开始，单轮工具调用超过 32 次的示例数量开始明显上升，并随着训练推进持续增加。

进一步分析表明，该阈值过于宽松。使用来自 general/dataset-epqd 数据源的 MiMo-V2.6-Flash 训练轨迹，我们测量了单轮包含超过八次工具调用的示例比例。在 RL 第 0 步时，已有一小部分表现出高量工具调用。由于低于 32 阈值的行为未被惩罚，它在训练过程中逐渐被放大，最终发展成越过阈值的严重泛滥。一些泛滥轨迹还包含重复或高度相似的调用，但我们此处的分析聚焦于异常调用量，并不将泛滥等同于重复。

代价高昂且泛化有限的修复

最直接的解决方案是降低洪泛惩罚阈值。在一个小型、隔离的 general/dataset-epqd 数据源上进行的单独实验中，我们将阈值从 32 次调用降低到 8 次，并从 MiMo-V2.6-Flash 的第 28 步检查点恢复训练。包含超过 8 次调用的轮次数量大幅下降，表明更严格的惩罚有效抑制了洪泛，且整体奖励没有明显损失。

缺点在于，该效果仅在约 20 个训练步骤后才显现。因此，在全规模上应用此修复将需要重新启动 20 步的 MixRL，估计成本为 231 万美元。

环境级惩罚在完整的内部评估集上也泛化不佳。使用所得检查点重放重复案例，将重复率从 13.45% 降至 3.83%，但并未消除该问题。

更严格惩罚检查点的重放重复率。History N 表示被重放请求的可见历史中已包含 N 个具有 ≥10 次工具调用的轮次

一个更高效且更具泛化性的解决方案

因此，我们需要一个既训练高效、又能在训练分布之外的真实场景中保持稳健的解决方案。我们最终采用了基于 MOPD 的方法（多教师在线策略蒸馏）。

我们首先使用内部收集的重复示例训练了一个专门的单轮 RL 教师。当发生重复时，一次 rollout 获得 0 奖励；只有当它既不包含重复也不包含错误工具使用时，才获得 1 奖励。我们还应用了 KL 损失，以使教师接近原始 RL 策略。仅经过 12 个训练步骤（包含约 7,000 个示例）后，该教师就在训练集和留出集上将重放重复降至零。

为了在更细的层面理解其机制，我们检查了从 RL 轨迹中采样的一条轨迹。在修复之前，模型发出了 59 次工具调用。在每个 <tool_call> token 位置，我们比较了修复前后模型分配给 <|im_end|>（轮次结束 token）的概率。

我们还计算了位置 k 处的累积停止概率：

F_k = 1 − ∏_i=1^k (1 − p_i)

其中 F_k 是模型在第 k 次工具调用前停止的概率。

在这个示例中，修复后的模型有 99.87% 的概率在八次工具调用内停止，并且在从第五次到第二十次的每个位置都表现出强烈的停止倾向。修复前，即使经过 59 次调用，累计停止概率仍只有约 50%。

第 12 次工具调用位置的前四 token 概率让这一变化尤为明显。修复前，模型有 94.56% 的概率继续发起另一次工具调用。经过 RL 训练后，它将 92.17% 的概率分配给结束本轮对话。专门的教师模型已经学会了何时停止；剩下的挑战是通过 MOPD 将这一行为合并到主模型中。

具体来说，我们将最终的 MOPD 运行回滚了五步，引入重复专用的 RL 教师模型，并使用 teacher-prefix OPD 继续训练。更多细节见技术报告第 5.6 节。训练期间，重复专用的 flood_opd_loss 稳步下降，而整体 opd_loss 保持稳定。

最终对比如下所示。经过 MOPD 后，MiMo-V2.6-Pro 和 MiMo-V2.6-Flash 在不同上下文长度和 agent harness 下的重复率均大幅下降，而在更广泛基准套件上的性能保持稳定。完整训练运行成本约为 90,000 美元，仅为 MixRL 替代方案估计成本的 4%。

新 Checkpoint 发布，MiMo Desktop 配额重置

我们已在 Hugging Face 上的 MiMo-V2.6 集合中开源了解决工具调用重复问题的最新 MOPD checkpoint。对应的模型名称带有 MOPD 后缀。

作为对用户的致歉，我们将为所有 MiMo Desktop 用户重置当前使用窗口中的剩余配额。

更新后的模型自 9 月 25 日 06:00 (UTC+8) 起已在我们的 API 平台上线。模型名称保持不变：mimo-v2.6-pro 和 mimo-v2.6-flash。

我们希望这篇文章能为诊断和解决 RL 过程中涌现的行为提供有用的经验：这些问题可能看似微小、能躲过标准指标，却会实质性地影响模型在多样化场景中的真实表现。