记忆系统系列

遗忘的艺术——什么时候该忘记

一、一个被忽略的问题

大多数记忆系统都在解决"怎么记住"。很少有人问：那些记住但不该记住的东西，怎么办？

我犯过这样一个错误。

几个月前，我开始让 Hermes 在每个会话结束时自动生成一个"会话摘要"。每次摘要包含：做了什么、关键决策、待办事项。存到 memory 里。

看起来很好。过了大概三周，memory 里堆了 40 多条记录。然后问题来了：

我在调试一个新的模块，Agent 检索了相关记忆——结果一次性拉回来 8 条，其中 5 条是几周前关于其他模块的记录，只是关键词碰上了。这些无关信息挤进了上下文窗口，占用了 Token，稀释了真正需要的信息。

更糟的是，其中一条旧的决策记录说："这里用方案 A，不用方案 B"。但实际上两天前我已经改为方案 B 了，新的决策记录也存在。Agent 看到两条冲突的记录，产生了困惑。

这不是记忆系统的故障，这是记忆系统的设计缺陷。 我只考虑了怎么存，没考虑什么时候该忘。

二、不遗忘的代价

没有遗忘策略，记忆系统会在不知不觉中积累三类问题。每一类我都踩过。

1. 上下文的信噪比下降

记忆越多，每次检索召回的无关结果越多。这些噪声挤进上下文，稀释了真正的关键信息。

记忆条目数	检索 10 条中相关数	Token 浪费（约）
20 条	7-8 条	可接受
50 条	4-5 条	50% 浪费
100 条	2-3 条	70%+ 浪费

这不是理论推演。我 40 条记录的时候就感觉到了——Agent 的回答开始变得"泛"，因为它要在有限的上下文里处理更多不相关的背景信息。

2. 决策冲突

同一个主题在不同时间点被记录了不同的结论。旧结论没有被标记"已过时"，新结论也没有声明"覆盖了旧结论"。

记忆 A（第 3 天）："这个接口不支持批量查询，每次只查一条"
记忆 B（第 15 天）："新增了批量接口，改成了数组参数"

问题在于：没有机制让 A 自动失效。

3. 检索成本增长

条目多了，每次检索（无论是向量搜索还是关键词匹配）的时间都在增加。精度在下降——因为候选集变大了。

三、三种遗忘策略

策略一：TTL（生存时间）

每条记忆带一个过期时间。到期后归档或删除。这是最直接、最可靠的策略。

记忆类型	建议 TTL	理由
日常 Bug 修复	30 天	短期有效，过时就没用了
临时决策	7 天	"今天先这样"类决策
架构/技术选型	90 天或更长	影响周期长，但也要被新决策覆盖
配置变更记录	永久（版本标记）	可能影响安全检查

策略二：重要性衰减

每条记忆有一个初始重要性分数。每次未被检索时分数递减。低于阈值就降级。

初始重要性：0.8（刚记录的 session，一般比较重要）
每 7 天未被检索：-0.1
低于 0.3：移出主动检索
低于 0.1：自动归档

这个策略的价值： 它让记忆系统"自适应"——真正重要的信息会被频繁检索，自然保持高分数；无关的信息逐渐沉底。

策略三：版本覆盖

当同一个主题有了新的决策时，旧决策不是追加，而是替换为新的版本。

旧：数据库扩展字段 → ALTER TABLE + 改 struct + 改 SQL
新：数据库扩展字段 → 加了一个步骤：还要改 routeTable

结果：旧记录被标记为"被 v2 覆盖"，新的 v2 成为活跃版本

关键： 替换不是删除，是版本化。旧版本保留但标记为"已过时"，不会进入主动检索。

四、遗忘和记忆是一枚硬币的两面

好的记忆系统 = 记住该记住的 + 忘记该忘记的

该记住的：架构决策、技术选型、已完成任务的结论
该忘记的：临时方案、已覆盖的旧决策、调试中间状态

你没有遗忘策略，就不算有记忆系统——你只有一个一直在膨胀的、越来越难用的存档。

五、实践建议

从今天可以做的三件事：

1. 给每条记忆加一个 TTL。 最简单的改进：30 天默认。
2. 每月做一次记忆清理。 打开记忆库，把超过 60 天的条目扫一遍。
3. 新决策覆盖旧决策时，显式声明。 不要让两条冲突的记忆同时存在。

---