和 Agent 聊了半小时，把任务背景、约束、偏好都讲清楚了。关掉窗口重新打开，它全忘了，又从「你好，有什么可以帮你」开始。这种「金鱼记忆」是最让人崩溃的 Agent 体验之一。
记忆是 Agent 从「一次性工具」走向「长期助手」的关键能力。没有记忆，Agent 每次都从零开始，无法积累对你的了解，无法复用历史经验。有记忆，它能记住你之前说过什么、偏好什么、上次任务进行到哪了，交互体验是质的飞跃。这篇讲 Agent 的记忆系统怎么设计。
先分清两种记忆
图：短期记忆在 context window 里即时可用，长期记忆在外部存储里需要检索才能取用。
人的记忆分短期和长期，Agent 也一样，而且这个区分对工程实现是关键。
短期记忆是当前对话的上下文。用户说了什么、Agent 回了什么、中间调用了什么工具、得到了什么结果。这些信息在对话进行时全部放在 LLM 的 context window 里，作为模型推理的输入。
短期记忆的特点是「即时但有限」。它能马上用上，但受 context window 大小限制。对话一长，早期的内容要么被截断，要么需要压缩。怎么管理这个有限的窗口，是短期记忆工程化的核心。
长期记忆是跨对话的持久信息。用户的偏好、历史任务的结论、学到的知识。这些信息不放在 context 里（放不下也浪费），而是存在外部存储里，需要的时候检索出来。
长期记忆的特点是「持久但需要检索」。它能跨越对话存在，但不能直接用，要先用某种方式把相关的记忆找出来。向量检索是最常用的「找」的方式，这也是为什么记忆系统和 RAG 的底层技术高度重合。
短期记忆，管理有限的 context window
图：当 context 超长时，滑动窗口、摘要压缩、选择性保留三种策略组合，让最相关的信息留在模型可见范围。
短期记忆的工程难点是，context window 是有限的，但对话可能很长。
最简单的策略是滑动窗口，只保留最近 N 轮对话。简单有效，但问题是早期的重要信息会丢失。用户在第一轮说的约束条件，到第十轮可能就被挤出窗口了，Agent 就开始「忘记」之前的要求。
更好的策略是摘要压缩。对话进行到一定长度，用一个 LLM 调用把前面的内容压缩成摘要，摘要替代原始对话留在 context 里。这样既保留了关键信息，又控制了 context 长度。代价是摘要可能丢细节，而且额外的 LLM 调用有成本和延迟。
还有一种策略是选择性保留。不是所有信息都同等重要，关键的事实、决策、约束要保留，寒暄、重复、无关内容可以丢弃。用一个轻量模型判断哪些值得留，能更高效地利用有限的窗口。
实际系统通常是这几种策略的组合。滑动窗口保近期，摘要保中期，关键事实提取出来长期留存。目标都是同一个，在有限的 context 里，让最相关的信息留到模型能看到的范围里。
长期记忆，存下来还要找得到
图：长期记忆的写入和检索就是一个小型 RAG——向量化、存、检索这套技术栈完全通用。
长期记忆要解决两个问题，怎么存，怎么找。
存什么。用户的偏好和画像（喜欢简洁回答、用 Java 技术栈）、历史任务的结果（上次帮用户做的分析结论是什么）、学到的事实（用户的项目用 pgvector 做向量检索）。这些信息有价值，但没必要每次都塞进 context，需要时检索出来就行。
怎么存。最常见的是向量化存储，把每条记忆转成向量存进向量库。记忆说到底就是一段文本，向量化后可以按语义检索。这和 RAG 的技术栈几乎完全一样，所以会做 RAG 的团队，做长期记忆是驾轻就熟的。
怎么找。用户问了一个问题，或者 Agent 需要历史信息时，把当前的问题或需求向量化，在记忆库里找语义最相关的几条，塞进 context。这就是一次小型的 RAG 检索。
这里有个关键设计，什么时机检索。一种是在每轮对话开始时，根据用户输入检索相关记忆。一种是 Agent 在推理过程中，主动判断「我需不需要查历史记忆」，需要时才检索。后者更智能但更复杂，前者更简单也更常用。
记忆的更新和遗忘
记忆不是只增不改的，它会更新、会过期、会被遗忘。
更新。用户的偏好变了，旧的偏好要覆盖。之前以为的事实被纠正了，错误记忆要修正。记忆系统要有更新的机制，不能只追加不修改，否则记忆库里会堆满矛盾的旧信息。
过期。有些记忆是有时效的，比如「用户当前在做项目 X」，项目做完了这条记忆就没用了。要有机制识别和清理过期记忆，否则无关的旧记忆会污染检索结果。
遗忘。这听起来像个 bug，其实是个 feature。人的记忆会遗忘是有道理的，如果什么都记得，检索的时候会被海量无关信息淹没。Agent 的记忆也一样，无关紧要的要忘掉，重要的才保留。实现上可以是「访问频率低的记忆降权」，长期不被检索到的记忆慢慢沉下去。
记忆系统的工程挑战
把记忆系统做稳，有几个真实的工程挑战。
相关性判断。检索回来的记忆不一定都该用。用户问「天气怎么样」，你检索出他三年前说过的一句话，塞进 context 就是噪音。要有一层过滤，判断检索到的记忆在当前场景下值不值得用。
记忆污染。错误的记忆一旦存进去，会反复被检索出来误导 Agent。比如 Agent 记住了一个错误的事实，每次相关检索都把它带出来，Agent 就会一直基于这个错误信息回答。记忆写入要有一定的质量把关，不能什么都存。
隐私和权限。记忆里可能有敏感信息，谁能看到、存多久、怎么删除，都要考虑。尤其涉及用户数据的合规要求，记忆系统不能是个无法清理的黑洞。
一致性。短期记忆和长期记忆可能冲突。用户这轮说了一个和长期记忆里不一样的偏好，以哪个为准。一般以最新的为准，但要把长期记忆更新过来，否则下次又用旧的。
没有（好的）记忆系统的 Agent，每次交互都是一次性的，用户要把背景重新讲一遍，体验很差。有记忆系统的 Agent，能积累对用户的了解，越用越顺手，用户粘性完全不同。这也是为什么记忆系统虽然工程复杂，但值得投入，它是 Agent 从「工具」变成「助手」的关键一跳。
记忆和 RAG 的关系
如果你已经理解了 RAG，记忆系统其实不难理解，因为底层技术高度重合。
长期记忆的存储和检索，说到底就是一个 RAG 系统。记忆库就是知识库，记忆检索就是文档检索。RAG 里踩过的坑（切块、Embedding 选型、召回率、重排），在记忆系统里一样会遇到。
区别在于，RAG 检索的是相对静态的文档，记忆检索的是动态增长的交互历史。记忆的写入更频繁，更新和遗忘的需求更强，对实时性的要求也更高。但核心的「向量化、存、检索」这套技术栈，是完全通用的。
所以做好 RAG 的团队，做记忆系统有天然优势。反过来，把记忆系统做扎实的团队，做 RAG 也是同样的思路。这两个领域的底层是连通的，理解了一个，另一个就是换了个应用场景的同一套技术。
