Agent 精读

Agent 精读（十）：记住一个用户，四种存法，和一次跳出文本

这是《深入理解 AI Agent》精读专题的第十篇，进入第 3 章「用户记忆和知识库」。读的是李博杰的开源书第三章的前半部分——本章另一半 RAG 还没读完，读完后有下篇。

第 3 章知识脉络：个体尺度与群体尺度两条线索，本篇只讲左半边

上下文管一次对话，这一章管一辈子

第 2 章读完的时候，我以为上下文工程就是 Agent 记忆的全部。第 3 章开头一句话把我点醒了：上一章解决的是单次交互的上下文管理，这一章要处理的是——对话结束之后，Agent 还记得什么。

书里把持久化记忆分成两个尺度：用户记忆面向单个用户，让 Agent 成为”懂你的助手”；知识库面向所有用户共享，让 Agent 成为”领域专家”。两者共用同一批底层技术（向量检索、知识压缩），也面对同样的三个麻烦：信息冲突、知识过期、检索不准。

我自己的一个归纳：如果上下文是 Agent 的”眼睛”（第 1 章的说法），那么用户记忆和知识库就是眼睛在时间维度上的延伸——上下文是此刻的观察，用户记忆是关于一个人的观察史，知识库是关于世界的观察沉淀。书里没有这么说，这是我读完这一章前半部分后自己接上的线，先记在这里。

先立尺子：我把两把尺子混成了一把

动手设计之前，书先回答”什么样的记忆系统算好”。这里我犯了一个被当场抓住的错误：我口述的时候把 LoCoMo 和三层次评估框架说成了一回事——“基础信息、隐藏信息、跨会话检索、整合能力”。其实它们是两把不同的尺子：

  • LoCoMo 是学术基准：平均约 300 轮、最多 35 个会话的超长对话，任务是问答（单跳、多跳、时间推理、开放域、对抗性五类）加事件摘要和多模态生成。它是被动问答——用户问了才答。
  • 三层次框架是书作者为 Agent 场景自建的：第一层基础回忆（准确存取用户直接给出的信息），第二层多会话检索（跨会话、跨对象把相关信息全部捞出来再推理——用户有两辆车，你得问”保养哪辆”，而不是猜一辆），第三层主动服务（没人问，系统自己发现护照快过期了并预警）。

分清它们的关键在第三层：主动服务是无指令的，LoCoMo 的任何一类问题都装不下它——问答题永远有一个提问者，而主动服务的起点恰恰是没人提问。作者自建尺子，就是为了量出 LoCoMo 够不着的那一段。

记忆三问：三套正交的分类体系

书里给了三套分类体系，我一开始只说出了两套。它们各自回答一个问题，而且互相正交、可以自由组合：

分类体系 回答的问题 具体类别
记忆层次 存在哪里？ 轨迹（当前会话）、用户长期记忆（跨会话）、业务状态（任务阶段）
存储格式 怎么存？ Simple Notes、Enhanced Notes、JSON Cards、Advanced JSON Cards
认知类型 存什么？ 情景记忆（具体事件）、语义记忆（一般知识）、程序记忆（行为流程）

轨迹和长期记忆的分野，原文有一句我很喜欢的对照：轨迹是流水账，长期记忆是档案。轨迹 append-only、不可变；长期记忆被反复改写、合并、淘汰。存什么的三个类型也好分：”订了下周五去东京的航班”是情景，”用户是素食者”是语义，”先搜直飞→确认座位→用常旅客号”是程序。

正交的意思是：一条”用户偏好靠窗座位”的语义记忆，可以用 Simple Notes 存在长期记忆里；一段订票流程的程序记忆，也可以用 Advanced JSON Cards 存。选格式看工程，选类型看业务。

四种存法，是一条修 bug 链

同一条信息（”我在 TechCorp 任高级工程师，负责推荐系统，带 5 人团队”），有四种存法。我第一次学的时候把它们当成四个并列的选项去背，越背越乱；后来把它们看成一条链才真正记住——每往右一步，都是在修上一步的 bug，同时引入新的 bug。

四种记忆策略对比：简单性递减，表达力递增

  1. Simple Notes 拆成原子事实，一条一行：更新是 O(1) 的，改”职位”那行就行，便宜。但关联性丢了——三条碎片之间没有任何联系，问”他的职业背景”要靠模型现场拼图，而且拼的时候可能把不同人的碎片拼到一起。
  2. Enhanced Notes 存整段叙事：语义完整，读到一段就拿到全部上下文。但同一个事实会在多个段落里重复出现，改一处要记得改所有处，漏一处，记忆库就自相矛盾。
  3. JSON Cards 三层结构化（类别→子类别→键值）：改 work.position.title 一个字段，别的不动，更新终于安全了。但它是刚性分类——我卡住的地方就在这。我以为”周末用 Python 开发个人项目”存不好是因为”信息不结构化”，错了：这条信息的三个维度（时间偏好、技术偏好、活动类型）个个明确，问题是它横跨三个类别，刚性单分类塞不下。问题不在信息，在容器。
  4. Advanced JSON Cards 在结构之上加元数据：backstory（为什么存这条）、person（这条信息关于谁）、relationship（这个人和用户什么关系）、时间戳。它解决的是理解层面的歧义——“张医生”是用户自己的牙医，还是用户父亲的心脏科医生？简单键值存储在”帮我安排家人的年度体检”这种请求面前根本无法区分为谁。代价：每次写入要模型做更多提取判断，生成维护成本高。

我在验收练习里自己拆过一条信息，用它说明第 1 步的坑最直观：”用户提到他母亲有高血压，最近开始服用氨氯地平”——用 Simple Notes 拆成两条原子事实，隐患立刻出现：这两行和记忆库里的其他行没有关联，三个月后用户说”我爸头晕想买降压药”，检索命中”服用氨氯地平”时，这条记忆没有”关于谁”的字段，母亲、父亲、用户自己的信息会混。这就是为什么健康这种关键信息值得用 Advanced 存：person 填”母亲”，relationship 填 family/mother，backstory 填”哪次对话、什么场景提到的”——注意 backstory 填的是出处，不是事实的复述。

四种存法的落点不是选一个最强的，而是混合：关键且少量的信息（偏好、家人关系、健康）用 Advanced 保证可检索可推理；大量且非关键的对话事实用 Simple 控制成本。

第五种存法：把记忆写成代码

四种格式本质上都是文本。文本擅长召回单条事实，但有三类活它干不了，只能交给 LLM”心算”：聚合（用户今年出国几次）、冲突检测（在用药和过敏史逐条交叉比对）、约束执行（护照有效期距出发日期不足 180 天就预警）。

心算的问题不是”模型完全不会算”，而是不确定：同一道题两次答案可能不同，长列表会数漏，算错了不留痕迹。数漏一次出国次数无所谓，过敏药漏检一条是医疗事故。这三类活要求每次结果一致、可审计、零遗漏——概率模型给不了这个保证。

书里给的第五种形态是 User as Code（作者自己的论文）：把用户状态改成带类型的可执行对象，把规则写成普通函数。数”2025 年出国几次”是一条查询语句；过敏药冲突是一个双重循环；护照检查是状态更新后自动跑的一个函数——不等用户来问。

状态怎么维护？书里用了数据库的味道很浓的方案：预写日志 + 检查点。会话结束后先把事实追加到只增日志，再定期从完整日志重建带类型的状态。我一开始以为这是为了省开销、批量处理，其实方向反了——日志是真相源，状态是派生缓存：

  • 重建代码有 bug、状态算错了？修好代码，从检查点重放日志，正确状态重新出来，证据一步没丢。
  • 反例是 Mem0 v2：写入时直接 UPDATE/DELETE，一次错误的更新不可逆地丢掉原始数据，错了就永远错了。v3 改成仅追加写入、把冲突判断挪到检索时，LoCoMo 从 71.4 涨到 92.5——教科书级的教训。

什么样的信息适合写成代码？我拷打自己得出的判据：带类型的数据 + 可判定的规则。护照有效期（date 类型 + 180 天规则）适合；常旅客号适合结构化存储；”用户是素食者”可以结构化成布尔字段，但用途只是订餐时召回提醒，不需要计算；”用户最近情绪低落””喜欢性价比高的产品”是模糊的主观状态，写不出判定函数，留在文本里。

而这一节真正让我觉得值钱的是一个时机问题：文本格式的记忆，计算发生在使用时，而且没有触发点——用户直接说”帮我订下周五去东京”，模型大概率根本不会想起来去算护照有效期。代码化的记忆，计算发生在写入时/事件时，由系统保证执行。算得准只是副产品，一定算才是本质——第三层”主动服务”的工程地基就在这里。

收进一张卡片

这一章前半部分读完，能收进一张卡片：

  • 记忆三问：存在哪里（轨迹/长期记忆/业务状态）、怎么存（四种格式）、存什么（情景/语义/程序），三套体系正交
  • 四种存法是一条修 bug 链：Simple 改得快拼不回，Enhanced 拼得全改不动，JSON Cards 解决”改”，Advanced 解决”理解”，生产上按”关键且少量→Advanced，大量且非关键→Simple”混合
  • 聚合、冲突检测、约束执行不能靠 LLM 心算；User as Code 用带类型状态 + 规则函数 + 预写日志（日志是真相源，状态可重建）
  • 代码化的判据：带类型的数据 + 可判定的规则；回报：计算时机从使用时移到写入时，主动服务从”祈祷模型想起来”变成”系统保证会跑”

下一步

  • 本章另一半 RAG（分块、稠密/稀疏嵌入、混合检索、RAPTOR/GraphRAG、智能体化 RAG）还没读，读完出下篇
  • 本章 知识图谱页已上线，随精读进度持续更新节点和笔记关联
  • 实验债清单：user-memory（三层次评估 + 四种模式对比）、log-sanitization

参考来源