# Oracle 出品的 Agent 记忆课值得学，Oracle 可以不用

> DeepLearning.AI 这门短课讲的记忆管道设计适用于任何客户，Oracle 数据库层可以替换。

原文: https://fdetimes.net/zh/books-courses/deeplearning-ai-oracle-agent-memory-course/

DeepLearning.AI 上的 Agent Memory: Building Memory-Aware Agents 一开篇就点出一个问题，把 Agent 部署到生产环境的人都不陌生：大多数 Agent 在单个会话内表现不错，会话一结束就什么都忘了。用户只能把之前给过的指令再说一遍。

前线部署工程师（FDE）很少在演示中遇到这种故障。它往往出现在第二周：真实用户开始追问 Agent，为什么昨天告诉它的事今天就忘了。

这门课直击这个问题，但它是和一家卖数据库的公司合作做的。所以真正该问的是：哪些内容值得学，客户不用 Oracle 时又该略过哪些。

## 谁来讲，适合谁？

这是 DeepLearning.AI 与 Oracle 联合制作的短课。讲师是 Oracle AI 开发者体验总监 Richmond Alake 和 Oracle 首席数据科学布道师 Nacho Martínez。教材由厂商编写，使用的技术栈是 Oracle AI Database、LangChain 和由 LLM 驱动的管道。

这并不降低课程的价值，但观看时要带着“必须在客户基础设施上部署”的眼光。课程页面称，这门课面向已经构建过 Agent、希望突破单会话交互的开发者。前置要求只有 Python 和对 LLM 的基本了解，不需要 Oracle 相关知识。

## 七个视频，三个最关键

课程共 7 个视频。课程页面顶部标注的总时长是 2 小时 2 分钟，部分搜索结果显示为 1 小时 57 分钟。时长最长的三节课也是动手最多的，每节都附有示例代码：Memory Manager（22 分钟）、Memory Operations（23 分钟）和 Memory Aware Agent（20 分钟）。

建议按顺序学，因为最后一节是综合项目：一个能跨会话保留状态、启动后立即重新加载此前上下文的 Agent。如果只有一个晚上，就把大部分时间花在这三节代码课上，并且亲手敲一遍代码，不要只看。

## 观点一：记忆是基础设施，不是一段提示词

课程把自己的方法称为记忆工程：把长期记忆视为位于模型之外的核心基础设施。这一思路转变，比课程里任何一行代码都重要。

**要点:** Agent 的记忆是需要你设计的基础设施，不是模型自带的东西。

一旦把记忆当作基础设施，你就会开始像基础设施工程师那样提问：数据存在哪里，谁能读取，什么时候过期，出错时怎么纠正？客户的安全团队也会问你同样的问题。

## 观点二：记忆是一条管道，不是一条 insert 语句

课程明确的目标之一，是构建一个能处理多种记忆类型的 Memory Manager，并配套一条三步管道：提取、整合、写入。中间这一步最常被跳过。

设想一个内部支持 Agent。会话 1 中，用户说团队在用 Postgres；到了会话 3，用户说团队已经迁移到 Snowflake。

如果管道只提取事实、直接写入存储，Agent 就会同时保留这两条“事实”，还可能依据旧的那条作答。整合这一步必须识别出两条记录相互冲突，并更新旧记录，而不是再加一条。

下面是这一步的最简示意。它只是示例，并非课程中的代码：

```python
def consolidate(new_fact, store):
    # 查找同一用户、同一主题（例如“团队数据库”）下已有的记录
    old = store.find(user_id=new_fact.user_id, key=new_fact.key)
    if old is None:
        store.insert(new_fact)                      # 新信息：直接添加
    elif old.value != new_fact.value:
        store.update(old.id, value=new_fact.value)  # 用户改了主意：覆盖，不要追加
    # 与旧记录完全相同：跳过，避免重复
```

实际难点在于生成稳定的 `key`，让“我们用 Postgres”和“我们已迁移到 Snowflake”落在同一个主题下。到了客户现场，第一件事就是把几个类似这样的“改主意”场景写成测试，甚至要在选数据库之前。

## 观点三：工具列表也可以检索

有一节 17 分钟的课讲语义工具记忆，用来扩大 Agent 可用的工具数量。这是一种检索模式，适用于任何向量存储。

假设客户有几百个内部 API。把所有描述都塞进提示词既浪费 token，又容易让模型选错。更好的做法是为每个工具的描述生成嵌入，每一轮只传入与请求语义最接近的几个工具。

## 客户不用 Oracle 时该去掉什么

Oracle 专属的部分相当集中，都在 langchain-oracledb 包及其 OracleVS 向量存储中，python-oracledb 驱动会随之一起安装。只有混合检索需要 Oracle Database 26ai。客户不用 Oracle 时，要替换的就是这一层。

其余部分依然可用，这得益于 LangGraph 本身的组织方式。LangGraph 文档把短期的、线程范围的记忆与长期记忆分开，后者跨对话存储用户或应用相关的数据。

对于短期记忆，LangGraph 建议在生产环境中使用基于数据库的 checkpointer。长期记忆是一个单独的 store，但说到底也只是存储层。两层都可以跑在客户现有的数据库上。

所以在第一次需求调研会上，要问清客户用的是什么数据库、由谁管理。答案决定记忆管道部署在哪里，管道本身的设计不变。

## 如何把这项技能写进简历

阅读 FDE 岗位描述时，留意 stateful agent、long-term memory 或 multi-session 之类的字眼。看到它们，就要为面试准备一个具体案例：你是如何处理 Agent 在会话之间丢失上下文的。

结课证书说明不了太多。一个小仓库更有分量：在 Oracle 以外的数据库上重做那个综合项目，并为“改主意”场景配一套测试。它能向面试官证明，你能把理念和厂商分开，而这正是 FDE 每周都在做的事。

这门课教 Agent 如何记忆。至于这些记忆放在客户基础设施的哪个位置，仍然要由 FDE 来决定。

**本周动手试试:**

- 看完 Memory Manager、Memory Operations 和 Memory Aware Agent 三节课，然后用你正在使用的数据库代替 Oracle，重写其中的代码。
- 挑一个你构建过的 Agent，写下三个用户可能在会话 1 中提到、又在会话 3 中改变的事实，检查 Agent 是正确覆盖，还是只会堆积新记录。
- 阅读 LangGraph 的 Add memory 页面，然后把你的演示拆成两层：用基于数据库的 checkpointer 保存每个线程的状态，再用单独的 store 保存跨会话的长期记忆，两者都放在你现有的数据库上。

## 信源

- [✨ New course! Enroll in Agent Memory: Building Memory-Aware Agents](https://community.deeplearning.ai/t/new-course-enroll-in-agent-memory-building-memory-aware-agents/890523)

- [Agent Memory: Building Memory-Aware Agents - DeepLearning.AI](https://www.deeplearning.ai/short-courses/agent-memory-building-memory-aware-agents/)

- [Oracle AI Vector Search: Vector Store - LangChain docs](https://docs.langchain.com/oss/python/integrations/vectorstores/oracle)

- [Add memory - LangGraph docs (LangChain)](https://docs.langchain.com/oss/python/langgraph/add-memory)