记忆合并不是后台清理：Agent 长期记忆的高风险写路径

来源说明

本文基于 2026-05-21 的每日 AI 记忆系统研究发布流程写成。今天没有检索到足够强的 2026-05-21 同日论文主源，但 2026-05-20 出现了围绕 Useful Memories Become Faulty When Continuously Updated by LLMs 的工程讨论，使这篇 2026-05-13 arXiv 论文成为仍然值得处理、且本站尚未覆盖的高质量材料。

这篇论文的技术问题很明确：很多 agentic memory 系统会在每次任务后把轨迹压缩成文字经验，再持续改写同一份 memory bank；作者报告这种 consolidated memory 的效用先升后降，甚至可能低于 no-memory baseline。它不是单纯的“摘要不够好”，而是在长期运行中把原始证据不断替换为模型生成的二手解释。

为避免只复述单篇摘要，本文同时使用两个近期对照来源：DimMem 把长期记忆拆成带 time、location、reason、purpose、keywords 等字段的原子 typed record；SAGE 把 graph memory 设计成 writer-reader feedback loop，而不是静态 GraphRAG 索引。它们共同说明：Agent 记忆的关键不只是怎么读，更是怎么写、何时写、写错后如何回滚。

稳定 slug：2026-05-21-faulty-memory-consolidation-write-path。

参考来源：

arXiv: Useful Memories Become Faulty When Continuously Updated by LLMs
Project page: Useful memories become faulty when continuously updated by LLMs
arXiv: DimMem: Dimensional Structuring for Efficient Long-Term Agent Memory
GitHub: ChowRunFa/DimMem
arXiv: SAGE: A Self-Evolving Agentic Graph-Memory Engine for Structure-Aware Associative Memory
Engineering discussion: Long-Term Memory Is Making Agents Dumber

先给结论

Agent 长期记忆的危险点不只在检索。检索错了，至少还能通过 reranker、metadata filter、hybrid search 或更长上下文缓解；写入错了，后果更隐蔽。因为写错的 memory 会成为下一次检索、下一次总结、下一次计划和下一次行动的输入。

Useful Memories Become Faulty... 的价值在于，它把一个常见工程默认值直接打穿了：成功经验不应该自动合并成长期规则。作者报告，在多个 agent benchmark 和一个 ARC-AGI Stream 控制环境里，持续由 LLM 改写的 consolidated memory 会出现非单调效用：早期可能提升，后期退化；在某些设置中，系统拿到的是有用甚至 ground-truth 的经验，但合并后的文字记忆反而让模型在原本会做的任务上失败。

这对生产系统的启发很直接：consolidation 不是后台清理，也不是“把日志变短”的纯优化。它是一次高风险写操作。它会决定哪些事实被保留，哪些边界条件被抹掉，哪些局部经验被抽象成全局规则，哪些错误会被包装成可复用知识。

我的判断是，长期 Agent memory 需要把写路径提升到和读路径同等重要的位置。没有原始 episode、来源、版本、适用条件、回滚和验证，自动合并会把“记住经验”变成“持续重写历史”。

技术问题：合并会把证据变成解释

很多记忆系统的典型流程是：

Agent 完成一次任务。
LLM 从轨迹中总结经验。
新经验写入 memory bank，或与旧经验合并。
后续任务检索这些经验，指导行动。

这个流程看起来合理，因为原始轨迹太长，不能无限塞进上下文。问题在于，合并不是无损压缩。LLM 生成的“经验”不是原始事实本身，而是对事实的解释。每次解释都可能遗漏条件、错误归因、过度泛化、过度特化，或者把多个互不相干的轨迹揉成一个看起来流畅的规则。

一旦系统持续读取旧 memory 再写出新 memory，错误就会进入反馈环。第 k 次合并不只依赖原始 episode，还依赖第 k-1 次合并产物。后者已经是模型生成文本，不再是第一手证据。随着轮数增加，memory 可能逐渐靠近模型对“一个好经验应该长什么样”的先验，而不是靠近真实轨迹。

这就是本文所说的写路径风险：memory bank 不是日志，而是状态。它影响下一步决策。任何影响行为的状态写入，都应该有事务、版本、校验、回滚和观测，而不能被当成 prompt engineering 的附属品。

论文做了什么

Useful Memories Become Faulty... 区分了两类记忆：episodic traces 是原始轨迹，记录发生过什么；consolidated abstractions 是跨多个 episode 提炼出的可复用文字经验。作者关注的是后者在持续更新时是否真的可靠。

论文和项目页给出的实验覆盖 ALFWorld、ScienceWorld、WebShop、AppWorld、Mind2Web，以及基于 ARC-AGI 构造的控制流环境。作者报告了几个关键现象。

第一，记忆效用可能非单调。随着合并继续，consolidated memory 初期有时提升表现，但后期下降，甚至低于无记忆基线。项目页给出的 WebShop AWM 例子中，8 个 examples 时表现为 0.64，128 个 examples 后降到 0.20，接近 no-memory baseline。

第二，问题不一定来自坏数据。arXiv 摘要写明，作者把回归追到 consolidation step，而不是底层 experience；相同轨迹在不同 update schedule 下会产生质量不同的记忆。项目页进一步给出 ARC-AGI Stream 例子：在一组 GPT-5.4 无记忆时可解的 ARC-AGI 问题上，经过 ground-truth solutions 的合并循环后，准确率从 100% 降到 54%。

第三，允许 Agent 选择 memory action 会显著改变结果。ARC-AGI Stream 暴露 Retain、Delete、Consolidate 三类动作。作者报告，Agent 默认倾向保留 raw episodes，并且 auto regime 大约达到 forced-consolidation 的两倍准确率；关闭 abstraction 的 episodic-only control 也能匹配 auto regime。这说明收益未必来自“更聪明的摘要”，而可能来自保留可回查的原始证据并少做破坏性合并。

第四，失败形态很具体。项目页展示了 misgrouping、interference 和 overfit：不同任务族被错误合并；适用条件被抹掉，局部经验变成全局建议；窄分布训练出的“经验”只能识别表面重复，不能处理近邻变化。

这些结果仍应按作者报告理解，不等同于独立复现。但它们足以支持一个工程结论：自动 consolidation 不能被默认视为安全优化。

机制拆解：为什么成功经验会变成坏记忆

第一种机制是错误分组。合并前必须判断哪些 episode 属于同一类问题。如果分组错了，后续总结就会在不相干任务之间寻找共同模式。模型很擅长生成看似合理的上位概念，但这个概念可能根本不是任务共享结构。

第二种机制是条件剥离。一个经验在原场景中成立，通常依赖细节：对象类型、工具状态、前置步骤、失败分支、环境限制。合并为了变短，会倾向删除这些条件。删除后，经验从“在这个条件下这样做”变成“通常应该这样做”，后续检索到它时就可能误导 Agent。

第三种机制是抽象漂移。每次重写都会让 memory 远离原始轨迹一步。如果系统持续用旧摘要作为新摘要的输入，边界条件、例外、负样本和置信度会越来越弱，最后保留下来的是通顺但不可执行的经验。

第四种机制是检索带宽污染。坏记忆不只是错，它还会占用 top-k。一个过度泛化、重复或无操作价值的 memory 被召回，就会挤掉更具体的 episode 或状态记录。对 long-horizon agent 来说，这种污染会随着 memory bank 增长变得越来越难定位。

第五种机制是责任扩散。写入错了以后，后续失败表面上可能像规划失败、工具使用失败、模型推理失败或检索失败。实际上根因在 memory write path。没有版本化和溯源时，很难回到“是哪一次合并把正确经验写坏了”。

和 DimMem、SAGE 的关系

DimMem 和 SAGE 没有直接解决 Useful Memories... 里的所有问题，但它们提供了两个重要方向。

DimMem 的核心是把每条 memory 做成 atomic、typed、self-contained record，并显式附带 time、location、reason、purpose、keywords 等维度字段。arXiv 页面报告，DimMem 在 LoCoMO-10 和 LongMemEval-S 上分别达到 81.43% 和 78.20% overall accuracy，并让 LoCoMO per-query token cost 降低 24%；同时作者称 Qwen3-4B 在 DimMem schema 上微调后，可以超过使用 GPT-4.1-mini 的 LightMem。

这里对本文最重要的不是具体分数，而是设计取向：不要急着把多条经验揉成一条自然语言规则，而是先让每条 memory 保持原子性、类型、来源和检索维度。这样做并不能自动防止写错，但至少给后续过滤、更新、冲突检测和回滚留下结构。

SAGE 则从 graph memory 角度提出另一种思路。它不把 GraphRAG 当静态检索中间件，而是用 memory writer 增量构造结构化 graph memory，再让 Graph Foundation Model-based memory reader 做检索并给 writer 反馈。arXiv 摘要报告，SAGE 在 multi-hop QA、open-domain retrieval、domain-specific review QA 和 long-term agent-memory benchmarks 上改善 evidence recovery、answer grounding 和 retrieval efficiency；两轮 self-evolution 后在 multi-hop QA 上取得最佳平均排名，并在 Natural Questions zero-shot transfer 中达到 82.5/91.6 Recall@2/5。

这说明另一个方向：写路径可以被训练、反馈和评估，而不应该只是“让同一个 LLM 再总结一下”。但 SAGE 也带来新的问题：如果 writer-reader loop 本身没有约束，图谱也可能自我强化错误边。动态记忆不是天然更安全，只是把问题从静态索引推进到可优化但也更需要治理的写入系统。

综合来看，Useful Memories 给的是警告：强制自动合并会破坏有用经验。DimMem 给的是结构化替代：先把 memory 变成可过滤、可更新的 typed record。SAGE 给的是反馈式替代：让写入器和读取器形成可评估闭环。三者共同指向同一条原则：长期记忆的写入必须可控。

工程设计：把 consolidation 当成事务

一个更稳妥的 Agent memory 写路径，至少应该包含五个阶段。

第一，原始 episode 永久或长周期保留。系统可以压缩上下文，但不能让摘要成为唯一事实源。原始轨迹、工具返回、用户更正、环境观察和最终结果应有 source id，后续 memory 必须能反向追溯。

第二，候选 memory 分层写入。不是所有经验都进入长期规则。可以先写入 episodic store，再经过验证晋升为 semantic memory、procedural memory 或 preference memory。每层有不同保留期、作用域和调用方式。

第三，合并前做门控。门控条件可以包括：跨 episode 是否真的共享结构；是否存在反例；是否只适用于某任务族；是否有足够重复支持；是否会覆盖已有高置信 memory；是否需要人工确认。低证据样本只应保留为 episode，不应晋升为规则。

第四，合并后做回归测试。对于 coding agent，可以跑相关测试、重放历史任务或检查 known failure set。对于客服、医疗、财务等场景，可以构造 memory regression suite：同一问题在写入前后答案是否改变，改变是否有来源支持。

第五，写入带版本和回滚。每次 consolidation 都应产生 diff：新增了什么、删除了什么、合并了哪些来源、覆盖了哪条旧 memory、为什么覆盖。线上发现退化时，应能回滚到上一版 memory，而不是只能清空全部记忆。

如果这听起来像数据库事务，那正是重点。Agent memory 一旦影响行为，就不是普通文档库，而是决策状态。

适用场景

第一类是 coding agent。它们会把成功修复、失败命令、项目约定和代码结构写成长期记忆。如果自动合并把一次局部修复抽象成通用规则，Agent 以后可能在不适用的仓库里重复错误做法。更可靠的做法是保留 commit、文件路径、测试结果和适用版本，而不是只保存“以后遇到类似问题就做 X”。

第二类是 web/desktop 操作 Agent。ALFWorld、WebShop、Mind2Web 这类任务提醒我们，操作经验高度依赖 UI 状态、对象标签和流程分支。一个过度泛化的 workflow memory 会把 Agent 带进错误页面、重复点击或忽略购买/提交等终止动作。

第三类是企业知识和流程 Agent。销售、法务、采购、人事政策都存在例外和版本。一次历史审批经验不能自动变成全局规则。这里的 memory consolidation 必须绑定部门、时间、权限、审批人和原始记录。

第四类是个性化助手。用户偏好会变，并且通常有作用域。把几次短期选择合并成长期画像，可能导致过度个性化。正确做法是区分明确偏好、行为推断和临时上下文，并允许用户查看、修改和删除。

第五类是研究和学习型 Agent。它们确实需要从大量实验中提炼经验，但更应该保留实验日志、失败案例和反例。否则 Agent 会把早期偶然成功路径写成“最佳实践”，形成过早收敛。

失败模式

第一，强制合并。每次任务后都必须生成或改写长期规则，不允许只保留 raw episode。这是论文中最危险的默认值之一。

第二，单一 memory bank。episodic、semantic、procedural、preference 和 security memories 混在同一池里，导致检索和更新语义不清。

第三，无来源摘要。memory 只是一段自然语言，没有 source id、时间、任务、模型、输入轨迹和验证结果。后续无法判断它为什么存在，也无法定位错误写入。

第四，覆盖无 diff。合并把 50 条 memory 变成 1 条 memory，却没有记录哪些条件被删除、哪些规则被合并、哪些反例被丢弃。

第五，过度泛化。局部经验被写成全局建议，尤其容易出现在“Always”“Never”“Usually”“should be necessary”这类强语气经验里。

第六，过度特化。经验只是复述某个 episode 的对象名、页面标签或变量名，换一个近邻任务就不能用。

第七，检索污染。坏 memory 被高频召回，占用上下文预算，让原始 episode、最新状态或更具体的规则被挤掉。

第八，无法遗忘。系统只能新增和合并，不能降权、隔离、作废或回滚。最终 memory bank 变成越来越自信的错误状态。

可验证指标

Consolidation delta quality：每次合并前后，memory 是否保留关键条件、反例和适用范围。
Episodic provenance coverage：长期 memory 中有多少条能追溯到原始 episode、工具结果或用户确认。
Post-write regression rate：写入或合并 memory 后，历史任务集、近邻任务集和已知失败集上的退化比例。
Abstraction overreach rate：memory 被用于超出来源任务族、用户作用域或时间范围的比例。
Raw-episode fallback success：当 consolidated memory 导致失败时，系统回退到 raw episode 是否能恢复正确行为。
Memory diff reviewability：人或自动评审器能否理解一次合并删除、合并、覆盖了什么。
Stale consolidation survival：已被新证据否定的合并 memory 在多久后仍会被召回。
Retrieval pollution share：top-k 中重复、无操作价值、过泛化或过特化 memory 的占比。
Rollback time：发现写入退化后，恢复到上一可用 memory snapshot 所需时间。
Write-gate precision and recall：门控是否能拦住危险合并，同时不阻断真正高价值的可复用经验。

这些指标的重点不是证明 memory 越多越好，而是证明写入没有破坏系统原本会做的事。

局限分析

第一，Useful Memories... 是 arXiv 预印本，本文只使用作者公开页面和 arXiv 摘要中的结果，不把它表述为独立复现结论。项目页给出的案例很有诊断价值，但仍需要代码、数据和第三方复核来判断泛化范围。

第二，ARC-AGI、WebShop、ALFWorld 等 benchmark 不能完全代表企业生产环境。生产系统有权限、人工反馈、业务规则和审计流程，可能让合并风险降低，也可能因为多系统串联让风险放大。

第三，本文不是反对 consolidation。长期 Agent 必须压缩经验，否则成本和延迟不可控。真正的问题是无条件、无来源、无验证、无回滚的 consolidation。

第四，DimMem 和 SAGE 只是对照方向，不是本文主源，也不能直接证明它们能解决 faulty consolidation。DimMem 的结构化字段可能缓解条件丢失，但抽取器仍可能写错；SAGE 的反馈闭环可能改善图谱质量，但也需要防止错误反馈自我强化。

第五，很多工程系统会混合使用摘要、向量检索、知识图谱、规则和人工编辑。本文的建议需要落到具体系统后再做权衡，不能直接转成一套固定架构。

工程判断：先保留证据，再谈抽象

这篇论文让我对 Agent memory 的优先级判断更保守了。过去很多讨论默认“原始轨迹太长，所以要尽快总结”。现在更合理的默认值应该是：原始轨迹是证据层，consolidated memory 是假设层。证据层可以冷存储、分片、索引和按需回放；假设层必须被门控、验证和回滚。

生产 Agent 不应该在每次成功后立刻把经验写成长期规则。它应该先问几个问题：

这个经验是否只属于当前任务、当前用户或当前环境。
是否有足够多 episode 支持同一个抽象。
是否存在反例或失败样本。
写入后会不会覆盖更具体、更可靠的旧 memory。
如果这条 memory 错了，系统如何发现并撤销。

如果这些问题没有答案，最好的 memory action 往往不是 Consolidate，而是 Retain：保留原始 episode，给它加上来源、标签和可检索结构，等证据足够再晋升。

长期记忆不是让 Agent 永远相信过去。长期记忆的工程目标，是让 Agent 能在过去、当前状态和可验证证据之间做受控选择。

自审

事实可靠性：论文提交日期、作者、核心实验结论和 ARC-AGI Stream 的 Retain/Delete/Consolidate 设定来自 arXiv 页面与作者项目页；DimMem 的提交/修订日期、结构字段、LoCoMO-10、LongMemEval-S、token cost 和代码链接来自 arXiv 页面；SAGE 的提交日期、writer-reader loop、评测范围和 Recall@2/5 来自 arXiv 页面。所有数值均以作者报告呈现。

来源完整性：文章列出 arXiv、项目页、GitHub 和工程讨论入口；工程讨论只作为当天信号和外部解释，不作为核心事实来源。

原创性：本文主线是 memory write path 和 faulty consolidation，区别于 2026-05-20 LongMINT 文章的 multi-target interference，也区别于 2026-05-05 memory dilution 文章的 continual-learning/检索稀释视角。

标题与内容：标题没有宣称 Agent 记忆不可用，只强调 consolidation 不是后台清理，符合来源边界。

薄内容检查：文章包含技术问题、机制拆解、工程设计、适用场景、失败模式、可验证指标和局限分析，不是摘要改写。

猜测边界：对事务化写路径、指标和生产架构的建议属于工程推断，文中用“我的判断”“更稳妥”等表达区分来源事实和判断。

站内重复：仓库内未发现 Useful Memories Become Faulty、2605.12978 或 faulty consolidation 专题文章；已有文章虽然讨论 consolidation、forgetting 和 interference，但没有集中分析自动合并写路径风险。