Agent 记忆

模型在两次调用之间没有记忆。一点都没有。每个请求都是全新的。

所以，你用过的每一个记忆功能，本质都是检索：有东西被存在模型之外，在后续请求中再放回上下文窗口。设计问题不是模型怎么记住，而是存什么，以及什么时候取回什么。

四种类型

它们的用途不同，存活时间也不同。

工作记忆——当前的对话记录，也就是 agent 循环中不断累积的消息列表。只持续一个任务，上限由上下文窗口决定。

情景记忆——过去会话里发生过什么，比如「上周你帮我调试过 auth 服务」。按与当前情境的相关性检索。

语义记忆——持久的事实，比如「用户偏好 TypeScript」「生产环境跑在 eu-west-1」。量小、稳定，通常每次请求都加载。

程序性记忆——学到的方法，比如「先查迁移日志，通常就能找到这类 bug」。最难做好，一旦奏效价值也最大。

大多数系统只需要前三种。第四种基本还在研究阶段。

工作记忆是眼前的问题

agent 跑得久，就会耗尽上下文窗口；而每轮迭代都要把整份对话记录重新发一遍——成本因此按平方增长。四种应对方式，按投入从小到大：

**截断。**保留近期消息，丢掉旧的。实现很简单，但一不小心就会把目标说明悄悄丢掉。务必显式保留任务描述。

**摘要。**定期把旧历史压成一段摘要。能拉长可用的时间跨度，但会丢掉细节，而且压缩过程中的信息损失你无法预测。

**精简工具返回结果。**性价比最高的做法，远超其他。一个工具本该只返回 200 token 却返回了 10,000 token，会污染之后的每一轮迭代。只返回标识符，让 agent 按需去取细节。

**外部化。**让 agent 把发现写进一个自己能重新读的文件或草稿区。对话记录保持简短，状态存在它之外。工程量更大，却是唯一真正能撑住长任务的做法。

跨会话记忆

真正管用的做法一点也不花哨：把记忆存成文本并配上 embedding，每次请求检索出相关的那几条，注入上下文。

这就是在 agent 自己的历史上做 RAG，所有检索层面的问题原封不动地适用——分块、混合检索、重排序。

有没有用，取决于三个决定。

**写什么。**什么都写会让检索充满噪声。两个选择：让模型自己判断什么值得记，灵活但不稳定；或者按既定触发器写入——用户明说的偏好、纠正、已解决的问题——可预测但会漏掉东西。以触发器为准是更好的默认做法。

**什么时候取。**语义事实体量小，每次都能全量加载。情景记忆则应按相关性检索，而且取太多比不取更糟：不相关的记忆会稀释注意力，偶尔还会被真的用上。

**什么时候忘。**这一步所有人都跳过。记忆会过期、会互相矛盾、会越积越多。没有过期机制或冲突消解，agent 的记忆就会变成主动误导——它会信心十足地套用一个用户几个月前就改掉的偏好。给所有内容打上时间戳，冲突时取新的，把一直没用上的清掉。

哪里会出问题

**过期的记忆被自信地套用。**破坏力最大的一种失效。记忆一旦进入上下文，模型就把它当成当前事实。

**矛盾。**两条记忆互相打架，没有东西来裁决。存时间戳，优先取更近的。

**检索噪声。**注入十条勉强相关的记忆会拉低输出质量。少而精。

**隐私累积。**什么都记的 agent 会攒出一份关于用户的长期画像。这会带来实实在在的数据处理后果：用户应当能看到存了什么并删掉它，记忆内容应当按个人数据对待。

**把记忆当作不可信输入。**记忆里若含有形似指令的文本，就是一个提示注入通道——当记忆可以由工具返回结果或用户内容写入时尤其如此。

实际形态

对大多数应用来说：一份简短的显式语义事实清单，每次请求都加载；加上情景记忆的相关性检索；再加上对工作记忆的激进压缩。

从最简单的版本起步——存一份用户偏好清单——等你指得出某个具体失效、而检索能修好它时，再加检索。复杂的记忆架构通常是在解决这个应用压根没有的问题。

要点回顾

• 模型没有记忆；一切都是检索，把内容取回上下文窗口。
• 四种类型：工作记忆（当前对话记录）、情景记忆（过去的会话）、语义记忆（持久事实）、程序性记忆（学到的方法）。
• 工作记忆：先精简工具返回结果，再把状态外部化到文件。
• 跨会话记忆就是在 agent 的历史上做 RAG——决定写什么、什么时候取，以及什么时候忘。
• 过期记忆是最糟的失效模式；给所有内容打时间戳，并激进地清理。

下一篇： 上下文工程