记忆别急着写死：JitMem 把"整理经验"推迟到用它的那一刻

你有没有想过一个反直觉的问题：给智能体加记忆，主流做法都是"任务一做完就写总结"——把这次的经历提炼成一条经验、一个技能、一段反思，存进库里。看起来天经地义对吧？

但这篇论文问了一个让我愣了一下的问题：你怎么知道未来哪个任务会用到这段经历里的哪部分信息？

写总结的时候，未来任务根本还不存在。你只能赌——赌你提炼的那一条经验恰好是以后用得上的。赌错了，丢掉的信息就永远丢了。

核心摘要：Salesforce AI Research 的这篇论文提出了 Just-in-Time Memory（JitMem），思路一句话讲完——记忆库里只存原始轨迹，不做任何蒸馏；等真正要用的时候，由一个 curator 看着当前任务，现场把检索到的轨迹整理成一份"为这次任务量身定制"的简报。这个看似简单的时机转移带来两个红利：信息不再过早丢弃，而且 curator 的训练奖励从"很多任务之后才知道有没有用"的长程信用分配，塌缩成了"payload 当场被消费、当场拿奖励"的单步问题。结果相当能打：ALFWorld、WebShop、τ²-bench 上分别比最强 baseline 高 16.2、16.3、3.9 个成功率点。更有意思的是，不训练的 curator 就已经打平甚至超过 RL 训练的写时记忆方法了——说明增益的大头来自"读时蒸馏"这个设计本身，而不是训练技巧。

论文信息

• 标题：Just-in-Time Memory: Learning to Curate Task-Adaptive Memory for LLM Agents
• 作者：Yefan Zhou、Yang Li、Zeyu Leo Liu、Semih Yavuz、Shafiq Joty（* 共同一作）
• 机构：Salesforce AI Research
• 链接：https://arxiv.org/abs/2609.27334 （arXiv:2609.27334v1，2026 年 9 月 23 日）

🎯 问题：写时蒸馏的两个结构性缺陷

先交代一下背景。智能体记忆（agentic memory）这条线最近很热：Reflexion 存语言反思，Voyager 存可执行技能，ReasoningBank 存推理策略，SkillOS 甚至用 GRPO 训练一个"写记忆"的策略。花样很多，但都有一个共同的骨架——任务结束时把轨迹蒸馏成一个固定的 artifact，之后靠相似度检索复用。

作者把这个范式拆开看，发现它有两个绕不过去的代价。

信息丢失是提前且不可逆的。 蒸馏发生在写入时，此刻你不知道未来的查询长什么样，只能按当前的判断扔掉细节。之后某个任务恰好需要被扔掉的那个细节？对不起，找不回来了。

一个固定 artifact 要服务无数个未来查询。 同一段轨迹对不同任务可能意味着完全不同的教训。论文里举的例子很到位：一段" household 交互"轨迹，对任务 A 来说价值在于状态转换模式（比如怎么加热、冷却物体），对任务 B 来说价值在于物体摆放策略。轨迹里不止藏着一条经验，藏着很多条——哪条重要取决于下游任务，而下游任务在写入时压根不知道。

顺着这个想下去，答案几乎是必然的：把蒸馏推迟到读取的那一刻。任务来了，知道了，再看着任务去整理检索到的原始轨迹。作者还顺手引了认知科学的观点做背书——人类的情景记忆本来就是重构式的（reconstructive），而不是录像回放式的，检索过程会被当前目标和线索塑造。这个说法我挺买账，虽然类比归类比，真正的说服力还是靠实验。

🏗️ 方法：四件套 + 一个即时奖励的 GRPO

图1：JitMem 系统总览。（a）推理管线：当前任务 \(x_t\) 到来后，retriever 从记忆库 \(\mathcal{M}_t\) 取回原始轨迹，curator \(\pi_\phi\) 以任务为条件把它们蒸馏成 task-adaptive payload 注入 executor 的上下文；执行完由 executor 兼任 judge 判定成败，成功轨迹回写记忆库。（b）训练管线：每步从固定训练库采样任务并检索轨迹，curator 生成一组候选 payload，冻结的 executor 逐个尝试并返回当场任务奖励，用 GRPO 更新 curator。

整个系统四个组件，只有 curator 是可训练的：

记忆库（Memory Bank）：存完整、未抽象的原始轨迹——任务描述加整个观测-动作交错序列。不做总结、不做反思、不做技能抽象。入库有个质量门：executor 自己当 LLM-as-judge，判成功才入库，保证库里都是正例。

检索器（Retriever）：BM25，只在任务描述上算（不算轨迹内容），取 top-\(k\)（主实验 \(k=3\)）。不训练，刻意保持轻量。说实话这里选 BM25 有点保守，作者自己也承认它可能成为记忆库变大后的瓶颈。

记忆策展器（Curator）：输入是"当前任务 + k 条原始轨迹"，输出是一份紧凑的自然语言简报 \(p_t = \pi_\phi(x_t, \hat{\boldsymbol{\xi}}_t)\)：哪些过往经历最相关、相似任务上什么策略 work 过、对当前任务的具体建议。关键点在于 \(p_t\) 以 \(x_t\) 为条件——同一条被检索到的轨迹，对不同任务产出不同的蒸馏结果。这就是 task-adaptive 的全部含义。

执行器（Executor）：冻结的预训练 LLM，全程不更新。payload 前置拼进 executor 的 prompt。冻结 executor 是个深思熟虑的工程决定：一个训练好的 curator 可以服务多个 executor 不用重训，记忆模块也能被隔离评估。

训练用 GRPO。每个训练任务，curator 生成 \(G=8\) 个候选 payload，冻结 executor 挨个拿着去尝试任务，拿回基准的原生奖励 \(r_t^{(i)}\)（ALFWorld 和 τ²-bench 是二元成功，WebShop 是连续分数）。组内优势 \(\hat{A}_i = r_t^{(i)} - \text{mean}_j\, r_t^{(j)}\)（省略标准差归一化），更新目标：

这个设计最值钱的地方在于：奖励是 payload 的当场函数，中间没有任何延迟步骤。curator 的动作和它的奖励之间时间差为零。

对比一下 SkillOS（最接近的前作）：它训练的是写时 curator，一次存储决策要等未来某个任务检索到这条记忆才能被打分，可能隔了很多个任务。为了造出学习信号，SkillOS 不得不把相关任务分组（grouping），人为制造时序依赖。而 JitMem 完全不需要这套脚手架。作者还特意引用 SkillOS 自己的消融——grouping 是它性能的主要来源之一——来说明这套脚手架有多重。

训练细节上有个小坑值得讲：为了让训练奖励只反映 payload 质量（而不是"恰好检索到什么"的随机性），训练用的是固定记忆库——先让裸 executor 在训练集上跑一遍，用真值标签留下成功轨迹，之后整个训练过程这个库不动。这引入了轻微的 train/test 分布漂移（测试时库里是 curator 增强的轨迹），后面消融里用 staged bank refresh 量化了这个 gap。

📊 实验：三个基准，全面压制

实验在 ALFWorld（文本具身控制，140 个测试任务）、WebShop（网购，500 个测试实例）、τ²-bench（airline/retail/telecom 三域的对话式工具使用）上做。三个冻结 executor：Qwen3-8B、Gemini-2.5-Pro、GPT-5.4。baseline 包括无记忆、ReasoningBank、MemP、SkillOS（含各自的 -base 免训练变体和 -gpt/-gemini 强模型 curator 变体）。

表1：ALFWorld / WebShop 主结果（SR，三个 executor）

有几个数我得停下来点评一下。

免训练的 JitMem-base 就已经很离谱了。 GPT-5.4 做 executor 时，JitMem-base 用 Qwen3-8B 当 curator（79.3）居然超过了用 GPT-5.4 自己当 curator 的 ReasoningBank（77.9）和 SkillOS-gpt（70.0）。弱 curator + 读时蒸馏，打赢强 curator + 写时蒸馏。这基本排除了"增益来自 curator 模型能力强"的解释，把功劳明确归到设计范式上。

WebShop 上的提升幅度大到需要警惕。 32.8 vs 16.5，翻倍。说实话看到这个数我第一反应是检查 baseline 是不是被压得太低——WebShop 上 Qwen3-8B 无记忆只有 9.8 SR，这个执行器本身就弱，记忆方法的相对提升空间自然大。作者在附录里倒是做了个诚实的交代（Table 6）：他们复现的 no-memory baseline 全部等于或低于 SkillOS 原论文报告值，保证增益是保守测量的。这个态度加分。

τ²-bench 上（表2，GPT-5.4 做 executor，只测免训练变体），JitMem-gpt 的 micro 平均 75.6，比最强 baseline ReasoningBank-gpt 的 71.7 高 3.9 个点。分域看很有意思：增益几乎全部来自 Telecom（72.6 vs 61.6，高 11.0），Airline 和 Retail 上所有记忆方法相对无记忆都没有超出方差的提升。作者的解释是：读时蒸馏在"需要综合流程性指导"的任务上最值钱，简单事实检索类任务帮不上什么。这个观察挺诚实的，没有硬吹全面碾压。

迁移能力是我最看重的一个实验。 curator 用 Qwen3-8B executor 训一次，直接拿去服务 GPT-5.4 executor，ALFWorld 上 86.7——距离"直接用 GPT-5.4 executor 训练"的 88.1 只差 1.4 个点。说明 curator 学到的是通用的蒸馏策略，而不是 executor 特定的 pattern。工程意义很实际：训一次，到处用。

效率数字也很能打。 GPT-5.4 executor 下，JitMem 每任务输入 token 9.8K，而 ReasoningBank 19.7K、SkillOS-base 22.4K——相对写时方法输入减少 50.3%–56.3%，执行步数减少 28.4%–31.4%（11.6 步 vs 无记忆的 17.8 步）。等等，读时现场蒸馏不该更贵吗？仔细想想其实不矛盾：写时方法塞给 executor 的是一堆预蒸馏的 artifact 原文，而 JitMem 给的是一份高度浓缩、针对当前任务的简报。信息密度高，executor 反而少走弯路。多花的代价是 curator 那一次额外 LLM 调用，论文 limitation 里也承认了。

🔬 消融：三个设计选择各自独立贡献

图2（a）：免训练 JitMem-base 的消融。依次去掉任务自适应条件、成功轨迹过滤、原始轨迹存储。ALFWorld（上）和 WebShop（下）× 三个 executor。

图2（b）：RL 训练版 JitMem 的消融，额外包含"去掉检索轨迹"这一项。最右侧柱子是完整方法。

三个核心设计挨个拆掉看：

去掉任务条件（curator 退化成 query 无关的摘要器）：免训练版掉 3.1（ALFWorld）/ 4.6（WebShop），训练后差距拉大到 11.4 / 10.4。这说明 RL 学的恰恰是怎么利用任务信号，而不是单纯把轨迹压得更短。

去掉成功轨迹过滤（改成全量存储 + 标注对错，即 ReasoningBank/SkillOS 的做法）：掉 1.5–3.4 个点。即使有对错标注，curator 也没法完全压住失败轨迹带来的噪声。

去掉原始轨迹（写入时就做 ReasoningBank 式蒸馏，只存蒸馏结果）：ALFWorld 掉 1.7–2.9，WebShop 掉 6.8–8.2。写入时丢掉的信息，读时 curator 再强也救不回来。

还有一个针对 RL 的检验我很喜欢：强制检索器返回空集。如果训练后的 curator 只是学会了从参数知识里编 hint，没有轨迹也该行；结果 SR 掉最多 14.8/15.2，退化到甚至低于免训练版。证明 RL 学到的确实是"蒸馏检索到的经验"这门手艺。

训练超参：Qwen3-8B 初始化（non-thinking）、GRPO 100 步、lr \(1\times10^{-6}\)、batch 32、group size 8、KL 系数 \(10^{-3}\)。单次训练 ALFWorld 约 21 小时、WebShop 约 27 小时，8×H200。检索数 \(k\) 从 3 到 5 的消融显示 SR 变化不到 2 个点，不敏感。

💡 我的判断

这篇论文最值钱的地方不是某个技巧，而是把一个被默认接受的设计假设——"记忆要在写入时整理好"——拽出来重新审视了一遍。读时蒸馏这个想法，坦白说并不是完全没有先例：并发的 MemHarness 也在读时做 curation，SkillTTA 在测试时合成任务条件技能。但 JitMem 的差异点很清晰：curator 和 executor 解耦，所以训练好的 curator 能跨 executor 迁移；而 MemHarness 把两者纠缠在一个模型里，换个 executor 就得重训。加上"原始轨迹无损存储 + 即时奖励训练"这个闭环，整个故事的完整度是这条线上目前最好的之一。

问题也得说。其一，检索器是 BM25，记忆库一大、任务分布一杂，这很可能成为第一个瓶颈——整套系统的前提是"检索到的轨迹大致相关"，检索垮了 curator 再强也白搭。其二，payload 格式是每个基准手工设计的 prompt，换环境要重新写，离"即插即用"还有距离。其三，每个任务多一次 curator 调用，延迟和成本都涨了，论文没给这部分的墙钟开销分析。其四，WebShop 上 Qwen3-8B 的绝对数字偏低，翻倍式的提升有多少能迁移到强 executor 场景，从表里看（50.5 vs 41.3）依然可观但没那么夸张了。

工程启发倒是立竿见影的：如果你在给自己的 agent 系统做记忆模块，先别急着设计蒸馏模板，把原始轨迹留下来。蒸馏模板这种东西，写入时你怎么设计都是猜；把蒸馏推迟到检索之后、以当前任务为条件，哪怕只是一个免训练的 prompt 版 curator，收益可能就已经超过你精心打磨的写时 artifact 了。这篇论文用 JitMem-base 的数字把这件事证明得很干净。

还有一个更本质的问题这篇没碰：当任务流是开放的、分布持续漂移的，库里那些"成功轨迹"本身的时效性怎么管？记忆会过期的。这可能是下一个值得被拽出来审视的默认假设。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我