记忆怎样形成、更新和撤回
一句话收获：记忆写入比读取更谨慎，所有长期影响都需要来源和生命周期。
这个场景在解决什么问题
这个场景要讲清"记忆"的完整生命周期——从一条对话信息怎么变成记忆，到记忆怎么更新、冲突怎么处理、最后怎么撤回。原文的做法是让一条对话信息从"候选"走到"准入"，再经历"更新"和"撤回"。它值得单独学，是因为大多数人只关心"读记忆"，而真正容易出事的是"写记忆"——写错、写冲突、撤不干净，都会留下长期隐患。
先理清这条判断链（文字版）
这个场景是一条"从候选到准入、再到更新和撤回"的生命周期链：先看模型提取的候选怎么形成，再看它怎么被准入并选一种表示方式，接着看新旧信息冲突时怎么处理，最后看过期信息怎么穿透所有派生层撤干净。验收标准是——能不能说清"写入为何比读取更谨慎、撤回为何要穿透所有层"。
- 先看候选形成：模型从轨迹提取的偏好/事实，只能先放候选区。
- 再看准入与表示：按未来用途选字段、摘要、卡片或方法制品。
- 接着看更新与冲突：新旧冲突时按属性更新、事件追加或来源并存。
- 最后看过期与撤回：主存储、索引、摘要、缓存、新任务同步失效。
逐层详解
第 1 步：候选形成
原文：模型从轨迹提取可能有用的偏好或事实，先放入候选区。
白话：模型从对话轨迹里提取出"可能有用"的偏好或事实，但只能先放进候选区，不能直接进长期记忆。
类比：像面试官面试时，先在心里记下"这人好像更喜欢远程办公"这种初步印象，但要等核实确认后才会写进正式档案。
举例：用户说了一句"我一般上午开会效率高"，模型把它提取成一条候选记忆"用户偏好上午开会"，先放候选区，等待进一步确认。
为什么重要：模型推断不能直接进入长期记忆——模型说的话是推断，不是事实，直接进长期记忆会把推测当成事实固化下来。
怎么验证（证据点）：
- 来源轨迹
- 主体明确
- 置信与敏感性
别踩的坑（边界）：候选出现不证明信息真实或应长期保存——出现一条候选，不代表它就是真的、也不代表它值得长期保存。
落地检查：先区分已确认事实和模型推断——落地时给每条候选打标签：这是用户明说的"已确认事实"，还是模型"推断"出来的，两者待遇不同。
第 2 步：准入与表示
原文：系统按未来用途选择字段、摘要、卡片或方法制品。
白话：系统根据这条信息"将来要拿来干什么"，选择用哪种形式存——字段、摘要、卡片、还是方法制品。
类比：像归档文件时先问"这资料以后是查精确值、还是看个大概、还是要照着执行"，再决定是存成表格字段、存成一段摘要，还是存成一页操作卡。
举例：用户偏好"上午开会"这种简单偏好，存成结构化字段「会议时段偏好=上午」；而"用户喜欢报告先看结论再看细节"这种复杂偏好，可能存成一张偏好卡片。
为什么重要：不同记忆需要不同表示和权限——用途不同，存储形式和权限就不同，不能一刀切。
怎么验证（证据点）：
- 用途明确
- 用户确认
- 保存范围明确
别踩的坑（边界）：结构化不等于内容正确——存成字段只是形式整齐，不代表内容就是对的。
落地检查：准入要同时检查事实和未来影响——落地时准入前问两个问题：这是不是事实？存进去以后会不会有长期影响（比如隐私、敏感信息）？
第 3 步：更新与冲突
原文：新信息与旧信息冲突时，按属性更新、事件追加或来源并存处理。
白话：当新信息和旧记忆冲突时，不能简单地"后写的覆盖先写的"，而要按信息类型选策略——属性类就更新、事件类就追加、来源不同就并存。
类比：像改通讯录，如果新电话只是"号码变了"就更新；如果是一条新发生的事件就追加一条记录；如果两个来源说的不一样，就把两个来源都留着，而不是随便删一个。
举例：用户改了偏好"现在下午开会效率高了"，这是属性类，就更新字段；而"3 月 5 日用户提到要搬家"是事件类，就追加一条新事件，而不是覆盖掉旧事件。
为什么重要：最后写入覆盖不能作为通用规则——"新的直接覆盖旧的"这条简单规则在很多场景是错的，会丢历史、会掩盖冲突。
怎么验证（证据点）：
- 旧值保留
- 新来源记录
- 冲突可见
别踩的坑（边界）：时间更新不自动证明新来源更权威——"信息是新的"不等于"它更可信"，可能只是某人后来说了一句错话。
落地检查：更新语义随信息类型变化——落地时为不同类型定不同的更新规则：属性更新、事件追加、来源并存，别用统一的"后写覆盖"。
第 4 步：过期与撤回
原文：主存储、索引、摘要、缓存和新任务同步失效。
白话：要撤回一条记忆，不是删掉主记录就完事，还要让它的索引、摘要、缓存、以及新任务里用到的地方一起失效。
类比：像撤下一本错版教科书——光把仓库里的书删掉没用，还得让书店下架、让已经发出去的摘抄作废、让老师备课不再引用，才算真撤干净。
举例：用户撤回"偏好上午开会"这条记忆，除了删掉主记录，还要让索引不再召回它、让缓存里的旧摘要失效、让新的排期任务不再引用这条偏好。
为什么重要：撤回必须穿透所有派生层——因为一条记忆会派生出索引、摘要、缓存等多个副本，只删一处等于没删干净。
怎么验证（证据点）：
- 主记录失效
- 索引不再召回
- 新任务不再使用
别踩的坑（边界）：删除一张表记录不证明撤回完成——删了主表那条，索引里、缓存里、摘要里可能还留着，还会继续影响新任务。
落地检查：生命周期以未来任务不再受影响为准——落地时把"撤回完成"的标准定为：未来新任务不再受这条记忆影响，而不是"主表里那条没了"。
落地可行性小结
本场景涉及的技术栈：记忆候选提取、记忆准入流程、多种表示形式（字段/摘要/卡片/方法制品）、更新冲突策略、以及"撤回穿透"（主存储 + 索引 + 摘要 + 缓存同步失效）。真实落地做法：给记忆加"候选区 → 准入 → 表示"的写流程，写比读多一道确认；冲突时按类型选策略；撤回时用统一的失效机制（如统一版本号/失效标记）穿透所有派生层。要检查的：每条记忆是否有来源和置信度、冲突是否可见、撤回是否让索引和缓存一起失效。常见坑：模型推断直接入库、用"后写覆盖"统一处理冲突、只删主表记录就以为撤回完成。
回顾
- 记忆写入比读取更谨慎：候选 → 准入 → 表示，多道关卡。
- 模型推断不能直接进长期记忆，要先区分事实与推断。
- 冲突处理不能一刀切"后写覆盖"，要按属性更新/事件追加/来源并存选策略。
- 时间新不等于来源更权威。
- 撤回要穿透主存储、索引、摘要、缓存和新任务，以"未来任务不再受影响"为准。