Google Agent 白皮书解析

最新推荐文章于 2025-11-21 16:38:16 发布

原创最新推荐文章于 2025-11-21 16:38:16 发布 · 595 阅读

30 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #大模型 #Agent

引言

Google 最近联合 Kaggle 发布了一个AI Agent 五天课程 5-Day AI Agents Intensive Course with Google，主要涉及内容：

Day 1: Introduction to Agents
Day 2: Agent Tools & Interoperability with MCP
Day 3: Context Engineering: Sessions & Memory
Day 4: Agent Quality
Day 5: Prototype to Production

目前五篇内容全部发布完成，目前看下来质量还是非常不错的。正好和工作内容也相关，后面会降这部分的学习笔记顺便分享给大家。

今天是先介绍 Day 1 的内容《Introduction to Agents and Agent Architectures》白皮书，原文地址: https://www.kaggle.com/whitepaper-introduction-to-agents

另外为了方便阅读，我通过 GPT-5 做了翻译做了中英文对照版本如下，可以通过后台回复 “agent-whitepaper” 获取。下面我们进入正文。

一、从「回答问题」到「完成任务」

目前的 LLM 是生成式 AI，更像一个预测引擎：

用户提出一个问题
模型基于训练数据和提示词，单次生成一个回答
每一步都要人类驱动，缺少持续性、记忆和行动能力

白皮书指出，我们正经历一场范式转移：
从 Predictive AI 转向 Autonomous Agents：

不再只是“给一个答案”，而是为一个目标持续工作
不再只依赖静态训练知识，而是主动调用工具、操作环境
不再是一次性调用，而是在一个循环中思考–行动–观测–修正

在这个范式下，一个 Agent 更像一个可以交代任务的“虚拟同事”，而不是一个“高级搜索框”。

二、什么是 AI Agent：脑、手、神经系统与身体

白皮书给出一个简洁而实用的定义：
Agent = 模型 + 工具 + 编排层 + 部署运行时，并用人体类比做了很好的抽象如下。这里和目前大部分的 AI Agent 的定义（LLM + Tool + Memory）多了一层部署运行时。

Model（大脑）
- 核心推理引擎：处理信息、权衡方案、做出决策
- 可以是通用大模型、领域微调模型，或多模态模型
- 决定了“能思考到什么程度”
Tools（双手）
- 把“会说话的模型”变成“能做事的系统”
- 包括：业务 API、代码函数、数据库/RAG、搜索、事务系统等
- Agent 负责选择哪个工具、如何调用，再把结果塞回上下文继续推理
- (补充：目前 Tools 最常用的方式是 MCP，但是最近 Anthropic 发布文章说 MCP 可能不一定是一个好的方式，这个后面有时间再另外发文细说)
Orchestration Layer（神经系统）
- 管理整个循环：规划步骤、维护状态、选择推理策略
- 通过 CoT、ReAct 等模式把复杂目标拆成多步
- 负责“记忆”：短期会话记忆、长期工作记忆、外部知识记忆等
Deployment & Services（身体与腿）
- 运行时（Serverless / 容器 / 专用 Agent 平台）
- 监控与日志
- 配置、版本管理与访问控制
- 把试验室里的 Agent 变成可用服务：
- 对用户是 GUI，对其他 Agent 是 API（A2A 接口）

开发模式也随之改变：传统开发者像“砌砖工”，写死每个 if-else； Agent 开发者更像“导演”，需要：

写清楚场景与角色设定（System Prompt、Persona、约束）
选择并编排合适的“演员”（工具、子 Agent）
提供足够又不过载的上下文（Context Engineering）
在运行中持续观测效果、迭代脚本（Agent Ops）

三、五步问题求解循环：Mission → Scene → Think → Act → Observe

白皮书把 Agent 的工作过程抽象为一个五步循环，这是理解一切 Agent 行为的基础：

Get the Mission：拿到任务
- 任务来源可以是用户请求（“帮我安排会议出差”）
- 也可以是系统触发（“来了一个高优先级工单”）
Scan the Scene：感知场景
- 用户最近的对话与历史偏好
- 工作记忆中是否已有尝试/中间结果
- 可用的工具与数据源是什么
- 看清楚当前环境与约束：
Think It Through：推理与规划
- 把 Mission 与 Scene 结合，形成多步计划
- 决定先做什么、后做什么，以及每一步需要什么信息
- 这是 LM 的核心能力发挥之处：
Take Action：调用工具行动
- 编排层选择具体工具并执行调用
- 对外可以是调用 API、运行函数、查询数据库、写入系统等
Observe and Iterate：观测并迭代
- 把工具返回结果写入上下文/记忆
- 回到第 3 步：基于最新信息重新思考下一步
- 循环直到完成任务或触发终止条件

白皮书用“查订单状态”的例子说明这一循环：
Agent 不会一上来就乱查，而是先想清楚要先查内部订单系统，再调用物流接口，最后汇总成对用户友好的回答。

工程上的关键信息是：
你不是简单“调用一次模型”，而是在设计一个持续多轮的闭环系统。

四、Agentic 系统能力分层：从 Level 0 到 Level 4

为了帮助架构师决定“要造多强的 Agent”，白皮书提出了一个从 0 到 4 的层级体系。

Level 0：核心推理系统（只有大脑）

只有 LLM，没有工具、记忆或外部环境交互
擅长解释概念、写文案、做一般性规划
完全无法感知实时世界（最新比分、实时库存等）
工程上就是我们熟悉的“纯模型调用”
(补充：我们在本地通过 Ollama 部署一个模型然后进行对话就是这种)

Level 1：接入工具的连通问题求解者

在 Level 0 上接入外部工具（搜索、API、RAG 等）
仍然是一个 Agent，但能力从“纸上谈兵”变成“能查真相”
典型能力：
- 查实时信息（比分、天气、股价）
- 访问企业内部系统（CRM、工单系统、数据库）

这是大多数实际项目的起点，也是最容易落地的阶段。

Level 2：具备上下文工程的战略问题求解者

能够围绕复杂目标做多步规划与上下文裁剪
关键能力是 Context Engineering（注：这也是一个很大的话题，后面单独再聊）：
- 主动决定“在有限的上下文窗口中，放什么信息最关键”
- 自动生成中间查询（如把长邮件压缩成机票信息再写入日历）

举例：帮你找两地之间“中途、评价足够高”的咖啡馆
Agent 会自动拆分为：算中点 → 查城市 → 在该城市查咖啡馆 → 过滤评价 → 汇总结果。

Level 3：协作型多 Agent 系统

不再追求万能大 Agent，而是一个有分工的 Agent 团队
常见角色：项目经理 Agent、执行 Agent、审查 Agent、学习 Agent 等
通信方式：Agent 把其他 Agent 当作“工具”去调用

例如一个新品发布项目：

ProjectManagerAgent：分解任务、制定时间表
MarketResearchAgent：做竞品与用户研究
MarketingAgent：写文案、广告与落地页
WebDevAgent：生成页面代码
CriticAgent：做质量与合规审查
LearningAgent：从失败案例中抽象出新规则

这类系统可以覆盖跨团队、跨职能的业务流程，但对观测、调试和治理提出更高要求。

Level 4：自我进化系统

不仅会完成任务，还会发现自身能力缺口并主动扩展能力
能够：
- 意识到缺少某种工具/子 Agent
- 调用“Agent 生成器”之类的工具，创建新的 Agent 或工具
- 把人类反馈固化为规则、Prompt 模板或工具升级

这类系统仍处在前沿探索阶段，但白皮书认为它代表了 Agentic 系统的长期方向。

五、架构关键：模型、工具与编排层的设计权衡

从工程实践的角度，白皮书强调了几个非常具体的设计要点。

1. 模型：不可“迷信大而全”

根据任务选择模型：
- 通用任务用主力大模型
- 对实时性/成本有要求的链路用轻量模型
- 多模态场景（语音、图像）用多模态模型
更重要的是：模型只是大脑，真正决定可靠性的，是你对上下文与工具的设计。

2. 工具：明确契约，最小完备

工具不是“给模型一个黑盒 API”，而是带有严格契约的能力组件：
- 明确输入输出结构
- 对参数范围、权限、错误做硬约束
工具分为两大类：
- 检索工具：搜索、数据库、RAG、配置中心
- 执行工具：写数据库、发邮件、调用第三方业务系统、操作 UI
- (注：这个分类感觉不是太好，也可以简单分成只读工具和写工具)

好用的 Agent 很大程度上是“工具设计得好”。

3. 编排层：Prompt + 记忆 + 策略

编排层负责：
- 场景化 Prompt（任务说明 + 角色 + 风格 + 边界）
- 管理短期/长期记忆与外部知识
- 选用合适的推理模式（一步直出 / CoT / ReAct / 计划再执行）

这部分实际上构成了你的“Agent 框架”，是很多团队竞争力所在。

六、Agent Ops：从“写完就跑”到“持续运营自治系统”

白皮书提出一个重要概念：Agent Ops，是 DevOps/MLOps 在 Agent 时代的自然演进。

1. 测试不再是“output == expected”

Agent 响应本身就是概率性的，同一个请求每次都可能略有不同
语言质量和任务完成度，往往难以用简单断言描述
传统单元测试模式不再适用，需要新的评估范式

2. 用 LM 做评测（LM-as-Judge）

搭建“评测集 + 评分 Rubric”：
- 覆盖核心业务场景与边缘案例
- 使用强模型（或专门微调模型）来打分：正确性、完整性、事实性、风格等
把评测结果作为版本上线的硬指标，而不是靠人工主观感觉

3. 像做 A/B 实验一样做迭代

定义业务 KPI：
goal completion rate、用户满意度、时延、成本、转化率等
每次改动都跑一遍 Golden Dataset + 线上 A/B 对比：
- 评估质量是否提升
- 监控延迟、成本、错误率是否可接受

4. 用 Trace 调试“思考过程”

借助 OpenTelemetry 等系统记录完整执行轨迹：
- 每次模型调用的 Prompt 与输出
- 调用了哪些工具、用什么参数、返回了什么
- 决策分支为何走错
Trace 不是给用户看的，而是给工程团队做“行为剖析”和根因定位。
（注：我们现在 Trace 使用比较多的是 LangFuse，可视化更好一点）

5. 人类反馈是最有价值的“训练数据”

每一次“差评”“工单”“人工纠正”，都是新的边界条件
系统化做法：
- 收集并聚合这些反馈
- 把高价值反馈转成新测试样本，加入评测集
- 既修复当前问题，又减少同类问题再出现的概率

从这个视角看，做 Agent 更像运营一个复杂的在线系统，而不仅仅是“部署了一个模型服务”。

七、互联互通：人与 Agent、Agent 与 Agent、Agent 与货币

白皮书还讨论了 Agent 与外部世界的三种关键关系。

1. Agents & Humans：更自然、更高带宽的交互

最简单的是聊天式 UI
进阶是结构化输出（JSON），驱动富 UI 或工作流引擎
更进一步是 Computer Use：
- Agent 直接操纵 UI 元素（点击、输入、导航）
- 通过专门的 UI 控制工具/协议实现
语音与多模态 live 模式让 Agent 成为“可对话的实时助手”：
- 实时语音双向流
- 能看到摄像头画面、理解环境
- 适合维修指导、购物顾问等场景

2. Agents & Agents：A2A 协议与任务式通信

随着企业内部 Agent 数量增长，点对点自定义集成会变成“集成地狱”
白皮书提出 Agent2Agent (A2A) 协议：
- 每个 Agent 发布一个包含能力与入口的 Agent Card（数字名片）
- 统一发现与认证方式，使 Agent 能够互相调用
- 交互以“任务”为单位，而非单次请求响应
- 支持长时间运行任务与流式状态更新

这为 Level 3 多 Agent 系统提供了基础设施。

3. Agents & Money：为 Agent 经济搭建可信支付层

当 Agent 可以代表人类做购买与交易时，问题变成：

“如果 Agent 买错了，责任在谁？”

白皮书提出两条关键路径：

AP2（Agent Payments Protocol）
- 通过加密签名的“Mandate（授权书）”表达用户意图
- 为每笔交易建立不可抵赖的审计链路
- 让 Agent 能在明确授权下自主浏览、谈判和交易
x402 协议
- 基于 HTTP 402（Payment Required）状态码的互联网支付协议
- 支持机器对机器的微支付，如按调用付费访问 API 或数字内容

两者共同构成了未来 Agentic Web 的“信任与结算层”。

八、安全与治理：Agent 是新的「主体」

在身份与安全体系中，Agent 被视为一种新的主体类型：

传统只有两类：
- 用户（OAuth/SSO）
- 服务账号（IAM/Service Account）
现在增加第三类：
- Agent 身份：有独立的数字身份、证书与权限范围
- 可以通过类似 SPIFFE 的标准进行身份验证
- 授予严格的最小权限，限制可访问的 API、数据与其他 Agent

白皮书提出多层防护思路：

身份层：区分用户、服务账号与 Agent 身份
授权层：用策略控制每个 Agent 能访问哪些工具、数据和下游 Agent
工具层 Guardrail：工具内部自己做权限与参数校验，杜绝越权操作
动态防护：
- 在工具调用前后插入 Callback/Plugin 做行为审查
- 使用“模型作为安全审查器”识别 Prompt 注入、越权意图、敏感数据泄露
- 也可以接入专业安全服务做统一的模型安全防护

在大规模部署时，还需要一个类似“控制平面”的治理系统：

统一注册与发现 Agent / 工具
管理版本、灰度与废弃
做集中审计与合规检查
避免 Agent 在组织内“野蛮生长、各自为政”

九、自主进化：持续学习、Agent Gym 与两个前沿案例

1. Agent 如何学习与自我演化

与人类类似，智能体通过经验和外部信号进行持续学习然后进化，才能胜任人类社会更多的任务（这也是一个比较热门的研究领域，后面再单独聊）。

白皮书把 Agent 的“学习信号”分成几类：

运行时经验：日志、Trace、记忆，包含成功与失败的轨迹
外部信号：新政策文档、监管要求、业务规则更新
人类反馈：专家批注、人工审核意见、用户纠错等

有了这些信息之类，我们要降这些“历史记录”转化为可复用的抽象产物，进而提升 Agent 的能力。概括来说主要有如下方式：

增强上下文工程: 系统会持续优化其提示、少量示例以及从记忆中检索的信息。通过为每个任务优化提供给语言模型的上下文，它可以提高成功的可能性
工具优化与创建: 智能体的推理可以识别其能力上的不足并采取行动加以弥补。这可能包括获取新工具的访问权限、即时创建新工具（例如，Python脚本），或修改现有工具（例如，更新API模式）
（除此之外，其实我们还可以利用真实世界的这些反馈数据对模型进行后训练微调，从而使模型在我们的场景下编写的更好）

2. Agent Gym：离线仿真与极限压测

除了上面的内容，当前业界也正在研究更先进的方法，即构建一个专用平台，通过先进的工具和功能在离线流程中优化多智能体系统，而这些工具和功能并不属于多智能体运行时环境。这个在白皮书中，被称为 “Agent Gym”：

不在生产路径上，是一个独立的离线优化平台
提供高保真仿真环境，让 Agent 在合成或回放数据上“训练”
可以调用更强大的模型、更多外部工具（包括红队、动态评估与批判 Agent）
可以利用合成数据不断扩充、覆盖真实难例
在难以自动判断的场景下，Agent Gym 还可以主动“求助”人类专家，
把人类判断固化为下一轮优化的基准

它更像是企业版的“Agent 训练场 + 红蓝对抗实验室”。

3. 两个代表性案例

白皮书中举了两个 Google 内部的例子，简单描述如下，不再赘述。

Google Co‑Scientist

面向科研的多 Agent 系统，作为“虚拟合作者”帮助探索科研假设空间
典型流程：
- 研究者定义目标与约束
- 系统生成项目计划，由 Supervisor Agent 分配给不同子 Agent
- 多个 Agent 在长时间尺度上生成、评估和改进假设
本质上是一个 Level 3/4 混合系统，既有多 Agent 协作，也开始具备自我改进能力

AlphaEvolve

用 Agent 体系探索数学与计算机科学中的复杂算法设计问题
核心机制：
- LM 负责生成候选算法（以可读代码形式）
- 评估器根据指标打分
- 通过“进化”过程选优并继续生成下一代
已在数据中心调度、芯片设计、矩阵乘法等场景中取得突破
适合“容易验证、难以直接构造”的问题空间
保留了人类专家在目标定义与指标设计上的关键角色，避免系统“钻空子”

十、对工程团队的启示

那么对于 Agent 从业者，结合白皮书内容，我们可以学到什么。我想下面是几条非常实用的启示：

从 Level 1–2 做起，而不是一上来造“超级 Agent”
- 先把“连通 + 工具调用 + 上下文工程”做好
- 把一个具体业务场景做深做稳，再考虑多 Agent 与自我进化
把 Agent 当“系统”而不是“模型能力”来设计
- 同等重视模型选择、工具设计、编排策略与运行治理
- 把 Tool 视为有严格契约的能力单元，避免朦胧的“万能函数”
尽早建立 Agent Ops 能力
- 搭建评测集与 LM 评审体系
- 接入 Trace 与监控，避免“黑箱调参”
- 把用户反馈系统化转化为测试用例与规则更新
安全与治理是架构的一部分，而不是事后补丁
- 在设计之初就考虑 Agent 身份、最小权限与策略层
- 对关键工具内置防护逻辑 + 行为审查
- 建立统一的 Agent 注册、发现和审计机制
保留人类的“掌舵权”
- 在高风险或高价值决策链路中留出 Human-in-the-Loop
- 把专家反馈视作核心资产，沉淀为规则、Prompt 和工具升级