Agent 记忆保留与清理策略：该存多久、什么时候该忘

设计 Agent 记忆系统时，大多数讨论都停在”怎么存”——用向量数据库还是结构化文件、分几种记忆类型（这部分可以看AI Agent 记忆系统设计）。但一个记忆系统跑上几个月之后，真正决定它好不好用的往往不是存储方案，而是清理策略：什么该留、什么该过期、冲突了怎么办。这篇文章专门讲记忆的生命周期管理，不重复讲记忆分类和存储架构。

一、为什么”只存不清”会拖垮 Agent

记忆系统上线初期效果通常很好，因为记的东西不多，检索结果也准。问题出现在几个月后：

检索噪声增加。 记忆条目越多，语义检索召回的候选也越多，其中过时、矛盾、无关的条目占比上升，稀释了真正有用的记忆的权重。

成本线性增长。 每次调用如果都要把相关记忆拼进上下文，记忆库越大、单次调用的 Token 消耗越高，即使只召回 Top-K，索引维护和 embedding 存储的成本也在涨。

过时信息比没有信息更危险。 一条”用户当前用的是 v1.2 版本”的记忆，在用户升级到 v2.0 三个月后如果没被清理，会让 Agent 给出基于错误前提的回答，而这种错误往往比”不知道”更难被用户发现。

这三个问题指向同一个结论：记忆系统需要主动的清理机制，而不是无限追加。

二、给记忆分配 TTL（过期时间），而不是让它永久存在

不是所有记忆都该同等对待。按记忆内容的”易变性”分级设置过期时间是最直接的做法：

记忆类型	典型内容	建议 TTL	理由
事实性长期偏好	用户的角色、语言偏好、职业背景	不过期，人工确认后更新	变化频率极低
项目/任务状态	当前在做的任务、进度、阻塞项	7-30 天，或任务标记完成时立即失效	状态类信息天然有时效性
环境/版本信息	用户用的工具版本、配置细节	与实际检测同步刷新，检测不到就标记不确定	容易过时且难以自我发现过时
一次性上下文	当前对话里提到的临时细节	会话结束即清理	跨会话保留价值很低，且占用检索资源

关键设计点：过期不等于删除。到期记忆可以先降权（检索时排到后面）或标记为”待确认”，而不是直接物理删除——避免误判导致有用信息被误删且无法恢复。

三、记忆冲突：新旧信息打架时怎么办

记忆系统运行久了必然会出现冲突：用户说过”我不喜欢用表情符号”，三个月后又说”以后可以适当用 emoji”。常见的三种处理策略：

时间优先（Last Write Wins）：新记忆覆盖旧记忆，实现简单，但如果新记忆是误判（比如临时开玩笑说的话），会污染长期偏好。
显式确认后覆盖：检测到冲突时先不覆盖，下次交互中用一句话向用户确认，确认后再更新。交互成本高，但准确率也高，适合影响面大的记忆（比如安全相关的规则）。
共存 + 场景标记：不覆盖，而是给两条记忆都打上适用场景标签（“正式场合不用 emoji” vs “轻松对话可以用”），让检索阶段按场景选择。这个方案实现复杂度最高，但避免了信息丢失。

选哪种策略不是技术问题，是产品设计问题——取决于记错一次的代价有多大。代价低（比如语气偏好）可以选时间优先；代价高（比如权限、安全类记忆）必须走显式确认。

四、用户主动要求”忘记”时，必须做到真删除

除了系统自动过期，用户明确要求删除某条记忆或清空记忆库时，这不是一个可以打折扣的功能需求，而是合规底线：

删除请求要能定位到具体记忆条目，而不是只能”清空全部”——用户经常只想删掉某一条错误记录，而不是连带删掉所有有用的记忆。
物理删除，不是软删除：如果记忆存在向量库里，删除操作要确认对应的 embedding 也被清除，而不只是从展示层隐藏。软删除残留的数据在下次全量重建索引或数据导出时可能重新出现，这是真实发生过的合规事故类型。
删除操作要有确认后的书面回执（哪怕只是一句”已删除以下 N 条记忆”），让用户能验证操作确实执行了，而不是静默处理。

这一条本质上是把 Agent 记忆系统当成一个小型的用户数据系统来对待，删除权是基本要求，不是加分项。

五、一个简单可落地的清理流程

不需要一开始就设计复杂的分级系统，从这个最小流程起步：

每条记忆写入时打上类型标签（长期偏好 / 任务状态 / 环境信息 / 临时上下文）和写入时间。
定时任务（比如每周跑一次）扫描过期记忆，先降权而不是删除。
降权后连续 N 个周期未被检索命中的记忆，进入待删除队列。
待删除队列人工或规则复核后清理，同时保留一份操作日志，方便追溯误删。
用户主动删除请求走独立的即时通道，不进入上述定时流程，必须实时生效。

这个流程的核心思路是先降权、观察、再删除，给系统留出”这条记忆是不是真的没用了”的验证窗口，避免过快清理导致有用信息丢失。

六、相关阅读

如果你的 Agent 记忆系统需要跨模型迁移或做多供应商容灾，YoTradeApi 提供统一 API 入口，切换底层模型时记忆层逻辑不需要跟着重写。