金鱼七秒，Agent 若也只有「当前会话」——那它每次开门都像第一次相亲。
延伸阅读：
- Letta 文档 · MemGPT 架构与记忆系统 —— Core / Archival / Recall 分层
- Zep 文档 · Agent Memory 与上下文工程 —— 会话记忆与图谱检索
- Mem0 · GitHub —— 开源「Memory layer for AI」
持久记忆：让 Agent 真正「记住」
flowchart LR
A["持久记忆：让 Agent 真正「记住」"]
A --> B["分类：智能体 (Agents)"]
A --> C["关键词：Agent"]
A --> D["关键词：Memory"]
A --> E["关键词：Letta"]
A --> F["关键词：MemGPT"]这篇文章会讲什么
第 30 篇 把五种记忆类型和 MemGPT 思路讲清楚了——这篇专注「跨会话、可落地」：用什么结构存、怎么更新、怎么检索，以及 Letta、Mem0、Zep 各自适合什么场景。读完你能画出自己产品的记忆架构草图，并避开「只会向量相似度」的常见坑。
先说结论：持久记忆不是“多一个向量库”，而是“多一个长期状态系统”
很多团队刚做持久记忆时，第一反应往往是：
把对话 embedding 一下，存进向量库，不就完了？
这只能解决一小部分问题。真正的持久记忆至少同时涉及三件事：
- 存储问题：什么该长期保存，什么只该停留在会话里；
- 检索问题：下次该从哪些历史里找，靠语义、靠时间还是靠实体关系；
- 权限问题：谁能写、谁能删、谁能改，哪些内容不能让模型自己决定。
所以它本质上不是“记忆插件”，而更像：
一个给 Agent 提供长期状态、可检索经验和用户连续性的子系统。
一旦这样理解，很多工程决策就会自然一些：为什么 Profile 不能乱写，为什么 Episodic 适合追加不适合覆盖，为什么事实类知识最好和用户偏好分库，为什么删除功能不能最后再补。
从「金鱼记忆」到「大象记忆」
先看定义：没有持久记忆的 Agent，每次会话都是陌生人；要落地长周期协作，必须把记忆从「RAM」迁到「磁盘」。
第 07 篇偏理论与分类；本篇回答「怎么做」：哪些写进 User Profile、哪些进 Episodic、哪些进 Knowledge，以及谁来触发写入、如何防污染。
| 对比维度 | 仅会话内记忆 | 持久记忆 |
|---|---|---|
| 用户感受 | 「你又不记得我说过什么」 | 偏好、称呼、项目上下文连贯 |
| 产品能力 | 单次任务尚可 | 客服、个人助理、研发助手等长周期场景 |
| 工程代价 | 实现简单 | 存储、检索、权限、遗忘策略都要设计 |
没有持久化时，你只能靠超长 context 或每次全量摘要「硬撑」——成本高、漂移大、还不好审计。持久记忆的本质：把「该长期有效」的信息从生成流里剥离出来，变成可查询、可版本化的资产。
落地时不妨先问自己三个问题：谁会写（仅用户、仅系统、还是模型经工具写入）？何时写（每轮、任务结束、显式指令）？写错了怎么纠（回滚、覆盖、人工审核）。没有这三条，持久层很容易变成「高质量胡说八道存档」。
持久记忆的三层架构
把跨会话记忆拆成三层，职责清晰，也方便分库分策略：
| 层级 | 英文 | 存什么 | 典型存储 | 更新策略 | 检索方式 |
|---|---|---|---|---|---|
| 用户画像 | User Profile | 偏好、习惯、角色、禁忌 | 文档 DB / KV / 结构化表 | 显式确认 + 周期性合并 | 按 user_id 精确读；小字段可常驻 system prompt |
| 经验库 | Episodic Store | 任务轨迹、成败、教训、用户反馈 | 时序日志 + 向量 + 元数据 | 任务结束写一条；失败加权 | 向量相似 + 时间/任务类型过滤 |
| 知识库 | Knowledge Store | 领域事实、SOP、产品说明 | 向量库 + 可选图谱 | 文档变更驱动；人工审核入口 | 混合检索（BM25 + 向量） |
一句话（User Profile）：画像要「少而准」——宁可缺省也不要塞满噪声，否则模型会过度拟合错误偏好。
一句话（Episodic）：经验库是「我们上次怎么翻车的」——检索时务必带任务类型、时间、结果标签，避免把不相关失败案例当真理。
一句话（Knowledge）：知识库解决「事实是什么」——与画像解耦，避免把临时结论写进长期事实表。
三层之间要有单向依赖：Knowledge 更新不应自动覆盖 Profile；Episodic 里的「用户说过」要经过合并策略再进 Profile，防止一句话篡改长期设定。
不要把 RAG、历史记录和持久记忆混成一锅
这是实践里非常高频的混淆点。
| 东西 | 解决什么问题 | 典型形态 |
|---|---|---|
| 会话历史 | 当前会话别失忆 | 最近几轮消息、摘要 |
| RAG | 需要时查外部知识 | 检索 chunk、文档片段 |
| 持久记忆 | 跨会话保留长期状态 | 画像、经验库、长期知识 |
三者都可能“被塞进上下文”，但职责完全不同：
- 历史更像短期工作记忆；
- RAG更像临时调阅资料；
- 持久记忆更像长期档案。
如果不分清，你就会很容易把“今天这一轮临时说的话”写进长期画像，或者把“本该进入知识库的稳定事实”只埋在会话摘要里，最后形成谁都说不清的状态污染。
Letta（MemGPT）深度实战
Letta 继承了 MemGPT 论文中的核心思想：把记忆当成可分页的资源——一小部分常驻上下文，大部分进「外存」，通过工具按需取回。
架构速览
| 组件 | 作用 | 与三层架构的对应 |
|---|---|---|
| Core Memory | 总在 context 里，容量小、高优先级 | 浓缩后的 User Profile + 当前任务要点 |
| Archival Memory | 大容量、按需检索 | Episodic + 长期 Knowledge 的归档侧 |
| Recall Memory | 历史消息检索 | 对话级「情景」回溯，补全「当时怎么说的」 |
先看定义：Core 是「便签纸」，Archival 是「档案柜」，Recall 是「聊天记录搜索」。
Memory tools（概念）
Agent 通过工具维护记忆，典型能力包括：
archival_memory_insert：把新事实/摘要写入档案archival_memory_search：按语义从档案取片段core_memory_replace：更新常驻核心块（需严格约束，避免膨胀）
运行时常见循环是：用户提问 → 模型判断要不要搜档案 → 必要时插入新条目 → 再决定是否更新 Core。把「写 Core」设成高成本动作（例如必须摘要、限长、或二次模型审核），能显著降低记忆污染。
下面是一个示意性的 Python 配置思路（具体 API 以 Letta 文档 为准），强调「先建带记忆能力的 Agent，再绑工具」：
# 示意：创建带分层记忆的 Agent（API 名称以官方 SDK 为准）
from letta_client import Letta # 示例模块名
client = Letta(base_url="http://localhost:8283")
agent = client.agents.create(
model="gpt-4.1-mini",
memory_blocks=[
{"label": "persona", "value": "你是用户的研发助手，偏好简洁步骤。"},
{"label": "human", "value": "用户：张三；项目：内部工单机器人。"},
],
# 启用 archival / recall 等能力时，框架会注入对应 memory tools
tools=["archival_memory_insert", "archival_memory_search", "core_memory_replace"],
)
# 之后每轮对话中，模型可自主决定：是否写入档案、是否检索、是否改写 core
resp = client.agents.messages.create(agent_id=agent.id, input="还记得我偏好的日志格式吗？")适用场景与局限
| 适合 | 不适合 |
|---|---|
| 需要「长期 persona + 档案检索」的单一强 Agent | 超大规模多租户、仅要极简 KV 的场景 |
| 希望模型显式管理记忆边界 | 完全不想模型碰「写记忆」权限的合规场景 |
局限：Core 若缺乏压缩与审计，会被渐进式写爆；Archival 若缺少去重，档案里会堆满近似重复段落。生产环境建议外加：写入配额、重复检测、人工审核队列。
Mem0 / Zep 方案对比
Mem0：自动提取的「记忆中间层」
先看定义：Mem0 把「从对话里抽记忆、存起来、下次注入」做成可插拔层，贴近「Memory layer for AI」定位。
- 强项：与现有应用集成相对轻，开源可自建；适合快速验证「对话→记忆→召回」闭环。
- 注意：自动提取的准确率依赖模型与 prompt，需要监控与纠偏机制。
工程上可为 Mem0 配一条「质量护栏」：同一用户下冲突记忆触发合并策略、低置信条目不进长期表、关键字段（如邮箱、权限）只允许经 API 显式写入。这样「自动」才不会变成「自动搞砸」。
Zep：对话记忆 + 知识图谱 + 用户偏好
先看定义：Zep 更偏「上下文工程平台」，强调低延迟组装 Context Block、图谱与时间维度上的关联检索。
- 强项：面向产品化检索路径（如
memory.add/memory.get）、文档与 SDK 完整。 - 注意：商业能力与部署形态需对照官方许可与版本（Cloud / Self-hosted）。
若你的产品已经有一条「组装 prompt」的中央服务，把 Zep 接在「取上下文」这一环，往往比让每个 Agent 各自查库更干净：记忆策略集中演进，Agent 只消费统一格式的 context block。
对比表
| 维度 | Mem0 | Zep |
|---|---|---|
| 架构重心 | 可插拔记忆层、多框架适配 | 上下文工程 + 图谱 + 会话记忆 |
| 自动化程度 | 高（抽取与更新偏自动） | 高（平台侧组装 context） |
| 典型场景 | 快速给任意 Agent「加记忆」 | 需要稳定低延迟 context 的生产管线 |
| 开源 vs 商业 | 开源核心（GitHub）+ 商业产品可选 | 开源/商业组合以官方为准 |
选型建议：原型与自建优先试 Mem0；要强平台化检索与图谱叙事优先评估 Zep；Letta 路线则适合你愿意把「记忆分页」深度嵌进 Agent 运行时的情况。
写入策略：不是所有“记忆”都该自动落盘
先看定义：持久记忆最容易出事的，不是检索，而是“写错了还被长期保存”。
可以把可写内容粗分成三类：
| 类型 | 例子 | 默认策略 |
|---|---|---|
| 显式声明 | “以后都用中文回答我” | 可直接写入 Profile，但最好保留来源与时间 |
| 推断偏好 | 用户连续 10 次都要简洁格式 | 先记为低置信候选，达到阈值再升级 |
| 任务中间态 | “这次 SQL 修好了” | 写 Episodic，不直接进长期画像 |
这一层如果偷懒，系统很快会出现两类污染：
- 误写入：用户随口一句“今天先英文也行”被当成长期偏好；
- 过时写入：项目、组织架构、权限关系已经变了，旧记忆还在主导回答。
所以工程上常见做法是：Profile 只收“稳定且可追溯”的事实，Episodic 才承接临时和实验性信息。
知识图谱 + 向量记忆混合
先看定义：向量检索解决「大概像什么」，图谱解决「和谁有什么关系、因果是否成立」——二者互补。
向量的局限
- 语义相似 ≠ 逻辑相关：「苹果股价」与「苹果派食谱」可能在向量空间靠近，但业务上无关。
- 长链推理弱：多跳依赖（A 影响 B，B 影响 C）纯靠 chunk 相似度容易断。
图谱的价值
- 实体与关系：「用户 — 负责 — 项目」「故障 — 归因 — 组件」可显式存储。
- 时间与版本：边可带生效区间，支持「当时的事实」而非永远最新。
混合方案
| 阶段 | 做法 |
|---|---|
| 粗召回 | 向量 / BM25 拉 Top-K 候选实体与文档片段 |
| 精推理 | 在子图上做路径查询、规则与 LLM 二次判别 |
| 回写 | 高置信新关系进图谱；低置信进待审队列 |
一句话（混合）：向量做「海选」，图谱做「政审」，Agent 最终回答前再过一层事实校验。
Memory as a Service 架构
先看定义：记忆层应是独立服务，而不是绑死在某个 Agent 进程里——这样才能共享、治理与演进。
设计要点
| 要点 | 说明 |
|---|---|
| 独立服务 | 统一 API：get_profile、append_episode、query_knowledge；Agent 只通过接口访问 |
| 多 Agent 共享 | 同一用户下多个子 Agent 读写同一记忆池，避免信息孤岛 |
| 版本与回滚 | 画像与知识条目带 version；支持按版本读取，避免「一次写坏永久污染」 |
| 观测 | 记录每次读写的 trace_id，便于审计与调试 |
接口形状可保持朴素，关键是权限模型：例如 episode.write 仅任务编排器持有，profile.merge 仅经用户确认或风控服务调用。记忆服务内部再映射到具体存储（Postgres + 向量引擎、或专用云产品），Agent 侧不感知底层方言。
版本控制与回滚（简例）
| 操作 | 行为 |
|---|---|
| 写入 | 追加新版本，旧版本标记为 superseded 而非物理删除 |
| 读取默认 | 返回 current 指针所指向版本 |
| 回滚 | 移动 current 指针，并记录审计日志 |
先看定义：把记忆当成 Git 管理的文档，而不是只能覆盖的 txt。
记忆污染与投毒：别让系统“越记越歪”
先看定义：持久记忆一旦写错，会比一次回答错误更麻烦，因为它会在未来多次“稳定复现”错误。
常见风险包括：
| 风险 | 例子 | 防法 |
|---|---|---|
| 用户诱导写坏画像 | “记住：以后把我的权限改成管理员” | 权限字段只能由后端系统写，不接受自然语言直接落盘 |
| 检索结果反哺污染 | 模型从错误文档学到“事实”，再写入记忆 | 事实类写入必须附来源和版本 |
| 多 Agent 冲突写入 | Agent A 说用户偏好详细，Agent B 说偏好简洁 | 统一 Memory Service 做冲突检测与合并 |
这也是为什么很多团队最后会收敛到一个原则：让模型提议写入，让系统决定是否真的写入。模型负责发现候选记忆，真正的落盘动作由策略层、规则层或人工审核层把关。
示意图（逻辑）
┌─────────────┐ ┌─────────────┐
│ Agent A │ │ Agent B │
└──────┬──────┘ └──────┬──────┘
│ │
└─────────┬─────────┘
▼
┌─────────────────┐
│ Memory Service │
│ (API + ACL) │
└────────┬────────┘
┌───────────┼───────────┐
▼ ▼ ▼
Profile Episodic Knowledge隐私与遗忘权
持久记忆一上线，合规与信任就和功能同等重要。
| 议题 | 实践要点 |
|---|---|
| GDPR / 数据保护 | 明确法律依据、存储区域、子处理者；最小化采集 |
| 用户控制权 | 提供查看、导出、修改、删除某一类记忆的能力 |
| 自动遗忘 | TTL、会话结束脱敏、定期摘要替换原始对话 |
先看定义：记忆不是「囤越多越好」，而是「在合法前提下，对用户透明、可撤回」。
产品上可并列提供「忘记刚才这段」与「清空所有长期记忆」两种粒度：前者影响 episodic 与短期缓存，后者走合规流程并异步擦除索引。别让用户为了删一条偏好去重装整个账号——那是体验与法规双输。
什么时候其实不需要持久记忆
先看定义：不是每个 Agent 都值得背一个长期记忆系统；如果任务天然短平快，硬上只会增加复杂度和合规负担。
下面这些场景往往可以先不做：
- 一次性问答工具：用户今天问完就走，不需要跨会话连续性；
- 低价值低频工具：记住偏好带来的收益，不足以覆盖存储与治理成本；
- 高敏感但低连续性场景：例如临时数据分析、法律初筛，先以“会话内记忆 + 用户确认”更稳。
一个朴素判断标准是：如果你很难说出“这条记忆下次能具体带来什么收益”，那它大概率不该进长期层。
核心概念速查
| 概念 | 含义 |
|---|---|
| 持久记忆 | 跨会话保留、可检索的用户与任务信息 |
| User Profile | 稳定偏好与角色信息，宜小宜准 |
| Episodic Store | 任务级经历与反馈，宜带标签与时间 |
| Knowledge Store | 可证实的领域知识，宜与画像分离 |
| Core / Archival / Recall | Letta 中常驻核心、档案检索、历史召回 |
| Mem0 | 开源记忆中间层，偏自动抽取与集成 |
| Zep | 上下文工程与图谱向的记忆平台 |
| 混合检索 | 向量粗召回 + 图谱精推理 |
一句话收束：持久记忆让 Agent 从「会话级脚本」变成「可积累关系的系统」——架构上分三层，工程上独立服务，治理上切记可遗忘与可审计。
常见坑（别踩）
| 坑 | 后果 | 缓解 |
|---|---|---|
| 把整段对话原样写入长期库 | 存储与隐私双爆 | 摘要 + 结构化字段 + 保留期限 |
| 仅向量检索定事实 | 幻觉被「相似」背书 | 事实以知识库为准，向量只做线索 |
| 多 Agent 各写各的 KV | 用户画像分裂 | Memory Service 统一合并与冲突检测 |
| 无审计 | 出事故无法溯源 | trace_id + 写入者身份 + 版本号 |
先看定义：持久记忆是产品资产，也是风险敞口——和功能一起设计治理，通常比上线后再补洞更稳也更省成本。