检索到了历史轨迹，Agent 就真能照着做对吗？QCR 用一半 Token 提升 10.7 分
Beyond Retrieval: Query-Conditioned Reuse of Long-Horizon Agent Trajectories
构建一个具备长期记忆的智能体（Agent）系统时，业界往往遵循一套自然的直觉：只要检索模块（Retrieval）足够强，能从历史经验库里捞出最相关的过往成功记录，再把这段轨迹塞进模型的上下文窗口（Context Window），Agent 就能顺理成章地“参考并完成”眼前的新任务。
ArXiv URL：https://arxiv.org/abs/2608.12847v1
来自西安交通大学（Xi’an Jiaotong University）等机构的研究人员在一项最新工作中指出了这种直觉的致命盲区：检索成功只是第一步，检索之后的“重用”（Reuse）才是长流程 Agent 记忆系统的真正瓶颈。在复杂交互环境中，一条过去成功的轨迹哪怕与当前任务在流程上完全一致，也必然携带着过时的旧参数——特定的人名、旧的订单编号、过去的日期或早已失效的环境状态。如果直接把长轨迹一股脑塞进上下文，Agent 不仅会浪费大量 Token，还极其容易被旧数据带偏，甚至直接复读失效的操作。
这项研究提出了名为 QCR（Query-Conditioned Reuse，查询条件化重用）的范式，并搭建了严格控制变量的评测框架。在涵盖 WebArena、WorkArena 和 AppWorld 三大主流环境的 2,391 个长流程任务实例评测中，QCR 在消耗在线 Token 减少 48.9% 的同时，端到端任务成功率达到了 62.3%，反超直接注入完整轨迹（Full Trajectory）整整 10.7 个百分点。
从事实检索到流程重用：记忆瓶颈在右移
为什么过去的记忆系统很少强调“重用”的独立性？根本原因在于短记忆与长轨迹的本质差异。
当记忆库中存储的是短事实或局部规则时，检索和重用几乎是等价的。例如用户问“上次讨论的会议密码是什么”，检索模块只要命中包含密码的那条记录，下游模型直接读取并作答即可。这里的检索质量就是记忆效用（Memory Utility）的完美代理指标。
然而，一旦进入浏览器自动化、系统 API 编排或复杂数据库交互等长流程（Long-Horizon）场景，问题结构就彻底变了。一条长达数十步的真实轨迹，往往交织着多步骤的工具调用链条、分支判断、重试探索，以及只属于那次特定运行的局部参数。如果将记忆项按长度递增排列，系统的核心痛点会一路从前置的“保留与检索”向后转移至“抽取、重新绑定与执行”。
作者将这种转变定义为设计假设的核心：长轨迹虽然能帮智能体省去大量的试错与盲目探索，但它在目标任务中的价值完全取决于智能体能否成功实现“目标绑定”（Target-Bound Reuse）。如果只是机械地将原始长历史呈现给模型，过时的实体、参数假设和杂乱的中间步骤会反客为主，把当前任务的目标彻底掩埋。
拆解后检索阶段：QCR 的轻量级四要素
为了科学地验证“重用瓶颈”这一假说，研究团队没有选择去堆砌复杂的图神经网络或重型外部知识库，而是设计了一种极简的结构化支持便签——QCR。
在 QCR 的流程中，离线库冻结了 623 条来自 WebArena、WorkArena 和 AppWorld 的已验证成功轨迹。当目标任务到来时，系统固定检索出 Top-5 候选记录，并利用轻量级重排器（Ranker）挑选出最合适的一条。随后，QCR 会立足于目标任务的实际 Query 与当前初始状态，从选出的源轨迹中提炼出一份精炼的支撑对象，其严格限制包含以下四项内容：
-
流程不变量（Workflow Invariant）：保留跨任务依旧通用的抽象操作步骤（例如“先检索过滤、再校验权限、最后批量修改”）。
-
待重新绑定的参数（Bindings to Re-obtain）：明确列出哪些实体、路径、标识符是属于旧任务的，Agent 必须通过当前环境的工具调用重新获取新值，禁止抄袭。
-
适用条件（Applicability Conditions）：显式声明当前流程在何种环境下有效，甚至包含何时应果断放弃重用的判断逻辑。
-
验证护栏（Verification Guardrail）：规定在最终交付前必须执行的状态检查，确保目标状态达到验证器要求。
这份便签的长度被严格压缩，并且绝对不泄露目标任务的真实答案或评测器内部信息。它唯一的作用就是剥离旧环境的陈旧数据，将经验提纯为一份“执行指南”。
控制变量实验：用一半 Token 换来更高的成功率
评测协议的严密性是该论文的一大亮点。为了排除干扰，研究人员锁定了所有对比方法的上游与下游：全轨迹输入（Full Trajectory）、无状态的通用摘要（Generic Summary）以及 QCR，三者接收到的候选集完全一致，由排序器挑选出的源轨迹也完全一致；同时，后端的模型（均采用 DeepSeek-V4-Pro）、解码参数、环境初始状态以及调用工具的预算全部相同。唯一的区别，仅仅在于传递给 Acting Agent 的经验呈现形式。
在 2,391 个由真实场景改写、具备不同程度参数漂移的实例评测中，各项指标展现出极为显著的分化：
-
无记忆基线（No Memory）：智能体完全自主探索，平均成功率仅为 38.6%。
-
通用摘要（Generic Summary）：离线预先生成的摘要虽省 Token，但缺少针对当前 Query 的解耦指导，平均成功率来到 48.1%。
-
完整轨迹直接注入（Full Trajectory）：将挑出的成功长轨迹完整贴入上下文，平均成功率达到 51.6%，相较无记忆提升了 13.0 个百分点，但这需要消耗平均 18.4k 的在线 Token。
-
QCR 方案：平均成功率飙升至 62.3%，在完整轨迹的基础上直接拔高了 10.7 个百分点；与无记忆相比提升了 23.7 个百分点。
更具说服力的是资源开销对比。QCR 在完成任务时所需的工具 API 调用次数是所有方案中最少的，其最终产生的在线 Token（包含生成支持便签本身的开销在内）平均仅为 9.4k，相比直接注入完整轨迹节省了 48.9% 的计算开销。
无论是在注重网页 DOM 交互的 WebArena（成功率领先 10.9 点）、偏向企业服务工单的 WorkArena（领先 10.8 点），还是多 API 调用的 AppWorld（领先 10.4 点），QCR 均展现出毫无争议的全面压制。这有力地反驳了“喂给大模型的历史越详尽越好”的粗暴假设——给长上下文灌入过多混杂着失效状态的细节，对模型而言实际上是一种严重的干扰噪声。
为什么直接注入容易失效？两大压力测试揭示根因
实验进一步拆解了检索阶段的内部表现。虽然基础 Embedding 检索器将正确轨迹排进 Top-5 的召回率高达 95.6%，但其 Top-1 的命中率只有 78.9%。通过对 Top-5 候选摘要进行快速重排（Summary Reranking），系统为 94.8% 的目标任务挑中了可重用的经验轨迹，成功率与理论上的全知选择器（Oracle Selector）差距仅有 1.8 个百分点。这意味着检索层面的问题已基本被解决，后续表现的崩塌只能归咎于重用阶段。
针对后续的重用表现，研究团队进行了两个维度的切片分析：
1. 轨迹长度的敏感性分析
任务越长，原始轨迹包含的信息量越大。实验将源轨迹按有效动作步数划分为 Short（5–10 步）、Medium（11–20 步）、Long（21–35 步）以及 Very Long（>35 步）四组。在 Very Long 组中，任务本身的基线成功率已跌至 18.9%。此时直接塞入 Full Trajectory，为模型带来的成功率增益从短轨迹时的 17.5 点断崖式下跌至 6.4 点；而 QCR 在超长任务场景下依然能稳稳输出 19.3 点的净收益。这证明当上下文长度增加、无关分支堆叠时，原始轨迹所附带的认知负荷会迅速抵消其参考价值。
2. 参数绑定漂移（Binding Shift）的冲击
这是检验智能体是否盲目抄袭的核心实验。研究人员在构建评测集时，有意识地调整了目标任务相对于源任务的重写幅度：从小规模修改一个局部参数，到重写多个核心变量，乃至彻底替换操作实体与初始环境状态。
数据表明，当目标与历史完全无偏差（No Rewrite）时，直接回放完整轨迹能够取得显著增益；但一旦发生中重度参数漂移，完整轨迹带来的帮助立刻出现滑坡。很多失败案例表明，模型在面对冗长的历史轨迹时，会不自觉地把前次交互中的用户名、旧文件路径或过期 ID 复制到当前调用中，导致环境判定报错。相反，QCR 在便签中明确标定了“待重新绑定的变量”，强迫 Agent 自行去目标环境中获取最新值，从而在剧烈的环境与参数漂移下依然保住了绝大部分效用增益。
重新定义 Agent 记忆系统的分工
这项工作最重要的启示，在于从根本上修正了长轨迹记忆系统的工程架构路线：
-
存储层与执行层必须解耦：在后端向量库或轨迹池中，系统应当尽可能完整地保留原始交互、环境反馈和工具调用链，以满足溯源、审计与全面分析的需求；
-
但在线交互层严禁原样搬运：当把历史提供给负责行动的 Acting Agent 时，系统必须经历一道“以当前目标为约束”的精炼转换，把通用的工作流抽象出来，并把失效的局部绑定剔除掉。
将检索完成视为记忆系统的终点，无异于默认大模型拥有完美的抗噪与实体对齐能力。QCR 证明，即便不更换底层基座模型，仅仅在检索与行动之间插入一层极轻量的“目标重用转化”，就能让历史轨迹在发挥指导价值的同时，彻底免除死记硬背的副作用。对于所有正在构建复杂自动化流程、长任务助理的开发者而言，如何在后检索阶段帮助 Agent 辨别“哪些流程该学、哪些旧值该扔”，将是下一阶段必须攻克的核心命题。