记忆系统里那个没人叫它 bug 的 bug
绝大多数智能体记忆系统共享同一个设计：一个任务结束时，系统把整段轨迹蒸馏成一条固定形态的记忆条目——一段反思、一个工作流、一项技能或一条推理策略，留待日后按相似度检索。问题在于，这条压缩发生在写入的时刻，而那时还没人知道下一个任务会需要什么。你被迫在「决定什么值得记」之前，就先替未来做了选择，并不可逆地扔掉了其余信息。
9 月 23 日，arXiv 2609.27334 提出 Just-in-Time Memory（JitMem），把压缩的时机整个翻过来：保留原始轨迹，写入时什么都不策展；等读的时刻、当前任务就摆在眼前时，再由一个 curator 针对这个具体需求，合成一小包紧凑、只服务于该任务的记忆载荷。同一份信息，决定的时刻不同，结论就不同。
读时策展，而不是写时策展
JitMem 的做法很直接：原始轨迹全留，检索到轨迹与新任务后，curator 合成仅适配当下任务的载荷。因为这个载荷在同一任务上就被消费掉，curator 可以直接用即时的任务成败来训练，不必等一个可能很多轮之后才出现的远期奖励信号，也不用手工把相关任务归成一组。
更反直觉的结果是：即便用未训练的 curator，它已经能打平甚至超过已有的写时基线。这意味着收益主要不是来自某个更聪明的学习组件，而是来自「把决策推后」这件事本身。训练 curator 之后，增益进一步叠加。
数字：三个环境的一致提升
在 ALFWorld、WebShop 与 tau-squared bench 上，JitMem 相较无记忆智能体，以及启发式与学习式的写时记忆方法，成功率分别提升 16.2、16.3 与 3.9 个百分点；其中 tau-squared 的增益相对小，作者也如实标注了这一点。值得强调的是，头部基线对比里已经包含「训练过的写时 curator」，JitMem 仍能稳定占优。
这篇论文还特意点了同一周在 GitHub 登上趋势榜的 Hindsight——后者走向写时结构化，把记忆激进地归进带类型的桶里。两条路线其实可以都对，因为它们优化的是不同的成本：写时结构化查询便宜、却永远有损；读时策展全留、却要为每次查询付费。该选哪条，取决于你的存储账单和推理账单谁更让你头疼，而眼下几乎没人是在 consciously 地做这个选择。
增量认知：策展时机，是记忆的一阶变量
把 JitMem 放进近期记忆研究的脉络里看，它的增量不在「又一种记忆模块」，而在把「何时策展」立成了一阶变量。此前的 MemCalib 关心的是记忆被用时的校准（过度或不足使用），长程记忆压缩关心的是留什么、怎么压；JitMem 补的是更上游的一步——别在还不知道要答什么时，就替未来决定记什么。
对工程落地而言，这给出一条可操作的提醒：如果你的智能体在跨任务时总「记得不对」或「忘得离谱」，未必是检索算法不行，也可能是写入时丢错了东西。与其反复调 embedding，不如先问问——这条记忆，是在任务结束那一刻被蒸馏的，还是留到用时才被挑出来的？
落地提醒：别先急着加 embedding 维度
多数团队发现智能体跨任务「记错」时，本能反应是换更好的检索模型、加更多 embedding 维度、调 top-k。JitMem 的实验给出反向提示：问题可能不在检索端，而在写入端——你在任务结束那一刻就把信息压成固定形态，后续检索再聪明也还原不出当时丢掉的上下文。
更务实的做法是分两层：先把原始轨迹留存一段时间（成本主要是存储），再观察哪些任务真正需要被策展；等出现高频复用模式，再决定哪些该固化成结构化记忆。把「记录」与「策展」拆成两件可独立迭代的事，比一次性追求完整记忆模块更稳，也更容易在线上小步验证。