TRACE开源：把Agent记忆做成主题树，干翻Mem0

一个不做RAG的记忆系统，反而把RAG方案吊打了

7月初，一个叫 TRACE 的开源项目在 r/MachineLearning 上被开发者放出来，附带一份看着有点扎眼的 benchmark：MemoryAgentBench（ICLR 2026）里的 EventQA 精确检索任务，TRACE 用 gpt-oss-20B 跑出了 82.5% 的 F1，换 120B 模型能再往上顶到 83.8%。

作为对比，同一个 benchmark 上论文里给出的官方数字是：

• Mem0（GPT-4o-mini）：37.5%
• MemGPT / Letta（GPT-4o-mini）：26.2%

一个跑在本地开源权重上的方案，把两个跑在闭源商业模型上、专门做 Agent 记忆的项目干出了 45 个百分点的差距。这个数字第一眼看上去有点离谱，但如果你最近踩过 Agent 长上下文记忆的坑，会明白它其实指向一个很久没人认真回答的问题——记忆到底该怎么组织。

所有 AI 记忆系统最后都长成了同一副样子

先说个开发者圈里已经默认的事实：现在市面上绝大多数 AI 记忆系统，方法论几乎是同一个模板。

聊天记录、用户偏好、上传的文档、工作流的中间产物——全部切 chunk，喂进向量库，下次 query 来了做一次 embedding 相似度检索，再拼回 prompt 里。Mem0、MemGPT、Letta、Zep，包括各种自研方案，架构上都逃不出这个圈。

这套办法不是不行，是在需要跨长时段、跨主题推理的场景下会崩。原因很朴素：

1. chunk 是无结构的。切成 500 token 一段之后，语义边界就没了，一个事件被切两半是常事。
2. 向量检索是"最相似"，不是"最相关"。用户问"我上次说过想去京都还是大阪"，向量库会把所有提到日本旅游的段落都捞出来，包括三个月前无关紧要的闲聊。
3. 没有时间线，没有因果。RAG 假设知识是静态的，但对话记忆本质上是一条动态时间轴，先说 A 后说 B，B 可能推翻 A。

MemoryAgentBench 之所以能把 Mem0 打到 37.5%，就是因为它专门测这种"你需要在长对话里精确找到某个特定事件"的能力。这不是 RAG 擅长的事。

TRACE 的做法：把对话组织成一棵会长大的主题树

TRACE 的核心思路，一句话概括：不把对话切碎，而是把它们按主题聚成一棵树，每个节点都自带摘要。

展开讲，它做了这么几件事：

• 主题分裂。新消息进来时，agent 判断它属于已有的哪个主题分支，还是需要开一个新分支。这一步是 LLM 主导的，不是聚类算法。
• 层级摘要。每个分支都维护一个动态更新的摘要，父节点的摘要是子节点摘要的抽象。你可以把它想成一个自动生成的、动态维护的"目录"。
• 树上检索。查询来的时候，先从根节点的摘要开始判断该往哪个分支走，逐层下探，最后到叶子节点拿具体细节。这是一次 top-down 的语义导航，不是全局向量匹配。

熟悉 B-Tree 或者文件系统的开发者应该立刻反应过来了——这本质上是给对话记忆装了一套索引结构。RAG 是全文搜索，TRACE 是目录结构。前者是暴力，后者是分治。

用 pip 就能装：

pip install trace-memory

作者把两次运行的完整 JSON log 都放出来了，包括每一步 LLM 的调用输入输出，这一点比很多只放最终数字的论文实在得多。

那份 benchmark 到底能信几分

必须泼一盆冷水：这个对比不是完全 apples-to-apples 的。

作者自己也在帖子里说得很清楚。TRACE 用的是本地跑的 gpt-oss-20B/120B，Mem0 和 MemGPT 那两个数字是论文里在 GPT-4o-mini 上跑出来的官方结果。理论上后端模型不一样，直接比不公平。

作者尝试过在 gpt-oss-20B 上把 Mem0 跑起来做同底座对比，结果卡在了 Mem0 的 fact-extraction 环节——那一步要求 LLM 严格输出 JSON，而 gpt-oss 在结构化输出上会漏格式。这不是 gpt-oss 独有的问题，Gemini 和 Mistral 上都能复现同样的坑。Letta 因为要起完整 server 就直接跳过了。

所以严格说，这份数据能证明的是：

• TRACE 在 gpt-oss 上能跑到 82.5%，这是一个绝对数字，站得住。
• Mem0/MemGPT 在同一个 benchmark 上，用更强的商业模型也只有 30% 上下，这是论文里的公开数字。
• 中间的差距，一部分是方法论差异，一部分可能是模型能力差异。但差 45 个点，方法论至少占了大头。

换句话说，就算你打个五折看，这个结果依然说明分层树结构在事件检索这类任务上，比 flat RAG 有明显优势。

为什么这件事对 Agent 开发者有意义

过去一年做 Agent 的团队，尤其是做长期陪伴、客服、个人助理这类需要"记住用户"的产品，几乎都被记忆这一层折磨过。典型症状是：

• 用户信息越攒越多，token 成本线性上涨
• 向量检索命中率随对话长度衰减，聊到 50 轮以后基本变随机
• 想加一个"总结上周聊了什么"的功能，发现根本做不到，因为 chunk 是无序的

TRACE 这类方案至少给了另一条思路：别再把对话当作待检索的知识库，而当作一棵需要维护结构的语义树。这对以下几类场景特别有价值：

1. 多轮对话 Agent：跨天、跨会话的记忆连续性
2. 多任务 Agent：一个 agent 同时负责代码、日程、写作，主题天然分叉
3. 审计与可解释：树结构可视化后，你能看到 agent"记得什么"，而 embedding 空间是不可读的

一些没解决的问题

实话说，TRACE 目前也有几个坎：

• 主题分裂的准确性依赖 LLM 判断。用弱一点的模型，树会长歪，摘要质量也会掉。作者用 20B 起步不是没原因的。
• 写入延迟。每条消息都要过一次 LLM 判断分支归属，比直接塞进向量库慢一个数量级。适合离线批处理，不适合每 token 都写。
• 检索路径错了就找不回来。top-down 导航一旦在中间节点选错分支，就摸不到答案。RAG 的"暴力搜索"至少在 recall 上更稳。
• 树太深怎么办。作者没细说剪枝和归档策略，长期运行下树会膨胀。

这些都是工程化时躲不掉的问题，但架构方向本身是对的——这一点比数字更值得关注。

顺便说一句后端模型的事

TRACE 用的是 OpenAI 今年放出来的 gpt-oss 开源系列，20B 和 120B 两个尺寸。这套模型在结构化推理、工具调用上表现不错，本地部署也不算离谱，24GB 显存能塞下 20B 的量化版。对于想复现 TRACE、又不想烧 GPT-4o token 的开发者，是个合适的选择。

如果你懒得本地跑，OpenAI Hub 上 gpt-oss 系列和 GPT-4o、Claude、Gemini、DeepSeek 一样都在，一个 Key 都能调，兼容 OpenAI 格式，方便做 A/B 对比——比如同一个 TRACE 逻辑，换不同后端看树的质量变化。这种横向实验用聚合平台确实省事。

一个方向性的判断

2025 到 2026，Agent 圈两个最反复出现的关键词是"上下文"和"记忆"。前者靠模型厂商堆窗口（Gemini 2M、Claude 1M），后者需要工程侧自己造轮子。

TRACE 不是这个方向上第一个尝试分层结构的项目，但它把方法讲清楚了、代码开源了、benchmark 跑出来了。记忆系统正在从"更好的 RAG"走向"更结构化的知识组织"——这可能是 Agent 从 demo 走向可用产品的必经之路。

RAG 不会消失，但它不该是 Agent 记忆的全部。

参考来源

• TRACE: open-source hierarchical memory for LLM agents - Reddit - TRACE 项目作者在 r/MachineLearning 发布的原始帖子，包含 benchmark 数据和实现细节说明