长期记忆怎么治理：保存、召回、过期和评估

长期记忆让 Agent 变得更像一个能持续服务的系统。它能记住用户偏好、关键实体、历史摘要，也能通过向量检索从很早以前的对话里找回相关片段。长期记忆相关概念 里列出的八种方式，从全量历史到 VectorStoreRetrieverMemory，本质上都在解决一个问题：当前回答需要过去的信息时，系统怎么把它取回来。

但记忆一旦跨过当前会话，风险也跟着上来。用户以前的偏好可能变了，实体关系可能抽错了，摘要可能遗漏限制条件，向量检索可能召回相似但不适用的旧片段。如果这些内容没有来源、没有时间、不能编辑，系统就会把旧错反复带进新回答。

所以长期记忆不能只讨论“怎么保存”。更要讨论保存之后怎么治理：哪些信息值得记，记下来要带什么来源，什么时候该过期，召回前要检查什么，回答后怎么评估，发现错误后如何纠正或删除。记忆质量不是靠一次设计完成的，它需要持续维护。

不是每一句用户消息都值得长期保存。长期记忆相关概念 里举了几个典型场景：电商咨询记住最近配送问题，法律咨询记住案件名称和相关个人信息，医疗咨询记住症状和病史关系，教育辅导记住学生的疑问点，技术支持记住长期故障排查过程。这些例子有一个共同点：记住的信息会影响后续服务。

值得记的内容通常有几类。第一类是用户明确表达的长期偏好，比如写作风格、产品关注点、沟通习惯。第二类是关键实体，比如人名、项目名、案件名、产品型号。第三类是长期约束，比如预算、权限、版本、地区。第四类是历史摘要，比如某个问题已经排查到哪一步。

不值得记的内容也要明确。临时闲聊、一次性任务细节、模型自己猜出的结论、未经确认的敏感信息，都不应该默认沉淀成长期记忆。保存动作最好有规则，有些信息自动保存，有些信息需要用户确认，有些信息只留在短期窗口。

相关概念 在 RAG 里反复强调 metadata：source、page、文件路径、页码这些信息，决定检索结果能不能追溯。长期记忆也一样。用户偏好、实体关系、历史摘要如果没有来源，后面就很难判断它是用户说的、模型总结的，还是系统从文档里抽出来的。

来源至少要包括三件事：来自哪一轮对话，原始文本是什么，是什么时间保存的。更复杂的系统还要记录保存方式，比如实体抽取、人工确认、摘要生成或向量写入。这样当用户说“我没说过这个”时，系统能找到原文；当记忆影响回答时，使用者也能知道这条记忆为什么会被召回。

时间同样重要。很多记忆不是永久事实。用户去年说常驻上海，今年可能去了深圳；某个项目曾经使用 MySQL，现在可能切到了 PostgreSQL；某份制度 2024 年有效，不代表 2026 年仍有效。没有时间戳，系统会把旧信息当成新信息使用。

长期记忆的召回和 RAG 检索很像。相关概念 里展示过相似性搜索的失败：Top-K 可能被重复文档占满，也可能因为只看语义相似而漏掉“第二讲”“第三讲”这类结构条件。记忆召回也会遇到类似问题：相似不代表适用，旧记忆不一定应该进入当前上下文。

召回前可以按六个点检查。第一，这条记忆是否属于当前任务；第二，它是否仍然有效；第三，它是否有来源和时间；第四，它是否经过用户确认；第五，它是否与业务知识库冲突；第六，它是否需要去重或 MMR，避免相同记忆反复占据上下文。

其中最关键的是冲突检查。用户记忆可以辅助理解，但业务答案要看 source_documents。用户曾经说“我们公司报销上限是 800 元”，如果业务知识库里的最新制度写的是 500 元，系统不能为了贴合用户记忆而采用 800 元。用户记忆是上下文，不是最终事实来源。

长期记忆相关概念 里提到 ConversationSummaryMemory 和 ConversationSummaryBufferMemory。摘要能把长对话压短，让系统保留脉络，同时减少上下文占用。教育辅导、技术支持、长期项目跟进都很适合用摘要。

摘要的问题是，它会选择性保留信息。模型总结时可能漏掉条件、弱化不确定性，或者把用户的猜测写得像事实。摘要一旦进入长期记忆，后续回答会直接依赖它。原始对话越长，摘要越要小心。

比较稳的做法是保留“摘要 + 原始来源”。摘要给模型快速理解脉络，原始来源用于复核。重要约束不要只放在自然语言摘要里，最好抽成结构化字段，比如有效期、版本、用户确认状态、关联实体。这样摘要错了，系统还有机会回到原文检查。

VectorStoreRetrieverMemory 的好处是可以从大量旧对话里按语义找相关片段。文中的示例把“我喜欢吃火锅”“我不喜欢看摔跤比赛”等历史对话写入向量记忆，再通过 prompt 把相关片段放回当前对话。它很适合历史很长、但每次只需要一小部分旧信息的场景。

不过，向量记忆会继承向量检索的老问题。相关概念 里讲过重复 chunk 会挤占 Top-K，MMR 可以缓解结果冗余；metadata 过滤能约束来源；压缩检索能从长片段里抽出相关句子。长期记忆也需要这些做法。否则旧记忆越多，召回越容易杂。

向量记忆还要特别处理过期。用户三个月前说喜欢某个工具，不代表今天仍然喜欢；一次应用中的限制，不代表所有项目都适用。写入向量库时最好保留时间、场景、用户确认状态和可删除标记。召回时先过滤，再排序，而不是只看相似度。

长期记忆不是为了让系统显得更了解用户，而是为了让回答更准确、更连贯、更省沟通。评估时不能只看“召回了几条记忆”，要看召回的记忆是否真的帮助回答。可以准备一批多轮问题，标注哪些问题需要短期历史，哪些需要长期偏好，哪些应该只查知识库。

每条评估记录最好包含五项：用户问题、召回记忆、命中文档、生成答案、人工判断。这样可以分清错误来自哪里。召回记忆不相关，是记忆检索问题；命中文档缺失，是知识库问题；两者都对但答案错，是生成或提示词问题。

相关概念 里强调过查看 source_documents 和检索结果的重要性。长期记忆评估也一样，不要只看最终回答。最终回答很容易写得顺，顺不代表对。把记忆、文档和答案放在同一张评估表里，才能知道系统到底有没有因为记忆变好。

长期记忆一旦错误，影响会反复出现。一次抽错的实体关系，可能让后面很多回答都带偏；一条过期偏好，可能让系统一直用旧方式服务用户；一段错误摘要，可能覆盖掉原始对话里的关键限制。没有纠错和删除，长期记忆很快会变成负担。

纠错流程可以做得简单：用户或人工评估发现记忆错误，标记原因，修改或删除记忆，记录修改人和时间。对于重复记忆，可以合并；对于过期记忆，可以降权或隐藏；对于敏感记忆，可以要求用户确认后再保存。

最重要的是，不要让记忆系统只进不出。全量历史、窗口记忆、实体记忆、知识图谱、摘要记忆、向量记忆，每一种都有自己的清理方式。能保存只是第一步，能在错误时退回来，才算真正可维护。