谷歌这门免费 Agent 工程课，把付费课“在地上摩擦”

最近谷歌放出了一门大约 72 分钟的 Agent 工程免费课，从“什么是 agent”一路讲到“多 agent 系统”，把整条链路铺满，而且配套代码全部开源、能直接跑。火山哥转发这门课时的评价很直接——它把市面上那些收费的 agent 课程按在地上摩擦。

这门课由多位谷歌工程师分段讲授，用的是谷歌自家的 ADK（Agent Development Kit，Agent 开发套件），模型跑在 gemini-3-flash-preview 上。它不玩概念堆砌，每一节都落到一段你能复制粘贴、adk run 就能跑起来的代码。下面按主题把它拆开讲。

一、从 Chatbot 到 Agent：不只是回答，而是决策 + 行动

课程第一句话就把 agent 和传统 chatbot 划清了界限：

"An agent is software that doesn't just answer — it can decide and take action."

agent 是那种“不只会回答、还能自己决策并采取行动”的软件。

区别在哪？传统 chatbot 接到问题就一次性吐出一段回答；而 agent 会先看你的请求、盘算需要哪几步，可能去调一个 API、跑一段代码、看看结果，再决定下一步做什么。

这套思路最清楚的出处，是那篇 ReAct（Reasoning + Acting） 论文。它的想法简单却有力：

"Language models shouldn't just generate text in one go — they can reason step by step, take an action like calling a tool or API, observe the results, and then decide what to do next."

语言模型不该一口气把文本生成完，而应该一步步推理、采取行动（比如调工具或 API）、观察结果，再决定下一步。

推理 → 行动 → 观察 → 调整，这个循环就是现代 agent 的地基。课程还把 agent 归成三种模式，帮你按问题选型：

就像订旅行，你不会随机买张机票，而是先定日期、再订酒店，按依赖顺序来——这就是规划型 agent 的用武之地。

二、用 ADK 构建第一个 Agent：几行代码就够了

课程给了 agent 一个更工程化的定义：

"An agent is an LLM with tools running in a loop to complete a task."

agent 就是一个带着工具、在循环里跑着去完成任务的 LLM。

ADK 帮你把“给 LLM 装工具、控制它循环、判断何时停手”这些样板代码全接管了。上手只要两步：去 AI Studio 拿一个 Gemini API key，然后 pip install google-adk（课程建议先装 uv、在虚拟环境里做）。建一个 agent 的代码少到出乎意料：

"That's all you need to write in order to create your first agent."

创建第一个 agent，你要写的就这么多。

从 google.adk.agents 导入 Agent，传几个参数就完事：model（这里用 gemini-3-flash-preview）、name、description，还有 instruction（也就是 system prompt）。然后 adk run first_agent 在终端里对话，或者 adk web 起一个本地网页界面——后者能看到完整的调用栈，调试时非常好用。

但光会聊天的 LLM 有个硬伤：它的知识有截止日期。你问它“现在几点、今天几号”，它要么不知道、要么瞎猜。解法是给它工具。课程写了个 get_current_time 函数，往 agent 的 tools 列表里一放，agent 就能拿到真实时间了：

"This allows us to extend the abilities of the large language model almost infinitely."

工具让我们几乎能无限扩展大模型的能力。

tools 是个列表，意味着你能塞多个工具。课程接着把内置的 google_search 工具挂上去（记得设 bypass_multiple_tools_limit=True，因为搜索常常要连着调好几次）——agent 一下子就能联网查实时信息了。

三、Agent 记忆三层架构：会话、数据库、语义记忆

这一节由软件工程师 Annie Wang 主讲，分成三集，把 agent 的记忆从“临时”一直讲到“跨越时间和媒介”。

第一层：短期记忆（session + state）

一个 session 就是一段连续对话，像手机上的一个聊天线程。ADK 默认用 InMemorySessionService，问题是——每开一个新 session，agent 就像第一次见你。课程演示了这个“失忆现场”：

"At turn two the user says 'perfect, plan day two,' but when we create a new session the agent starts over — it forgets everything."

第二轮用户说“很好，规划第二天”，可一旦新建 session，agent 就从头来过，把之前说的全忘了。

修复很简单：复用同一个 session。session 内部有两样东西——events（每条消息的完整“逐字稿”）和 state（像一张便利贴，存餐厅名、确认号这类要快速取用的值）。有一条铁律：不要在工具代码里直接改 session 对象，必须通过 context.state 写，这样 ADK 才会把变更记进 event log、之后才能持久化。

第二层：持久化记忆（database）

短期记忆像 RAM，一重启就没了。把 InMemorySessionService 换成 DatabaseSessionService，每条消息、每次回复、每次状态变更都写进数据库文件（或 Postgres 这类真数据库）。应用重启后，凭同一个 session id 就能接着聊。课程还加了一张小小的用户偏好表，配 recall/save 两个工具——哪怕下周开一个全新对话，agent 也记得你“是素食主义者”。

第三层：长期记忆（memory bank）

用 VertexAiMemoryBankService，它存到云端、支持语义检索：

"A search for 'two-wheeled vehicle' can find a note about a bicycle."

搜“两轮交通工具”，能命中一条关于“自行车”的笔记。

它能吞下整段会话、甚至图片/音频/视频，用 Gemini 抽取事实、生成 embedding。检索靠 preload_memory_tool——每一轮开口前自动跑语义搜索，把最相关的事实注入 prompt，agent 本身不用写任何特殊逻辑。

课程的 demo 很直观：你在一次对话里分享了一张历史建筑照片、一段海边视频、一条小镇语音，结束时用 add_session_to_memory 把整段会话喂进 memory bank，引擎自动抽出你喜欢历史建筑、享受海岸、去过那座小镇这些事实。隔些天开一个全新 session，你只问它根据之前分享的图片视频音频推荐个文化目的地，preload_memory_tool 先跑语义搜索、把这些事实注进 prompt，agent 立刻给出贴合的推荐——这就是跨媒介长期记忆在工作。

三层叠起来，你就有了一个跨天、跨周、跨媒介都记得你的个性化 agent。

四、Agent Loop 与长期运行代理：能跑几周的工作流

大多数 agent demo 是无状态的：你问、它答，对话结束，全程活在一个上下文窗口里，填满就丢。长期运行 agent 正相反：

"A long-running agent maintains its state across sessions and operates over hours, days, maybe even weeks. Your unit of work isn't a prompt — it's a workflow."

长期运行 agent 跨会话维持状态，运行数小时、数天甚至数周。它的工作单元不是一次 prompt，而是一整个工作流。

课程拿一个真实开源例子演示：新员工 Onboarding 协调 agent。它给新人发欢迎包，然后暂停好几天等对方签文件；签完再等硬件寄到；中间 IT 开通账号的活儿委派给专门的子 agent；最后生成第一天的日程。整个过程横跨很多天，agent 却从不丢上下文。

要让这套跑通，有三件事必须为真：

1. agent 能真正“睡着”——不能靠 active polling、不能有个线程干耗着，要能休眠到某个外部事件（webhook、定时、人工审批、工具回调）把它叫醒。
2. 每一步都有 checkpoint——状态在每次转移时都持久落盘，容器崩了、重新部署，agent 还能从原地精确续上，不会幻觉出中间步骤。
3. agent 不能给自己的活儿打分。

"When an agent evaluates its own output, it consistently overrates it."

agent 评价自己的产出时，总是持续高估。

这一点来自包括 Anthropic 在内多家实验室的研究，结论相当一致。所以业界的最佳实践是三 agent 分工：一个 planner 规划、一个 generator 生成、一个独立的 evaluator 去测真实结果。

课程还点出这套模式和普通 chatbot 的三点根本不同：一是持久状态是数据库里的 enum，而不是塞在某个向量库里的原始 JSON 聊天记录，所以闲置几周也不会 token 膨胀、上下文污染；二是事件驱动的休眠，两次暂停之间 agent 完全休息、不烧一点算力；三是多 agent 委派，协调 agent 要开账号时不自己硬扛，而是交给专门的子 agent，让每条推理链都保持干净。

课程还点了长期运行前常撞的三堵墙——上下文退化、缺少持久状态的原语、无法自我验证；以及让它变得可行的三大突破：agent harness（harness engineering，能规划/构建/评估，而不是一个 monolithic 循环）、持久记忆模式（把 living plan 当 markdown、把变更日志当“实验室笔记”，甚至跑 ralph loop）、以及托管基础设施（Gemini Enterprise Agent Platform 上的 sessions + memory bank）。三者一叠，你就从 chatbot 升级成了能在后台替你干活的东西。

五、MCP vs API：什么时候该用哪个

这一节把 MCP（Model Context Protocol，模型上下文协议） 讲透了。一句话抓本质：

"If you think of the agent as the brain, MCP is the wire that connects it to its hands and eyes."

如果 agent 是大脑，MCP 就是把它接到“手和眼睛”的那根线。

几十年来 API 是系统间的“通用握手”：定义端点、发请求、收响应，干净又可预测。可当大模型进场，一切变了——模型可能要一次性接触十个端点、把它们串起来、还要追问上下文。课程有个精准的比喻：

"An API is like a locked cabinet — you need to know exactly which drawer to open and what shape the key is. But a model is trying to understand what's inside the cabinet without clear labels."

API 像一个上锁的柜子，你得确切知道开哪个抽屉、钥匙什么形状；而模型是在没有清晰标签的情况下，试图搞懂柜子里有什么。

MCP 翻转了这个假设。它给模型一张活的、机器可读的能力地图：这个工具能做什么、要什么输入、返回什么，全都自描述。于是分野很清楚：

拿“管理支持工单”举例：接 Gmail、Notion、Jira，用 API 你得为每个集成写自定义代码、处理分页/鉴权/限流，还得用长长的 prompt 教模型。而 MCP 下，每个服务暴露一个 MCP 接口，模型自动发现这些工具、自己推理该用哪个——等于给它一个工具箱，而不是逼它背下每把工具怎么用。

关键澄清：MCP 不是要取代 API。

"MCP doesn't replace your back end — it replaces the middleware between the model and the API. APIs are not dead; they are just evolving."

MCP 取代的不是你的后端，而是模型和 API 之间的中间层。API 没死，只是在进化。

就像当年 HTTP 统一了互联网，MCP 想为 AI agent 做同一件事：你把连接器写一次，任何兼容的模型都能立刻用上。当然它还早，挑战在于生态采纳、安全权限，以及开发者从“端点思维”转向“能力思维”的心智转变。

六、多 Agent 系统：一个 root agent 指挥一群专才

单个塞满工具的 agent 会遇到天花板，课程的答案是多 agent 系统——把复杂任务拆给一群各司其职的专才。

第一个例子是博客写作 agent，架构是经典的 Conductor / Planner / Writer：root agent（叫 blogger，相当于 Conductor）拿到主题后，先调 planner 工具生成大纲、再调 writer 工具写正文，最后补三个备选标题和两条推文式钩子。而 planner 和 writer 各自是 LLM agent，被包在 loop agent（ADK 里的 workflow agent）里：

"The loop agents handle retries automatically if validation fails."

校验不通过时，loop agent 会自动重试。

每个 loop 里配一个校验器：大纲有没有标题、intro、四到六个小节、结论？合格回 OK，不合格回 retry 并说明问题，最多重试三次。最妙的是把整个 loop 当成工具暴露给 root agent——root agent 直接调用，完全不用管里面发生了什么。这就是 agents-as-tools（agent 即工具） 模式。

第二个例子更能体现威力：一个 researcher agent 当编排者（orchestrator），手里握着两个 agent 工具——search agent 负责联网找信息，url-verifier agent 负责逐条抓取网页、确认信息真假（因为 LLM 会编造 URL）。这其实就是 LLM-as-judge（用 LLM 当裁判）：把一个模型的产出，喂给另一个装了验证工具的模型去核实。为什么要这么拆？

"By giving each agent a very specific task, you get better management of its performance, its memory, and its cost — and each agent can be powered by a different model."

给每个 agent 一个非常具体的任务，你就能更好地管理它的表现、记忆和成本——而且每个 agent 可以用不同的模型驱动。

简单任务用便宜快的模型，复杂推理用更强更贵的模型。多 agent 系统给你的，是对“任务确定性、成本、性能”三者的精细控制——这是单 agent 堆一堆工具永远给不了的。

七、总结：60 多分钟的密度，直接动手

这门课的信息密度，真的对得起“把付费课在地上摩擦”这句评价。它从 agent 的定义讲到 ReAct 循环，从几行 ADK 代码讲到记忆三层、长期运行工作流、MCP 协议，最后落到多 agent 编排——每一节都有能跑的代码，配套文章和仓库全部开源。

如果你只想记住一件事：agent 不是“更会聊天的 chatbot”，而是带着工具、在循环里推理和行动、还能记住过去的软件。想真正搞懂它，最好的方式不是再看一篇综述，而是打开 adk.dev，把课程里的代码亲手跑一遍。

本文基于谷歌 Agent 工程免费课（约 72 分钟，多位谷歌工程师讲授，ADK + gemini-3-flash-preview）的 ASR 转录整理，做了结构化编排并尽量保留工程师原话。火山哥推荐推文：@huoshan007；原始线程：@0xCodez。上手入口：adk.dev。