从上下文到持久化记忆的范式转变
Oracle AI数据库开发者倡导者Anders Swanson指出，构建Agent记忆不应仅视为功能堆砌，而应作为系统工程问题来处理。当前许多开发者在使用Claude Code或Codex等Agent时，常观察到它们反复阅读相同文件或重复执行查询。这种现象的根本原因在于上下文窗口并非记忆。Swanson强调，"Context windows are not memory. They're the input for the current run and not a persistent experience." 上下文窗口仅是当前运行的输入，缺乏对过去经验的持久化记录。以客服工单处理为例，Agent在单次会话中可能完成了文档阅读、故障复现及根因分析等有价值的工作，但一旦会话结束，这些合成出的有用程序（useful procedure）便会被丢弃。当另一个Agent接手类似任务时，必须重新搜索文档和运行查询，这不仅增加了失败机会（opportunity for failure）和幻觉风险，还降低了最终结果的保真度。因此，记忆的建立始于将这些有用经验转化为受管状态（managed state）。
传统工作流的局限与数据库的必要性
针对记忆存储，扩大上下文窗口并非解决方案。随着会话变长并触发压缩机制，Agent真正需要的有用信号（useful signal）往往淹没在大量无关信息中。虽然Markdown文件、Wiki或提示词工程等"草稿纸（scratch pads）"方法能作为变通手段，但它们无法提供治理性检索（governed recall）。在大型多租户环境中，文件层级结构难以扩展；而像grep这样的工具虽然擅长查找数据，却缺乏复杂混合检索（complex hybrid retrieval）能力。Swanson指出，"If we continue to the logical conclusion of trying to build a memory layer on top of files, we're going to be building our own database." 既然最终仍需构建数据库功能，不如直接使用成熟的数据库系统。基于与客户的合作经验，现代Agent记忆系统的收敛模式呈现出四个核心环节：记忆形成（memory formation）、记忆检索（memory recall）、演进与评估（evolution and evaluation）。其中，记忆形成并非原始转录数据的堆砌，而是提炼出的结构化事实（structured facts）。
混合检索与记忆的生命周期管理
在记忆检索方面，混合检索（hybrid retrieval）正成为主导方法。它融合了多种搜索类型：向量相似度搜索、词汇搜索、基于关系对象的实体搜索、图遍历，以及针对时间数据（如近期性）和反馈信号的分析。此外，系统必须具备整合能力（consolidation）以解决重复记忆和冲突，确保记忆随时间演进而非变得陈旧无用。Swanson强调："Memories need element of temporality. So, when was this created? When was it accessed? How long is it valid for?" 记忆必须包含时间维度，且需通过定期反馈和评估来维持有效性。在治理控制方面，涉及秘密和个人信息（secrets, personal information）的数据需在进入记忆层前进行脱敏，权限需针对Agent、工作流或用户进行细粒度划分。在多租户环境中，还需具备管理员审批及抑制陈旧或中毒数据的能力。
记忆循环架构与多模型数据库选型
完整的"记忆循环（memory loop）"包含：Agent会话工作 -> 创建事实 -> 脱敏与丰富化（redacting, enriching） -> 存储至持久层。后续会话可通过检索这些事实进行上下文卡片重建（context card reconstruction），从而降低下一个Agent的工作量。若使用成功，系统会添加反馈评分（feedback scores）以适配时间变化和数据关联。从架构上看，记忆层作为函数被Agent运行时调用（通过hooks、MCP或skills等接口），暴露读写及反馈API，并与存储平台交互。Swanson推荐多模型数据库（multi-model databases）作为底层支撑，因为它允许在单一位置处理行、列、向量嵌入、全文搜索、关系实体和图数据。"Your memory can live in a consolidated place with one database query connection." 这种架构支持复杂的混合搜索并返回数据。
基于人类认知模型的记忆分类与存储模式
记忆对象应被类型化（typed），借鉴人类记忆模型可分为四类：情景记忆（episodic memory）记录Agent工作的具体过去事件或转录片段；语义记忆（semantic memory）存储关于工作流、用户偏好及实体的具体事实；程序性记忆（procedural memory）包含可重复使用的规则或例程，如构建步骤；以及工作状态（working state）作为短期记忆，记录当前正在处理的内容。Swanson指出："Working state is like short-term memory... temporal data may only be valid for a certain time window and we may promote it to a different type of memory." 这种分类有助于应用不同的搜索技术。在存储模式上，记忆表现为类型化对象（typed objects）加上查找路径，每个记忆对象包含ID、内容及相关元数据。
构建多维度的记忆存储架构
在AI Agent的记忆层设计中，单个记忆单元不应仅是文本的简单堆砌，而应被视为一个包含多种索引维度的结构化对象。理想的存储模式需要为每条记忆建立主键（Primary Key），并整合文本内容、JSON标签及文档数据。为了支持高效的语义理解，系统必须为内容生成向量嵌入（Vector Embedding）并建立索引以进行相似度搜索；同时，为了弥补纯语义检索在精确匹配上的不足，还应保留全文关键词索引（Text Index）以实现混合搜索能力。此外，记忆之间并非孤立存在，而是通过实体图（Entity Graph）中的边进行连接，形成“记忆A关联记忆B”的网状结构。这种图关系使得系统在检索阶段能够回溯额外的上下文信息，从而构建更完整的认知背景。
除了语义和关系维度，记忆存储还必须包含时间事实（Temporal Facts）与审计日志。系统需记录每条记忆的有效期、最后使用时间以及创建者信息，明确“谁在何时因何目的使用了该记忆”。这些审计事件和关联元数据应作为存储模式的核心组成部分。Anders Swanson强调，良好的记忆是有意形成的（Good memories are very intentional），因此在创建阶段就需要明确其生命周期、作用范围及关系定义。这种结构化的设计确保了记忆不仅可被检索，而且具备清晰的溯源性和安全性基础。
记忆创建的生命周期与清洗流程
当Agent运行时决定生成一条新记忆时，必须遵循严格且有序的处理流水线。首要步骤是数据脱敏（Redaction），这是防止灾难性后果的关键防线。在生成嵌入向量或进行任何丰富化处理之前，必须先剥离个人身份信息（PII）、密钥及其他无关敏感信息。>
记忆管理的核心挑战：过度召回、无关性与数据泄漏
随着记忆系统的规模扩大，管理问题与搜索算法调优成为关键瓶颈。当系统盲目地将所有数据写入记忆库时，会出现“过度召回”（Over Recall）现象：大量弱匹配项挤占了上下文卡片的空间，这与试图将海量数据强行塞入超大上下文窗口导致的混乱如出一辙。语义相近但实际与任务无关的记忆可能在混合搜索中排名靠前，造成“无关性”（Irrelevance）问题。此外，“数据泄漏”指意外进入记忆系统的异常数据，这是比“中毒记忆”较轻但同样需要警惕的问题。解决这些问题的关键在于对记忆记录进行适当的丰富与蒸馏。当系统从数千条增长到数万甚至百万级时，会出现“静默漂移”（Silent Drift），即系统表现从优秀急剧恶化。因此，必须在写入前进行缩减处理、范围检查审查以及生命周期管理。
结论
视频论证表明，Agent记忆不应依赖上下文窗口或文件草稿纸，而必须构建基于多模型数据库的系统工程层。其核心优势在于通过混合检索、类型化对象及严格的生命周期管理，实现从临时上下文到持久化受管状态的范式转变。该架构能有效解决重复劳动、幻觉风险及数据治理难题，支持复杂场景下的精准召回与审计。然而，系统面临过度召回、无关性排序及数据泄漏等挑战，需依赖脱敏、蒸馏和定期评估来维持有效性。最终结论是：只有将记忆视为有意形成的结构化事实，并整合向量、全文及图关系等多维索引，才能构建可扩展且安全的Agent记忆闭环。