TL;DR

本文核心观点：

  1. 上下文窗口不是记忆 — 上下文窗口是工作记忆的载体，session 结束就清空；真正的长期记忆需要持久化存储
  2. 每轮只解冻近 3 轮 episode，长期记忆走只读向量库 — 显存峰值降低 54%，不是因为压缩了记忆，而是因为不让所有历史都进入 GPU 计算图
  3. 50 步多跳任务遗忘率从 31% 降到 9% — 选择性解冻策略在保持记忆可用性的同时，大幅削减了每轮需要激活的数据量
  4. LangGraph 中间件实现 — 不是论文概念验证，是一个可嵌入现有 LangGraph 流水线的组件

上下文窗口的边界

大上下文窗口解决的是单次调用能看到多少历史的问题。但上下文窗口本质上是工作记忆——session 结束就清空，下次对话从零开始。

这是设计上的根本混淆：把工作记忆的容量扩展了，却以为解决了长期记忆的问题。一个 100 万 token 的上下文窗口可以让你这一轮看到很多历史，但它不告诉你这些历史下次还在不在。

真正需要长期记忆的场景：Agent 在第三天记住用户偏好、在第四周记住项目里的 API 约定。上下文窗口对这些毫无帮助。

选择性解冻：只激活最近的episode

EpisodicFreeze 的核心设计思路是解耦工作记忆和长期存储。

每一轮推理，Agent 只”解冻”最近 3 轮的 episode 内容，放入工作记忆参与推理。长期记忆本身不参与计算——它以只读向量库的形式存在，Agent 需要的时候通过检索补进上下文，而不是整库加载进 GPU。

这个策略能work 的底层逻辑：不是所有历史都需要参与当前推理。50 步多跳任务里，真正影响下一步判断的通常是最近几步的决策上下文，早期 episode 的信息通过向量检索按需召回就够了。

遗忘率与显存峰值的双重收益

选择性解冻带来了两个可测量的改善：

显存峰值降低 54%。不是因为记忆被压缩了，而是因为每轮参与计算的数据量大幅缩减。长期记忆以向量形式存在，不进入 GPU 计算图，只有被检索命中的片段才被加载。

50 步多跳任务遗忘率从 31% 降到 9%。这里的遗忘率指的是：Agent 在长程任务中重复之前已解决的子问题、或忽略之前确立的约束条件的比例。选择性解冻让最近 3 轮episode始终保持激活状态，防止早期关键决策被后续轮次稀释。

LangGraph 中间件：嵌入成本降到最低

论文提供了一个 LangGraph 中间件实现。这是降低落地门槛的关键选择：不需要改造已有的 LangGraph 流水线的核心逻辑，在节点层面插入 EpisodicFreeze 的状态管理层即可。

中间件负责：

  • 维护近 3 轮 episode 的激活状态
  • 管理长期向量库的检索和回填
  • 处理 episode 与工作记忆之间的数据交换

对于已经在用 LangGraph 的团队，这意味着接入成本不是重构，而是加一层调用。

结尾

记忆系统的设计有一个常见误区：把容量当能力。上下文窗口越来越大，向量库越来越丰富，但 Agent 的长程推理质量并没有等比例提升。EpisodicFreeze 的贡献在于指出了问题的另一面：不是记忆不够用，而是每次推理时激活的记忆太多了。选择性地让哪些记忆进入工作记忆，和记忆本身一样重要。

Paper: EpisodicFreeze: Decoupling Working Memory from Long-Term Store — arXiv:2608.13266