Oracle Agent Memory作为面向长周期AI智能体的企业级记忆基座

# Oracle Agent Memory 作为长周期 AI 代理的企业级记忆基底
来源：https://arxiv.org/html/2607.13157

Richmond Alake, Cesare Bernardis, Paul Cayet, Luca Engel, Damien Hilloulin, Sungpack Hong, Allen Hosler, Nickolas Kavantzas, Ingo Kossyk, Son Le, Rhicheek Patra, Kartik Talamadupula, Valentin Venzin
Oracle

###### 摘要

对于长周期代理而言，代理记忆是一个系统性问题。实际部署需要在长时间对话中保留任务状态，跨会话恢复用户特定的事实和偏好，以及积累来自先前结果的过程性知识。这些需求超越了文档检索：一个记忆层必须决定哪些交互会转变为持久状态、该状态的范围如何界定、如何在延迟约束下进行检索，以及如何随时间对其进行修订或移除。本报告将 Oracle Agent Memory 作为一个基于 Oracle Database 构建的、以数据库为本源的记忆基底进行研究。讨论围绕三个主题展开：将记忆视为一个生命周期，涵盖摄取、提取、整合、检索、摘要以及修订或移除；一种分层架构，将主动记忆核心与被动记忆存储接口分离，并对用户、代理和线程进行显式的范围控制；以及一种评估方法，在该方法中，下游任务准确度由记忆中心度量（如证据检索、召回率、延迟和预估令牌使用量）进行补充。本报告总结了 LongMemEval 的结果（达到 93.8% 的准确率），将 Oracle Agent Memory 与扁平历史基线（使用约 10.7 倍更少的令牌）以及已发布或报告的现有外部基线进行了比较，并以包含设置、线程生命周期和搜索语义等面向实现的附录材料作为结尾。

## 1 引言

对于企业级代理而言，代理记忆已成为一个核心的系统性问题，因为大多数有用的部署都超越了一次有边界交互的范畴。代理会积累用户偏好、事实背景、中间计划和先前的执行痕迹。一个支持代理可能需要跨越数周的事件历史和特定于账户的偏好。一个编码代理可能需要跨越会话的先前设计决策、失败的实验和可复用的修复方案。一个分析或 NL2SQL 代理可能需要领域规则、重复出现的连接模式以及对模糊业务术语的澄清。因此，核心问题不仅仅是对话记录的召回，而是要在明确的范围、保留和检索约束下管理异构记忆。

这一需求改变了设计空间。一个记忆子系统必须同步对话历史和工具痕迹，从原始交互中提取持久的事实或准则，为后续轮次生成紧凑的短期上下文，在延迟约束下检索相关的先前证据，并强制执行跨用户、代理和对话的范围边界。该子系统还必须能够适应随时间的变化，因为事实可能变得陈旧，偏好可能改变，体验性记忆也会根据新的结果更新。因此，将记忆建模为一个有管理的生命周期，比将其视为单一的检索接口更为自然。

近期的调查研究支持了这一观点。智能代理系统中的记忆涵盖多种形式、功能和时态动态，不能简单地用短期与长期的二分法来充分描述 [Hu et al. (2025b](https://arxiv.org/html/2607.13157#bib.bib1)、 [Zhang et al. (2024)](https://arxiv.org/html/2607.13157#bib.bib2)。同时，实现仍然分散于虚拟上下文管理器、反思缓冲区、特定于记忆的服务、向量存储、图层和框架抽象之中 [Packer et al. (2024)](https://arxiv.org/html/2607.13157#bib.bib3)、 [Shinn et al. (2023)](https://arxiv.org/html/2607.13157#bib.bib5)、 [Chhikara et al. (2025)](https://arxiv.org/html/2607.13157#bib.bib18)、 [Rasmussen et al. (2025)](https://arxiv.org/html/2607.13157#bib.bib19)、 [Xu et al. (2025)](https://arxiv.org/html/2607.13157#bib.bib20)、 [Letta (2026)](https://arxiv.org/html/2607.13157#bib.bib27)、 [LangChain (2026)](https://arxiv.org/html/2607.13157#bib.bib28)。在企业环境中，这种碎片化使得治理、安全、数据本地性、可靠性以及与驱动代理循环的应用逻辑的集成变得复杂。

Oracle Agent Memory 的动机来自于观察到这些记忆需求与数据库需求高度一致。消息、摘要、事实、配置文件以及相关的记忆工件需要持久化、索引、范围感知检索，以及与结构化和半结构化企业数据的兼容性。Oracle Database 已经提供了关系型存储、JSON、向量、事务和运维控制。因此，本研究所关注的系统将数据库视为显式记忆层的基板，而不是嵌入向量的外部存储池。

本报告其余部分组织如下。第 2 节将记忆构建为一个生命周期，并介绍全文使用的分类法。第 3 节将 Oracle Agent Memory 置于先前的记忆系统和基准测试背景中。第 4 至 6 节描述了架构、集成工作流和代表性工作负载。第 7 和第 8 节审视了评估方法，包括当前基于 LongMemEval 的结果以及更广泛的如何衡量记忆子系统的问题。报告随后陈述了当前局限性，指出了未来工作，并得出结论。

## 2 记忆分类法与问题框架

我们围绕三个操作性类别来组织记忆问题，这些类别能很好地映射到更广泛的调研文献和先前的代理记忆系统 [Hu et al. (2025b)](https://arxiv.org/html/2607.13157#bib.bib1)、 [Zhang et al. (2024)](https://arxiv.org/html/2607.13157#bib.bib2)、 [Park et al. (2023)](https://arxiv.org/html/2607.13157#bib.bib4)、 [Shinn et al. (2023)](https://arxiv.org/html/2607.13157#bib.bib5)。

首先，**短期或工作记忆** 捕获任务的活跃状态：线程摘要、上下文卡片、未解决的子目标、近期动作，以及保持代理在长时间交互中连贯性所需的最小上下文状态。
其次，**长期事实记忆** 存储稳定信息，如用户偏好、已知事实、规则、类似配置文件的属性以及应跨会话保持可用的领域知识。
第三，**长期体验性或程序性记忆** 捕获从先前执行轨迹或反馈中学到的结果、策略、经验教训和指导原则。

这些类别在运行时存在显著差异。工作记忆高度动态，且与当前交互紧密耦合。它需要频繁刷新，保持足够紧凑以便注入提示，并且保留指导下一轮交互的信息，而非完整的对话轨迹。在 Oracle Agent Memory 中，这一角色主要由线程摘要和上下文卡片体现。

事实记忆具有不同的操作模式。事实和偏好可能源于特定的交互，但一旦提取出来，它们通常需要持久存在，超越其来源线程。像“用户偏好简洁的回答”或“该分析师使用与自定义日历对齐的财季”这样的陈述，会成为持久的上下文，必须保持可搜索性，可归属于正确的用户或代理，并且与检索和治理策略兼容。因此，事实记忆强调持久化、索引和范围感知查找，而非轮次级别的刷新。

程序性或体验性记忆提出了一个更困难的推理问题。仅存储事件是不够的；系统必须识别出应保留哪些经验教训、策略或指导原则。在 NL2SQL 工作流中，持久的工件可能是一个解释“平均支出”的规则，或是一个习得的偏好，即除非明确要求，否则排除零支出客户。在故障排查工作流中，它可能是一个补救路径解决了某类重复出现事件的证据。因此，程序性记忆依赖于提取、整合，以及在某些情况下对结果的反思，而非仅直接存储原始消息。

生命周期表述比静态类型层次结构更具信息量。在一个典型流程中，新消息或工具痕迹作为原始记录进入系统。这些记录可能触发候选记忆的提取。系统可能为短期使用摘要当前线程，将重复出现的证据整合到更长寿命的记忆中，对承载文本的记录进行索引以供语义检索，并在后期为新的任务检索或重组相关子集。随着时间的推移，随着证据的变化，记忆可能需要被编辑、合并、范围调整或移除。

这个生命周期暴露了几个系统性问题。第一个是**选择**：并非每条消息都应成为持久记忆。过度激进的提取会增加混乱、矛盾以及检索成本，而提取不足则会带来冷启动和重复澄清的问题。第二个是**表示**：有些记忆自然地存储为叙述文本，有些作为配置文件记录，有些作为消息历史，还有些作为更结构化或图结构化的工件。第三个是**范围**：一条记忆可能仅适用于一个线程内、一个用户的多个线程、服务于多个用户的代理，或者全局适用。第四个是**演化**：记忆可能变得陈旧，与新的证据冲突，或者在没有编辑和遗忘机制的情况下编码不受欢迎的反馈。

企业环境加剧了这些约束。记忆系统需要对业务数据进行受控访问，跨用户和代理边界的行为可预测，并对结构化、半结构化和向量化表示进行统一控制。它们还必须保持持久化与推理之间的区别。即使摘要或提取的记忆后来被修订，原始的线程消息仍然作为证据记录存在。

Oracle Agent Memory 通过结合用于主动记忆管理的线程级工作流和一个更广泛的存储抽象来满足这些需求，该抽象能够在共同的范围模型下容纳消息、记忆、配置文件和未来的工件。后续章节将始终使用这种生命周期视角。架构部分将研究系统如何支持记忆管理的每个阶段。工作流部分将研究线程操作、搜索和显式记忆插入如何映射到代理编排框架。评估部分则将下游的答案质量与记忆生命周期本身内的选择、持久化和检索质量区分开来。

## 3 相关工作与基准测试

### 3.1 语言代理中的记忆机制

近期的调查将语言代理系统中的记忆描述为一组机制，而非单一的持久化原语 [Hu et al. (2025b)](https://arxiv.org/html/2607.13157#bib.bib1)、 [Zhang et al. (2024)](https://arxiv.org/html/2607.13157#bib.bib2)。相关的设计空间包括用于维持局部连贯性的短期状态、用于事实和偏好的长期语义记忆、用于先前交互的情景记忆，以及源自先前结果的程序性记忆。这种框架与那些在即时模型上下文之外显式维护观察、计划、反思或检索到的证据的代理系统是一致的 [Park et al. (2023)](https://arxiv.org/html/2607.13157#bib.bib4)、 [Shinn et al. (2023)](https://arxiv.org/html/2607.13157#bib.bib5)、 [Packer et al. (2024)](https://arxiv.org/html/2607.13157#bib.bib3)。

几个有影响力的系统将记忆确立为代理循环的一部分。Generative Agents 维护一个关于观察的记忆流，根据相关性、近因性和重要性检索记忆，并使用反思从积累的经验中综合出更高级别的推断 [Park et al. (2023)](https://arxiv.org/html/2607.13157#bib.bib4)。Reflexion 将口头反馈存储在情景记忆缓冲区中，并重用它来改进后续试验，而无需更新模型权重 [Shinn et al. (2023)](https://arxiv.org/html/2607.13157#bib.bib5)。ReAct 和 Toolformer 并非狭义上的记忆系统，但它们阐明了更广泛的代理环境，在此环境中，记忆必须与工具使用、外部动作和迭代控制流程共存 [Yao et al. (2023)](https://arxiv.org/html/2607.13157#bib.bib6)、 [Schick et al. (2023)](https://arxiv.org/html/2607.13157#bib.bib7)。这些系统激励了一种记忆基底，它不仅存储原始对话：痕迹、结果、摘要和工具中介状态都可能成为后续检索的候选。

### 3.2 检索增强与非参数化记忆

代理记忆也建立在检索增强语言建模之上。RAG 将参数化的序列到序列模型与检索到的片段的密集非参数化记忆相结合，使检索成为生成的一等组件 [Lewis et al. (2020)](https://arxiv.org/html/2607.13157#bib.bib8)。Dense Passage Retrieval 表明，学习到的密集嵌入可以在大规模开放域问答中取代稀疏的词汇匹配 [Karpukhin et al. (2020)](https://arxiv.org/html/2607.13157#bib.bib9)。REALM 将检索集成到语言模型预训练中，而 RETRO 则使语言模型以检索到的来自大型语料库的块为条件 [Guu et al. (2020)](https://arxiv.org/html/2607.13157#bib.bib10)、 [Borgeaud et al. (2022)](https://arxiv.org/html/2607.13157#bib.bib11)。这些论文确立了许多记忆系统使用的核心机制：对承载文本的记录进行编码，搜索向量索引，并以检索到的证据为条件进行生成。

对话记忆在几个方面与文档 RAG 不同。存储的工件通常是推断出来的，而不是从规范文档中复制来的。它们的作用域限定于用户、线程、代理、租户或工作流，而非全局有效。随着偏好改变或新证据取代旧状态，它们可能会被修订。它们还包括派生的工件，如摘要、上下文卡片和反思。一个通用的检索流水线可以近似这些行为，但关于范围、生命周期和记录类型的一等概念减少了必须在检索器周围重建的应用程序特定策略的数量。

### 3.3 长上下文与虚拟上下文管理

长上下文建模是与外部记忆互补的，但并未消除对记忆管理的需求。诸如 Longformer 之类的架构通过稀疏注意力模式降低了处理长文档的成本 [Beltagy et al. (2020)](https://arxiv.org/html/2607.13157#bib.bib13)。然而，关于长上下文使用的实证工作表明，当相关证据出现在长输入的中部时，模型可能无法可靠地使用信息 [Liu et al. (2024)](https://arxiv.org/html/2607.13157#bib.bib12)。这个限制对代理记忆很重要，因为扁平的对话记录可能包含必要的事实，但将其呈现为模型难以利用的形式。MemGPT 通过虚拟上下文管理解决了同样的约束：模型在一个有边界的活跃上下文上操作，同时在工作上下文和更长寿命的存储层之间移动信息 [Packer et al. (2024)](https://arxiv.org/html/2607.13157#bib.bib3)。这种操作系统类比直接适用于企业代理记忆。目标不仅仅是最大化发送给模型的文本量；而是要决定哪些状态应该是活跃的、哪些状态应该被持久存储、以及为给定任务应检索哪些记录。

### 3.4 当代代理记忆系统

近期的记忆系统使这些想法更加明确。Mem0 提取、整合和检索突出的对话信息，包括用于关系记忆的基于图的变体 [Chhikara et al. (2025)](https://a