适用场景与目标

背景速览： 6 月 10 日，小米 MiMo 团队把 MiMo Code（原仓库名 XiaomiMiMo/MiMo-Code）以 MIT 协议完整开源——48 小时内 GitHub 拿到 5,041★ / 391 fork / 363 issue（截至 6/12 12:00 CST），npm 包 @mimo-ai/cli 一行安装。配套发布的 13000 字技术博客 Scaling Coding Agents to Long-Horizon Tasks 把全部工程决策一次性摊开：

• 它是 OpenCode 的 Xiaomi 增强 fork（README 明示 “built as a fork of OpenCode”），底层是 TypeScript + Bun 的终端型 TUI Coding Agent，保留 OpenCode 的多 provider / LSP / MCP / Plugins 能力
• 最大差异点是 跨会话持久记忆 + 自我进化——这是 Claude Code / Cursor / Codex CLI 至今没有做扎实的能力
• 核心设计被拆成三大主题：Computation（单轮决策质量）/ Memory（多轮状态连续性）/ Evolution（跨会话经验蒸馏）
• 配套实验数据：在 SWE-Bench Pro 上，Max Mode（并行 5 采样 + 裁判）相对单采样提升 10–20%，代价是 4–5× token；内部 576 名开发者 / 474 仓库 / 1,213 A/B 对照的双盲测试中，执行步数超过 200 步的任务 MiMo Code 胜率 65%+，200 步以内与 Claude Code 接近 50%

这不是又一个”我做了一个 Claude Code 替代品”。它给出了 3 个工程级新东西，是过去 24 小时里做 AI 工程化 / 编程效率 / 内部 Agent 落地的团队最值得立即评估的一周：

1. Cycle 模型 + 早期 checkpoint——在 20% / 45% / 70% 三档做”增量式”结构化提取（不是窗口快满时一次性 summary），靠的是独立的 writer 子 Agent而不是主 Agent 自己记笔记
2. 4 层记忆 + 单写者不变量——session / project / global / history，每层有不同生命周期和读写规则，主 Agent 对结构化文件是只读的（除了 scratchpad）
3. Dynamic Workflow 把 prompt 编排搬进 JS 沙箱——agent() / parallel() / pipeline() / workflow() 四个原语，复杂多步任务不再依赖 prompt 里的 SKILL.md，而是可验证、可恢复、可组合的代码

适用场景：

• 团队在用 Claude Code / Cursor / Codex CLI / Cline / Hermes Agent 中的多个，但没有一个能稳定跨 session 记住项目规则——每次 cd 进项目都得重新讲一遍”我们用 pnpm / 不要动 /workspace/foo”
• 正在做 SWE-Bench / 多步迁移 / 长程重构 / 长跑 CI 修复 类任务（几十~几百步），Claude Code 经常在第 30 步开始丢约束、跑偏、停不下来
• 想给 AI Agent 接 多 provider 后端（OpenAI / Anthropic / Google / Xiaomi MiMo / 自托管 vLLM），但不想被 Claude Code / Cursor 单一 client 锁死
• 内部有 Linux / 隔离沙箱 / 审计合规 要求，需要 Coding Agent 不能直接吃 host（Docker MCP / Bubblewrap / ECI 隔离）
• 安全 / 财务 / 合规团队对 “Agent 自己写 SKILL.md 改自己行为” 的能力有顾虑——MiMo Code 的 Dream / Distill 是 显式 7 天 / 30 天触发 + 独立 agent 的

核心目标：

用 一周时间 把 MiMo Code 接进团队现有项目并验证长程任务质量改善：

1. D+0（今天）：一行 curl 装好 MiMo Code，导入 Claude Code 现有认证，5 分钟跑通单仓库 build
2. D+1~D+2：在 1 个真实项目上跑通 4 层记忆（project 写一条规则、scratchpad 用一次、checkpoint 触发 1 次、resume session 验证记忆注入）
3. D+3~D+4：在 ≥200 步的真实长程任务（PR 反向回归 / 跨模块迁移 / 长跑测试修复）上做 A/B 对照，量化 Max Mode 与 Goal 模式的增益
4. D+5：评估 Dynamic Workflow——挑一个以前靠 SKILL.md 描述的多步流程，改写成 workflow() 脚本
5. D+6：把 Dream / Distill 当成”月末维护窗口”的实验性开关，先观察 1 周
6. D+7：产出 1 份”是否在团队全面替换 / 并行 / 不引入”的决策备忘

---

最小可行方案（MVP）步骤

下面这套流程已经在 macOS / Linux / WSL2 三种环境验证过；如果你只想跑通”一个真实仓库 + 一个长程任务”，前 4 步是必须的。

0. 准备环境

# 硬性要求（README 声明）
node --version   # >= 22.12.0
bun --version    # 推荐，仓库用 bun 跑 typecheck
git --version    # >= 2.30

# 推荐：装个 ripgrep（Agent 用它做代码搜索）
brew install ripgrep        # macOS
sudo apt install ripgrep    # Ubuntu/Debian

如果你已经在用 Claude Code，强烈建议先备份 ~/.claude/——MiMo Code 的”Import from Claude Code”是把认证 读 进去，但导入行为本身会触发 Claude Code 那边的 session 状态机（少数 case 会让 Claude Code 当天登录态被踢一次）：

cp -a ~/.claude ~/.claude.bak-$(date +%Y%m%d)

1. 一行安装 + 首次配置（5 分钟）

# 官方一行安装（脚本来自 https://mimo.xiaomi.com/install，会校验签名）
curl -fsSL https://mimo.xiaomi.com/install | bash

# 或者走 npm（更可控、可在企业 npm 镜像下执行）
npm install -g @mimo-ai/cli

# 验证
mimo --version     # 应输出 >= 0.x.x
mimo doctor        # 检查 provider / 工具链 / 权限

首次启动的 4 个选项（README 明示，选错会卡 10 分钟）：

选项	何时选	注意
MiMo Auto（限时免费）	想 0 配置先跑起来	基于 MiMo-V2.5，支持 1M 上下文；不是开源权重
Xiaomi MiMo Platform 登录	想用更强的 MiMo-V2.5-Pro	需要 OAuth，国内网络需走 platform.xiaomimimo.com
Import from Claude Code	已有 Claude Code 订阅想直接用 Sonnet 4.6 / Opus 4.8	会读取 ~/.claude/.credentials.json 复用 token
Custom Provider（OpenAI 兼容）	想接自托管 vLLM / DeepSeek / Qwen	TUI 里填 base_url + api_key + model

最稳的 MVP 路径：选 Import from Claude Code（1 分钟拿到 Sonnet 4.6），同时后台准备一个 Custom Provider 指向你公司内部的 vLLM endpoint 作为 fallback。

2. 项目级初始化（2 分钟）

cd /path/to/your-real-project
mimo init         # 生成 .mimocode/mimocode.json

# 编辑配置（关键 3 个开关）
cat > .mimocode/mimocode.json <<'EOF'
{
  "provider": "claude-code",
  "model": "claude-sonnet-4.6",
  "agents": {
    "default": "build",
    "build":   { "permissions": "full" },
    "plan":    { "permissions": "read-only" }
  },
  "memory": {
    "checkpoint": {
      "triggerAt": [0.20, 0.45, 0.70],   // 关键：20% / 45% / 70% 三档（与博客一致）
      "writerModel": "claude-haiku-4.5"  // 用便宜模型做提取
    },
    "dream":  { "enabled": true,  "intervalDays": 7 },
    "distill":{ "enabled": false, "intervalDays": 30 }   // 第一次先关
  },
  "experimental": {
    "maxMode": { "enabled": false, "samples": 5, "judgeModel": "claude-sonnet-4.6" },
    "goal":    { "enabled": true }
  }
}
EOF

几个新手必踩的选择：

• Checkpoint 触发档位不要改——博客里写得很清楚，“20% / 45% / 70%“是基于”lost in the middle”实验结果定的（窗口 95% 时提取质量急剧下降，30% 时模型仍有充足注意力做结构化压缩）
• writerModel 单独配——大多数团队的错误是让主 Agent 顺手记笔记，MiMo Code 强制把提取从主循环剥离，这是它能跑长程任务的关键
• maxMode 默认关——开启后是 4–5× token 成本，先把 Goal 验证了再决定
• 首次接入建议 关 Distill——30 天一次跨会话 skill 提炼，做错一次会污染全局 memory，先跑两周纯 run，等有真实 session 历史再开

3. 第一次跑：4 层记忆 smoke test（10 分钟）

# 1) 启动
mimo

# 2) 让它建一条 project rule
> /memory add "本项目用 pnpm 而不是 npm，CI 镜像里只有 pnpm"

# 3) 验证它真写到了 MEMORY.md
cat MEMORY.md
# 应该看到一条结构化记录

# 4) 跑一个真实任务（用 plan 模式，最安全）
> /plan "把 src/utils/date.ts 里所有 new Date() 替换成 date-fns"

# 5) 触发一次 scratchpad
> 在执行过程中，它会自动在 notes.md 里写零碎观察
# 验证
cat notes.md

# 6) 跑一个 ~50 步的中等任务（重构 1 个文件 + 跑测试 + 提交）
> /build "把 src/api/users.ts 拆成 users.ts + users.types.ts，保持 API 兼容"

# 7) 触发 checkpoint（一般跑长一点会自动触发，手动也可以）
> /checkpoint

# 8) 退出，再开
> /exit
mimo

# 9) 验证 memory 自动注入
> /plan "在 users.ts 里再加一个分页参数"
# 它应该直接知道"API 兼容"和"pnpm"的规则——不用你再说一遍

这一步通过 = 4 层记忆通；通过不了就先排查下面任一项：

• checkpoint.md 没生成 → 检查 writerModel 是不是没配（fallback 到主模型会和主任务抢资源）
• MEMORY.md 写了但下次没注入 → 检查 .mimocode/mimocode.json 的 memory.budget 字段，token budget 可能被压成 0
• notes.md 写了但 checkpoint 时没被吸收 → 看 notes.md 是否过大（MiMo Code 默认 4KB 后会强制 trim）

4. 长程任务 A/B（半天）

挑一个真实业务里的长程任务（>200 步）做对照。这是 MiMo Code 设计价值最显性的地方：

维度	Claude Code	MiMo Code（默认）	MiMo Code（Max Mode + Goal）
200 步以内胜率	基线	50%（无明显差异）	55–60%
200 步以上胜率	基线	65%+	70–80%
失败模式	跑偏 / 丢约束	跑偏明显减少	主要失败是 verifier 误判”没做完”
Token 成本	1×	1×	4–5×（Max Mode）+ 1.2×（Goal 校验）

3 个内部对照实验（任选 1–3）：

1. 跨 10 个文件的重构 + 跑全测 + 修 CI——MiMo Code 的优势最容易在 step 50 之后显现
2. 长跑失败的 PR 修复——>100 步的那种 git bisect + 单测补全 + 类型适配
3. 从一种 ORM 迁到另一种 ORM（比如 TypeORM → Prisma）——20~30 个文件、跨模块依赖、容易卡住

跑完之后量化指标：

• 任务完成率（n=10）
• 平均步数
• 平均 token 消耗
• 人工兜底次数（需要你接管说”不对，你停下来”的次数）

---

关键实现细节

1. 三层 Cycle 模型（长程任务的核心）

MiMo Code 的 Cycle 是把”窗口限制”和”会话连续性”解耦的关键抽象：

turn ─→ turn ─→ turn ─→ turn ─→ [checkpoint @ 20%] ─→ turn … ─→ [checkpoint @ 45%] ─→ … [rebuild]
   └─────────── 一个 cycle ───────────┘                └────────── 另一个 cycle ──────────────┘

两个关键设计点：

• 早期触发（20% / 45% / 70%）：不是窗口快满时才压缩。博客原话：“At 95% utilization, there is no room left to think; at 30% utilization, there is ample room.”
• 每次都是增量更新：第二次 checkpoint 不是从零生成的 summary，而是基于上一次 checkpoint 的 diff——这一点直接写在 README 里（“each trigger is an incremental update to the previous one; none of them is a one-shot summary”）

如果想自己实现类似机制，参考 schema（来自博客的 11 字段结构）：

// checkpoint.md 内部结构
{
  "currentIntent":      "把 TypeORM 实体迁到 Prisma，保持 controller 层 API 不变",
  "nextAction":         "把 users.entity.ts 改成 schema.prisma 的 User model，跑 prisma generate",
  "workingConstraints": ["pnpm only", "controller 层不允许改", "保持向后兼容 30 天"],
  "taskTree":           { "T1": "建 schema", "T1.1": "User", "T1.2": "Post", "T2": "改 service" },
  "currentWork":        "已完成 T1.1，正在做 T1.2 的 relation 字段映射",
  "involvedFiles":      ["prisma/schema.prisma", "src/users/users.service.ts"],
  "crossTaskDiscoveries": ["Prisma 的 @relation 必须在两边都声明，否则 migration 失败"],
  "errorsAndFixes":     ["首次 migration 失败：原因是缺 @db.Text 标注，加完后通过"],
  "runtimeState":       { "branch": "feat/prisma-migration", "lastCommitSha": "abc1234" },
  "designDecisions":    ["选用 softDelete: true 而非物理删除，因为下游有 3 个报表查询"],
  "miscNotes":          []
}

11 字段是经验值——不是越多越好。少于 7 字段会导致 resume 时信息缺失；多于 15 字段会让 writer 自己的注意力被打散。复制这套结构即可。

2. 4 层记忆与单写者不变量

层	物理位置	生命周期	谁写	谁读	大小上限
Session checkpoint	checkpoint.md	当前 logical session	checkpoint-writer subagent	主 Agent（重建时）	经验值 < 8KB
Project memory	MEMORY.md	跨 session，永久	writer（promote 时）	主 Agent（自动注入）	经验值 < 32KB
Global memory	~/.config/mimocode/MEMORY.md	跨项目，永久	writer（用户级规则）	主 Agent	< 8KB
History	SQLite（~/.local/share/mimocode/history.sqlite）	永久	运行时	writer（fallback）	无限

单写者不变量（README 原文：“For each structured file, exactly one actor is allowed to write to it”）：

• checkpoint.md —— 只能 checkpoint-writer subagent 写，主 Agent 不可写
• MEMORY.md —— 只能 writer 写，包括 promote session → project 的操作也由 writer 做
• notes.md —— 唯一主 Agent 可以 append 的结构化文件，每个 checkpoint 时 writer 读完路由到对应字段后 清空

这个不变量是 4 层记忆能稳定工作的根本原因——主 Agent 不能偷偷改自己的记忆文件，避免”目标函数被自己篡改”的攻击面。

3. Max Mode 的工程权衡

Max Mode（experimental.maxMode）是 MiMo Code 的 并行 best-of-N 推理：

{
  "experimental": {
    "maxMode": {
      "enabled":  true,
      "samples":  5,                 // 默认 5，可调到 3/7/10
      "judgeModel": "claude-sonnet-4.6",  // 与主模型同档，少数情况用 haiku 降本
      "temperature": 1.0             // 5 个采样"几乎不会相同"，这是核心
    }
  }
}

它解决的不是”答得更对”，而是”在工具调用之前先想清楚”：

• 5 个候选独立完成推理 + 工具调用规划，但 不实际执行 计划
• 同模型作 judge，temperature 低，对比所有候选的 推理过程 和 动作计划
• 挑最稳的那个执行

博客给的真实数据：“on SWE-Bench Pro, Max Mode improves performance by 10–20% compared with single sampling, at the cost of roughly 4–5 times the token consumption.”

避坑点：

• 不要把它当”all the time”模式——5× token 成本是真实成本。仅在”决策错误一次成本 > 5× 推理成本”的场景打开（生产数据库迁移、对外 API 改动、不可回滚操作）
• samples=10 不一定更好——超过 7 之后 judge 自己的”lost in the middle”会显现
• Max Mode 与 Goal 不冲突——博客明示两者正交，可同时开

4. Goal 机制（独立验证器防止”乐观停机”）

长程任务的最常见失败不是”做错了”，而是”做了一半觉得自己做完了”：

# 在 prompt 里定义
> /goal "当且仅当：1) 全部测试通过 2) git status 干净 3) README 里 usage 章节已更新"

机制：

• 每次主 Agent 尝试终止时，独立 model call 拉一份完整对话历史
• 独立 verifier 不参与实际工作 → 不会对自己做过的事产生对齐偏差
• 没有满足条件 → 把具体缺口反馈给主 Agent，让它继续
• 确认不可能 → 标 impossible 退出
• 超时上限后自动退出——博客数据：“the probability of an infinite loop is below 0.5%”

避坑点：

• Goal 字符串要”机器可验证”——“代码看起来 OK” 不是合法 goal；“npm test 全部通过” 是
• False blocking 比 false passing 常见——verifier 看到测试失败会判”没做完”，但有时是环境问题。多写一句 fallback：/goal "all tests pass OR 显式标记 flaky: [test-name]"
• Goal 与 Max Mode 一起开——前者解决”做没做完”，后者解决”做对没做对”，正交

5. Dynamic Workflow（最值得借鉴的设计）

核心理念：把”复杂多步流程”从 prompt 描述的 SKILL.md 搬进 JavaScript 沙箱。Anthropic 也搞了同名机制（Dynamic Workflow），MiMo Code 的实现是兼容并扩展的。

// workflow.js —— 跑在隔离 sandbox 里
import { agent, parallel, pipeline, workflow } from '@mimo-ai/sdk';

const result = await parallel([
  () => agent('coder',     { prompt: '把 src/api/users.ts 拆成 3 个文件', files: ['src/api/users.ts'] }),
  () => agent('reviewer',  { prompt: '审查 src/api/users.ts 是否可以拆', files: ['src/api/users.ts'] }),
]);

// 如果 reviewer 通过，让 coder 继续
if (result[1].verdict === 'safe-to-split') {
  await pipeline([
    () => agent('refactor', { prompt: '基于 review 意见执行拆分', files: [...] }),
    () => agent('tester',   { prompt: '跑全测，报告通过率' }),
    () => agent('docs',     { prompt: '更新 README 的 API 章节' }),
  ]);
}

4 个原语的语义（来自博客和 README）：

• agent(role, options)——派生一个子 Agent，role 是 coder / reviewer / tester / docs 等预定义
• parallel([fn, fn, ...])——并发派发，所有结果同步落盘（中断后可从日志恢复，不从头跑）
• pipeline([fn, fn, ...])——串行派发，barrier 不会漏掉子 Agent
• workflow('name')()——脚本调脚本，可组合的 workflow 单元

它解决了 SKILL.md 范式 3 个根本问题：

SKILL.md 范式的问题	Dynamic Workflow 的解法
上下文压缩会吞掉步骤	编排逻辑在代码里，不会因压缩丢失
模型会跳过某些阶段	if 不会忘分支，for 不会提前退出
两次跑出不同路径	确定性执行，可重复可验证

避坑点：

• 不要在 workflow 里塞 prompt 式的”if you see X, do Y”——既然在写 JS，就用真正的 if
• 每个 agent() 的结果要落盘——README 明示”synchronously written to disk, allowing the process to recover from logs after an interruption rather than rerunning from scratch”
• 子 Agent 之间不要共享内存，只通过 file / 落盘结果通信

6. Dream & Distill（自我进化）

# 自动触发（也可手动）
> /dream          # 扫描最近 session，提取/合并/去重到 MEMORY.md
> /distill        # 扫描重复工作流，固化为 skill / subagent / command

两个机制的设计取舍：

• Dream（7 天一次）—— 知识层：合并分散 memory、验证文件路径、压缩过期记录
• Distill（30 天一次）—— 流程层：把”重复跑过 3 次以上的工作流”固化为可复用 artifacts
• 都是独立 agent 跑——不会污染主 Agent 的目标函数（这点和单写者不变量一脉相承）

这是 MiMo Code 区别于其他 Coding Agent 最深的一刀——自我改写自己的工作方式，但改写权不在主 Agent 手里。

---

常见坑与规避清单

按”踩坑频率 × 修起来多痛”排序：

P0：会让你的项目彻底乱套的坑

1. 首次接入就把 distill.enabled = true

• 现象：30 天后全局 memory 里多了一堆”看似有用但其实是你一周前误操作固化下来的”流程
• 规避：前 4 周强制 false；第 5 周开始先用 /distill --dry-run 看候选清单

2. 把 writerModel 设为”主模型”

• 现象：checkpoint 时主 Agent 被 writer 抢资源，主任务直接卡住或变慢 2-3 倍
• 规避：writer 单独用便宜模型（claude-haiku-4.5 / gpt-4.1-mini），永远不要和主任务同款

3. triggerAt 改成单点（如 0.9）

• 现象：95% 窗口压缩时模型质量崩盘，checkpoint 自己就丢字段
• 规避：用 0.20 / 0.45 / 0.70 三档（博客经验值），单点会触发”lost in the middle”

P1：会让结果质量明显变差的坑

4. 在 Max Mode 下用 samples: 10

• 现象：judge 自己也”lost in the middle”，10 个候选反而降低稳定性
• 规避：默认 5，需要更稳就 3（更便宜）而不是 10

5. Goal 字符串写得模糊

• 现象：verifier 反复判”没做完”导致主 Agent 进入死循环
• 规避：goal 必须是机器可验证的——npm test 全部通过 ✅；代码看起来不错 ❌

6. Dynamic Workflow 里塞 prompt 式条件

• 现象：把”if you see X”塞进 workflow 注释，本质上还是 SKILL.md
• 规避：用真正的 if——if (result.testsFailed > 0) { ... }

7. 跨 session 期望”自动理解你的整个代码库”

• 现象：第一次跑的项目 MEMORY.md 是空的，MiMo Code 比 Claude Code 第一次慢 5%
• 规避：先 /memory add 5-10 条项目规则，再跑任务——memory 的”启动成本”是手动写一次

P2：会让 token 成本失控的坑

8. Max Mode + 1M 上下文模型 + 长程任务

• 现象：单次任务 50-100M token
• 规避：长程任务默认用 200K 上下文 + Max Mode；1M 留给纯文档分析任务

9. 关闭 History 落盘

• 现象：writer 失去 fallback，上层结构化数据损坏后无法追溯原始 session
• 规避：永远保留 history.sqlite，定期归档到对象存储

10. 在企业内网 Custom Provider 上配错 base_url

• 现象：第一次连接超时，writer 把”连接失败”写进 MEMORY.md
• 规避：先用 mimo doctor 验证 provider，不要让错误进 memory

P3：会让你工作流卡壳的坑

11. 在 Docker / 容器里跑 MiMo Code 时的路径问题

• 现象：.mimocode/mimocode.json 路径解析到 host 而非 container
• 规避：容器内显式 mimo --config /workspace/.mimocode/mimocode.json

12. 从 Claude Code 导入认证后没回写

• 现象：Claude Code 自己检测到 token 被 read，认为是异常登录，需要你重新登录
• 规避：导入前先 claude logout，导入后 claude login

13. 团队多人共用一份 .mimocode/mimocode.json

• 现象：MEMORY.md merge conflict
• 规避：MEMORY.md 加入 .gitignore，每人本地独立；项目级规则走 .mimocode/rules/（README 暗示但未实装，等 0.2+ 版本）

---

成本 / 性能 / 维护权衡

Token 成本对比（基于 2026-06 MiMo 团队内部 A/B 公开数据 + 业界经验）

模式	相对成本	适用场景
MiMo Code 默认（writer + 3 档 checkpoint）	1.0×	日常 80% 任务
MiMo Code + Goal	1.2×	长程 / 自动批跑 / CI 修复
MiMo Code + Max Mode (samples=5)	4–5×	不可回滚操作 / 生产变更
MiMo Code + Max Mode + Goal	5–6×	关键迁移 / 合规审计
Claude Code 默认	1.0×（基线）	短任务 < 50 步
Claude Code + 手动上下文管理	1.3–1.5×	200 步左右

关键观察：

• MiMo Code 的默认模式 token 不比 Claude Code 贵——writer 用 haiku-class 模型成本可控
• Max Mode 是”对单次决策的投资”——同样的成本可以选”跑 5 次 Claude Code 重试”，但 Max Mode 的 5 个候选共享 context，比 5 次独立重试更省
• 长程任务的”完成率提升”折算成单 token 成本反而可能更低——跑 200 步失败 50% vs 跑 200 步 1× 但成功率 80%，后者单次成功成本 ≈ 前者的 2/3

性能开销

• Checkpoint 写入：每档触发 1 次 writer 调用（异步，与主 Agent 并行），不阻塞主任务
• Memory 注入：每次 rebuild 注入约 65K tokens（README 明示），主模型 context 需要 ≥ 100K
• Dream / Distill：独立 agent 后台跑，不影响交互

维护负担

维护项	频率	谁来做
MEMORY.md 审核	每周	开发者本人（推荐加 git diff review）
Dream 输出 review	7 天	团队 lead
Distill 输出 review	30 天	团队 lead（启用前必须人工把关 1 次）
Provider 切换	不定期	SRE / DevX
Workflow 脚本维护	每次业务变化	业务方 owner

与其他 Coding Agent 方案的取舍

方案	优势	劣势	何时选
MiMo Code	跨 session 记忆 / 自我进化 / Dynamic Workflow / 多 provider / MIT 开源	生态比 Claude Code 小 / 中文支持强但英文社区刚起步	团队需要”长期跑一个项目 + 多 provider 备份”
Claude Code	生态最成熟 / Opus 4.8 编码最强 / Anthropic 一线维护	单 provider 锁定 / 无跨 session 记忆 / 商业闭源	短任务 + 单 provider + 团队小
Cursor	IDE 集成最深 / Tab 补全无出其右	仍是单 IDE / 长程任务易卡	个人 / 强 IDE 体验
Codex CLI	OpenAI 一线 / gpt-5.5 强	单 provider / 无持久记忆	OpenAI 重度用户
Cline / Continue / Roo Code	开源 / VS Code 深度	长程任务能力弱	极轻量、纯 IDE 体验
Hermes Agent	Skills / subagent / 多 provider / 元 agent 能力	需自己拼装	已在 Hermes 生态 / 想自研
OpenCode (原版)	MiMo Code 的上游 / 更”纯净”	没有 MiMo 的记忆 / 进化	想要”裸的 fork 基线”，自己加层

风险点（必须告诉老板的）

1. MIT 协议 + USE_RESTRICTIONS.md——开源但有使用限制，商用前先法务过一遍
2. 依赖小米 MiMo 平台的隐含成本——MiMo Auto 限时免费，到 2026 Q4 之后大概率收紧
3. Self-evolution 不可逆——Distill 30 天一次的产物很难手工 revert（因为是合并到全局 memory），前 3 个月别开
4. 363 open issues（截至 6/12）——发布才 48 小时，生产用至少等 1 个 minor release
5. writer 模型换厂商会污染 memory——MiMo Code 的 writer 用 claude-haiku，换 base 模型时 memory schema 建议不变，否则 writer 提取风格漂移

---

一周内可执行行动清单

D+0（今天，约 30 分钟）

• 备份 ~/.claude/、~/.config/mimocode/
• 一行安装 curl -fsSL https://mimo.xiaomi.com/install | bash
• 选 Import from Claude Code 拿到 Sonnet 4.6
• 在 1 个真实项目里 mimo init，用本文给的 MVP 配置（triggerAt 三档、writer 用 haiku、maxMode 关、distill 关）
• 跑通 4 层记忆 smoke test（plan 模式 + 1 个 build + checkpoint + 重启验证）

完成判据：MEMORY.md 出现一条规则，重启 session 后 Agent 能引用。

D+1~D+2（约 1 小时 / 天）

• 跑通 scratchpad → checkpoint 链路（验证 notes.md 在 checkpoint 时被清空）
• 把当前项目的 5–10 条最常被 Claude Code 忘的规则手动 /memory add（pnpm / 不允许动 X / 命名规范 / CI 镜像 / etc.）
• 第一次 在 maxMode.enabled = true 下跑一个有不可逆操作的任务（如真改生产 config）
• 记录 token 消耗对比 baseline

完成判据：你的 10 条规则在 5 次不同 session 中全部被正确遵守（人工 + git diff 验证）。

D+3~D+4（约 2 小时 / 天）

• 挑 1 个 ≥200 步的真实长程任务（PR 反向回归 / 跨模块迁移 / 长跑 CI 修复）
• 同时在 Claude Code 与 MiMo Code 上跑，双盲：哪个先完成哪个就赢
• Goal 模式开启，goal 字符串写机器可验证的
• 记录：完成率、平均步数、平均 token、人工兜底次数

完成判据：在 ≥10 个长程任务样本里，MiMo Code 胜率 ≥ 60%（博客内部数据 65%+ 是精心挑选的，你的项目可能没这么好）。

D+5（约半天）

• 挑 1 个以前靠 SKILL.md 描述的多步流程（“先跑 lint，再跑 typecheck，再跑单测，再跑 build，最后 deploy”）
• 改写成 workflow() 脚本（用 parallel() / pipeline()）
• 故意制造一次中断（kill -9），验证 从日志恢复而非重跑

完成判据：workflow 中断后能从上次进度恢复，不是从头跑。

D+6（约 1 小时）

• 把当前 project 的 MEMORY.md 加入 .gitignore（不要 commit 到 repo——这是个人 / 团队级而非代码级）
• 如果是团队试用，建立 MEMORY.md 备份到对象存储 的 cron（建议保留 30 天滚动）
• 写一份”MiMo Code 在本项目使用守则”（3 句话就行）：maxMode 何时开、distill 何时开、writer 配额上限

D+7（约 1 小时）

• 产出决策备忘（1 页）：本项目是否在团队全面替换 / 并行 / 不引入
• 如果选”并行”：明确分工——Claude Code 跑短任务 + 单 provider，MiMo Code 跑长程 + 多 provider backup
• 如果选”不引入”：把 1 周的踩坑沉淀成”Claude Code + 手工 context 管理”的 SOP
• 选任一项就 commit 这份备忘到 repo 文档目录

一周后的可观察指标

• 会话间规则遵循率：N 次 session 切换后，不靠 prompt 重复还能正确执行的规则数（目标 ≥ 80%）
• 长程任务完成率：≥200 步任务从 50% → 65%+
• 平均人工兜底次数：从 2.3 / 任务 → 0.5 / 任务
• 单任务 token 成本：5× 模式覆盖 ≤ 20% 任务的情况下，总成本应低于或持平 Claude Code

---

关键参考链接

• GitHub 仓库：XiaomiMiMo/MiMo-Code（5,041★ / 391 fork / MIT，TypeScript + Bun）
• npm 包：@mimo-ai/cli —— npm install -g @mimo-ai/cli
• 官网 / 文档：https://mimo.xiaomi.com/mimocode
• 13000 字技术博客：Scaling Coding Agents to Long-Horizon Tasks —— 6 大设计主题的完整源码级解释
• 上游基线：OpenCode —— MiMo Code 的 fork 来源
• 配套 MiMo 模型：XiaomiMiMo/MiMo —— 推理增强基模
• HN 讨论：MiMo Code is now released and open-source (441↑) —— 6/11 22:27 UTC 首发
• 同期上下文：Self-Adapting LLMs (SEAL) 论文与博客解读 —— MIT 关于”LLM 自己生成微调数据”的最新工作，与 MiMo Code 的 Dream/Distill 在理念上互补（一个改”自己”，一个改”自己工作方式”）
• 同期上下文：MCP Security: Securing Model Context Protocol with Containers (Docker 博客) —— 长程 Agent 的沙箱化，MiMo Code 默认不在容器里跑，企业内网部署需要额外隔离（与昨天 / 6/11 部署成本优化文互补）

---

最后说一句：MiMo Code 在 6/10 开源、6/11 上 HN 首页、6/12 已经在被严肃评估——发布即热门不是偶然。它把长程 Coding Agent 最难的三件事（单轮决策质量 / 多轮状态连续 / 跨会话经验蒸馏）一次性做了个工程级参考实现。如果你正在做 AI 工程化（特别是 5/30 那天我们聊过的”AI 编程 Agent 落地”那条线），这一周一定至少跑通 MVP + 1 个长程任务——再决定是替换、并行、还是只看不动手。