当人说"Agent Memory"时，他们通常指的不是同一件事。Oracle 工程师 Richmond Alake 最近与 Angie Jones 的对话，把这个问题拆成了七种不同的记忆类型，每种都有 distinct 的存储、检索和失效策略。
七种记忆类型
1. 对话记忆（Conversational Memory）
最直观的类型：存储用户与助手之间的消息交换。问题是，大多数系统的实现方式只是不断把历史消息追加到提示里。这不是记忆工程，这是"不断提醒"。
真正的记忆系统需要决定：什么该存、存哪里、怎么检索、何时摘要、何时遗忘。
2. 语义记忆（Semantic Memory）
存储持久事实，应该超越具体对话而存在：
- 用户偏好 Python 而非 TypeScript
- 客服代理需要访问历史工单
- 生产系统每天处理 5 万次查询
向量搜索对此有用，因为检索不需要精确匹配原句，只需要语义相关。
3. 情景记忆（Episodic Memory）
存储事件——"发生了什么"：
- 代理搜索了最近的 API 网关模式
- 代理为工单 #4821 生成了回复草稿
- 工作流在合规审查步骤失败
对调试、审计和长周期工作流尤其重要。这通常是数据库查询问题，不只是向量搜索。
4. 程序记忆（Procedural Memory）
关于"如何做某事"：
- 调查失败部署时，先查日志，再查近期配置变更
- 起草客服回复时，包含工单摘要、可能原因、推荐修复和下一步
- 创建数据库感知代理时，扫描表注释、列注释、约束和近期工作负载模式
这种记忆帮助代理在混乱的真实环境中改进流程。
5. 实体记忆（Entity Memory）
关于特定人、账户、项目、系统或对象的事实：
- Angie 偏好实例而非抽象解释
- 客户 Acme Corp 有严格的数据驻留要求
- 工单 #4821 与账单对账问题相关
记忆安全在这里至关重要——代理不应意外混合不同用户或客户的记忆。
6. 工作记忆（Working Memory）
当前任务的短期草稿纸。不是所有临时信息都值得变成长期记忆。如果代理把每个临时想法都存为长期记忆，记忆库会迅速变噪。
7. 摘要记忆（Summary Memory）
解决上下文窗口限制。当对话过长时，压缩成紧凑表示：
用户正在构建 SaaS 客服代理。偏好 Python 和 FastAPI，部署在 OCI，希望代理检索历史工单后再起草回复。目前正在评估生产环境的记忆策略。
判断难题
记忆的核心难点不是存储，是判断：
- 什么该记住？ "我通常偏好 Python" vs "这次实验试试 Python"
- 何时更新？ 用户改变偏好了，旧记忆该删除、覆盖还是保留时间戳？
- 检索多少？ 太少遗漏关键上下文，太多让提示变噪
- 如何防止泄漏？ 跨用户/租户的记忆隔离
- 如何验证记忆是否有效？ 应减少重复提问、改善连续性、降低 token 消耗
Oracle AI Agent Memory Platform (OAMP)
Oracle 的做法是把 AI Database 26ai 作为代理的记忆核心，而不是拼接向量数据库、关系数据库、文档存储和自定义线程管理。
OAMP 提供：
- Users & Agents：界定记忆所有权
- Memories：持久事实和提取知识
- Threads：对话历史和连续性
- Context Cards：紧凑的、提示就绪的记忆检索
- Summaries：长对话的压缩表示
- Vector Search：语义召回
- Database-backed Persistence：记忆在重启后存活
关键洞察：Agent Memory 不只是向量搜索问题。有些记忆需要语义检索，有些需要有序读取或精确 SQL 过滤。数据库原生的记忆系统可以支持所有这些模式。
一个特别有趣的用例：用记忆教代理了解数据库。代理扫描数据库目录（ALL_TABLES、ALL_TAB_COLUMNS、ALL_TAB_COMMENTS 等），将技术细节转化为自然语言记忆。当用户问"哪里可以找到关于船舶和承运商的信息？"时，代理通过语义检索找到相关 schema 记忆。
这避免了一个常见陷阱：期望模型已经知道你的私有系统。它不知道。但你可以通过将系统元数据转化为记忆来教它。