LLM - Google 5-Day AI Agents Intensive

文章目录

[从大模型到 AI Agent：以 Google 5-Day AI Agents Intensive 为例看架构与趋势](#从大模型到 AI Agent：以 Google 5-Day AI Agents Intensive 为例看架构与趋势)
- 引言：从「会聊天」到「会干活」
- [什么是 AI Agent：解决的真实问题](#什么是 AI Agent：解决的真实问题)
- - 超越「智能聊天」的系统能力
  - [Google 的定义视角：课程里的 Agent](#Google 的定义视角：课程里的 Agent)
- [典型 Agent 架构：从四个核心组件拆解](#典型 Agent 架构：从四个核心组件拆解)
- - 架构基本要素
  - [与 Google 课程模块的映射](#与 Google 课程模块的映射)
- [Google 生态中的 Agent 技术栈概览](#Google 生态中的 Agent 技术栈概览)
- - 技术栈要素一览
  - [「从 Prompt 到 Agent」的心智转变](#「从 Prompt 到 Agent」的心智转变)
- [从零到一：一个最小可用 Agent 的设计思路（伪代码）](#从零到一：一个最小可用 Agent 的设计思路（伪代码）)
- - [目标：任务管理 Agent](#目标：任务管理 Agent)
  - 核心设计要点
- [记忆系统与上下文管理：让 Agent 不再「金鱼记忆」](#记忆系统与上下文管理：让 Agent 不再「金鱼记忆」)
- - 短期与长期记忆的边界
  - [Agentic RAG 与 Memory 的结合](#Agentic RAG 与 Memory 的结合)
- [多 Agent 系统：从单点智能到协同智能](#多 Agent 系统：从单点智能到协同智能)
- - [多 Agent 协作模式](#多 Agent 协作模式)
  - [多 Agent 的收益与代价](#多 Agent 的收益与代价)
- [2025 年 Agentic AI 的关键趋势（含 Google 视角）](#2025 年 Agentic AI 的关键趋势（含 Google 视角）)
- - 行业趋势概览
  - [Google 在趋势中的定位](#Google 在趋势中的定位)
- [面向开发者的学习与实践路径（基于 Google 课程）](#面向开发者的学习与实践路径（基于 Google 课程）)
- - 一条可行的学习路线
  - 学习过程中可关注的问题
- [结语：Agent 时代的开发者心态](#结语：Agent 时代的开发者心态)
学习地址
参考资料
- [Google 官方与课程相关资料](#Google 官方与课程相关资料)
- 课程解析、学员体验、博客文章
- 产业洞察、趋势与未来分析
- 相关视频资源（YouTube）

从大模型到 AI Agent：以 Google 5-Day AI Agents Intensive 为例看架构与趋势

https://www.kaggle.com/learn-guide/5-day-agents

引言：从「会聊天」到「会干活」

2023--2024 年，大模型应用的主流形态是「智能问答」与「对话助手」，开发者主要在做 Prompt 工程、RAG 检索与简单工具调用。进入 2025 年，叙事开始明显转向「Agentic AI」------不是再多一个聊天机器人，而是能规划任务、使用工具、记住上下文、协作完成复杂目标的 AI Agent 系统。[3][4][5]

这种转变在 Google 生态里体现得尤为明显：从 2024 年的 Gen AI Intensive，到 2025 年与 Kaggle 合作推出的 5-Day AI Agents Intensive，课程主题已经从「如何使用大模型」升级为「如何构建生产级 Agent 系统」，涵盖架构、工具、内存、评估与多 Agent 协作等模块。对开发者而言，这不仅是一门课，而是一条从 LLM 原型到 Agent 系统工程的学习路径。[6][7][1]

什么是 AI Agent：解决的真实问题

超越「智能聊天」的系统能力

如果用一句话对比：传统大模型应用侧重「回答问题」，而 AI Agent 则侧重「完成任务」。前者多是一次性问答或有限轮对话，后者强调在环境中持续感知、决策、执行和反思。[5][3]

典型 LLM 应用的局限包括：

无法主动分解目标，只能被动响应用户的逐条指令。[3]
工具调用零散，缺乏统一的工具编排与错误恢复机制。
记忆停留在当前对话上下文，难以跨会话保持长期状态与用户偏好。[2]

AI Agent 则试图在以下方面补齐「系统能力」：

具有明确的目标和策略：不是回答单个问题，而是围绕目标规划步骤。
会用工具行动：通过 API、数据库、外部服务等工具修改世界状态，而不仅是生成文本。[8][2]
具备记忆与上下文管理：能在多轮、多会话中延续状态，并根据历史行为不断调整策略。[2]

Google 的定义视角：课程里的 Agent

在 Google 的 5-Day AI Agents Intensive 中，第一天就强调了「Agent 与传统 AI 工具/聊天机器人的区别」：Agent 被视为一个能在特定环境中自主采取行动、使用工具、维护状态、并与其他 Agent 或系统协作的智能体。课程从一开始就将 Agent 放在「系统工程」而非单一模型的视角下，这对开发者理解非常关键。[1][2]

典型 Agent 架构：从四个核心组件拆解

架构基本要素

纵观各类 Agent 框架（包括 Google 自家 ADK、以及课中示例的 LangGraph 流程），可以抽象出一套通用架构组件：[9][4][8]

感知（Perception）
- 输入来源：用户请求、系统事件、定时触发、外部 Webhook 等。
- 作用：把非结构化输入（文本、日志、状态）转换为 Agent 可理解的表征。
决策（Planning & Control）
- 规划：将高层目标拆分成可执行的子任务或步骤。
- 策略：根据当前状态和工具可用性，决定下一步是继续思考、调用工具还是结束任务。[8][9]
执行（Tool Use & Actions）
- 工具：HTTP API、数据库操作、代码执行、第三方 SaaS、Google Cloud 资源等。
- 编排：以安全、可观察、可重试的方式调用工具，处理错误与超时。
记忆与状态管理（Memory & State）
- 短期记忆：本次会话的对话轮次和中间结果。
- 长期记忆：跨会话的偏好、历史任务、知识片段，通常存放于向量库或数据库。[8][2]

这些组件并非简单串联，而常通过一个「Orchestrator（编排器）」或「Runner」进行统一调度，在 Google 的 ADK 与课程示例中亦是如此。[4][9]

与 Google 课程模块的映射

5-Day AI Agents Intensive 的课程结构基本可以与上述框架一一对应：[7][2][8]

Day 1：Introduction to AI Agents & Agentic Architectures
- 对应：整体架构、感知与决策的基本概念。
Day 2：Tools & MCP（Model Context Protocol）
- 对应：执行层与工具编排，通过 MCP 暴露外部能力。
Day 3：Context & Memory Management
- 对应：状态管理与长短期记忆构建。
Day 4：Logging, Quality & Evaluation
- 对应：可观测性、评估与安全控制。
Day 5：A2A（Agent-to-Agent） & Production Deployment
- 对应：多 Agent 协作与生产级部署。

通过课程结构可以看到，Google 在 Agent 教学中明显强调「工程化」与「生产就绪」，而不是停留在单一模型的 Prompt 技巧层面。[7][1]

Google 生态中的 Agent 技术栈概览

技术栈要素一览

在 Google 生态下构建 Agent，通常会涉及如下关键要素（具体组合可灵活调整）：[9][2][8]

模型层：
- Gemini 系列模型，用于自然语言理解、工具调用决策、代码生成等。
工具与协议层：
- Model Context Protocol（MCP）用于统一暴露工具能力，让 Agent 以标准方式访问外部系统。[10][8]
- 自定义工具：HTTP 服务、Google Cloud API、企业内部 API 等。
编排与开发工具：
- ADK（Agent Developer Kit）和相关 Runner，用于定义 Agent 流程、工具 schema、session 等。[9]
- 部分 codelab 使用 LangGraph 展示 Agentic 流程构建思路。[4]
记忆与存储：
- 向量数据库、Cloud SQL、Firestore 或其他存储，用于长期记忆与任务状态记录。
部署与运行：
- Vertex AI Agent Engine 作为多 Agent 系统的托管环境，支持 A2A 协议和生产级调度。[9]

整体上，这套技术栈的目标是让开发者从「调用单一模型 API」自然升级到「构建可观测、可扩展的 Agent 系统」，而不需要完全重造轮子。

「从 Prompt 到 Agent」的心智转变

对熟悉 Gen AI Intensive 的开发者来说，5-Day AI Agents Intensive 相当于从「如何写一个好的 Prompt + RAG」升级为「如何定义工具、状态与流程，围绕一个目标 orchestrate Agent」的课程。这种升级要求开发者：[6][4]

多思考「系统边界」和「模块职责」，而不是只调模型参数。
学会在架构层面设计：哪些逻辑由 Agent 决策，哪些逻辑由传统程序负责。
关注非功能性需求：可靠性、可观测性、安全性和成本控制。[5][9]

从零到一：一个最小可用 Agent 的设计思路（伪代码）

本节只给出架构与伪代码思路，不依赖具体框架 API，方便迁移。

目标：任务管理 Agent

设定一个简单但实用的场景：一个「任务管理 Agent」，接受自然语言任务请求，负责：

解析任务并写入任务系统（例如存储在数据库/表格）。
根据任务状态定期检查并提醒用户。
支持自然语言查询任务进度。

核心设计要点

工具定义（Tool Schema）
- create_task(title, description, due_date)
- list_tasks(status_filter)
- update_task_status(task_id, status)
  每个工具需要定义：名称、输入参数（类型与描述）、输出结构以及错误类型，以便 Agent 可以基于 schema 正确规划调用。[2][8]
Agent 循环（伪代码示意）

text 复制代码

loop:
  input = get_user_or_system_input()
  context = load_session_state(user_id)

  plan = model.think(goal=input.goal, context=context)

  if plan.requires_tool:
      tool_call = plan.next_tool
      result = safely_invoke_tool(tool_call)
      log_observation(tool_call, result)
      update_memory(user_id, input, tool_call, result)
      output = model.reflect(observation=result, context=context)
  else:
      output = plan.final_answer

  save_session_state(user_id, context, output)
  send_output_to_user(output)

  if goal_completed(output):
      break_or_wait_for_next_goal()

这段伪流程体现了 Google 在课程中强调的几个概念：明确的「思考」阶段、工具调用的安全执行、对 observation 的记录以及对 session/memory 的管理。[8][2][9]

错误处理与重试
- 在工具返回错误时，Agent 不应简单把错误文字扔给用户，而应：
  - 判断错误类型（参数错误、权限错误、网络错误等）。
  - 再次思考是否需要调整调用参数或向用户请求更多信息。[8][9]

从工程角度看，这本质上是在 Agent 层「建模非正常路径」，而不是把所有异常都推给底层服务。

记忆系统与上下文管理：让 Agent 不再「金鱼记忆」

短期与长期记忆的边界

Google 在课程中将「Memory Management」单独设为一天，强调实现可持续交互的 Agent 需要系统化记忆设计，而不是简单「让模型记住所有对话」。一般可以区分：[2][8]

短期记忆（Session State）
- 保存当前任务或会话中的最新上下文，包括用户目标、已执行步骤、工具调用轨迹。
- 存在时效性，通常只在 session 生命周期内有效。
长期记忆（Long-Term Memory）
- 保存跨会话的偏好、历史任务、知识摘要等。
- 可存储于向量数据库、关系数据库或特定文档存储中。

关键问题不是「存什么」，而是「何时写入长期记忆、何时读取、如何避免污染」。这被 Google 归类到「Context Engineering & Memory」的 broader topic 之中。[4][8]

Agentic RAG 与 Memory 的结合

在实际系统中，RAG（检索增强生成）与 Agent 记忆并不是两套互斥系统，比较常见的模式是：

长期记忆中的重要片段（如关键事件、用户习惯）以结构化/嵌入形式保存在数据库中；
Agent 在规划阶段可以决定：
- 是否需要查询知识库（RAG）。
- 是否需要查询用户历史记录（Memory）。
- 是否需要将当前任务结果写回记忆系统，以便未来复用。[5]

这意味着，Agent 不再被动等人「喂知识」，而是主动选择何时读取与写入知识/记忆，向「会学习的系统」更近一步。

多 Agent 系统：从单点智能到协同智能

多 Agent 协作模式

在 5-Day AI Agents Intensive 的后两天，课程强调了多 Agent 协作与 A2A（Agent-to-Agent）协议的重要性，用于支持多个 Agent 间的通信和任务分解。常见模式包括：[2][9]

角色分工模式
- 如「研究员 Agent」「写作者 Agent」「审查 Agent」按角色分工，各司其职。
专家团队模式
- 为不同领域（法律、财务、技术）构建专门 Agent，让总控 Agent 做路由与协调。
评审和仲裁模式
- 通过 Critic Agent 或 Judge Agent 对其他 Agent 的输出进行质量评估与纠偏。

Google 的 A2A 协议旨在为这些协作模式提供统一通信规范，使多 Agent 系统在 Vertex AI Agent Engine 上更易于部署和监控。[9]

多 Agent 的收益与代价

多 Agent 系统的潜力巨大，例如：Agentic AI 市场研究指出，企业正在探索通过多个协同 Agent 承担复杂的跨部门流程，如供应链优化、客服自动化、财务对账等。这类系统被认为能显著减少人工在多步骤流程中的时间投入。[11][12]

但代价也不可忽视：

复杂度显著提升：调度、多 Agent 死锁、对话风暴等问题需要精心设计。
可观测性与调试成本上升：必须有完善的 tracing、logging 和 replay 工具。[5][9]
资源消耗增加：更多模型调用、更频繁的工具访问，需要结合业务价值和成本进行权衡。

因此，Google 的课程在教授多 Agent 时，强调从小规模实验开始、逐步引入协作模式，而不是一开始就构建过度复杂的「超级 Agent」。[8][2][9]

2025 年 Agentic AI 的关键趋势（含 Google 视角）

行业趋势概览

多家机构对 2025 年的 Agentic AI 做出了相对一致的判断：从「概念验证」走向「生产试点」。例如，有研究报告称，大约四成左右的头部企业已经在尝试将 Agent 系统用于真实业务流程，且预计未来数年采用率还将显著上升。[11][5]

核心趋势可以归纳为：

Agent 的自主性增强：从半自动助手向更高程度自动化的业务执行者演进。[12][5]
多 Agent 协作成为常态：复杂业务不再依赖单一 Agent，而是通过多角色协同实现端到端自动化。[12][11]
垂直场景深化：从通用 Chat Agent 走向行业特化 Agent（金融、医疗、制造、运营等）。[13][12]

Google 在趋势中的定位

Google 通过 Gen AI Intensive 和 5-Day AI Agents Intensive 显然在做两件事：

在教育侧：培养一批熟悉 Agentic 思维的开发者，让他们掌握模型、工具、内存、评估与部署的一体化技能。[1][6][7]
在平台侧：通过 Gemini、ADK、Vertex AI Agent Engine 等组件，提供一个从学习到生产的闭环，使得「在 Kaggle 上写的课程 Agent」可以较自然地迁移到企业环境中运行。[4][9][8]

从趋势角度看，这种「课程 + 工具链 + 云平台」的组合，是在用生态力量抢占 Agentic AI 的开发者心智与工作负载。

面向开发者的学习与实践路径（基于 Google 课程）

一条可行的学习路线

结合 Google 现有课程体系，可以为开发者给出一条偏「概念 + 架构 + 趋势」的学习路径：[6][4][2][8]

阶段一：夯实 Gen AI 基础
- 参加或自学 Gen AI Intensive（Prompt 工程、Embedding、基础 RAG）。
阶段二：入门 Agent 思维
- 学习 5-Day AI Agents Intensive 的 Day 1--2：理解 Agent 架构、工具调用和 MCP。
阶段三：掌握记忆与上下文
- 深入 Day 3：Session 状态管理、长期记忆设计、Context Engineering 案例。
阶段四：工程化与评估
- 关注 Day 4：日志、Tracing、评估指标和安全策略。
阶段五：多 Agent 与生产部署
- 实践 Day 5：A2A 协议、Vertex AI Agent Engine 部署，以及将课程中的 Demo 迁移到真实业务场景。

在每个阶段，都可以结合自身业务需求做一个小型实验，例如：自动报告生成 Agent、数据运维 Agent、客服 triage Agent 等。[5][9]

学习过程中可关注的问题

何时需要 Agent，而不是一个简单的 RAG + 工具调用服务？
哪些逻辑必须交给传统程序（例如权限控制、关键决策），哪些逻辑可以让 Agent 自主探索？
如何设计指标来判断「Agent 是否真的带来价值」，而不是仅仅「看起来很酷」？[3][5]

这些问题没有标准答案，但 Google 课程提供了较好的案例和评估框架，适合作为反思参照系。[2][9][8]

结语：Agent 时代的开发者心态

从 Google 的课程演进和行业趋势可以看出，一个重要变化是：开发者的工作重点正从「写一个调用模型的脚本」转向「设计一个由模型驱动的系统」。在这个过程中，架构、协议、内存、评估、多 Agent 协作等系统性问题，比单个 Prompt 的优雅更重要。[6][5]

对于想在 2025 年及之后保持竞争力的开发者而言，理解并实践 Agentic AI，将会像十年前掌握云原生和微服务那样，成为一项核心工程能力。对于已经熟悉 Google 生态的开发者，更可以借助 5-Day AI Agents Intensive 这样的公开课程，把这股趋势转化成自己的技术优势和产品机会。[11][12][5]

学习地址