MemCurrent：为生产级 Agent 设计持久记忆

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

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

在这篇文章中，我们介绍 MemCurrent，一种用于生产环境 agent 的持久记忆架构，它现在为新的 Agent Bricks Memory 和 Genie 提供支持。Agent 在工作时读写记忆，而一个离线的“做梦”流水线会整合记忆，使其保持一致和新鲜。在我们基于真实企业任务构建的内部基准上，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 目录中写脚本”。离线做梦流水线捕获其余内容，将每个新会话中的隐式经验提炼到相关文件中。它还会清理整个存储，拆分过大的文件、合并重复项并解决冲突。

读取分层进行。在会话开始时，插件注入记忆索引，因此 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 评判器根据一系列评分标准进行评分（有些依赖记忆，有些是任务固有的）。

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

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

记忆为行动提供输入，而非答案。 在过去的对话中找到正确的字符串还不够；agent 必须应用检索到的知识来完成多步任务。

多样性。 测试用例涵盖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 split）（每样本38–62个会话）和（c）ConvoMem（500个样本的分层子集，每样本100个会话）上的成本-准确率1权衡。我们使用 GPT 5.6 luna 作为智能体和记忆模型。所有记忆后端均作为插件运行，该插件会自动搜索与问题相关的记忆，并在会话开始时将其注入智能体上下文。2 准确率是 LangGraph 和 OpenAI Agents SDK 两个框架以及 3 次重复的平均值。成本是每个问题的平均输入 token 数（对数刻度）。

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

图6。在我们的内部记忆基准测试中，跨3次重复的每个任务的通过率、平均延迟和平均 token 使用量。我们使用 Claude Opus 4.6 作为智能体模型，GPT 5.6 sol 作为记忆模型。所有记忆后端均作为智能体工具和会话启动插件提供。

MemCurrent 实战

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

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

图7。一个匿名示例，展示记忆如何帮助智能体避免重复出现幻觉错误。

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

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

MemCurrent 为何有效

为了解是什么造就了 MemCurrent 的卓越性能，我们在内部记忆基准测试上针对两个设计选择进行了消融实验：记忆类型和提取策略。

我们需要两种记忆类型吗？仅情景记忆就有中等程度的帮助：35.8%，高于无记忆时的22.3%。原始历史记录是有用的，但智能体仅在约三分之一的测试用例中搜索它，尽管在搜索时其中有60%能通过。派生记忆避免了这个问题，因为在会话开始时注入的记忆索引为智能体提供了有关记忆中可用内容以及何时查找的信息，将通过率提升到66.1%。在此基础上再加入情景记忆可获得最佳结果，达到68.4%。增益很小，但它表明原始痕迹可以恢复蒸馏所丢弃的细节。

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

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

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

结论

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

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

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

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

快速开始

我们正将这些发现用于推动 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 以及我们内部用户研究的参与者，感谢他们在整个项目期间提供的反馈和支持。

1 在所有记忆后端上，延迟相近（每个问题 4-7 秒），因为大多数问题可在单跳内回答。

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