AI编程助手存在"失忆"问题：记忆增强生成技术解析

周五，你花了四十分钟向 Codex 介绍你的项目。你解释过后端用的是 PostgreSQL，测试套件必须用 make test-fast 来运行，因为完整套件要跑二十分钟，还有 payments 模块很脆弱，没有工单绝对不能重构。之后的整个会话中，Codex 都表现得非常出色。

到了周一，你打开一个新会话。Codex 建议重构 payments 模块。它跑了完整测试套件。它问你用的什么数据库。

没有任何东西出错。这就是设计本身。大型语言模型是 stateless 函数：模型对你项目"已知"的一切都存在于当前会话的上下文窗口中，而当会话结束时，那个上下文就被销毁了。周五那四十分钟的上下文并没有退化或丢失。它从未存在于任何地方——除了一个已经不存在的缓冲区中。

本文要讲的是为解决这一问题而构建的一类技术——名为 Memory-Augmented Generation（记忆增强生成，MAG）——以及 OpenAI 的 Codex 在实践中是如何实现它的。

为什么上下文窗口不够用

一个显而易见的质疑是：现在的上下文窗口已经很大了，为什么不把所有东西都放在上下文中？

首先，上下文本是按会话隔离的。即使有一百万 token 的窗口，如果周五的会话消失了，周一也帮不上你。窗口大小解决的是容量问题，不是持久化问题。

其次，长上下文会退化。注意力效果随距离衰减，这种失败模式被记录为"中间迷失"现象：模型可靠地使用长上下文开头和结尾的信息，但会遗漏埋在中间的信息（Liu et al., 2024, https://arxiv.org/abs/2307.03172）。把你整个项目历史塞进上下文不仅昂贵，而且不可靠。

第三，上下文是不加区分的。一份 transcript 包含所有内容：有用的架构决策和之前十四次失败的尝试。你真正想要传递的是蒸馏后的事实（"我们选择 SQLAlchemy 2.0 风格是因为 X"），而不是产生它的原始日志。

记忆增强生成（Memory-Augmented Generation）为 LLM 增加了外部记忆系统，可以在会话之间持久化，并且被主动管理：写入、整合、检索和修剪。这一术语在 MemOS 论文（Li et al., 2025, https://arxiv.org/abs/2505.22101）中得到形式化，该论文认为记忆应该是 LLM 第一等的架构关注点，而不是事后才想到的东西，并将三种记忆类型加以区分：参数记忆（嵌入权重的知识）、激活记忆（短暂的运行时上下文）和明文记忆（外部的、可编辑的知识）。同一谱系的早期工作包括 MemGPT（Packer et al., 2023, https://arxiv.org/abs/2310.08560），它将 LLM 视为一个操作系统，在小的"主上下文"和更大的外部存储之间分页数据。

理解 MAG 最有效的方式是通过对比你已经熟悉的模式：检索增强生成（RAG）。

RAG 做检索。MAG 做记忆。RAG 在查询时从静态外部语料库中拉取相关片段；语料库不会从交互中学习任何东西。MAG 增加了一条写入路径和生命周期：系统决定从一次交互中值得保留什么，将其与已有知识合并，之后检索它，并最终遗忘不再有用的东西。

右侧的循环是定义性特征。一个只有只读向量数据库的 RAG 系统不是在做 MAG，无论检索做得多复杂。MAG 需要写入、整合和遗忘阶段。修剪是作为后台扫描在存储上运行，而不是内联在循环中——这在我们后面看 Codex 如何调度它时会很重要。

一个需要谨慎读者的术语提示：MAG 是一个新兴术语，不是像 RAG 那样已经确立的标准。业界大部分仍在说"agent memory"，还有一个独立的框架叫 MMAG（Mixed Memory-Augmented Generation，Zeppieri, 2025, https://arxiv.org/abs/2512.01710），它将 agent memory 组织成五个认知层。不要混淆两者。

案例研究：Codex 如何记忆

Codex 是 OpenAI 的编码 agent，它配备了两层记忆模型，几乎完美地映射到上面的静态与生命周期区分。两层都在 https://developers.openai.com/codex 有文档。

第一层：AGENTS.md，静态层

AGENTS.md 是一个 markdown 指令文件，Codex 在每个会话开始时都会读取它。它遵循跨工具开放约定（https://agents.md），也被 Cursor、Aider 等工具使用。Codex 按层级发现这些文件：从 ~/.codex/AGENTS.md 的全局文件开始，然后是从仓库根目录到工作目录下每个 AGENTS.md，按路径顺序拼接。

这一层用于稳定的事实：测试命令、部署流程、代码风格规则、哪些模块是脆弱的。它受版本控制、可在团队间共享，完全处于人类控制之下。

严格来说，它也不是记忆。它是配置。人类编写它，人类维护它，而且它只捕获有人记得写下来的东西。周二下午你发现的 Redis 怪癖不会出现在 AGENTS.md 中，除非你手动写进去。而且有一个硬性的实际限制：合并后的文件内容默认被限制在 32 KiB，超过上限的截断是静默的。

第二层：Memories，生成层

第二层是 Codex 实际实现 MAG 的地方。Codex 在后台汇总自己的先前会话，并将结果写入 ~/.codex/memories/，后续会话读取这些内容。注意这一层默认关闭：你必须在 ~/.codex/config.toml 中启用它（参见官方文档中的配置参考）。根据 OpenAI 的文档以及 https://mem0.ai/blog/how-memory-works-in-codex-cli 的分析， pipeline 如下：

有几个设计选择值得注意，因为它们可以推广到 Codex 之外：

整合是异步的。 一个会话必须空闲数小时才有资格被处理。记忆形成发生在离线状态，而不是内联在生成过程中，这保持了交互循环的快速。这反映了更广泛的行业模式——后台"睡眠时间"整合。

两个模型，两种工作。 一个模型从会话中提取候选记忆；第二个模型将候选记忆合并到已有存储中。提取和整合是不同的问题，将它们分离让各自可以独立调优。

遗忘是一种特性。 三十天未被召回的记忆会被修剪。这是 MAG 设计中反直觉的部分：不断增长的记忆存储会降低检索质量并积累过时事实，所以刻意的遗忘反而改进了系统。

存储是纯 markdown，检索用的是 grep。 没有向量数据库。在会话开始时，Codex 整体读取一份整合后的 memory_summary.md（第三方对开源 CLI 的分析认为这次注入的上限大约是 5000 token，这一预算决策与 32 KiB 的 AGENTS.md 上限如出一辙），然后指示 agent 在需要细节时对长格式的 MEMORY.md 执行 grep。这是一个真实的工程权衡：词法检索快速、可预测、可调试（你可以用 cat 查看 agent 的记忆），但它无法匹配措辞与查询不同的已存储事实。基于 embedding 的系统则把这个权衡倒转了过来。

这个实验很简单，但有两个前提条件如果跳过会悄无声息地毁掉它。首先，Memories 必须在 ~/.codex/config.toml 中启用；在默认安装下该功能是关闭的，不会写入任何东西。其次，如果你的账户在 EEA、英国或瑞士，Memories 层在启动时不可用，只有 AGENTS.md 层生效。

搞清楚这些之后：

运行一个会话，以对话方式建立项目特定的事实，而不是通过 AGENTS.md。找一些足够独特可以明确无误的东西，比如一个虚构的内部服务代号。

关闭会话，等待超过空闲窗口（默认六小时）。

检查 ~/.codex/memories/ 并阅读 memory_summary.md。那个事实是否在提取和整合中存活了，以什么形式？

启动一个新会话，问一个需要用到那个事实的问题。检查 Codex 是否未经提示就回忆起来，以及它是否通过 grep 长格式记忆来做到这一点。

有趣的结果不是第四步成功，而是比较你在第一步所说的和第三步写入的内容。两者之间的距离就是提取模型的编辑判断，值得你亲眼看到之后再信任它。

对 MAG 的诚实讨论需要涉及失败模式，因为在 Codex 或任何其他地方这都不是已经解决的问题。

错误的记忆会累积。 如果提取模型在第一周记录了一个误导性的结论，agent 会在第四周自信地应用它。Codex 确实在狭义上提供了溯源：记忆条目可以通过引用块追溯到它们来源的会话文件和行号。缺失的是争议语义。没有机制来标记一条记忆是有争议的或已被取代的；纠正是通过整合隐式发生的，如果确实发生了的话。可追溯性告诉你一条坏记忆从哪里来，但它无法阻止 agent 依据它行动。

过时性。 代码在变；记忆不会自动注意到。说"部署通过 make ship 进行"的那条记忆会在迁移到新部署 pipeline 后继续存在，直到它因长期不用而被修剪，或被更新的会话覆盖。在空窗期，agent 自信地出错，这比无知更糟糕。

无法共享，无法同步。 Codex 的记忆是本地的、按用户生成的状态。第二台笔记本从头开始。新队友除了进入版本控制的 AGENTS.md 的那些内容外，什么也继承不到。这正是外部记忆层（Mem0，以及像 agentmemory 这样的开源项目）存在的意义——通过 MCP 来填补这一空白，代价是增加一个依赖项，对于托管选项来说，还要把你的项目上下文发送给第三方。披露：Mem0 卖的正是这一层，所以它对 Codex 缺口的分析（上面引用过）应该带着这个背景来读。缺口是真实存在的；但其叙述方式是一个销售漏斗。

隐私面。 一个自动汇总你做的一切并写入磁盘的系统，是一个可以记忆秘密的系统。Codex 在 pipeline 中内置了秘密删除，但删除是模式匹配，模式匹配会遗漏东西。

MAG 的认识是：无状态性——这个使 LLM 易于推理的特性——是让它们成为长期有用协作伙伴的主要障碍。Codex 的实现展示了这一模式带来了什么——一个不再问"你用什么数据库"的 agent——以及我们仍然处于多早期的阶段：上述失败模式是开放问题，不是边缘情况。RAG 大约花了三年从 2020 年的论文走到标准实践。记忆看起来走在类似的轨迹上，而那些开放问题正是未来几年工作会发生的地方。

---

参考文献

Li, Z. et al. (2025). MemOS: An Operating System for Memory-Augmented Generation (MAG) in Large Language Models. https://arxiv.org/abs/2505.22101

Packer, C. et al. (2023). MemGPT: Towards LLMs as Operating Systems. https://arxiv.org/abs/2310.08560

Liu, N. F. et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. https://arxiv.org/abs/2307.03172

Zeppieri, S. (2025). MMAG: Mixed Memory-Augmented Generation for Large Language Models Applications. https://arxiv.org/abs/2512.01710

OpenAI. Codex documentation: AGENTS.md guide, Memories, and config reference. https://developers.openai.com/codex

AGENTS.md open specification. https://agents.md

Sangshetti, H. (2026). Codex CLI Memory: How It Works. Mem0 blog. https://mem0.ai/blog/how-memory-works-in-codex-cli (third-party analysis by a vendor selling an external memory layer; used where official docs are thin, with that conflict of interest in mind)

Codex Knowledge Base (2026). Codex CLI Memory Internals: Pipelines, Secret Sanitisation and Intelligent Forgetting. https://codex.danielvaughan.com/2026/04/08/codex-cli-memory-internals/ (third-party analysis of the open-source CLI; source for the citation-block provenance mechanism and the memory summary token cap)