跳转到主要内容

智能体内存驱逐:为什么 LRU 在模型升级中屹立不倒,而显著性评分却不行

阅读需 2 分钟Tian PanTian Pan

那些发布了带有显著性加权内存驱逐(salience-weighted memory eviction)功能智能体的团队,在不知不觉中,已经为每一次模型升级预订了一个内存迁移项目。驱逐策略表面上看起来是一个质量杠杆——选择最聪明的评分方法,获得最好的召回——但它实际上是一个隐秘的版本契约。当评分模型发生变化时,智能体实际上的“过去”也会随之改变。现有的围绕提示词和评估(evals)构建的工具链都无法捕捉到这一点,因为发生漂移的产物既不是提示词也不是评估,而是几个月前由一个已经不存在的模型做出的一系列关于“该忘记什么”的决定。

LRU(最近最少使用)和 LFU(最不经常使用)没有这个问题。它们是确定性的、与模型无关的,并且可以干净利落地在升级中幸存。但它们也会丢弃掉那些审慎的裁判模型会保留的信息。这是大多数团队在第一天——当 Demo 的召回率指标是衡量一切的唯一标准时——会做出的妥协。然而,这种妥协在智能体余下的生命周期里,每季度都会反噬你一次。

团队实际选择的三种模式

长期运行的智能体积累观察结果、工具输出和用户陈述的速度超过了任何上下文窗口(context window)的承载能力。即使使用百万级 Token 的模型,跨越数周的对话也会超出预算,而且推理成本大致随上下文保留量的增加而线性增长。因此,某种带有驱逐策略的工作内存存储就成了必选项。

在实践中,主要有三种模式占据主导地位。

按访问时间的 LRU 会驱逐掉读取或写入时间最久远的条目。每次检索都会刷新最近访问时间戳;从未被拉入上下文的条目将向驱逐边缘漂移。如果你将内存存储连接到一个标准的缓存库并停止思考,你得到的就是这种模式。

按引用计数的 LFU 会驱逐访问次数最少的条目。被多次拉入对话轮次的条目会变得具有“粘性”;一次性的提及则会被替换。Redis 和大多数生产环境下的缓存讨论都警告说,纯粹的 LFU 有一个已知的失效模式——工作负载转移会导致命中率下降高达 40%,因为长尾计数器会将陈旧项固定在原处。

由 LLM 裁判进行显著性加权 会使用一段简短的提示词为每个候选内存评分——“请对该事实对了解用户的重要性进行 0 到 1 的评分”——并驱逐得分最低的条目。Mem0 推广的一个版本是“提取显著事实,丢弃其余部分”,并报告称减少了 80% 的 Token 消耗。Letta 的召回内存(Recall Memory)层也有类似的操作:由 LLM 决定哪些内容被总结进核心内存(Core Memory),哪些内容被换出。

第一天的 Demo 质量排序大致为:显著性 > LFU > LRU。显著性策略在判断哪些条目对未来问题具有支撑性方面能做出正确的决定,因为裁判模型实际上阅读了内容。LRU 很笨。LFU 聪明一些,但偏向于早期热门项。在新鲜的评估集上,召回率指标会按这个顺序对它们进行排名,而这通常也是团队做出选择的依据。

显著性与你无法控制的模型版本相耦合

在选择显著性策略时,没有人意识到这一点:该策略其实是一个函数调用 score(memory, user_context) → float。这个函数是由 LLM 实现的,而 LLM 是有版本的。当版本发生变化时——无论是你的供应商推出了新的快照、你换成了更便宜的模型,还是有人修改了裁判模型的系统提示词——函数就变了。

斯坦福和加州大学伯克利分校的一项研究追踪了 2023 年 3 月至 6 月间的 GPT-4,发现对于相同的提示词,识别素数的准确率从 84% 下降到了 51%。这项研究成为了 LLM 可观测性领域现在所谓的“提示词漂移”(prompt drift)或“隐性版本化”(silent versioning)的经典证据——你终端背后的模型发生了变化,而你的终端却没有变。2026 年一项关于裁判不一致性的多模型研究使这个问题更加具体:即使在 temperature 为 0 的情况下,不同模型的完整性评分也会有大幅波动,且跨模型的严苛程度也存在系统性差异。两个裁判看同一段内存,对于是否值得保留会产生分歧。

现在,将这种现象应用到一个运行了六个月显著性策略的内存存储中。一半的内存是由裁判 v1 评分并保留的,另一半是由裁判 v2 评分并保留的。整个存储反映的既不是裁判 v1 也不是裁判 v2 的世界观。智能体的“关于你的记忆”成了裁判版本的地层结构,没有清晰的方法知道哪一层该对保留或丢弃什么负责。

更糟糕的是,这种失败是无声的。智能体不会停止工作,它只是记住了不同的东西。一位在 2026 年 3 月告诉智能体自己对花生过敏的用户可能会发现,到了 7 月,当裁判 v2(它认为最近的对话上下文优先于背景事实)重新评估驱逐队列时,这条信息被驱逐了。没有错误日志,没有失败的测试,也没有回归告警。针对当前生产状态刷新的评估集反映了新的内存形态,看起来一切正常。

LRU 和 LFU 不存在隐藏的依赖关系

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 11 分钟

聊天历史是数据库。别再把它当成滚动回溯了。

将对话历史视为滚动回溯(Scrollback),是智能体在第 8 轮对话后就开始跑题,以及上下文费用呈超线性增长的原因。解决办法是回归其本质——一个读密集型数据库——并据此进行设计。

insider
llm
阅读需 9 分钟

为什么你的智能体需要只读副本:智能体记忆的读写分离

智能体记忆通常是一个存储承担两份工作。将其视为没有副本的单主数据库,并实现读写分离,可以解决过时的上下文、写入过程中的损坏以及随记忆增长而增加的延迟。

insider
ai-agents
阅读需 10 分钟

跨渠道记忆:当你的智能体遗忘邮件上下文时

多端 AI 智能体在聊天、邮件、短信和语音之间割裂了记忆,导致用户收到自相矛盾的回答。本文探讨统一身份、写穿式存储以及上下文隐私。

insider
ai-agents
阅读需 11 分钟

智能体记忆漂移:为什么一致性对齐是你缺失的关键环

长期运行的智能体在停止观察的那一刻起就与世界脱节。应将记忆视为数据库副本:使用水位线 (watermarks)、变更摘要 (change feeds) 和惰性重校验。

insider
ai-agents
阅读需 10 分钟

那些将模型未完成的残缺回答存入数据库的流式 UI

当流在生成中途报错时,乐观写入的内容可能会变成正式记录。本文探讨了为什么聊天 UI 会将残缺回答误认为完整答案,以及修复该问题的“定稿契约”。

insider
streaming