MiMo Code 的“无限上下文”机制其实并不复杂——它并非依赖堆叠 Token 来强行处理长对话，而是构建了一套结构清晰、分工明确的记忆管理方案。简单来说，它不指望大模型能记住所有细节，而是让系统自行学会“抓重点、存档案、做简报”。接下来，我们逐层拆解其运作逻辑。

Checkpoint 机制：在遗忘发生前主动保存关键节点

许多方案往往等到上下文窗口接近满额时才仓促处理，但 MiMo Code 的设计更为智能——它在对话进行到 20%、45%、70% 时自动触发检查点。这一提前量至关重要，能够为独立的 Writer 子 Agent 留出充足时间，完成结构化的信息提取。

• Writer 子 Agent 读取当前会话，从中提取出 11 个固定字段：意图、操作、任务树、错误记录、设计决策等
• 这些字段被写入磁盘文件（如 MEMORY.md 或 checkpoint-xxx.json），形成可追溯的项目记忆档案
• 主 Agent 对这些文件仅有读取权限，无法修改，从而避免人为干扰导致的记忆污染

Rebuild 流程：实现断点续传的关键操作

当上下文接近上限时，系统不会硬性填充或简单截断，而是执行 Rebuild——切断当前会话窗口，利用已保存的结构化记忆重新构建轻量级上下文。重建后的内容并非原始聊天记录的压缩版本，而是由 Writer 提炼出的语义摘要，以及当前任务状态。这相当于为新会话提供了一份“项目简报”，而非回放全部历史，显著降低了信息噪音。即使用户中断后重新启动，Agent 也能直接从上次中断点的任务树继续推进，无需重复解释背景信息。

四层记忆体系：不同粒度，各司其职

记忆并非扁平堆放，而是分层管理，各自承担不同职责：

• 项目记忆：跨会话沉淀，存储架构图、接口约定、技术选型依据，写入 MEMORY.md
• 会话检查点：单次长会话中的关键节点快照，支持中断后恢复
• 任务进度：实时追踪 Compose 模式下的子任务完成状态，用于 Goal 停止判断
• notes.md：唯一允许用户手动编辑的便签区，用于临时备注或调试提示

/dream 命令：记忆的定期蒸馏与进化

记忆并非越多越好，冗余和冲突反而会拖慢推理效率。/dream 是 MiMo Code 提供的主动治理工具：每 7 天自动运行一次，读取所有分散的记忆片段，识别重复决策、过时方案、已被推翻的设计假设，然后生成压缩后的当前状态简报，并更新 MEMORY.md 的主干内容。这相当于为项目做一次“记忆体检”，确保 Agent 始终基于最新共识工作。

这套逻辑绕过了 Transformer 注意力机制的物理限制，将“记什么”和“怎么记”交给工程系统，而将“怎么思考”留给模型自身。原理并不复杂，但往往容易被忽视。