MiMo Code 是小米 MiMo 团队做的终端 AI 编码代理。号称无限上下文。
怎么安装
Mac 和 Linux 可以直接走安装脚本：
curl -fsSL https://mimo.xiaomi.com/install | bash
Windows 文档里给的是 npm 安装：
npm install -g @mimo-ai/cli
装完以后，在项目目录执行：
mimo
第一次用时先连模型。在 TUI 里输入：
/connect
文档里默认推荐的是 Xiaomi MiMo Token Plan，也可以接其他 LLM provider。MiMo Code 底层用了 AI SDK 和 Models.dev，文档里写到支持 75+ LLM 提供商，也支持本地模型。模型接好以后，再用：
/models
切到当前任务需要的模型。这个入口比较实用，同一个 Android 项目里，读代码、改代码、写文档、做 review，不一定要用同一个模型。
配置文件
MiMo Code 的配置文件是 mimocode.json。常见字段包括 model、small_model、provider、permission、agent、command、skills、mcp、lsp、formatter、instructions 等。
最小配置可以先只写 schema、模型和 provider 信息。API Key 不要直接写死在仓库里，文档支持从环境变量和文件读取：
{
"$schema": "https://mimo.xiaomi.com//config.json",
"model": "{env:MIMOCODE_MODEL}",
"provider": {
"anthropic": {
"options": {
"apiKey": "{env:ANTHROPIC_API_KEY}",
"baseURL": "{file:~/.secrets/anthropic-endpoint}"
}
}
}
}
这里的 {env:VAR} 会从环境变量读值，{file:path} 会从文件读值。对公司项目来说，这个写法比把 key 放进配置文件稳一些，也方便在不同机器上切换 provider。
如果只想让团队使用一组固定 provider，可以加 enabled_providers 或 disabled_providers。文档里说明 disabled_providers 优先级更高，也就是说即使某个 provider 配了环境变量，被禁用后也不会出现在选择列表里。
{
"enabled_providers": ["anthropic", "openai"],
"disabled_providers": ["gemini"]
}
这个配置适合团队统一入口。比如公司内网代理只支持一部分 provider，就不要让每个人在本地随便试。
权限别放太开
AI 编码工具最容易出问题的地方不是“它能不能写代码”，而是“它能不能随便执行命令”。
MiMo Code 的权限支持 ask、allow、deny，也支持对不同工具和命令前缀做规则。一个偏保守的 Android 项目配置可以这样写：
{
"permission": {
"bash": {
"*": "ask",
"git status*": "allow",
"git diff*": "allow",
"git log*": "allow",
"./gradlew tasks*": "allow",
"./gradlew test*": "ask",
"./gradlew assemble*": "ask",
"git commit*": "deny",
"git push*": "deny"
},
"edit": "ask",
"write": "ask"
}
}
这里没有放开 git commit 和 git push。AI 可以帮你改代码，但提交和推送最好还是人来确认。Gradle 命令也不建议全部放行，因为 Android 项目里的构建命令可能触发较长时间的编译、下载依赖或设备测试。
文档里的 ask 审批有三个选择：once、always、reject。always 只在当前 MiMo Code 会话剩余时间内有效，不是永久写入配置。这个设计比较适合临时放行一组安全命令，比如这次任务里反复执行 git diff 或某个测试命令。
三种主代理
MiMo Code 内置了 build、plan、compose 三种主代理。
build 是默认模式，文件操作和系统命令都能用，适合实际改代码。平时让它修一个 Compose 页面、补一个 ViewModel 测试、改一个 Gradle 配置，大部分都是这个模式。
plan 是受限模式，默认不能写文件、不能改文件、不能打 patch、不能跑 shell 命令。它适合先读代码和拆任务。比如要迁移一个老模块到 Koin 4，先让 plan 看依赖、列风险、拆步骤，比直接让模型动手更稳。
compose 更像工作流模式。文档里写到它带了一组内置技能，例如 compose:tdd、compose:debug、compose:verify、compose:plan、compose:execute、compose:review、compose:worktree 等。它不是替代 build，而是让模型按技能组织任务。
切换方式也比较直接：按 Tab 在主代理之间切换，或者在消息里用 @compose 调用。
Android 项目里，我会把它们分成三类用法：
-
• 不确定改动范围时，用
plan先读代码。 -
• 明确要改文件时，用
build执行。 -
• 任务需要计划、执行、验证、review 这几步时，用
compose。
这几个模式的差异最好不要只停在名字上。真正影响结果的是权限、工具、提示词和模型配置。比如 plan 如果被你额外放开了写权限，它就不再是只读规划；build 如果把 bash 全部设成 deny，很多验证动作也跑不起来。
最后
MiMo Code 的基本形态已经比较完整：终端入口、模型连接、配置文件、权限、主代理、子代理、Skills、MCP、LSP、formatter 都有对应文档。
反正我不用，看看就好。
