【Google ADK 实战】04 session 与 memory：让你的 Agent 拥有记忆

原创于 2025-11-27 08:01:12 发布 · 230 阅读

4 ·

CC 4.0 BY-SA版权

大家好，我是Tony Bai。

欢迎来到我们的专栏《Google ADK 实战：用 Go 构建可靠的 AI Agent》的第四讲。

在上一讲中，我们成功地为 Agent “插上了手臂”，构建了一个能调用 Go 函数查询实时天气的天气助手。它能准确地回答“北京天气怎么样？”。但很快，我们就会发现它的一个“致命缺陷”——它有严重的健忘症。

让我们把挑战升级。想象一下，我们希望这个助手不仅仅是一个“查询工具”，更是一个能帮助我们做决策的“旅行规划助理”。

试想一下这段对话：

你: 我在考虑下周去旅行，帮我看看北京的天气怎么样？ Agent: (调用工具) 北京下周天气晴朗，温度适宜。你:听起来不错。再帮我看看上海的天气。 Agent: (调用工具) 上海下周可能会有阵雨。你: 嗯... 那深圳呢？ Agent:(调用工具) 深圳下周天气也很好，阳光明媚。你: 好了，综合来看，哪个城市最适合我去？

面对最后一个问题，我们上一讲的 Agent 会彻底“卡壳”。为什么？因为它虽然能查询每个城市的天气，但它完全不记得之前的查询结果。每一次查询都是独立的、一次性的操作。当被要求“综合来看”时，它的“记忆”是空白的，根本无从比起。

这个问题，暴露了我们 Agent 的一个“致命缺陷”。它缺乏在一次对话中积累和持有信息的能力。

要解决这个“健忘症”，就必须为 Agent 引入记忆系统。这正是我们这一讲的核心议题。学完这一讲，你将能够：

区分 session 和 memory，理解 ADK 中短期记忆和长期记忆的设计哲学。
掌握 tool.Context.State() 和 SearchMemory()，学会通过这两个核心 API 在对话中读写短期和长期记忆。
升级我们的天气助手，让它能够记录和比较多次查询结果，并能“记住”你跨会话的偏好。

准备好为你的 Agent 安装“海马体”，让它从一个简单的“查询工具”进化成一个真正的“助理”了吗？让我们开始吧。

短期记忆 vs. 长期记忆：`session` 与 `memory`

在 ADK 的设计中，记忆被清晰地划分为两个层次，这对于我们理解和构建复杂的 Agent 至关重要。你可以用一个简单的比喻来理解它们：

session.Service (短期记忆 - RAM):
- 作用域： 单次完整的对话（从开始到结束），由 SessionID 标识。
- 特点： 速度快，易于访问，用于存储当前对话的上下文信息。
- 用途： 存储用户本轮对话中提到的实体（城市名）、临时的计算结果（天气对比列表）、当前的对话状态等。它保证了 Agent 在一次连续的交互中，是“有记忆”和“连贯”的。
memory.Service (长期记忆 - Hard Drive):
- 作用域： 跨越多次对话，通常与一个 UserID 绑定。
- 特点： 持久化存储，用于知识的沉淀和积累。它允许 Agent “记住”过去与某个用户的所有交互精华。
- 用途： 存储用户的偏好（“我最喜欢的城市是北京”）、历史交互的关键信息（用户过去经常查询的城市）、Agent 通过学习获得的知识等。这让 Agent 在下一次与你对话时，能“记起”你是谁，你喜欢什么。