多轮对话长期记忆怎么做：8 种 Memory 方式怎么选

前面讲 ConversationalRetrievalChain 时，我们已经碰到过短期记忆：用 chat_history 帮系统理解“这个前提”“它”“刚才说的那个方法”这些追问。那一层解决的是当前会话里的上下文衔接。长期记忆要处理的问题更麻烦：用户聊了很多轮、隔了很久又回来、曾经提过偏好或关键信息，系统到底该记住什么、怎么取出来、什么时候不要用。

资料《多轮对话中让 AI 保持长期记忆的 8 种优化方式篇》把这个问题拆成了八种做法：全量历史、滑动窗口、实体记忆、知识图谱、阶段摘要、摘要缓冲、Token 缓冲、向量检索记忆。它们都叫 Memory，但解决的不是同一个问题。有的保留原话，有的只保留最近几轮，有的抽实体，有的抽关系，有的把历史压缩成摘要，有的用向量检索从旧对话里找相似片段。

所以不要把长期记忆理解成“越多越好”。记忆越多，上下文越重，错误历史、过期偏好和无关信息也越容易被带进回答。长期记忆的关键不是保存一切，而是把该保存的内容以合适形态留下，并在当前问题需要时取出来。

资料 先讲 ConversationBufferMemory，也就是获取全量历史对话。它用电信客服做例子：用户先问账单问题，又问网络连接问题，机器人如果能记住完整对话，就能在回答网络问题时保留前面账单相关细节，服务体验会更连贯。

全量历史的优点是简单，信息不容易丢。你不需要判断哪一句重要，也不需要额外做摘要或检索。只要对话不长，直接把历史带回模型，系统就能看到前后文。做 Demo、短客服会话、一次性任务助手时，这种方式很顺手。

但它的缺点也明显：历史会一直变长。上下文窗口不是无限的，越往后越容易挤占当前问题和资料片段的位置。更现实的问题是，历史里可能有用户改口、模型答错、旧任务结束后的闲聊。全量塞回去，模型未必知道哪些应该继续使用，哪些应该丢掉。

第二种是 ConversationBufferWindowMemory。资料 用电商商品咨询举例：用户先问手机电池续航，又问配送方式，系统只保留最近一两个问题，就能更快聚焦在配送，而不是把整个购物过程都带进来。示例里 k=1，表示只保留最后一次互动。

第七种 ConversationTokenBufferMemory 也在做类似的事，不过它不是按轮数，而是按 token 控制范围。资料 用金融咨询举例：用户可能连续问投资、市场动态、个人财务规划，系统需要聚焦最近和最关键的几个问题，同时避免记忆过多造成信息混淆。按 token 控制比按轮数更贴近模型上下文限制。

这两种方式适合当前任务比旧历史更重要的场景。比如电商客服、技术支持的某个操作步骤、短期咨询、表单填写。它们的代价是可能忘掉早期关键信息。如果用户第一轮说“我只要企业版”，第十轮问“这个套餐多少钱”，滑动窗口太小就可能丢掉企业版这个条件。

第三种是 ConversationEntityMemory。资料 用法律咨询场景举例：客户可能提到案件名称、相关条款或个人信息，比如去年的交通事故、赔偿建议。实体记忆会把这些关键实体提取出来，在后续对话中继续使用。示例代码里，系统从对话中提取了 wx 这个实体及其值。

实体记忆不是保存整段聊天，而是保存结构化点位。谁、什么案件、哪个地点、什么产品、什么偏好、哪个账号，这些都可以作为实体。它的好处是轻：不需要把一大段历史塞进上下文，也能让系统知道用户前面提过的重要对象。

不过实体抽取要谨慎。实体错了，后面会一直错；实体过多，维护成本会上升；涉及隐私和敏感信息时，还要考虑用户是否允许保存、是否能删除、是否有权限查看。长期记忆一旦从“当前会话”变成“跨会话保存”，产品责任也变重了。

第四种是 ConversationKGMemory。资料 用医疗咨询举例：病人可能描述多个症状和过往病史，比如糖尿病史、口渴、疲劳。知识图谱记忆可以把症状、疾病历史和健康关联组织成关系网络。示例里也展示了“小李是从事技术工作的人”“莫尔索是小李的笔名”，最后能查询出小李的职业和笔名关系。

实体记忆像是一张名片夹，知识图谱更像关系网。它关心的是 A 和 B 的关系：某人属于某公司，某案件发生在某法院，某症状关联某病史，某产品依赖某模块。对复杂咨询、医疗、法律、企业知识管理来说，关系往往比单个实体更重要。

但知识图谱也更难维护。关系抽取可能错，旧关系可能过期，同一个实体可能有多个名字。工程上不能只让模型自由生成关系，最好有人工校正、来源引用、时间戳和删除机制。否则图谱看起来很聪明，实际可能把错误关系越织越密。

第五种 ConversationSummaryMemory 是阶段性总结摘要。资料 用教育辅导举例：学生连续提出数学问题，比如不理解二次方程求解方法。系统把前面辅导内容和学生疑问点总结起来，后续就能更有针对性地解释和安排练习。

摘要的优点是压缩。它不保存每一句原话，而是保留“前面发生了什么、用户哪里不懂、已经讲到哪一步”。这对长对话很有用。比如学习助手、长期项目辅导、写作修改、心理支持类产品，都需要保留过程脉络，但又不能无限堆历史。

第六种 ConversationSummaryBufferMemory 更进一步：既保留最近几轮的详细信息，又保存较早历史的摘要。资料 用长期技术支持举例：用户在多次对话里提供不同错误信息和反馈，系统既要看最近日志，也要知道之前排查过什么。这种“近期细节 + 旧摘要”的组合，往往比单纯全量历史或单纯摘要更实用。

第八种 VectorStoreRetrieverMemory 把旧对话放进向量库，用语义检索取回相关片段。资料 用新闻事件举例：用户问最近经济峰会的重要决策，系统可以从大量历史新闻数据中找出和当前问题最相关的背景信息。示例里也保存了“我喜欢吃火锅”“我不喜欢看摔跤比赛”，再通过 prompt 把相关历史片段放回当前对话。

这种方式很适合历史很长、但当前问题只需要其中一小部分的场景。比如用户很久以前说过饮食偏好、项目背景、写作风格、某个需求约束，现在又问相关问题。向量检索记忆不用把所有历史带进上下文，只找语义上最接近的几段。

它的问题和 RAG 检索类似：召回可能错，旧信息可能过期，相似不等于当前需要。比如用户半年前说喜欢火锅，现在因为健康原因改变饮食，系统如果继续使用旧偏好，就会显得冒失。因此向量记忆必须配合时间、来源、可删除和置信度，不要把旧记忆当成永久事实。

资料 主要从 LangChain 类和使用场景讲记忆，但落到产品里，还要多想一层：记忆不是模型内部的小纸条，而是用户可能会感知、依赖甚至要求删除的数据。一个系统如果偷偷记住用户偏好、案件信息、健康记录或财务计划，风险会很高。

比较稳的做法是，把长期记忆做成可见的调试或管理面板。用户和使用者至少能看到：短期窗口里有哪些最近对话，实体记忆里保存了哪些人和事件，知识图谱里有哪些关系，向量检索命中了哪些旧片段。重要记忆要有来源、时间和删除入口。

这也是长期记忆和普通 RAG 知识库的区别。知识库多是组织管理的资料，长期记忆往往来自用户对话。前者要保证资料准确，后者还要保证用户可控。记忆越“聪明”，越需要让人能改、能删、能追溯。

第一，先区分短期和长期。短期 chat_history 只服务当前会话，长期记忆才跨会话保存。不要把所有聊天记录默认永久化。第二，先保存少量高价值信息，比如用户明确表达的偏好、关键实体、项目背景和重要约束。第三，为每条记忆保留来源和时间，避免以后不知道它从哪来。

如果场景简单，可以用窗口记忆或摘要缓冲，不急着上知识图谱。若用户问题强依赖人物、案件、产品、地点，实体记忆会更直接。若历史跨度很长、旧信息很多，再考虑向量检索记忆。复杂系统可以组合使用，但组合之前要先弄清每一种记忆在负责什么。

长期记忆的目标不是让 Agent 显得什么都记得，而是让它在合适的时候想起合适的信息。能想起，还要能解释为什么想起；能保存，也要能删除。做到这一步，多轮对话才会从“上下文续得上”慢慢走向“服务真的有连续性”。