长程智能体跑得越久，背的历史就越重。每一步交互都被塞进上下文，上下文越长，推理成本越高，而真正有用的信息反而越难被捞出来复用。过去一年，上下文管理大多在「怎么压缩、怎么检索」上打转，却很少有人回答一个更底层的问题：一段历史到底什么时候才安全到可以压掉？9 月 23 日，三篇几乎同一天挂上的预印本，不约而同地扑向了这个子方向，把「长程记忆压缩」从边缘技巧推成了独立课题。
长程 agent 的历史债：上下文与成本一起膨胀
问题根源很直白：长程 agent 在任务执行中持续累积交互历史，而历史里每条信息的重要性会随 agent 状态变化。固定窗口、固定周期或单纯按相关性来压，都会踩坑——压早了，未来动作还要用的信息没了；压保守了，上下文开销又压不下来。三篇新研究没有各说各话，而是分别抓住了「时机」「信号」「证据」三个侧面，共同把压缩做得更省、更准。
StateComp：让状态决定「何时能压」
arXiv 2609.27298 的 StateComp（状态条件压缩）给出的思路是：不要按固定规则压，而按当前 agent 状态判断一段历史是否安全可压。它用两阶段标注构造 KEEP 与 READY 监督信号，在冻结的语言模型隐状态上训练一个对不平衡敏感的路由器；再把相邻的 READY 片段聚成连续区间，执行时替换成紧凑摘要。在 WorkBuddyBench 上，总 agent 与摘要 token 减少 52.27%，同时任务表现基本不掉，表征提取提速 12.67 倍。它的贡献是把「何时压」从拍脑袋变成了可学习的决策。
PaMER：动作前的隐状态已编码了记忆需求
arXiv 2609.27286 的 PaMER 换了个更刁钻的角度：它去看了每次 agent 动作之前那一瞬的隐状态，发现「要不要压缩、要不要召回」的需求，其实已经被模型内部表示出来了，而且没法简单用上下文长度或交互进度解释，在不同模型深度还呈现不同的形成模式。进一步的结论是，大部分记忆决策信息保存在一个紧凑的近期上下文里，而按需恢复的历史证据，正好补上近期上下文缺的那截长程依赖。PaMER 再加一步「按步选证据」，只恢复当前任务真正要用的历史。这等于说：模型自己知道什么时候该记、什么时候该忘，关键是把它听见。
GEM：别只看几何，要看任务证据
arXiv 2609.27332 的 GEM（几何引导证据保留记忆）点出了一个常被忽略的陷阱：用几何冗余判断「能不能压」是不够的。实验显示，在相同的保留块数下，按证据感知选择，能把下一步动作的 Top-3 保留率从 0.31 拉到 0.69，而质心相似度仍停在 0.98——也就是几何上看几乎一样，任务证据却差很多。GEM 是个免训练的压缩器：先保护任务与执行证据，再用几何残差补覆盖。它把单任务平均合并 token 从 2.69M 降到 2.11M（降 21.4%），同时奖励基本不降。这条路线提醒同行：压缩的优化目标，应该是「保留任务证据」，而不是「看起来覆盖得全」。
多模态也中招：MM-ContextFold
同一周还有一篇 MM-ContextFold，把问题延伸到多模态智能体检索。它基于约一万条轨迹的实证研究指出：原始图像在视觉线索被文本化后会越来越冗余，继续留着反而抬高输出熵、拖垮准确率。于是它保持一个纯文本主上下文做高层规划，只在图像相关的子任务里临时拉起一个短期分支上下文，按需加载图像。这套「上下文折叠」同样免训练，思路与前面三篇一脉相承——都是在不同模态、不同证据类型上，做同一件事：只留此刻真正要用的。
这条线为什么现在热
四篇工作合起来，划出了一个清晰的新子方向：长程智能体的记忆管理，重点正从「怎么压」转向「何时压、压什么、留什么证据」。它们大多不动模型权重，只在冻结骨干上做路由、检索与重排，工程上更易落地。对要把 agent 跑长、跑便宜的团队，这类方法的增量很实在——同样的任务，上下文更短、token 更少、关键信息更不容易被淹没。当然，这些结论目前主要来自各自基准（如 WorkBuddyBench）的实测，跨模型、跨真实业务链路的泛化表现，仍待更多独立验证。