小米 MiMo 团队 9 月 27 日发了一篇技术博客，复盘 MiMo-V2.6 上线后被开发者反复吐槽的一个毛病：在编程代理里，模型会一遍遍发出相同或几乎相同的工具调用，上下文和算力都烧掉了，任务却原地不动。修复后的权重已经开源，文件名带 MOPD 后缀；API 平台从 9 月 25 日早上 6 点（北京时间）起就已切到新版本，MiMo Desktop 用户当期剩余额度被整体重置，算是补偿。
先把”调用多”和”调用重复”分开
博客没有把所有”调用太多”都当成病。小米列了三种情况：并行调用是正常优化，几个调用各查各的信息；调用泛滥是数量超出任务所需；调用重复则是环境状态和已知信息都没变，模型还在重复同一个动作。团队要修的是第三种。
按小米的内部评估，回复级别的重复率超过了 0.05% 的容忍线，各环境差别不小：
| 环境 | Flash | Pro |
|---|---|---|
| OpenCode | 1.02% | 0.54% |
| Claude Code | 0.27% | 0.10% |
| MiMo Desktop | 0.19% | 0.19% |
| MiMo Code | 0.11% | 0.07% |
OpenCode 里 Flash 版的数字最难看，大约每 100 次回复就有 1 次在打转。
病根在强化学习阶段
团队回放了强化学习各个检查点，发现单轮发出 10 次以上调用的样本占比，从第 0 步的 11.1% 一路升到第 20 步的 24.6%；在 MiMo Code 环境里更夸张，从 30.6% 升到 41.7%。训练里原本设了惩罚：单轮超过 32 次调用才扣分。从第 15 步起，触发这条惩罚的样本明显变多，说明 32 这个门槛太松，没能拦住模型养成”多调几次总没错”的习惯。
博客给了一组很直观的概率：修复前，模型在第 12 次调用的位置选择继续调用的概率是 94.56%，选择收手只有 5.43%。粗略理解，就是它几乎不会自己停。
两条修法，差了一个数量级
第一条路最直接：把惩罚门槛从 32 降到 8，用原来的 MixRL 流程重跑。内部测试里重复率从 13.45% 降到 3.83%，但要回退 20 个训练步重新训，小米估算成本约 231 万美元，而且换个数据集效果就不稳。
最后采用的是 MOPD，也就是多教师在线蒸馏。做法是拿内部收集的重复样本，单独训一个专门学”什么时候该停”的强化学习教师，只跑了 12 步、用了约 7000 条样例；再把主模型回退 5 步，在教师引导下接着训。整套下来约 9 万美元，是前一方案的 4% 左右。
效果上，第 12 次调用位置的收手概率从 5.43% 提到 92.17%。按博客的累计停止曲线，修复前要到第 59 次调用，模型停下来的概率才过半；修复后到第 8 次调用，这个概率已经是 99.87%。小米称各平台重复率大幅下降，不同上下文长度下表现一致，整体基准分数没有掉。
放回 V2.6 这条线上看
MiMo-V2.6 是 9 月 22 日发布并开源的，当时小米最强调的是后训练规模：据媒体披露的账目，Pro 和 Flash 各跑 30 步强化学习，合计成本约 350 万美元。五天后这篇复盘，等于把那轮训练留下的一个副作用摊开来讲，连”本来可能要多花 231 万美元”都写了出来。
国内模型团队公开发布后事故复盘的并不多，更少见的是把失败方案的成本一起列出。对在 OpenCode、Claude Code 里接国产模型干活的开发者来说，更实际的一点是：如果前几天遇到过 MiMo 反复读同一个文件、反复跑同一条命令，现在的 API 已经是修过的版本，自部署的用户则需要换成带 MOPD 后缀的权重。这些重复率数字都来自小米内部评估，第三方复测结果目前还没有出来。
参考来源：小米 MiMo 团队技术博客、CocoLoop；各环境重复率、泛滥率与两种修复方案成本以小米内部评估口径为准。