6 月 11 日凌晨，小米 MiMo 团队把一款终端 AI 编程助手推到了 GitHub 上。MiMo Code V0.1.0，基于 OpenCode 二次开发，MIT 协议，任何人可以商用、修改、分发。

如果只看这些信息，它像是又一个开源编程工具——2026 年上半年，这类产品已经密集到让开发者审美疲劳。但一个细节值得停下来：MiMo Code 在 SWE-Bench Pro（一个衡量 AI 自主修复真实 GitHub Issue 能力的基准测试）上拿到 62%的通过率，而 Anthropic 的 Claude Code 是 57%。

一个刚发布 V0.1.0 的工具，跑赢了目前公认最强的终端编程助手？

答案藏在一个叫 Compose 模式的设计里。按下 Tab 键切换进去，给它一句话需求，它会自动拆解为设计、规划、编码、测试、审查五个步骤逐一执行。这不是一个更聪明的模型在独自工作，而是一组 Agent 在流水线上接力。

这件事的意义超出了 MiMo Code 本身。它指向一个正在发生的行业转折：AI 编程的竞争焦点，正在从「谁的模型更聪明」滑向「谁的 Agent 协作框架更成熟」。

单 Agent 串行模式的天花板在哪里

理解 Compose 模式之前，需要先理解它要解决的问题。

早期或典型的 AI 编程助手——从最初的 GitHub Copilot 到 Cursor——更接近单 Agent 串行模式：你给它一个需求，它在一个连续的上下文窗口里完成理解、规划、编码、调试的全部工作。模型越强，窗口越长，理论上能处理的任务就越复杂。

但真实开发场景暴露了这个模式的天花板：当任务需要上百轮对话、跨越多个文件甚至多个子系统时，单 Agent 会遇到两个工程瓶颈。一是上下文窗口的物理限制——即使模型支持 100 万 Token，真正有效的注意力范围远小于此，越往后输出质量越差。二是「记忆污染」——早期对话中的临时决策、废弃方案、调试信息会持续占据窗口，干扰后续判断。

小米官方用了一个直白的描述：「越用越忘」。开发者在第 50 轮对话时发现，AI 已经忘了第 3 轮确定的架构决策。

MiMo Code 的解法是把「记忆管理」和「任务执行」拆开。主 Agent 专注执行当前任务，一个独立的 subagent 在后台持续记录状态——项目记忆、会话检查点、任务进度。当主 Agent 的上下文窗口快满时，subagent 自动生成一份干净的简报，主 Agent 基于这份简报继续工作，而非从零开始。

这个设计的本质是：用多 Agent 分工来突破单 Agent 的物理限制。它不需要模型本身变得更强，只需要在工程层面把「记忆」这个职责外包出去。

Compose 模式的真正对手是谁

如果把视野拉开，MiMo Code 的 Compose 模式并不孤独。腾讯在 2026 年上半年发布的两个产品，走的是同一个方向的不同路径。

先厘清 MiMo Code 自身的架构层级。MiMo Code 在产品框架层已经具备明确的 Agent 协同机制：它拥有 build、plan、compose 三个主智能体，Tab 键实现的是在主智能体之间切换；同时在系统层有 subagent 子智能体，由系统按需生成，支持共享上下文、并行工作、生命周期追踪、取消和后台执行。换言之，MiMo Code 属于开发工具内的系统级 Agent 协同——它让模型与 Agent 框架深度适配，在单个开发者的长程任务中稳定完成设计、规划、编码、测试和审查闭环。

腾讯 Marvis 走的是另一条路：组织级多 Agent 编排。它采用 1 主 5 副的 Agent 协作架构，一个主 Agent 负责理解需求和任务分发，五个专业化的副 Agent 分别处理代码生成、测试编写、文档更新、代码审查、部署配置等环节。与 MiMo Code 的核心区别在于：MiMo Code 的 Agent 协同聚焦于开发工具内部，让单个开发者在终端里高效完成长程任务；而 Marvis 的协同发生在系统调度层面，每个副 Agent 可以是不同的模型实例，由一个独立的调度系统管理它们之间的通信和依赖关系，天然面向多人协作、跨仓库依赖和并行任务分发。

这个差异决定了各自的适用边界。MiMo Code 的 Compose 模式更适合单个开发者在终端内处理单项目或单仓库的长程开发任务——它的优势在于规划、记忆、上下文重建、测试验证和审查的完整闭环，而非简单的线性执行。Marvis 的架构则面向团队级复杂度——当五个副 Agent 可以同时工作时，涉及多服务、多仓库的项目吞吐量会显著提升。

另一条路径来自腾讯旗下的 Ardot。它通过 MCP（Model Context Protocol）协议打通设计工具、代码编辑器、CI/CD 管道之间的数据流。MCP 解决的问题更底层：当协同不仅发生在代码层面，还需要让设计稿里的组件规范自动流入代码生成 Agent、让测试结果自动触发部署 Agent 时，Agent 之间需要一个标准化的「互相发现和调用」协议。

三种路径可以这样理解：MiMo Code 的 Compose 模式是「开发工具内的系统级 Agent Harness」，Marvis 是「组织级多 Agent 编排平台」，MCP 是「让不同系统能互相对话的协议层基础设施」。它们解决的是同一个大问题——多 Agent 协同——的三个不同层级。

62%这个数字能说明什么，不能说明什么

MiMo Code 在 SWE-Bench Pro 上的 62%通过率是一个值得认真对待的数据点，但需要谨慎解读。

SWE-Bench Pro 测试的是 AI 自主修复真实开源项目 Issue 的能力——给定一个 Bug 描述和代码仓库，AI 需要定位问题、编写修复代码、确保测试通过。62%意味着 MiMo Code 能独立解决接近三分之二的真实 Bug，这个水平在半年前还属于行业天花板。

但几个边界条件需要注意。这个成绩来自官方测试，目前没有第三方独立验证。SWE-Bench Pro 的测试集以 Python 项目为主，对其他语言和更复杂的企业级项目（多仓库、微服务架构、私有依赖）的代表性有限。更关键的是，62% vs 57%的差距有多少归功于 Compose 模式的工程设计，有多少归功于 MiMo-V2.5 模型本身的能力，目前无法拆开归因。

另一个数据点是 Terminal Bench 2 的 73%（对比 Claude Code 的 68%）。Terminal Bench 2 测试的是 AI 在终端环境中执行复杂操作序列的能力，更贴近 MiMo Code 的使用场景。两个 Benchmark 共同指向一个趋势：当编程助手从「补全代码片段」进化到「自主完成完整任务」时，工程架构的设计（如何管理状态、如何分配子任务、如何处理失败重试）对最终表现的影响，可能已经不亚于底层模型的能力。

小米大模型负责人罗福莉在 4 月的一次公开访谈中说过一句话：「2026 年的竞争核心不再是对话体验，而是长程自主任务执行、工具调用与自我修复能力。」MiMo Code 的 Compose 模式是这句话的工程化注脚。

开发者真正需要回答的选型问题

对于正在评估 AI 编程工具的开发团队来说，「哪个工具更好」可能是一个错误的问题。更有效的问题是：「我的任务复杂度处于哪个层级？」

如果你是一个独立开发者，面对单一代码仓库，需求是从一个想法快速推进到可运行的代码——MiMo Code 的 Compose 模式或 Claude Code 这类终端工具就够用。它们的优势是零配置、即开即用、单人效率极高。MiMo Code 额外提供的持久记忆系统（每 7 天通过/dream 命令自动合并历史记忆）和 subagent 并行机制，让它在长期项目中的规划深度和状态稳定性更有保障。

如果你的团队有 5-10 人，项目涉及多个服务、多个仓库、需要并行推进不同模块——组织级的多 Agent 编排（如 Marvis 的架构思路）开始变得必要。单个开发工具内的 Agent 协同无论多强，都无法同时调度前端组件开发、后端 API 设计和数据库迁移脚本编写这些跨角色任务。

如果你的组织需要打通从产品设计到代码交付到持续部署的完整链路，涉及 Figma、VS Code、Jenkins、Kubernetes 等多个工具的数据流——协议级协同（MCP 或类似方案）是绕不开的基础设施。

这三个层级之间存在一个尚未解决的问题：它们目前是割裂的。MiMo Code 的 Compose 模式不能直接调用 Marvis 的副 Agent，Marvis 的调度系统也没有原生支持 MCP 协议。行业还没有出现一个统一框架把三层打通。谁最终能做这件事——是云厂商、是工具厂商、还是开源社区——目前看不清楚。

但有一件事已经清楚：AI 编程正在从「一个聪明的对话伙伴」变成「一座有分工、有流程、有质检的工厂」。MiMo Code V0.1.0 只是这座工厂最早的一块砖。它采用 MIT 协议开源、支持接入 DeepSeek、Kimi、GLM 等第三方模型的设计，说明小米把它定位为模型消费端的入口工具，而非封闭生态。这意味着，无论底层模型来自谁、推理服务跑在哪朵云上，终端工具层的竞争逻辑已经变了——比的不是模型参数量，而是 Agent 协作的工程成熟度。

对于那些还在用「模型跑分」来选工具的开发者来说，是时候换一个评估维度了。

 

图片来源：视觉中国