当 Codex 开始记得你偏好的语言、常用验证方式和反复出现的工作流，新任务会少一些重新磨合。但“记得”很容易被理解成“它会自动遵守所有规则”，这两件事并不相同。

Codex Memories 更适合保存跨任务仍然有用的背景与偏好，让后续任务能够从更接近你的起点开始；必须遵守的项目规则、实时变化的外部事实和只对当前任务有效的要求，则各有更可靠的归宿。本文从这条边界出发，梳理 Memories 如何工作，以及它与 AGENTS.md、Skills、MCP 和当前线程应当怎样分工。

Memories 到底记住什么

按照 OpenAI 的 Codex Memories 文档，Memories 是 Codex 在本地生成和使用的一层长期上下文。它不是把每次对话全文永久塞进提示词，而是从适合沉淀的任务中提取稳定信息，再经过整理，供后续任务按需参考。

适合进入这一层的内容，通常具有两个共同特征：跨任务仍然成立，并且能减少重复沟通。例如：

  • 默认使用中文交流，但技术名词可以保留英文；
  • 某个仓库长期使用 Node 22，并以 npm run build 作为基本验证；
  • 用户偏好先整合已有笔记，而不是创建近似重复的新文件；
  • 某类工作已经形成反复出现的步骤与已知陷阱。

与之相对，临时日志、当前分支状态、一次性的路径、刚从网页查到的数据和某个 PR 是否已经合并，都可能很快失效。它们即使在当前任务里很重要，也不一定值得成为长期记忆。

Memories 是辅助回忆层，不是事实与规则的唯一权威来源。它的价值不是让 Codex 无条件相信过去，而是帮助新的任务更快找回可能有用的背景。

它如何生成与存储

Memories 目前是一项默认关闭的实验性能力。启用功能后，Codex 可以在后台从合适的任务中生成记忆；它会跳过仍在活跃的会话和过短的任务，等待系统空闲，并受剩余速率额度阈值影响。官方文档也说明，生成字段会进行敏感信息清理，但仍明确建议不要把 API key、密码等秘密交给 Memories 保存。

主开关可以写在 Codex 的 config.toml 中：

[features]
memories = true

生成的内容属于本地 Codex 状态，通常保存在 ~/.codex/memories/；如果修改了 CODEX_HOME，位置也会随之变化。这里的文件可以检查和清理，却不适合作为需要人工长期维护的第二套知识库，更不应该替代 Git 中的项目文档。

这也意味着，本地 Codex Memories 与 ChatGPT 网页端的记忆不是同一套存储。两者都可能让交互更连贯，但作用范围、配置方式和数据位置不同，不应混为一谈。

使用与生成是两只不同的开关

“让当前任务读取已有记忆”和“让当前任务生成新的记忆”是两个独立动作。全局配置中可以分别控制：

[memories]
use_memories = true
generate_memories = true

前者决定任务能否使用已有 Memories，后者决定任务结束后是否参与新记忆的提取。命令 /memories 则提供当前任务级别的控制，不会悄悄改写全局设置。

读取过去与沉淀现在应当分开判断。例如，一次处理敏感材料的任务仍可能需要使用已有的语言偏好，却不适合把这次任务继续写入长期记忆；一次全新的工作流试验也可能暂时关闭已有记忆，避免旧习惯过早影响探索。

最重要的不是开关，而是分层

Memories 真正容易被用错的地方，不在于配置项，而在于把不同性质的上下文全部交给同一层。一个长期运行的 Codex 工作流，通常至少包含以下几类信息：

层次主要载体最适合保存不适合承担
当前任务Prompt 与本轮输入眼前目标、临时要求、交付范围跨任务长期复用
当前过程Thread已完成步骤、中间判断、连续对话新任务的稳定起点
长期回忆Memories稳定偏好、反复出现的背景和经验强制规则、实时事实、秘密
项目规则AGENTS.md、仓库文档必须遵守的约束、验证方式、目录约定只属于个人的模糊偏好
可复用方法Skills一类任务的步骤、格式知识和检查方法新权限与实时外部数据
实时上下文MCP、网页与其他工具当前文件、服务状态、最新文档与数据未经核验的长期结论
环境设置config.toml功能开关、模型与本机行为项目内容和写作知识
flowchart TB
  Task["当前任务与线程"] --> Agent["Codex 组织与执行"]
  Memory["Memories\n长期背景与偏好"] --> Agent
  Rules["AGENTS.md / 仓库文档\n必须遵守的项目规则"] --> Agent
  Skills["Skills\n可复用的方法与格式知识"] --> Agent
  Live["MCP / Web / Tools\n实时外部上下文"] --> Agent
  Config["config.toml\n本机与功能设置"] --> Agent
  Agent --> Result["经过验证的结果"]

这张图里没有哪一层能够取代其余所有层。Prompt 负责说清这一次要做什么；Thread 保持当前过程连续；Memories 帮助想起长期背景；仓库规则提供可审查的强约束；Skills 沉淀重复任务的方法；MCP 和工具则获取此刻真实存在的文件与外部状态。

如果想进一步理解 Skills 为什么属于“方法层”，可以阅读 AI Agent 的 Skill 是什么：结构、运行机制与概念边界；如果关注 MCP、Skills 与应用控制在知识库中的具体协作，则可以继续看 Codex 操作 Obsidian 的能力分层。

为什么强规则应当写进 AGENTS.md

OpenAI 的 AGENTS.md 文档把它定义为 Codex 开始工作前会读取的项目指令。它可以随仓库进入版本控制，也可以按目录逐层覆盖，因此团队成员和自动化检查都能看到规则何时发生了变化。

这与 Memories 的性质不同。记忆是后台生成的本地状态，可能尚未提取、已经过时、被用户关闭，或没有在这一次任务中使用。如果一条要求关系到数据安全、发布流程、目录结构或构建结果，就不应该只寄希望于“Codex 也许还记得”。

必须稳定执行的要求写进 AGENTS.md 或仓库文档；希望减少重复说明的长期偏好，再交给 Memories。

例如，“回答尽量使用中文”可以是一项个人偏好；“合并前必须运行测试，不得把密钥提交进仓库”则应该成为可见、可审查的项目规则。前者偶尔需要根据语境调整，后者不应依赖一次概率性的回忆。

外部上下文为什么需要单独对待

Codex 还提供 disable_on_external_context 设置，用于避免从使用了 MCP、网页搜索或其他外部上下文的任务中生成 Memories：

[memories]
disable_on_external_context = true

这项设置背后的问题很实际：工具返回的内容未必代表用户的长期偏好。网页中的一句话、MCP 读取到的旧文档、临时环境里的路径，甚至第三方材料中的指令，都可能只对当下有效。如果不区分来源，外部事实就可能被错误概括成“用户一直希望这样做”。

工具给出的事实，不等于用户希望被长期记住的偏好。

是否开启这项设置要看工作方式：如果日常任务高度依赖网页、MCP 和连接器，开启它能减少外部内容进入长期记忆的机会；如果某些稳定工作流恰好只能在工具辅助下完成，则需要接受更少自动沉淀，或在之后通过明确的项目文档补上真正值得留下的结论。

一套更稳妥的使用方式

Memories 不需要承担一切，反而更适合在边界清楚时使用。可以从下面这套流程开始：

  1. 先把强规则写进仓库。 发布流程、安全限制、目录约定和验证命令进入 AGENTS.md 或项目文档。
  2. 只让稳定信息成为记忆候选。 偏好和经验至少应当跨越多个任务仍然成立。
  3. 把实时事实留给工具核验。 当前版本、在线状态、法律与价格等易变化信息，每次使用时重新确认。
  4. 定期检查本地记忆。 发现过时、过度概括或包含敏感信息的内容时及时清理，不把生成结果视为不可触碰的系统文件。
  5. 按任务控制使用与生成。 面对敏感材料、外部上下文或需要刻意摆脱旧习惯的探索任务时，使用 /memories 调整本轮行为。
  6. 让方法进入 Skills。 当某套步骤经过多次真实任务验证，再把它整理为可复用、可检查的工作流，而不是只留下一句模糊偏好。

这种分工看起来多了几层，实际却减少了冲突：规则有明确出处，方法可以版本化，实时事实能够重新查询，Memories 也终于只需要做好它擅长的事——在新任务开始时，帮你少重复介绍一点自己。

结语

Codex Memories 最值得期待的，不是“它什么都记得”，而是它能在不把所有历史对话长期塞进上下文的前提下，保留一部分真正有复用价值的背景。

如果只保留一句总结，可以记成：

把长期偏好交给 Memories，把必须遵守的规则写进 AGENTS.md，把可复用的方法整理成 Skills，再让 MCP 与工具负责核验此刻的事实。

当这些层次各自承担合适的责任，记忆才不会变成另一种不可见的配置债务，而会成为长期协作中安静、但确实有用的一层。

参考资料