MiMo Code 概述与核心概念

适合读者: 所有对 AI 编码智能体感兴趣的读者

MiMo Code 是小米 MiMo 团队基于 OpenCode 构建的开源终端编码智能体，于 2026 年 6 月以 MIT 协议发布。它不仅是一个实用的 AI 编程工具，更是一个“住在你电脑里、理解你的 AI“——使用越多，越懂你。

设计动机

编码智能体的基本结构是将语言模型置于运行时中并循环调用：模型负责推理和决策，运行时管理工具、持久化状态并组装每轮输入。模型本身是无状态的——每次调用从零开始，所有连续性由运行时提供。

对于短任务（通常少于 10 轮），这种结构运作良好：只需将完整对话历史传递给模型即可，因为历史本身充当了足够的工作记忆。但随着任务轮次增加，两个问题逐渐显现：

问题一：上下文窗口最终会耗尽。 无论窗口多大，数十轮的工具输出、代码片段和错误日志最终会填满它。此时必须压缩或丢弃部分历史。常见的方法是生成摘要来替代丢弃的内容。但简单的压缩不断强化邻近信息，削弱远距离信息。这种方法遇到类似 Mamba 等循环模型的内在困境：它有状态，但无法按需回溯。我们需要的不是更好的压缩，而是明确的存储和检索机制，决定什么信息应该写入持久化结构，以及何时召回。

问题二：即使上下文窗口足够大，模型的指令遵循能力也会随输入长度增长而下降。 有用的约束和意图被大量工具输出稀释，使得模型越来越难以提取下一步应该做什么。

MiMo Code 团队观察到，不同时间尺度上最突出的瓶颈各不相同：

这三个时间尺度恰好对应 计算（Computation）、记忆（Memory）和进化（Evolution）。MiMo Code 围绕这三个主题设计。

三大主题

1. 计算（Computation）：扩展单轮推理

当任务增长到数十甚至数百步时，每个单独步骤的错误率随时间累积，而智能体在长时间执行中往往缺乏外部纠正信号。直接的应对方式是在不同粒度级别投入额外计算以换取可靠性：在单步骤级别降低决策错误概率，在任务级别防止过早终止或方向漂移，在执行级别减少不必要的来回开销。

1.1 并行采样与选择（Max Mode）

Max Mode 在每轮并行生成 N 个候选解决方案（默认 N=5）。每个候选独立完成推理和工具调用规划，但不实际执行计划。然后使用同一模型作为判断者，比较所有候选的推理过程和行动计划，选择最佳的一个执行。

默认情况下，温度设为 1，因此五个独立采样几乎不会产生相同的结果。如果多个候选恰好收敛，这本身就表明该方向具有高置信度；当候选显著不同时，使用低温判断者选择最稳健的计划比依赖单个采样更可靠。

在 SWE-Bench Pro 上，Max Mode 相比单采样提升 10-20% 性能，代价是约 4-5 倍的 token 消耗。

注意：Max Mode 目前是实验性功能，必须通过配置手动启用。

1.2 独立完成验证（Goal）

Max Mode 解决“做对“的问题；Goal 解决“做完“的问题。

长任务中常见的失败模式是：在看到先前进度后，智能体倾向于过早宣布“完成“或提出问题。这在自动化执行中尤其危险，因为没有人站在旁边纠正或提供反馈。

Goal 机制的工作原理：用户定义自然语言停止条件，例如“所有测试通过且代码已提交“。每当智能体试图终止时，系统自动启动独立的模型调用，审查完整对话历史并判断条件是否真正满足。如果不满足，反馈具体差距让智能体继续；如果任务被确认为不可能，则标记为不可能。

这个验证器不参与实际工作，因此不会对智能体已完成的部分产生对齐偏差。每次它接收与智能体完全相同的上下文，包括实际的工具输出。

实践中，误阻塞（条件已满足但验证器判断未满足）比误通过更常见。这主要发生在测试因环境问题失败时。总体而言，无限循环的概率低于 0.5%，系统可在达到限制后自动退出。

Max Mode 和 Goal 代表测试时计算的两个正交方向：Max Mode 是并行的，在同一步骤上花费 N 倍计算选择最佳选项；Goal 是串行的，在同一任务内花费更多时间进行自检和持续执行。两者可以同时启用。

1.3 动态工作流（Dynamic Workflow）

当任务规模变得足够大时——例如将整个项目从一种编程语言迁移到另一种——需要同时协调数十甚至数百个并行工作单元，逐轮工具调用不再足够。

传统方法是将流程写入 SKILL.md，用自然语言告诉模型：“先做 A，然后做 B，如果发生 C 就做 D。“这在简单场景中有效，但在复杂工作流中系统性失败：上下文压缩可能吞没步骤，模型可能跳过某些阶段，分支和重试逻辑依赖模型判断而非代码保证，同一工作流在两次运行中可能遵循不同执行路径。根本问题是编排逻辑存在于自然语言中，而自然语言是模糊的、易忘的、不可验证的。

Dynamic Workflow 将编排逻辑从提示词转为代码。主 Agent 生成 JavaScript 脚本，在隔离沙箱内确定性执行。脚本通过 agent() 调度子智能体，通过 parallel() / pipeline() 控制并发——if 语句不会忘记分支，for 循环不会提前退出，barrier 不会遗漏子智能体。模型的判断只在应该使用的地方使用，例如理解和生成代码，而非浪费在流程控制上。

2. 记忆（Memory）：维护多轮任务的状态连续性

扩展单轮计算可以降低每一步的错误率，但不解决多轮任务的核心问题：上下文最终会用完。本节讨论如何让逻辑会话无限延伸，同时保持每个物理窗口有界。

2.1 循环（Cycle）：无界会话的基本单位

想象会话是排列在从左到右的轮次序列。窗口有上限，轮次不断积累，窗口最终会填满。如果没有干预，会话要么在达到限制时结束，要么悄悄退化。

在达到限制之前，运行时在几个固定位置干预。我们称这些位置为检查点。在每个检查点，运行时分派独立的写入器子智能体：它读取迄今为止的对话，并将结构化状态文件写入磁盘。主智能体在写入器运行时继续工作，两者互不干扰。

当窗口接近真正上限时，运行时执行重建：切断当前窗口，打开新窗口，并使用持久化文件作为种子重建上下文。主智能体在新窗口中醒来，状态已摆在其面前，然后继续工作。从模型的角度看，对话从未中断；从运行时的角度看，新的物理窗口已经开始。

一个经过检查点并最终以重建结束的轮次序列是一个循环（Cycle）。循环数量没有上限——每个循环受物理窗口大小限制，但逻辑会话是循环的链，该链没有最大长度。

2.2 为什么提前提取

自然直觉是延迟提取直到窗口几乎满。我们发现这恰恰是错误的。

首先，模型能力在高上下文利用率下退化。文献中称之为“中间丢失“：随着输入变长，对中间部分的注意力下降，结构化提取的可靠性显著下降。在压缩能力退化的关键时刻要求模型执行最关键的压缩是糟糕的权衡。

其次，提取本身需要空间。写入器必须读取历史、维护其解释并产生结构化输出——所有这些都在同一个窗口内。在 95% 利用率下，没有思考空间；在 30% 利用率下，空间充裕。

因此，检查点在远低于上限时触发——大约在配置预算的 20%、45% 和 70%。每次触发都是对前一次的增量更新；没有一次是单次摘要。接近上限时的最终重建不是匆忙压缩，而是沿途积累的结构化记录转化为工作上下文的时刻。

2.3 写入器：独立于主智能体的提取器

最自然的反应是让主智能体维护自己的笔记。我们发现这在长任务中行不通：要求当前正在调试棘手问题的模型同时维护结构化日志，往往导致两项任务都做得更差。

因此我们施加不同的约束：主智能体不维护自己的记忆。 提取完全移出主循环，由运行时触发并由独立的写入器子智能体执行——不共享主智能体的注意力或 token 预算。

写入器写入具有固定结构的检查点文件（11 个字段：当前意图、下一步操作、工作约束、任务树、当前工作、涉及文件、跨任务发现、错误和修复、运行时状态、设计决策和杂项笔记），并在需要时更新项目级记忆。对于每个结构化文件，只允许一个写入者写入——单写入者是防止并发写入导致不一致状态的最简单不变量。

2.4 四层记忆

写入器不只写一个文件。它维护分层记忆系统，每层具有不同的生命周期：

上层更精炼、更持久、更小；下层更完整、更大、更慢。写入器负责向上蒸馏，历史作为底层的回退。

主智能体对结构化文件具有只读访问权限，有一个例外：notes.md，一个会话级自由格式暂存区。主智能体可以随时向其中追加零散发现；在每个检查点，写入器读取它，将其内容路由到适当的结构化字段，然后清空它。这是主智能体可用的唯一写入通道。

2.5 重建注入

当运行时执行重建时，它将持久化文件组装成分层提示并注入新窗口，每个部分有独立的 token 限制。近似顺序为：任务列表（智能体首先需要知道它应该做什么）→ 会话检查点 → 最近用户消息的逐字片段（防止写入器的重写偏离用户原始意图）→ 项目记忆 → 全局记忆 → 笔记 → 可按需读取的内存文件路径索引 → 告诉智能体下一步做什么的尾部提醒。

即使每个部分达到限制，总注入内容也保持在约 65K tokens 以内——完全在任何合理上下文窗口的工作预算内。从这些信息恢复状态后，智能体直接继续工作，无需重新确认目标或重新读取已处理的文件。

3. 进化（Evolution）：从经验中持续改进

前两节解决如何在单轮和单会话内良好工作。但在实际开发中，用户可能与同一项目交互数十甚至数百次。如果每次会话结束后所有经验都丢失，智能体永远无法从过去的工作中积累；它必须每次重新发现相同的项目约束并重复相同的错误。

3.1 项目记忆

MiMo Code 维护项目级记忆文件（Markdown 格式），跨会话持久存储知识：项目背景、用户明确指定的规则、架构决策及其理由、以及反复验证的技术事实。

选择文件而非纯向量数据库的核心原因是可审查性：一旦记忆影响智能体的后续行为，用户需要能够看到系统记住了什么、删除不正确的条目、修改过时的知识。文件可以通过标准读写工具直接操作，无需为每个维护操作提供专用接口。全文索引在文件之上提供快速检索。

写入器每次触发时只更新当前会话的检查点，并在代码级别强制执行写入权限。后台写入器只能写入指定文件路径，任何越界写入直接被拒绝。

3.2 记忆维护（Dream 和 Distill）

项目记忆文件随时间增长。如果不维护，过时的条目、重复记录和无效文件引用逐渐积累，降低信噪比。

Dream 每 7 天自动触发。独立智能体读取历史会话对话和现有记忆文件，然后执行合并、去重、路径有效性验证和压缩——将零散记忆收敛为当前状态的紧凑表示，并更新全局记忆。

Distill 每 30 天自动触发。也由独立智能体执行，读取历史会话，但其焦点不是知识——而是过程。它识别重复的工作模式，并将其固化为可复用的技能、CLI 命令、自定义智能体、SOP 文档和类似工件。

核心特性速查

核心概念说明

1. 上下文窗口（Context Window）

什么是上下文窗口？ 上下文窗口是语言模型在单次API调用中可以处理的输入token的最大数量。想象一下，这是模型的"注意力范围"——它一次只能关注这么多内容。

典型大小？ 早期的GPT模型支持约4K tokens，当前主流模型（如GPT-4、Claude 3）支持8K-32K tokens。MiMo Code 使用的MiMo-V2.5模型支持高达100万tokens，这是普通对话模型无法比拟的。

为什么重要？ 上下文窗口决定了模型一次可以理解多少历史信息。窗口太小意味着模型需要不断忘记重要上下文；窗口太大意味着计算成本高昂且可能出现注意力稀释。MiMo Code 的创新在于，它通过检查点和重建机制，让逻辑会话无限延伸，即使物理窗口有限。

简单类比： 想象你在看一本厚书，但书桌空间有限，只能摊开10页。如果你想看完整本书，你需要定期把看过的部分存到书架上，然后把新内容展开继续看。MiMo Code 的检查点就是这种"存书到书架"的过程。

代码示例：

// 上下文窗口管理示例
const contextWindow = {
  maxTokens: 100000,  // MiMo-V2.5 支持 100K tokens
  currentUsage: 0,
  bufferThreshold: 0.8,  // 80% 时触发重建
  
  shouldCheckpoint() {
    return this.currentUsage >= this.maxTokens * this.bufferThreshold;
  },
  
  injectContext(checkpointData) {
    // 从持久化检查点重建上下文
    const reconstructed = this.reconstructFromCheckpoint(checkpointData);
    return this.trimToWindow(reconstructed);
  }
};

2. Token 预算（Token Budget）

什么是Token预算？ Token预算是模型在单次API调用中可以使用的token数量限制。每个输入（提示词）和输出（回复）都消耗预算。

如何消耗？ 每个消息、工具调用、代码片段、错误信息都会被转换为token。预算消耗遵循简单的加法原则：总使用 = 所有输入token + 所有输出token。MiMo Code 的智能上下文管理通过预算注入技术，在重建时确保关键信息在预算范围内。

预算耗尽时会发生什么？ 当预算耗尽时，系统会触发检查点写入器，持久化当前状态。然后执行上下文重建，从持久化文件中提取关键信息，智能地注入新窗口。模型继续工作时，预算会自动分配给重建内容，确保没有信息丢失。

简单类比： 想象你有一个每月1000美元的预算。购物时，每件商品都有价格。当预算用完时，你需要停止购物，保存已买的商品，然后第二天继续购物。MiMo Code 的预算管理就像一个自动的"购物助手"，确保你不会超支，并能继续工作。

代码示例：

// Token 预算管理示例
class TokenBudget {
  constructor(maxTokens) {
    this.maxTokens = maxTokens;
    this.usedTokens = 0;
    this.injectionPriority = ['taskList', 'checkpoint', 'userIntent', 'projectMemory'];
  }
  
  canInject(content) {
    const contentTokens = this.countTokens(content);
    return this.usedTokens + contentTokens <= this.maxTokens;
  }
  
  injectWithPriority(content, priority) {
    if (this.injectionPriority.includes(priority) && this.canInject(content)) {
      this.usedTokens += this.countTokens(content);
      return true;
    }
    return false;
  }
  
  reset() {
    this.usedTokens = 0;
  }
}

3. 检查点（Checkpoint）

检查点是什么？ 检查点是MiMo Code 的持久化机制，类似于游戏中的"保存进度"。当上下文窗口接近极限时，系统会自动保存当前状态到磁盘。

与游戏保存点的区别？ 游戏保存点通常手动触发，而MiMo Code 的检查点是自动的、智能的。游戏保存点通常只保存游戏状态，而MiMo Code 的检查点保存完整的对话历史、意图、操作计划、工作约束、任务树、当前工作、涉及文件、跨任务发现、错误和修复、运行时状态、设计决策等11个字段。

检查点如何工作？ 写入器子智能体独立于主智能体运行，不消耗主智能体的注意力或token预算。每个检查点都包含分层记忆：会话记忆（当前逻辑会话）、项目记忆（持久化项目级知识）、全局记忆（跨项目偏好）、历史（完整会话追踪）。当窗口需要重建时，系统从这些持久化文件中提取关键信息，智能地注入新窗口。

简单类比： 想象你在写一篇长篇论文。 halfway 的时候，你会保存草稿到磁盘，这样如果电脑突然死机，你可以继续写。MiMo Code 的检查点就像这种"自动保存"的过程。

代码示例：

// 检查点写入器示例
class CheckpointWriter {
  constructor() {
    this.checkpointData = {
      conversationHistory: [],
      currentIntent: '',
      nextActions: [],
      workConstraints: [],
      taskTree: [],
      currentTask: '',
      involvedFiles: [],
      crossTaskDiscoveries: [],
      errorsAndFixes: [],
      runtimeState: {},
      designDecisions: [],
      notes: ''
    };
  }
  
  async writeCheckpoint() {
    // 独立于主智能体运行
    const structuredData = await this.extractStructuredData();
    await this.persistToDisk(structuredData);
    return structuredData;
  }
  
  async reconstructContext() {
    const checkpointData = await this.loadFromDisk();
    return this.reconstructFromCheckpoint(checkpointData);
  }
}

与 OpenCode 的关系

MiMo Code 是 OpenCode 的分支（fork）。它保留了 OpenCode 的所有核心能力（多供应商、TUI、LSP、MCP、插件），并新增了：

• 持久化记忆系统
• 智能上下文管理
• 子智能体编排
• 目标驱动自主循环
• Compose 工作流
• 通过 Dream/Distill 实现的自我改进

这种设计选择使得 MiMo Code 可以无缝迁移现有 OpenCode 配置，同时获得长任务自动化方面的显著优势。

快速开始指南

安装步骤

# 一键安装，或通过 npm 安装
curl -fsSL https://mimo.xiaomi.com/install | bash
npm install -g @mimo-ai/cli

# 运行
mimo

首次运行示例

首次启动时，MiMo Code 引导用户选择模型访问方式：

┌─────────────────────────────────────┐
│     MiMo Code - 首次启动向导     │
├─────────────────────────────────────┤
│ 请选择您偏好的模型访问方式：     │
│                                   │
│  1. MiMo Auto（限时免费）         │
│     - 基于 MiMo-V2.5，支持 100 万 token 上下文 │
│                                   │
│  2. 小米 MiMo 平台               │
│     - OAuth 登录                   │
│                                   │
│  3. 从 Claude Code 导入         │
│     - 一步迁移现有认证           │
│                                   │
│  4. 自定义模型                   │
│     - 在 TUI 中添加任何 OpenAI 兼容 API │
│                                   │
│ 请输入选项编号 [1-4]：           │
└─────────────────────────────────────┘

选择选项 1 后，系统会显示欢迎界面并开始初始化。用户将看到类似以下内容：

┌─────────────────────────────────────┐
│           MiMo Code 欢迎您！        │
├─────────────────────────────────────┤
│  模型：MiMo-V2.5 (100K tokens)      │
│  状态：初始化中...                │
│                                   │
│  ✓ 加载配置...                    │
│  ✓ 初始化记忆系统...              │
│  ✓ 设置上下文管理器...            │
│  ✓ 启动子智能体系统...             │
│                                   │
│  正在加载您的项目...              │
│  （如无项目，将创建示例项目）   │
│                                   │
│  按 Ctrl+C 退出                 │
└─────────────────────────────────────┘

常见反模式

反模式一：把 MiMo Code 当成“更聪明的 Copilot“用。 Copilot 的交互模式是“你写一行，我补一行“，每次交互都是独立的。MiMo Code 的设计目标是“你给一个任务，我持续执行直到完成“。如果你用 MiMo Code 的方式和 Copilot 交互（每次只说“帮我写个函数“），你会觉得 MiMo Code 的记忆系统和检查点机制“没什么用“——因为你的任务太短了，根本不会触发检查点。MiMo Code 的价值在长任务中才体现：200+ 步骤的代码迁移、多天完成的重构、需要跨会话保持上下文的项目。用短任务的标准评价长任务工具，就像用城市 SUV 的标准评价越野车的通过性。

反模式二：忽视 Distill 生成的技能需要人工审查。 Distill 每 30 天自动从历史会话中提取重复模式，固化为 CLI 命令、自定义智能体和 SOP 文档。这个过程是自动化的，但不是完美的。它可能把一次性的特殊操作错误地固化为“标准流程“，或者把两个相关但不同的模式合并为一个模糊的技能。有些开发者看到 Distill 生成了新技能就直接用，不检查内容是否准确。结果是智能体开始按照一个“看起来合理但实际上不准确“的 SOP 执行，错误被自动化放大。每次 Distill 运行后，花 10 分钟审查生成的技能文件，删除无用的、修正不准确的，这个投入远低于事后修复自动化错误的成本。

反模式三：在 MEMORY.md 中存储大量原始数据。 MEMORY.md 的设计意图是存储“经过验证的稳定知识“——架构决策、用户规则、反复确认的技术事实。有些开发者把 API 文档片段、代码示例、完整的错误日志都塞进 MEMORY.md，把它当成“万能笔记本“。结果是 MEMORY.md 膨胀到几千行，智能体在重建时需要从海量信息中提取关键内容，token 消耗暴增且提取质量下降。原始数据应该存在 SQLite 历史中，按需查询；MEMORY.md 只保留提炼后的结论。

适用场景与限制

MiMo Code 最适合的场景： 长周期自动化任务，比如将整个项目从 JavaScript 迁移到 TypeScript、从零搭建包含数据库和 API 的完整微服务、执行大规模的代码审查和重构。这类任务通常需要 200+ 步骤、跨越多个会话，MiMo Code 的检查点、上下文重建和 Dream/Distill 机制能显著降低失败率和重复劳动。需要持久化记忆的项目也很适合——比如一个分多天完成的特性开发，每次新会话 MiMo Code 自动加载之前的进度、决策和发现，不需要你重新介绍项目背景。

MiMo Code 不适合的场景： 简单的一次性交互（问一个问题、改一行代码、生成一个函数），这些任务 OpenCode 完全能胜任，MiMo Code 的记忆系统和检查点机制反而是不必要的开销。需要严格控制 token 成本的场景也要谨慎——Max Mode 的 4-5 倍消耗在按量计费模型下成本可观。另外，如果你的团队已经深度定制了 OpenCode 的 Plugin 生态，迁移成本可能高于收益，特别是那些依赖 OpenCode 特定行为的自定义 Plugin。

Dream/Distill 的边界： Dream 和 Distill 是自动化的经验积累机制，但它们不能替代人工的架构思考。Dream 合并的是“记忆“，不是“知识“；Distill 提取的是“模式“，不是“设计“。它们能帮你记住“上次这么做出了问题“，但不能帮你判断“这次应该怎么做“。架构决策、技术选型、安全策略这类需要人类判断的工作，不能交给自动化机制。

常见失败与陷阱

陷阱一：首次启动时选择错误的模型访问方式。 MiMo Code 首次启动时引导选择模型访问方式，选项包括 MiMo Auto（基于 MiMo-V2.5）、小米 MiMo 平台、从 Claude Code 导入、自定义模型。很多开发者习惯性选择“从 Claude Code 导入“，因为他们已经在用 Claude Code。但 MiMo-V2.5 在长任务场景下的表现经过专门优化，特别是 100 万 token 的上下文窗口是 Claude 系列无法比拟的。如果你的核心需求是长任务自动化，MiMo Auto 是更好的起点。从 Claude Code 导入更适合那些已经深度定制了 Claude Code 配置、不想重新配置的团队。

陷阱二：检查点文件被意外修改。 checkpoint.md 是写入器子智能体的专属文件，主智能体只有只读权限。但有些开发者直接用文本编辑器打开 checkpoint.md “看看写了什么”，甚至手动修改其中的内容。写入器在下次检查点时会基于对话历史重新生成 checkpoint.md，手动修改会被覆盖。更糟糕的是，如果手动修改引入了格式错误（比如破坏了 11 个字段的结构），写入器可能无法正确解析，导致整个检查点机制失效。想查看检查点内容，用 mimo /memory-view checkpoint.md 命令，不要直接编辑文件。

陷阱三：多会话之间的记忆冲突。 两个开发者在同一项目上工作时，各自的 MiMo Code 实例会向 MEMORY.md 写入不同的观察。开发者 A 记录“使用 PostgreSQL“，开发者 B 记录“迁移到 MySQL“，Dream 合并时可能选择其中一个，另一个的观察被丢弃。结果是某个开发者醒来后发现项目记忆和自己之前的理解不一致，按照错误的前提执行任务。团队使用时建议约定“MEMORY.md 的主要维护者“，或者定期人工审查合并结果，确保关键决策的准确性。

下一步

• 想深入了解架构设计？→ MiMo Code 架构深度解析
• 想了解驾驭工程优化？→ 驾驭工程优化设计
• 想了解循环工程优化？→ 循环工程优化设计
• 想对比 OpenCode？→ MiMo Code vs OpenCode 对比分析

Skill 作者视角

MiMo Code 的 Dream 和 Distill 机制与 OpenCode 的 Skill 系统有着深刻的联系和互补性。

1. Dream（每周压缩）

什么是 Dream？ Dream 是 MiMo Code 的每周自动化压缩机制，它从历史会话对话和现有记忆文件中提取模式，执行合并、去重和路径有效性验证，最终将零散记忆收敛为当前状态的紧凑表示，并更新全局记忆。

与 OpenCode Skill 的联系？ OpenCode 的 Skill 系统允许开发者定义可重用的代码片段和工作流。Dream 则从实际使用中提取这些模式，将它们转化为可共享的技能。想象 Dream 就像一个“技能发现器“，它自动识别出哪些代码片段和工作流模式值得提炼为 Skill。

具体实现：

// Dream 机制示例
class DreamEngine {
  async weeklyCompression() {
    // 1. 读取历史会话和记忆文件
    const historyData = await this.loadHistoryData();
    const memoryFiles = await this.loadMemoryFiles();
    
    // 2. 执行合并和去重
    const compressed = await this.mergeAndDeduplicate(historyData, memoryFiles);
    
    // 3. 验证路径有效性
    const validated = await this.validatePathValidity(compressed);
    
    // 4. 更新全局记忆
    await this.updateGlobalMemory(validated);
    
    // 5. 生成可导出的技能模式
    return await this.generateSkillPatterns(validated);
  }
}

2. Distill（每月技能提取）

什么是 Distill？ Distill 是 MiMo Code 的每月技能提取机制，它识别重复的工作模式，并将它们固化为可复用的技能、CLI 命令、自定义智能体、SOP 文档等工件。

与 OpenCode Skill 的联系？ 这更直接——Distill 实际上就是 OpenCode Skill 的自动化生成器。MiMo Code 通过 Distill 发现重复模式，然后将其转化为 OpenCode Skill，使这些模式成为可重用的组件。

具体实现：

// Distill 机制示例
class DistillEngine {
  async monthlySkillExtraction() {
    // 1. 读取历史会话
    const historyData = await this.loadHistoryData();
    
    // 2. 识别重复的工作模式
    const patterns = await this.identifyWorkflows(historyData);
    
    // 3. 验证模式的有效性和通用性
    const validatedPatterns = await this.validatePatterns(patterns);
    
    // 4. 生成可复用的技能
    const skills = await this.generateSkills(validatedPatterns);
    
    // 5. 输出 Skill 文件
    return await this.outputSkillFiles(skills);
  }
}

3. 互补关系

为什么需要两者结合？

1. 自动发现 vs 显式定义：MiMo Code 的 Dream/Distill 可以自动发现值得提炼的模式，而 OpenCode Skill 允许开发者显式定义和控制技能。

2. 持续改进 vs 稳定版本：Dream/Distill 提供持续的自动化改进，而 OpenCode Skill 提供稳定的、可版本控制的技能库。

3. 大规模模式识别 vs 小规模定制：MiMo Code 擅长识别大规模重复模式，而 OpenCode Skill 适合小规模定制和专业化技能。

实际应用示例：

当一个开发团队每天都在执行类似的代码审查任务时，MiMo Code 的 Distill 会识别出这种模式，并将其转化为一个可重用的 Skill。团队成员可以直接在 OpenCode 中使用这个 Skill，而 MiMo Code 的 Dream 则持续优化这个 Skill，使其更高效。

这种互补关系使得开发者既能从实际使用中获得自动化收益，又能保持对技能的完全控制和可重用性。

• 想深入了解架构设计？→ MiMo Code 架构深度解析
• 想了解驾驭工程优化？→ 驾驭工程优化设计
• 想了解循环工程优化？→ 循环工程优化设计
• 想对比 OpenCode？→ MiMo Code vs OpenCode 对比分析