#0118 给AI Agent装一个遗忘曲线——基于引用频率的记忆衰减系统

type

Post

status

Published

date

Feb 15, 2026

slug

308a745569bb81e78fbfd5c2e74b5c9d

summary

你的 AI Agent 记忆管理，大概率是错的。不是说你没做持久化，也不是说你没做清理。而是你清理的逻辑——"写入超过30天就删"——本质上是一刀切。

给 AI Agent 装一个"遗忘曲线"——基于引用频率的记忆衰减系统

你的 AI Agent 记忆管理，大概率是错的。

不是说你没做持久化，也不是说你没做清理。而是你清理的逻辑——"写入超过30天就删"——本质上是一刀切。高频使用的关键记忆被误杀，没人碰的垃圾记忆反而还活着。这不叫记忆管理，这叫定时清垃圾桶。

问题是，垃圾桶不分贵重物品和废纸。

按时间淘汰，蠢在哪

大部分 Agent 框架的记忆层长这样：写入一条 → 带个时间戳 → 定期扫描 → 超期删除。简单粗暴，工程上零负担。

但你仔细想想这个场景：

用户三个月前告诉 Agent 自己对虾过敏。这条记忆被按时间淘汰了。下次 Agent 推荐餐厅，虾全席安排上。

用户昨天随口说了一句"今天好累"。这条记忆还活得好好的，占着位置。

时间维度是记忆重要性最差的代理变量。 一条记忆重不重要，跟它什么时候写入的关系不大，跟它被用了多少次关系很大。

你可能会说，那我加个重要性标签呗。问题来了——谁来标？让 LLM 在写入时判断重要性？它根本不知道这条信息未来会不会被反复用到。重要性是动态的，不是写入时能决定的。

人脑怎么干这事的

艾宾浩斯遗忘曲线，中学都学过。核心就一句话：不是按时间遗忘，是不复习就遗忘。

你背一个单词，第一天忘60%，第三天忘75%。但如果你第二天复习了一次，遗忘速度直接变慢。复习三四次之后，这个词基本就长在脑子里了。

换句话说，人脑的"淘汰机制"不是看这条记忆多久以前写入的，而是看它最近一次被调用是什么时候。经常被回忆的知识，"永远年轻"。长期不被回忆的知识，自然衰减直到消失。

这个机制优雅在哪？不需要任何人工判断。 用户不需要给记忆打标签，系统不需要猜测哪条重要。使用频率本身就是最好的重要性信号。

方案：给每条记忆加一个 ref 字段

想法很简单——给每条记忆追踪"最后一次被实际使用"的时间。我把它叫 ref（reference date），引用日期。

格式大概长这样：

💡 [P1][2026-01-15][ref

拆开看：

P1 — 优先级（后面细说）

2026-01-15 — 写入日期，记录这条记忆是什么时候创建的

ref — 引用日期，这条记忆最后一次被实际用到是什么时候

后面跟具体内容

淘汰逻辑不再看写入日期，而是看 ref 日期。ref 越新，说明这条记忆越活跃，越不该删。

优先级分层

不是所有记忆都该一视同仁。分三档：

P0 — 永不自动淘汰。 核心身份信息、安全规则、系统级配置。这些东西删了系统就废了，不参与衰减。

P1 — ref 超过90天淘汰。 用户偏好、长期习惯、重要但非致命的信息。三个月没被用到，大概率确实不重要了。

P2 — ref 超过30天淘汰。 临时信息、短期上下文、一次性指令。一个月没被引用，放心删。

💡 优先级在写入时确定，可以手动调整。但淘汰判断只看 ref，不看写入时间。

什么算"被引用"

这是整个方案最容易踩坑的地方。

不是每次加载就算引用。 很多 Agent 系统在每次对话开始时会批量加载记忆到上下文。如果加载就算引用，那所有记忆的 ref 永远是今天，衰减机制等于废了。

真正的"引用"必须满足一个条件：这条记忆实际影响了 Agent 的输出。

怎么判断？几种思路：

显式引用： Agent 在回复中明确提到了这条记忆的内容。比如说"您之前提到对虾过敏，所以我推荐了这家店"。

检索命中： 用 RAG 做记忆检索时，这条记忆被检索召回并注入了上下文。注意是"被召回"，不是"存在于索引中"。

决策依赖： Agent 的行为明显受到了这条记忆的影响，即使没有显式提到。这个判断成本高，一般用前两种就够。

💡 实际工程中，最简单的做法是在 RAG 检索召回时更新 ref。成本低，覆盖率够用。

向后兼容

已有系统里肯定有一大堆旧记忆，没有 ref 字段。怎么办？

回退策略：没有 ref 的，拿写入日期当 ref。

这意味着旧记忆会按写入日期来判断是否该淘汰。如果一条旧记忆确实还在被使用，它会在下次被引用时获得新的 ref，从此进入正常的衰减周期。如果它一直没被引用——那它本来就该被清理。

不需要迁移，不需要批量更新，零成本过渡。

衰减清理怎么跑

定时任务，每天跑一次就行。逻辑很简单：

扫描所有记忆条目

跳过 P0

对 P1，检查 ref 距今是否超过90天

对 P2，检查 ref 距今是否超过30天

超期的，标记删除或移入归档

💡 建议先做"软删除"——移到归档区而不是直接删。万一误判还能捞回来。跑稳了之后再改成硬删。

整个清理脚本的核心逻辑可能就二三十行。没有什么花活，纯粹是换了一个判断维度。

跑起来之后的效果

上了这套之后，几个变化很明显：

高频记忆永远保留。 用户反复提到的偏好、经常用到的工具配置，ref 一直在刷新，永远不会被淘汰。

低频记忆自然消失。 那些"三个月前的天气吐槽""某天的临时安排"，没人引用，自动衰减掉。

记忆池大小趋于稳定。 不再是只增不减或者暴力清空。活跃记忆保留，僵尸记忆淘汰，总量在一个合理范围波动。

不需要人工干预。 没有人需要手动打标签、手动清理、手动判断哪条重要。使用行为本身就是最好的筛选器。

本质上，这套系统把"管理记忆"这个问题从一个需要主动决策的任务，变成了一个自组织的过程。

一些你可能会想到的问题

Q：ref 更新会不会有性能问题？

每次引用就写一次日期，不会。你又不是每秒引用一万次。如果真到那个量级，按天去重就行——同一天内多次引用只更新一次 ref。

Q：P0/P1/P2 的阈值怎么定？

90天和30天是拍脑袋的起点。跑两周看看被淘汰的记忆里有没有误杀的，有就调长。实际操作下来，P1 用90天、P2 用30天对大部分场景够用。

Q：能不能更细粒度，比如引入引用次数？

能。你可以把 ref 扩展成 ref，最后一个数字是引用次数。次数越多，衰减越慢。但这会让逻辑复杂不少，建议先跑最简版本，确认方向对了再加。

Q：RAG 检索不准导致该引用的没引用怎么办？

这确实是个问题。如果你的检索召回率低，一些重要但表述特殊的记忆可能一直不被召回，ref 不更新，最终被误杀。解决办法是提高检索质量——这本来就是你该做的事，和衰减系统无关。

从遗忘曲线到认知架构

做这套东西的时候，有个想法越来越强烈：AI 的记忆管理和人脑的差异，可能没我们想象的那么大。

人脑不是硬盘。它不会忠实地存储每一个细节，然后等你来查。它一直在做筛选——用遗忘来筛选。被反复调用的神经通路越来越强，不被调用的越来越弱，直到断开。这不是 bug，是 feature。遗忘是认知效率的核心机制。

AI Agent 的记忆管理，本质上也需要同样的机制。无限存储不是答案。你给一个 Agent 塞十万条记忆，它的表现不会比精心维护的一千条好。信噪比才是关键，而遗忘是提高信噪比最自然的方式。

当然，AI 和人脑还是有本质区别。人的遗忘是不可逆的——忘了就是忘了，除非有外部线索触发残留记忆。但 AI 可以做"软遗忘"——归档而不是删除，需要时还能捞回来。这可能是 AI 记忆管理比人脑更优雅的地方。

另一个有意思的点：人脑的遗忘是无意识的，你控制不了自己忘什么。但 AI 的遗忘可以是有策略的——P0 保护机制就是一种"选择性不遗忘"。我们在用工程手段，重建一个本来属于生物系统的能力，同时避开了生物系统的局限。

说到底，给 AI Agent 做记忆管理，核心命题不是"怎么记住更多"，而是"怎么忘得更聪明"。

你的 Agent 系统，现在是怎么遗忘的？