MiMo Code MiMo Code 是一个开源终端 AI 编码代理，具备显式长期记忆架构，适用于复杂长期任务，通过独立检查点管理上下文并执行沙盒工作流。 热门评论 PH 用户大家好！MiMo Code 基于 @opencode，但在处理长时间运行的会话上下了更多功夫。它不让主智能体自己管理内存，而是用一个独立的 writer 子智能体，按计划定期写入结构化的 checkpoint。一个关键设计是，这些 checkpoint 会在相对早期就被触发，远在上下文窗口填满之前。这样就避免了在高上下文压力下做大量压缩。当窗口最终接近上限时，系统会从累积的 checkpoint 和项目记忆重建工作上下文，而不是依赖越来越不可靠的摘要。它还会在后台运行进程，从过去的工作中持续提取可复用的模式。PH 用户提前做 checkpoint 这个思路很合理：在上下文还健康的时候做摘要，而不是窗口已经压力山大时再搞。我担心的难点是负面记忆。如果某个 checkpoint 在一次长时间重构中捕获了一个错误假设，MiMo Code 如何防止它被提升为持久化的项目记忆？你们是否会把任务本地的 checkpoint 与可复用的 MEMORY.md 风格知识分开，直到后续验证通过？PH 用户角度有意思。对于智能体记忆，我想看到的是它如何保持可审查性：记住了什么、什么可以重置、以及开发者如何判断旧上下文何时弊大于利。PH 用户checkpoint 子智能体这个想法最吸引我。长时间编码智能体在上下文管理不显式时就会崩溃。你们是如何决定哪些内容写入长期记忆、哪些保留为任务本地状态的呢？PH 用户长时间的编码会话通常因为上下文压缩得太晚而崩溃。独立的 checkpoint 子智能体感觉是一个实用的修复方案：少一些魔法，当任务持续数小时时记忆更可靠。PH 用户编码智能体中的长期记忆是最难的部分。当一个函数在10个文件中被重构时，MiMo-Code会自动更新其存储的理解，还是需要手动让过时的上下文失效？ 热门产品Zac Zuo2026-06-15原文 打开互动版
MiMo Code 基于 @opencode，但在处理长时间运行的会话上下了更多功夫。
它不让主智能体自己管理内存，而是用一个独立的 writer 子智能体，按计划定期写入结构化的 checkpoint。
一个关键设计是，这些 checkpoint 会在相对早期就被触发，远在上下文窗口填满之前。这样就避免了在高上下文压力下做大量压缩。
当窗口最终接近上限时，系统会从累积的 checkpoint 和项目记忆重建工作上下文，而不是依赖越来越不可靠的摘要。
它还会在后台运行进程，从过去的工作中持续提取可复用的模式。
我担心的难点是负面记忆。如果某个 checkpoint 在一次长时间重构中捕获了一个错误假设，MiMo Code 如何防止它被提升为持久化的项目记忆？你们是否会把任务本地的 checkpoint 与可复用的 MEMORY.md 风格知识分开，直到后续验证通过？