用户记忆:让 Agent 记住你是谁
这一章讲三件事: 「记住用户」到底指什么(不是存记录,是建 模型); 记下的东西用什么格式存(四种格式与它们各自的代价);以及记忆多了之后 怎么整理、冲突了怎么办、隐私怎么保。
1. 这一章讲什么
上一章的上下文管理管单次任务;这一章问的是:对话结束后,怎么让 Agent 仍然记得。书里把持久化记忆分成两个尺度:用户记忆针对单个用户—— 在与这位用户的交互中逐渐了解其偏好习惯,构建专属于他的知识模型;知识库 面向所有用户共享——行业法规、公司流程、专业文档。前者让 Agent 成为 「懂你的助手」,后者让它成为「领域专家」1。本章讲前者,后者(知识库:把「在资料库里找内容、拼进上下文」做成一套手艺,行话叫检索增强生成,缩写 RAG(它是下一章的主角)。
先立住一个观念:记忆并非简单记录用户说过的每一句话。就像与朋友相处, 你不会记住每次对话的原文,而是通过持续交互形成一个关于对方的生动模型—— 爱好、习惯、价值观——这个模型让你能理解甚至预测对方的需求2。
2. 顶层全景
一次对话结束
│ 提取:从对话里抽出候选事实(「用户靠窗座」「常旅客号 12345678」)
▼
对比:与已有记忆比较 ── 新增?更新?删除?还是不动?
▼
存储:四种格式选一种(或混合)写入长期记忆
│
▼
整理:重要性评分 → 聚类摘要 → 抽象泛化 → 冲突版本化
│
▼
下次对话:按需取回相关记忆,注入上下文(工作记忆)
图说:这条流水线里,「提取-对比-决策」是 Mem0 的骨架,
「整理」是 3.5 节的内容,「取回」是下一章检索的主场。
3. 核心原理
3.1 主走查:订一次机票,留下四条记忆
场景与记忆条目来自原书;英文对话为原书示例。
用户说:「帮我订下周五去东京的航班,我偏好靠窗座位」;几轮后补充: 「用我的美联航常旅客号 12345678」。对话结束后,记忆系统从这几句话里 提取出3:
- 用户偏好靠窗座位 (偏好类)
- 用户的常旅客号: 12345678 (会员项目类)
- ……(共四条,每条是一个最小事实,不带对话原文)
注意被丢掉的是什么:问候语、检索过程、「Here are your options」这类过程性 文本——记忆要的是结论,不是录音。这几条记忆将跨会话生效:三个月后用户 再说「订机票」,Agent 不必再问座位偏好;而当他订国际航班时,系统还可以主动 调出数月前存的护照信息(3.2 节的第三层能力)。
顺带看清记忆与轨迹的分工:轨迹是一次运行的完整历史,按时间追加、只增不改; 用户长期记忆是跨会话提炼的稳定信息,会被反复改写、合并、淘汰。书里一句话 钉住两者的差别:前者是流水账,后者是档案4。
3.2 评估先立尺子:三层次框架
「什么样的记忆系统算好?」书里先引学术基准 LoCoMo(长期对话记忆,数百轮对话的 公开测试集),再自己设计了更贴 Agent 场景的三层次评估框架5:
| 层 | 要求 | 例子 |
|---|---|---|
| 一:基础回忆 | 准确存取用户直接给的无歧义信息 | 「我的会员号是 12345」,要用时精确返回 |
| 二: 多会话检索 | 从不同对象、不同时期的会话里集齐相关信息并推理 | 用户有两辆车,说「为我的车预约保养」时应找齐两辆并问哪辆,而不是随便猜一辆 |
| 三:主动服务 | 综合跨越很久之前的会话,提供预见性帮助 | 订国际航班时主动调出护照信息,发现即将过期并预警;手机坏了,主动整合自带保修+信用卡附加险+运营商保障6 |
第三层是「助理」与「查询接口」的分水岭:它要求从看似无关的记忆里发现联系。 书里的实验按此框架构造评估集:每层 20 个用例,每个用例合计约 50 轮对话,且 被测 Agent 只能访问记忆、不能回看原始会话——逼着系统把宝押在记忆质量上7。
3.3 四种存储格式:简单性与表达力之争
同一条信息,粒度和结构可以差很远。书里给了四种递进的格式,每一种都在 「简单」与「表达力」之间做了不同的交换8:
| 格式 | 长什么样 | 代价 |
|---|---|---|
| Simple Notes | 每条是最小不可分事实(「用户邮箱:john@example.com」),增删改 O(1) | 关联完全丢失——工作信息被拆成三条互不相干的事实 |
| Enhanced Notes | 带完整上下文的段落 | 冗余、更新要重写多处;段落越长,后续检索越难精确——简介越长越难抓住重点 |
| JSON Cards | 三层嵌套(类别→子类别→键值对),支持部分更新 | 刚性结构假设信息可清晰分类 |
| Advanced JSON Cards | 在事实之外记录来源背景(backstory)、主体(person)、与用户的关系(relationship)、时间 | 最全面也最重 |
第四种的存在理由值得单独讲:它解决消歧。「张医生」可能是用户自己的牙医, 也可能是他父亲的心脏科医生——简单键值存无法区分;有了 backstory(为什么 存这条)和 relationship(为谁存的),系统才能答对「我父亲的医生」这类问题9。
实践取舍,书里的标准很干脆:关键且少量的数据(偏好、关键人物关系)用 Advanced 保证可检索;大量非关键的对话事实用 Simple 降成本;多数生产系统是混合模式—— 同一 Agent 内,不同类信息走不同的路10。