智能体记忆垃圾回收:大规模工程化的策略性遗忘
每个生产环境的智能体团队最终都会构建同一个东西:一个无限增长的记忆存储、悄然退化的检索性能,以及在用户报告智能体引用了他们的旧工作、已弃用的 API 或三个月前取消的项目后,一场疯狂的冲刺来添加遗忘功能。业界已经在赋予智能体记忆上投入了巨大的努力。更困难的工程问题——对记忆进行垃圾回收——才是真正的生产可靠性所在。
与软件垃圾回收的类比不仅仅是隐喻。智能体记忆系统面临着同样的根本张力:你需要回收资源(上下文预算、检索相关性),同时不能销毁仍然可达(语义上与未来查询相关)的数据。解决这个问题的算法与你的运行时已经使用的算法惊人地相似。
为什么记忆累积是默认行为
智能体记忆系统几乎普遍遵循仅追加模式:检测到重要内容,嵌入它, 存储它,稍后检索它。这在前一百次交互中运行得很好。到第一千次时,失败模式就会出现——不是以崩溃的形式,而是以响应质量的悄然退化。
数据是惊人的。关于 LLM 智能体经验跟随行为的研究表明,使用"全部添加"记忆策略的智能体累积了超过 2,400 条记录,而其在医学推理任务上的准确率降至 13%。同样的智能体在使用主动记忆管理后,维持了 248 条记录并达到了 39% 的准确率。存储更少反而带来了 3 倍的性能提升。
这是因为 LLM 表现出经验跟随特性:它们会复制接收到的任何上下文的风格和质量。当你的记忆存储被过时、矛盾或低质量的条目污染时,智能体会忠实地再现这些特征。记忆系统不是有质量问题——而是有垃圾回收问题。
适用的 GC 算法
借鉴运行时垃圾回收为我们提供了一个有用的智能体记忆管理策略分类法。每种策略解决不同的失败模式,生产系统通常需要所有这些策略同时运行。
分代收集:基于时间的衰减层
最有效的生产模式模仿了分代 GC。记忆诞生在具有积极衰减的"新生代"中,只有在证明有用后才会晋升到更长寿的层。
实现使用 Weibull 衰减函数:w(Δτ) = exp(-(Δτ/η)^κ),其中自上次检索以来的经过时间决定了记忆的相关性分数。低于新鲜度阈值的记忆在到达智能体的上下文窗口之前就被修剪。但关键洞见是,并非所有记忆都应该以相同的速率衰减。
生产系统根据语义类别分配不同的生存时间值:
- 不可变事实(用户身份、系统约束):无限 TTL,永不回收
- 程序性知识(如何使用特定工具、工作流模式):长 TTL,数周到数月
- 偏好信息(沟通风格、格式选择):中等 TTL,数天到数周
- 瞬态上下文(当前任务状态、进行中的调试):短 TTL,数小时到数天
这与人类记忆的工作方式一致——艾宾浩斯遗忘曲线显示大多数信息呈指数衰减,而有意义的内容通过复习而持久。实现访问频率强化的智能体记忆系统——每次记忆被成功检索和使用时提升其相关性分数——创造了与间隔重复相同的效果。有用的记忆会不断刷新自己的 TTL。
标记-清除:语义去重
智能体记忆中最容易被忽视的 GC 操作是去重。随着智能体随时间交互,它们会积累几乎相同的记忆:"用户偏好 Python"与"用户的主要语言是 Python"和"编码时使用 Python"并存。这些不是相同的字符串,所以基于哈希的去重会遗漏它们。但它们占用了三个检索槽位来传递一条信息。
语义去重作为对记忆存储的标记-清除操作。标记阶段计算主题聚类内的成对语义相似度。清除阶段合并高于相似度阈值的记忆,保留最完整的版本并丢弃冗余片段。
生产实现将此作为后 台作业运行,而不是内联写入。成本很重要:一个系统报告通过积极的子原子提取和语义去重从 7,327 个 token 的基线实现了 51 个 token——压缩比为 99.3%。即使是适度的去重,只对明显的近似重复项进行操作,通常也能在不损失任何信息的情况下将记忆存储大小减少 30-40%。
组织模式也很重要。在多智能体系统中,去重需要跨智能体边界运行——不同的智能体观察同一事件会生成重叠的记忆。协调遗忘协议识别并丢弃噪声,同时保留任何单个智能体的去重过程都无法发现的团队关键信息。
引用计数:矛盾检测
最微妙的 GC 问题是矛盾。当用户更换工作时,旧雇主的记忆不会变得无关——它变得主动有害。关于用户雇主的高检索频率记忆具有高度相关性,直到它不再相关的那一刻,此时它变成了自信地错误而不仅仅是过时。
真值维护系统通过在整合任何新记忆之前运行一致性检查来解决这个问题。检查提取主语-谓语-宾语三元组,并测试四种类型的矛盾:
- 否定:"用户不使用 AWS"与存储的"用户使用 AWS"
- 时间取代:"用户在 B 公司工作"取代"用户在 A 公司工作"
- 值冲突:"项目截止日期是 3 月 15 日"与存储的"项目截止日期是 2 月 28 日"
- 反义词检测:"用户偏好详细输出"与存储的"用户偏好简洁输出"
当检测到矛盾时,系统必须做出决定:更新现有记 忆,还是标记供人工审查?最安全的生产模式拒绝与核心事实矛盾的更新(ΔM ∧ M_core ⊧ ⊥),并将它们路由通过调和层。这既防止了合法更新的丢失,也防止了对抗性记忆投毒对存储的破坏。
这里困难的开放问题是区分真正的更新和上下文变化。在令人沮丧的调试会话中说的"我讨厌 Python"实际上并不矛盾"用户偏好 Python"。检测一个陈述何时反映永久状态变化与何时反映短暂情绪表达,需要当前系统处理不好的推理能力。
压缩与检索的权衡
当智能体的记忆超出其上下文预算时,你面临一个根本性的架构选择:压缩记忆以适应,或选择性检索并接受不完整的上下文。
全上下文方法——将所有内容塞入提示——在基准测试中实现了最高准确率。但它们在生产中完全不可用。每个请求 100K token,每次调用约花费 5,000。更糟糕的是,模型表现出"中间丢失"退化,即埋在长上下文中的信息实际上是不可见的。
选择性检索——嵌入查询、搜索记忆存储、返回 top-K 结果——以微小的准确率损失换取大量的成本和延迟节省。比较这些方法的研究发现,选择性记忆管道与全上下文相比仅接受 6 个百分点的准确率损失,换取了 91% 更低的 p95 延迟和 90% 更少的 token。
自适应压缩代表了中间地带。观察性记忆系统运行后台智能体持续压缩智能体观察,实现 26-54% 的峰值 token 减少,同时保持 95%+ 的任务准确率。关键区别是压缩异步发生——它不阻塞用户交互——并且设计上是有损的。系统决定什么信息密度值得上下文预算。
生产决策框架:
- 10K 以下记忆,延迟不敏感:全上下文可能有效,监控中间丢失效应
- 10K-100K 记忆,实时服务:选择性检索配合语义去重,目标 top-20 检索
- 100K+ 记忆或多智能体:分层架构,包含压缩、检索和驱逐策略
构建 GC 管道
生产就绪的记忆 GC 系统同时运行四个进程,每个都有自己的调度。
写入时过滤是第一道防线。在记忆进入存储之前,评估它是否添加了尚未表示的信息、是否达到最低质量阈值,以及是否在没有解决方案的情况下与核心事实矛盾。研究表明,仅严格的 写入时过滤就比朴素记忆增长产生了 10% 的绝对性能提升,即使没有任何删除机制。
后台去重按计划运行——高流量智能体每小时一次,低流量智能体每天一次。它按主题聚类记忆,计算聚类内相似度,并合并近似重复项。这在计算上很昂贵(聚类内 O(n²) 成对相似度),但容忍批处理,因为去重是最终一致的。
衰减清扫持续运行,根据自上次访问以来的时间和语义类别递减相关性分数。低于阈值的记忆首先被软删除(从检索中排除但不销毁),在宽限期后硬删除。宽限期很重要——它是防止过度激进回收的安全网。
一致性审计定期对整个存储运行,检查写入时过滤遗漏的矛盾。这些捕获困难的情况:渐进的语义漂移,其中没有单个更新触发矛盾,但累积效果使记忆存储内部不一致。
告诉你 GC 是否正常工作的指标
大多数团队用存储指标来监控记忆系统:数量、大小、写入速率。这些是必要的但不充分的。实际告诉你 GC 是否正常工作的指标是检索质量指标。
K 处的检索精度衡量 top-K 检索的记忆中有多少实际上与当前查询相关。如果这个数字随着存储增长而随时间下降,你的 GC 太被动了。
过时检索率跟踪检索到的记忆包含明显过时信息的频率。这需要真值标注,成本很高,但即使对 1% 的检索进行采样和人工审查,也能在用户注意到之前给你一个领先指标。
上下文利用率衡量被检索记忆填充的上下文窗口中有多少百分比实际上影响了智能体的响应。低利用率意味着你在为模型忽略的上下文付费——这是你的记忆太冗长或太多的信号。
矛盾率计算检索到的记忆包含相互矛盾事实的频率。这里任何非零率都是智能体不可靠性的直接输入。如果你在检索结果中看到矛盾,你的真值维护系统有漏洞。
为什么记忆管理胜过记忆存储
2026 年的智能体记忆生态系统揭示了一个有启发性的模式。五个主要记忆框架仅在第一季度就累积了超过 80,000 个 GitHub 星标,每个都以不同方式解决问题——逐字存储、文件系统抽象、知识图谱、单二进制简洁性、多模态终身记忆。它们在存储机制、决策权限和专业化上存在根本分歧。
它们一致认为存储是已解决的问题。每个框架都能可靠地持久化记忆。未解决的问题——决定你的智能体是否真正随时间改进还是逐渐退化的问题——是记忆管理。具体来说:忘记什么、何时忘记,以及如何验证遗忘没有破坏任何东西。
那些发布可靠的长期运行智能体的团队,不是拥有最复杂嵌入模型或最快向量数据库的团队。他们是那些将记忆视为具有生命周期的托管资源的团队——创建、晋升、整合、弃用和删除。换句话说,他们是构建了垃圾回收器的团队。
与软件工程的类比是精确的。我们花了几十年构建更快的分配器,才意识到自动内存管理——让运行时决定释放什么——才是使复杂软件成为可能的突破。智能体记忆正处于同样的拐点。获胜的框架不会是存储最多的那些。而是遗忘得最好的那些。
- https://ossinsight.io/blog/agent-memory-race-2026
- https://arxiv.org/html/2603.11768
- https://arxiv.org/html/2603.07670v1
- https://mem0.ai/blog/state-of-ai-agent-memory-2026
- https://thenewstack.io/memory-for-ai-agents-a-new-paradigm-of-context-engineering/
- https://arxiv.org/html/2601.01885v1
- https://www.zenml.io/llmops-database/observational-memory-human-inspired-context-compression-for-agent-systems
- https://vectorize.io/articles/best-ai-agent-memory-systems
