小米开源 MiMo Code：把长程编程 Agent 做进终端
小米 MiMo 团队发布并开源 MiMo Code V0.1.0，把终端代码助手、跨会话记忆、上下文重建、Compose 编排和 Dream/Distill 经验沉淀放到同一个开源工具里。它基于 OpenCode 构建，适合小团队关注长程编程 Agent 的实际落地边界。
小米 MiMo 团队在 2026 年 6 月 10 日发布并开源了 MiMo Code V0.1.0。它是一个运行在终端里的 AI 编程 Agent，能够读写代码、执行命令、管理 Git，并把跨会话记忆、上下文重建和任务进度追踪做成核心能力。
这次发布的重点不只是“又一个代码助手”。MiMo Code 把开发者近几个月最关心的几件事放在同一个工具里：长任务怎样不断片，Agent 怎样知道自己是否真的完成目标，团队积累的项目知识怎样沉淀下来，现有 Claude Code、OpenCode、MCP 和多模型工作流怎样迁移。
对于独立开发者和小团队，它更像是一个值得拿真实仓库测试的开源样本：如果一个终端 Agent 能把记忆、工具调用、模型调度和工作流编排打通，AI 编程工具的竞争就会从“哪个模型更会写代码”继续转向“哪个系统更能稳定完成一个工程任务”。
MiMo Code 具体发布了什么
MiMo Code V0.1.0 已在 GitHub 开源，代码基于 OpenCode fork 构建，源代码采用 MIT 许可证。官方 README 把它定位为“终端原生的 AI 编程助手”，保留多 Provider、TUI、LSP、MCP、插件等基础能力，并在此基础上加入 MiMo 自己的长程任务机制。
从官方说明看，首版主要包含这些能力：
模块 | 作用 |
|---|---|
多智能体 | 提供 build、plan、compose 等主智能体模式，子智能体可按需生成并行工作 |
持久化记忆 | 用项目记忆、会话检查点、笔记和任务进度保存跨会话上下文 |
上下文管理 | 当窗口接近上限时，用 checkpoint、memory、任务日志重建上下文 |
Compose 模式 | 把规划、执行、代码审查、TDD、调试、验证和合并串成规格驱动流程 |
Goal 机制 | 用独立裁判模型判断设定目标是否已经满足，减少任务半途停住 |
Dream / Distill | 从历史会话中提取可复用知识、工作流、skill、subagent 或 command |
安装方式也走低门槛路线。Mac 和 Linux 用户可以通过安装脚本启动，Windows 用户可用 npm 安装 @mimo-ai/cli。首次启动会引导配置，支持 MiMo Auto 限时免费通道、小米 MiMo 平台 OAuth 登录、从 Claude Code 导入认证，以及添加 OpenAI 兼容 API Provider。
官方同时强调 MiMo Code 是探索性版本。也就是说，它已经具备可试用入口和开源代码，但还不应该被直接理解成成熟稳定的企业级开发平台。
最值得关注的是长程任务状态管理
代码智能体最容易失效的地方，通常不是第一轮能不能写出代码，而是多轮之后是否还能记住“为什么这么改”。真实项目里，一个任务可能包含读架构、改多文件、运行测试、修复失败、重新解释需求、做代码审查和整理提交信息。上下文一旦被挤掉，Agent 就会重复探索、误删约束，或者用新的猜测覆盖旧的决策。
MiMo Code 的核心回答是四层记忆加上下文重建：
MEMORY.md保存跨会话的项目知识、规则和架构决策。checkpoint.md保存结构化状态快照，由 checkpoint-writer 子智能体维护。notes.md作为临时记录区，放近期推理和观察。tasks/<id>/progress.md记录单个任务的推进过程。
这些内容会在会话恢复时按 token budget 注入上下文。官方博客还把计算、记忆和进化作为三条设计主线：计算负责用并行推理和验证机制提高决策质量，记忆负责保留项目状态，进化则负责把重复工作流沉淀成可复用能力。
这对小团队的实际意义很直接。过去使用终端 Agent 时，开发者常常需要自己写 CLAUDE.md、维护任务笔记、手动总结上下文，甚至在上下文快满时暂停工作重新开会话。MiMo Code 把这些动作产品化，至少给出了一个可观察的实现路径。
它不是只想做“开源 Claude Code 替代品”
外部报道常把 MiMo Code 放到 Claude Code 对比框架里，这个角度容易理解，但不完整。
MiMo Code 确实提供了迁移便利：官方 README 提到它可以从 Claude Code 导入已有认证，聚合报道也提到对 skills、MCP 服务器和命令的兼容。对于已经在 Claude Code 或 OpenCode 上积累配置的开发者，这能降低试用成本。
但从产品设计看，小米更想强调的是 Agent 与模型、记忆和工作流之间的协同。MiMo Code 支持多 Provider 和 OpenAI 兼容 API，也可以使用 MiMo Auto 或小米 MiMo 平台模型。它的差异点不只是调用哪一个模型，而是把这些模型放进一个带记忆、checkpoint、目标判断和流程编排的终端工作台。
这种方向会改变小团队评估代码工具的方式。以后比较 AI 编程工具，不能只问“默认模型是谁”，还要问：
- 它能否稳定读取并保留项目规则。
- 上下文溢出时是直接丢失信息，还是能重建任务状态。
- 是否支持把常见流程沉淀成 skill、command 或 subagent。
- 对命令执行、文件修改和 Git 操作有没有清晰权限边界。
- 失败后能不能从测试、日志和审查结果中继续修复。
如果这些问题回答不好，即使模型能力很强，真实项目里的表现也会波动很大。
官方自测数据可以参考，但不宜过度解读
小米在技术博客中提到，MiMo Code 的 Harness 能让同一模型在 SWE-Bench Pro V2 和 Terminal Bench 2 上比 Claude Code 高 5 个百分点；官方还描述了真人双盲 AB 测试和多个长程任务评测场景，包括网页克隆、文献综述、复杂 3D 图像生成、自动修复 GitHub Issue、游戏构建和量化策略构建等。
这些信息说明小米已经把 MiMo Code 放进真实任务评测里，而不是只展示简单 demo。对开发者而言，这比单纯跑代码补全榜单更有参考价值，因为终端 Agent 的质量取决于模型、上下文、工具调用、测试反馈、权限控制和任务恢复机制的组合。
不过，这些仍然是官方口径。第三方可复现评测、不同模型组合下的表现、企业仓库里的稳定性、长时间运行后的成本和权限风险，都还需要继续观察。尤其是“比 Claude Code 强”这类说法，最好先当成测试假设，而不是采购结论。
小团队可以先测哪些场景
MiMo Code 最适合先用在边界清楚、验证明确、失败可回滚的任务里。不要一上来就交给它处理支付、权限、数据迁移或生产部署。
可以优先测试四类场景：
- 仓库理解与任务拆解：让它解释项目结构、找到相关模块、生成修改计划，再看计划是否贴近真实代码。
- 小规模功能实现：选择 1-3 个文件范围内的需求，要求它修改、运行测试并说明风险。
- 测试补齐和失败修复：给它一个明确失败日志，观察它是否能利用终端反馈迭代。
- 项目记忆维护：连续几天在同一仓库内工作，检查
MEMORY.md、checkpoint 和 task progress 是否真的减少重复说明。
如果团队已经在使用 Claude Code、Cursor、OpenCode 或自研脚本，可以把 MiMo Code 放在非核心仓库里做对照测试。重点记录的不只是完成率，还包括上下文恢复质量、命令审批体验、生成 diff 的可审查性、对团队规范的遵循程度，以及失败后的恢复成本。
还需要观察的限制
MiMo Code 当前是 V0.1.0。官方没有把它包装成稳定版，也没有给出长期商业化、企业权限、托管服务 SLA 或私有化部署承诺。语音输入等功能还与 MiMo 登录和特定模型能力相关，并不等于所有 Provider 都能获得完整体验。
它基于 OpenCode fork 构建，这有利于继承成熟的终端 Agent 基础能力，也意味着后续要看小米如何处理上游同步、插件兼容、社区贡献和自身差异功能之间的关系。开源许可证宽松是一件好事，但真正进入团队流程，还需要看 issue 响应、版本节奏、安全边界和文档质量。
对多数小团队来说，合理动作不是马上替换现有工具链，而是把 MiMo Code 加进代码智能体评测清单。先选一个真实但低风险的仓库，跑完安装、模型配置、Claude Code 配置迁移、MCP 接入、长任务 checkpoint 和 Dream/Distill 机制，再决定它能承担哪一段工作流。
这次发布释放出的信号很清楚：国内模型团队正在从 API 和模型榜单继续往开发者工具界面深入。MiMo Code 值得关注的地方，不在于它能不能立刻取代某个既有产品，而在于它把“模型 + Harness + 记忆 + 工作流沉淀”开源到一个可以被真实测试的终端工具里。
