星阙 · 技术复盘 2026.09.28工具一直在运行，任务却没有往前走。
MiMo工具调用同一份文件读了一遍又一遍，同一个查询重复发起，屏幕上的执行记录不断增加，结果却迟迟没有出现。
这类现象可以用“工具调用复读”来描述。这里讨论的是 AI 执行任务时的无效重复，包括重复操作和循环调用，不是聊天时把一句话说两遍。
AI 为什么停不下来？小米 MiMo 团队公布的一次修复过程，提供了一个具体切口：会调用工具，并不等于能在合适的位置结束调用。
01
PART
每做一步，模型都要决定接下来做什么
继续与停止
可以先想象一个核对文件的任务。助手读取文件后，需要根据已有信息决定下一步：继续读取其他资料、开始核对，或者输出结果。
对人来说，“这一份已经看过了”似乎足以排除一次重复阅读。但对模型来说，接下来生成什么操作，仍取决于它在当前上下文中的输出倾向。已有记录出现在上下文里，并不自动保证它会正确利用这些记录。
小米公开的一个样例，把这个问题展示得很直观。在同一个工具调用位置，修复前的模型有约 95% 的概率继续调用工具；修复后的模型则有约 92% 的概率输出结束符。小米官方复盘
这里的“结束”，指结束本轮输出，并不代表整个任务已经完成。这个对比说明，在该样例中，模型对“继续调用”和“结束这一轮”的选择发生了明显变化。
从用户视角看，它在原地打转；从这个样例看，它在该停下的位置，仍然强烈倾向于继续生成调用。
02
PART
为什么训练过的 AI，仍然会这样
训练中的评价盲区
关键在于，训练的评价标准是否充分约束了执行过程。
可以用一个假设来理解：两份作业答案都正确，一份计算了三步，另一份把同一个计算重复了几十次。如果评分只检查最后的答案，这种低效就很难从分数中体现出来。
AI 的工具使用也存在类似的评价难题。任务做对了，执行过程仍然可能有大量冗余。 如果训练对无效操作的约束不足，模型就未必能学会稳定地避开它们。这是一种帮助理解奖励规则的类比，不意味着模型有意“偷懒”或“刷分”。
小米团队在排查中，怀疑原有的工具调用数量惩罚阈值过松。这为理解此次故障提供了线索，但不能据此认定所有 AI 重复操作都出自同一个原因。原因分析
03
PART
那就限制次数，为什么还不够
次数与必要性
因为“调用得多”和“重复做无用功”并不是同一件事。
核对二十份不同的文件，本来就可能需要多次读取。反过来，同一份文件没有变化、上次读取也成功了，再读一次就可能毫无帮助。
因此，数量限制可以拦住一部分过量操作，却无法单独判断每一步有没有必要。合理的重试、等待任务完成时的状态查询、修改代码后的重新测试，也不能一概算成复读。
小米尝试收紧调用数量限制后，更广泛测试中的复读仍未完全消失。随后，团队转向专项训练：明确区分重复调用与正常调用，再把学到的行为通过蒸馏合入主模型。修复过程
这段修复过程揭示了一个容易被忽略的能力：模型除了要学会如何使用工具，还需要学会控制调用，避免在没有必要时继续操作。
04
PART
看起来一直在忙，为什么任务没进展
动作与实际进展
回到开头的现象，执行记录持续增加，只能说明系统仍在产生动作。要判断这些动作有没有价值，还得看它们是否带来了新信息、有效修改，或者必要的验证结果。
例如，代码已经修改，再跑一次测试，可以回答“修改是否有效”。如果代码没变、测试结果也没有新的用途，机械地反复运行同一条命令，就需要追问这次执行究竟要验证什么。
重复操作的关键，是缺少必要性和新增进展。 次数只是表象，“是否还需要这一步”才是判断的核心。
小米的案例展示了其中一种成因与修复路径：当模型过度倾向于继续调用，而训练约束又没有充分纠正这种行为时，无效操作就可能不断出现。专项训练可以改变这种倾向。
这也解释了为什么“工具会用”还不够。可靠地完成任务，还包括用好已经得到的结果，并在合适的位置停下来。
本文以小米 MiMo 团队 2026 年 9 月 27 日发布的工具调用重复问题复盘为案例展开解释。模型概率与修复结果来自官方测试；文件核对、作业评分等为说明性假设。该案例不能解释所有模型、所有场景中的重复行为。
我是星阙运营小助手，星阙是一个专注于 OPC（一人公司 / 超级个体）的投资与孵化平台。