AI 记忆治理：让 Agent 学会"忘"¶

记忆污染——Agent 最容易被忽视的陷阱，也是最难排查的。一条错误记忆一旦沉淀，会稳定地影响所有后续决策。这不是 bug，不是模型不够聪明，而是缺了一道叫"闸门"的东西。本文拆解三层记忆治理框架，帮助理解生产级 Agent 记忆的核心设计问题。

目录¶

#存储 vs 记忆：一个根本区别
#记忆污染：被自己的历史拖着走
#三层记忆治理框架
#程序性记忆：从事实到步骤
#记忆系统的工程实践
#评估任何 AI 记忆的四个问题

存储 vs 记忆：一个根本区别¶

核心区别¶

维度	存储	记忆
本质	被动数据保存	主动回忆与调用
触发	显式调用	上下文/条件触发
目的	数据持久化	理解过去、优化决策
类比	仓库管理员（找到相似材料）	主厨（决定今天哪些材料能上桌）

RAG 不是 Memory¶

RAG 解决的是"能不能找到相似内容"。Memory 要多回答一层：

RAG：    有没有跟这个相似的材料？→ 搬几箱过来
Memory：这些材料今天能不能用？
         ├─ 这段历史现在还有效吗？
         ├─ 是长期偏好还是一次性要求？
         ├─ 是正式政策还是内部讨论稿？
         ├─ 是用户让记的还是系统自己推断的？
         └─ 跟当前信息冲不冲突？

旧材料不是一定不能用，但得先过闸门。 没有这道闸门，Agent 就是被自己的历史拖着走。

记忆污染：被自己的历史拖着走¶

什么是记忆污染¶

旧信息未经重新审查就直接影响了新判断。

三种典型场景¶

场景	表现	根因
偏好固化	你说"今天赶时间别展开"，下次复杂问题也短答	临时约束被当成长期偏好存了
知识过期	公司换了退款政策，Agent 还拿旧政策回复新用户	没有版本/时效验证
错误沉淀	Agent 记住了一次稿子的错误判断，后面反复带回来	没有纠错和覆盖机制

为什么更难排查¶

这不是模型笨。正相反，很多时候是模型太会补全——它把旧资料、模糊记忆、自己的语言能力混在一起，生成一个听着很顺、但实际上已经过期或者越界的答案。

更长的上下文、更大的向量库、更强的模型都不能自动解决这个问题。有确实有帮助，但如果没规则，它带进来的不是智慧，而是更大的历史包袱。

记忆规模 vs 治理需求

  记忆少 → 不需要管理
  记忆多 → 必须管理
                 ↑
  你会发现：真正能落地的 Memory
  越来越不像搜索框，更像一套治理系统
  它得回答：来源是哪？谁存进去的？何时失效？冲不冲突？听谁的？

三层记忆治理框架¶

Agent = Model + Harness

  ┌──────────────────────────────────────────────────┐
  │                  Memory System                     │
  │                                                    │
  │  ┌──────────┐   ┌──────────┐   ┌──────────────┐  │
  │  │  Ledger  │──→│  Views   │──→│   Policy     │  │
  │  │ 原始账本  │   │ 派生视图  │   │  调用策略    │  │
  │  └──────────┘   └──────────┘   └──────────────┘  │
  │       ↑               ↑              ↑           │
  │   发生了什么      整理成了什么    什么时候允许      │
  │   从哪来的        能更新能覆盖    它影响当前决策    │
  └──────────────────────────────────────────────────┘

第一层：Ledger（原始账本）¶

记的是：发生了什么、从哪来的、什么时候的事、前后是什么。

类比财务：你不能把原始发票直接改成漂亮报表。报表可以由原始凭证生成，但原始凭证得留着。

Agent 的记忆也一样：

必须记录的元数据	说明
来源	用户明确说的？系统推断的？原始文档？模型总结的？
时间戳	什么时候存的
作用域	哪个用户/会话/任务
类型	对话记录、用户偏好、关键决策、政策版本
状态	有效/过期/被覆盖

Ledger 是追加式（Append-only）的权威记录。所有写入、更新、删除都带来源和时间。这是记忆治理的"原始凭证"。

第二层：Views（派生视图）¶

从原始记录里整理出来的东西，面向检索和推理优化。

Ledger（原始账本）         Views（派生视图）

  原始对话 ──────────→   用户画像摘要
  用户偏好记录 ──────→   近期任务状态
  关键决策记录 ──────→   历史摘要
  政策版本 ────────→   当前有效政策

  ⚠️ Views 不是原始事实，是总结出来的
     既然是总结，就可能过期、可能有错
     所以必须能更新、能覆盖、能回溯到 Ledger

View 类型	内容	特点
用户画像	偏好、习惯、历史决策	可多、可 lossy
任务状态	近期进展、待办、上下文	高时效性
政策索引	当前有效版本 + 过期标记	必须可回溯
知识图谱	实体关系网络	支持多跳推理

关键约束：Views 可以多、可以 lossy，但必须能回指到 Raw Ledger。

第三层：Policy（调用策略）¶

最容易漏掉，也最关键。决定什么能写进去、什么时候翻出来、冲突听谁的、哪些任务不能用记忆。

Policy 把"能不能搜到"变成了"能不能用"

没有 Policy：
  Agent 把历史一股脑带进当前任务
  → 看着听懂你，其实在拿过去塑造现在

有 Policy：
  "我以后写稿喜欢短句" → 可存长期偏好 ✅
  "今天赶时间别展开"    → 临时约束，不存 ❌
  退款政策 v2 → 历史背景参考，但不能直接回复用户 ❌
  退款政策 v3（当前有效）→ 可以使用 ✅

Policy 的四类决策¶

决策	问题	示例
写策略	什么能写进去？	用户明确说"记住"→ 写；临时抱怨 → 不写
读策略	什么时候翻出来？	新会话开始 → 加载画像；敏感决策 → 清空偏见
冲突策略	新旧矛盾听谁的？	新信息覆盖旧信息，但旧信息保留在 Ledger
遗忘策略	什么该被清理？	一次性对话偏好不持久化；过期政策标记失效

程序性记忆：从事实到步骤¶

事实记忆 vs 程序性记忆¶

类型	定义	记错了的后果
事实记忆	"是什么"	一个答案错
程序性记忆	"怎么做"（成功干成过的事，直接可套用的步骤）	后面会稳定地错

程序性记忆听着更强大（直接复用成功经验），但也更凶险——因为事实记错最多一个答案错，程序记错后面会稳定地错。

当前状态¶

程序性记忆目前还是正在成熟的方向，不算已经能铺开用的东西。但它是记忆系统最值得关注的演进方向。

记忆系统的工程实践¶

ChatGPT 的记忆架构（逆向工程）¶

ChatGPT Memory 三层结构

  ┌─────────────────────────────────────────┐
  │ 可保存记忆（Save Memories）              │
  │ - 用户主动控制                           │
  │ - "记住我喜欢简洁的技术解释"              │
  │ - 注入系统提示使用                       │
  ├─────────────────────────────────────────┤
  │ 聊天历史                                 │
  │ ├─ 当前会话：过去一天 <10 条消息         │
  │ ├─ 对话历史：两周内精确引用，超两周摘要   │
  │ └─ 用户洞察：自动化高级版记忆             │
  └─────────────────────────────────────────┘

用户洞察生成流程：找活跃用户 → 聚类分析（k-NN）→ LLM 生成洞察摘要 → 附时间戳和置信度。

关键特征：把"Save Memories"、"历史对话"、"临时绘画"分开，用户可以自己看、自己删。

Mem0 框架¶

操作	场景
ADD	原有记忆中不存在的新事实
UPDATE	新旧事实可合并（如"喜欢冰淇淋"+"喜欢烧烤"→合并）
DELETE	新旧事实矛盾（移除旧记忆）
NOOP	不需要修改知识库

2026 年 Mem0 基准成绩：

Benchmark	分数	平均 token/查询
LoCoMo	92.5	6,956
LongMemEval	94.4	6,787
BEAM (1M)	64.1	6,719

~6,900 tokens/查询 vs 全量上下文方案的 ~26,000 tokens。在规模上这是显著的推理成本差异。

System 1 + System 2 架构¶

  System 1（快循环）          System 2（慢循环）

  通用 Agent 推理              记忆检索 + 验证
  (LLM + tools + planner)     (PreThink → Retrieve → Evidence → Stop)

       ↑                              │
       └──── 检索结果 + 来源溯源 ───────┘

  System 1 提供基线能力（通用性）
  System 2 通过记忆提供修正项 Δ（个性化、时序修正、经验复用）

Memory 能力与 LLM 其他 Agent 能力「相对正交」——可拆成低耦合模块分别优化。同一 base model 接入不同记忆策略显著改变长程表现；同一套记忆 infra 可服务多种 base model。

评估任何 AI 记忆的四个问题¶

评估清单：面对任何 AI 记忆功能，先问四件事

  ① 来源：这条记忆从哪来的？
     ├─ 用户让记的还是系统推断的？
     ├─ 来自原始文档还是模型写的总结？
     └─ 能不能追溯到 Ledger？

  ② 时效：它现在还有效吗？
     ├─ 有时间限制吗？有版本限制吗？
     ├─ 有场景限制吗？
     └─ 是长期偏好还是这一回的临时要求？

  ③ 可控：能不能看、能不能删、能不能改？
     ├─ 发现记错了有办法纠吗？
     ├─ 政策失效了能让它停用吗？
     └─ 用户有完整的查看和删除权吗？

  ④ 适用：这次任务该不该用记忆？
     ├─ 需要历史背景 → 用
     ├─ 敏感决策 → 清空偏见
     ├─ 全新项目 → 需要客观判断
     └─ 不能让旧印象自动进场

什么场景不能用记忆¶

场景	原因
敏感决策	旧偏见可能扭曲判断
全新项目	需要客观视角，不被历史束缚
政策变更后	旧版本必须失效，不能自动召回
用户明确要求"忘掉"	遗忘权和删除权