删除记忆

删除前先确定范围

处理删除请求前，应明确：

问题	说明
删除谁的记忆	确认 Project、用户和 Session 边界。
删除什么内容	是某条 Message、某组 Facts、某条 Summary，还是某个主题下的全部内容。
删除原因	用户请求、合规要求、数据错误、过期归档或业务策略。
是否保留审计记录	某些场景需要保留删除操作记录，但不再让内容参与召回。

推荐处理流程

1. 根据用户、Session、query 或来源 ID 定位相关 Memory。
2. 找到支撑 Summary 的 Facts 和来源 Message。
3. 对应内容进入 deleted 或 archived 状态。
4. 更新检索索引或过滤条件，避免后续 Query Memory 继续召回。
5. 保留必要的审计记录，例如删除时间、操作者和原因。

管理状态

Summary 的治理状态可以表达删除前后的不同阶段：

状态	适用场景
active	当前有效，可以参与召回。
deprioritized	信息仍保留，但降低召回优先级。
archived	信息归档，默认不参与普通召回。
deleted	信息已删除或软删除，不应继续参与召回。

删除请求通常应使相关 Summary 不再处于 active。如果 Facts 或 Message 仍需用于审计，也应确保它们不会继续进入普通 Agent 上下文。

不要只删除 Topic

Topic 是召回入口，不是事实本身。只删除 Topic 可能导致 Summary 或 Facts 仍然通过其他路径被召回。

更稳妥的做法是从来源开始处理：

Message / Facts -> Summary -> Topic

这样可以同时处理证据、长期摘要和主题关系。

接口边界

当前公开文档不承诺一个稳定的 DELETE /memory endpoint。不同部署可以通过后台治理 API、retention job、forget pipeline 或管理员工具执行删除。无论具体接口如何，外部产品都应保证：

• 用户删除请求能定位到明确范围。
• 被删除内容不再进入普通召回。
• 删除操作有可审计记录。
• 业务数据库中的强一致数据由业务系统自行删除或脱敏。

检查结果

删除或归档后，使用相关 query 再次查询 Memory。期望结果是：

• 普通 Query Memory 不再返回被删除内容。
• 如果保留审计数据，它不会出现在 Agent 可用上下文中。
• Topic 摘要不再暗含已删除的用户事实。

下一步

阅读 WebHooks 了解如何在写入和生成阶段加入清洗、审计和同步逻辑。