MiMoCode：12.8K Star 的小米官方 Coding Agent——把 OpenCode fork 成「模型与 Agent 协同进化」闭环：310B 自家模型 + SQLite FTS5 持久记忆 + 14 阶段 compose 流水线，代价是免费 API 已关、坏 key 静默退出

先建立坐标系：大厂第一次把「模型 + Agent」做成一个产品闭环

过去一年 Coding Agent 赛道的玩家分两类：一类是模型厂做 agent（Anthropic 的 Claude Code、OpenAI 的 Codex、xAI 的 Grok Build），一类是纯软件做 agent（OpenCode、Cline、Kilo）。小米的 MiMoCode 是第一个把「自家模型 + 自家 agent」绑成一个闭环来推的——而且手法很直接：fork 了 200K Star 的 OpenCode，README 最后一段白纸黑字写着「MiMoCode is built as a fork of OpenCode. It keeps all core OpenCode capabilities (multiple providers, TUI, LSP, MCP, plugins) and adds persistent memory, intelligent context management, subagent orchestration, goal-driven autonomous loops, compose workflows, and self-improvement via dream/distill」。

为什么要 fork 而不是自己写？因为 terminal agent 的活（TUI、权限、LSP、MCP 客户端、多 provider）OpenCode 已经干完了，小米要的是在这层底座上证明一件事：「模型和 agent 应该一起进化」——agent 跑出来的会话痕迹（traces）沉淀成记忆和技能，反哺模型使用效率；而自家 310B/1T 的模型针对自家 agent 的工作负载调优。这个循环 OpenAI/Anthropic 是关起门来做的，小米把它开源了：MIT，模型权重上 HuggingFace（MiMo-V2.5 已 41.7 万下载），agent 代码上 GitHub。生态位很清晰——想研究「大厂怎么把 agent 产品化」的人，这是目前唯一能扒开看的样本。

核心机制一：持久记忆不是 hook 外挂，是 SQLite FTS5 原生内置

工坊之前写过的 claude-mem、engram 都是「外部挂件」路线：hook 进 Claude Code 的会话，把上下文摘要存进自己的库。MiMoCode 把记忆做成了 agent 的内置器官——数据落在 ~/.local/share/mimocode/mimocode.db，我实测扒了表结构：40+ 张表里躺着 memory_fts、history_fts 两张 FTS5 全文搜索表，以及 actor_registry（子代理注册表）、task、workflow_run、session_share。记忆分四层，全部自动维护：

项目记忆 MEMORY.md——项目知识、规则、架构决策的长期沉淀；
会话检查点 checkpoint.md——由专门的 checkpoint-writer 子代理维护的结构化状态快照；
草稿 notes.md——agent 的临时记事本；
任务进度 tasks/<id>/progress.md——每个任务的独立日志。

会话恢复时记忆自动注入，agent 不用重新学项目上下文。跟 claude-mem 那种「会话结束才压缩」的批处理不同，它是边干边写检查点——会话中途崩溃，从最近的 checkpoint 就能续上，配合树形任务系统（T1、T1.1 层级，跟检查点联动），长任务中断重开的成本被压到很低。这正好打在长 horizon agent 最疼的点上。

核心机制二：上下文管理是「预算制」——自动检查点 + 预算注入 + 可调压缩点

上下文窗口再大也会满，MiMoCode 的做法是把「什么时候压缩、压缩进什么、压缩多少」全部显式化：

自动检查点：根据模型上下文窗口决定何时保存会话状态，不是固定步数；
上下文重建：接近上限时，从最新检查点 + 项目记忆 + 任务进度 + 保留的近期消息重建上下文，任务不中断；
预算注入：检查点/记忆/笔记进上下文要过 token 预算，按重要性排序，不是全量塞；
/context-limit 可调压缩点：按模型单独设 compaction.max_context，比如 "openai/gpt-5.6": "272K" 或 "anthropic/*": "300K"（支持通配符）。README 给了很实在的理由：OpenAI 对 272K 以上输入按 2 倍价计费；同一个模型走订阅、直连 API、OpenRouter 拿到的实际窗口不一样；超长上下文又慢又不一定更好。

实测 mimo models 输出里每行都带压缩点：mimo/mimo-auto — window 1M, compacts at 960K——窗口和压缩点是分开算的两件事，提示符底栏显示 33.0K/260K↓ (13%)，那个 ↓ 表示有预算在生效，/status 可查明细。这种「压缩点显式可配」的设计，比闷头等窗口满了再压缩的 agent 精细一个档次。

核心机制三：多代理编排——三个主代理 + 按需子代理 + /goal 独立裁判

MiMoCode 的主代理有三个，Tab 切换：build（默认，全工具权限）、plan（只读分析）、compose（spec 驱动开发编排）。有个细节很反直觉但很实用：compose 一旦进入就锁定——build 和 plan 可以互相切，但 compose 隔离，因为「会话开始就把 skill/工具集固定」能显著提升工具调用可靠性。对前沿模型，README 建议直接用 build + /compose-next skill，而不是进 compose 模式。

子代理系统是运行时按需创建的（数据库里的 actor_registry 表就是干这个的）：共享当前会话上下文、可并行、有生命周期跟踪、可取消、可后台执行。最有意思的是 /goal 命令：给会话设一个停止条件，agent 想停的时候，由一个独立的 judge 模型重新评估对话，判断条件是否真满足——专治 autonomous 模式下的「乐观提前停止」（活没干完就宣布胜利）。这是对「agent 自我评估不可信」这个老问题的直接回应：自己判自己不算数，换个模型来判。

核心机制四：确定性工作流 + 26 个内置 skill + /dream /distill 自我进化

对话式 agent 的一个痛点是「同样的流程每次跑得不一样」。MiMoCode 的 Workflows 是确定性 JavaScript 脚本，在沙箱运行时里编排多个 agent，固定阶段顺序、有限重试、自动并行，fire-and-forget 不用人盯着。内置四个：

工作流	阶段	适用场景
compose	Brainstorm → Design → Implement → Verify → Review → Report → Merge	能拆成独立子任务的完整开发管线；自动把独立任务并行化到隔离 git worktree，每个任务单独跑 TDD
deep-research	Brief → Plan → Research → Reflect → Write → Review	多来源深度研究报告；并行子代理收集带引用的发现，最后冷审引用
fact-check	Plan → Search → Extract → Group → Crosscheck → Report	对抗式事实核验；3-juror 投票交叉检查每条可核验声明
research-experiment	Baseline → Loop → Audit → Report	机械可验证指标的自主优化循环；自带防「刷指标」审计

内置 skill 我实测落盘数了：builtin_skills/0.1.13/skills/ 下有 26 个，比 README 表格里的 23 个多——README 没提的 memory-search、playwright、drive-mimo 都躺在里面。亮点几个：evolve（允许 agent 重写自己的任何一层：工具、行为钩子、知识、工作流，甚至 UI）、claude-code 和 codex（把活委托给 Claude Code / Codex CLI，装了对应可执行文件才暴露）、learn-everything（把文档变成带练习的自适应课程）。而 /dream 和 /distill 是「自我进化」的落点：前者扫描近期会话痕迹、把持久知识提取进项目记忆并清掉过时条目；后者发现近期重复出现的手动工作流、把高置信候选打包成可复用的 skill/subagent/command——用多了，agent 会自己长出「肌肉记忆」。

上手：我在沙箱实测跑通的命令

Ubuntu 无头沙箱。全链路：安装 → 版本 → 命令面 → 无 key 裸跑 → 自定义 provider → mock 服务验证请求，都走了一遍。

# 1) 安装（npm 启动器只有 13.4 kB，实测 5 个包 16 秒；另有 curl 一键脚本）
npm install -g @mimo-ai/cli

# 2) 验证
mimo --version            # 实测输出: 0.1.13
mimo --help               # 24+ 个子命令：run/providers/models/stats/serve/attach/
                          # acp/mcp/export/import/pr/llm-server/github/session/db

# 3) 默认模型（未登录也能看到，全是小米自家）
mimo models
# mimo/mimo-auto — window 1M, compacts at 960K
# xiaomi/mimo-v2.5 — window 1.05M, compacts at 1.01M
# xiaomi/mimo-v2.5-pro — window 1.05M, compacts at 1.01M
# xiaomi/mimo-v2.5-pro-ultraspeed — window 1.05M, compacts at 1.01M

# 4) headless 跑一句（无任何 key）
mimo run "say hi"         # 实测: "Error: MiMo free API service has ended.
                          #         Sign in or configure a third-party API."

# 5) 配自定义 OpenAI 兼容 provider（~/.config/mimocode/mimocode.jsonc）
#    模型名用 custom/ 前缀，key 存明文，别提交进 git
{
  "$schema": "https://mimo.xiaomi.com/mimocode/config.json",
  "model": "custom/fake-model",
  "provider": {
    "custom": {
      "name": "Custom",
      "npm": "@ai-sdk/openai-compatible",
      "only_configured_models": true,
      "models": { "fake-model": { "name": "fake-model" } },
      "options": { "baseURL": "http://127.0.0.1:9999/v1", "apiKey": "sk-xxx" }
    }
  }
}

# 6) 首次运行会做 SQLite 迁移，数据落在 XDG 目录
#    ~/.local/share/mimocode/   # mimocode.db + auth.json + skills
#    ~/.config/mimocode/        # mimocode.jsonc（$schema 自动注入，267KB schema 实测可下载）
#    ~/.cache/mimocode/         # 语言服务器、模型目录缓存

最有信息量的实测是第 5 步的延伸：我把自定义 provider 指向本地一个 mock OpenAI 兼容服务，跑 mimo run "say hi"——它真的发起了 /v1/chat/completions 请求，我能看到完整系统提示词：第一次调用是「title generator」（一个专门生成会话标题的小模型调用，提示词里明确要求「只输出标题，别回复问题」），之后是主 agent 的 You are MiMoCode, an interactive CLI tool... 完整提示词，默认 max_tokens: 32000，失败会自动重试（一次 run 里 mock 收到 4 次请求：1 次标题 + 3 次主对话）。这说明「接任何 OpenAI 兼容服务」不是宣传——配置即用，协议是真的。

实测与踩坑：4 个坑，第 2 个最阴

坑 1（首跑必踩）：开箱默认走小米免费 API，但服务已经终止。装完什么都不配直接 mimo run，实测报 Error: MiMo free API service has ended. Sign in or configure a third-party API.——免费通道已经关了，必须登录 MiMo 平台（OAuth）、登录 Codex、或自己配 provider。README 的 Quick Start 写着「first launch guides you through configuration automatically」，但无头环境里就是一句报错，没有引导 UI。
坑 2（最阴）：坏 key / 坏端点静默退出，exit 0。配了假 key + 指向死端口的 provider 跑 mimo run "say hi"：输出一行 > build · fake-model 然后直接退出，exit code 是 0，全程没有任何错误提示——shell 脚本里它会被当成「成功跑完」。排障时最容易误判。对比无 key 时反而会明确报错，坏 key 却装死。
坑 3：响应校验极其严格。mock 服务返回了完全合法的 chat.completion JSON（content 为 string 和数组两种格式都试了），它都判 Error: empty output——说明底层 AI SDK 适配器对响应 schema 的要求比「合法」更苛刻。真实 API 不会有这个问题，但你自己写中转/网关时要注意：不是返回合法 OpenAI 格式就行。
坑 4：README 跟实际有出入。README 表格列了 23 个内置 skill，实测落盘 26 个（memory-search、playwright、drive-mimo 没写进表格）；WSL 要装 xsel、macOS 不支持 Terminal.app 只支持 iTerm2/VS Code 终端——这些 README 都写在折叠的 details 里，不看就踩。另外 apiKey 明文存配置文件，README 自己都提醒「keep the file readable only by your user and never commit it」。

对比：记忆型 Agent 赛道上的站位

维度	MiMoCode	OpenCode（fork 前身）	Claude Code	claude-mem / engram
出身	小米官方，fork OpenCode 加四层	社区（原 sst/opencode）	Anthropic 官方	第三方记忆挂件
持久记忆	✅ 内置 SQLite FTS5，四层自动维护	❌ 无	⚠️ CLAUDE.md 手动为主	✅ hook 式外挂
上下文管理	✅ 检查点/重建/预算注入/可调压缩点	⚠️ 基础压缩	⚠️ 自动压缩	✅ 摘要注入
子代理编排	✅ 按需创建 + /goal 独立裁判	⚠️ 有限	✅ subagents	❌
确定性工作流	✅ JS 沙箱 + 4 内置（含自动 worktree 并行）	⚠️ 部分	⚠️ 部分	❌
自我进化	✅ /dream /distill / evolve skill	❌	❌	⚠️ 只记忆不进化
多后端	✅ 任意 OpenAI 兼容 + 小米/Codex	✅ 多 provider	❌ 仅 Anthropic	✅ 随宿主
许可 / Star	MIT / 12,851	MIT / 200,261	专有 / 142,426	MIT / 90,000+

一句话定位：claude-mem 那类是「给现有 agent 装记忆」，MiMoCode 是「记忆原生长在 agent 里，还顺带把上下文预算、子代理裁判、确定性流水线、自我进化全做了」——它是目前开源阵营里「记忆/上下文管理」做得最系统的一个，而且背后有 310B/1T 自家模型在按它的工作负载调优。OpenCode 是它的底座，但加了这四层之后已经不是同一个物种了。

值不值得装：三个场景对号入座

被上下文爆掉、长任务总断片的：值得装。检查点 + 预算注入 + 树形任务这套是目前开源 agent 里最完整的上下文管理方案，2 个半月 12.8K Star 说明踩坑的人不少、修得也快（周更）。先配好 provider 再干活，别裸跑撞坑 1。
想研究大厂 agent 产品化的：必看。这是第一个「自家模型 + 自家 agent」开源闭环样本：fork 策略、提示词结构（title generator 分离）、记忆分层、judge 机制、workflow 设计全都能扒源码看。
只想找个顺手的多后端终端 agent 的：OpenCode 本体可能更合适——MiMoCode 默认把小米模型放在最前面，你如果不用小米生态，等于多了一层「开箱先撞免费 API 终止」的障碍；但它的记忆/上下文层是 OpenCode 没有的，取舍看你要什么。

最后说句公道话：12.8K Star、周更、Trendshift 在榜、模型权重公开在 HuggingFace——小米这次不是玩票，是把「模型 + Agent 协同进化」当成一个真产品在推。技术上它确实把记忆和上下文管理做到了开源第一梯队，/goal 独立裁判和确定性 workflow 是别人没有的巧思。但两个体验问题很实在：免费 API 终止后开箱即用门槛变高，坏 key 静默 exit 0 这个行为在 CI 里会咬人。MIT，仓库 github.com/XiaomiMiMo/MiMo-Code，npm @mimo-ai/cli，安装 npm i -g @mimo-ai/cli。