Agentic AI 系统中的长期记忆
过去一年里，我陆续做过几个 AI Agent 相关的项目，从简单的对话助手到带工具调用的 Agentic AI 系统。一个成熟的 Agentic AI 系统当然不只是模型推理能力，它需要工具编排、状态管理、反馈闭环，甚至一定程度的自治能力。但真正进入生产环境后，我意识到一个更底层的问题：如果没有长期记忆，AI Agent 本质上只是无状态的一次性工具。它记不住用户的偏好，记不住过去的决策，更无法从历史结果中学习。在真正可用的 Agentic AI 系统里，长期记忆 (Long Term Memory) 不是锦上添花，而是决定系统是否具备长期进化能力的基础设施。
1. 为什么 AI Agent 需要长期记忆？
在单轮对话场景下，LLM 的能力已经足够强大。很多时候，我们只需要一个 prompt，就可以完成写作、总结，甚至复杂推理。但当 AI 从一次性的对话工具，演变为持续多轮运行的 Agent 时，问题就完全不同了。
一个真正运行在生产环境里的 Agent，不只是完成任务，它需要在时间维度上持续存在。它要面对同一个用户多次发出的请求，要在不同阶段做出决策，要在反馈中调整行为。
如果没有长期记忆，每一次与 Agent 的交互其实都是重新开始。用户表达过的偏好会被遗忘，过去的决策无法复用，失败的经验也不会转化为系统的改进。所谓的用户个性化 (personalization) 只能停留在当前会话里，无法跨时间跨 session 延续。
没有记忆的 Agent，本质上只是一个无状态工具；有记忆的 Agent，才有可能成为一个长期协作甚至动态演进的系统。
2. 什么是 AI Agent 的记忆？
当我们讨论 Agent 的长期记忆时，首先要搞清楚一个问题：什么是 AI Agent 的长期记忆？
短期记忆 (Short-Term Memory, STM) 很好理解，它是 Agent 在当前任务或当前会话中暂时持有的上下文状态，比如当前的对话信息。但是短期记忆是暂时的 (Ephemeral)，在会话结束就会被丢失。
长期记忆 (Long-Term Memory, LTM) 是跨任务、跨会话、可持久化的状态存储，用来保存会在未来影响用户决策的信息。它可以被复用，并且是实现系统个性化的关键。
它并不只是保存聊天记录，也不是简单地把所有信息丢进向量数据库或者DDB。真正有意义的记忆，是那些会在未来影响决策的信息。
借鉴认知科学的划分，Agent 的长期记忆通常可以分为三种类型：
语义记忆（Semantic Memory）
这是关于事实 (facts) 的记忆。它包括用户的稳定属性、明确表达的偏好，以及长期有效的信息。例如用户的时区、写作风格、业务约束等。这类记忆更新频率不高，但一旦出错，会长期影响系统表现。情景记忆（Episodic Memory）
这是关于过往经历 (past experience) 的记忆。它记录过去发生过的事情，以及当时的上下文和结果，例如一次工具调用的输出、一段关键对话、一次失败的决策或用户反馈。这类记忆数量往往较多，也更容易产生噪声，因此通常需要筛选和摘要。程序记忆（Procedural Memory）
这是关于行为规则 (rules / constraint) 的记忆。它体现为规则、约束和行为策略。在很多 LLM 系统中，它可能存在于 system prompt、工具使用说明或者一些写在系统 markdown 中的 guardrails。程序记忆决定了 Agent 的行为边界，是系统稳定性的核心。
当我们把这三种记忆区分开来，问题其实就变得清晰很多：哪些信息属于长期事实？哪些属于可参考的历史？哪些属于行为规则？
3. 长期记忆库里应该存什么？
当我们决定为 Agent 引入长期记忆之后，一个更关键的问题就出现了：什么信息值得被记住？
AI Agent 和人类一样，更多记忆并不意味着更好表现。如果我们不管三七二十一，把所有信息所有原始对话记录都扔进长期记忆库，记忆中的大量噪声反而会干扰 Agent 的判断并产生很多的幻觉 (hallucination)。这点已有大量研究证明，比如 Lost-in-the-Middle Effect 或者 RAG 中的检索噪声问题。
所有，真正重要的不是存多少记忆，而是选择有效的记忆。
一个更合理的原则是：
只存储那些会在未来影响决策的信息。
从这个角度出发，长期记忆中通常会包含几类内容：
长期有效的用户事实或偏好
例如写作风格、优先级规则、固定业务约束等。这类信息通常比较稳定，一旦确定，就会持续影响后续行为。关键决策及其结果
某种策略是否有效？某次操作是否成功？失败是否暴露了系统限制？这些都属于情景记忆的重要来源。它们的价值不在于事件本身，而在于对未来决策的参考意义。经过多次交互推断出的长期倾向
有些信息并非用户明确表达，而是系统在多次交互中逐渐观察到的，例如用户更偏好简洁回答，或更关注成本而非性能。这类信息通常需要设置信心阈值，避免过早写入。
与此同时，记忆的遗忘同样重要。如果 Agent 把所有对话和行为永久保存，记忆很快就会变成负担。一个成熟的长期记忆系统，往往需要具备筛选、压缩甚至衰减机制，让不再重要的信息逐渐淡出。
设计长期记忆时真正困难的，不是“如何存储”，而是“是否应该存储”。
4. 什么时候读取 / 写入长期记忆？
上一节探讨了长期记忆“存什么”的问题，在真实生产环境中，一个更实际的问题是长期记忆“什么时候用”？
什么时候读取？
通常发生在以下场景：
- 新一轮交互开始时
- 需要做重要决策之前
- 调用关键工具之前
但读取并不意味着加载全部记忆。合理的做法是根据当前任务进行有选择的检索，让相关信息进入上下文，而不是让历史记忆淹没当前决策。
什么时候写入？
在实践中，长期记忆的写入通常有两种机制：
Hot Path（同步写入）
在 Agent 主循环中直接更新记忆。实现简单、一致性强，但会增加服务的延迟，并可能写入未经筛选的低质量信息。Background（异步写入）
主 Agent 只发出“记忆信号”，由后台 (可以是另一个 agent) 进行整理、总结和存储。这种方式可以降低延迟，并对记忆进行质量控制，但系统复杂度更高。
在多数实际系统中，更合理的做法是采用混合模式：
对用户明确表达的长期偏好使用同步写入，对需要总结或推断的信息使用异步机制，同时在写入前进行置信度判断和去重处理。
长期记忆并不是简单的存储组件，而是 Agent 架构中的一个独立层级。它既影响性能，也影响系统稳定性，更决定了 Agent 是否具备长期演化的能力。
5. 一个带长期记忆的简单 Agent 示例
前面聊了长期记忆的概念和设计原则，如果只是停留在理论层面，总感觉有点“纸上谈兵”。不如让我们 get hands dirty，来做一个带长期记忆的简单对话 Agent，它大概会长什么样？
想象一个简单的 AI 聊天助手。如果没有长期记忆，这个助手每次对话都像第一次见面 —— 你刚刚说过的话、表达过的偏好、甚至刚刚做过的决策，都会在下一轮对话中被彻底遗忘。某种程度上，这样的 Agent 更像是一个“健忘但聪明”的工具。
但如果给它加上长期记忆，事情就开始变得有意思了。这个 Agent 可以记住你喜欢简洁的回答风格，也可以记住你曾经否定过某种方案，甚至可以逐渐形成对你工作习惯的理解。随着时间推移，它不再只是回应问题，而是在逐渐“懂”用户。
从工程角度来看，这个 AI Agent 其实并不复杂。每一轮对话，Agent 只需要做几件事情：先从长期记忆库里找找有没有相关信息，然后筛选出真正有用的部分，再生成回复。等对话结束后，再判断这一轮有没有值得长期保存的新信息新记忆，如果有，就写回长期记忆库里。
这样，一个完整的长期记忆循环就形成了：
- Retrieve memory
- Distill memory
- Use memory
- Write memory
用流程图表示，大概是这样的：
检索记忆 + 记忆蒸馏：当用户输入到来时，Agent 会先从长期记忆库中检索可能相关的信息。但这些检索结果往往包含噪声，因此下一步会对这些检索出的记忆进行一次记忆蒸馏 (distillation)，筛选出真正有用的部分，再注入到当前上下文中。
提取新的记忆：在生成回复之后，Agent 会试图提取记忆，也可以理解为是再进行一次 记忆蒸馏 (memory distillation)，不过这一次是针对当前对话。Agent 会判断这一轮交互中是否出现了值得长期保存的信息，比如用户表达的偏好、约束条件，或者新的事实。
存储长期记忆：如果有新的长期记忆，就写入长期记忆库 (Long Term Memory Store)；如果没有，这一轮流程就结束。
这个过程就像是一个“记忆循环”：Agent 一边读取记忆来辅助当前回答，一边从新的对话里提炼出未来还会有价值的信息以供之后的轮次使用。
长期记忆的价值，就在于它能改变 Agent 之后的行为。随着时间推移，Agent 的行为会变得更加稳定和个性化，它会慢慢变得像一个“懂你”的老朋友。
拿我制作的这个简单的 chat agent 来说，长期记忆 (Long Term Memory) 的效果很容易观察。
最开始，长期记忆库里什么都没有：
1 | LTM Agent Started: |
这时候 Agent 只能基于当前问题回答，因此给出了一个很普通、甚至不符合我饮食习惯的建议。
接着，我在对话中表达了一个饮食偏好：
1 | You> I am vegetarian |
这里最关键的不是回复本身，而是 记忆蒸馏 (distill_new_memory) 这一步。它说明 Agent 没有把这句话当成一次普通闲聊，而是识别出“用户是素食主义者”是一个未来可能持续有用的事实，于是把它写进了长期记忆库。
我们来看一下这时长期记忆库里有什么
1 | { |
到了下一轮，这条记忆就开始真正发挥作用了：
1 | You> /show_ltm |
这一次，我并没有重新说明自己的饮食偏好，但 Agent 在检索记忆 (retrieve_memory) 阶段取回了之前保存的那条长期记忆，于是回答自然就变成了素食选项。也就是说，有了长期记忆之后，Agent 在新的轮次里能够主动把过去提炼出的用户偏好拿来辅助回答，这就是一个简单的具有个性化和持续进化能力的 Agent 的例子。
以上带有长期记忆能力的 Chat Agent 的代码示例放在了这个代码仓库中 https://github.com/yanshengjia/artificial-intelligence/tree/master/langgraph-agent-with-long-term-memory
6. 长期记忆的生命周期
到这里，我们已经讨论了如何为 Agent 引入长期记忆，以及如何在每一轮对话中读取和更新记忆。但当系统真正运行一段时间之后，一个新的问题很快就会出现：长期记忆会越来越多。
直觉上，我们可能会认为记忆越多越好。毕竟，Agent 记住的越多，似乎就越“聪明”。但在实际系统中，情况往往恰恰相反。随着记忆不断积累，检索噪声开始增加，相关性变得模糊，甚至会出现互相冲突的记忆。久而久之，Agent 不但没有变得更聪明，反而更容易做出不稳定的决策。
这也是为什么长期记忆不仅需要“写入”，还需要“管理”。一个成熟的长期记忆系统，通常需要考虑以下几个方面：
Memory Pruning
随着时间推移，一些记忆可能不再有价值。例如一次性的对话信息、已经过时的偏好，或者被更准确记忆替代的旧信息。这些记忆需要被定期清理，否则长期来看只会增加噪声。Pruning 通常由系统自动执行，例如根据时间、置信度或使用频率进行裁剪。Memory Update
用户的偏好并不是一成不变的。一个用户可能今天偏好简洁回答，明天又希望更详细的解释。如果系统只是一味追加记忆，而不更新已有信息，很快就会出现冲突。因此，长期记忆往往需要支持更新，而不是只追加。Memory Deletion
与 pruning 不同，memory deletion 更多是由用户主动发起的。例如用户可能希望“忘记我刚才说的偏好”，或者清除某些不再希望被记住的信息。这不仅是用户体验的一部分，也关系到系统的可控性和信任度。
从某种角度来看，长期记忆更像是一个“活的系统”，而不是一个简单的存储组件。它需要不断积累，也需要适时遗忘。
这其实也和人类的记忆机制非常相似。我们不会记住所有事情，而是不断筛选、压缩、甚至遗忘信息。正是这种动态的记忆管理，让我们能够在复杂环境中保持高效决策。
对于 Agent 来说也是一样。存储更多记忆并不一定带来更好的效果，关键在于如何管理这些记忆的生命周期。只有当长期记忆能够被有效维护时，Agent 才能真正具备持续进化的能力。