长程智能体不是缺上下文，而是缺会翻旧账的记忆
你有没有碰到过这种 Agent：前面查了半天资料，排除了一堆错误候选；跑到第 60 轮，突然又像失忆一样，把早就排除过的路重新走一遍。
这不是模型不会搜索，也不一定是上下文窗口太小。更烦人的地方在于：它其实“见过”关键线索，只是当前这一刻不知道该把哪段旧历史翻出来。
这篇 arXiv:2605.24468 的论文《SAM: State-Adaptive Memory for Long-Horizon Reasoning Agent》聊的就是这个问题。作者提出 State-Adaptive Memory，简称 SAM：把长程交互历史切成可回溯的“页面”，每页生成一个轻量 cue 放在上下文里；真正需要旧信息时，Agent 按当前意图选择 cue，再让记忆模型回到对应原始页面里重构有用内容。我的第一反应是，这个设计最漂亮的点不在“总结得更短”，而在“总结不再替代历史”。它更像给 Agent 做了一套可查询的案件卷宗。
论文信息
- 论文标题：SAM: State-Adaptive Memory for Long-Horizon Reasoning Agent
- arXiv ID：2605.24468
- 链接：https://arxiv.org/abs/2605.24468
- 提交日期：2026 年 5 月 23 日
- 作者：Yuyang Hu, Hongjin Qian, Shuting Wang, Jiongnan Liu, Ziliang Zhao, Jiejun Tan, Zheng Liu, Zhicheng Dou
- 机构：GSAI, Renmin University of China；Beijing Academy of Artificial Intelligence
- 代码/系统定位：一个外挂式记忆模块，不重训底层 Agent backbone
核心摘要
长程智能体的痛点，并不是“历史太长”这么简单，而是过去某个看似边缘的线索，可能在几十轮之后才突然变成决策关键。截断会丢信息，滚动总结会把细节压扁，按最近性取上下文又经常取错。SAM 的做法是把轨迹切成 page，写入时生成 memory cue，读出时按当前 recall intent 回到原始 page 里重构信息。实验上，在 GLM-4.7 上四个 benchmark 平均分从无上下文管理的 49.4 提到 57.0；在 Qwen3.5-35B-A3B 上从 44.5 提到 48.8。这个结果挺能打，但我觉得它更像一次记忆接口设计上的工程突破，而不是单纯靠更大模型刷出来的分数。
问题不是窗口，而是“当前状态”
长程 Agent 的交互历史很脏。
里面混着思考、搜索 query、网页 observation、代码执行结果、临时假设、被排除的候选、半截结论。你把这些东西全塞进 128K 上下文里，模型也不一定能用好。很多时候，真正需要的只是一小块：已经确认了什么，排除了什么，还有哪个约束没闭合。
作者把这个东西叫 decision state。它不是原始轨迹本身，而是面向下一步决策的“任务状态”。论文里用一个很抽象但有用的式子表示：
这里 \(\tau_t\) 是到第 \(t\) 步为止的交互轨迹，\(x\) 是任务。\(s_t\) 关心三件事：已经建立的事实、已经解决的问题、还没完成的部分。
这个视角挺关键。
如果你把问题理解成“上下文太长”，自然会想到截断、压缩、保留最近 \(k\) 轮。可如果你把问题理解成“当前决策需要哪部分旧证据”，方案就会变成：怎么让 Agent 在需要的时候，找回过去那块证据。
这就是 SAM 的切入点。
SAM 的核心：cue 不是总结，而是索引
先看论文的总览图。
图1：上半部分是写入和读出路径。左边把临近 token budget 的交互片段切成 page，并生成 memory cue；右边根据 recall intent 选 cue，再从原始 page 里重构当前有用的信息。下半部分是训练流程：先用强模型轨迹做监督微调，再用 OAT-GRPO 做强化学习优化。
SAM 有两个视角。
一个是留在上下文里的轻量 memory cue。它要短，要能提醒 Agent “这里曾经发生过什么”。
另一个是放在外部 page store 里的原始轨迹页面。它不在活跃上下文里，但没有被销毁。
这和普通 rolling summary 最大的差别在这里：summary 通常是替代历史，写完就回不去了；SAM 的 cue 更像索引卡片，卡片上写着“第 2 页记录了哪些候选被排除、哪个约束还没解决”，真要细查时还能翻回原始页面。
论文把最近交互切成 page：
每个 page 生成一个 cue \(m_k = M_{sum}(p_k)\)。cue 放进 memory bank，原始 page 放进 page store。等 Agent 觉得需要查旧信息时，它发出一个 recall intent \(q_t\)，选择一小组 cue，再让记忆模型读对应 page：
返回的 \(\rho_t\) 不是原文回放，而是围绕当前意图重构出来的决策支持。
我很喜欢这个“写时粗、读时细”的拆法。写入时别太聪明，避免复杂语义切分带来的不稳定；读出时再根据 Agent 当前问题做精细重构。其实吧，这比“每轮都让模型总结一下历史”更贴近真实工程：日志先按时间归档，排障时再按问题翻日志。
为什么“只做总结”不够
论文专门做了一个 recall 侧消融：固定 SAM 的 page store，只改读出方式。
图2：在 Qwen3.5-35B-A3B 上，SAM 的 intent-driven recall 达到 42.2；summary-only 为 39.0，recency 为 37.0，raw-content 为 38.0，无上下文管理为 36.0。只保留原始 page 或最近 page 都不够，关键是按当前意图重构。
这张图信息量很大。
summary-only 不是完全没用，39.0 比无管理的 36.0 高。但它离 SAM 的 42.2 还有距离。recency 只有 37.0，几乎只是稍微好一点。raw-content 也只有 38.0。
看到 raw-content 这个数，我反而更信服作者的论点。因为如果“原始信息没丢”就够了，直接把 raw page 塞回来应该接近 SAM。可它没有。原因很现实：原始页面太长、太杂，当前决策需要的是重构后的证据链，不是一坨历史文本。
所以 SAM 的收益不是“我保留了更多历史”。
是“我知道当前该怎样使用历史”。
训练：为什么普通 GRPO 不太对劲
SAM 不是只写 prompt。作者训练了一个 Qwen3.5-9B 记忆模型，负责 page consolidation 和 intent-driven recall。
训练分两段。
第一段是 expert-guided SFT。Claude-4.5-Opus 和 GPT-5.4 作为专家记忆模型，在正确轨迹上生成 consolidation 和 recall 的监督信号。这里保留的是能得到正确最终答案的轨迹，所以 SFT 学到的不是普通摘要风格，而是“对后续解题有帮助的记忆写法”。
第二段是 OAT-GRPO，全称 Oracle-Anchored Tree GRPO。
GRPO 大家可能已经很熟，DeepSeek-R1 那波之后，组内相对优势、少一个 value model、用同组样本做 baseline，成了 LLM RL 里很常见的讨论对象。但这里的问题有点不一样：被训练的不是 Agent 主策略，而是 Agent 调用的一个 memory tool。
这会带来信用分配麻烦。
一次长程任务里，Agent 可能多次调用记忆模型。最终答案对了或错了，不能直接告诉你“第 37 轮那次 recall 写得好不好”。普通轨迹级奖励太稀疏，容易把功劳和锅都糊到整条 trajectory 上。
OAT-GRPO 的办法是把 memory call 组织成树。每到一个 memory action 节点，就采样多个 sibling recall，让冻结的 reasoner 沿每个分支继续跑，最终叶子节点按答案正确性打分。一个 memory action 的 outcome reward 是它下面所有叶子的平均：
这样，同一个父上下文下的多个 recall 输出可以互相比较。你不是问“这条任务成没成”，而是问“在同一个 Agent 状态下，哪种记忆输出更能把后面带向正确答案”。
作者又加了一个 oracle-anchored recoverability reward。因为最终答案奖励还是稀疏，他们用 GPT-5.4、GLM-4.7、DeepSeek-V4-Flash 组成 committee，为同一个 recall intent 和 page 生成参考；再让 GPT-5.4 作为 assessor，从相关性、覆盖度、一致性给候选 recall 打 0 到 10 分，缩放到 \([0,1]\)。
坦率地讲，这块工程代价不小。用 frontier model 当 teacher 和 judge，训练成本、偏差继承、可复现性都会是问题。论文自己也在 limitations 里承认了这一点。但从方法设计看，它确实对准了 memory 这个组件的核心难题：记忆质量只有在未来使用时才显现。
实验设置：控制变量做得比较干净
作者评估了四个长程 benchmark：
| Benchmark | 主要考察点 |
|---|---|
| BrowseComp | 长程网页浏览，多步证据聚合，早期线索可能很晚才有用 |
| BrowseComp-ZH | 中文多跳搜索，覆盖 11 个领域，网页噪声和跨语言问题更明显 |
| WideSearch | 大搜索空间里的广泛探索，需要回看较早收集的证据 |
| HLE | 科学知识密集任务，还会用到 scholar 和 python 工具 |
训练数据来自公开 agent trajectory：OpenSeeker 的 11.7K QA 轨迹，以及 OpenResearcher 的深度研究轨迹。作者会过滤掉过短轨迹和最终答案与 gold 不一致的轨迹。
推理协议也比较明确：
| 项目 | 设置 |
|---|---|
| 上下文窗口 | 128K tokens |
| 触发上下文管理 | 超过 64K tokens |
| page 大小 | 默认 32K tokens |
| 工具 | search、visit、memory；HLE 额外有 scholar、python |
| 汇报方式 | avg@3，三次独立 rollout 平均 |
| 评测抽样 | BrowseComp 和 HLE 各抽 200 题；BrowseComp-ZH 和 WideSearch 全量 |
这里有个细节要看清：开放 Agent 系统的数字，比如 WebThinker、WebSailor、ReSum、IterResearcher、AgentFold，是从原论文拿来的，不是作者在完全相同协议下重跑。真正公平的控制变量比较，是同一个 backbone、同一套工具下的 w/o CM、discard-tool、recent-k、summary 和 SAM。
这个区分很重要，不然容易把跨系统表格读得太满。
主结果：SAM 在两个 backbone 上都赢了
论文的主表很长，我把最关键的受控上下文管理结果摘出来。
| Backbone | 方法 | BrowseComp | BrowseComp-ZH | HLE | WideSearch | 平均 |
|---|---|---|---|---|---|---|
| GLM-4.7 | w/o CM | 43.5 | 52.5 | 37.2 | 65.4 | 49.4 |
| GLM-4.7 | discard-tool | 49.0 | 62.5 | 36.5 | 66.3 | 53.6 |
| GLM-4.7 | recent-k | 51.5 | 61.2 | 37.2 | 67.1 | 54.3 |
| GLM-4.7 | summary | 53.5 | 59.0 | 37.5 | 68.3 | 54.6 |
| GLM-4.7 | SAM | 56.5 | 64.2 | 38.2 | 69.2 | 57.0 |
| Qwen3.5-35B-A3B | w/o CM | 36.0 | 42.2 | 34.0 | 65.6 | 44.5 |
| Qwen3.5-35B-A3B | discard-tool | 40.5 | 43.5 | 36.0 | 64.7 | 46.2 |
| Qwen3.5-35B-A3B | recent-k | 38.2 | 45.0 | 34.2 | 65.3 | 45.7 |
| Qwen3.5-35B-A3B | summary | 39.5 | 43.0 | 35.2 | 66.8 | 46.1 |
| Qwen3.5-35B-A3B | SAM | 42.2 | 46.5 | 37.2 | 69.1 | 48.8 |
在 GLM-4.7 上，SAM 比最强 heuristic summary 的平均分高 2.4；比无上下文管理高 7.6。
在 Qwen3.5-35B-A3B 上，SAM 比最强 heuristic discard-tool 高 2.6；比无上下文管理高 4.3。
不是爆炸式提升，但很稳。尤其 BrowseComp 和 BrowseComp-ZH 这种长链搜索任务，SAM 的收益更明显。GLM 上 BrowseComp 从 43.5 到 56.5，BrowseComp-ZH 从 52.5 到 64.2；Qwen 上 BrowseComp 从 36.0 到 42.2，BrowseComp-ZH 从 42.2 到 46.5。
我的判断是：这类任务里，Agent 的失败经常不是“最后一步推理不会”，而是“它忘了之前排除过什么”。SAM 正好打在这个痛点上。
消融：SFT 和 OAT-GRPO 都有用，但别神化 RL
作者用 GLM-4.7 作为冻结 Agent backbone，做了训练阶段和 memory backbone 大小的消融。
| 变体 | BrowseComp | BrowseComp-ZH | HLE | WideSearch | 平均 |
|---|---|---|---|---|---|
| w/o CM | 43.5 | 52.5 | 37.2 | 65.4 | 49.4 |
| SAM | 56.5 | 64.2 | 38.2 | 69.2 | 57.0 |
| w/o SFT | 55.2 | 63.2 | 37.3 | 67.9 | 55.9 |
| w/o OAT-GRPO | 54.5 | 62.7 | 37.4 | 67.7 | 55.6 |
| SAM-27B | 56.6 | 63.9 | 37.8 | 68.3 | 56.7 |
去掉 SFT 或去掉 OAT-GRPO 都会掉，平均大概掉 1.1 到 1.4。这个幅度说明两段训练确实互补，但也提醒我们别把论文解读成“RL 一上就飞升”。
更准确的说法是：架构本身贡献最大，监督轨迹给了一个可用的记忆先验，OAT-GRPO 再把 recall 输出往下游任务收益上推。
SAM-27B 的平均分 56.7，和 9B full-finetune 的 57.0 很接近。这里我会稍微谨慎一点：这说明机制对更大 memory backbone 也成立，但不代表越大越好。27B 版本是 LoRA SFT，没有后续 RL，训练方案并不完全对齐。
长程行为：越拖到后面，记忆越值钱
论文还分析了 SAM 在长程场景里的行为。
图3a：在上下文管理触发时，SAM 的 tool-call count、confidence 和 accuracy 都最高。SAM 的 accuracy@trigger 为 39.3，summary 为 37.4，recent-k 为 29.1，discard-tool 为 24.5。
这张图能回答一个很实际的担心：外部记忆会不会只是让模型更“自信”，但没有更准？
SAM 的 confidence@trigger 是 72.9，比 summary 的 71.6 稍高；但 accuracy@trigger 是 39.3，比 summary 的 37.4 也高。提升不只是声音更大，确实更准一点。
图3b：BrowseComp 按交互轮数分桶后，SAM 在 21–40、41–80、超过 80 轮三个区间都领先。超过 80 轮时，w/o CM 降到 0.0，summary 约 25.0，SAM 仍有 27.1。
长程任务越往后，普通策略越容易崩。w/o CM 在超过 80 轮时直接到 0.0，这个数有点刺眼。summary 还能撑住一部分，但 SAM 仍然领先。
不过我也不会把 27.1 讲得太漂亮。超过 80 轮的任务本身已经很难，SAM 只是让 Agent 不那么快失忆，还没有解决长程搜索里的全部失败模式。
图3c：page size 从 32K 到 128K 的敏感性。BrowseComp 上 32K 最好，为 44.0；BrowseComp-ZH 上 32K 最好，为 48.4。128K 在 BrowseComp 上掉到 35.0，说明 page 太大时 cue 的意图信号会被稀释。
这张图挺有工程味。
page 不是越大越好。32K 到 64K 是比较合适的区间；到 128K，BrowseComp 反而从 baseline 的 36.0 附近掉到 35.0。你想想看，一个 page 里塞太多无关交互，cue 本身就会变得模糊。后面 recall 再聪明，也得先从一个过大的抽屉里找东西。
论文里最有价值的案例：SAM 也会放大错误框架
我觉得附录里的 failure case 比成功案例更有意思。
成功案例是 BrowseComp 的 id=567：问题需要从 7 条独立线索里识别一个作者，再回答相关历史学家。Agent 跑到 65 轮，超过触发阈值。SAM 把早期候选和排除理由存成两个 page；后面 Robert Graves 这个新线索出现时，Agent 发起 goal-conditioned recall，SAM 把旧的 sibling-count、von-Ranke lineage、Mann-family rejection 等证据合在一起，帮助它答出 Leopold von Ranke。
这是理想情况：早期线索被保留，后期意图能把它们重新激活。
失败案例 id=1058 更扎心。Agent 很早就锚定了错误路径：把问题框进 Home Game / The Darling Buds of May 这条链。SAM 忠实记录了这个错误框架，也保留了一些 caveat，比如替代候选、性别矛盾、关系链未闭合。可后续 Agent 的 recall query 仍然在错误框架里提问，SAM 只能围绕这个框架重组信息。最后 Agent 明知道关系链没完全找到，还是给了 80% confidence 的错误答案。
这说明 SAM 的边界很清楚。
它擅长保存和重构 Agent 已经探索过的信息；但如果 Agent 从一开始就问错问题、搜错方向、把 recall intent 写得带偏，SAM 不会凭空创造未探索的正确线索。
说实话，这个局限比论文主表更值得工程团队记住。记忆系统不是纠错神谕，它更像一个高质量案卷管理员。案卷管理员能提醒你“这里有未解决矛盾”，但侦探自己非要忽略，那还是会破错案。
和已有方法比，SAM 到底新在哪
长程 Agent 的上下文管理大概有三类常见路线。
| 路线 | 典型做法 | 问题 |
|---|---|---|
| 截断或保留最近历史 | discard-tool、recent-k | 简单稳定，但远期证据容易丢 |
| 折叠成总结 | ReSum、AgentFold、rolling summary | 压缩后不可逆，后面需要细节时很难恢复 |
| 检索历史 | 从原始历史或向量库里捞片段 | 检索目标和当前意图不一定对齐，返回内容可能太碎或太杂 |
| SAM | cue 留在上下文，raw page 外部保存，按意图回读 | 系统更复杂，训练和调用成本更高 |
所以我不会说 SAM 推翻了总结类方法。更像是补上了它们最难受的一块：总结不能只服务“现在省 token”，还要服务“未来能找回”。
这也是“state-adaptive”这个词真正的含义。不是记忆内容一直变，而是访问记忆的方式随 Agent 状态变。
我对这篇论文的判断
这篇论文最值钱的地方，是把长程 Agent 的上下文问题从“压缩文本”改写成“可恢复记忆接口”。
这个改写很重要。
过去很多方案都在问：怎么把 100K 历史压成 10K？SAM 问的是：怎么让未来某个状态需要旧信息时，还能按意图把证据链恢复出来？这两个问题看起来接近，工程结果差很多。
我会给它三个正面评价。
一是架构直觉清楚。cue-page 结构没有过度复杂化，写入时 page-based consolidation，读出时 intent-driven recall。这个模块可以挂在不同 backbone 上，也不要求重训 Agent。
二是实验控制还算扎实。真正的上下文管理 baseline 共享 backbone、工具和推理协议，SAM 在 GLM-4.7 和 Qwen3.5-35B-A3B 上都赢了，不是单点偶然。
三是作者没有只报主表，还分析了 recall 机制、page size、长程 round bucket 和失败案例。这些分析让方法更可信。
但我也会保留几个疑问。
第一，训练成本偏重。SFT 用 Claude-4.5-Opus 和 GPT-5.4 做 expert traces，RL 又用 GPT-5.4、GLM-4.7、DeepSeek-V4-Flash 做 committee 和 judge。这个 pipeline 对普通团队不轻。
第二，测试集中 BrowseComp 和 HLE 是各抽 200 题。这个选择能理解，长程 Agent 评估太贵，但它也让统计稳定性没那么完美。
第三，开放 Agent 系统的横向比较不能读得过度。那些数字来自原论文，不是同协议重跑。真正应该关注的是同 backbone 下 SAM 对 summary、recent-k、discard-tool 的提升。
第四，latency 和运行成本还缺一张更硬的表。SAM 每次 recall 都要额外调用 memory model，还要管理 page store。对于真实产品，这部分吞吐、延迟和缓存策略会直接决定能不能上线。
如果你要把 SAM 用到工程里，我会这么试
别一上来就复刻 OAT-GRPO。成本太高，也不一定是第一瓶颈。
更现实的路线是：
- 先做 page store。把 Agent 的 tool call、observation、关键中间结论按 16K 到 64K 的粒度切 page，别只存纯文本，也存结构化元信息。
- 再做 cue。cue 不要写成普通摘要，而要包含“已确认事实、被排除候选、未解决 blocker、未来可能相关的线索”。
- 给 Agent 一个明确的 recall tool。输入不是关键词，而是当前意图：我要验证哪个假设？我要找之前排除某候选的原因？我要回看哪个 blocker？
- recall 返回时强制带 caveat。尤其是“证据不足”“冲突未解决”“该 page 未覆盖某方向”，不要藏在正文里。
- 最后再考虑训练。早期可以用强模型蒸馏 cue 和 recall，等有真实线上轨迹后，再用任务成功率做偏好或 RL。
有个我自己会额外加的机制：final answer 前做 blocker check。只要最近一次 recall 返回了未解决 caveat，Agent 就不能直接高置信提交，必须解释为什么 caveat 不影响答案，或者继续搜索。
这正好对准论文 failure case 里暴露的问题。
收尾
SAM 不是在告诉我们“上下文窗口不重要”。窗口当然重要，128K、1M 都有价值。
但窗口越长，越暴露另一个问题：信息多了以后，Agent 更需要一套记忆组织方式，而不是把所有历史都堆在眼前。
这篇论文给出的答案很朴素：把过去存成可翻阅的 page，把 page 的索引留在当前上下文里，等当前状态真的需要时，再按意图翻出来。
我觉得这个方向会越来越常见。未来的 Agent 系统，memory 可能不会只是一个向量数据库，也不会只是 rolling summary，而会变成一个可写、可读、可追责的外部认知模块。
如果你也在做长程搜索、深度研究、软件工程 Agent，这篇 arXiv:2605.24468 值得细读。不是因为它把分数刷到了多夸张，而是因为它把“Agent 为什么会忘事”这件事讲得很准。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我