Beyond Retrieval: Query-Conditioned Reuse of Long-Horizon Agent Trajectories 精读

论文链接： arxiv:2608.12847

发表时间： 2026 年 8 月 13 日（arXiv v1）

发表机构： 西安交通大学计算机科学与技术学院 + MOE KLNN 实验室（纯高校工作；Yifei Li 与 Heng Wang 同等贡献，通讯作者 Lingling Zhang）

领域标签： cs.AI（智能体记忆、轨迹复用、长程任务评测）

一句话概括： 检索决定了"哪段历史值得看"，但没解决"这段历史怎么用"——QCR 用一页四字段的"目标绑定笔记"替换整条原始轨迹，让 Agent 复用流程的同时拒绝照抄旧值。

一、论文背景

1.1 Agent 记忆系统是什么

想象一个每天替你干活的 AI 助理：今天帮你订机票，明天帮你报销发票，下个月又要处理一张类似的发票。如果每次都从零开始摸索（打开哪个网站、点哪个按钮、填哪个表格），既慢又容易出错。Agent 记忆系统（Agent Memory）就是为了让智能体"把过去的经验带到未来的决策里"而生的——它维护一个外部存储，把历史交互记录下来，建立索引，在新任务到来时检索相关经验注入上下文。

过去几年这条线进展很快：MemGPT 把记忆管理做成操作系统式的分页调度，MemoryBank、HippoRAG、Mem0、A-MEM 各自改进了存储、索引和更新方式。与之配套的 LongBench、LoCoMo、LongMemEval 等基准则测试"系统能否在长上下文里找回证据"。这些工作共同让历史经验变得可访问了。

但论文开篇就点出一个微妙的缺口：经验可访问，不等于经验有用。绝大多数记忆评测到"检索"就结束了——系统能否保住一条记录、能否为查询排出相关条目、能否回答关于早先交互的问题。可对于一个真正要动手干活的 Agent，还有第二个问题：当一段经验进入上下文之后，它到底有没有帮 Agent 把当前任务做得更好？

1.2 轨迹记忆的"检索—复用"两步

论文的关键观察（Figure 1）是：瓶颈的位置随记忆条目的长度右移。

• 对于短事实（某个参数、一条本地指令），检索到约等于用上了——返回正确条目通常就提供了答案所需的一切，检索质量是记忆效用的良好代理。
• 对于长轨迹（一段完整的浏览器操作序列、一串 API 调用），条目本身能省下的探索量远大于短事实，但难度也从"找到"转移到了"用对"：找到一条相关轨迹之后，目标侧的 Agent 还必须提取仍然适用的流程、恢复当前的绑定值、剔除已经失效的源任务细节、验证新的最终状态。

也就是说，长轨迹记忆的流水线是两段的：检索决定哪段历史进入视野，复用决定这段历史如何转化为当前环境里的行动。检索必要，但不再充分。

1.3 为何"检索到"不等于"用得好"：实体绑定过期问题

一条成功的历史轨迹里混着两类性质完全不同的信息：

1. 程序性知识：工具调用顺序、决策规则、验证步骤——这些往往可跨任务迁移；
2. 绑定值（bindings）：具体的用户名、文件路径、记录 ID、日期、参数、当时的环境状态——这些是源任务的"快照"，换一个目标就全部过期。

问题在于二者在原始轨迹里是交织在一起的。当整条轨迹被塞进上下文，Agent 面对的诱惑是统计意义上的模仿：照着旧轨迹走最省事，于是旧的用户名、旧的路径、旧的日期被原样抄进新任务。论文给了一个精确的刻画——stale-binding 错误：动作、输出或工具参数中重复了与目标任务查询或目标侧观测相冲突的源任务专属值。轨迹越长、包含的源绑定越多，这种"照抄偏移"就越严重。这正是本文要处理的痛点：检索到了金子，连同金子一起递过去的还有渣滓，而模型分不清哪是哪。

二、论文定位和关联工作

2.1 记忆研究的三条谱系

把本文放进已有工作的坐标系里，可以分出三条主要脉络：

谱系一：检索导向的记忆系统。 RAG 确立了"检索—条件化生成"的标准范式（Lewis et al., 2020）；MemGPT、MemoryBank、HippoRAG、Mem0、A-MEM 等系统研究存储、索引、更新与上下文交付；Transformer-XL、Memorizing Transformers 让超长访问在架构上可行。但正如"Lost in the Middle"（Liu et al., 2024a）所揭示的，上下文更长不保证模型用到相关部分。这条线的评测问题止步于"访问"。

谱系二：经验记忆与轨迹蒸馏。 Reflexion 从失败中提炼反思，Voyager 沉淀技能库，ExpeL 从轨迹中抽取可复用经验与规则，Synapse 做"轨迹即范例"的提示，Agent Workflow Memory 把跨任务的稳定工作流蒸馏出来存档。这类方法已经意识到"原始轨迹不是最好的交付形式"，但论文指出它们留下了一个未解的问题：如何评估这些抽取物对"某个特定后续查询"的价值——蒸馏出的反思/技能是否有用，缺少一个把检索质量与复用质量分开的测量框架。

谱系三：长程 Agent 评测。 WebArena、WorkArena、AppWorld、AgentBench、τ-bench 等提供可交互、可验证的多步环境，但它们通常评测孤立执行，不评测"带着历史经验执行"。

2.2 本文的位置：查询条件化的复用

本文的独特站位是：冻结前三条线的所有变量，只动"检索之后、执行之前"的那一步。候选集、选中记录、模型、解码配置、工具预算全部锁死，唯一变化的是交付给执行 Agent 的经验表示方式——原始轨迹、通用摘要、还是目标绑定的 QCR 笔记。对齐方式对比如下：

一句话：ExpeL 们回答"该从轨迹里留什么”，本文回答"留下的东西到了新任务手里该怎么变形"。

三、问题定义

3.1 抽象问题：程序性知识与绑定值的分离

本文把"经验复用"提炼为一个干净的分离问题：历史经验中的"程序"可以迁移，而"值"必须重取。

打个比方：同事交给你一份他去年办离职手续的完整截图记录。流程（先找 HR 系统、再填表、最后找主管签字）今年大概率还有效；但截图里的工号、系统路径、截止日期全是去年的，照着填必错。人类会自动做"取其流程、弃其数值"的分离，而现有记忆系统把整份记录原样递给模型，指望模型自己分离——论文的实证结果表明它经常分不好。

形式化地：目标任务 $t$ 有查询 $q_t$ 和初始观测 $o_{t,0}$；冻结的验证轨迹库 $B$；固定检索器 $R$ 对所有对比方法返回同样的 top-5 候选 $Z_t$；一个复用机制 $\rho$ 写出支持对象 $r_t = \rho(Z_t, q_t, o_{t,0})$；执行 Agent 据 $(q_t, o_{t,0}, r_t)$ 生成新轨迹并接受目标环境自己的验证器裁决。评测只看目标侧结果——记忆的价值由"是否改善了当前查询的解决"来定义，而非源保真度。

3.2 目标绑定笔记：四字段设计

论文的实例化是"目标绑定笔记"（target-bound note），含四个字段：

1. 工作流不变量（workflow invariant）：目标任务仍然需要的动作模式；
2. 需在目标侧重新获取的绑定（bindings to re-obtain）：点名"这里有个用户名/路径/日期依赖"，但禁止把源值当答案给出；
3. 适用条件（applicability conditions）：包括何时应当拒绝复用；
4. 验证护栏（verification guardrail）：提交前必须复做的目标侧检查。

这个四字段是"最小实现选择"，不是宣称唯一最优的记忆模式——论文用它是为了让诊断干净：如果同样的检索记录下这一步有效，说明缺的操作是复用而非存储。

四、问题解法

4.1 四字段各自堵住哪种错误

逐个看这四个字段分别对应的失败模式：

工作流不变量只保留目标还需要的动作骨架，例如"检查当前对象 → 验证相关条件 → 执行修改 → 校验结果"。它把轨迹中的弯路、失败分支、无关观测全部丢弃，解决的是"长轨迹淹没当前目标"的注意力问题。

需重取绑定直接对冲 stale-binding 错误。源轨迹提到某个用户名、文件路径、账户、对象 ID，这些对解源任务有用，但对目标值只字未提。笔记的做法是点名依赖而不供给旧值——告诉执行 Agent"这一步需要当前环境里的真实 ID，去查"，而不是让旧 ID 躺在上下文里等着被照抄。这是整个设计里最反直觉也最关键的一笔：承认记忆里"有这个东西"，同时拒绝"给出这个东西的值"。

适用条件保留"当初上一个 Agent 为什么停顿、为什么换分支、为什么验证"的理由，并允许输出"此流程不适用于当前状态"——拒绝复用是一个合法结果，而不是逼迫 Agent 一定要把历史用上。

验证护栏把源任务中"确认完成"的那个检查带过来，要求在目标侧重新执行后再宣告完成，防止流程迁移了、验证没跟上。

4.2 改写器如何工作

QCR 写手的输入严格限定为三样：选中的那条历史轨迹、目标查询 $q_t$、初始目标观测 $o_{t,0}$。它不能私下调环境、不能换掉缓存的选择、不能看到验证器信息。附录 D 给出的提示词模板大意是：把历史标识符、路径、用户、日期、工具输出、环境状态一律视为"源侧证据而非目标答案"；不得推断隐藏目标状态、不得调工具、不得把历史绑定抄进目标；若源流程不适用，写出阻断复用的条件。

工程配置（附录 B）显示全套系统统一使用 DeepSeek-V4-Pro：源 rollout 与执行 Actor 用温度 0.2 随机解码（最大 4096 token），摘要写手、排序器、QCR 写手全部用温度 0 的确定性解码（最大 512/1024 token）。执行 Agent 收到的提示明确说明历史信息是建议性的，而非要求逐字重放动作。

4.3 冻结预算的公平对比设计

这套评测最讲究的地方是归因边界。所有条件共享：目标套件与初始状态、缓存的 top-5 检索结果、排序器选中的同一条轨迹、同一个模型、同一解码配置、同一工具预算、同一随机种子（每目标每条件 3 个种子匹配运行）。差异只剩一个：同一条被选中经验的表示与使用方式——原始交付（Full Trajectory）、仅源侧压缩（Generic Summary，在目标查询到来之前离线生成、长度预算与 QCR 对齐）、或目标绑定支持（QCR）。

成本核算同样精细：在线 token = 基础执行提示 + 交付的记忆 + 支持合成的输入输出 + 执行输出，QCR 的合成开销单独报告并计入在线总量，避免"只是把活儿挪到写手上"被当成免费收益。检索与排序在所有条件跑之前完成并缓存。这样，表里的任何差异都无法归因于检索或选源——这正是"把复用从检索里剥离出来单独测量"的全部意义。

4.4 一个类比对偶：程序代码 vs 硬编码常量

理解 QCR 最省力的类比来自软件工程：完整轨迹注入 ≈ 把上一版程序连同硬编码常量一起复制过来；QCR ≈ 代码与数据分离。好的工程师复用一个脚本时会参数化其中的硬编码路径，把"程序逻辑"和"环境相关的配置值"拆开——逻辑复用，值重新注入。QCR 做的就是对 Agent 经验的同类重构：

五、评估指标与实验证据

5.1 实验规模与协议

三个基准：WebArena（浏览器）、WorkArena（企业知识工作）、AppWorld（API 与数据库混合），交互模态与状态可观测性各不相同。记忆库为跨环境统一混合的 623 条验证轨迹（WebArena 228 / WorkArena 201 / AppWorld 194，由各环境原生检查器验收通过的源任务 rollout 构成，可含弯路与失败尝试）；每条源轨迹平均衍生 3.84 个目标变体，共 2,391 个目标实例，每个目标每条件跑 3 个种子。检索器为 BGE-M3 嵌入检索（top-5），排序用 DeepSeek-V4-Pro 对候选摘要重排后选 1 条。指标：验证成功率、里程碑完成率、API 调用数、在线 token 数；分层分析报告效用 $U = S_{\text{memory}} - S_{\text{no memory}}$。

5.2 主结果：更准还更省

Table 1（2,391 目标，Success/Milestone 为百分比，API 调用与在线 token 为均值）：

读表要点：

• 经验确实有用：两种记忆基线都胜过 No Memory，Generic Summary 比无记忆高 9.5 点，完整轨迹再高 3.7 点；
• QCR 平均 62.3%，比 Full Trajectory 高 10.7 点，且逐环境看优势一致：WebArena +10.9、WorkArena +10.8、AppWorld +10.4——效果不是被某一个"容易的"基准扛出来的；
• 相对 No Memory，QCR 在三个环境分别 +23.2 / +23.8 / +24.7 点；
• 代价同时下降：在线 token 9.4k 约为完整轨迹 18.4k 的一半（省 48.9%），API 调用 16.7 次还是所有条件中最少的。收益不来自"给执行者更多历史上下文"，恰恰来自给得更少但更对。

5.3 记忆供给充足吗：选择诊断（Figure 3 / 附录 E）

在谈"复用"之前得先排除"检索不行"的解释。数据说检索与选择已经足够好：

• 嵌入检索把配对轨迹（构造该目标所用的源轨迹）召回 top-5 的比例 95.6%，至少一条可复用轨迹 97.8%；但直接取 top-1 的配对准确率只有 78.9%；
• 对候选摘要重排后，最终配对准确率升到 91.7%、可复用记忆覆盖 94.8% 的目标，仅 5.2% 选中的记忆完全无关（重排分别带来 +12.8 / +12.4 点提升，配对 MRR 0.87）；
• 选择消融：从 top-5 随机选 → 端到端 Success 44.8%；直接用检索 top-1 → 56.1%；重排选择 → 62.3%；而"总能选中一条可复用记忆"的 oracle 是 64.1%——距 oracle 仅 1.8 点。

这组数字完成了一个重要的排除法：既然 94.8% 的目标都能拿到可复用记忆、选择质量距上限只差 1.8 点，而 Full Trajectory 只有约 51.6% 的平均 Success，主要损失必然发生在"相关记忆到达执行者之后"。这就是复用瓶颈存在的直接证据。

5.4 机制证据一：轨迹越长，直接注入越失效（Table 2）

按选中记忆的有效动作长度分层（Short 5–10 / Medium 11–20 / Long 21–35 / Very Long >35 步），报告组内相对 No Memory 的效用增益：

No Memory 的成功率从 Short 组的 55.2% 一路跌到 Very Long 组的 18.9%（越长的轨迹对应越难的任务），所以看组内增益才公平。结论清晰：完整轨迹注入的效用随长度陡降——从 +18.4 跌到 +2.9，只保住了短轨迹组效用的 15.8%；Generic Summary 保住 32.4%；QCR 也随长度衰减，但 Very Long 组仍保有 +13.2 点，保住短组的 60.3%。（论文诚实地注明：这是注册构造下的关联性结论，不是长度的因果估计，因为长度组同时隐含任务难度差异。）

5.5 机制证据二：绑定偏移是重灾区（Table 3 + 附录 C）

按源→目标的绑定改写强度分层（None 不改 / Small 改 1 个局部绑定 / Medium 改 2–3 个或 1 个核心约束 / Large 改 ≥4 个、或同时换目标实体与初始环境状态；目标数 623/602/588/578）：

这条曲线就是论文核心论点的实证形态：不换绑定时完整轨迹非常好用（+26.9，甚至略胜 QCR）；偏移一大就崩到 +2.2，仅保住无偏移时效用的 8.2%；QCR 在最大偏移下仍有 +20.1，保留 67.9%。注意 QCR 并没有让绑定偏移"消失"——它降低的是过期源值挤掉当前任务证据的速率。

错误分析（附录 C，大偏移层，2 名标注者 + 1 名裁决者，Cohen’s κ = 0.87，标注员检查源记录、目标观测与实际执行轨迹而非从成败倒推）：

这是全文最硬的一块机制证据：同一批目标上，直接注入轨迹的近半数目标出现照抄源值，而 QCR 把这个数字压掉约四分之三，把"正确重取当前值"的比例翻了倍以上。

六、效果优势的根源解释

为什么一页四字段笔记能同时赢下"更准"和"更省"？把证据串成因果链：

Full Trajectory 的失效链条：完整轨迹注入 → 大量过期绑定值随轨迹进入上下文 → 执行模型在统计上倾向于模仿最显眼的模式（旧的参数就在眼前，照抄最省力；与"Lost in the Middle"现象一致，模型并不总能可靠地用对长上下文的相关部分）→ 大偏移下 46.9% 的目标出现 stale-binding 错误，效用仅剩 +2.2。同时 18.4k token 的记忆本身挤占了注意力，当前目标被"旧观测与无关分支"淹没——更长并不更清楚，反而是噪音源。

QCR 的增益链条：改写器显式完成"程序知识 / 绑定值"的分离 → 工作流不变量只留骨架（注意力聚焦在"怎么做"上）→ “需重取绑定"字段把每个值依赖变成一条显式指令（“此处需当前环境的真实 ID”），把’知道有这个依赖’与’提供这个值’解耦 → 正确重绑定率从 31.7% 升至 77.8%；适用条件与验证护栏则兜住"不该用时用了"与"用完没验"两类残余错误 → 笔记短（9.4k 在线 token，约为完整轨迹的 51%），注意力不再被稀释，API 调用也最少（16.7 次）——探索减少但不省必要的检查。

还有一个容易忽略的对比：Generic Summary 比 No Memory 只高 9.5 点、大偏移下仅 +5.3。这说明收益不是"压缩"本身带来的——同样短的交付，如果只在源侧做通用摘要（目标查询到来之前就写好），过期绑定虽被稀释但流程与值仍未分离。起作用的是"以目标查询为条件"这个动作：知道目标任务是谁、缺什么，才能写出"哪些绑定必须重取”。短是必要条件，目标条件化才是充分条件。

论文自己对边界也很克制：结果不意味着"所有任务都该省 token"（安全敏感任务可能需要更多检查）；没测量不可逆副作用或策略违规；也没隔离四字段各自的贡献。QCR 是一个诊断性干预——它证明了"缺的那一步是复用"，而非宣称四字段是 universally preferred 的记忆格式。

七、必要知识反推

假设要重新发明这项工作，需要哪些前置知识？

领域层（Agent 记忆与评测）：熟悉 MemGPT/Mem0/HippoRAG 一系记忆系统的存储-索引-检索分工，知道 LongBench/LoCoMo/LongMemEval 测的是"访问"而非"使用"；熟悉 WebArena/WorkArena/AppWorld 提供的可验证多步环境及其 milestone 检查器；知道"Lost in the Middle"等长上下文失效证据。

方法论层（实验设计，本文最出彩处）：

• 瓶颈归因的排除法：先证明选择侧距 oracle 仅 1.8 点、覆盖 94.8%，把失败"逼"到复用环节——这是"控制变量到归因边界"的典范；
• 冻结式公平对比：缓存检索结果与选中记录，让所有条件吃同一份输入，差异只剩表示方式；成本核算明确到"在线 token 五个组成部分"，合成开销单独记账防止重复计费或漏记；
• 构造式分层：不满足于自然分布，而是按绑定改写强度（None/Small/Medium/Large）系统性构造目标变体，让"偏移敏感度"从混淆变量变成可控自变量；标注协议（双标注+裁决、κ=0.87、按执行轨迹而非成败倒推）保证了 stale-binding 这一核心指标的可靠性。

工程层：程序分析与数据流思想——把轨迹看作程序，识别其中的"自由变量"（绑定）与"纯逻辑"（工作流）；提示工程上用"把历史值一律视为源侧证据而非目标答案"的强约束实现软性的污点分析（taint tracking）；统一的审计账本（附录 G）让每次运行的候选集、选中记录、token 分解、绑定标签可追溯。

融合节点：这篇论文的本质是把软件工程里"代码与数据分离"的老原则引入了 Agent 记忆——参数化配置、前置条件检查、断言验证，这些软件工程的同学看一眼就懂的东西，被精准地翻译成了四字段笔记。跨领域转译而非发明全新理论，恰恰是这类工作优雅的地方。

八、通用性灵感

灵感一：程序性知识与绑定值分离，是一切"经验复用"的核心不变量。 论文证据：分层实验中大偏移下 Full Trajectory 效用仅剩 +2.2（8.2% 保留率），QCR 保留 67.9%；stale-binding 错误 46.9% → 10.9%。 推广场景：任何"参考历史产出"的场景都适用——代码 Agent 复用旧 patch 时分离"修复策略"与"旧的文件路径/行号/版本号"；RAG 系统引用旧报告时分离"论证结构"与"过期数字"。判断标准很简单：这段经验里哪些部分换个环境必然失效？把它们点名并禁抄。

灵感二：记忆系统应该"存全量、交紧凑"——存储保真与交付表示是两个独立决策。 论文证据：库中存完整轨迹（含弯路，供审计与溯源），交付给 Actor 的是目标绑定短笔记；token 减半的同时成功率反升 10.7 点。论文讨论部分明确主张"a store may preserve a complete record for evidence and provenance, while the acting prompt should contain a compact, target-bound account"。 推广场景：个人知识库、企业 wiki、Agent 长期记忆——不必为了上下文预算而删库，该做的是在"取用瞬间"按当前任务改写交付物。检索系统和交付系统应该解耦设计。

灵感三：给系统显式的"拒绝复用权"。 论文证据：适用条件字段"make non-reuse a valid outcome"——当目标状态违反源前置条件时，合法输出是"此流程不适用"，而非硬着头皮重放历史。 推广场景：推荐系统（允许说"无相似案例"）、RAG（允许说"检索结果不可信"）、few-shot 示例选择（允许"无合适示例"）。很多幻觉与错误移植源于系统被隐式要求必须用上手里的信息；把拒绝写进输出空间，是廉价而有效的安全阀。

灵感四：验证护栏是复用的安全网——流程可以抄，验证必须重做。 论文证据：第四字段强制"在目标侧重新执行源任务中确认完成的那个检查"再宣告完成；QCR 在 API 调用最少（16.7 次）的同时成功率最高，说明省的是无效探索、没省必要检查。 推广场景：自动化运维复用历史处置方案（方案可参考、健康检查必须重跑）、代码生成复用旧实现（逻辑可借鉴、测试必须重新执行）。复用的成本下限由"验证不可省"划定。

灵感五：评测要测量"转化率"而非"覆盖率"。 论文证据：选择诊断显示 94.8% 的目标可获得可复用记忆、距 oracle 仅 1.8 点，而直接注入只兑现了约一半的潜在收益——供给充足、转化亏损。 推广场景：评估任何中间产物（检索结果、蒸馏知识、缓存）时，都应区分"拿到好资源的比例"与"把好资源变成好结果的比例"。前者达标而后者不达标，说明该投入的方向是转化环节，而非继续堆检索精度。

结语

这篇论文做了一件"小而准"的事：在所有人都在卷记忆的存、取、索引时，它用一套冻结到牙齿的对照实验证明——长轨迹记忆的下一个瓶颈在检索之后，并把那个环节形式化为"查询条件化复用"，再用一页刻意简单的四字段笔记把它做出来。62.3% 的平均成功率、减半的 token、46.9% → 10.9% 的过期绑定错误率，三个数字分别对应"更准、更省、机制对"。它不宣称发明了终极记忆格式，而是给后来者立了一个清晰的规矩：报告你的系统时，分清检索到了什么、选中了什么、交付了什么、验证了什么。

本文基于论文全文逐页阅读撰写（含附录 A–G 的全部表格与协议细节）。