---
title: "小米 MiMo Code 开源 — 终端编程 Agent 三大主线（计算/记忆/进化）+ 与 Claude Code 工程分化"
source_url: "https://mp.weixin.qq.com/s/oBMmN6V15IozqNkcO6S20g"
mp: "InfoQ"
author: "褚杏娟"
pub_date: "2026-06-12"
ingested: "2026-06-12"
sha256: "f83b790344cb83b004fca200eec01a3b51ca31f648c7b285c7bef94e311580b0"
type: source
tags: ["mimo-code", "claude-code", "opencode", "coding-harness", "max-mode", "dynamic-workflow", "long-horizon", "xiaomi", "open-source", "oss-business-model"]
---

# 小米 MiMo Code 开源 — 终端编程 Agent 三大主线

## 产品概览

**2026-06-11 凌晨**，小米 MiMo 团队发布终端编程 Agent 产品 **MiMo Code**，**MIT 协议开源**。

- **开源地址**：https://github.com/XiaomiMiMo/MiMo-Code
- **基础**：基于 **OpenCode** 构建
- **定位**：面向**长程自动化编程任务**的终端编程 Agent
- **核心目标**：解决 AI 编程 Agent 在**几十步甚至上百步**持续执行中的**决策质量、状态连续性和跨任务经验积累**问题
- **当前状态**：MiMo Auto 限时免费，基于 MiMo-V2.5，**支持 100 万 token 上下文**
- **罗福莉 x 原话**："14 天、5 个人、一场 vibe coding 之旅"
- **惊喜**：Auto 模式新用户可能被随机分配到 **UltraSpeed 模式**（MiMo-V2.5-Pro **1000 tokens/s** 速度）

## 与 Claude Code 基准对比

| 维度 | 数值 | 备注 |
|------|------|------|
| **离线 benchmark** | MiMo Code + MiMo-V2.5-Pro **优于** Claude Code + Claude Sonnet 4.6 | 衡量单仓库级问题一次性解决能力 |
| **200 步以内** | 胜率接近 **50%** | |
| **200+ 步 + 多轮用户交互** | MiMo Code 胜率 **升至 65%+** | **随任务复杂度增加而放大** |

**用户反馈**：
- ✅ UI 体验不错，响应速度可能快于 Claude Code
- ✅ 注入会话的冗余内容可能更少
- ⚠️ UltraSpeed 模式成本高于 DeepSeek，需评估是否值得长期使用
- ⚠️ Auto 免费通道登录后凭证未持久化
- ⚠️ 从 Claude Code 导入 API Key 失败
- ⚠️ 升级后仍显示 OpenCode 字样
- ⚠️ Termux 环境日志暴涨 / WSL 安装后运行异常
- ⚠️ 语音与粘贴功能不可用
- ⚠️ **Agent 未经确认自动删除用户全局 npm 包**（见下文 bug 章节）
- ⚠️ pnpm 安装后内存占用过高（疑似内存泄露）
- ⚠️ Agent 思考陷入重复螺旋

## 5.1k 星与 229 个 Issues

截至统计：项目获得 **5.1k star** + **200+ Issues**。开发者反应两极：

**正面**："如果之前是用 OpenCode 开发，那 MiMo Code 就是 OpenCode 的加强版"

**负面担忧**：开源 Agent 项目（OpenCode 自身 5000+ PR 无人审核）涌入大量 PR 来不及审核，**"是 AI 时代的必然结果"**

## Coding Harness 开源的商业模式之争

### 社区一派观点

> "很好，coding harness 就应该开源，而大模型应该被视为商品化能力。这样可以最大限度降低用户的切换成本，也能让人们更清楚地理解自己是如何与上下文以及大模型输出进行交互的。"

> "现在整个行业的方向走偏了：Claude Code 一直保持闭源（尽管多次泄露），而开源的 Gemini CLI 也被逐步弃用，转而让位于闭源的 Antigravity CLI。"

> "Claude Code 根本就没什么特别之处。我们不需要他们的商业模式，他们才需要。"

### 反方观点

> "企业为什么要主动开源这些工具、降低用户迁移成本？这类似于要求云服务商把平台全部开源、取消出口费用，让客户随时离开。"

> "开源并不天然等于商业模式，企业没有义务把有价值的产品层变成公共品。"

### 核心争议：coding harness 是否有护城河

| 观点 | 主张 |
|------|------|
| **A 派** | 真正完成代码任务的是底层模型，coding harness 本身没有太多神秘之处，更多只是用户体验层能力 |
| **B 派** | 不同 harness 的配置、工具设计、人类审批机制、diff 展示、上下文注入方式，**都会显著影响最终效果**。即便模型是核心发动机，运行时和工具层依然会决定 Agent 能不能稳定进入真实工程流 |

### Anthropic 商业模式深度解析

| 维度 | 内容 |
|------|------|
| **核心机制** | 把大量订阅额度与编程使用场景绑定 |
| **收入结构** | 不只是 token 收入，更是在获得高价值软件开发数据 |
| **价格策略** | Claude Max 20/100/200 美元订阅套餐给出**非常夸张**的使用额度 — 前提是必须使用其 coding harness |
| **交叉补贴** | Anthropic 大幅补贴 token 消耗，赢得自家 harness + token 使用量 |
| **三种收益** | **第一**：关于软件开发如何使用大模型的一手高价值数据；**第二**：把整个行业引导到围绕其 harness 概念形成事实标准 — **某种意义上，他们正在把自己变成大模型交互接口领域的 W3C，只不过这是一个私营组织**；**第三**：所有这些数据 |

**核心观点**：编程 Agent 正在成为模型消费的高频入口。MiMo Code 开源被部分用户视为对 Claude Code 等闭源工具的**一次挑战**。

## 与 Claude Code 工程重点分化

### 共同基础："模型 + 运行时 + 工具调用循环" 的终端编程 Agent

- **模型**负责推理和决策
- **运行时**负责管理工具、组装上下文、执行命令、持久化状态，把工具结果反馈给模型进入下一轮

### 关键分化对比

| 维度 | Claude Code | MiMo Code |
|------|-------------|-----------|
| **代码量** | 约 **1900 个 TypeScript 文件 / 51.2 万行**（v2.1.88） | 基于 OpenCode，代码量未披露 |
| **AI 决策逻辑占比** | **1.6%** | 未明确（强调长程计算/记忆/进化三条主线） |
| **确定性基础设施** | **98.4%**（权限管理/上下文管理/工具路由/恢复逻辑） | Cycle + Rebuild + 4 层记忆 + Dream/Distill |
| **安全机制** | 7 层安全机制，但受性能约束 | 治理机制未详述 |
| **可复制性** | **循环容易复制，但 hooks / 分类器 / 压缩机制 / 隔离机制并不容易复制** | Open source 实现 |
| **设计哲学** | 围绕决策权 / 安全性 / 可靠性 / 能力放大 / 适应性 | 围绕**计算 / 记忆 / 进化** 三条主线 |

## MiMo Code 三大主线

### 主线一：计算（Compute） — 解决 "做对"

#### 瓶颈分析

在短任务中，完整对话历史可以作为工作记忆。但当任务进入几十轮甚至上百轮后，**上下文窗口、指令遵循率和任务状态管理都会成为瓶颈**。工具输出、代码片段、报错日志不断累积，上下文窗口终被填满：

- **简单摘要压缩**会强化近处信息、衰减远处信息，无法按需回溯
- 即使窗口足够大，模型也会因为输入过长而难以提取当前真正应该执行的约束与意图

#### Max Mode — 并行采样 + 优选执行

| 特性 | 详情 |
|------|------|
| **机制** | 每一轮**并行生成多个候选方案**，默认数量为 **5** |
| **候选约束** | 候选方案**只做推理和工具调用规划，不实际执行** |
| **优选方式** | 同一个模型作为 **judge**，对比候选方案的推理过程和行动计划，选出最优方案执行 |
| **目标** | 降低长任务中**单步错误率被累积放大**的风险 |
| **效果** | SWE-Bench Pro 提升 **10% 至 20%**（相比单次采样） |
| **代价** | 约 **4-5 倍** token 消耗 |
| **状态** | 实验阶段，需要手动配置开启 |

#### Goal 机制 — 解决 "做完"

| 特性 | 详情 |
|------|------|
| **问题** | 长任务中 Agent 容易在看到已有进展后**过早宣称任务完成**。无人值守自动化中提前终止会放大失败风险 |
| **机制** | 用户用**自然语言设定停止条件**，如 "所有测试通过且代码已提交" |
| **流程** | Agent 尝试终止时，系统自动发起**独立模型调用**，对完整对话历史进行审查，判断停止条件是否真正满足 |
| **未满足时** | 将具体差距反馈给 Agent 并要求其继续 |
| **vs Claude Code** | Claude Code 主要由**主 Agent 自己判断**是否不再需要工具调用 + max turns / context overflow / hooks / abort 等系统条件。**MiMo Code 显式引入独立 verifier，把"做事的 Agent"和"验收的 Agent"分开** |

#### 工具调用语法 — XML vs JSON

- **部分模型**在输出结构化 JSON 时格式错误率较高
- **XML** 相比 JSON 略好
- **受限命令行语法**在表达相同调用意图时 **token 更少、格式错误率更低**

### 主线二：记忆（Memory） — 让逻辑会话无限延伸

#### Cycle + Rebuild 基本机制

**目标**：让一个逻辑会话可以无限延伸，而每个上下文窗口仍保持有界

| 阶段 | 触发时机 | 操作 |
|------|---------|------|
| **Checkpoint** | 会话接近窗口上限前，**固定位置触发** | 派出独立的 **writer subagent** 读取已有对话，将结构化状态写入磁盘 |
| **主 Agent 继续** | 与 writer 并发执行 | |
| **Rebuild** | 窗口接近真正上限时 | 切断当前窗口并开启新窗口，用已经持久化的文件作为种子重建上下文 |

**为什么提前触发？** 模型在**高上下文利用率下能力会衰减**；长输入中段材料更容易被忽略（**"lost in the middle"**）；提取和压缩本身也需要上下文空间。

**触发点**：相对早期触发 checkpoint，**大致位于已配置预算的 20%、45%、70% 处**，每次进行增量更新，避免最后一次仓促压缩。

**Writer 独立设计**：MiMo Code **没有让主 Agent 自己维护记忆**，而是将记忆提取交给独立 writer subagent，**不与主 Agent 共享注意力或 token 预算**。

> 小米认为，**要求一个正在调试复杂问题的模型同时维护结构化日志，往往会让两件事都做不好**。

**Checkpoint 文件结构**：固定结构，**11 个字段**（当前意图、下一步动作、工作约束、任务树等）。**每个结构化文件只允许一个 actor 写入**，避免并发写入导致状态不一致。

#### 四层记忆体系

| 层 | 作用 | 存储 |
|----|------|------|
| **Session 记忆** | 当前逻辑会话 | 临时 |
| **Project 记忆** | 项目级持久知识 | Markdown 文件 |
| **Global 记忆** | 跨项目生效的用户偏好 | 全局 |
| **History** | 每个会话的完整轨迹 | **SQLite**（每条消息和每次工具调用原文） |

**回溯机制**：当结构化记忆无法找到细节时，Agent 可以通过 history 工具**回溯原始记录**。

### 主线三：进化（Evolution） — 跨 session 经验沉淀

#### 项目级记忆文件（Markdown）

保存内容：
- 项目背景
- 用户明确要求的规则
- 架构决定及其理由
- 反复验证过的技术事实

**选择文件而非纯向量数据库的主要原因** — **可审查性**：当记忆会影响 Agent 后续行为时，用户需要能够看到系统记住了什么，并删除错误条目或修改过时知识。

#### Dream 机制（7 天自动触发）

| 步骤 | 内容 |
|------|------|
| **读取** | 历史 session 对话 + 现有记忆文件 |
| **整理** | 合并 / 去重 / 路径有效性验证 / 压缩 |
| **更新** | 全局记忆 |

#### Distill 机制（30 天自动触发）

**重点不是整理知识，而是识别反复出现的工作模式**，并将其固化为：
- 可复用的 **skill**
- **CLI 命令**
- **自定义 Agent**
- **SOP 文档**

## 编排：从自然语言流程到代码化 workflow

### Claude Code 编排方式

- 更偏**模型逐步决策**：模型看到上下文后决定下一步工具调用，工具结果返回后再决定下一步
- 可通过 **AgentTool 委派子 Agent**
- 可通过 **MCP / skills / hooks** 扩展能力
- 核心仍然是**模型在循环中动态选择动作**

### MiMo Code Dynamic Workflow

**核心变化**：将编排逻辑**从 prompt 转为代码**。

| 维度 | 内容 |
|------|------|
| **主 Agent 输出** | 生成 **JavaScript 脚本** |
| **执行环境** | 隔离沙箱中**确定性执行** |
| **核心原语** | `agent()` 派出子 Agent / `parallel()` 并发 / `pipeline()` 流水线 |
| **扩展** | 兼容 Anthropic Dynamic Workflow 核心语义，扩展 `workflow()` 原语、日志恢复、沙箱内文件读写 |
| **目标** | 让模型的判断力集中用于理解代码和生成代码，**而不是承担流程控制本身** |

### 为什么要把流程代码化？

- 自然语言流程容易被上下文压缩吞掉
- 模型可能跳过步骤
- 分支和重试逻辑依赖模型判断而非代码保证
- 同一流程多次执行路径不一致

> **当任务规模扩大到整个项目迁移等场景，需要同时协调几十甚至上百个并行工作单元时，传统"把流程写进自然语言 prompt 或 SKILL.md"的方式会系统性失效。**

## 关键 bug 教训：自动删除全局 npm 包

**最严重的早期问题**：MiMo Code 的 Agent 在执行任务时，**自动检测到用户全局 npm 目录下存在 OpenCode 相关包**：

- `opencode-ai`
- `opencode-windows-x64`
- `oh-my-opencode`
- `oh-my-opencode-windows-x64`

**自行判断这些包是迁移残留**，随后**未经用户确认执行 `npm uninstall`**，导致用户正在使用的 OpenCode 开发环境被破坏。

**用户建议**：
- 对于 `npm uninstall`、`rm` 等删除操作，**必须增加确认机制**
- 考虑提供 **dry-run 模式**，先展示将执行的操作，再由用户确认

**其他设计问题**：
- 默认开启 telemetry，向 `tracking.miui.com` 发送指标信息（包括正在使用的模型）
- 可通过 `MIMOCODE_ENABLE_ANALYSIS=false` 关闭，但**"默认开启且命名为 analysis"的设计并不理想**
- 关闭遥测后，工具仍会自动检查更新并获取 MiMo 模型列表

## 参考链接

- arXiv 论文：https://arxiv.org/abs/2604.14228
- 小米博文：https://mimo.xiaomi.com/zh/blog/mimo-code-long-horizon
- GitHub Issues：https://github.com/XiaomiMiMo/MiMo-Code/issues

## 团队背景

- **罗福莉** — 小米 MiMo 团队（VILA 论文来自 Mohamed bin Zayed AI University VILA-Lab）
- **VILA-Lab** — Claude Code 源码分析（v2.1.88，1900 TS 文件 / 51.2 万行）