智能体记忆系统：短期记忆与长期记忆

这节我们参考 LangChain 的 Memory 概念文档，梳理智能体记忆系统，包括短期记忆和长期记忆，并进一步了解不同类型的长期记忆及其管理方式。

在 LangChain Memory 一文中，Memory 被定义为一个用来记住先前交互信息的系统。对智能体来说，记忆不仅帮助它接续之前的对话，也能让它利用反馈、适应用户偏好。接下来我们就从它按回忆范围划分的两类记忆开始了解。

先给记忆系统一个定义

智能体的记忆系统，是一套在交互过程中保存、组织和取回信息的机制。它通过短期记忆维持当前会话的连续性，并通过长期记忆让有用的信息跨会话保留；在需要时，系统将相关记忆提供给大语言模型，用于生成回应或完成任务。

因此，记忆系统不只是数据库。它还涉及信息筛选、结构组织、检索、更新和过期清理。LLM 可以帮助提取或整理记忆，但应用需要管理保存范围、读写时机和数据校验。

两种记忆范围：短期与长期

短期记忆：跟随当前会话

短期记忆通常保存同一个会话线程（thread）中的消息历史和任务状态。一个 thread 可以看作一条独立的对话线；它不必等同于浏览器窗口或标签页，具体由应用如何分配会话 ID 决定。

在 LangChain Memory 一文中，短期记忆是 Agent state（状态）的一部分，并可通过与 thread 关联的 checkpointer（检查点机制）持久化。状态除聊天消息外，也可以包含任务进度、上传文件、检索结果或工具调用结果。恢复同一个 thread 时，应用可以读取相应状态继续处理。

检查点机制可以理解为在会话处理过程中，为某个 thread 的 state 保存一份带有标识的进度快照。后续请求带上同一个 thread ID 时，系统就能读取最近保存的检查点，恢复这条会话的消息和任务状态；如果程序中断，也可以从已保存的状态继续。它保存的是应用状态，不是让 LLM 自己记住内容。

同一 thread 的消息与任务状态
          ↓
      Agent state
          ↓
   checkpointer 持久化
          ↓
  后续请求恢复同一 thread

对话历史会不断变长。把全部历史都塞进每次模型请求，可能超过上下文窗口，还会增加耗时和成本，并让旧的无关内容干扰当前任务。应用可以保留最近几轮、总结较早内容，或按任务筛选仍有用的状态。

长期记忆：跨会话保留

长期记忆保存用户或应用层面的信息，可以跨不同会话线程使用。例如，“用户偏好中文解释”可以在之后的新对话中取回。与当前会话的短期记忆不同，长期记忆关注的是哪些信息值得跨会话保留，并在之后的交互中按需取用。

长期记忆不是把全部历史永久放进提示词。系统会针对当前请求查找相关记忆，只把需要的信息提供给模型。还应考虑用户隔离、权限、信息更新和删除。

长期记忆可以保存什么？

LangChain 文档借用三种常见记忆类型来描述长期记忆的内容。它们不是和“短期、长期”互斥的另一套存储，而是回答“记忆里保存什么”。

例如，“用户喜欢 Java 示例”是事实，属于语义记忆；“上次成功处理某个退款问题的步骤”是一次经历，可作为情景记忆；“退款前必须检查政策”是规则，可作为程序记忆。

注意：语义记忆（semantic memory）和语义搜索（semantic search）不是一回事。前者是所保存的记忆内容类型；后者是按照含义相似度查找信息的一种检索方法。

语义记忆的两种组织方式

语义记忆常保存用户、组织或其他对象的事实。LangChain 文档举出两种管理形态：集中维护一份 Profile，或把记忆拆成多个独立条目的 Collection。

Profile：更新一份档案

Profile 通常是有明确字段的 JSON 文档。系统把旧档案和新对话交给模型，让模型提出更新后的档案或 JSON Patch，再由应用校验并保存。

{
  "preferred_language": "中文",
  "example_language": "Java",
  "answer_style": "简洁"
}

优点是整体画像集中，取用方便；随着字段增多，合并新旧信息时更容易遗漏或错误覆盖，因此需要明确 schema（数据结构）并进行校验，也可以按主题拆分档案。

Collection：维护一组记忆条目

Collection 是一组持续添加、更新或删除的独立记录。每条可以有自己的结构和元数据，例如内容、来源、创建时间和适用用户。

[
  {"fact": "用户偏好中文回答", "type": "preference"},
  {"fact": "用户正在学习 RAG", "type": "learning_goal"},
  {"fact": "示例项目使用 Java", "type": "project_context"}
]

这种方式便于单条新增和检索，但需要处理重复、冲突、更新与删除；条目分散也可能让模型缺少它们之间的整体关系。使用 Collection 时，检索逻辑和记忆维护规则尤其重要。

可以这样选择：需要一个稳定、整体的用户画像时，Profile 较直观；信息来源多、条目持续增长且需要逐条搜索时，Collection 更灵活。系统也可以组合两者，例如用 Profile 保存当前偏好，用 Collection 保存具体经历。

情景记忆：用过去的例子帮助当前任务

情景记忆保存过去发生的事件或 Agent 的行动。在一些任务中，系统可以把成功的输入与输出保存为示例，再根据当前输入选择相似示例，作为 few-shot prompting（少样本提示）的一部分。

过去的案例：用户问订单进度 → 查询订单状态 → 用简洁语言说明
当前的问题 → 找到相关案例 → 把示例放进提示词 → 模型参考示例处理

关键不是把所有历史案例都交给模型，而是按当前输入挑选有帮助的例子。案例需要维护和评估，避免错误或过时的做法被反复模仿。

程序记忆：维护做事规则

对智能体来说，程序记忆可以体现在模型权重、Agent 代码和提示词中。通常由开发者控制代码与模型配置；应用也可以根据反馈改进提示词或规则。

例如，客服 Agent 的操作规则可以是：先确认用户身份，再查询订单；涉及退款时核对政策；信息不足时先向用户追问。系统可把近期反馈和旧指令交给模型，生成一版候选指令，但应经过审核或自动校验后再启用，不能把一次性要求误当作永久规则。

长期记忆何时更新？

记忆写入可以放在处理用户请求的主流程中，也可以放到后台异步执行。选择取决于信息是否需要立即生效，以及当前响应能否接受额外延迟。

例如，用户刚刚更正自己的语言偏好。如果下一轮请求必须立即使用新偏好，可以在主流程更新；如果记忆整理较慢且不影响当前回答，可以先回复，再异步写入。后台图示里的时间延迟只是说明处理可以稍后发生，并非固定等待时间。

设计时先回答四个问题

1. 记什么？ 区分当前任务状态、用户事实、历史经历和长期规则，避免把所有消息都当成记忆。
2. 何时写？ 决定在请求主流程即时写入，还是交给后台异步整理。
3. 怎样取？ 根据 thread、用户、任务、关键词或语义相关性，挑选当前真正有用的记忆。
4. 何时更新或删除？ 处理偏好变化、事实冲突、过期信息、用户撤回和数据保留期限。

短期记忆的重点是让当前任务接得上；长期记忆的重点是留下跨会话仍有价值的信息。两者一起工作，才构成可持续使用的智能体记忆系统。

延伸阅读

• LangChain：Memory 概念概览，介绍短期/长期记忆及语义、情景、程序记忆。
• LangGraph：短期记忆，介绍 thread state 与 checkpointer。
• LangGraph：长期记忆，介绍 Store、namespace、Profile 与记忆读写。
• CoALA：Cognitive Architectures for Language Agents，从认知架构角度讨论语言智能体的记忆、行动和决策过程。