Agent 长期记忆别急着堆：一套防止“越用越笨”的记忆治理方案

很多人做 Agent，开局很兴奋：

接上向量数据库
给对话自动总结
每轮都写入长期记忆
再加一句“越用越懂你”

看起来很完整，对吧？

可真正跑几周，你可能会遇到一个很诡异的场景：Agent 记住了你三个月前随口说的一句话，还把它当成铁律。你明明已经改过需求，它依旧按旧方案输出。更糟的是，它会引用自己以前写错的结论，语气还特别自信。

这不是记忆能力强。

这是把错误塞进了大脑，还把大脑的橡皮擦扔了。😅

Agent Memory 的重点，从来不是“存得越多越好”。真正要解决的是四件事：

哪些信息值得写入
写入的信息可信度有多高
什么时候必须重新验证
发现记错后，怎么撤销和回滚

下面咱们直接拆一套可执行的方案。

一、为什么 Agent 会陷入“错误记忆闭环”

假设你在做一个客服 Agent。

某天，用户问：“会员能不能退款？”

模型没有查到最新规则，于是猜了一句：“购买 7 天内可以全额退款。”

如果系统把这句话直接写进长期记忆，后面就麻烦了：

下一位用户来问退款，Agent 检索到这条记忆。
它把旧答案当成历史经验，继续回答“7 天内可退”。
系统发现这句话被多次提及，又给它加上了更高权重。
错误答案从一次幻觉，升级成了“内部常识”。

这就是错误记忆闭环。

模型并不真的知道这条信息对不对。它只看到了：这段内容出现在记忆库里，而且和当前问题很相关。

很多团队踩坑，就踩在这里：把模型生成的内容，和经过验证的业务事实，放进了同一个记忆池。

这两类东西的待遇，绝对不能一样。

二、别把所有内容都存起来：给记忆分四层

一个好用的 Agent 记忆系统，不该像仓库。什么都往里堆，迟早找不到东西。

更像一个有纪律的档案室。不同资料，放不同柜子，权限和保质期都不同。

1. 用户偏好：可以长期保存

这类内容通常稳定，且能直接改善后续互动。

例如：

用户喜欢中文回答
用户希望答案简洁
用户常用 Python 和 FastAPI
用户习惯把输出整理成 Markdown
用户不想收到邮件提醒，只接受企业微信通知

这类记忆可以直接进入长期库，不过仍要支持用户修改和删除。

建议保存格式：

{
  "type": "user_preference",
  "key": "response_style",
  "value": "简洁、给可执行步骤、使用 Markdown",
  "source": "user_explicit",
  "confidence": 0.98,
  "status": "active",
  "updated_at": "2025-03-08"
}

关键点在于 source。

用户明确说过的话，和模型从对话里猜出来的话，可信度不是一个级别。

2. 任务上下文：短期保存，到期就扔

这类信息只服务于当前任务，不该永久占坑。

例如：

用户正在写一份融资 BP
当前项目使用 Next.js 14
本次会议讨论的是 Q2 营销预算
用户这次上传的 PDF 是产品需求文档 V3

任务结束后，这些内容大概率会过期。

给它们加 TTL（存活时间）。比如 24 小时、7 天或项目结束后自动失效。

{
  "type": "task_context",
  "content": "当前在修改官网改版 PRD V3",
  "expires_at": "2025-03-15T00:00:00Z",
  "status": "active"
}

别小看“过期”这个动作。

很多 Agent 之所以答非所问，不是模型不聪明，而是它还抱着半年前的上下文不撒手。

3. 业务事实：必须带来源和版本

价格、政策、库存、合同条款、产品功能、公司制度，这些内容不能靠模型“记得”。

它们必须有权威来源。

推荐保存这些字段：

{
  "type": "business_fact",
  "content": "企业版套餐支持 SSO 登录",
  "source_url": "https://docs.example.com/pricing",
  "source_title": "产品套餐说明",
  "source_version": "2025-03-01",
  "verified_at": "2025-03-08",
  "confidence": 1.0,
  "status": "active"
}

这里有个硬规则：

没有来源的业务事实，不进长期记忆库。

宁可 Agent 回答“我需要查一下最新规则”，也别让它编一个看似合理的答案。

客服场景里，一句错的退款政策，可能就是一张投诉工单。财务、医疗、法律场景更别提了，别拿线上事故给模型交学费。

4. 模型推断：默认可疑，单独放

模型很擅长归纳和猜测。

比如它会推断：

用户可能偏好深色界面
某客户可能对价格敏感
这个项目大概会在月底上线
用户提到“报错”，可能卡在环境配置

这些推断有价值，却不能当事实。

正确做法是把它们放进“候选记忆区”，并打上明显标签：

{
  "type": "model_inference",
  "content": "用户可能偏好深色模式",
  "evidence": [
    "用户两次提到夜间使用电脑",
    "用户曾询问深色主题配置"
  ],
  "confidence": 0.62,
  "status": "pending_verification"
}

候选记忆只能影响回答的语气或建议，不能直接驱动关键决策。

比如，Agent 可以问：“你要不要试试深色模式？”

它不能直接替用户把主题改掉。这个区别很重要。

三、给每条记忆加“身份证”：来源、置信度、时间、状态

一条只存文本的记忆，几乎等于埋雷。

你至少要让每条记忆带上这些元数据：

| 字段 | 用途 | | --- | --- | | memory_id | 唯一编号，方便追踪和删除 | | type | 用户偏好、任务上下文、业务事实、模型推断 | | source | 用户明确表达、知识库、工具返回、模型推断 | | confidence | 可信度分数，建议 0~1 | | created_at | 创建时间 | | verified_at | 最近一次验证时间 | | expires_at | 过期时间 | | status | active、pending、deprecated、revoked | | version | 版本号，用于回滚 |

一个简单的可信度规则，可以直接抄：

用户明确表达：0.95 ~ 1.0
官方知识库或数据库查询结果：0.95 ~ 1.0
人工审核通过的总结：0.9
多轮对话归纳：0.7 ~ 0.85
模型单次猜测：不高于 0.6
来源不明的历史文本：不高于 0.4

检索时也别只看语义相似度。

可以用一个简单公式做排序：

最终分数 = 语义相似度 × 可信度 × 新鲜度 × 来源权重

举个例子：

一条 2023 年的旧价格表，语义匹配度很高，可信度却很低。
一条今天从价格 API 查到的数据，语义匹配度略低，却是最新的。

该选谁？

当然选 API 数据。用户问的是价格，不是在考古。

四、关键问题别依赖记忆：用“检索 + 验证”双保险

长期记忆适合保存偏好、背景和线索。

涉及实时变化的信息，要回到权威系统验证。

常见的高风险内容包括：

商品价格
库存数量
订单状态
账户余额
退款与售后政策
合同条款
医疗建议
法律法规

给 Agent 定一条明确指令：

当用户询问价格、库存、订单、政策、账户、合同等高风险信息时，
不得仅依据历史记忆回答。
必须调用对应工具或检索权威知识源。
若无法验证，请明确说明信息未确认，不要猜测。

这条规则很朴素，却能挡住一大批事故。

一个典型工作流

用户问：

我的订单什么时候发货？

正确流程：

识别为订单状态查询。
不读取“历史订单状态记忆”作为最终依据。
调用订单系统 API。
拿到最新状态后再生成自然语言回复。
如有必要，只记录“用户经常查询某订单”这类低风险行为线索。

错误流程：

从记忆里翻出“三天前订单待发货”。
直接回复“还在待发货”。
实际上仓库两小时前已经出库。
用户打开物流页面一看：你这 Agent 在说啥？

五、记忆写入前，加一道“闸门”

别让每轮对话都自动写库。

一个实用的写入闸门，可以按下面四步走。

判断 1：这件事未来还会用到吗？

用户说“我今天心情不太好”，通常不该永久保存。

用户说“以后所有周报都按这个结构写”，值得保存。

判断 2：这是事实、偏好，还是模型猜测？

类型不清楚，就先别写。

尤其是模型自己总结出来的“用户画像”，很容易自作多情。

判断 3：有没有明确来源？

没有来源的业务信息，禁止写进事实库。

用户明确确认过的偏好，可以记录来源为 user_explicit。

判断 4：用户是否可能介意被记住？

健康状况、财务信息、身份信息、私人关系、精确位置，这类内容要格外谨慎。

能不存就不存。

确实需要存，也要有告知、授权、加密和删除入口。

一个可直接使用的写入策略：

仅写入满足以下条件的信息：
- 对未来任务有稳定价值；
- 来源可追溯；
- 不属于敏感信息，或已获得用户授权；
- 信息类型明确；
- 能设置置信度、有效期和状态。

模型推断默认进入候选区，不得直接写入事实区。

六、做回滚，不要指望“覆盖写入”能救你

很多系统更新记忆时，喜欢直接把旧内容改掉。

这很省事，也很危险。

因为你一旦发现新内容错了，旧版本已经没了。

正确做法是：记忆不可直接覆盖，采用版本化更新。

比如用户原本说：

我常用邮箱是 a@example.com

后来又说：

邮箱换成 b@example.com 了。

别把旧值直接抹掉。可以这样记录：

[
  {
    "memory_id": "email_v1",
    "value": "a@example.com",
    "version": 1,
    "status": "superseded",
    "valid_to": "2025-03-08T10:30:00Z"
  },
  {
    "memory_id": "email_v2",
    "value": "b@example.com",
    "version": 2,
    "status": "active",
    "valid_from": "2025-03-08T10:30:00Z"
  }
]

这样做有三个好处：

你能查到错误是从哪一版开始出现的
你能一键回滚到上一版
你能审计“谁在什么时候改了什么”

如果系统支持事件日志，可以再进一步。

把每次创建、验证、更新、废弃、撤销都记成事件：

2025-03-08 10:00 创建记忆：用户偏好简洁回答
2025-03-08 10:05 模型推断：用户偏好表格展示
2025-03-08 10:06 用户否认该推断
2025-03-08 10:06 撤销候选记忆：用户偏好表格展示

这就是 Agent 的“时间机器”。

出问题时，不用盯着向量库抓瞎。你能顺着日志，把错误链路一段段扒开。

七、让 Agent 学会怀疑自己：触发重新验证的条件

Agent 不需要时时刻刻自我怀疑，那会慢得像在泥里跑步。

可一旦碰到下面这些信号，就该重新验证：

记忆超过有效期
当前信息和旧记忆冲突
用户明确纠正过 Agent
记忆的置信度偏低
回答涉及钱、权限、合规、健康等高风险内容
同一问题出现多个互相矛盾的答案
外部系统数据发生更新

可以给模型一份很明确的决策规则：

若检索到的记忆状态不是 active，禁止作为事实引用。
若记忆置信度低于 0.8，优先向用户确认或调用工具验证。
若用户提供的信息与历史记忆冲突，以用户当前明确表达为优先，并将旧记忆标记为待复核。
若涉及高风险业务字段，必须以实时工具结果为准。

注意一句：用户当前明确表达，通常比历史偏好更可信。

用户以前说“我喜欢简短回答”，今天说“这次展开讲，给我完整方案”，你还硬塞三行摘要，那不是贴心，是犟。

八、一个能落地的最小架构

如果你正在做 Demo，别一上来就搞复杂的记忆图谱、十几个 Agent、全自动反思链路。

先把下面这套最小架构跑稳：

用户输入
   ↓
记忆检索（按类型、可信度、新鲜度过滤）
   ↓
风险判断
   ├─ 低风险：使用长期记忆辅助回答
   └─ 高风险：调用 API / 检索权威知识库验证
   ↓
生成回答
   ↓
记忆写入闸门
   ├─ 可保存：写入对应记忆层，附带元数据
   ├─ 待确认：进入候选区
   └─ 不该保存：直接丢弃
   ↓
版本日志与可回滚记录

技术选型不必死磕：

向量检索：pgvector、Milvus、Qdrant、Pinecone
结构化记忆：PostgreSQL、MySQL、Redis
文档知识库：Elasticsearch、OpenSearch、Notion / 飞书知识库同步
版本与审计：数据库事件表、Append-only 日志、Git 风格快照
任务编排：LangGraph、Dify、Coze、LlamaIndex，或者自己写状态机

向量数据库负责“找得到相似内容”。

结构化数据库负责“知道这条内容从哪来、还能不能用、该不该信”。

别把所有问题都甩给向量库。它擅长语义召回，不擅长替你管理真相。

九、常见坑：这些做法看着省事，后面都很疼

坑 1：把每轮聊天都自动总结后写入长期记忆

后果：垃圾信息越来越多，旧上下文开始污染新任务。

处理方式：只保存稳定偏好、明确事实、长期项目背景。其他内容设置短期 TTL。

坑 2：模型说过的话默认当事实

后果：幻觉变成“历史经验”，错误会反复出现。

处理方式：模型输出必须标记来源。没有权威来源的业务结论，只能作为候选信息。

坑 3：检索到什么就相信什么

后果：旧政策、旧价格、旧项目状态被重新拿出来回答。

处理方式：检索阶段过滤 status、expires_at、verified_at 和 confidence。

坑 4：发现错误后直接删数据

后果：你失去了追踪问题的线索，也无法恢复误删内容。

处理方式：优先标记 revoked 或 deprecated，保留版本和审计记录。

坑 5：没有给用户记忆管理入口

后果：用户不知道 Agent 记住了什么，也没法纠正，信任会掉得很快。

处理方式：提供“查看我的记忆”“删除这条记忆”“忘记我刚才说的内容”等入口。

十、上线前检查清单 ✅

把这份清单过一遍，再去谈“越用越懂你”。

[ ] 用户偏好、任务上下文、业务事实、模型推断是否分开存储？
[ ] 每条记忆是否记录了来源、时间、置信度和状态？
[ ] 高风险问题是否强制调用实时工具或权威知识库？
[ ] 过期记忆是否会自动降权或失效？
[ ] 模型推断是否进入候选区，而不是直接进入事实库？
[ ] 用户纠正 Agent 后，旧记忆是否会被标记待复核？
[ ] 是否支持版本记录、撤销和回滚？
[ ] 用户能否查看、修改、删除自己的长期记忆？
[ ] 敏感信息是否默认不存，或经过明确授权后再存？
[ ] 你是否能回答：“这条记忆从哪里来的，为什么还能被使用？”

如果有几项答不上来，先别急着给产品挂“长期记忆”标签。

真正靠谱的 Agent，不是记住一切。

它知道哪些内容只是聊天里的烟雾，哪些内容是可靠事实；知道什么时候该信任历史，什么时候该重新查；也知道自己记错时，得老老实实撤回。

会遗忘、会验证、能回滚，才是长期记忆该有的样子。