四种格式按什么维度递进？
- 维度: 同一条用户信息可用的粒度与结构复杂度;
- 顺序: Simple Notes → Enhanced Notes → JSON Cards → Advanced JSON Cards，代表渐进式的记忆表示;
- 说明: 与 文档分块 遇到的是同源问题——表示粒度越粗或越长，越难精确表达单一含义;
Simple Notes 的取舍是什么？
- 形态: 每条记忆是一个最小的、不可再分的事实（“用户邮箱：john@example.com”）;
- 优势: 开销极低，支持 O(1) 操作（耗时固定、不随数据量增长的操作）;
- 代价: 信息关联性完全丢失——“在 TechCorp 担任高级工程师，负责推荐系统开发”被分解为三个独立事实，同一份工作的内在联系被割裂;
- 后果: 需要综合多条信息才能回答的查询，系统要重新拼凑碎片;
Enhanced Notes 的取舍是什么？
- 形态: 每条记忆保存为包含完整上下文的段落（“用户在 TechCorp 担任高级软件工程师，专注于机器学习已有三年，目前领导一个推荐系统项目，团队 5 人”）;
- 优势: 保留信息的叙事结构，语义完整而丰富;
- 代价: 存储冗余（相同信息在多个段落中重复）、更新复杂（属性变化需重写多个段落）;
JSON Cards 的取舍是什么？
- 形态: 三层嵌套结构（类别→子类别→键值对），如
personal.contact.email、work.position.title;
- 优势: 支持部分更新——修改
work.position.title 不影响 work.company.name; 结构可预测、可扩展;
- 代价: 刚性结构假设信息可以清晰分类;
- 反例: “周末用 Python 开发个人项目”同时涉及时间偏好、技术偏好与活动类型，强制归入单一类别会丢失多维性;
Advanced JSON Cards 增加了什么？
- 新增字段: 信息来源的叙事背景（backstory）、主体身份（person）、与用户的关系（relationship）和时间戳;
- 核心思想: 同一条信息在不同场景下可能有完全不同的含义——“张医生”可能是用户自己的牙科医生，也可能是用户父亲的心脏科医生;
- 解决的消歧问题: 用户可能有多个身份（为自己、为父母、为子女），简单的键值存储无法准确区分;
- 机制: backstory 提供信息的获取上下文（“为什么”存储这条信息），person 与 relationship 建立清晰的实体模型（“为谁”存储）;
- 例子: 用户说“帮我安排家人的年度体检”时，系统通过 relationship 识别所有家庭成员，通过 backstory 了解健康历史;
- 代价: 生成和维护成本较高;
实验中四种格式表现如何？
- Simple Notes: 以最低的生成成本通过第一层“基础回忆”的多数用例，但在需要综合多条信息、区分同名实体的第二、三层用例上频繁失分;
- Advanced JSON Cards: 在涉及消歧和跨会话关联的用例上表现最好，代价是每次会话结束后的记忆维护调用明显更贵、更慢;
- 项目形态:
user-memory 在统一接口下实现四种模式，每种都提供记忆生成（分析会话、写入记忆）与记忆检索（按当前问题取回相关记忆）的完整实现，运行时通过配置切换;
- 中间两种: 表现位于两个极端之间，体现简单性与表达力的连续取舍;
实践中如何选择？
- 关键且少量: 用户偏好、关键人物关系用 Advanced JSON Cards，以保证可检索性;
- 大量且非关键: 对话事实用 Simple Notes，以降低成本;
- 生产常态: 混合模式——同一 Agent 内不同类别的信息走不同路径;