MiMo Code long-horizon agent routing：Max Mode、Goal 验证与 OpenAI-compatible 后端

大多数编程 agent 的设计目标是在单轮对话内完成任务。但当一个任务延伸至数十乃至上百个工具调用步骤时，"扩大上下文窗口"这一直觉解法会带来多重复合失效：超长上下文下模型的指令跟随能力下降、token 消耗失控、以及 agent 在任务完成前就虚假声明"已完成"。6 月 10 日，小米 MiMo 团队发布了 MiMo Code 的工程设计文档——这是一款基于 OpenCode 构建、以 MIT 协议开源的终端编程 agent，其架构选择对通过 API gateway 路由 agent 工作负载的团队具有直接影响。

MiMo Code 实际交付了什么

MiMo Code 是一个 harness，而不是一个模型。它封装了任意支持 OpenAI-compatible chat completions 接口的模型，并在基础循环之上增加了三个架构层：

Max Mode — 并行采样。 每个 agent 步骤并行生成 N 个候选方案（默认 N=5，temperature=1）。一个独立的"裁判"模型调用对所有候选方案的推理轨迹和行动计划进行比较，选出最优方案后再执行。没有任何候选方案会在裁判投票前执行。在 SWE-Bench Pro 上，Max Mode 将解题率提升 10–20%，代价是每步 token 消耗约增加 4–5 倍。

Goal — 独立完成验证器。 当 agent 尝试终止时，一个独立的模型调用会根据用户定义的自然语言停止条件（例如"所有测试通过且代码已提交"）审查完整对话历史。若条件未满足，差距信息会被反馈给 agent 并继续执行。误阻断（目标已达成但验证器判断未达成）是更常见的错误；无限循环概率低于 0.5%，系统设有步数硬上限作为安全阀。

结构化内存检索。 MiMo Code 不是将历史压缩为滚动摘要，而是为任务状态维护显式存储结构，并通过检索来选择性地召回历史上下文。其设计动机在于：滚动摘要压缩的行为类似于循环模型——有状态但无法按需回溯。

Max Mode 与 Goal 是正交的：Max Mode 在每步横向展开（更宽），Goal 在任务中纵向延伸（更多步骤）。两者可同时启用，token 成本相应叠加。

对工程团队的影响

1. 模型无关部署是核心路由决策

MiMo Code 支持任意 OpenAI-compatible 后端。Hacker News 上的讨论指出："MiMo Code 与 OpenCode 具有相同的 provider 支持。即使是 Claude Code，也可以通过任何暴露 Anthropic API 接口的 provider 来使用。"实际上，这意味着运行 MiMo Code 自动化编程 pipeline 的 operator 需要做出以下选择：

• worker 角色路由到哪个模型（大量步骤，高并发，成本敏感）
• 裁判角色路由到哪个模型（Max Mode 专用，准确率关键，调用量较低）
• worker 与裁判是否应使用相同模型或不同模型

worker/裁判角色的拆分为路由策略提供了天然的分叉点：worker 轮次使用更快、更便宜的 provider，裁判调用使用更高精度的模型。能够根据请求中的角色元数据进行逐请求模型选择的 AI gateway，无需修改 agent harness 即可独立路由这两类角色。

2. Max Mode 改变了 token 预算计算方式

在 N=5 的配置下，每个 agent 步骤消耗约单样本 agent 5 倍的 token。以 50 步任务为例：

• 标准模式：约 50 次 worker 调用 + 50 次裁判调用 = 约 100 次 API 调用
• Max Mode：约 250 次 worker 调用 + 50 次裁判调用 = 约 300 次 API 调用

实际倍数取决于任务复杂度和步骤数，但预算影响是明确的：Max Mode 是底层 provider 的吞吐量放大器。团队应将其视为独立的成本层级，并在启用 Max Mode 时考虑限速余量。如果路由层对每个模型设置了 TPM 上限，Max Mode 可能会在单任务 session 内悄然触及限速。

3. MiMo-V2 弃用已进入成本核算截止期

固定使用 mimo-v2-flash 或 mimo-v2-tts 模型 ID 的 operator 已经经历第一阶段自动重路由：2026 年 6 月 18 日 00:00（GMT+8），小米平台开始把 v2-flash 和 v2-tts 的请求路由至 V2.5 对应版本——并按 V2.5 定价计费。完全弃用将在 6 月 30 日执行。

如果你的路由层使用厂商侧的模型别名（即直接向小米接口传递 mimo-v2-flash），6 月 18 日的重路由可能已在不改变配置的情况下改变你的每 token 成本。如果你的路由层对模型 ID 进行了规范化映射，需在 6 月 30 日前审计映射关系，确保 V2.5 版本及其价格在成本核算中得到正确体现。

Router/operator 视角分析

MiMo Code 揭示了两种超出该工具本身、普遍适用于 agent 场景的 operator 模式：

worker/裁判角色不对称。 在主 worker 调用之外使用"规划"或"验证"调用的 agent harness 越来越普遍。将这两类角色路由至不同 provider——或同一 provider 的不同质量层级——需要 gateway 能够根据请求中的角色元数据进行调度，而不仅仅依赖模型名称。

步骤数放大效应。 长程 agent 以非线性方式放大 API 调用量。以"任务"为单位计量消耗的治理层，在 Max Mode 或 Goal 生效时会低估实际 token 消耗。准确的成本归因需要在 API 调用粒度进行逐请求核算，而非任务粒度。

值得关注的动态

• MiMo-V2-Flash 和 MiMo-V2-TTS 已于 6 月 18 日开始自动重路由至 V2.5 定价；完全弃用将在 6 月 30 日执行——现在就应审计模型 ID 映射。
• MiMo Code v0.1 是早期版本；受限命令行工具调用语法（减少 token 开销）已列入未来迁移计划，当前尚未上线。
• Max Mode 目前为实验性功能，需在配置中手动启用。
• MiMo Code GitHub 仓库 以 MIT 协议开源，可配合任意 OpenAI-compatible 后端自托管部署。

评估长程编程 agent 的路由团队，应将 worker/裁判角色的模型选择、Max Mode token 倍数，以及 provider 限速余量作为路由与成本模型的一等参数来对待。