TL;DRAgent Memory 的真正难题不是怎么存而是怎么删。本文用一次真实的 memory 审计数据拆解记忆陈腐Staleness、冲突和膨胀三类问题给出 TTL / 冲突覆盖 / 遗忘曲线三种管理策略的适用场景和优先级。一、事故现场上周我跟 AI 助手说我最近在学 Vue 3。这没什么问题。但三个月前我跟同一个助手说过我们团队用 React我很熟悉 React 生态。后来我问它“帮我推荐一个状态管理方案。”它的回答“考虑到你的技术栈推荐 ReduxReact 生态或 PiniaVue 生态你可以根据项目选择。”我盯着屏幕愣了三秒。我已经不用 React 了它怎么还在推荐 Redux答案很简单——它把两条记忆都存了。“喜欢 React和在学 Vue 3在它的记忆库里和平共处没有任何机制告诉它这两条信息是冲突的新的应该覆盖旧的。这不是个例。我翻了一下自己正在使用的 AI 编程助手 CodeBuddy 的 file-based memory 系统做了一次冷静的审计。结果不太好看。8 个记忆文件52KB积累了不到两个月。听起来不多但问题已经开始冒头了memory 索引说某篇文章进入锤炼阶段”实际上它早就发布了——索引自己 stale 了系统在三周前完成了一次术语大迁移v1 → v2但有一条记忆还在用旧术语——同一个 memory 系统里两条记忆对同一件事给出矛盾描述有 3 条记忆其实是完整的技术文档309 行的 API 调用手册——系统自动抽取时未做长度过滤占了总体积的 57%——记忆变成了垃圾桶8 个文件就出了这么多问题。想象一下更大规模的 Agent上百条记忆、数百 KB如果没有管理机制memory 系统会从助手变成噪音源。二、当记忆开始溢出上面那个 React vs Vue 的例子问题还算容易发现——两条记忆明显矛盾。但有一种更隐蔽、更危险的情况记忆没有错只是旧了。想象这个场景李薇去年 10 月从 B 公司跳槽到 C 公司。她用的 AI 助手记住了大量旧公司的上下文——阿里云部署环境、Java 技术栈。跳槽后她告诉助手我现在在 C 公司用 Go gRPC助手也记住了。半年后她问“帮我写一个服务监控方案。”助手检索记忆。“阿里云 ECS K8s这条记忆相关性很高确实是部署环境相关的信息。于是它输出了一份基于阿里云 ARMS SLS 的方案。问题是李薇现在在腾讯云上。这就是 Staleness记忆陈腐。高相关但已过时的记忆和低相关记忆不同低相关的记忆不会被检索命中不会造成伤害。而 Stale 记忆恰恰相反它会被优先检索到而且看起来很合理。这是自信地给出错误答案”。这个问题有多普遍我对那 8 个文件做了有效性评估。样本量 8仅基于个人审计数据非行业统计。但趋势清晰状态占比说明完全有效25%信息准确当前仍有参考价值部分有效62.5%核心正确部分细节过时过时12.5%已失去存在意义最让我警觉的不是那 12.5% 的过时而是 62.5% 的部分有效。“部分有效比完全过时更危险。完全过时的记忆Agent 有机会发现时间错位自行忽略。但部分有效的记忆看起来是对的核心信息也确实是对的。Agent 会因为大部分正确而信任整条记忆顺带接受了那些已经过时的细节。这正是 Mem0 在 2026 年发布的State of AI Agent Memory报告中将 Staleness 列为开放研究问题的原因。不是因为它稀有恰恰是因为目前没有好的解决方案。还有一个被忽视的问题记忆只增不减。43 天8 个文件52KB。没有任何自动清理机制只会越积越多。一条记录了三周前已完成的页面优化任务的记忆至今仍然安静地躺在记忆库里——不是因为它有用而是因为没有人也没有机制去删除它。当存储是自动的、免费的而管理是手动的、昂贵的记忆系统必然退化。三、三种删”大多数 Agent Memory 教程教你怎么加记忆——怎么嵌入向量、怎么语义检索、怎么连接外部知识库。很少有人教你怎么删记忆。这不是疏忽。是因为删比存难得多。存储是确定性操作一条信息要么存了要么没存。删除是不确定性决策删错了可能比不删更糟。多存了不需要的信息最多浪费空间删掉了关键记忆可能导致灾难性错误。但不删不行。前面两章已经说明了为什么。我把现有的记忆管理策略归纳为三种删。它们不是互斥的是互补的对应三个不同的维度。TTL 删除时间到了就扔最简单的策略。给每条记忆贴一个保质期到期自动清理。TTL 简单到只需一个时间戳字段加定时扫描。适合处理明确有时效的信息“今天想吃川菜“用户正在出差“本次对话的特定需求”。这些记忆天然有过期时间。但不是所有记忆都有保质期。用户的母校不会过期。编程语言偏好可能几年不变。给这些记忆设 TTL 就像给学历证书贴保质期。而且 TTL 设多长短了有用的记忆被误删长了过时的记忆继续污染。不同类别需要不同的 TTL身份信息长≠ 偏好信息中≠ 任务信息短。冲突覆盖删新的替换旧的当新记忆与旧记忆在语义上冲突时用新的覆盖旧的。像手机通讯录存了朋友的新号码旧号码自动被覆盖。因为一个人的当前手机号只能有一个。开头那个 React vs Vue 的问题就该用这个策略解决。“喜欢 React”→“在学 Vue 3”这是同一维度的偏好变更新值应该覆盖旧值。但核心难点在于什么算冲突”“喜欢 React和喜欢 Vue是冲突吗如果用户是全栈工程师同时精通两个框架呢“我是后端工程师和我正在学前端矛盾吗当然不——但 Agent 需要理解这一点。这本质上是自然语言推理问题——判断两条记忆是否在说同一件事的不同版本”。而且不只是语义同一条我喜欢 React”是指当前项目还是通用偏好这涉及时间和作用域推理。真正难的是把这套推理做到工程可靠。不只是字符串匹配需要语义理解能力。遗忘曲线淘汰不用的慢慢忘如果只按频率淘汰过敏信息第一个被删——用户可能从没主动提过但这条记忆可能救命。这就是按使用频率淘汰记忆的核心矛盾。像图书馆的书架被频繁借阅的书放在显眼位置很少被借的书逐渐移到仓库。听起来合理但有些冷门藏书恰恰是关键时刻唯一的参考。严格说这里更接近 LFU按频率淘汰而非 Ebbinghaus 遗忘曲线——但遗忘这个比喻有助于理解意图工程实现是另一回事。用户半年前关注区块链最近一直聊 AI——区块链记忆权重自然衰减。这很合理。但用户的血型一年被问一次每次都很关键。调用频率 ≠ 重要性。一个成熟的遗忘策略需要综合考虑调用频率、调用质量检索后是否被采用、记忆类别身份 偏好 任务、上下文关联度。这是三种策略里最接近人类记忆运作方式的也是工程上最难落地的。三种策略的关系 左侧简单右侧复杂详见下方对比图。一个成熟的 Agent Memory 系统应该三者兼备。但现实是大多数系统连 TTL 都没有做好——它们只有 ADD没有任何形式的删”。除了删还有浓缩。Mem0 和 LangMem 都在做的 memory consolidation——把多条相关记忆合并为一条摘要减少数量但保留信息。这不是删是合并。但合并本身也需要判断哪些记忆算相关合并后丢了哪些细节又是语义理解问题。资源有限时先上 TTL——成本最低、效果最确定。如果用户偏好多变比如技术栈切换必须加冲突覆盖。遗忘曲线是锦上添花前两个做不好之前别碰它。三种策略至少实现一种——先从 TTL 开始这是成本最低的保险。四、行业的答案这不是理论推演——行业头部玩家正在为此争吵。2026 年初Mem0 发布了State of AI Agent Memory报告。在 LOCOMO 基准测试的加权平均上选择性记忆 vs 全量上下文准确率仅差 6%——但注意在时序敏感任务上差距更大。延迟降低 91%token 消耗降低 90%。选择存什么、淘汰什么才是瓶颈。Letta前 MemGPT的联合创始人 Sarah Wooders 在社交媒体上公开质疑这组数据。争论背后的根本分歧Mem0 认为记忆的核心是检索Letta 认为核心是上下文管理——像操作系统管理虚拟内存。当然这是简化理解——Mem0 也有删除 APILetta 也需要检索。差异更多在架构哲学中间件 vs 操作系统。用我们的框架看两家不是对立——是三种删的不同起点。Mem0 从 TTL 和检索起步“先能找到”Letta 从冲突覆盖和状态管理起步“先别矛盾”。最终都要走到三者兼备。LOCOMO 基准测试只测记不记得住不测该不该忘记——而后者才是真正的工程难题。五、你的 Agent 什么时候需要 Memory说完了行业回到你自己。回到开头那个同时推荐 React 和 Vue 的问题。真正的答案跟向量数据库和 Embedding 模型都没关系。要从一个更前置的问题开始你的 Agent 到底需不需要长期记忆128K token 的上下文窗口已经能容纳一本小说。但能装下不等于能用好——研究表明LLM 对长上下文中间部分的信息检索准确率会显著下降。即便如此对于大多数单次对话场景——写代码、翻译文档、回答问题——上下文窗口就够了不需要额外的 Memory 系统。Memory 系统真正不可替代的场景只有一个跨会话的个性化。“用户三个月前说过他偏好 TypeScript”——这条信息不在当前对话上下文里全量上下文方案Full-context做不到。只有持久化的 Memory 才能跨越会话边界。例外如果你的 Agent 需要在单次对话中调取用户历史数据比如客服查工单仍然需要外部记忆——只是不一定是 Agent Memory更可能是数据库查询。如果你的 Agent 只服务单次对话大概率不需要 Memory。但如果需要跨会话记住用户偏好——那就得上同时得想清楚怎么管。如果你决定上 Memory那这篇文章的核心信息就是你的备忘录不要只想着怎么存先想清楚怎么删。因为记忆溢出不是内存不够用。是你的 Agent 记得太多、管得太少开始自信地给出错误答案。记忆过期了怎么办——这才是 Agent Memory 的真正难题。