长程智能体有个绕不开的动作：上下文窗口有限，跑久了就得把历史压一压、腾出空间继续干。最常见的做法是写一段文本摘要，把「Agent 觉得该留下的东西」存下来。但摘要天然有损——它只能保留写摘要那一刻被认为重要的内容，那些当时看不出用处的线索，就在压缩里永远丢了。一篇 10 月 8 日挂出的论文 REMORY，想给这道压缩补一条「残差连接」。
摘要之外，再追加一小段软记忆
REMORY 的思路不复杂：在文本摘要之后，由一个小记忆网络生成一段有界长度的软记忆 token，拼接在摘要后面一起交给冻结的 LLM。摘要负责「Agent 选留下的东西」，软记忆 token 负责「它来不及命名、却影响后续决策的东西」。论文把它类比成序列维度上的残差连接——软 token 不是可读的文字，而是一个学出来的潜变量，目标是让冻结模型拿着它续写时，逼近「拿着完整历史续写」的效果。换句话说，它没打算让模型重读一遍原始历史，而是用一个紧凑的潜表示，把丢掉的信息补回来一部分。
效果上，在 SummHay 长文档溯源基准里，REMORY 在几乎不损失洞见覆盖的前提下改善了来源归属，只用约 5.2% 的输入位置，就逼近了全上下文的联合得分。在多个长程 Agent 基准上，Qwen3.8-27B 和 GLM-5.3-Flash 都拿到一致增益；两者在 BrowseComp 和 Terminal-Bench 2.1 上，重复的工具输出和工具错误也明显变少。这对长程任务是个实在的信号：很多 Agent 卡壳，不是不会干活，而是反复踩同一个工具坑、吐同样的废话，残差记忆恰好压住了这类重复。
它和同期的两条思路怎么摆
把 REMORY 放进近期的记忆讨论里看，位置很清晰。AutoCompact 研究的是「什么时候该压缩」，给出的是触发时机；Just-in-Time Memory 主张把整理推迟到问题已知之后再做事。REMORY 动手的是另一环：让提前写下的摘要不那么有损。三者其实都在拒绝「盲目压缩」，只是切口不同——一个管时机，一个管延后，一个管保真。同期还有一篇论文反过来指出，朴素地挂一层持久记忆往往测不出收益，因为单问题基准本就每条自带证据、且要求跨条件重置。两篇合起来说明：记忆不是「加上就有用」，而是「怎么加、加什么、在什么基准下验证」才有用。
边界与前提
但残差记忆不是免费午餐。它要为每个基座模型单独训练那个小网络，论文尚未展示跨模型家族的迁移能力；软 token 是不可读的潜变量，出了事你没法像读摘要那样审计它「记了什么」。它给上下文省了预填与 KV，却多了一个要训练、要回归的组件。对已经上了压缩流程的团队，它的价值在于把「摘要漏掉的关键」补回来，而不是替代摘要本身。更务实的期待是：把它当成压缩管线的可选增强——当你的长程 Agent 反复犯同一个工具错误、或溯源得分上不去时，值得试一次；别指望它能救回一套本来就没做时效淘汰的烂记忆。
从工程视角看，REMORY 点破的一件事很值钱：上下文压缩的本质是一道「该记住什么」的赌注，而赌注的代价在压缩那一刻还看不清。软记忆 token 把问题从「我必须记住哪些字」换成「我必须让模型知道哪些信息存在」，用更紧凑的潜表示兜住了摘要的损失。当智能体越跑越长，这种「不重读原文、却补回关键信息」的思路，可能会比再堆上下文窗口更经用。