MiMo Code 长程 Agent 架构解读：计算、记忆、进化三层设计对 Operator 路由策略的影响

当一个 coding agent 在生产代码重构的第 40 步卡住时，问题几乎从不出在模型质量上。真正的问题是路由和编排设计：context window 已经满了，指令跟随能力在高负载下下降，或者工作流逻辑写在自然语言里并在 context 压缩过程中丢失了。

2026 年 6 月 10 日，小米 MiMo 团队发布了 MiMo Code——一个基于 OpenCode 构建、以 MIT 协议开源的终端原生 coding agent。配套的技术博客以罕见的坦率记录了三类失效模式的架构应对：单轮推理的计算瓶颈、多轮会话中状态连续性失效、以及跨会话无法积累经验。每一类都对应一个设计层：计算（computation）、记忆（memory）、进化（evolution）。

对于运营 Claude Code、Cursor、Kimi Code 或自托管 agent 栈的 AI 工程团队来说，MiMo Code 的设计文档是目前公开资料中对长程 agent 路由实际需求最详尽的阐述。

发生了什么

MiMo Code 于 2026 年 6 月 11 日上线，定位为针对"数十甚至数百步执行"场景设计的终端 coding agent。官方技术博客 mimo.xiaomi.com/blog/mimo-code-long-horizon 比产品发布早一天发布，是理解其架构的主要 operator 参考。

该 agent 基于 OpenCode 构建，MIT 协议，GitHub 仓库两天前仍有活跃提交。它默认使用小米自研的 MiMo-V2.5 和 MiMo-V2.5-Pro 模型，但基于 OpenCode 底座，与 Claude Code、Cursor 和 Cline 工作流也有文档记录的兼容性。

三层架构框架的核心含义：

1. 计算（Computation） — 随任务长度增长如何维持单轮决策质量
2. 记忆（Memory） — 如何在单个 context window 之外保持多轮状态连贯性
3. 进化（Evolution） — agent 能力如何在独立会话间持续积累

对 AI 工程团队意味着什么

MiMo Code 设计的核心论断，是任何运行长程自动化任务的 operator 应当马上认出来的：无状态模型调用是单元；runtime 是连续性的来源。 多轮 agent 执行中的每一个失效模式，都追溯到 runtime 如何管理状态，而不是模型如何推理。

这一重新定义对团队如何分配计算和设计路由有直接影响：

并行采样的成本权衡。 MiMo Code 的"Max Mode"在每轮生成 N 个候选方案（默认 N=5），由独立 judge 模型在执行前选择最优方案。在 SWE-Bench Pro 上，Max Mode 以约 4–5× 的 token 消耗换来 10–20% 的性能提升。对 AI gateway 的 operator 而言，这是路由层的决策：Max Mode 每个 agent 步骤路由多个并发调用而非一个。按请求计数或按 token 预算定价的团队需要显式建模这种成本扩张。

完成验证作为独立模型路由。 Goal 机制——每当 agent 尝试终止时触发的独立验证器——是一次独立的 API 调用，可路由到相同或不同的模型。这在 API 用量中产生可观测的分支模式：验证器调用是 agent 循环风险的信号，其失效模式（因 flaky 测试导致的误拦截）在网关侧表现为意外的成本峰值。

Checkpoint writer 作为 sub-agent 路由事件。 记忆层在配置 context 预算的 20%、45%、70% 处分别触发独立的 writer sub-agent。每次 writer 调用都是完整独立的 API 路由，有自己的 token 预算和模型选择。通过 AI gateway 运行的团队可以将这些调用路由到更便宜或更小的模型，而不降低主 agent 质量。

编排即代码作为路由治理面。 Dynamic Workflow 将自然语言 SKILL.md 编排逻辑转换为在隔离沙箱中运行的确定性 JavaScript，通过 agent() 调度 sub-agent，通过 parallel() / pipeline() 控制并发。从 operator 路由角度看，这意味着并发峰值变得可预测：工作流代码可以静态审计，以确定任务会产生多少并发 agent 调用。这与基于 prompt 的编排有根本区别——后者的并发是涌现的，无法提前评估。

Router/Operator 视角

计算–记忆–进化框架对应三个路由策略问题：

1. 如何为并行采样成本做预算？ Max Mode 是可选的实验性功能，但它代表了一个真实模式：提供采样并行性的 coding agent 平台将计算从推理深度转向推理广度。AI gateway 的 operator 需要能够处理 N× 突发模式的每请求和每会话成本上限，而不会让下游账单出现意外。MiMo 设计文档明确披露了成本乘数（4–5×），这比大多数平台公开的信息更透明。

2. 如何建模 sub-agent 路由？ MiMo Code 将独立 sub-agent 用于两种不同角色：完成验证（Goal）和记忆提取（checkpoint writer）。这是不同的请求画像——验证器调用是短 context 的摘要评估；writer 调用是结构化提取任务。将所有 sub-agent 调用通过同一模型和优先级层路由的 AI gateway，会错过这两条路径可分化时的成本-质量优化空间。

3. 你的会话边界路由策略是什么？ Cycle 抽象——checkpoint、重建、继续——意味着单个逻辑任务从模型 provider 视角可能跨越多个 API"会话"。速率限制计数器和每会话成本归因需要在 gateway 层感知会话，而不仅仅在单请求层面。在任务执行中途触及 provider 速率限制的团队，需要能够保留 checkpoint 状态而非从头重启的 fallback 策略。

TheRouter 用户应该关注什么

MiMo Code 目前是开源产品，可在 github.com/XiaomiMiMo/MiMo-Code 获取。目前不提供托管 API 路由。通过 gateway 使用小米 MiMo 模型的团队，可参考小米 MiMo V2.5 Provider 发布报道了解模型访问上下文。

MiMo Code 记录的架构模式——并行采样预算、checkpoint writer sub-agent 路由、编排即代码并发——适用于所有 coding agent 平台，包括 Claude Code、Kimi Code 或基于 OpenCode 的自定义 agent 栈。正在评估生产 coding agent 部署的 AI gateway 配置的团队，应针对这三个维度审计路由策略：

• 你的 gateway 是否支持每会话 token 预算（不仅仅是每请求）？
• 你能否将 sub-agent 调用路由到与主 agent 调用不同的模型层？
• 你是否有能将验证器调用与主 agent 调用在成本归因中区分开来的可观测性钩子？

关于编排即代码的并行模式，也可参考 ZCode coding agent operator 路由报道，了解 Zhipu GLM-5.2 agent 栈的类似设计。

Provider 配置和路由策略文档请访问 /docs/。