先说一个核心判断：MiMo Code 的“无限上下文”并非单纯依赖海量 Token 堆积，而是通过“结构化记忆 + 自动重建”机制支撑起跨文件的逻辑跳转。它不要求模型记住整个项目代码，而是确保系统始终清楚当前任务是什么、执行到哪一步、关联了哪些文件——这才是真正的关键。

当你在 A.ts 修改了一个函数，接着询问“这个函数被哪些组件调用”时，MiMo Code 不会从头扫描整个项目，而是直接从已持久化的记忆中快速定位。此时真正发挥作用的是它的四层记忆体系：

• MEMORY.md：记录项目级别的知识。例如“UserContextProvider 是全局状态入口，所有页面组件都通过它获取用户信息”，这类信息一旦写入，后续跳转就无需反复解析。
• checkpoint.md：保存当前会话的关键状态。比如“正在重构 auth 流程，已修改 login.tsx 和 api/auth.ts”，相当于为用户标记了一条“正在做什么”的进度线。
• tasks/ 目录下的任务日志：明确标注了任务编号和描述，例如“task-042：将 token 刷新逻辑从 AuthGuard 移至 useAuth hook”。每次跨文件操作，日志都会更新，确保用户始终清楚每个任务的边界。
• notes.md：用户手动记录的临时备注，比如“注意：DashboardLayout 的 header 需要兼容暗色模式切换”。这些非结构化的碎片信息，系统也会一并纳入记忆。

拥有这四层记忆后，跳转时就不容易丢失上下文线索。例如你从 src/pages/Home.tsx 切换到 src/lib/utils.ts，再切回 src/features/profile/ProfileCard.tsx，MiMo Code 并非重新加载全部文件，而是执行三项操作：

• 先检测当前 Token 预算余量——如果低于阈值，立即触发上下文重建（rebuild）；
• 然后读取最近的 checkpoint、MEMORY.md 中相关模块描述以及 tasks/ 下未完成项，提取出最关键的上下文；
• 最后动态注入最相关的 3–5 个文件片段——注意，这些片段按语义相关性排序，而非时间顺序或文件路径。同时保留调用链路痕迹，例如“ProfileCard → useUserProfile → fetchUserProfile → api/user.ts”。

说到跨文件关联，SQLite FTS5 全文搜索功不可没。传统的 grep 或 LSP 在模糊语义下容易漏匹配，而 MiMo Code 将所有代码注释、函数签名、commit message，甚至你写过的 notes.md 都索引到 SQLite 的 FTS5 引擎中。这意味着什么？

• 搜索“token refresh”能同时命中 api/auth.ts 中的 refreshToken 方法、useAuth.ts 中的 useEffect 块，以及 notes.md 里你写的“token 刷新需加 retry 机制”——跨文件、跨类型，全部命中。
• 跳转时不只是查找符号定义，还能识别“这个 error handler 实际处理的是 login flow 的 network timeout”这类隐含逻辑——系统会将代码里的语义关联也建入索引。
• 跨文件引用关系自动构建图谱：点击某个 props 类型，可以反向追溯到定义它的 interface、使用它的组件以及测试用例所在位置，比传统的引用查找方便得多。

最后还有一个容易被忽略的点：Writer 子 Agent。主 Agent 在执行跨文件编辑时，自身不维护上下文快照。每次关键操作——比如保存修改、跳转到新文件、确认函数签名变更——Writer 子 Agent 都会同步更新结构化字段，这些字段包括：

• 动作（action）：“refactor function signature”
• 影响范围（affected_files）：["src/hooks/useAuth.ts", "src/api/auth.ts"]
• 设计决策（design_decision）：“将 refreshToken 提升为独立 hook，避免在 AuthGuard 中耦合副作用”
• 错误（error）：“原实现中未处理 401 后的 redirect，已在 useAuth 中补全”

下次你中断后重启，系统不是靠重放对话来恢复现场，而是依靠这些字段重建意图和上下文。跳转逻辑自然就连贯了——哪怕你隔了一天才回来，系统也能知道当时在做什么、进行到哪一步、关联了哪些文件。这才是“无限上下文”的真正底气。