谈到 MiMo Code 的持久化记忆，许多人首先会想到“不过是把聊天记录保存下来”。然而，如果仅仅这样理解，可能就忽略了这套系统真正的设计初衷。它并非简单的日志归档，而是一套面向真实开发场景打造的工程化状态维护方案。其核心目标是：当你在一个编程任务上需要跨越数天、跨越多个会话、经历上百轮交互时——比如上周确定的接口规范、昨天调整的配置路径，甚至临时放弃的分支策略——AI 如何继续记住这些信息？答案并不在语言模型的参数中，而是藏在它的记忆架构里。

那么，这套记忆架构具体是如何运作的？

基于 SQLite FTS5 的本地记忆底层

所有记忆数据默认保存在项目根目录下的 memory.db 文件中。它并非普通的数据库表，而是依托 SQLite 的 FTS5（全文搜索）扩展构建而成——一个专门针对语义检索进行优化的索引体系。这意味着什么？你搜索“暗色模式组件”，结果能命中“dark mode toggle”或“theme switcher”，依靠的是模糊匹配、词干提取以及权重排序。

• 在每个会话结束时，主 Agent 并非直接保存原始对话流，而是由 Writer 子 Agent 提取关键实体（文件路径、函数名称、决策结论、错误日志），生成结构化的记忆条目。
• MEMORY.md 是便于阅读的摘要文件，checkpoint.md 则是二进制快照，两者都由 FTS5 索引同步维护，搜索响应时间基本在毫秒级别。
• 数据库按项目自动隔离——不同仓库各自拥有独立的记忆空间，不会互相干扰，也不会泄露信息。

三重记忆机制的协同配合

单一的存储方式难以应对长周期任务的复杂性，因此 MiMo Code 将记忆拆分为三个层次，各司其职：

• 项目记忆：长期沉淀。自动生成 MEMORY.md，记录架构选型、编码规范、已知问题点、第三方依赖约束等。举个例子：当你第一次询问“这个服务是否需要添加 JWT 验证”时，回答会被提炼成一条规则写入项目记忆，后续所有与鉴权相关的操作都会自动参考这条规则。
• 会话检查点：中断续写的保障。每 15 轮交互，或者检测到 Git 提交、文件保存时，自动创建 checkpoint.md。下次使用 mimo --resume 启动，直接加载最新的检查点，一切无缝衔接，无需重新解释上下文。
• 动态简报压缩：上下文的守门员。当对话接近模型窗口上限时，独立的子 Agent 启动压缩流程——合并同类操作（例如连续三次修改同一个 config.ts）、剔除中间调试输出、保留最终状态及失败原因，生成精简版上下文供主 Agent 继续使用。

/dream 命令：让记忆实现自我进化

记忆并非静止的归档，而是持续演化的知识体系。/dream 是 MiMo Code 内置的记忆治理指令，每 7 天自动触发（也支持手动执行）。它调用专用的 Distill Agent 完成四项工作：

• 扫描所有历史会话及当前的 MEMORY.md，识别重复描述（例如多次提到“API 返回 401 时需要刷新 token”），然后去重合并。
• 验证所有引用的文件路径是否仍然有效，失效路径会被自动标记为 obsolete 并降低权重。
• 将分散的同类决策进行聚类——比如五次重构某模块的尝试，合并生成一条“该模块重构建议”的新条目。
• 输出一份 human-readable 的 dream-summary.md，告知你这周项目认知有哪些更新。

开发者可干预的记忆控制点

虽然记忆系统默认是全自动的，但在关键节点们为人工干预预留了入口：

• 使用 /forget file:src/utils/api.ts 可以主动清除与某个文件相关的记忆，适合重构后清理旧上下文。
• 直接编辑 MEMORY.md，增删项目规则，保存后立即生效——FTS5 索引会自动重建。
• 设置 MIMO_MEMORY_RETENTION=30d 环境变量，控制历史会话在数据库中的保留天数。
• 启用 --no-memory 启动参数可以完全关闭持久化功能，适用于敏感代码仓库的临时调试。

这套机制并不依赖大模型自身的记忆力，而是通过确定性的工程手段来兜住不确定性。它不承诺“永远不忘”，但确保“该记住的，一定记得住；该遗忘的，干净利落。”