AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。
MemCurrent: Designing Persistent Memory for Production Agents | Databricks Blog Skip to main content AI tools have made it easy to vibe code agents. Building and maintaining an enterprise agent in production, however, remains significantly more challenging. In particular, developers are often forced to make a trade-off between quality (getting good answers, especially on long-tail tasks) and efficiency (keeping cost and latency in check at scale). Oftentimes, techniques bring gains in one dimension at the cost of another. Memory is a promising way to improve both at the same time. It can help agents carry useful context across tasks, such as user preferences, prior corrections, metric definitions, and successful workflows. In principle, this can improve accuracy, reduce repeated errors, and avoid unnecessary rediscovery. But more history is not necessarily better memory. Supplying every past interaction is costly and can introduce stale, conflicting, or irrelevant context. The central challenge is deciding what to retain, how to maintain it, and how to measure usefulness. In this post, we introduce MemCurrent, a persistent memory architecture for production agents, which now powers the new Agent Bricks Memory and Genie. Agents read and write memory as they work, and an offline “dreaming” pipeline consolidates memory to keep it consistent and fresh. On our internal benchmark, built from realistic enterprise tasks, MemCurrent triples the agent's pass rate over having no memory, while using 31% fewer tokens and running 26% faster. The rest of this post covers how we designed and evaluated it, and what we learned along the way. Figure 1. Pass rate vs. tokens per task on our Internal Memory Benchmark. MemCurrent is on the Pareto frontier, outperforming Mem0, PropMem, and OpenClaw memory on both dimensions. How We Designed Memory There are three ways to wire memory into an agent. As a plugin (like our earlier work on MemAlign and Memory Scaling), memory is read and written automatically at fixed points in a session. As tools, the agent decides what and when to read and write. As an offline pipeline, memory is updated in the background on a schedule or trigger, and used in later sessions. Each comes with trade-offs: Memory as a … Triggered by Time of computation Pros Cons Plugin Automatic Online Updates take effect immediately Predictable behavior Higher runtime cost and latency Inflexible (e.g., wasting tokens even when memory isn't needed) Tool Agent Online Updates take effect immediately Agent has flexibility Higher runtime cost and latency Quality constrained by agent capability PipelineSchedule or triggerOffline Lower runtime cost and latency (async batched) Updates arrive with a delay Table 1. Three access patterns of memory: plugin, tool, or offline pipeline. MemCurrent uses all three, each where it fits best. Figure 2. Overview of MemCurrent. MemCurrent has two types of memory: episodic memory, which stores raw session traces; and derived memory, which has the distilled learnings from these traces, stored as files in a structured knowledge base. An auto-generated memory.md index sits at the top, describing the file structure and what each file contains. Both episodic and derived memory live in a production-grade database that can scale to many users while delivering low-latency responses. Episodic memory is append-only, where a plugin logs each step as the session runs. Derived memory is a mutable table simulating a hierarchical file system, where writing happens in two ways. Agent tools (add_memory, update_memory, delete_memory) handle explicit requests like “Never write scripts in the /tmp dir”. An offline dreaming pipeline captures the rest, distilling implicit learnings from each new session into the relevant files. It also cleans up the whole store, splitting oversized files, merging duplicates, and resolving conflicts. Reading works in layers. At session start, a plugin injects the memory index, so the agent knows what it knows before it begins. During the session, the agent has two tools that work across both memory types: search_memory returns the top matches for a query (a step in a past trace, or a line in a memory file), and fetch_memory returns the full entry by identifier (session ID or file path). How We Evaluated Memory Benchmarks We start with three popular open-source benchmarks: LoCoMo, LongMemEval, and ConvoMem. All three test whether an agent can recall facts stated earlier in open-ended synthetic conversations. In addition, we built an Internal Memory Benchmark from real Genie conversations, where users ask all kinds of questions about their data. As in Figure 3, we started from 12K+ sessions, mined 3K candidates containing memory-worthy signals, and drafted a follow-up question with scoring rubrics. The other sessions from the same user serve as fillers for the test case. An adversarial judge then checked each test case against 7 criteria, such as whether the knowledge is actually present, specific to the user, required to answer, natural, and verifiable. After a final manual review, the benchmark has a total of 114 test cases, with 29 users and 2,233 history sessions. Figure 3. How we built our Internal Memory Benchmark. Here's an example: Figure 4. An example test case from our Internal Memory Benchmark. In a past session, the user corrects the agent's choice of table and tells it to exclude background requests. Later, the agent faces a different but related question, and has to find that session among 100+ others and apply what it learned. The output is scored by an LLM judge based on a list of rubrics (some memory-dependent, some task-intrinsic). Our benchmark differs from existing ones in three ways: Enterprise domain. Existing benchmarks are open-ended chats about the lives of simulated personas. Ours is from real work in a data workspace, involving rich enterprise knowledge like table semantics, metric definitions, and workflows. Memory feeds actions, not answers. Finding the right string in past conversations is not enough; agents must apply retrieved knowledge to complete multi-step tasks. Diversity. Test cases span 5 memory types (profile, preferences, domain knowledge, projects, workflows) crossed with 11 scenarios (direct instruction, changing or outdated facts, multi-session aggregation, memory-independent questions, and more). Results We compare MemCurrent with three open-source memory backends, Mem0, PropMem, OpenClaw memory, using the same underlying LLM. Open-Source Benchmarks. We pair each memory backend with a simple question-answering agent, built with two agent harnesses (LangGraph and OpenAI Agents SDK). We also run two baselines: a floor with no memory, and a ceiling with full context, where every past session goes into the agent's context. Across all three benchmarks, MemCurrent scores highest among all memory backends and stays on the cost-accuracy Pareto frontier. On average, MemCurrent (88.1%) performs on par with full context (87.8%) at ~12x fewer input tokens per question (8.4K vs 103K). On the two benchmarks with the longest histories, it even beats full context, where dumping everything into the prompt ends up confusing the agent. Figure 5. Cost–accuracy1 trade-off of memory backends on (a) LoCoMo (19–32 sessions/sample), (b) LongMemEval (s split) (38–62 sessions/sample), and (c) ConvoMem (stratified subset of 500 samples, 100 sessions/sample). We use GPT 5.6 luna as the agent and memory model. All memory backends are run as a plugin, which automatically searches for related memories to the question and injects them into the agent context at session start.2 Accuracy is the mean over the LangGraph and OpenAI Agents SDK harnesses and 3 repeats. Cost is mean input tokens per question (log scale). Internal Memory Benchmark. On our benchmark, the gap widens. Here, each memory backend runs inside our internal Genie, the same agent the benchmark sessions came from. The histories are too long to fit in context, so our ceiling is gold injection: injecting only the gold memories into the agent's context. Among all memory backends, MemCurrent has the highest pass rate (68.4%) and the lowest latency (252s) and token usage (418K), closing over 80% of the gap between no memory (22.3%) and gold injection (78.6%). Notably, while Mem0 was also on frontier on earlier benchmarks, it trails at 43.9% here with higher latency and cost. Compared to no memory, MemCurrent triples the agent's pass rate (22.3% → 68.4%) while making it 1.35x faster and 1.44x cheaper. Figure 6. Pass rate, mean latency, and mean token usage per task on our Internal Memory Benchmark across 3 repeats. We use Claude Opus 4.6 as the agent model and GPT 5.6 sol as the memory model. All memory backends are provided as agent tools and a session-start plugin. MemCurrent in Action In addition to benchmark numbers, let's examine two examples of how MemCurrent helps in practice, from internal Genie sessions. Example 1: Memory stops an occasional hallucination mistake. In Figure 7, a user asked the agent for the top 20 users of Product X over the past two months. The agent wrote a correct SQL query, but never read the actual execution results saved to a file. It still confidently produced a table with hallucinated content. Upon user feedback, the agent saved the lesson to memory. Next time, once the query ran, the agent read the results first and returned the right table. One memory correction kept a one-off slip from becoming a habit. Figure 7. An anonymized example of how memory helps the agent avoid a repeated hallucination mistake. Example 2: Memory saves computation on related tasks. In Figure 8, a user asked for “the top 5 SDP customers”. The agent had to figure everything out from scratch: what “SDP” stands for, which tables held usage data, and how to join and filter them. It took 11 tool calls, 8 subagents, and nearly six minutes. The agent saved these steps as a workflow file in memory, which it could reuse on related tasks. Later, the user asked a different question: how many SDP customers had more than 5K pipeline runs last month. Using the workflow, the agent answered with 2 tool calls and 1 subagent in 41 seconds. The question was new, but the path to the answer wasn't, and memory let the agent skip unnecessary exploration. Figure 8. An anonymized example of how memory turns a 6 minute task into 41 seconds. What Makes MemCurrent Work To understand what accounts for MemCurrent's superior performance, we ran ablations on our Internal Memory Benchmark for two design choices: memory types and extraction strategy. Do we need both memory types? Episodic memory alone helps moderately: 35.8%, up from 22.3% with no memory. The raw history is useful, but the agent only searches it in about a third of test cases, though it passes 60% of those when it does. Derived memory avoids this issue, as the injected memory index at session start gives the agent information about what's available in memory and when to look, lifting pass rate to 66.1%. Adding episodic memory on top gives the best result, at 68.4%. The gain is small, but it suggests raw traces can recover details that distillation drops. Figure 9. Pass rate by memory type. What's a good memory extraction strategy? As shown in Figure 2, two channels extract derived memory: online tools and offline dreaming. When isolated, offline dreaming (63.5%) beats online tools (53.9%) by nearly 10 points. Their combination produces the highest pass rate at 66.1%. That supports a split of duties: dreaming handles background extraction and consolidation, while online tools make explicit requests take effect right away. Figure 10. Pass rate by extraction strategy. Conclusion Memory is how an agent stops starting from zero. In this post, we introduced MemCurrent, a memory architecture for production agents that combines episodic memo [truncated for AI cost control]