先记住这个答案
用户纠正长期事实时，应先识别用户、事实类型、适用范围和生效条件，把新陈述与已有事实关联起来。确认属于替换后，可以保留历史版本并让当前有效指针指向新值，或按保留策略直接更新；检索只返回适用的当前事实。并发写入需要版本检查，模型推断与用户明确陈述也应区分，不能一律用“最后写入的文本获胜”处理所有冲突。
- 先区分永久变更与本次任务的临时条件
- 事实更新需要身份、范围、来源和版本
- 检索端也必须过滤已经失效的旧事实
为什么直接追加向量记录会反复出现旧答案
假设用户原来住在甲市，后来明确说已经搬到乙市。如果应用只把两句话分别写入向量库，后续查询住址时，两条记录都可能因为语义相近而被召回。让模型自行从模糊上下文中猜最新地址，会受到检索顺序、摘要质量和时间表达影响。
可以为事实建立稳定的用户范围与语义键，例如默认居住城市，并记录原始来源、确认状态、生效时间和版本。向量表示负责帮助查找相关信息，结构化字段负责判断哪条事实当前适用。历史记录是否保留是另一个数据保留决策，不能因为需要审计就让旧值继续作为有效事实返回。
搬家与临时收货地必须区别处理
用户说“我搬家到乙市了”与“这周出差请寄到乙市酒店”并不等价。前者可能更新长期地址，后者通常只影响特定时间和任务。系统应结合上下文确定范围；若要执行寄送等实际动作，仍需确认这次订单适用的地址，不能只凭一个宽泛的长期城市事实推导完整收件信息。
有歧义时可以先把新陈述记录为待确认信息，并保留原有效值，明确说明冲突。用户确认后再变更当前事实。这样的流程比无条件覆盖更容易解释，也避免将模型从闲聊里推测出的地点升级成用户已经认可的长期偏好。
并发更新与删除需要同时覆盖写端和读端
假设两个会话都从版本三读取地址，其中一个先写出版本四，另一个稍后结束又试图按旧上下文更新。写入时应检查预期版本或使用相应事务机制，冲突后重新读取并决定是否仍可应用，而不是让延迟完成的旧任务覆盖最新用户确认。
删除或失效操作也必须传播到检索流程。如果主记录已失效，但旧向量条目、缓存摘要仍可被召回，用户会继续看到错误信息。可以在检索后按有效状态和版本过滤，并维护索引同步任务。验证时应模拟并发纠正、删除后询问与缓存未刷新，而不只检查数据库里是否多了一条新记录。
容易答错的地方
- 认为时间戳越新事实就一定更可信
- 最新写入可能来自迟到任务或模型推断，而较早记录可能是用户明确确认。要结合事件时间、来源和适用范围判断；数据库插入时间不能独自代表事实可靠性。
- 把历史版本保留等同于当前检索可见
- 保存历史可以用于审计与追溯，但当前答案应该选择有效事实。若历史与当前数据都混在同一个检索结果中，又没有明确标注状态，就会把审计需求变成回答冲突。
面试官还会怎么问？
用向量相似度能否直接判断两个事实互相矛盾？
相似度只能提供候选，不能单独证明矛盾。默认住址与临时配送地址可能很相似却可以同时成立，需要比较实体、属性、时间和适用任务后再决定。
是否必须保留用户所有旧地址？
不必须，应按实际用途和用户的数据管理要求确定保留策略。即使保留，也要限制访问并区分历史状态；不应为了可能有用而无期限收集与当前服务无关的信息。
更新长期记忆后是否还要修改当前线程摘要？
如果当前线程仍会使用旧摘要中的事实，就需要让上下文装配明确采用新版本或更新相应摘要。否则存储层改对了，本次模型调用仍可能继续读取旧值。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。