MemCurrent: Designing Persistent Memory for Production Agents

MemCurrent：为生产环境代理设计持久化内存 | Databricks 博客

跳至主要内容

研究

2026年10月20日

MemCurrent：为生产环境代理设计持久化内存

由 Databricks AI 研究团队撰写

AI 工具让构建代码代理变得简单。然而，在生产环境中构建和维护企业级代理仍然面临显著挑战。特别是，开发者常常被迫在质量（获得良好答案，尤其是处理长尾任务）和效率（在规模上控制成本和延迟）之间做出权衡。通常，一种技术在提升某一维度的同时会牺牲另一维度。

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

在本文中，我们介绍了 MemCurrent，这是一种为生产环境代理设计的持久化内存架构，现已支持新的 Agent Bricks Memory 和 Genie。代理在工作时读写内存，而一个离线的“梦境”管道会整合内存以保持其一致性和新鲜度。在我们基于真实企业任务构建的内部基准测试中，MemCurrent 在无内存情况下将代理通过率提升了三倍，同时使用了 31% 更少的 token 并运行速度提升了 26%。本文其余部分将介绍我们如何设计和评估它，以及在此过程中的收获。

图 1. 我们内部内存基准测试中通过率与每任务 token 数的关系。MemCurrent 位于帕累托前沿，两项指标均优于 Mem0、PropMem 和 OpenClaw 内存。

我们如何设计内存

将内存集成到代理中有三种方式。作为插件（如我们之前在 MemAlign 和 Memory Scaling 上的工作），内存会在会话中的固定点自动读写。作为工具，代理决定何时读写内存。作为离线管道，内存在后台按计划或触发条件更新，并在后续会话中使用。每种方式都有其权衡：

内存作为……

触发方式

计算时间

优点

缺点

插件

自动

在线

• 更新立即生效

• 行为可预测

• 运行时成本和延迟更高

• 不灵活（例如，即使不需要内存时仍会浪费 token）

工具

代理

• 代理具有灵活性

• 质量受代理能力限制

管道

计划或触发

离线

• 运行时成本和延迟更低（异步批量处理）

• 更新存在延迟

表 1. 内存的三种访问模式：插件、工具或离线管道。

MemCurrent 同时使用这三种方式，根据最适合的场景进行选择。

图 2. MemCurrent 概览。

MemCurrent 有两种类型的内存：情节内存（episodic memory），用于存储原始会话记录；以及衍生内存（derived memory），从这些记录中提炼出的知识以结构化知识库中的文件形式存储。自动生成的 memory.md 索引位于顶部，描述文件结构及每个文件的内容。

Both episodic and derived memory reside in a production-grade database capable of scaling to numerous users while maintaining low-latency responses. Episodic memory is append-only, with a plugin logging each step as the session executes. Derived memory is a mutable table simulating a hierarchical file system, where writes occur in two distinct ways. Agent tools (add_memory, update_memory, delete_memory) manage explicit requests such as "Never write scripts in the /tmp directory." An offline dreaming pipeline captures the remainder, distilling implicit learnings from each session into relevant files. It also performs maintenance tasks across the entire store, splitting oversized files, merging duplicates, and resolving conflicts.

Reading operations occur in layers. At session initiation, a plugin injects the memory index, enabling the agent to understand its prior knowledge before starting. During the session, the agent has two cross-memory-type tools: search_memory returns top query matches (a step from a past trace or a line in a memory file), while fetch_memory retrieves full entries by identifier (session ID or file path).

How We Evaluated Memory

Benchmarks

We began with three widely-used open-source benchmarks: LoCoMo, LongMemEval, and ConvoMem. All three assess whether an agent can recall facts mentioned earlier in open-ended synthetic conversations.

Additionally, we developed an Internal Memory Benchmark based on real Genie conversations, where users ask diverse questions about their data. As shown in Figure 3, we started with over 12K sessions, extracted 3K candidates containing memory-worthy signals, and drafted follow-up questions with scoring rubrics. Other sessions from the same user served as fillers for test cases. An adversarial judge then evaluated each test case against seven criteria, including whether the knowledge was actually present, user-specific, essential for answering, natural, and verifiable. After final manual review, the benchmark contains 114 test cases spanning 29 users and 2,233 historical sessions.

Figure 3. How we constructed our Internal Memory Benchmark.

Here's an example:

Figure 4. A sample test case from our Internal Memory Benchmark. In a previous session, the user corrected the agent's table selection and instructed it to exclude background requests. Later, the agent encounters a different but related question and must locate that session among over 100 others while applying learned knowledge. Outputs are scored by an LLM judge using a rubric list (some memory-dependent, others task-intrinsic).

Our benchmark differs from existing ones in three key aspects:

Enterprise domain. Existing benchmarks focus on open-ended chats about simulated personas' lives. Our benchmark is based on real work in a data workspace, involving complex enterprise knowledge like table semantics, metric definitions, and workflows.

Memory drives actions, not just answers. Simply finding the right string in past conversations is insufficient; agents must apply retrieved knowledge to complete multi-step tasks.

Diversity. Test cases cover five memory types (profile, preferences, domain knowledge, projects, workflows) combined with 11 scenarios (direct instruction, changing/outdated facts, multi-session aggregation, memory-independent questions, etc.).

Results

We compared MemCurrent with three open-source memory backends—Mem0, PropMem, OpenClaw memory—using the same underlying LLM.

开源基准测试。我们为每种内存后端搭配一个简单的问答代理，该代理基于两种代理框架（LangGraph 和 OpenAI Agents SDK）构建。我们还运行了两种基线：无内存的下限和完整上下文的上限，其中所有历史会话都会进入代理的上下文。在所有三个基准测试中，MemCurrent 在所有内存后端中得分最高，并始终位于成本-准确性帕累托前沿。平均而言，MemCurrent（88.1%）在每次问题的输入令牌数（8.4K vs 103K）减少约12倍的情况下，表现与完整上下文（87.8%）相当。在两个历史记录最长的基准测试中，MemCurrent 甚至超越了完整上下文，因为将所有内容注入提示反而让代理感到困惑。

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

内部内存基准测试。在我们的基准测试中，差距进一步扩大。在此测试中，每种内存后端都在我们的内部Genie中运行，而Genie是生成基准测试会话的相同代理。由于历史记录过长无法放入上下文，我们的上限是黄金注入：仅将黄金记忆注入代理的上下文。在所有内存后端中，MemCurrent 的通过率最高（68.4%），延迟最低（252秒）且令牌使用量最少（418K），将无记忆（22.3%）与黄金注入（78.6%）之间的差距缩小了超过80%。值得注意的是，尽管Mem0在之前的基准测试中也位于前沿，但在此测试中其表现落后（43.9%），且延迟和成本更高。与无记忆相比，MemCurrent 将代理的通过率提高三倍（22.3% → 68.4%），同时使其速度提高1.35倍，成本降低1.44倍。

图6. 在我们的内部内存基准测试中，3次重复下任务的通过率、平均延迟和平均令牌使用量。我们使用Claude Opus 4.6作为代理模型，GPT 5.6 sol作为内存模型。所有内存后端均作为代理工具和会话启动插件提供。

MemCurrent 实际应用

除了基准数据，我们再通过两个来自内部Genie会话的实际案例，看看MemCurrent如何在实践中发挥作用。

案例1：内存阻止了偶发的幻觉错误。在图7中，用户要求代理提供过去两个月Product X的前20名用户。代理编写了正确的SQL查询，但从未读取保存到文件的实际执行结果。它仍然自信地生成了包含幻觉内容的表格。在用户反馈后，代理将教训保存到内存中。下一次查询运行时，代理先读取了结果，然后返回了正确的表格。一次内存修正阻止了偶发错误演变为习惯性错误。

图7. 一个匿名示例，展示内存如何帮助代理避免重复出现幻觉错误。

示例 2：内存可节省相关任务的计算资源。在图 8 中，用户询问了“前五大 SDP 客户”。代理需要从零开始推导所有内容：SDP 的含义、哪些表存储了使用数据，以及如何连接和过滤这些表。整个过程耗时 11 次工具调用、8 个子代理和近六分钟。代理将这些步骤作为工作流文件保存在内存中，可在相关任务中重复使用。之后用户提出不同问题：上个月有多少 SDP 客户的流水线运行次数超过 5000 次。借助工作流，代理仅用 2 次工具调用、1 个子代理和 41 秒就完成回答。问题本身是新的，但解题路径并非全新，内存使代理跳过了不必要的探索。

图 8。匿名示例展示内存如何将 6 分钟任务缩短至 41 秒。

使 MemCurrent 生效的关键因素

为理解 MemCurrent 为何表现优异，我们在内部内存基准测试中对两个设计选择进行了消融实验：内存类型和提取策略。

是否需要两种内存类型？仅使用情景内存已能带来中等提升：从无内存的 22.3% 提升至 35.8%。原始历史记录有一定价值，但代理仅在约三分之一的测试案例中会搜索它，且在这些案例中仅能通过 60%。派生内存避免了这一问题，因为会话开始时注入的内存索引向代理提供了内存中可用信息及何时检索的提示，使通过率提升至 66.1%。叠加情景内存后效果最佳，达到 68.4%。提升幅度虽小，但表明原始轨迹能恢复蒸馏过程丢失的细节。

图 9。按内存类型划分的通过率。

什么是有效的内存提取策略？如图 2 所示，两种渠道提取派生内存：在线工具和离线梦境。单独使用时，离线梦境（63.5%）比在线工具（53.9%）高出近 10 个百分点。两者的结合产生最高通过率 66.1%。这支持职责分工：梦境处理背景提取与整合，而在线工具使显式请求立即生效。

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

结论

内存是代理避免从零开始的关键。在本文中，我们介绍了 MemCurrent，这是一种结合情景内存和派生内存的生产级代理内存架构，包含三种访问模式：自动记录和加载上下文的插件、按需调用的工具，以及在后台整合内存的离线梦境流水线。

在所有基准测试中，MemCurrent 同时提升了质量和效率，打破了我们设定的权衡限制。在开源基准测试中，其在约 12 分之一输入标记量下达到完整上下文性能。在基于真实数据工作的内部内存基准测试中，它在无内存情况下使代理通过率翻三倍，同时提升速度并降低成本。

消融实验指明了价值来源。派生内存承担了主要工作，情景内存通过恢复蒸馏丢失的细节提供较小增益。结合在线工具与离线梦境是最佳提取策略：显式请求立即生效，而梦境在后台提炼隐式学习并整合存储。

除了数字之外，内存还提供了一个知识库，这个知识库不局限于单个代理或大型语言模型（LLM）。它可以随着用户迁移到新的代理或LLM，并可能在组织内部共享知识，这是我们下一步正在探索的方向。

入门指南

我们将这些发现应用于改进Databricks产品的各个方面：

面向代理开发者。Agent Bricks是Databricks用于构建自定义代理的开发者平台。MemCurrent作为Agent Bricks内存解决方案的核心组件，由Lakebase提供支持。该解决方案包含以下功能：

• 会话存储用于情景记忆
• 内存存储用于派生记忆
• 自动梦境生成流水线
• 代理质量追踪与评估（包括内存影响分析）
• 命令行工具，可帮助您在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. 我们发现基于插件的内存对于现有基准测试已足够。添加工具后的结果被严格支配，因此省略。

订阅最新文章

订阅我们的博客，将最新文章直接发送到您的邮箱。

立即订阅

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"