长上下文解决不了长期记忆

Agent 产品一谈长期工作，很容易把问题推给上下文窗口。窗口更大，能塞更多历史，似乎就不容易忘事。这个直觉只对了一半。

更大的上下文确实能降低短期遗忘，但它没有回答长期记忆里最麻烦的几个问题：什么值得写入，什么应该丢掉，什么需要改写，什么已经过期，什么只对这个用户有效，什么可以被团队共享，什么在当前目标下才应该被取回。

最近几篇 Agent memory 论文有一个共同变化：它们不再把记忆当成一个外挂向量库，而是把记忆当成有生命周期的系统资源。存储只是第一步。工程问题在后面：写入、索引、链接、检索、更新、遗忘、调度、成本和权限。

这也是为什么「记住所有东西」不是答案。没有过滤的记忆会变脏，没有目标的检索会变散，没有生命周期的知识会过期。长期 Agent 如果把记忆层做成历史垃圾堆，越用越笨并不奇怪。

Goal-Mem：检索必须服从目标，而不是只看相似

Goal-Mem 处理的是 RAG-based memory 里一个很常见的问题。传统做法通常拿用户当前一句话去检索语义相似的历史片段。这个方法简单，但遇到多跳推理和隐含条件时很容易失效。相似片段不一定包含中间事实，能搜到一堆相关内容，也不等于能回答当前问题。

Goal-Mem 的改法是从用户问题反推目标。它把目标拆成原子子目标，再围绕每个子目标做定向检索；当中间目标无法满足时，再判断还缺什么记忆。这是把检索放回推理链里。

这对 Agent 记忆很关键。长期记忆不是「搜索历史聊天记录」。它应该回答更具体的问题：为了完成当前目标，哪些过去信息能补上缺口，哪些只是看起来相关，哪些会干扰判断。

如果一个 coding agent 要修一个老 bug，它需要的可能是三个月前某个架构取舍、一次失败迁移、一个测试环境限制。相似度检索未必能找到这些材料。目标驱动的记忆检索，才更接近真实任务。

D-MEM：写入要有门槛，惊讶和效用都要算

D-MEM 从另一个方向切入：不是所有输入都值得触发长期记忆重组。论文批评 A-MEM 这类 append-and-evolve 系统会遇到写入延迟和 token 成本问题，因为每次新记忆都可能触发复杂的历史记忆演化。

它提出的 Fast/Slow routing 很有启发。日常、低价值、低 surprise 的输入，可以绕过或缓存到快速访问层；高 surprise、高 utility 的输入，比如事实矛盾、偏好变化、关键失败，才触发慢速的记忆演化管线。论文用 Reward Prediction Error 来做类比，重点是写入策略。

这条原则很适合工程系统。Agent 每天会看到大量中间日志、用户闲聊、重复命令、临时文件、失败尝试。如果都写进长期记忆，系统会被自己的历史拖慢。值得长期保留的，往往是偏好变化、稳定约束、失败模式、例外规则和高价值决策。

D-MEM 的另一个贡献是把噪声加入评测。长期会话里，噪声重点是默认环境。一个记忆系统如果只能在干净历史里表现好，进入真实产品后很快会失真。

A-MEM：记忆要组织成网络，而不是平铺列表

A-MEM 关注的是记忆组织方式。它指出，很多记忆系统能存、能搜，但缺少更复杂的组织能力；固定结构也限制了跨任务适应。它借鉴 Zettelkasten 方法，把新记忆写成带上下文、关键词、标签的结构化 note，并自动寻找与历史记忆的连接。

这比「每条历史一条 embedding」更接近人类使用经验的方式。长期记忆里的价值在记录之间的关系：这次失败和上次失败是否同类，这个用户偏好是否覆盖旧偏好，这个项目规则是否只适用于某个目录，这个成功方案能不能迁移到另一个场景。

不过 A-MEM 也暴露了成本问题。记忆越多，维护关系越贵。D-MEM 后来强调 gating，本质上就是在回答：既然记忆网络会带来成本，系统必须决定什么有资格进入网络，什么只配留在短期缓存里。

所以更稳的判断是：Agent 记忆不能只做平铺存储，也不能无节制演化。它要在结构和成本之间找平衡。

Pancake：多 Agent 记忆会变成服务系统问题

当多个 Agent 同时存在，记忆问题会从产品功能变成服务系统问题。Pancake 这篇论文直接把问题放到 LLM serving 里：大规模存储、频繁更新和多个共存 Agent，会让近似最近邻搜索变得复杂且昂贵。

它提出多层索引缓存、跨 Agent 协同索引管理，以及 GPU-CPU 协同加速。论文在 realistic agent workloads 上报告了超过 4.29 倍的端到端吞吐提升。

这组结果最值得看的是问题位置的变化。记忆不再只是某个 Agent 的私有附件，而会变成团队、系统、租户之间共享或隔离的基础设施。多个 Agent 读写相近知识，索引如何复用；不同用户的数据如何隔离；热记忆和冷记忆如何分层；GPU 资源和 CPU 存储如何配合，都会进入工程账本。

这和今天企业部署 Agent 的趋势一致。只要 Agent 数量上来，记忆层就会遇到和数据库、缓存、搜索系统类似的问题：吞吐、延迟、一致性、权限、冷热分层和成本归因。

MemOS：把记忆当成可调度资源

MemOS 把这个方向说得更直接。它认为现有大模型主要依赖静态参数和短期上下文，RAG 虽然引入外部知识，但仍然像一个无状态 workaround。MemOS 提出的核心是把 memory 作为可管理的系统资源，统一 plaintext、activation-based 和 parameter-level memories。

它的 MemCube 设计把内容和 provenance、versioning 等元数据包在一起。这个细节很重要。长期记忆如果没有来源和版本，就很难审计，也很难撤回。一个 Agent 记住了错误事实，或者记住了已经过期的用户偏好，系统必须知道这条记忆从哪来、何时写入、被谁更新、在哪些场景里用过。

MemOS 的价值在于它把记忆从「上下文补丁」推进到系统资源管理。记忆可以组合、迁移、融合，也可以被调度和演化。这个方向比单纯拉长 context window 更接近长期 Agent 的现实需求。

记忆层要先回答六个工程问题

把这些论文放在一起，可以得到一套更务实的检查清单。一个长期 Agent 的记忆层，至少要回答六个问题。

  • 写入：哪些信息值得进入长期记忆，哪些只留在当前任务。
  • 检索：当前目标需要哪些中间事实，不能只按语义相似度取。
  • 更新：新事实是否覆盖旧事实，还是只是在某个条件下成立。
  • 遗忘：过期偏好、错误经验、临时状态和敏感内容如何清除。
  • 调度：热记忆、冷记忆、跨 Agent 共享记忆如何分层管理。
  • 审计：每条记忆的来源、版本、适用范围和使用记录能不能追踪。

这六件事没有做好，记忆越多越危险。它会增加 token 成本，放大旧错误，制造隐私风险，还可能让 Agent 在不该泛化的地方套用旧经验。

反过来，如果这六件事做得足够扎实，记忆层就会成为竞争点。它让 Agent 不必每次从零开始，也不必把所有历史重新塞进上下文。系统可以用更少的材料，取回更准的中间事实，保留更有价值的经验。

下一阶段是记忆更有边界

这轮 Agent memory 研究的共同含义，可以压成一句话：长期记忆重点是治理问题。

Goal-Mem 说明检索要围绕目标。D-MEM 说明写入要有门槛。A-MEM 说明记忆要能组织和演化。Pancake 说明多 Agent 记忆会遇到服务系统瓶颈。MemOS 则把记忆提升为可调度、可版本化、可迁移的系统资源。

这条线也解释了为什么「无限上下文」不会自动带来可靠 Agent。上下文窗口像桌面，记忆层更像档案系统、缓存系统和权限系统的组合。桌面再大，如果没有整理、检索、过期、来源和边界，最后只会堆满东西。

值得期待的 Agent 记忆，重点是它知道什么该记、为什么记、什么时候取、什么时候删，以及取出来之后如何服务当前目标。