MiMo-V2.6 重复调用工具：AI Agent 上线前的产品验收门槛
小米的 MiMo-V2.6 修复暴露了 Agent 看似忙碌却没有进展的故障。用任务回放、停止规则和上线记录检验真实产品。
9 月 27 日，小米公开了 MiMo-V2.6 重复调用工具的诊断与修复。在一些 Agent 运行环境里，模型会反复发出相同或几乎相同的工具请求，却没有取得多少进展。小米称修复后的 API 模型已经部署，也开放了 MOPD checkpoint。对产品团队来说，真正的问题不止是某个模型有没有修好，而是：自己的 Agent 忙而无功时，能否发现并安全停止？已经执行过的外部动作，能否查清？
这直接关系到用 AI app builder 开发研究、排期、写作、文档处理或连接其他应用功能的创始人与小团队。常规的“成功率”看板可能看不出循环：API 正常响应，工具也返回结果，最终文字甚至很像一份答案；用户却多等了几分钟，消耗了预算，甚至收到重复通知。本文提供故障分类、任务回放方法、验收矩阵和上线记录模板。小米的数据是厂商自评；文中的案例和通过条件是建议的测试方式，不是 YBuild 或第三方对 MiMo 的实测结果。
这次发布的启示，超出“换成修复版模型”
小米在 技术说明中提到，MiMo Desktop、MiMo Code、OpenCode 等运行环境都观察到重复调用。修复前的按响应统计数据随模型和运行环境而变；以 OpenCode 为例，Flash-RL 为 1.02%，Pro-RL 为 0.54%。这些数不能预测你的应用会发生多少次问题。它们说明，同一个模型放进不同的工具链，表现也会变化。不能只看模型榜单，就推断自家提示词、工具权限和客户任务也可靠。
官方称，修复后的 API 模型从 9 月 25 日北京时间 06:00 起可用，但模型名仍是 mimo-v2.6-pro 和 mimo-v2.6-flash。另一方面，Flash-MOPD 与 Pro-MOPD 的开放 checkpoint 为有能力自行部署的团队提供了比较材料。API 名字不变，意味着事后不能只凭模型标签还原客户遇到的是哪种行为。至少要保存供应商响应 ID、调用时间、配置、可获得的模型修订信息，以及整段任务轨迹。
小米表示，专门训练的 teacher 在其回放集上消除了重复调用，MOPD 之后其他综合 benchmark 表现基本持平。这是关于小米测试设置的一手工程证据，却不能直接证明你的任务完成率、等待时间、重复发送风险或“每个被接受结果”的成本。小团队无需复现训练技术，但应该借这次发布检查自己真正交付给用户的结果。
先说清什么叫“重复”，再开始计数
工具调用是模型向外部能力发出的请求，例如查文档、读日历、创建草稿、发送消息或收款。本文说的一轮，指模型收到工具反馈之前发出的那批调用。轨迹则是按时间排列的模型决策、工具请求与返回、权限检查，以及用户界面状态。OpenAI 的 Agent 评估文档也把轨迹作为排查工作流问题的关键材料，而不是只看最终回答。有三种情况不能混为一谈。并行处理可能是合理的：一次检索三个不同来源，不是死循环。调用泛滥是发出的请求超过任务所需或系统能有效处理的数量，导致排队与积压。重复调用则是在没有新信息、环境也没有变化时，重复同一实际动作。超时后重试可能有理由；文件刚成功读取且没有变化，又读一次通常没有。付款请求超时后，未核对第一次是否生效就再次请求，风险尤其大。
小米采用了一个范围明确、容易复现的指标：在同一轮里，对 JSON 参数做规范化，再看是否出现“同一工具、同一参数”。若共有 N 次调用、其中 U 个不重复的工具与参数组合，精确重复比例是 (N - U) / N。原文同时说明，它抓不到跨轮重复、参数稍有变化的近似重复，也可能看不到藏在代码执行工具内部的动作。因此，它适合做便宜的预警，不能代表全部用户损失。Agent 可以换着说法反复搜索同一个问题，精确重复率仍然为零。
产品还需要两个判断：有没有推进任务，以及有没有产生外部效果。前者看这次调用是否带来新证据或状态变化；后者看它是否真的发出邮件、创建记录或改变费用。这些不能从 token 数自动推断。对边界模糊的调用保留人工标注样本，避免拦截器把必要的复核也当作死循环。
具体场景：一直在“检索”的会议简报助手
假设有一款会议助手 CedarMeet。客户让它读取日历事件、三份关联文档和最新客户备注，整理一份待审批的会议简报。正确交付物是在正确工作区里出现一份准确草稿。Agent 读了日历、抓了文档、查了备注；接着却不断调用 search_notes("renewal blockers")。有的请求拿回同一页内容，有的只是改了几个搜索词，结果仍是那些旧备注。界面持续显示“正在研究”，客户便以为工作在推进。
粗暴的调用次数上限也许会终止任务，却留下半成品草稿；粗暴重试又可能生成第二份草稿。即便最终文字流畅，也可能掩盖某份附件根本没有读取成功。产品需要区分四种状态：找到新证据；临时错误后的合理重试；没有新信息的停滞搜索；以及结果未知的写入。最后一种状态必须先核对下游系统，才谈得上重试。界面应按事实显示“草稿已保存、已核对两个来源、一个来源不可用”，或“保存前已暂停、等待审核”，不能一律给个“完成”。
CedarMeet 是说明方法的假设案例，不代表 MiMo 或其他供应商曾在这个产品里出现这种行为。它的好处是，非技术创始人也能判断交付物。请团队用固定任务分别回放旧路径和候选新路径，标记简报是否可接受、是否无理由地重复获取同一来源、草稿是否只写入一次、界面是否准确说明停止位置。这比问“新模型是不是感觉没那么爱重复”有用得多。
用客户真正付费的任务建立回放集
先选 20 到 50 个经过同意或人工构造的任务，覆盖产品最有价值的路径。加入顺利完成、数据缺失、权限拒绝、超时、限流、模糊的工具返回，以及确实需要再调用一次才能核验的任务。未经数据条款检查，不要把原始客户机密直接交给外部评估服务。每个样例都应保存目标、允许使用的工具、初始状态、预期产物和禁止发生的外部效果。OpenAI 的轨迹评分指南介绍了如何给完整轨迹加结构化标签；即便只用表格人工评分，也可以采用这一思路。
尽可能固定输入、连接器权限、工具说明、评分标准和停止规则。有条件时记录实际模型版本或部署时间窗口，因为公开模型名未必随行为更新而变化。让旧路径与候选路径在同一组任务上比较。如果两次测试间真实连接器的数据发生变化，就在记录里注明，不要把差异全归因于模型。涉及写入的任务，优先使用受控测试租户和固定数据。如果每次运行都依赖不断变化的外部状态，团队首先需要的是一套小型测试数据，而不是一份看似精确的性能结论。
轨迹不能只有提示词和最终回答。至少记录工具名、规范化参数或保护隐私的哈希、调用起止时间、响应状态、返回结果指纹、执行前后的状态版本、重试理由、权限决定、写入所用的幂等键，以及用户实际看到的界面状态，并用任务 ID 串起来。Anthropic 的工具调用文档区分模型请求工具与应用实际执行工具这两个环节：模型想做某事，不等于外部系统已经做成。工具报错也不能被静默转换成“任务完成”。
人工标签可以分为“必要重复”“可避免重复”“结果不确定”“造成有害外部效果”。对争议案例补一句理由即可。目标不是发明能识别所有循环的通用检测器，而是用一致的尺子观察模型或编排变化有没有伤害自己的客户任务。候选版本不要看完结果再临时放宽通过标准。
衡量被接受的结果，而非单看调用次数
上线决策要用少量能说明产品结果的指标。任务被接受率：满足事先定义的产物和效果要求的运行比例。可避免重复率：人工判定为在已有成功结果或不变状态后，没有带来必要信息的调用比例。达到可用状态的时间：用户得到真实、可操作结果所需时间，而不是第一个 token 出现的时间。每个被接受任务的成本：包含失败与重试在内的模型和工具总费用，除以被接受的任务数。重复外部效果数：重复创建、发送、收费或修改的次数。
精确重复调用减少，产品仍可能变差：模型省掉了必要检查；硬性次数限制降低成本，却让更多任务半途而废；激进重试看似提高完成率，却复制了草稿或通知。反过来，源文档在两次读取间确实更新时，两次参数相同的读取也可以合理。要把调用与状态版本、交付验收一起看。Anthropic 关于工具设计的文章提醒，冗余调用也可能源于分页设置不合适或错误信息不给力；问题未必只在模型。
不要把小米公布的重复率拿来当自己产品的通过线。你应根据损害决定门槛：只读研究功能的无效调用，主要浪费时间与费用；付款或发信功能，一次重复效果就可能足以阻断上线。每次报告都列出分子、分母和样例构成。只拿几个简单任务测出的低比例，不足以支持向全部用户放量。
停止规则要保住状态，也要如实告知用户
停止规则应结合多种信号。一轮里首次出现精确重复，可以标记轨迹并预警；在同一成功结果后继续重复，可以暂停或要求换一种方案；临时错误只允许在明确预算内重试；写入结果不明时，核对下游状态之前不能再写。对外部可见动作，规则应严于可撤销的读取。OWASP 的 AI Agent 安全检查表建议限制工具权限和调用、监测异常，并对敏感动作加入人工审批。
拦截器应放在应用或工具层，而非只写进提示词。这样即使模型忽略提醒，系统仍可执行规则。每条记录都要带任务、工具、参数、结果指纹和状态版本，还应说明为什么允许再次调用：需要新信息、状态已更新、用户明确要求，或符合重试政策。如果原因说不清，产品可以暂停并请用户确认或缩小范围。“因重复检索暂停”是可理解的状态；永远旋转的加载动画不是。
除了重复检测，还要设整次任务的上限：最长时间、工具调用数、供应商费用和写入尝试数。这些是护栏，不是质量目标。达到上限时，给出真实的部分结果、已完成和未完成步骤。模型写出最后一段话，不代表任务成功。客户应能从已保存状态继续，或者把案例交给人工处理，而不必盲目重试结果未知的写入。
把读取、重试和外部效果分开管理
重复读取可能浪费资源，重复写入却可能无法撤销。把工具按产品风险分成三类：只读、可撤销写入、高影响外部动作。只读搜索通常可以按来源版本做短时缓存；创建草稿时，应让同一个任务能重新打开已有草稿；付款、公开发送或删除则需要更强的授权与事后核对。OWASP 关于过度代理权的指南建议收窄工具功能与权限，并对高影响动作进行独立审批。
幂等键是一个稳定标识，下游服务靠它认出“同一个意图”的重试。Stripe 的幂等请求文档说明，在其规定的保留条件内，用同一个键重复请求会得到第一次请求保存的结果。这能在服务提供相应保证时，避免网络重试创建第二个对象。但它不能证明第一次操作本来就该做；换个新键仍可能产生新效果。应用必须把键绑定到客户意图，并核对下游结果，再决定向用户显示什么。如果连接器没有可靠的幂等支持，就在自己的应用里保留写入台账。执行前记录预期效果和目标；执行后保存下游对象 ID 或状态核对结果；超时则转为“结果未知”，先查证再决定下一步，不要马上发出第二次写入。这是一项设计建议，而非对所有第三方 API 的通用保证：各家的数据一致性、记录保留和查询能力都不同。上线测试必须覆盖客户实际使用的连接器。任何把“不知道第一次成功没有”直接变成盲重试的路径，都应阻断发布。
可复用的下一次模型更新验收矩阵
下表是模板。请换成自己产品的任务和数据样例。每一行都保存轨迹和用户实际看到的页面。“通过”意味着外部动作与界面说明同时符合事先约定；表格不是 MiMo 的实测成绩。
| 回放样例 | 团队需要的证据 | 产品应如何表现 | 何时阻断 |
|---|---|---|---|
| 独立并行读取 | 不同来源 ID 及返回 | 完成有效并行，不误拦截 | 护栏取消了必要来源 |
| 收到反馈前精确重复 | 相同工具和规范化参数 | 标记重复，执行次数遵守政策 | 同一无效请求不断继续 |
| 近似重复搜索 | 相同意图、来源状态未变 | 没有新证据时暂停或换方法 | 换词掩盖循环 |
| 读取超时 | 错误、重试次数、来源版本 | 有预算地重试，或说明来源不可用 | 无限重试或假报成功 |
| 来源确实更新 | 更新前后版本 | 允许有理由的第二次读取 | 把新证据误判成重复 |
| 草稿写入结果不明 | 意图 ID、下游对象核查 | 查清结果后才重试 | 产生第二份草稿 |
| 高影响发送 | 审批记录、下游回执 | 明确批准后发送一次 | 重复或越权发送 |
| 预算用尽 | 时间、次数、费用、保存状态 | 停止并展示真实部分结果与继续方式 | 一直转圈、悄然放弃或显示“完成” |
产品、工程与客服应在执行回放前，对每一行的预期答案达成一致。如果有人认为第二次搜索必要，另一个人认为纯属浪费，就把缺少的上下文写出来：也许返回内容被截断，也许来源更新，或者用户要求独立复核。这种分歧很有价值。它告诉团队在自动检测循环之前，应用还需要记录哪些状态。
决定放量、限量还是暂缓
上线决策可以有三种结果。放量：候选版本在回放集中满足任务验收要求，没有新增有害外部效果，处于任务预算内，且能诚实报告部分完成状态。限量：普通只读任务变好，但某个连接器、任务类别或用户群仍有未解风险；只开放安全范围并持续抽检。暂缓：仍有重复写入、被界面掩盖的停滞，或不可接受的回退；即使模型榜单好看，也不能靠榜单越过产品门槛。
分阶段开放：先用内部只读任务，再到少量知情客户，最后在检查线上轨迹样本后扩大。分别为异常调用量、相同意图无新结果、预算触顶和重复外部效果设置告警。留一个开关，必要时关闭受影响工具或退回人工处理。提前明确谁接收告警、谁可以决定回滚。没有负责人的监控面板，不算真正的控制措施。
留一页上线记录：日期与部署身份、任务集版本、供应商与模型路由、工具与权限版本、任务被接受率及分母、可避免重复标签、成本与耗时、重复外部效果数、已知缺口、放量／限量／暂缓结论、负责人和回滚条件。OpenAI 的 Agent 评估文档支持用轨迹做回归分析，但这张记录应让不熟悉评估平台的人也能读懂。它是决策凭据，不是宣传素材。
适用边界与不能代替的检查
这道验收门适用于连接外部工具的 AI 应用，尤其是研究、客服、排期、文档、编程和运营流程。用户看见 Agent 忙碌，却无法判断它有没有前进时，它尤其有用。供应商在熟悉的模型名背后更新模型，或团队修改提示词、工具结构、重试政策时，同样可以用它。完整轨迹还可以帮助判断问题出在模型、编排、工具反馈，还是连接器。
它不是完整的安全审查。精确重复检测看不到语义相近的调用、藏在 exec 中的循环，也拦不住一次就造成损害的动作。回放集通过，不等于所有罕见的高影响场景都可靠。隐私、授权、提示词注入和行业领域正确性需要各自的测试。本文也没有证明小米修复版一定适合你的负载：官方文章报告的是其内部评估；开放 checkpoint 让独立检查成为可能，却不能代替它。
下次发布会上，创始人可以只问一个问题：“Agent 重复动作时，状态变了吗，花了多少成本，产生了什么效果，客户看到了什么？”如果团队能拿轨迹和上线记录回答，模型更新就是可控的产品决策。如果回答不了，最急需改进的可能是应用自身的停止与核对机制，而不是再做一轮模型对比。