• 性质：对话沉淀为可复用 Q&A（无独立 source/_posts 剪藏）。
  • 日期：2026-06-23

问题背景

看到 Codex 本地的 MEMORY.md 内容很多，容易把它理解成「本地缓存命中」：以前问过的问题，之后就直接从缓存里拿答案。

这个理解有一部分是对的，但如果把它当成普通缓存，就会误判它在 agent 工作流里的作用。

1. 它是不是本地缓存命中？

可以部分这么理解，但不准确。

MEMORY.md 的作用更像一个长期工作记忆索引，而不是把历史内容全文塞进上下文、命中后直接复用答案。

它主要帮助 agent 快速判断：

  • 这个问题以前是否处理过类似链路；
  • 应该优先查看哪些文件、模块或命令；
  • 用户在某个项目里的稳定偏好是什么；
  • 哪些历史结论可能有用，但需要重新验证。

2. 它和普通缓存有什么不同？

普通缓存通常追求「输入相同，直接返回已有结果」。但 Codex memory 更接近「路由线索」：

对比项 普通缓存 Codex memory
主要目标 复用结果 缩小探索范围
命中后动作 直接返回或直接使用 继续读取当前文件和上下文
适合内容 稳定计算结果 项目偏好、历史路径、常见入口
风险 缓存过期 记忆过期或场景迁移错误

所以它不是「命中后直接执行」，而是告诉 agent：从哪里开始查更可能快。

3. 实际使用流程

典型流程是：

  1. 先看压缩摘要，判断是否可能相关；
  2. 按关键词检索 MEMORY.md；
  3. 只有命中明确条目时，才打开对应 rollout、skill 或历史记录；
  4. 回到当前仓库，以当前文件、命令和运行结果为准。

这和 LLM 维护的知识库 的思路接近：持久化材料负责降低重复探索成本，但不能替代当前验证。

4. 什么时候可以信 memory？

适合信的部分：

  • 用户长期偏好；
  • 项目常见入口；
  • 之前踩过的坑；
  • 某类问题的排查路径。

需要重新验证的部分：

  • 当前代码实现；
  • 命令输出；
  • 依赖版本；
  • 文件路径；
  • 最近改动后的行为。

尤其是代码仓库会不断变化，memory 里的历史结论只能当作线索，不能当作现状。

一句话总结

Codex memory 更像是「本地长期工作记忆 + 检索索引 + 历史经验路由」，不是「缓存命中后直接返回答案」。

另见

Query 草稿：Codex 整理本轮讨论；2026-06-23。