所谓的“无限上下文”听起来似乎非常强大，仿佛模型可以无限制地吞入所有内容。但实际上，MiMo Code 通过一套精心设计的工程策略——记忆系统与自动重建机制——确保在长期任务中不丢失上下文、无需重复解释、也不用从头开始。它依赖的是策略，而非单纯依靠模型硬撑百万 token 而不崩溃。

实际上，上下文窗口依然存在物理上限。MiMo Code 默认集成 MiMo-V2.5-Pro 模型，支持 100 万 token 的上下文长度，这已是当前行业顶尖水平。然而，若超出此范围，KV Cache 可能溢出，推理延迟急剧增加，甚至直接导致 OOM（内存溢出）。由此可见，所谓的“无限”并非指无限制的窗口长度。

• 100 万 token 约等于 75 万汉字，或 20 万行中等复杂度的代码——足以覆盖一个中型项目的全部文件及完整对话历史。
• 当窗口接近上限时，模型对中间部分内容的关注度会显著下降（即经典的“Lost in the middle”问题），单纯拉长窗口只是治标不治本。
• MiMo Code 并未试图绕过这一物理限制，而是采取主动干预策略：在窗口使用率达到 20%、45%、70% 时分别触发 checkpoint，从而防止系统在临界点崩塌。

记忆系统的实际作用：将“记住什么”与“怎么记”分离开来

主 Agent 负责编写代码、运行命令和修改 Git；Writer 子 Agent 则负责观察、摘要和存档。两者权限分离：主 Agent 只能读取 memory 文件并写入 notes.md；Writer 独立运行，仅写入结构化字段（意图、动作、错误、设计决策等 11 类）。这种分工使得记忆更加稳定、可追溯，不易被临时指令污染。

• 每次 checkpoint 生成的不是原始对话快照，而是压缩后的语义摘要，体积通常仅为原始上下文的 3%～5%。
• 在 rebuild 阶段，注入的是这些摘要、当前任务目标以及最新代码变更，而非全部历史——这样既能保留关键信息，又能控制输入长度。
• /dream 命令每 7 天自动执行一次，合并重复记忆、验证路径有效性、剔除已关闭的任务，相当于对记忆进行一次“磁盘整理”。

开发者该如何正确使用：善用机制，而非依赖幻觉

所谓的“无限上下文”并非鼓励你将一个 50MB 的代码库直接扔给它便等待结果。其真正价值体现在持续迭代过程中——你今日修改接口，明日调用它，后日添加测试，它都能把握住上下文脉络。前提是：你需要让它“参与过程”，而非只给出最终需求。

• 启动长任务时，使用 /start project-name 明确声明项目上下文，帮助 Writer 初始化记忆锚点。
• 将关键设计决策、命名约定、TODO 清单主动写入 notes.md（主 Agent 唯一可写区域），这些内容将自动纳入下次 rebuild。
• 避免在单次 prompt 中堆砌所有背景信息——应当逐步交代项目结构、已有逻辑和当前目标，系统会自动串联起来。
• 如果发现某轮输出偏离前期共识，无需重新开始对话，可直接使用 /recall 查看最近的 checkpoint 摘要，随后发送指令进行纠正。

当前仍存在的局限性

再精细的工程方案也存在实际限制。MiMo Code V0.1.0 在记忆使用方面仍有以下几个明显的边界：

• 跨项目记忆不共享——每个 project-name 对应独立的 memory 目录，切换项目相当于重置记忆，目前尚无全局知识图谱。
• 非结构化文本（例如大段日志、未经解析的错误堆栈）可能会被 Writer 忽略，需要手动标注重点片段。
• 本地部署时若关闭持久化存储（如禁用 ~/.mimo/memory），checkpoint 将退化为内存缓存，重启后即消失。
• 多用户共享同一终端环境时，若 memory 目录权限未隔离，存在交叉污染的风险。