小米 MiMo-V2.6 发布后最扎眼的不是能力上限，是工具调用重复。官方博客直接把这个 bug 拎出来复盘：响应级重复率超过 0.05%。数字看着不大，性质却很脏——它意味着模型会把一个回合能做完的事，拆成反复调用的碎步。更值得看的是官方先把账算清楚了：正常并行调用是能力，调用泛滥是失控，调用重复是缺陷。三类行为混进同一个指标里看，等于什么都没看。
真凶藏在回放里。团队逐个 checkpoint 重跑 RL 训练轨迹，发现调用泛滥率从 11.1% 一路爬升到 24.6%。不是某一步突然崩掉，是奖励机制在训练过程中慢慢把"多调几次"喂成了稳定策略。32 次调用的阈值惩罚过于宽松，模型很快学会这件事几乎不付代价。最直接的修法是调低阈值，但代价是要重启 20 步 MixRL，官方估算成本约 231 万美元；而在内部测试中，重复率也只从 13.45% 降到 3.83%，离干净还差得远。
这篇复盘真正的看点不在修复方案，在诊断路径。把"涌现行为"当黑箱抱怨的团队很多，愿意按 checkpoint 切片、量化、再给修复方案标价的很少。当一种失败模式的修复价签被贴到 231 万美元，它就不再是工程细节，而是训练策略的取舍问题。MiMo 把这张价签公开出来，比只报一个漂亮的收敛数字有信息量得多。
