过去两年，大模型最常见的使用方式还是“你问一句，它答一句”。但真正值得关注的变化，不是模型越来越会聊天，而是它开始能够调用工具、读取结果、持续决策，并把一件事情真正做完。
这正是 AI Agent（智能体）与普通聊天机器人的分界线。
Google 官方发布了一套 AI Agent 系列教程，从 Agent 的基础概念讲到如何使用 ADK（Agent Development Kit，智能体开发工具包）构建多 Agent 系统，还系统介绍了记忆、长期运行和 MCP 等关键能力。
本文根据这套视频内容整理。相比逐集复述，我们更关心一条主线：当大模型从“生成答案”走向“完成任务”，软件应该如何重新设计？
一、Agent 到底是什么？一句话概括：
Agent 不只是回答问题，而是能够围绕目标做出决策并采取行动的软件。
传统聊天机器人的典型流程很简单：接收问题，生成答案，任务结束。
Agent 的工作方式则更像一个执行者：
接收用户目标；判断完成目标需要哪些步骤； 调用 API、运行代码或访问外部工具； 观察执行结果；根据结果调整下一步动作，直到任务完成。例如，用户说“帮我安排一次旅行”，普通聊天机器人可能给出一份行程建议；Agent 则可能进一步搜索航班、筛选酒店、检查时间冲突，并在需要付款或确认时暂停，等待用户决策。
两者的差异，不只是回答质量，而是系统边界发生了变化：聊天机器人交付的是内容，Agent 交付的是结果。
Agent 的基本循环：推理、行动、观察、调整现代 Agent 的核心思想通常可以用 ReAct（Reasoning + Acting）来理解：
推理（Reasoning）：分析当前目标和已有信息；行动（Acting）：选择并调用工具；观察（Observing）：读取工具返回的结果；调整（Adjusting）：判断是否继续、重试或改变方案。这个循环让模型不必在第一次回答时就“猜出”完整答案。它可以先做一步、看结果，再决定下一步。
按照决策方式，教程将 Agent 概括为三类：
类型工作方式适用场景 顺序型按固定步骤依次执行简单、稳定、可预测的流程反应型根据当前环境即时决策状态频繁变化的动态任务规划型先拆解目标，再按依赖关系执行旅行预订等复杂多步骤任务
这三类并不互斥。真实系统往往会组合使用：大框架由顺序流程保证稳定，局部节点允许 Agent 动态判断，复杂任务再加入规划能力。
二、用 ADK 构建一个真正可用的写作 Agent理解 Agent 最直接的方式，是看它如何完成一项具体工作。
Google 在教程中使用 ADK 构建了一个博客写作系统。它没有让一个模型从头写到尾，而是把任务拆成“规划、验证、写作、再验证”四个环节：

Root Agent（总控）
├── Blog Planner（生成大纲）
├── Outline Validation Checker（检查大纲）
├── Blog Writer（撰写正文）
└── Blog Post Validation Checker（检查成稿）其中，Root Agent 只负责接收主题和协调流程。Planner 先生成包含标题、引言、正文结构和结论的大纲；Checker 检查大纲是否完整，如果不合格，就带着具体问题返回重试。大纲通过后，Writer 再写出完整文章，最后由另一个 Checker 检查文章是否符合大纲、解释是否清晰、结构是否完整。
这套设计有两个值得注意的地方。
1. 把开放式创作变成可检查的流程“写一篇文章”是一个模糊目标，模型很容易漏掉关键部分。将任务拆成大纲、正文和验证后，每一步都有明确输入和输出，失败也更容易定位。
ADK 中的 Loop Agent 可以把“生成—检查—重试”封装成循环，并设置最多重试次数。它解决的不是模型能不能写，而是系统如何控制质量。
2. 用共享状态连接不同 AgentPlanner 生成的大纲会写入 blog_outline，Writer 从共享状态中读取它；成稿再写入 blog_post，供后续检查和输出使用。
这意味着多个 Agent 不是靠反复复制整段对话来协作，而是通过结构化状态交接结果。任务越复杂，这种设计越重要。
教程还介绍了 ADK 中的三种主要 Agent 形式：
LLM Agent：由大模型驱动，适合规划、写作、判断等开放任务； Loop Agent：负责循环、验证和重试等工作流控制；Custom Agent：通过继承基础类实现更定制化的逻辑。从这个案例可以看出，多 Agent 的价值并不在于“多叫几个模型一起讨论”，而在于明确分工、限制职责和建立检查点。
三、没有记忆，Agent 就无法真正连续工作如果 Agent 每次对话都像第一次见面，它就很难处理持续性任务。
Google 用三集教程解释了 Agent 的记忆体系。它不是一个单独的“记忆开关”，而是从当前对话、持久化状态到长期语义检索的三层结构。
第一层：Session 与 State，保存当前任务上下文Session 可以理解为一个对话线程，其中包含两类信息：
Events（事件）：用户消息、Agent 回复以及图片等媒体输入的完整记录；State（状态）：餐厅名、确认号、当前步骤等结构化关键值。Events 让 Agent 能回顾发生过什么，State 则像一张随手可查的便签。为了找到一个确认号，让模型每次扫描十几轮历史消息，既慢又浪费上下文；把它写入状态后，下游 Agent 可以直接读取。
教程特别提醒，不要直接修改 Session 对象，而应通过 ADK 提供的 Context 或 State 接口写入。原因很简单：记忆不只是一个变量，还需要被记录、持久化和恢复。
第二层：持久化 Session 与用户画像内存中的 Session Service 适合本地测试，但程序重启后数据就会丢失。将它换成数据库或云端 Session Service 后，Agent 逻辑不需要重写，之前的对话却可以恢复。
但恢复对话仍然不等于真正理解用户。
当用户开启一个新 Session 时，旧聊天记录不会自动出现。因此教程又加入了 User Profile（用户画像）：用 user_id 和偏好键值保存饮食习惯、常用交通方式等长期稳定信息。
Agent 在对话开始时先读取偏好，在规划任务时使用它；发现新的稳定偏好后，再询问并保存。这样，用户不必在每次新对话中重新介绍自己。
第三层：Memory Bank，支持跨对话语义召回用户画像适合保存明确、结构化的偏好，但真实信息往往隐藏在长对话和多媒体中。
Memory Bank 扮演的是长期“文件柜”：它可以归档完整对话，从文字、图片、视频或音频中提取事实，并通过 Embedding（向量嵌入）支持语义搜索。
例如，用户曾在另一次对话中分享过历史建筑照片和海边视频。几周后，他只说“根据我以前分享的内容推荐一个文化旅行目的地”，预加载工具就可以搜索 Memory Bank，将“喜欢历史建筑”“享受海边”等相关事实放回当前上下文。
三层记忆解决的是三个不同问题：
层级解决的问题 Session + State当前对话进行到哪里、关键变量是什么持久化 Session + User Profile程序重启后如何恢复、跨新对话如何个性化Memory Bank如何从长期历史和多媒体中按语义召回信息
把所有信息都塞进一段越来越长的 Prompt，并不是真正的记忆。可靠的 Agent 需要区分对话记录、结构化状态和长期知识，并为它们选择不同的存储与检索方式。
四、Agent 如何把一项任务持续几天甚至几周？许多有价值的业务流程无法在一次对话中结束。
员工入职就是教程中的一个例子：发送欢迎包、等待签名、配置 IT 权限、交付硬件、生成第一天日程。步骤之间可能相隔数天，还会遇到人工审批、Webhook 回调和系统中断。
如果 Agent 只能依赖当前上下文持续“在线等待”，这个流程既昂贵又脆弱。因此，长期运行的 Agent 需要三项基础能力。
1. 持久化状态，而不是保留一段无限增长的聊天记录教程建议把任务阶段设计成数据库中的明确状态，例如：

WELCOME_SENT → SIGNED → IT_READY → HARDWARE_DELIVERED → DAY1_READY每次状态转换都被持久化。即使容器崩溃或服务重新部署，系统也能从最近的检查点恢复，而不是要求模型重新阅读所有历史记录并猜测进度。
2. 事件驱动休眠，而不是持续轮询Agent 等待签名时应该彻底休眠，不占用计算资源。签名 Webhook、定时任务、人工审批或工具回调到达后，再唤醒流程继续执行。
这里的工作单元已经不再是一次 Prompt，而是一个可以暂停、恢复和跨越多天的 Workflow（工作流）。
3. 让独立角色负责评估教程推荐将复杂任务拆成三类角色：
Planner（规划） → Generator（执行） → Evaluator（独立验证）关键点是，不让执行者单独给自己的结果打分。规划、生成和验证彼此分离，系统才能在每个关键节点建立真正的质量控制。
这也解释了为什么生产级 Agent 更像“带有 AI 决策能力的状态机”，而不是一个永远不关闭的聊天窗口。
五、MCP：让 Agent 以统一方式使用外部工具Agent 要采取行动，就必须连接搜索、数据库、文件系统和各种业务 API。问题在于，每接入一个工具都手写一套适配代码，很快就会形成新的集成泥潭。
MCP（Model Context Protocol，模型上下文协议）试图解决这个问题。
可以把它简单理解为：
Agent 是大脑，外部工具是手和眼睛，MCP 是两者之间统一的连接方式。
MCP Server 会向 Agent 描述自己有哪些工具、每个工具需要哪些参数、会返回什么格式。Agent 可以在运行时发现这些能力，再按统一协议调用。
Agent ←→ MCP ←→ 外部工具或现有 API教程将它的价值归纳为四点：
隔离性：工具在独立进程中运行，单个工具失败不必拖垮 Agent；互操作性：工具可以使用 Python、Go 或 Node.js 等不同语言实现；可发现性：工具通过 Schema 自我描述，模型可以动态理解如何调用；可扩展性：添加、替换和升级工具时，不需要重写 Agent 的核心逻辑。在演示中，博客 Agent 接入了 Google Trends MCP Server。服务端将已有函数包装成工具，注册“列出工具”和“调用工具”两个处理器；Agent 端只需把 MCP 工具集加入 Root Agent，调用方式就和本地函数基本一致。
MCP 会替代 API 吗？不会。
API 仍然承担业务逻辑和数据访问，MCP 位于模型与 API 之间，把现有能力翻译成模型可以发现和调用的形式。
维度APIMCP 主要对象程序与程序模型与外部环境使用方式开发者预先知道端点和参数模型根据 Schema 发现并调用能力核心角色代码级接口面向模型的标准协议
因此，MCP 替代的更接近过去为每个模型和 API 手写的中间适配层，而不是 API 本身。
当然，统一协议也带来新的问题：谁有权调用工具、可以读写哪些数据、认证信息如何管理、危险操作如何审批。这些权限边界不是附加功能，而是 Agent 真正进入生产环境的前提。
六、Google 这套教程真正讲清楚了什么？从博客写作、记忆、长期任务到 MCP，看似是几个独立主题，实际上都指向同一个结论：
构建 Agent 的重点，正在从“选择一个更强的模型”，转向“设计一个更可靠的系统”。
模型负责理解、生成和判断，但仅靠模型无法解决以下问题：
任务如何拆解，步骤之间如何交接；结果不合格时，谁来检查和重试；对话结束后，状态和用户偏好如何保留；等待数天的任务如何暂停和恢复；外部工具如何被发现、调用和限制权限；服务中断后，流程如何从准确位置继续。这些问题的答案，来自传统软件工程中的状态机、数据库、事件驱动、权限控制和可观测性，再叠加大模型擅长的推理与生成能力。
这也是理解 Agent 最重要的视角：它不是给聊天机器人多装几个工具，也不是让多个模型在群里互相讨论。它是一种新的软件组织方式——确定性的工作流负责边界和秩序，大模型负责处理其中开放、模糊、需要判断的部分。
结语Google 的 AI Agent 系列教程给出了一条较完整的学习路径：
从 ReAct 循环理解 Agent 如何推理和行动； 用 ADK 将复杂任务拆成多个职责单一的 Agent； 用 Session、State、用户画像和 Memory Bank 建立分层记忆； 用持久化状态与事件驱动机制支持长期任务； 用 MCP 统一连接外部工具和现有 API。如果只想做一个演示，让模型调用一次工具就够了；如果希望 Agent 真正进入业务流程，就必须继续回答四个问题：状态放在哪里、失败如何恢复、结果由谁验证、权限如何约束。
模型决定了 Agent 能做什么，系统设计决定了它是否值得信任。
内容来源说明：本文根据 Google 官方 AI Agent 系列教程视频，我和 Marvis 共同整理，并对原视频中的多个主题重新编排。ADK 相关代码与资料可参考 Google ADK 官方 GitHub 仓库[1]。
Tip
专注于 AI 智能体实践与技术演进深度思考。主理人拥有资深技术背景与心理学视角，致力于通过真实实验（2025年更新361篇实操记录）探索 LLM、RAG 与 Agentic Workflow 的落地边界。
引用链接[1] Google ADK 官方 GitHub 仓库: https://github.com/google/adk