别再离线建记忆库了：T²Mem 让 Agent 边想边「现场拼装」记忆，LongMemEval 直接高出 7 分

💡 一句话总结：给 AI 助手建长期记忆，大家都在离线把聊天记录压成「记忆库」，又贵又容易答非所问。这篇论文把顺序反过来——离线只留一张轻量索引，等你提问的那一刻，让模型边推理边检索、现场拼出这份答案专用的记忆。LongMemEval 上比最强离线记忆系统高出 7 分多，token 花销却没多。

做 AI 助手、客服 Bot 或者个人助理的朋友，大概率被「长期记忆」折磨过：用户三个月前随口提过一句对海鲜过敏，今天问「帮我推荐个餐厅」，你希望 agent 能想起来。

主流方案是什么？离线建记忆库。把历史对话切片、总结、压缩，变成 Mem0 式的事实条目、MemGPT/MemoryOS 式的分层记忆、或者干脆上知识图谱。听起来很工程化，很稳妥。

但用过的人都知道这套有多拧巴：预处理贵、维护累，最要命的是——你根本不知道用户以后会问什么。库建得越「全」，成本越高；建得越「省」，真问起来又缺关键信息。做记忆系统的团队，谁没在「存什么、删什么、怎么更新」上开过无数次会？

东北大学联合清华、阿里巴巴的这篇新论文（arXiv 2610.13348），给出了一个相当反直觉的答案：别建了。至少，别提前建那么多。

资源在这，先收藏

• 📄 论文：arXiv 2610.13348
• 💻 代码：GitHub · OpenBMB/T2Mem

离线记忆库的两难，出在哪？

先把问题说透。现有记忆系统的流程是：历史对话进来 → LLM 反复调用，提取、总结、合并、去重 → 生成一份「查询无关」的记忆表示 → 之后每个查询来了，从库里检索几条塞给模型。

这套流程有个内生的矛盾。

一是成本错位。因为不知道未来查询长什么样，预处理必须「宁滥勿缺」：每段对话都要过一遍 LLM，还要持续维护（新对话来了要更新旧条目、解决冲突）。论文引用的研究直接指出，这种构建维护开销已经拖累了记忆系统的实际部署和扩展。

二是供需错配。预构建的记忆是通用的，查询却是特定的。最直白的证据在实验里：LightMem 在 LongMemEval 的多数类别上表现不错，但在「单助手」类问题上只拿了 10-25 分（满分 100）——离线压缩时丢掉的细节，恰好是某类问题的命门。同一套库，有的题型 90 分，有的题型 10 分，忽高忽低。

那把构建推迟到查询时刻行不行？其实已经有这类工作（论文里叫 LazyMem），做法是「先一次性检索一批候选事实，再现场组装成记忆」。听起来已经挺「现场」了，但问题在于：初始检索定生死。第一轮没检回来的证据，后面构建过程就永远见不着——而真正需要深度构建的多跳、时序问题，恰恰是初始检索最容易漏的。

它的思路是什么？

T²Mem（Test-Time Memory Construction）的核心转变只有一句话：记忆不是预先建好的库，而是推理过程中逐步涌现的状态。

灵感来自人类的联想回忆（associative recall）：一个线索激活一段记忆，这段记忆又带来新线索，再激活下一段。你回忆「去年年会谁坐我旁边」时，不是先在脑子里建好一张座位表，而是顺着「那次在宴会厅→坐在老王旁边→老王当时在聊跳槽」一路联想下去。

落到工程上，整个框架分两半。

离线只做一件事：建索引，不建库。 用 LLM 给每段会话提取一份轻量的「情景元数据」——关键事件、事实、实体、时间线索的半结构化小卡片，并且每张卡片都带一个回链，指向原始会话。注意，原始对话一条不删、一份不压，全部保留。

测试时边推理边拼装。 查询来了，模型先按相关性取 Top-5 张元数据卡片，然后进入一个循环：每一步，模型看着「已拼装的记忆 + 最新观察」，决定是收工作答，还是调用两个工具之一继续挖——

• 🔍 SearchMeta：再看一张没看过的元数据卡片（已看过的不会重复推给你）；
• 📖 ReadRaw：顺着某张卡片的回链，把对应的原始会话原文调出来读。

每一步挖到的证据都被蒸馏进「记忆缓存」，一步步拼接。信息够了、或者到 5 步上限，就停止，用拼好的记忆生成最终答案。

图 1：T²Mem 整体架构。上面是离线索引，下面是测试时的动态构建循环。

看出门道了吗？检索不再是「一次定终身」，而是被推理牵着走。拼到一半发现缺时序信息？调 SearchMeta 补卡片。卡片语焉不详？调 ReadRaw 下原文。构建过程自己知道缺什么、去哪补——这就是它和 LazyMem「一次检索定天下」的本质区别。

顺带一提，这个设计还有个隐藏好处：因为原始对话一直都在，摘要做错了、细节丢了都不致命——回链一按，原文就在那。对做记忆工程的人来说，「留回链」这个习惯可能比任何精巧的摘要策略都值钱。

效果到底怎么样？

两个基准、两个骨干模型，结论高度一致：全面领先，而且不是靠堆 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：

方法	平均分（Qwen3.5-27B）
Naive RAG	71.60
MemoryOS	63.80
LightMem	77.40
LazyMem	72.60
T²Mem	84.80

比最强离线系统 LightMem 高出 7.4 分。单看「单助手」类问题更夸张：T²Mem 98-100 分，LightMem 只有 10-25 分。换 Gemma4 骨干，85.20 分，结论不变。

有人会问：是不是偷偷花了更多算力？还真不是。LoCoMo 上 T²Mem 全程 token 是 8.8k，LazyMem 要 11.3k，LightMem 6.2k——同一量级。它赢在分配策略：离线的钱只花在索引上，推理的钱花在「这一问真正需要的证据」上。

图 2：构建出的记忆质量五维评估。注意「细节保留」——因为能随时回读原文，T²Mem 存下的记忆颗粒度明显更细。

还有一个对 test-time 路线很关键的发现：给 T²Mem 加推理预算，性能持续上涨；Search-o1 加预算涨得慢；Naive RAG 加预算反而下降。这说明「测试时扩展」（test-time scaling）不是无脑堆算力就灵——额外的计算得能转化成「对记忆演化真正有用的证据」才有意义。RAG 检索回来的东西一锤定音，多给预算只是多塞噪音，越塞越糊。

拆开看：哪个部件在起作用？

消融实验把每个部件的功劳算得挺清楚（LoCoMo，Qwen3.5-27B）：

• 元数据 vs 摘要 vs 图谱：半结构化元数据 71.69 > 每段会话换成摘要 68.64 > 换成实体关系图 62.92。图谱那项值得多说一句：建图又贵（token 更多）又掉分，时间戳、事件、主题这些「平铺的线索」比精心组织的图结构更能帮模型定位证据。做记忆系统的朋友，这条可能直接推翻你下个季度的排期。
• 去掉元数据（直接在原始会话上构建）：掉到 69.74，token 反而涨到 11.8k——没有索引，模型在原始对话里大海捞针。
• 去掉原文回链（只看元数据）：掉到 67.60——卡片再好也代替不了原文细节。
• 去掉动态构建（初始检索完直接答）：掉到 65.45——约 6 分的差距，就是「边想边找」这一步的净贡献。

四个部件，环环相扣，缺哪个都掉分。这不是单点创新，是一套配合好的组合拳。

泼冷水：先别急着重构你的记忆系统

论文漂亮，但落地前有几个坎得想清楚。

延迟搬家了。 离线构建的开销省下来了，但每次问答都要跑最多 5 轮「检索-阅读-蒸馏」循环，在线延迟是实打实上升的。论文没有报告延迟绝对值（uncertain）——对内部知识库查询无所谓，对实时对话产品，这笔账得自己算。

索引质量是单点依赖。 元数据是离线提取的，如果某次提取漏了关键事件，测试时的 SearchMeta 永远找不到它——索引只是指针，不是全文。回链能救「卡片写得糙」，救不了「卡片压根没生成」。

任务范围有边界。 两个基准都是「读取型」任务：历史都在那，问的只是查得准不准。但真实 agent 场景还有「写入型」需求——用户偏好更新、旧信息失效、该遗忘的遗忘。T²Mem 本质是读取侧方案，这部分它没碰。

评测依赖 LLM judge。 虽然统一了裁判模型、方法也算规范，但 judge 偏置在长答案对比里始终是个变量，数字看看就好，别背小数点。

理性看待：这条路线的真正信号

跳出这篇论文本身，我觉得它最大的价值是给「记忆系统工程」提了一个尖锐的问题：你离线做的那些压缩、组织、合并，到底是在为查询服务，还是在为存储服务？

如果模型足够便宜、检索足够快，那「存原文 + 轻索引 + 现场构建」可能就是更优解——毕竟原文是唯一无损的表示，其他一切加工都是有损的赌注。当然，模型不会永远便宜，检索也不会无限快，所以现实里大概率是混合方案：高频、模式化的信息离线整理好，长尾的、查询难料的部分留给测试时现场拼。

对开发者，我建议带走三样东西：

• 📋 元数据 schema 可以直接抄：事件 + 事实 + 实体 + 时间线索 + 源链接，比你现在的摘要格式更值得投入；
• 🔁 「推理与检索交错」的循环设计可以搬进任何 agent harness——两个工具接口（搜索引、读原文）加上防重复机制，实现成本很低；
• 🧊 先做消融再上图谱：这篇论文里知识图谱输给了平铺元数据，你自己的场景里未必不是同样的结局。

论文和代码都开放了，链接在上面。做记忆方向的，值得一读。