MiMo Code 深度实战：当小米杀入 AI 编程赛道——从 SQLite FTS5 持久记忆到子智能体编排、Max Mode 并行推理与 Compose 自进化工作流的生产级完全指南（2026）

14 天、5 个人、vibe-coding 方式拼出来的开源 AI 编程 Agent，三天内狂揽 8000+ Stars。小米 MiMo 团队用 MiMo Code 向整个 Coding Agent 行业投下了一枚重磅炸弹。

引言：为什么一个「套壳 OpenCode」的项目值得你花 30 分钟读完这篇文章？

2026 年 6 月 11 日，小米 MiMo 技术团队在 GitHub 上正式开源了 MiMo Code V0.1.0——一款终端原生的 AI 编程助手。消息一出，中文技术社区炸了锅。有人说这是「套壳 OpenCode」，有人说「又一个营销项目」，还有人说「终于有人认真解决 AI 编程的长程记忆问题了」。

三天时间，8000+ Stars，499+ Forks。GitHub Issues 和 PR 像潮水一样涌入。

但如果我们把视线从「是谁做的」转移到「解决了什么问题」上，你会发现 MiMo Code 背后的工程思考，恰恰击中了当前所有 Coding Agent（Claude Code、Cursor、Codex 等）的共同痛点：

1. 上下文窗口是有限的，但真实的编程任务是无限的。当你让 Agent 连续干上百轮操作，它必然「断片」。
2. 模型「健忘」不是 Bug，是物理定律。Transformer 的注意力机制天然不利于超长序列的信息保持。
3. Agent 的「乐观停止」——它觉得自己干完了，但实际只完成了 90%。谁来当裁判？

MiMo Code 的回答是：用工程手段兜住模型的不确定性。

本文不会重复那些你已经看过的 PR 稿文案。我们将从架构设计、核心机制、代码实现、性能优化、生产部署五个维度，深度拆解 MiMo Code 的技术实现。不管你最终用不用它，这篇文章都会让你对「如何构建一个真正能用的 Coding Agent」有全新的理解。

一、背景：Coding Agent 的「最后一公里」问题

1.1 当前主流 Coding Agent 的能力边界

截至 2026 年中，市面上的主流 Coding Agent 大致可以分为几类：

它们的共同点：在单次会话内表现优秀，一旦跨越会话边界，就变成了「失忆症患者」。

1.2 为什么「跨会话记忆」这么难？

从工程角度看，这个问题的本质是：

编程任务的上下文 ≠ 单次会话的上下文

一个真实项目的上下文包括：
- 项目架构决策（为什么用 Monorepo？为什么选 PostgreSQL？）
- 代码约定（命名规则、目录结构、Git 分支策略）
- 历史踩坑（上次那个 race condition 怎么修的？）
- 进行中的任务（T1 实现了 80%，T2 还没开始）
- 隐性知识（这个服务端口号改过一次，别用默认值）

这些信息不可能每次都让 Agent 重新理解——这意味着浪费 token、浪费时间、而且Agent 可能每次理解出不同的结果。

MiMo Code 的核心论点是：把「记忆」从模型的负担变成系统的能力。

二、架构总览：MiMo Code 的三层设计哲学

2.1 架构分层

MiMo Code 的架构可以分为三层：

┌─────────────────────────────────────────────┐
│           交互层 (Interaction Layer)          │
│  ┌─────────┐ ┌─────────┐ ┌────────────────┐  │
│  │ Build   │ │ Plan    │ │ Compose        │  │
│  │ Agent   │ │ Agent   │ │ Agent          │  │
│  └────┬────┘ └────┬────┘ └───────┬────────┘  │
│       └──────────┬┘──────────────┘            │
├──────────────────┼───────────────────────────┤
│           编排层 (Orchestration Layer)        │
│  ┌──────────┐ ┌───────────┐ ┌───────────┐   │
│  │ Sub-Agent│ │ Goal Judge│ │ Max Mode  │   │
│  │ Manager  │ │ (裁判模型) │ │ (并行选优)│   │
│  └────┬─────┘ └─────┬─────┘ └─────┬─────┘   │
├───────┼─────────────┼──────────────┼─────────┤
│           记忆层 (Memory Layer)               │
│  ┌──────┐ ┌──────────┐ ┌──────┐ ┌────────┐  │
│  │Memory│ │Checkpoint│ │Notes │ │ Tasks  │  │
│  │.md   │ │.md      │ │.md   │ │/progress│  │
│  └──────┘ └──────────┘ └──────┘ └────────┘  │
│         SQLite FTS5 全文搜索引擎              │
└─────────────────────────────────────────────┘

2.2 三层各司其职

• 交互层：面向用户的 Agent 模式。Build（默认开发）、Plan（只读分析）、Compose（specs-driven 编排）。
• 编排层：管理子智能体生命周期、评估任务完成度、执行 Max Mode 并行推理。
• 记忆层：基于 SQLite FTS5 的持久化存储，在会话之间保持项目知识。

这三层设计的关键洞察是：不应该依赖模型自身来管理记忆和任务状态，而应该用确定性的工程系统来兜底。

三、核心机制深度拆解

3.1 持久化记忆系统：SQLite FTS5 的巧妙运用

3.1.1 为什么选 SQLite FTS5？

MiMo Code 的记忆系统选择了 SQLite 的 FTS5（Full-Text Search 5）扩展作为底层引擎。这个选择非常有品味：

-- FTS5 全文搜索示例：创建记忆表
CREATE VIRTUAL TABLE IF NOT EXISTS project_memory 
USING fts5(
    content,
    content='project_memory_content',
    tokenize='porter unicode61'
);

-- 插入一条项目记忆
INSERT INTO project_memory(content) VALUES (
    '项目使用 PostgreSQL 作为主数据库，ORM 选型为 Prisma，' ||
    '因为需要支持 edge runtime 部署。认证系统采用 JWT + refresh token，' ||
    'token 有效期 15 分钟，refresh token 7 天。'
);

-- 按语义搜索相关记忆
SELECT content, rank 
FROM project_memory 
WHERE project_memory MATCH 'database ORM PostgreSQL'
ORDER BY rank;

为什么不用向量数据库？

这是一个关键设计决策。对于编程项目的记忆场景：

1. 精确匹配 > 语义匹配：当你搜索「PostgreSQL 连接配置」时，你需要的是精确的技术细节，而不是「嗯，可能是关于数据库的」这种模糊结果。
2. 零外部依赖：SQLite 是嵌入式数据库，不需要启动额外服务。对于终端工具来说，这至关重要。
3. ACID 保证：项目记忆的写入和读取必须强一致，SQLite 天然提供。
4. 文件级映射：记忆最终以 Markdown 文件形式（MEMORY.md、checkpoint.md）存在项目目录中，SQLite 索引只是加速检索。

3.1.2 四种记忆文件

MiMo Code 的记忆系统维护四种 Markdown 文件：

.mimocode/
├── memory.md          # 项目记忆：跨会话持久的项目知识
├── checkpoint.md     # 会话检查点：结构化状态快照
├── notes.md          # 笔记暂存：Agent 临时记录
└── tasks/
    ├── T1/
    │   └── progress.md    # 任务 T1 的进展日志
    ├── T1.1/
    │   └── progress.md    # 子任务进展
    └── T2/
        └── progress.md

MEMORY.md 示例：

# 项目记忆

## 架构决策
- [2026-06-10] 选用 Monorepo 架构，使用 Turborepo 管理
- [2026-06-10] API 框架选择 FastAPI（Python），因为团队 Python 熟练度高
- [2026-06-11] 缓存层使用 Redis 7，因需要 Stream 功能支持实时通知

## 代码约定
- 命名：snake_case（Python）、camelCase（TypeScript）
- 目录结构：apps/（业务应用）、packages/（共享包）、tools/（工具脚本）
- Git 分支：feature/*（功能）、fix/*（修复）、release/*（发布）

## 踩坑记录
- [2026-06-11] FastAPI 的 BackgroundTasks 不适合长时间任务，
  已改用 Celery + Redis
- [2026-06-11] Prisma 的 transaction 超时默认 5 秒，
  需在 schema.prisma 中配置 interactiveTransactions

## 关键配置
- 数据库端口：5432（生产环境注意内网访问）
- Redis 端口：6379
- API 前缀：/api/v1

checkpoint.md 示例：

# 会话检查点 #42

## 当前状态
- 任务：实现用户认证模块
- 进度：JWT 签发 ✅ | refresh token ✅ | 密码重置 🔄
- 上下文使用率：78%

## 待处理
- [ ] 密码重置邮件发送逻辑
- [ ] 速率限制（每 IP 每分钟 5 次）
- [ ] 单元测试覆盖

## 决策记录
- 使用 passlib 而非 bcrypt，因为需要支持 argon2 未来迁移

3.1.3 记忆的生命周期管理

MiMo Code 通过两个命令实现记忆的自我进化：

/dream 命令——记忆蒸馏：

# 触发记忆蒸馏：扫描近期会话，提取持久知识
mimo> /dream

🎯 正在扫描最近 7 天的会话轨迹...
  ├── 会话 #38: 实现了 WebSocket 实时通知
  ├── 会话 #39: 修复了 JWT 过期时间配置
  ├── 会话 #40: 添加了 rate limiting
  └── 会话 #41: 重构了错误处理中间件
  
📝 发现可持久化的知识：
  [+] "WebSocket 消息格式采用 {type, payload, timestamp} 三元组"
  [+] "JWT secret 必须通过环境变量注入，禁止硬编码"
  [+] "rate limiting 使用滑动窗口算法，Redis key: ratelimit:{ip}"

🧹 清理了 3 条过时记忆
✨ 项目记忆已更新 (MEMORY.md)

/distill 命令——技能提炼：

mimo> /distill

🔍 分析近期工作流模式...
  发现重复操作：代码审查 → 运行测试 → 提交 PR
  置信度：92%
  
📦 已创建 Skill：code-review-and-push
  - 自动运行 lint + type check
  - 执行测试套件
  - 生成 PR 描述
  - 创建分支并推送

使用方式：/code-review-and-push

3.2 智能上下文管理：当上下文窗口接近上限时怎么办？

这是 MiMo Code 最核心的工程创新之一。当模型的上下文窗口即将用满时，系统会触发上下文重建流程：

上下文重建流程：

1. 检测触发条件：context_usage > 85%
2. 保存当前状态到 checkpoint
3. 计算重建预算：
   - checkpoint 注入：40% budget
   - 项目记忆注入：30% budget
   - 近期消息保留：20% budget
   - 笔记注入：10% budget
4. 按优先级注入：
   - 当前任务的 checkpoint（最高优先）
   - 相关的项目记忆（FTS5 匹配）
   - 最近 5-10 轮对话（保底）
   - 相关笔记（补充）
5. Agent 从重建后的上下文继续工作

关键实现伪代码：

interface ContextRebuildConfig {
  triggerThreshold: number; // 触发重建的上下文使用率阈值，默认 0.85
  budgetAllocation: {
    checkpoint: number;    // 默认 0.4
    memory: number;         // 默认 0.3
    recentMessages: number; // 默认 0.2
    notes: number;          // 默认 0.1
  };
}

async function rebuildContext(
  currentSession: Session,
  config: ContextRebuildConfig
): Promise<RebuiltContext> {
  const totalBudget = modelContextWindow - SAFETY_MARGIN;
  
  // 1. 获取当前任务的最新 checkpoint
  const checkpoint = await getLatestCheckpoint(currentSession.taskId);
  const checkpointTokens = await tokenize(checkpoint.content);
  
  // 2. FTS5 搜索相关的项目记忆
  const relevantMemories = await searchMemories({
    query: extractKeywords(currentSession.recentMessages),
    maxTokens: totalBudget * config.budgetAllocation.memory,
    ranking: true
  });
  
  // 3. 保留最近的消息（按时间倒序）
  const recentMessages = currentSession.messages
    .slice(-10) // 保留最近 10 轮
    .filter(msg => tokenize(msg) < totalBudget * config.budgetAllocation.recentMessages);
  
  // 4. 获取相关笔记
  const relevantNotes = await searchNotes({
    query: currentSession.taskId,
    maxTokens: totalBudget * config.budgetAllocation.notes
  });
  
  // 5. 按预算裁剪并组装
  return assembleContext({
    checkpoint: truncateToFit(checkpoint, totalBudget * config.budgetAllocation.checkpoint),
    memories: relevantMemories,
    messages: recentMessages,
    notes: relevantNotes
  });
}

这个设计的精妙之处：它不是简单地「截断旧消息」，而是有选择地保留最重要的上下文。就像人类程序员不会把每一行代码都记在脑子里，但会记住关键的设计决策和当前任务的进度。

3.3 子智能体系统：并行执行与生命周期管理

MiMo Code 的子智能体（Sub-Agent）系统是其实现高效率的关键。主智能体可以按需生成子智能体，共享当前会话上下文，并行工作。

interface SubAgent {
  id: string;
  parentSessionId: string;
  type: 'checkpoint-writer' | 'task-executor' | 'code-reviewer' | 'test-runner';
  status: 'created' | 'running' | 'completed' | 'cancelled';
  model: string;      // 可以使用更轻量的模型（如 Haiku）降低成本
  toolPermissions: ToolPermission[];
  createdAt: number;
  completedAt?: number;
}

// 子智能体编排示例
async function executeTaskWithSubAgents(task: Task): Promise<TaskResult> {
  // 1. 生成代码执行子智能体
  const coder = await spawnSubAgent({
    type: 'task-executor',
    instructions: `实现 ${task.description}，遵循以下约束：${task.constraints}`,
    toolPermissions: ['read', 'write', 'execute', 'search'],
    model: 'mimo-v2.5' // 主力模型
  });
  
  // 2. 同时启动测试运行子智能体（轻量模型）
  const tester = await spawnSubAgent({
    type: 'test-runner',
    instructions: `准备测试环境，等待代码完成后立即运行测试`,
    toolPermissions: ['read', 'execute'],
    model: 'haiku' // 轻量模型降本
  });
  
  // 3. 代码完成后触发审查
  coder.on('complete', async (code) => {
    await tester.send(`运行 ${code.filePath} 的测试`);
    
    const reviewer = await spawnSubAgent({
      type: 'code-reviewer',
      instructions: `审查 ${code.filePath}，关注安全性和性能`,
      toolPermissions: ['read', 'search'],
      model: 'sonnet' // 中等模型
    });
    
    reviewer.send(code);
  });
  
  // 4. 收集结果
  return await Promise.all([coder.result, tester.result]);
}

checkpoint-writer 子智能体 是最特殊的一个——它是一个后台常驻进程，专门负责在关键时刻自动保存会话状态：

// checkpoint-writer 的触发时机
const CHECKPOINT_TRIGGERS = [
  'tool_use_complete',    // 每次工具调用完成后
  'file_write',           // 文件写入后
  'test_pass',           // 测试通过后
  'context_rebuild',     // 上下文重建时
  'error_occurred',      // 发生错误时
  'user_interrupt',      // 用户中断时
];

这种「记录工作完全外包给后台进程」的设计，比 Claude Code 依赖模型「自觉记笔记」的方式要可靠得多。

3.4 Goal 系统：防止「乐观停止」的裁判模型

这是 MiMo Code 最有洞察力的设计之一。

问题场景：你让 Agent「实现用户注册功能，包含邮箱验证」。Agent 写了注册接口、验证邮件发送逻辑，然后告诉你「完成了」。但实际上，它忘了处理邮箱格式校验、重复注册检测、验证码过期等边界情况。Agent 不是在撒谎——在它的理解中，它确实完成了「主要部分」。

MiMo Code 的解决方案：

// /goal 命令设置停止条件
interface GoalConfig {
  description: string;           // 目标描述
  criteria: string[];             // 具体验收标准
  judgeModel: string;             // 裁判模型（独立于执行模型）
  strictness: 'normal' | 'strict'; // 严格程度
}

// 使用示例
mimo> /goal 实现用户注册功能，包含邮箱验证
        criteria:
          - 邮箱格式校验（正则或库）
          - 重复邮箱检测（数据库唯一约束）
          - 验证码生成与存储
          - 验证码过期机制（默认 24 小时）
          - 验证码校验 API 端点
          - 错误处理（邮箱不存在、验证码错误、验证码过期）
          - 单元测试覆盖率 > 80%
        judge: mimo-v2.5
        strictness: strict

🎯 Goal 已设置。当 Agent 请求停止时，裁判模型将评估以下条件：
  ✓ 邮箱格式校验
  ✓ 重复邮箱检测
  ✓ 验证码生成与存储
  ✓ 验证码过期机制
  ✓ 验证码校验 API 端点
  ✓ 错误处理
  ✓ 单元测试覆盖率 > 80%

裁判模型的评估流程：

async function evaluateGoalCompletion(
  goal: GoalConfig,
  conversation: Conversation,
  codebase: Codebase
): Promise<GoalEvaluation> {
  const judge = await createJudgeModel(goal.judgeModel);
  
  // 裁判模型独立审查（不使用执行模型的上下文）
  const evaluation = await judge.evaluate({
    goal: goal.description,
    criteria: goal.criteria,
    evidence: {
      codeChanges: await codebase.getRecentChanges(),
      testResults: await codebase.getTestResults(),
      conversationSummary: conversation.summarize(),
      fileStates: await codebase.getRelevantFiles(goal.description)
    }
  });
  
  return {
    passed: evaluation.allCriteriaMet,
    score: evaluation.overallScore, // 0-100
    details: evaluation.criteriaDetails,
    recommendations: evaluation.improvementSuggestions
  };
}

关键设计：裁判模型和执行模型是隔离的。裁判不会看到执行模型在过程中犯了哪些错、绕了哪些弯路——它只看最终结果。这避免了执行模型「自卖自夸」的问题。

3.5 Max Mode：并行 best-of-N 推理

MiMo Code 的 Max Mode 是一个实验性功能，实现了「并行推理 + 裁判选优」的模式：

Max Mode 工作流程：

用户请求
    │
    ├───> 候选方案 A（mimo-v2.5）
    ├───> 候选方案 B（mimo-v2.5）
    ├───> 候选方案 C（mimo-v2.5）
    │
    └───> 裁判模型评估 ──> 最优方案

interface MaxModeConfig {
  enabled: boolean;
  candidates: number;      // 生成候选方案数，默认 3
  judgeModel: string;     // 裁判模型
  judgeCriteria: string;   // 评判标准
}

async function maxModeGenerate(
  prompt: string,
  config: MaxModeConfig
): Promise<string> {
  // 并行生成 N 个候选方案
  const candidates = await Promise.all(
    Array.from({ length: config.candidates }, () =>
      generate({ prompt, temperature: 0.9 }) // 高温度增加多样性
    )
  );
  
  // 裁判模型评估并选优
  const judge = await createJudgeModel(config.judgeModel);
  const ranked = await judge.rank({
    prompt,
    candidates,
    criteria: config.judgeCriteria
  });
  
  return ranked[0].content; // 返回最优方案
}

适用场景：

• 复杂的架构决策
• 关键代码路径的实现
• 安全相关的代码审查

不适用场景：

• 简单的代码修改（成本不值得）
• 调试已有 bug（需要线性推理）

3.6 Compose 模式：specs-driven 开发流程

Compose 模式是 MiMo Code 的另一个差异化功能。它提供了一套结构化的开发流程：

Compose 工作流：

需求描述 (Spec)
    │
    ├──> 规划 Agent：生成实现计划
    │
    ├──> 执行 Agent：按计划编码
    │
    ├──> 审查 Agent：代码审查
    │
    ├──> 测试 Agent：TDD 验证
    │
    ├──> 调试 Agent：问题修复
    │
    └──> 合并 Agent：最终交付

// Compose 模式配置示例
interface ComposeConfig {
  spec: string;           // 需求规格描述
  workflow: WorkflowStep[];
  qualityGates: QualityGate[];
}

const composeExample: ComposeConfig = {
  spec: `
    实现一个 RESTful API 端点：POST /api/v1/users
    - 接收 { email, password, name }
    - 返回 { id, email, name, created_at }
    - 邮箱唯一约束
    - 密码使用 argon2 哈希
    - 输入验证（email 格式、密码强度）
  `,
  workflow: [
    { agent: 'planner', output: 'implementation-plan.md' },
    { agent: 'coder', input: 'implementation-plan.md', output: 'user-routes.ts' },
    { agent: 'tester', input: 'user-routes.ts', output: 'test-results.json' },
    { agent: 'reviewer', input: 'user-routes.ts', output: 'review-report.md' },
  ],
  qualityGates: [
    { name: 'all-tests-pass', threshold: '100%' },
    { name: 'no-security-issues', threshold: '0 findings' },
    { name: 'type-check', threshold: 'no errors' },
  ]
};

切换到 Compose 模式只需按 Tab 键——这个交互设计很聪明，让三种 Agent 模式之间的切换零摩擦。

四、代码实战：从零搭建 MiMo Code 开发环境

4.1 安装与初始配置

# 方法 1：一键安装（推荐）
curl -fsSL https://mimo.xiaomi.com/install | bash

# 方法 2：通过 npm 安装
npm install -g @mimo-ai/cli

# 启动 MiMo Code
mimo

# 首次启动会进入配置引导

初始配置选项：

🔐 MiMo Code 配置向导

选择认证方式：
  [1] MiMo Auto（限时免费）— 零配置
  [2] 小米 MiMo 平台 — OAuth 登录
  [3] 从 Claude Code 导入 — 一键迁移
  [4] 自定义 Provider — OpenAI 兼容 API

> 4

配置自定义 Provider：
  API Base URL: https://api.deepseek.com/v1
  API Key: sk-***
  模型名称: deepseek-v4-chat
  上下文窗口: 131072 tokens

✅ 配置完成！

4.2 项目级配置

在项目根目录创建 .mimocode/mimocode.json：

{
  "provider": {
    "type": "custom",
    "baseUrl": "https://api.deepseek.com/v1",
    "apiKey": "${DEEPSEEK_API_KEY}",
    "model": "deepseek-v4-chat",
    "contextWindow": 131072
  },
  "agents": {
    "build": {
      "tools": ["read", "write", "execute", "search", "git"],
      "permissions": "full"
    },
    "plan": {
      "tools": ["read", "search"],
      "permissions": "readonly"
    }
  },
  "memory": {
    "checkpoint": {
      "triggerThreshold": 0.85,
      "budgetAllocation": {
        "checkpoint": 0.4,
        "memory": 0.3,
        "recentMessages": 0.2,
        "notes": 0.1
      }
    },
    "dream": {
      "autoInterval": "7d",
      "scope": "last-7-sessions"
    },
    "distill": {
      "minFrequency": 3,
      "confidenceThreshold": 0.85
    }
  },
  "goal": {
    "judgeModel": "mimo-v2.5",
    "defaultStrictness": "normal"
  },
  "experimental": {
    "maxMode": {
      "enabled": true,
      "candidates": 3,
      "judgeModel": "mimo-v2.5"
    }
  },
  "mcp": {
    "servers": {
      "github": {
        "command": "npx",
        "args": ["-y", "@anthropic/mcp-github"],
        "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
      }
    }
  }
}

4.3 实战示例：用 MiMo Code 开发一个 REST API

第一步：用 Plan Agent 分析需求

mimo> /plan
切换到 Plan 模式（只读分析）

mimo> 分析当前项目结构，为我设计一个用户管理模块的 API 架构

🤔 分析中...

第二步：设置 Goal 停止条件

mimo> /goal 实现用户管理 CRUD API
  criteria:
    - POST /api/v1/users (创建用户)
    - GET /api/v1/users/:id (获取用户)
    - PUT /api/v1/users/:id (更新用户)
    - DELETE /api/v1/users/:id (删除用户)
    - GET /api/v1/users (列表，分页)
    - 输入验证（所有端点）
    - 错误处理统一格式
    - 单元测试覆盖率 > 85%
  judge: deepseek-v4-chat
  strictness: strict

第三步：切换到 Build Agent 执行

mimo> [按 Tab 切换到 Build 模式]

mimo> 按照上面的需求，实现用户管理 API。使用 FastAPI + SQLAlchemy。

🔧 开始执行...
  ├── 创建 models/user.py
  ├── 创建 schemas/user.py
  ├── 创建 routes/users.py
  ├── 创建 services/user_service.py
  ├── 创建 tests/test_users.py
  └── 运行测试...

[checkpoint-writer] 自动保存检查点 #1

  ✅ POST /api/v1/users 创建完成
  ✅ GET /api/v1/users/:id 创建完成
  ✅ PUT /api/v1/users/:id 创建完成
  ✅ DELETE /api/v1/users/:id 创建完成
  ✅ GET /api/v1/users 创建完成
  
[Agent 请求停止]
[裁判模型评估中...]
  ✅ POST /api/v1/users — 输入验证 ✓ | 错误处理 ✓
  ✅ GET /api/v1/users/:id — 存在性检查 ✓ | 404 处理 ✓
  ⚠️ PUT /api/v1/users/:id — 部分更新未实现
  ❌ DELETE /api/v1/users/:id — 软删除逻辑缺失
  
[裁判结论] 目标未达成（完成度 71%）
[Agent 继续]...

  🔧 修复 PUT 端点部分更新
  🔧 添加 DELETE 软删除逻辑
  🔧 补充额外测试用例

[Agent 再次请求停止]
[裁判模型重新评估...]
  ✅ 所有标准通过
  
[Agent] 任务完成！
  修改了 8 个文件，新增 452 行代码
  测试覆盖率：89%（目标 > 85%）

第四步：查看自动生成的记忆

cat .mimocode/memory.md

# 项目记忆

## [2026-06-17] 用户管理 API 实现

### 架构决策
- 使用 FastAPI + SQLAlchemy 2.0（async）
- 数据库：PostgreSQL 16
- 认证：JWT（后续实现）
- 密码哈希：argon2（待实现，当前明文存储）

### API 端点
| Method | Path | 功能 | 状态 |
|--------|------|------|------|
| POST | /api/v1/users | 创建用户 | ✅ |
| GET | /api/v1/users/:id | 获取用户 | ✅ |
| PUT | /api/v1/users/:id | 更新用户 | ✅ |
| DELETE | /api/v1/users/:id | 软删除 | ✅ |
| GET | /api/v1/users | 分页列表 | ✅ |

### 代码约定
- 模型层：models/
- Schema 层：schemas/（Pydantic v2）
- 业务逻辑：services/
- 路由：routes/
- 测试：tests/（pytest + httpx）

### 待办
- [ ] 实现 JWT 认证
- [ ] 添加密码哈希
- [ ] 添加 rate limiting
- [ ] 接入 Redis 缓存

4.4 跨会话恢复：记忆的真正威力

现在，关闭终端，第二天重新打开：

cd ~/projects/myapp
mimo

🔄 检测到项目记忆文件
📋 注入项目记忆：用户管理 API 架构、代码约定、待办事项
📋 注入检查点 #3：上次完成了用户管理 CRUD API
📋 注入任务进展：T1（用户管理）✅ → T2（认证系统）⏳

mimo> 上次我们完成了用户管理 API，现在开始实现 JWT 认证

Agent 不需要重新理解项目结构——它已经从记忆中知道了所有上下文。这就是 MiMo Code 的杀手锏。

五、与其他 Coding Agent 的对比分析

5.1 MiMo Code vs Claude Code

5.2 MiMo Code vs Cursor

5.3 什么时候应该用 MiMo Code？

推荐使用场景：

• 后端项目开发（API、微服务、数据库）
• 需要多天才能完成的复杂功能
• 团队协作项目（记忆可以共享）
• 需要跨会话保持上下文的场景
• 模型选择灵活（想用 DeepSeek、Kimi 等）

不推荐使用场景：

• 简单的单文件修改
• 需要实时预览的前端开发（缺乏 GUI 集成）
• 对安装依赖敏感的环境（需要 Bun 运行时）

六、性能优化与最佳实践

6.1 记忆系统的优化

{
  "memory": {
    "checkpoint": {
      "triggerThreshold": 0.80,
      "budgetAllocation": {
        "checkpoint": 0.35,
        "memory": 0.25,
        "recentMessages": 0.25,
        "notes": 0.15
      }
    },
    "dream": {
      "autoInterval": "3d",
      "scope": "last-5-sessions",
      "compressionRatio": 0.7
    }
  }
}

优化建议：

1. 降低 triggerThreshold：从默认 0.85 降到 0.80，更早触发上下文重建，避免信息丢失。
2. 定期执行 /dream：不要等到自动触发。每天结束工作前手动执行一次，确保当天的重要知识被持久化。
3. 清理过时记忆：MiMo Code 的 /dream 会自动清理，但也可以手动审查 MEMORY.md，删除过时信息。
4. 控制记忆文件大小：MEMORY.md 建议保持在 2000 行以内，过大的记忆文件会拖慢注入速度。

6.2 子智能体的成本优化

// 不同类型的子智能体使用不同级别的模型
const SUB_AGENT_MODEL_STRATEGY = {
  'checkpoint-writer': 'haiku',       // 记录任务用最轻量的模型
  'test-runner': 'haiku',             // 运行测试只需理解测试输出
  'code-reviewer': 'sonnet',          // 审查需要理解力
  'task-executor': 'mimo-v2.5',       // 执行任务用主力模型
  'architect': 'mimo-v2.5',           // 架构设计需要最强模型
};

成本控制的核心思路：不是所有子智能体都需要最强模型。记录、测试运行这类确定性任务，用轻量模型完全够用，但执行、审查这类需要创造力和判断力的任务，还是需要强模型。

6.3 Goal 系统的最佳实践

# 好的 Goal 设置：具体、可衡量
mimo> /goal 实现用户认证
  criteria:
    - POST /auth/login 返回 JWT token
    - POST /auth/register 创建用户并返回 token
    - POST /auth/refresh 刷新 token
    - POST /auth/logout 使 token 失效
    - 中间件验证 Authorization header
    - token 过期返回 401
    - 所有端点有输入验证
    - 测试覆盖率 > 80%

# 差的 Goal 设置：模糊、不可衡量
mimo> /goal 把认证做完

原则：

• 每个标准都是可独立验证的
• 覆盖正常路径和异常路径
• 包含可量化的质量标准

七、生产环境部署建议

7.1 企业级部署架构

团队协作部署：

┌──────────────────────────┐
│      共享项目记忆          │
│  (Git 仓库中的 .mimocode) │
└──────────┬───────────────┘
           │
    ┌──────┴──────┐
    │             │
┌───┴───┐   ┌───┴───┐
│开发者A │   │开发者B │
│MiMo   │   │MiMo   │
│Code   │   │Code   │
└───────┘   └───────┘

# .gitignore 配置
.mimocode/checkpoint.md     # 检查点是个人会话级别的，不需要共享
.mimocode/notes.md         # 笔记是个人级别的
.mimocode/tasks/*/progress.md  # 任务进展是个人级别的

# 但 MEMORY.md 应该共享！
# !.mimocode/memory.md      # 这条不要加

7.2 CI/CD 集成

# GitHub Actions 中的 MiMo Code 使用
name: Auto Code Review with MiMo Code

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  code-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Install MiMo Code
        run: npm install -g @mimo-ai/cli
        
      - name: Run code review
        env:
          MIMO_API_KEY: ${{ secrets.MIMO_API_KEY }}
        run: |
          mimo plan --review \
            --spec "Review this PR for security issues, \
                     code quality, and test coverage" \
            --output review-report.md
      
      - name: Post review comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const report = fs.readFileSync('review-report.md', 'utf8');
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: report
            });

八、争议与反思

8.1 「套壳」争议的理性分析

MiMo Code 基于 OpenCode 二次开发，这一点毫不避讳。但这种「套壳」真的有问题吗？

历史上，几乎每一个成功产品都是「套壳」起家的：

• VS Code 套壳了 Monaco Editor
• Claude Code 套壳了 Anthropic API
• macOS 套壳了 Mach + BSD

关键不在于你「套」了什么，而在于你在套壳之上加了什么。

MiMo Code 在 OpenCode 之上加了：

1. 持久化记忆系统（最大差异化）
2. 独立裁判模型（Goal 系统）
3. 子智能体编排
4. Max Mode 并行推理
5. /dream 和 /distill 自我进化
6. Compose 工作流

这些工程创新的价值，远超「基于什么 fork」这个事实。

8.2 「14 天 5 人」背后的思考

MiMo 团队用 vibe-coding 方式在 14 天内完成了 MiMo Code 的开发——这本身就是一个「用 AI 写 AI 工具」的鲜活案例。

这个信息有两层含义：

1. 正面：AI 工具已经强大到可以快速构建复杂应用
2. 反面：14 天的产品，工程质量需要时间检验

建议在实际生产使用中：

• 关注 Issue tracker 中的已知问题
• 不要在生产环境的 codebase 上直接使用
• 持续关注版本更新（当前 V0.1.0，迭代速度很快）

8.3 限时免费的 MiMo Auto

MiMo Code 内置了限时免费的 MiMo Auto 通道（使用 MiMo-V2.5 模型）。这意味着你可以零配置、零成本地体验完整功能。

但要注意：「限时」意味着未来可能会收费。对于个人开发者来说，更稳妥的选择是配置自己的 Provider（如 DeepSeek、Kimi），不依赖厂商的免费午餐。

九、未来展望

9.1 MiMo Code 的发展方向

基于当前架构和社区反馈，MiMo Code 可能的发展方向：

1. GUI 前端：当前只有 CLI，未来可能推出 VS Code 扩展或 Web 界面
2. 团队协作：共享记忆、任务分配、代码审查工作流
3. 多模态输入：语音输入已经支持（/voice），未来可能支持截图识别、设计稿转代码
4. IDE 集成：LSP 协议的深度利用
5. 模型生态：支持更多国产模型（通义千问、文心一言等）

9.2 Coding Agent 的终局思考

MiMo Code 提出了一个值得整个行业思考的问题：

Coding Agent 的核心竞争力到底应该是什么？

是模型的推理能力？是工具链的丰富程度？是 IDE 集成的深度？

MiMo Code 的回答是：工程化地管理上下文和记忆。

这暗示着一个趋势：未来 Coding Agent 的差异化可能不再来自模型本身（因为大家都在用类似的模型），而是来自工程层面的创新——谁能让 Agent 更可靠、更持久、更可控，谁就赢了。

十、总结

MiMo Code 虽然还很年轻（V0.1.0），但它展现的工程思路是成熟的：

1. 把记忆从模型的负担变成系统的能力——SQLite FTS5 + 结构化 Markdown 文件
2. 用确定性工程兜住模型的非确定性行为——Goal 系统、checkpoint-writer
3. 通过并行推理提升关键决策的质量——Max Mode
4. 让 Agent 越用越懂你——/dream 和 /distill 自我进化
5. 开放模型选择权——不绑定单一厂商

无论你是 Claude Code 的深度用户、Cursor 的忠实粉丝，还是刚接触 AI 编程的新手，MiMo Code 都值得你花时间了解——不是因为它是「小米做的」，而是因为它用正确的方式解决了正确的问题。

# 一行命令开始体验
curl -fsSL https://mimo.xiaomi.com/install | bash

等你真正体验到「跨会话记忆」的威力时，你就会理解为什么我说——这可能改变你对 Coding Agent 的全部认知。

本文基于 MiMo Code V0.1.0 版本撰写，项目地址：https://github.com/XiaomiMiMo/MiMo-Code，采用 MIT 许可证开源。