终端里的 AI 编码助手这两周又添了一个有分量的玩家。小米开源的 MiMoCode 仓库在 GitHub 上已积累 13250 个 star、1374 个 fork，采用 MIT 许可，最近一次提交时间是 2026 年 9 月 21 日，热度还在往上走。
但真正值得写一篇实战的，不是它的 star 数，而是它的设计取向。市面上大量编码代理是把「对话 + 工具调用」封装成 CLI 就交付了，长周期任务一旦超过上下文窗口就开始失忆，用户只能反复重新交代背景。MiMoCode 把这个问题拆成了三块分别处理：跨会话记忆、上下文预算、重复流程固化。这篇工坊就按这三条主线走一遍，把能直接抄的配置和命令都给出来。
一、安装与接入：先跑起来
官方提供三种安装路径，选一种即可。macOS 与 Linux 走脚本安装，Windows 用 PowerShell，跨平台也可以走 npm：
# macOS / Linux
curl -fsSL https://mimo.xiaomi.com/install | bash
# Windows PowerShell
powershell -ep Bypass -c "irm https://mimo.xiaomi.com/install.ps1 | iex"
# 任意平台走 npm
npm install -g @mimo-ai/cli
# 启动
mimo首次启动会进入配置向导，给出五类接入方式：小米 MiMo 平台 OAuth 登录、Codex（ChatGPT Plus 或 Pro）的 OpenAI OAuth 登录、从 Claude Code 一步迁移既有认证、按 API key 连接目录内厂商（支持 OAuth 的比如 xAI 也能直接授权），以及在 TUI 里添加任意 OpenAI 兼容的自定义端点。
这里有个容易忽略但很实用的点：接入层是解耦的，MiMoCode 本身不绑定自家模型。你完全可以用它驱动别家的前沿模型，或者把它接到公司内部的中转网关上。对于已经在用其他编码代理、不想推翻既有供应商关系的团队，这条降低了试用成本。
💡 提示：MiMoCode 明确不支持 macOS 自带的 Terminal.app。如果界面错位、闪烁或渲染异常，换 iTerm2 或 VS Code 内置终端。
二、三种主代理：权限边界比功能更值得研究
按 Tab 键可以在三种主代理之间切换，这个划分方式比常见的「一个全能代理」要克制：
| 代理 | 定位 | 关键约束 |
|---|---|---|
build | 默认代理，拥有完整工具权限 | 直接的读写与执行能力 |
plan | 只读分析模式，用于代码勘探与方案设计 | 不落盘改动 |
compose | 编排模式，面向规格驱动的开发与技能工作流 | 进入后隔离 |
真正有设计含量的是最后一条约束：首条消息发出后模式即锁定。Build 与 Plan 之间仍可互相切换，但 Compose 一旦进入就隔离，因为它需要从会话开始就固定技能与工具集合。官方的解释是——固定工具集能显著提升工具调用可靠性。
这个取舍值得抄。工具列表在会话中途变化，是代理「忘记自己有什么能力」或「调用了刚被移除的工具」的常见根因。把工具集当成不可变输入，等于把不确定性从运行时提前到了启动时。
另外官方给了个明确的推荐：对前沿模型（它们能内化大部分流程），跑 Compose 风格的开发流程不要用 compose 代理，而是用 build 代理配合 /compose-next 技能——一份自包含的契约，比十四步的课程式流程更省 token，也更少被打断。更强的模型吃更少的脚手架，这条经验在多个代理框架里反复出现。
三、持久记忆：四类文件 + 全文索引
这是 MiMoCode 与多数同类工具拉开差距的地方。它的跨会话记忆不是把历史对话一股脑塞回去，而是分成四类职责清晰的载体，检索层用 SQLite FTS5 做全文索引：
MEMORY.md—— 项目长期知识、规则与架构决策checkpoint.md—— 由 checkpoint-writer 子代理自动维护的结构化状态快照notes.md—— 代理的临时草稿区tasks/目录下的 progress.md —— 按任务 id 记录的任务进度日志
会话恢复时记忆会被自动注入，代理不需要重新学习项目背景。注意这里的工程细节：结构化的三段式（长期知识 / 状态快照 / 任务进度）各自独立，而不是混成一个不断膨胀的日志。这样做的直接好处是注入时可以按重要性排序、按 token 预算裁剪，而不是被迫全量灌入。
再往上一层是任务系统：树形结构（T1、T1.1、T1.2……）与 checkpoint 打通，会话恢复时任务进度一并保住。长任务被中断后重启，不需要重述「我们做到哪了」。
四、上下文预算：把压缩点调到窗口之前
上下文管理这一节，是我认为 MiMoCode 文档里最有价值的部分，因为它把一个常被忽略的成本问题摊开了。
默认行为是接近模型上下文窗口时才触发压缩。MiMoCode 允许你用 /context-limit 把工作预算压得更低，取值可以是 200K、300K、500K、1M，也可以是窗口的百分比，按模型存进配置：
{
"compaction": {
"max_context": {
"openai/gpt-5.6": "272K",
"anthropic/*": "300K"
}
}
}支持通配符，最长匹配生效；数值会被强制收敛到厂商实际接受的范围内，所以这个配置只能下调压缩点，不能上调；设成 0 则恢复模型自身窗口。
为什么要主动提前压缩？官方给了三条我认为完全站得住的理由：
- 成本分层。以 GPT-5.6 为例，提示词超过 272K 输入时，整个请求按双倍输入、1.5 倍输出计价。注意是整段请求，不是超出部分——这意味着在临界点附近多塞几个 token，代价可能翻倍。
- 标称窗口不等于可用窗口。同一个模型，经 ChatGPT 或 Codex 订阅、直连 API、中转商三条路访问，可用窗口可能各不相同。目录里写着 1M，不代表你这条路由真的给 1M。
- 长上下文的收益递减。上下文越长越慢，而且超过某一点之后质量并不更好。
诊断工具也给齐了：mimo models 命令带上厂商参数，会逐个打印 MiMoCode 解析出的窗口与压缩触发点；提示栏页脚用同一个数字作分母显示占用率，尾部的向下箭头表示当前有预算在生效；/status 给出完整拆分。
五、工作流：把重复流程固化成确定性脚本
如果说记忆解决的是「别忘」，工作流解决的是「别乱」。MiMoCode 的工作流是确定性的 JavaScript 脚本，在沙箱运行时里编排多个代理。与代理对话不同，工作流把阶段序列写死，带边界重试与自动并行，属于发起后就不用管的执行方式。
内置四个，覆盖的开发场景挺全：
| 工作流 | 阶段 | 适用场景 |
|---|---|---|
compose | 头脑风暴 → 设计 → 实现 → 验证 → 评审 → 报告 → 合并 | 需求清晰、可拆成独立子任务 |
deep-research | 简报 → 计划 → 研究 → 反思 → 写作 → 评审 | 多来源研究报告，可断点续跑 |
fact-check | 计划 → 搜索 → 抽取 → 分组 → 交叉核验 → 报告 | 精确论断的事实验证 |
research-experiment | 基线 → 循环 → 审计 → 报告 | 有机械可验证指标的自主优化 |
compose 工作流有个细节值得单独点出：它会把互相独立的子任务自动并行到隔离的 git worktree，逐个应用 TDD，再在阶段之间串接结构化输出。隔离 worktree 是关键——并行修改同一份工作区是代理协作最容易翻车的地方，物理隔离比约定规范可靠得多。
fact-check 用的是三陪审员对抗投票，research-experiment 则内置了针对「指标被刷」的审计环节，要求在固定预算的评估命令和明确的可编辑文件范围内作业。这两个设计都在回答同一个问题：怎么让自主循环不至于自欺欺人。
想自定义，把 .js 文件放进 .mimocode/workflows/ 或 .claude/workflows/ 即可；用同名文件可以覆盖内置实现。
六、技能生态与自我进化
技能是可复用的指令集。MiMoCode 的查找策略是三层：精确名称、本地化别名、BM25 相关性。高置信度匹配自动加载，不确定的排序后交给代理判断。TUI 里输入斜杠可以浏览补全列表，或用斜杠加技能名直接调用；一条消息里提到两个及以上技能会自动加载并注入多技能编排计划。
技能目录这一块，MiMoCode 走了开放标准路线：.mimocode/skills/ 是自有目录，同时兼容项目级与用户级的 .agents/skills/。.claude/skills、.codex/skills、.opencode/skills 则需通过环境变量显式开启。后扫描到的用户技能会覆盖同名内置技能。
内置技能里有几个值得注意的：arxiv 用于检索与引用论文，claude-code 可以把编码、测试、评审、Git 任务委托给 Claude Code CLI，codex 面向无头自动化与 CI 环境。也就是说它默认把「别的代理」当成可调用的工具，而不是竞争关系。
最后是自我进化这一块，两个命令：
/dream—— 扫描近期会话轨迹，把持久知识抽取进项目记忆，并清理过时条目/distill—— 发现反复出现的手工流程，把高置信度的候选打包成可复用技能、子代理或命令
/distill 这个方向我很欣赏：把「用户重复做的动作」当成技能生成的信号源，而不是靠人预先写规范。当然它的风险也明显——自动归纳出的技能可能抽象过度，把一次性的绕路当成通用模式。合理用法是把它当候选生成器，人来把关。
七、远程与协作：服务与客户端分离
TUI 直接跑在 SSH 会话上容易卡，官方的解法是把渲染和推理拆开：远端只跑服务，本地做端口转发后连接。
# 远端：只跑服务
mimo serve --port 4096
# 本地：建立 SSH 端口转发
ssh -N -L 4096:127.0.0.1:4096 user@remote-host
# 本地：另一个终端里连上去
mimo attach http://127.0.0.1:4096这个架构另外的好处是：重负载留在远端机器上，本地只要有终端即可；多人也可以各自 attach 到同一个远端服务。如果只是装饰动画拖慢界面，在命令面板里把 Vivid 切成 Minimal 就行，不必上服务化方案。
还有一个值得一提的命令是 /goal：它给会话设置停止条件。当代理试图结束时，会由独立的裁判模型评估对话，判断条件是否真的达成——专门用来防「乐观停机」。自主任务必配停止条件的独立校验，这个模式在今天的代理工程里已经越来越像标配。
八、落地建议与局限
结合官方文档，我给几条实操建议：
- 先立规矩再放权。
.mimocode/mimocode.jsonc支持 JSON Schema 校验，编辑器里能补全。项目级配置跟着仓库走，团队行为才一致。 - 压缩点按账单定，不按窗口定。先把
mimo models跑一遍，看真实可用窗口，再对照厂商的阶梯价把max_context设到临界点之下。 - 用 workflow 处理可并行的批量任务，用对话处理需要中途改向的任务。这条边界官方说得很清楚，照做能省不少来回。
- 技能目录统一到
.agents/skills。这是开放标准，多个代理框架都能识别，比锁死在单一工具的私有目录里更划算。 - 长任务一定设
/goal。没有独立裁判的停止条件，自主循环很容易在错误的点上宣布完成。
局限也要说清楚。第一，MiMoCode 是终端 TUI，对完全不习惯键盘工作流的成员有适应成本，虽然它有桌面版但仍在 beta 邀请阶段。第二，记忆注入虽然做了预算与排序，但「哪些该进预算」仍是启发式，项目记忆写得太杂时注入质量会下降——记忆文件的卫生需要人来维护。第三，工作流是确定性脚本，灵活性换稳定性，遇到需要频繁变更阶段的探索型任务，反而不如对话式代理好用。第四，仓库里带有使用限制说明文件，商用前建议按自己的场景读一遍。
总体来看，MiMoCode 值得放进候选清单的理由，不在于它又多支持了几个模型，而在于它把长周期代理的三个真问题——记忆、预算、流程固化——都做成了可以配置、可以审计的具体机制。对正在把编码代理推向生产环境的团队，这套设计比一份功能清单更有参考价值。