用户记忆系统
1. 两个尺度：个人记忆与共享知识
单次交互的上下文管理解决「这一轮模型看到什么」；更难的问题是：对话结束后，Agent 还能不能记住用户、记住知识。
持久化记忆可以从两个尺度理解：
- 用户记忆：针对单个用户的个性化记忆------偏好、习惯、需求，构建专属于该用户的知识模型；
- 知识库：面向所有用户共享的集体知识------行业法规、公司流程、专业文档。
前者让 Agent 成为「懂你的助手」，后者让它成为「领域专家」。两者解决的是同一个问题，只是尺度不同：一个关注个体，一个关注群体。它们共用许多底层技术（向量检索、知识压缩），也面对同样的麻烦：信息冲突、知识过期、检索不准。
图 1：用户记忆与知识库的知识脉络
2. 记忆不是聊天记录
要让 Agent 跨会话提供个性化服务，需要一层持久的用户记忆。它不保存每句对话，而是用额外的 LLM 调用提取、压缩并审查对未来有用的事实；这与只在当前窗口生效的上下文学习不同。
一段订票对话：
text
User: Help me book a flight to Tokyo next Friday. I prefer window seats
and I'm vegetarian, so I'll need a special meal.
Agent: [calls flight_search tool, returns 3 options]
User: Yes, and use my United MileagePlus number 12345678.对话结束后，框架调用一次专门的 LLM 提取值得长期记住的信息：
text
Extracted memories:
- User prefers window seats (preference)
- User is vegetarian, needs special meals on flights (dietary restriction)
- User's United MileagePlus number: 12345678 (loyalty program)
- User has travel plans to Tokyo (recent activity)提取结果要满足三条规则：选择性 （丢弃「搜索返回 3 个选项」这类短期细节）、抽象化 （把本次「靠窗座位」归纳为长期偏好）、结构化（用可检索字段保存事实）。
3. 怎样算「好记忆」
在动手设计之前，先要回答「什么样的记忆系统算好」。公开基准中，LoCoMo 构造了平均约 300 轮、最多 35 个会话的超长多轮对话，通过问答、事件摘要、多模态对话生成考察长程记忆。
综合各类基准与商业产品实践，用户记忆能力可以归纳为八项：
- 个人信息保留：记住身份等长期信息；
- 偏好追踪：跟踪长期偏好；
- 上下文切换：多个话题之间保持连贯；
- 记忆更新：新信息与旧信息矛盾时正确处理；
- 多会话连续性：跨会话保持知识；
- 复杂思考：联合多个记忆片段推理，例如用户对花生过敏时，推荐泰国菜要提醒花生成分；
- 时间感知：记住日期、理解相对时间、做时间计算；
- 冲突解决：识别并处理记忆之间的不一致。
更贴切 Agent 场景的是一个三层次框架：
- 基础回忆：准确存储并检索用户直接提供的、结构化、无歧义的信息。如「我的会员号是 12345」，需要时精确返回。这是基本可靠性。
- 多会话检索：面对来自不同对象、不同时期的多段会话，能检索出所有相关信息并推理。用户有两辆车、要求「为我的车预约保养」时，系统要找出两辆车的信息并主动询问是哪一辆；询问贷款状态时，要分辨正在履行的有效合同，忽略过去咨询但未生效的报价；取消「洛杉矶之旅」时，要理解旅行是复合事件，关联机票与酒店。
- 主动服务：综合多个会话、甚至很久以前的信息，提供预见性帮助。订国际航班时关联数月前存储的护照信息，发现即将过期并预警；手机损坏时整合手机保修、信用卡附加保修、运营商保险；报税季主动搜集过去一年的股票销售、自由职业收入、房产税文件。这要求系统在没有明确指令时，主动规避问题、整合信息。
评估可以按三层各构造测试用例：第一层通常单会话，第二、三层由跨时间、跨对象的多段会话组成。流程是：根据第一个会话生成记忆，再根据记忆与下一个会话修改记忆（只能访问记忆、不能回看原始对话），直到处理完所有会话；最后根据记忆回答新问题，用另一个 LLM 对比参考答案打分。
4. 记忆的层次
记忆设计可以拆成三个维度：放哪里、怎么存、存什么。先看「放哪里」。
为了让 Agent 既能高效处理当前任务，又能跨会话提供个性化服务，记忆要分层：
- 轨迹（Trajectory）：一次运行的完整历史------用户消息、模型回复、工具结果，按时间顺序追加、只增不改。它为当前决策提供即时上下文：「刚才说了什么」「用户如何回应」「工具返回了什么」。
- 用户长期记忆：跨会话、跨实例的持久化存储，通常以键值对与用户 ID 绑定，保存偏好、历史摘要与提取的知识点。Agent 通过特定工具显式读取和更新，实现跨会话连续性。
- 业务状态：开发者定义的高层状态抽象，表示任务的逻辑阶段（「需要澄清」「处理中」「等待付款」「完成」）。在事件驱动架构中尤其重要。
轨迹是流水账，长期记忆是档案：前者按时间追加、不修改；后者会被反复改写、合并、淘汰。分层设计既保证当前任务的高效（依赖轨迹），又提供长期个性化（依赖长期记忆）。
5. 四种存储格式
同一条用户信息，可以用不同粒度与结构表示：
图 2：四种记忆策略对比
Simple Notes：每条记忆是一个最小、不可再分的事实，如「用户邮箱：john@example.com」。开销极低，支持 O(1) 操作；但信息关联性完全丢失------「在 TechCorp 担任高级工程师，负责推荐系统」被拆成三个独立事实，同一份工作的内在联系被割裂。综合多条信息的查询需要重新拼碎片。
Enhanced Notes：每条记忆保存为包含完整上下文的段落。同样的工作信息可以写成：「用户在 TechCorp 担任高级软件工程师，专注机器学习三年，目前领导一个 5 人推荐系统项目。」语义完整、叙事结构保留；代价是存储冗余、更新复杂------属性一变要重写多个段落。
JSON Cards ：三层嵌套（类别 → 子类别 → 键值对，如 work.position.title），模拟人类分类。支持部分更新（改职位不影响公司名），可预测、可扩展；但刚性结构假设信息能清晰分类------「周末用 Python 开发个人项目」同时涉及时间偏好、技术偏好、活动类型，强制归入单一类别会丢失多维性。
Advanced JSON Cards：从信息存储走向知识管理。每张卡片不仅记录事实，还加入来源叙事背景（backstory）、主体身份（person）、与用户的关系（relationship）和时间戳。核心思想是：同一条信息在不同场景下含义可能完全不同------「张医生」可能是用户自己的牙科医生，也可能是用户父亲的心脏科医生，脱离情境无法正确理解。
这种设计解决了传统系统的消歧问题。用户可能有多个身份（为自己、为父母、为子女），简单键值存储无法区分。backstory 提供信息获取上下文（「为什么」存），person 与 relationship 建立实体模型（「为谁」存）。用户说「帮我安排家人的年度体检」时，系统可通过 relationship 识别所有家庭成员，通过 backstory 了解健康历史。代价是生成与维护成本较高。
实践中的选择标准：关键且少量 的数据（偏好、关键人物关系）用 Advanced JSON Cards 保证可检索性；大量且非关键的对话事实用 Simple Notes 降低成本；多数生产系统采用混合模式，不同类别信息走不同路径。
6. 三套分类体系的关系
记忆设计里同时存在三套分类，容易混淆：
| 分类体系 | 回答的问题 | 具体类别 |
|---|---|---|
| 记忆层次 | 存在哪里 | 轨迹、用户长期记忆、业务状态 |
| 存储格式 | 怎么存 | Simple Notes、Enhanced Notes、JSON Cards、Advanced JSON Cards |
| 认知类型 | 存什么 | 情景记忆、语义记忆、程序记忆 |
三套体系正交，可以自由组合：一条「用户偏好靠窗座位」的语义记忆，可以用 Simple Notes 存在长期记忆中；一段「先搜直飞 → 确认座位 → 用常旅客号」的程序记忆，可以用 Advanced JSON Cards 存储。格式选择取决于工程需求（简单性与表达力的取舍），类型选择取决于业务场景（记事实、事件还是流程）。
7. 补记
用户记忆最容易被做成「把聊天记录存下来」。真正有价值的记忆是经过提炼的稳定信息：偏好、约束、关系、关键事实。原始对话是证据，记忆是结论；把两者混在一起，既贵又难检索。
另一个判断是：不要追求「记住一切」。记忆的价值取决于「未来会不会用到」，而不是「当时有没有发生」。选择性丢弃短期细节、把具体事件抽象成偏好，往往比全量保存更有效。