大家好，我是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 在下一次与你对话时，能“记起”你是谁，你喜欢什么。
本讲我们将同时实践这两种记忆：用 session 来解决我们开篇提出的“多城市天气比较”问题，再用 memory 来实现一个更酷的功能——让 Agent “记住”你的常用城市。