10 月 9 日提交到 arXiv 的 T²Mem（论文标题 Test-Time Memory Construction，东北大学联合清华、阿里巴巴，编号 2610.13348，代码在 OpenBMB/T2Mem），把长期记忆工程里一个大家心知肚明的痛点摆到了台面上：现有记忆系统几乎都在离线预建记忆库，而这件事的成本结构从根上就是拧巴的。
现有流程大致是这样：历史对话进来，模型被反复调用去提取、总结、合并、去重，生成一份与查询无关的记忆表示；之后每个查询来了，从库里检索几条塞给模型。论文指出这有两个内生矛盾。
两个矛盾，一份实测证据
成本错位：因为无法预知用户将来会问什么，预处理只能宁滥勿缺——每段对话都要过一遍模型，新对话进来还得更新旧条目、解决冲突。论文引用的研究直接指出，这种构建与维护开销已经拖累了记忆系统的实际部署与扩展。
供需错配：预构建的记忆是通用的，查询却是特定的。论文里的实测证据很具体：离线方案 LightMem 在 LongMemEval 多数类别上表现不差，但在「单助手」类问题上只拿到 10 到 25 分（满分 100）。同一套库，有的题型 90 分，有的题型 10 分，忽高忽低。离线压缩时丢掉的细节，恰好是某类问题的命门。
把构建推迟到查询时刻
论文其实也提到已有类似工作（LazyMem），做法是先一次性检索一批候选事实，再现场组装。问题在于初始检索定生死——起始那一轮没检回来的证据，后面构建过程永远见不着，而真正需要深度构建的多跳与时序问题，恰恰是初始检索最容易漏的。
T²Mem 的转变是让检索被推理牵着走。离线阶段只做一件事：建索引，不建库。每段会话被抽成一张轻量元数据卡片，含关键事件、事实、实体与时间线索，每张卡片带一个回链指向原始会话；原始对话一条不删、一份不压。测试时模型先取 5 张卡片起步，然后在最多 5 轮的循环里决定是收工还是调用两个工具之一——SearchMeta 再看一张没看过的卡片，ReadRaw 顺回链把原文调出来读。挖到的证据蒸馏进记忆缓存，信息够了就停。
灵感来自人类的联想回忆：回忆「去年年会谁坐我旁边」时，不是先在脑子里建好一张座位表，而是顺着线索一路联想下去。
赢在预算分配，不在堆 token
两个基准、两个骨干模型，结论一致。LoCoMo 上用 Qwen3.5-27B 做骨干，T²Mem 平均 71.69 分，超过 LazyMem 的 69.84、LightMem 的 68.70 与 HiMem 的 65.34；换 Gemma4-31B 骨干，71.30 分依然居首。分项里最能体现「按需深挖」价值的 Multi-Hop（59.22）与 Temporal（75.70）都是全场最优——这两类问题的证据分散在多个会话里，正是「一次检索」最吃亏的场景。
LongMemEval 上的差距更大：T²Mem 平均 84.80 分，比 LightMem 的 77.40 高出 7.4 分；「单助手」类问题上 98 到 100 分对 10 到 25 分。Gemma4 骨干下 85.20 分，结论不变。
那是不是偷偷多花了算力？并没有。LoCoMo 上 T²Mem 全程 token 是 8.8k，LazyMem 要 11.3k，LightMem 是 6.2k，同一量级。它赢在分配策略：离线的钱只花在索引上，推理的钱花在「这一问真正需要的证据」上。论文还有一个对 test-time 路线很关键的发现——给 T²Mem 加推理预算，性能持续上涨；Search-o1 涨得慢；Naive RAG 加预算反而下降。额外计算得能转化成「对记忆演化真正有用的证据」才有意义。
一组可能推翻排期的消融结果
消融实验把每个部件的功劳算得很清楚（LoCoMo，Qwen3.5-27B）：半结构化元数据 71.69 高于每段换成摘要的 68.64，更高于换成实体关系图的 62.92。图谱那项值得多说一句——建图又费 token 又掉分，说明时间戳、事件、主题这类「平铺的线索」比精心组织的图结构更能帮模型定位证据。去掉原文回链掉到 67.60，去掉动态构建掉到 65.45，后者约 6 分就是「边想边找」这一步的净贡献。
泼几盆冷水
落地前有几个坎得想清楚。延迟搬家了：离线构建开销省下来了，但每次问答都要跑最多 5 轮「检索—阅读—蒸馏」循环，在线延迟实打实上升，论文没有报告延迟绝对值。索引质量是单点依赖：元数据是离线提取的，某次漏了关键事件，测试时 SearchMeta 就永远找不到它——索引只是指针，不是全文，回链能救「卡片写得糙」，救不了「卡片压根没生成」。任务范围也有边界：两个基准都是读取型任务，而真实场景还有用户偏好更新、旧信息失效、该忘的遗忘这类写入需求，论文没碰。评测依赖裁判模型，长答案对比里的裁判偏置始终是个变量，数字看趋势就好。
但这篇论文最大的价值，是给记忆系统工程提了一个尖锐的问题：你离线做的那些压缩、组织、合并，到底是在为查询服务，还是在为存储服务？如果模型足够便宜、检索足够快，「存原文 + 轻索引 + 现场构建」未必是更差的选择——毕竟原文是无损的表示，其他一切加工都是有损的赌注。