Agent 长期记忆什么时候写入、纠错与删除？

写作助手今天记住一个偏好，明天就不用用户重说一遍。但这份便利也带来新责任：偏好可能只是一次例外，可能来自模型推断，可能被本人更正，甚至已经要求删除。长期记忆需要完整的写入、读取、纠错、过期和删除规则，不能只靠一个保存聊天摘要的数据库。

上下文图解释一次调用收到了什么；长对话压缩处理同一任务进行中历史过长的问题。长期记忆则是主动把一条记录放到用户或组织作用域，让它跨会话被再次取回。LangGraph 就把线程内历史与按命名空间存取的跨会话记忆分开。压缩摘要和旧聊天都不应自动升级成永久用户画像。

先判断候选信息是否值得下次再读

写入前问三个问题：它会改善哪项未来任务？描述的是谁？什么时候可能失效？给每条候选信息选去向：

候选信息	默认去向	理由
本人明确表示希望以后沿用的偏好	确认适用范围，再考虑限期保存	可以减少重复说明，但不能套用到所有任务
只服务本次订单或本轮对话的条件	留在本次会话或任务状态	一次条件不等于长期偏好
模型推断、检索网页或第三人对用户的描述	不当作用户事实持久化	说话者和证据都不足以支持这一步
敏感详情或凭据	默认排除在可选记忆之外	潜在便利不足以支持长期留存

可选个性化可以由产品设计成明确选择加入；团队仍需按适用地区判断处理依据与保留义务。用户在聊天中说过一句话，不等于同意把它永久保存。Google Cloud 的记忆生成文档也明确提醒：它尝试过滤敏感个人信息，但这种过滤并非万无一失；应用必须设置自己的写入关卡。

每条记忆都要有生命周期契约

只存一条范围明确的陈述，不存整段对话。记录应标明主体与租户、用途、适用范围、来源及时间、本人如何确认、敏感性、负责人、到期或复核事件、当前状态。可以保存受控原件的位置，但不要为了显得“有证据”又复制一份原件。

状态至少区分待确认、有效、争议中、已取代、待删除、已删除。只有在当前主体、租户和用途下仍有效且未过期的记录，才能进入后续请求。检查应发生在检索和组装 Prompt 之前。“喜欢简短回答”只是个性化资料，不能让 Agent 自动获得发邮件、读取私密文件或绕过审批的权力。

到期时间只是兜底，并不保证到期前一直正确。尽量设置事件复核：项目结束、角色变化、新表述发生冲突，或用户询问系统记得什么。没有维护人和移除路径的记录，不应进入长期存储。

纠错时先分清全局偏好和本次例外

新表述与旧记录不同时，先问它适用于本次任务、单一项目，还是今后的全部会话。本次例外可以和全局偏好并存；本人明确说“今后改成……”时，才在同一键和同一范围内取代旧值。给新旧记录建立关联，旧记录标记为已取代，并更新可能检索到旧值的索引。如果两条陈述都含糊，就先停用这条记忆，询问清楚。

不能只按时间判胜负。较新的工具返回可能不如本人早前确认的偏好可靠；模型摘要也可能丢掉一个“不”字。复核时展示双方来源、范围和时间。若记忆将影响重大决定，仍要回到相应业务系统核对，不能把它当成权威记录。

删除是一条跨存储面的流程

收到有效的忘记请求后，先阻断后续检索，再逐一找出可能复现它的地方：当前记忆库、语义索引、Prompt 或结果缓存、复制库、导出文件、历史修订、日志和备份。记录哪些已立即清除，哪些受到单独的保留规则约束，由谁负责，到何时不再可用。不能只调用一次删除接口，就对用户说“所有地方都已消失”。

这一差别有具体例子。Google Cloud Memory Bank 文档说明，删除当前 Memory 资源后，旧事实仍可能留在子级 MemoryRevision 中，直到修订自己的保留期限结束。当前资源查询返回 404，不代表历史修订也被清空。不同服务规则不同，应检查实际使用的产品。英国 ICO 的官方指南还讨论有条件的更正与删除权、下游接收者通知及备份处理；这是英国法规背景下的指南，不能写成全世界都能即时删除所有副本的承诺。

验证要从新会话、同一身份范围重新开始：查询当前库，使用合成标记做负向搜索，按约定核对修订和导出，再确认 Agent 不会继续使用已撤回内容。需要时再演练一次备份恢复，确保旧副本不会悄悄把已删除记忆重新激活。删除回执保存请求号、检查系统、负责人、时间和例外即可，不要把待忘记的敏感原值再抄入回执。

案例一：写作偏好更正，不把本次例外当成全局规则

一位作者明确要求助手记住：“以后内部简报用简洁的中文要点。”产品确认这条偏好只适用于内部简报，保存一条带复核日期的有效记录。下周，作者要求为某客户写正式英文信函。这是信函自身的要求，不会覆盖长期偏好。

后来作者又说：“今后所有内部简报改用中文段落，不要列要点。”这是同一范围内的长期更正。旧的“要点”记录标记为已取代，新记录指向旧 ID，检索索引随之更新。新会话测试要求写一份内部简报，预期出现段落；另一条测试仍要求按本次任务写英文客户信。若新旧偏好同时被取出，更正流程就没有完成。

案例二：误推断的健康信息不能继续跟随旅客

规划一次行程时，旅客只是在某餐馆询问低糖甜点。提取步骤却把“旅客患有糖尿病”写成持久记忆。旅客从未这样陈述，而且这是敏感健康推断。问题被发现后，应用立即禁止检索这条记录，排查它是否影响过其他会话，不让模型猜测这一推断“也许正确”。

旅客要求删除。负责人按记忆 ID 排查当前库、搜索索引、回答缓存、修订、导出，以及适用的日志和备份。新会话生成行程时不能再依据推断的健康状况做个性化；单独查询记忆库也不能返回它。若修订或备份依据已公布规则暂时留存，团队应记录访问限制和结束日期，并如实说明这一限制。删除回执不能再次写入健康推断的原文。

开放写入前先做四条测试

用合成资料验证：一次性要求只留在本次任务；本人明确的长期更正能在新会话压过旧值；另一个租户无法读取这条记录；删除后不会由搜索、缓存或备份恢复重新出现。除了看 Agent 回答，还要看底层读取结果。有时过期记忆已经被取回，只是恰好没有出现在流畅的回答中。

不适用边界

下方工作表是设计辅助工具，填写内容会保存在当前浏览器。请只用虚构标识和值，不要输入真实健康详情、身份信息、凭据或删除请求。生产记忆仍需要访问控制、正式保留期限、用户可用的更正和删除入口，以及按适用地区进行隐私评审。一条无法追踪和移除的记录，就不应被写入。