MiMo-V2.6工具调用复读：9万美元MOPD修订已上线

小米MiMo团队在9月27日发布的技术复盘中披露，MiMo-V2.6-Pro和Flash在代理任务中会反复发起无效工具调用；团队以约9万美元完成MOPD修订。修订模型已于9月25日06:00（UTC+8）上线小米官方API，调用名仍是mimo-v2.6-pro和mimo-v2.6-flash；自行部署旧权重的用户，需要换用名称带MOPD后缀的新检查点。

一名开发者在9月22日提交的故障单中记录，更新前的mimo-v2.6-pro曾在单次响应里发出最多120个并行工具调用，并把同一个无效调用重复13次；提报者写道“The model never adjusts.”。这些记录来自修订模型上线前的会话，呈现了故障的具体形态，不能当作更新后仍会以同样频率发生的测试结果。

长会话里，调用如何变成空转

这次故障出现在连续使用工具调查代码的任务中。模型通过OpenCode调用本地代码搜索工具，本应根据搜索、文件结构和调用关系查询的反馈逐步缩小范围，却在尚未收到同一批工具结果时，就把大量请求塞进一条响应。执行队列因此先行膨胀，后续请求也失去了依据上一项结果调整参数的机会。

其中一组无效请求使用rls_trace和intent=data_flow参数，缺少工具要求的对象；相同调用仍在同一响应中反复出现。另一组输出没有沿着分页结果给出的next_cursor继续查询，而是重新发起搜索。提报者用较短的对照请求发现，模型能够选用合适工具；异常更容易在多轮上下文累积后显现，因此不能仅凭一次简短调用正常，就认定代理工具链没有问题。

并行调用本身有合理用途：读取彼此独立的文件，或同时查询不同线索，都可能节省等待时间。问题在于信息与环境状态没有实质变化时，模型继续提交相同或高度相似的请求，任务却没有推进。大量调用属于洪泛，缺乏理由的再次调用属于复读；一次失控响应可以同时具有两种表现，也可能只出现其中一种。

只看结果，为何会留下奖励盲区

复盘把根源指向强化学习对最终正确率的偏重：如果一次任务最终答对，途中多次无效调用未必得到相称的负反馈。原有训练流程虽设置了洪泛惩罚，却要等单轮调用超过32次才触发；未越过门槛的冗余行为可能继续留在训练轨迹中。这个机制解释了为何模型可以在最终答案指标之外，养成耗费时间和上下文的调用习惯。

在曾出现复读的内部样本回放中，MiMo-V2.6-Flash训练早期已有单轮高调用量现象，随着训练推进，洪泛比例上升。团队曾在一个独立的小数据源上把惩罚门槛从超过32次收紧为超过8次，高调用量随训练下降，整体奖励未见明显损失。但效果需要继续训练才逐渐显现：按完整MixRL方案重新执行所需步骤，估算成本约231万美元。

更严的数量限制也没有完全解决复读。在内部问题样本的回放中，相关检查点把一组复读率从13.45%降到3.83%，仍有失败案例。原因之一是调用次数和调用必要性不是同一个问题：一批数量不多、却反复索取相同信息的请求，可能始终够不到数量门槛；相反，复杂任务也可能合理地需要多项并行查询。

MOPD修订针对的是调用行为

最终采用的MOPD方案先训练一个专门识别复读的强化学习教师模型，再把这种行为合入主模型。特化训练中，出现复读的输出得不到奖励；没有复读、同时也没有错误工具调用的输出才获得正向奖励。训练还约束教师模型与原模型保持接近，目的是减少修订对其他能力的扰动。这使停止无效调用成为训练目标，而不只是等待最终答案评分间接反映问题。

在内部回放样本上，特化教师模型经过12步、约7000条样本的训练后，使训练集和留出集中的复读率降为零。随后，团队将其通过MOPD合入主模型；Pro与Flash在不同上下文长度和代理运行环境下的单轮复读率明显下降，其他基准表现基本持平。约9万美元是这次完整修订训练的成本，约为重新执行MixRL方案估算成本的4%，不是面向用户收取的修复费用。

这组改善有明确的统计边界。主要指标是单轮内精确重复：在模型尚未收到工具反馈的一轮里，工具名相同、参数经JSON规范化后完全一致，才计为重复。它适合稳定回放和计数，却看不到参数略有差异的近似请求、收到反馈后再次陷入的跨轮循环，也看不到藏在exec脚本内部的实际调用。因此，指标下降说明被测行为减少，并不意味着所有形式的空转都有同等幅度的改善。

官方API、本地权重和桌面端的更新路径

直连小米官方API的开发者可以继续使用原有的两个模型调用名。修订发生在名称背后的服务端部署，单看请求中的模型名，无法判断一份历史响应是在切换前还是切换后生成。若通过第三方平台接入同名模型，实际使用哪个检查点取决于该平台的部署；小米公布的上线时间只适用于其官方API。

自行托管模型则要看已加载的权重。新发布的开放检查点带有MOPD后缀，旧实例不会因为客户端改了别名就自动获得修订；需要取得相应新权重，并让推理服务实际加载它。对照版本时，API模型名保持不变与本地检查点名称变化是两回事，不能用同一条规则判断两种接入方式。

MiMo Desktop在复盘中被列为曾出现复读的使用场景。小米同时表示，将重置桌面端用户当前使用窗口的剩余额度，但没有列出用户必须手动替换权重或升级客户端的步骤。桌面端用户无需照搬本地部署的检查点替换流程；额度重置的承诺，也不等于每段既有会话都已重新运行。

新权重出现了另一种用户报告

修订版发布后，一名开发者在9月29日提交的问题单中报告，自托管的MiMo-V2.6-Pro-MOPD在连续两次正确调用同一工具后，曾拒绝第三次使用不同参数的合法调用，并编造工具不存在的限制。这是特定vLLM环境下的用户复现，报告将现象描述为间歇性出现；它不能直接推断官方API或MiMo Desktop具有相同行为。

这份报告指向修订后的一个实际边界：避免无意义复读时，模型仍需允许有新信息需求的再次调用。对长会话代理任务而言，已发布的检查点带来了明确的版本切换路径；修订对近似重复、跨轮循环以及合法重复调用的覆盖程度，还需要更完整的公开评估来界定。