Databricks 发布 MemCurrent 生产级 Agent 持久记忆架构

AI 工具让智能体的 vibe 编程变得轻而易举。然而，在生产环境中构建和维护企业级智能体仍然要困难得多。尤其是，开发者往往被迫在质量（获得好的答案，尤其是在长尾任务上）和效率（在大规模下控制成本和延迟）之间做出取舍。通常，某些技术会以牺牲一个维度为代价来换取另一个维度的收益。

记忆是一种有望同时改善两者的方法。它可以帮助智能体跨任务携带有用的上下文，例如用户偏好、先前的纠正、指标定义和成功的工作流。原则上，这可以提高准确性、减少重复错误，并避免不必要的重复探索。但更多的历史记录并不一定意味着更好的记忆。提供每一次过去的交互成本高昂，并且可能引入过时、冲突或无关的上下文。核心挑战在于决定保留什么、如何维护它，以及如何衡量其有用性。

在这篇文章中，我们介绍 MemCurrent，一种面向生产智能体的持久记忆架构，它现在为新的 Agent Bricks Memory 和 Genie 提供支持。智能体在工作时读写记忆，一个离线的“dreaming”流水线会整合记忆，使其保持一致和新鲜。在我们基于真实企业任务构建的内部基准上，MemCurrent 将智能体的通过率提升至无记忆时的三倍，同时使用的 token 减少了 31%，运行速度提高了 26%。本文的其余部分将介绍我们如何设计和评估它，以及我们在此过程中学到了什么。

图 1. 在我们的内部记忆基准上，通过率与每任务 token 数的关系。MemCurrent 位于帕累托前沿，在两个维度上都优于 Mem0、PropMem 和 OpenClaw memory。

我们如何设计记忆

将记忆接入智能体有三种方式。作为插件（就像我们之前在 MemAlign 和 Memory Scaling 上的工作），记忆在会话中的固定点自动读写。作为工具，智能体决定读写什么以及何时读写。作为离线流水线，记忆按计划或触发条件在后台更新，并在后续会话中使用。每种方式都有其取舍：

表 1. 记忆的三种访问模式：插件、工具或离线流水线。

MemCurrent 三种方式都会用到，各取所长。

图 2. MemCurrent 概览。

MemCurrent 有两种记忆：情景记忆， 存储原始会话轨迹；以及派生记忆，包含从这些轨迹中提炼出的经验，以文件形式存储在结构化知识库中。顶部有一个自动生成的 memory.md 索引，描述文件结构以及每个文件的内容。

情景记忆和派生记忆都存放在生产级数据库中，可扩展到大量用户，同时提供低延迟响应。情景记忆是仅追加的，插件会在会话运行时记录每一步。派生记忆是一张模拟分层文件系统的可变表，写入有两种方式。Agent 工具（add_memory, update_memory, delete_memory）处理显式请求，例如“永远不要在 /tmp 目录下写脚本”。离线 dreaming 流水线负责其余部分，将每个新会话中的隐式经验提炼到相关文件中。它还会清理整个存储，拆分过大的文件、合并重复项并解决冲突。

读取是分层进行的。会话开始时，插件会注入记忆索引，让 agent 在开始前就知道自己掌握哪些知识。会话期间，agent 有两个可跨两种记忆类型使用的工具： search_memory 返回查询的最佳匹配项（过去轨迹中的某一步，或记忆文件中的某一行）， fetch_memory 按标识符（会话 ID 或文件路径）返回完整条目。

我们如何评估记忆

基准测试

我们从三个流行的开源基准测试开始： LoCoMo、 LongMemEval 和 ConvoMem。这三者都测试 agent 能否回忆起开放式合成对话中早先陈述的事实。

此外，我们还基于真实的 Genie 对话构建了一个内部记忆基准测试，用户会在其中就自己的数据提出各种问题。如图 3 所示，我们从 12K+ 个会话出发，挖掘出 3K 个包含值得记忆信号的候选会话，并起草了一个带有评分标准的后续问题。同一用户的其余会话作为测试用例的填充内容。随后，一个对抗性评判器根据 7 项标准检查每个测试用例，例如知识是否确实存在、是否特定于该用户、是否为回答所必需、是否自然以及是否可验证。经过最终人工审核，该基准测试共有 114 个测试用例，涉及 29 个用户和 2,233 个历史会话。 

图 3. 我们如何构建内部记忆基准测试。

下面是一个示例：

图 4. 内部记忆基准测试中的一个示例测试用例。在过去的会话中，用户纠正了 agent 对表的选择，并告诉它排除后台请求。之后，agent 面对一个不同但相关的问题，必须在 100 多个其他会话中找到那个会话，并应用所学到的内容。输出由 LLM 评判器根据一系列评分标准进行评分（有些依赖记忆，有些是任务本身固有的）。

我们的基准测试在三个方面与现有基准测试不同：

企业领域。现有基准测试是关于模拟人物生活的开放式聊天。我们的基准测试来自数据工作空间中的真实工作，涉及丰富的企业知识，例如表语义、指标定义和工作流。

记忆驱动行动，而非答案。 在过往对话中找到正确的字符串还不够；智能体必须应用检索到的知识来完成多步任务。

多样性。 测试用例涵盖 5 种记忆类型（个人资料、偏好、领域知识、项目、工作流），并与 11 种场景交叉组合（直接指令、变化或过时的事实、多会话聚合、与记忆无关的问题等）。 

结果

我们将 MemCurrent 与三个开源记忆后端 Mem0、 PropMem、 OpenClaw memory 进行比较，使用相同的底层 LLM。 

开源基准测试。 我们将每个记忆后端与一个简单的问答智能体配对，该智能体使用两种智能体框架（LangGraph 和 OpenAI Agents SDK）构建。我们还运行两个基线：下限为无记忆，上限为完整上下文，即每个过往会话都进入智能体的上下文。在所有三个基准测试中，MemCurrent 在所有记忆后端中得分最高，并且保持在成本-准确率帕累托前沿上。平均而言，MemCurrent（88.1%）的表现与完整上下文（87.8%）相当，而每个问题的输入 token 数约少 12 倍（8.4K 对 103K）。在历史最长的两个基准测试中，它甚至超过了完整上下文，因为把所有内容都塞进提示词反而会让智能体困惑。 

图 5. 记忆后端在 (a) LoCoMo（每样本 19–32 个会话）、(b) LongMemEval（s 划分）（每样本 38–62 个会话）和 (c) ConvoMem（500 个样本的分层子集，每样本 100 个会话）上的成本-准确率¹权衡。我们使用 GPT 5.6 luna 作为智能体和记忆模型。所有记忆后端都作为插件运行，该插件会自动搜索与问题相关的记忆，并在会话开始时将其注入智能体上下文。² 准确率是 LangGraph 和 OpenAI Agents SDK 两种框架及 3 次重复的平均值。成本是每个问题的平均输入 token 数（对数刻度）。

内部记忆基准测试。 在我们的基准测试中，差距进一步扩大。在这里，每个记忆后端都在我们内部的 Genie 中运行，该智能体与基准测试会话来自同一个智能体。历史记录太长，无法放入上下文，因此我们的上限是黄金注入：仅将黄金记忆注入智能体的上下文。在所有记忆后端中，MemCurrent 的通过率最高（68.4%），延迟最低（252s），token 使用量最低（418K），弥合了无记忆（22.3%）与黄金注入（78.6%）之间超过 80% 的差距。值得注意的是，虽然 Mem0 在较早的基准测试中也处于前沿，但在这里以 43.9% 落后，且延迟和成本更高。与无记忆相比，MemCurrent 使智能体的通过率提高到三倍（22.3% → 68.4%），同时速度提高 1.35 倍，成本降低 1.44 倍。

图 6。在我们的 Internal Memory Benchmark 上，每个任务在 3 次重复中的通过率、平均延迟和平均 token 用量。我们使用 Claude Opus 4.6 作为 agent 模型，GPT 5.6 sol 作为 memory 模型。所有 memory 后端都以 agent 工具和会话启动插件的形式提供。

MemCurrent 实战

除了基准测试数字之外，让我们从内部 Genie 会话中看两个例子，了解 MemCurrent 在实践中如何提供帮助。

示例 1：记忆阻止了一次偶发的幻觉错误。在图 7 中，用户向 agent 询问过去两个月 Product X 的前 20 名用户。agent 写了一条正确的 SQL 查询，但从未读取保存到文件中的实际执行结果。它仍然自信地生成了一张包含幻觉内容的表格。在用户反馈后，agent 将这一教训保存到记忆中。下一次，查询运行后，agent 先读取结果，然后返回了正确的表格。一次记忆纠正阻止了一次性失误变成习惯。

图 7。一个匿名化示例，展示记忆如何帮助 agent 避免重复的幻觉错误。

示例 2：记忆在相关任务上节省计算。在图 8 中，用户要求“前 5 名 SDP 客户”。agent 必须从头弄清楚一切：“SDP”代表什么、哪些表保存使用数据，以及如何连接和过滤它们。它花了 11 次工具调用、8 个子 agent 和近六分钟。agent 将这些步骤保存为记忆中的工作流文件，可以在相关任务上复用。后来，用户问了一个不同的问题：上个月有多少 SDP 客户的 pipeline 运行次数超过 5K。使用该工作流，agent 在 41 秒内用 2 次工具调用和 1 个子 agent 回答了问题。问题是新的，但通往答案的路径不是，记忆让 agent 跳过了不必要的探索。

图 8。一个匿名化示例，展示记忆如何将 6 分钟的任务变成 41 秒。

MemCurrent 为何有效

为了理解 MemCurrent 卓越表现的原因，我们在 Internal Memory Benchmark 上针对两个设计选择进行了消融实验：记忆类型和提取策略。

我们需要两种记忆类型吗？ 仅情景记忆有中等帮助：35.8%，高于无记忆时的 22.3%。原始历史有用，但 agent 只在约三分之一的测试用例中搜索它，不过当它搜索时，其中 60% 能通过。派生记忆避免了这个问题，因为会话开始时注入的记忆索引让 agent 了解记忆中有什么以及何时查看，将通过率提升到 66.1%。在此基础上加入情景记忆可获得最佳结果，为 68.4%。增益很小，但它表明原始轨迹可以恢复蒸馏所丢弃的细节。 

图 9。按记忆类型划分的通过率。

什么是好的记忆提取策略？ 如图 2 所示，两个通道提取派生记忆：在线工具和离线 dreaming。单独使用时，离线 dreaming（63.5%）比在线工具（53.9%）高出近 10 个百分点。它们的组合产生了最高的通过率，为 66.1%。这支持了职责分工：dreaming 处理后台提取和整合，而在线工具让显式请求立即生效。

图 10。按提取策略划分的通过率。

结论

记忆是智能体不再从零开始的方式。在本文中，我们介绍了 MemCurrent，这是一种面向生产环境智能体的记忆架构，它结合了情景记忆和派生记忆，并提供三种访问模式：自动记录和加载上下文的插件、智能体按需调用的工具，以及在后台整合记忆的离线 dreaming 流水线。

在我们运行的所有基准测试中，MemCurrent 同时提升了质量和效率，这正是我们想要打破的权衡。在开源基准测试上，它以约 12 倍的输入 token 减少量达到了完整上下文的性能。在我们基于真实数据工作构建的内部记忆基准测试上，它将智能体的通过率提升至无记忆时的三倍，同时还使其更快、更便宜。

消融实验指出了价值来源。派生记忆承担了大部分工作，而情景记忆通过恢复蒸馏过程中丢失的细节带来了较小的提升。将在线工具与离线 dreaming 相结合形成了最佳的提取策略：显式请求立即生效，而 dreaming 则在后台提炼隐式学习成果并整合存储。

除了数字之外，记忆还提供了一个不绑定于单个智能体或 LLM 的知识库。它可以随用户迁移到新的智能体或 LLM，并可能为其组织内共享的知识提供种子，这是我们接下来要探索的方向。

开始使用

我们正在将这些发现应用于推动 Databricks 各产品的改进：

面向智能体开发者。 Agent Bricks 是 Databricks 用于构建自定义智能体的开发者平台。MemCurrent 已内置于 Agent Bricks 的 Memory 产品中，由 Lakebase 提供支持。该产品包括：

• 用于情景记忆的会话存储
• 用于派生记忆的记忆存储
• 自动 dreaming 流水线 
• 对智能体质量的追踪和评估，包括记忆的影响
• 一个 CLI，帮助你在 <10 分钟内快速上手一个包含上述所有功能的端到端示例智能体 

立即开始 构建你的自定义智能体。

面向 Databricks Genie 用户。 Genie 是一个界面，Databricks 用户可以通过自然语言与其数据对话。MemCurrent 已在幕后投入使用，帮助提高答案质量，同时降低响应延迟和成本。

立即开始 使用 Genie。

作者：Veronica Lyu, Wenhao Zhan, Sam Havens, Ziyi Yang, Jenny Sun, Qinxin Wang, Nihit Desai, Sirui Sun, Ankit Mathur, Jane Zhang, Yi Liu, Jialu Liu, Michael Bendersky, Matei Zaharia, Xing Chen

我们感谢 Jonathan Li、Rishabh Singh、Andy Zhang、Kenneth Choi、Will Tipton、Cassie Cao、Siddharth Murching、Sue Ann Hong、Pranav Sukumar、Neo Ni、Shanshan Zheng、Chung Wu 以及我们的内部用户研究参与者在整个项目过程中提供的反馈和支持。 

¹ 所有记忆后端的延迟相似（4-7 秒/问题），因为大多数问题可以在单跳内回答。

² 我们发现基于插件的记忆足以应对现有基准测试。添加工具的结果严格劣于前者，因此省略。