Databricks 发布 MemCurrent：为生产级 Agent 设计持久记忆架构

AI 工具让编写 agent 代码变得轻松。然而，在生产环境中构建和维护企业级 agent 仍然困难得多。特别是，开发者常常被迫在质量（获得好答案，尤其是在长尾任务上）和效率（在大规模下控制成本和延迟）之间做出权衡。通常，某些技术会在一方面带来收益，却以另一方面为代价。

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

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

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

我们如何设计记忆

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

表 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 秒/问题），因为大多数问题可以在单跳内回答。

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