MiMo Code long-horizon coding agent routing：有状态 workflow 接入 API gateway

MiMo Code long-horizon coding agent routing 是小米 MiMo 新开源终端 Agent 中最值得运营团队关注的信号。6 月 10 日的官方文章不只是又一个 coding assistant 发布；它描述的是一种面向几十步甚至上百步任务的运行时：状态连续性、完成度检查、并行候选选择和可复用 workflow 脚本，与底层模型同样重要。对 AI 团队来说，路由问题也从“哪个模型回答了这个 prompt”，变成“哪个 runtime、memory layer 和成本通道应该拥有这个 agent session”。

MiMo Code long-horizon coding agent routing 发生了什么

小米 MiMo 团队将 MiMo Code 作为基于 OpenCode 构建的 MIT 协议终端 coding agent 开源。官方文章把设计拆成三个运营主题：计算、记忆和进化。文章指出，短任务可以通过把完整对话历史传回模型来维持连续性，但更长 session 需要在上下文耗尽、决策质量下降之前，显式完成状态提取、checkpoint 和 rebuild。

计算层包含 Max Mode：一个实验性路径，在每轮并行采样多个候选计划，再让 judge model 在真正执行前选择最稳妥的方案。小米称该模式在 SWE-Bench Pro 上带来 10-20% 提升，代价是约 4-5 倍 token 消耗。同一节还介绍了 Goal：当 Agent 尝试停止时，由独立完成度验证器审查完整对话，确认目标是否真的满足，或把缺口反馈回主循环。

对 operator 更关键的是记忆层。MiMo Code 会在配置预算约 20%、45%、70% 的位置触发 checkpoint writer subagent，并在上下文接近上限时，从结构化文件 rebuild 新的物理窗口。文章还把 session memory、project memory、global memory 和 history 拆成不同层级，并通过 Dream、Distill 等周期性任务整理持久知识和可复用 workflow。

为什么 MiMo Code long-horizon coding agent routing 对 AI 工程团队重要

一个可以运行 200 步以上的 coding agent，会改变 gateway 的基本假设。传统 API routing 通常把每次调用视作近似无状态请求，只需要关联 provider、model、latency 和 token cost。长程 coding agent 更像一个分布式 job：它有 session identity、状态文件、checkpoint writer、verifier call、child agent、workflow script，以及可能很久之后才出现的最终产物。

这意味着 operator 不能只看前台模型来定价和治理整个 session。Max Mode 可能让单次决策的 token 成本成倍增加；Goal 检查会增加串行验证调用；checkpoint writer 和 memory distillation 会产生后台流量，而且未必使用与主 Agent 相同的模型；Dynamic Workflow 会把 prompt 中描述的流程变成 JavaScript 编排，并派生并行 subagent。如果这些流量共用一个没有区分的 API key，成本归因和事故响应都会很快变乱。

更深层的重点是可靠性。小米文章认为，用 prompt 写 workflow 时，一旦上下文压缩吞掉步骤、模型跳过分支，或重试逻辑完全交给自然语言，复杂流程就会系统性失效。把编排逻辑移入确定性的 workflow code，是一种 operator 模式：让模型负责理解与生成代码，把 loop、barrier、retry 和 fan-out 交给可审计控制面。

MiMo Code long-horizon coding agent routing 的 router/operator 视角

运营这类 Agent 的更稳妥方式，是按 session role 拆分路由，而不是只按模型名拆分：

1. 前台编码通道。 将交互式规划和代码编辑调用，路由到符合任务复杂度与延迟要求的模型层级。
2. 验证器通道。 给 Goal 风格的完成度检查配置更便宜或更严格的模型策略，因为它们应该审计，而不是自由发挥。
3. Checkpoint writer 通道。 将记忆提取视作后台流量，拥有自己的 rate limit、retention rule 和失败告警。
4. Workflow 通道。 把 agent() fan-out、parallel() barrier 与 child-agent budget 作为一个受治理 session 追踪，而不是互不相关的 API 调用。
5. Distillation 通道。 用明确日程运行记忆整理和 skill 提炼，并与用户可见工作分离审计日志。

这就是 AI gateway 走向 agent control plane 的位置。它需要保留 session ID，附加 route class metadata，按 role 核算 token 支出，并提供 subagent 可用模型的策略表面。正在思考 gateway-side policy 的 TheRouter 团队，可以对照宽入口的 TheRouter AI routing documentation 和此前的 AI gateway agent session routing analysis。

TheRouter 用户应关注或尝试什么

TheRouter 用户不必复制 MiMo Code 的 runtime，也可以吸收它的设计经验。最直接的测试，是把 coding-agent 流量按角色打标签：foreground、verifier、checkpoint、workflow child 和 distillation。只要标签存在，route policy 与 billing 就更容易解释。

运行 Claude Code、OpenCode、Cursor 类工具或自研终端 Agent 的团队，也应该重新审视 workflow 定义方式。基于 prompt 的 SKILL 文件适合灵活指导，但确定性的迁移、多仓库重构和大规模 fan-out 任务，需要代码级 workflow 边界。最近的 Claude Code dynamic workflows operator analysis 讨论了类似转向：从自然语言流程，转向可审计执行图。

MiMo Code long-horizon coding agent routing 决策清单

在采用任何长程 coding agent runtime 前，先问清楚：

1. 哪些调用属于前台工作、验证器、checkpoint 写入或 workflow fan-out？
2. gateway 能否在物理上下文 rebuild 之间保留稳定 session ID？
3. 后台 subagent 是否允许使用与主 Agent 相同的模型层级？
4. Max Mode 或并行 workflow 是否需要给用户明确成本提示？
5. 记忆文件是否可被 operator 检查、修正和删除？
6. workflow 层是否记录 retry、branch、barrier 和 child-agent 结果？

这些答案决定了长程 coding agent 只是一个漂亮 demo，还是平台团队真的能运营的系统。