AI Agents
完全指南
融合 Google「Agents」(42页) 与「Agents Companion」(76页) 两份白皮书,从基础到进阶,12章节一本读透 AI Agent 全貌。
Chapter 01
什么是 AI Agent
AI Agent 是一种使用工具观察世界并采取行动、以追求目标的应用程序。Agent 是自主的,可以独立于人类干预而行动。
核心定义
Agent 不同于普通 LLM 应用的关键在于:它们能自主决策下一步该做什么,使用工具与外部世界交互,并通过编排逻辑管理推理-行动循环。
三大核心组件
模型 (Model)
Agent 的"大脑"。负责推理、规划、生成文本,以及决定何时调用哪些工具。
工具 (Tools)
弥补基础模型知识与能力的不足。让 Agent 能执行 API 调用、检索数据、操作代码等。
编排层 (Orchestration)
管理 Agent 的推理-行动循环。获取信息、处理内部推理、决定下一步行动。
深入理解:Agent 与模型的区别
模型 是静态系统:接收输入 → 生成输出。它本身不会主动"做"任何事。
Agent 使用模型作为核心推理引擎,但增加了:
- 工具调用能力 — 可以执行 Google Search、调用 API、查询数据库
- 记忆与状态管理 — 跨多轮对话保持上下文
- 自主决策循环 — 根据观察结果决定下一步是继续推理、调用工具、还是返回结果
- 目标驱动 — 不只是回答问题,而是为了达成目标而规划和行动
类比:模型像一个聪明但只能纸上谈兵的顾问,Agent 则是能真正动手干活的项目经理。
模型层细节:选择与配置
Agent 可以使用不同大小和能力级别的模型(如 Gemini 系列),关键配置:
- 温度 (Temperature) — 控制输出的随机性
- System Instructions — 定义 Agent 的角色、行为边界和输出格式
- Few-shot Examples — 提供示例来引导模型行为
编排层运行机制详解
核心是一个 推理-行动循环:
- 接收输入 — 用户查询或上一步的观察结果
- 推理 — 模型分析当前状态,决定下一步
- 选择行动 — 调用工具、请求更多信息、或生成最终回答
- 观察结果 — 获取行动的返回值
- 循环或结束 — 根据结果决定是否继续循环
Chapter 02
认知架构
Agent 的"思考方式"——不同的推理框架决定了 Agent 如何分解问题、规划步骤、执行任务。
ReAct(推理+行动)
目前最广泛使用的 Agent 推理框架,交替进行"思考"和"行动"。
ReAct 完整示例
用户:"帮我订明天下午3点的会议室"
Thought 1:需要先查看明天下午3点有哪些会议室可用。
Action 1:调用 calendar_api.check_availability(date="tomorrow", time="15:00")
Observation 1:会议室A(可用)、会议室B(已占用)、会议室C(可用)
Thought 2:有两个可用。选择会议室A并预订。
Action 2:调用 calendar_api.book_room(room="A", date="tomorrow", time="15:00")
Observation 2:预订成功。确认码:#12345
Final Answer:已为您预订明天下午3点的会议室A。确认码:#12345。
Chain-of-Thought (CoT)
让模型"逐步思考",把复杂推理拆解成可追踪的中间步骤。是 ReAct 中"Thought"环节的核心技术。
CoT 变体一览
- 标准 CoT — "Let's think step by step" 即可激活
- Self-Consistency CoT — 生成多条推理路径,投票选最一致答案
- Active Prompting CoT — 针对模型最不确定的问题动态选择示例
- Multimodal CoT — 将视觉和文本信息融合进推理链
Tree-of-Thoughts (ToT)
将推理从单一链条扩展为树形结构。每一步探索多个可能方向,评估后选择最优路径。
ToT vs CoT 对比
| 维度 | CoT | ToT |
|---|---|---|
| 结构 | 单一线性链 | 分支树结构 |
| 探索 | 一条路走到底 | 多条路径并行探索 |
| 回溯 | 不支持 | 支持(剪枝+回溯) |
| 适用 | 直接推理题 | 创造性/规划/博弈 |
Chapter 03
工具体系
工具让 Agent 从"只会说"变成"能做事"。Google 定义三类工具,对应不同集成方式。
Extensions
Agent 直接调用外部 API。Agent 端执行,适合需要实时数据的场景。
Functions
模型输出函数调用名称和参数,由客户端执行。开发者控制执行逻辑。
Data Stores
为 Agent 提供外部知识检索 (RAG)。支持网站、文档、结构化数据三种数据源。
Extensions vs Functions:如何选择?
| 维度 | Extensions | Functions |
|---|---|---|
| 执行方 | Agent 端 (服务端) | 客户端 (开发者应用) |
| 谁控制API调用 | Agent 自动调用 | 开发者代码执行 |
| 适用场景 | 实时数据、Google 服务集成 | 私有API、安全敏感操作 |
| 安全性 | Agent 直接访问外部 | 开发者完全控制 |
Function Calling 工作流:
- 开发者定义函数 Schema(名称、描述、参数)
- 用户提问 → 模型决定调用哪个函数,输出结构化参数
- 开发者应用接收参数 → 执行实际 API 调用
- 返回结果给模型 → 模型生成自然语言回答
Data Store 与 RAG 原理
- 数据导入 — 将文档/网页/数据库导入 Vertex AI Search
- 向量化 — Embedding 模型将文本转为高维向量
- 检索 — ScaNN 等算法找到语义最相近的文档片段
- 增强生成 — 检索片段作为上下文注入 LLM prompt
支持数据源:网站内容(URL 爬取)、非结构化文档(PDF/HTML/TXT)、结构化数据(Cloud SQL/Spanner/BigQuery)。
Chapter 04
学习方式与部署
模型如何持续学习新知识,以及如何从原型走向生产环境。
模型学习的三种方式
In-Context Learning
在 prompt 中提供示例,模型"临时"学会新任务。无需训练,但受上下文窗口限制。
Retrieval-Based
通过 RAG 从外部知识库检索最新信息。适合知识频繁更新的场景。
Fine-Tuning
用特定数据集对模型微调。效果最好但成本最高,适合深度领域定制。
从原型到生产:Vertex AI 工具链
- LangChain on Vertex AI — 快速原型开发,集成 Google 服务
- Vertex AI Agent Builder — 可视化构建 Agent,配置工具和数据源
- Vertex AI Agent Engine — 托管运行时,自动扩缩容,内置会话管理、追踪、评估
- Cloud Trace / Observability — 监控 Agent 行为和性能
LangChain + Gemini 代码速览
Agent 进阶
来源:Google "Agents Companion" 白皮书 (Feb 2025, 76 pages)
Chapter 05
Agent Ops
从 DevOps 到 MLOps,再到专为 AI Agent 设计的运维方法论。
运维演进路径
四代运维体系详解
DevOps — CI/CD、自动化测试、容器化、监控告警。
MLOps — 增加:数据管道、模型训练/版本管理、A/B 测试、数据漂移检测。
FMOps / GenAIOps — 专注大模型运维:
- PromptOps — Prompt 版本管理、A/B 测试、自动化评估
- DataOps — RAG 数据管道、向量数据库管理
- RAGOps — 检索质量监控、chunk 策略优化、grounding 验证
AgentOps — 增加 Agent 特有维度:
- 工具管理 — 注册、权限、版本、性能监控
- 编排管理 — 推理路径追踪、决策审计、循环检测
- 记忆管理 — 会话记忆、长期记忆、记忆同步
- 任务分解 — 子任务追踪、依赖管理、失败重试
- 多 Agent 协调 — Agent 间通信、任务分配、冲突解决
Agent 成功指标体系
北极星指标
业务层 KPI:目标完成率、用户留存、收入影响。
关键任务指标
Agent 层面:任务成功率、首次正确率、工具选择准确率。
遥测指标
系统层面:延迟、错误率、token 消耗、trace 数据。
白皮书建议
从业务 KPI 开始定义成功标准。先问"Agent 帮用户完成了什么?",再问"它用了多少 token?"
可观测性实操:Cloud Trace 与 LangSmith
Agent 系统的可观测性远比传统应用复杂,因为每次用户请求可能触发多次 LLM 调用、工具调用和中间推理步骤。
Google Cloud Trace
- 自动收集 Agent 的完整执行路径(span)
- 每个 span 记录延迟、token 消耗、工具名称、参数、返回值
- 支持跨服务追踪
- 集成 Cloud Monitoring 实现阈值告警
LangSmith(LangChain 生态)
- 专为 LLM 应用设计的观测平台
- 可以看到每一步的完整 prompt
- 支持 A/B 测试不同 prompt 版本
- 内置评估功能
Chapter 06
Agent 评估
系统化评估 Agent 的能力、过程和结果——不只看最终答案对不对,还要看怎么得到的。
能力评估 (Capability)
BFCL
测试工具选择和调用准确率。Gemini 排名领先。
τ-bench / PlanBench / AgentBench
分别评估工具效率、规划能力、真实环境综合表现。
轨迹评估 (Trajectory)
评估执行过程——路径是否合理高效。
| 方法 | 说明 | 适用场景 |
|---|---|---|
| Exact Match | 工具调用序列必须完全一致 | 严格流程 |
| In-Order Match | 关键步骤顺序正确即可 | 有先后依赖 |
| Any-Order Match | 包含所有必要步骤 | 步骤间无依赖 |
| Precision | 实际步骤中有多少是必要的 | 检测多做无用功 |
| Recall | 必要步骤中有多少被执行了 | 检测漏掉关键步骤 |
最终响应评估
基于参考答案
精确匹配、BLEU、ROUGE 等指标。
LLM-as-a-Judge
用另一个 LLM 评价输出质量。需注意位置偏差、冗长偏差。
三种评估方法优劣对比
| 方法 | 优势 | 劣势 |
|---|---|---|
| Human | 捕捉细微差异 | 主观、耗时、昂贵 |
| LLM-as-Judge | 可扩展、高效 | 可能忽略中间步骤 |
| Automated | 客观、可扩展 | 可能无法捕捉全部能力 |
Benchmark 详解:BFCL、τ-bench、DBAStep
BFCL — 2000+ 测试用例评估函数调用能力,AST 匹配评分。
τ-bench — 评估真实环境工具使用效率,成功率 × 效率得分。
DBAStep — 评估数据库多步推理能力。
PlanBench — STRIPS/PDDL 形式化规划。
AgentBench — 8 个不同环境的综合评估。
Autorater 设计方法论
三大偏差:
- 位置偏差 — 偏好列表第一个选项
- 冗长偏差 — 给更长回答更高分
- 自我偏好偏差 — 偏好与自己生成风格相似的回答
校准流程:人类标注 → 对比 autorater → 调整 prompt → Cohen's Kappa > 0.7
Chapter 07
多 Agent 系统
多个专业 Agent 协作解决复杂问题——就像组建一个 AI 团队。
更高精确度
互相校验,减少幻觉
更高效率
并行工作加速完成
更好扩展性
按需添加专业 Agent
更强容错
一个失败,其他接管
减少幻觉
多视角交叉验证
处理复杂任务
分解子任务各司其职
六大设计模式
层级模式 (Hierarchical)
Orchestrator Agent 作为"经理",分析意图后路由到专业 Agent。
例:汽车 AI 中将"找寿司店"路由给 Navigation Agent。
钻石模式 (Diamond)
专业 Agent 输出经 Rephraser Agent 调整语气和风格后呈现给用户。
例:技术性胎压数据 → Rephraser → "前右轮有点低,下个加油站补补气。"
点对点模式 (Peer-to-Peer)
Agent 间可直接转交查询,检测到自己不合适时主动 handoff。
例:Navigation Agent 识别为知识问题,主动转交 General Knowledge Agent。
协作模式 (Collaborative)
多 Agent 同时处理同一问题的不同方面,Response Mixer 合并输出。
例:"水漂打滑怎么办?" → 三个 Agent 各出专业信息 → Mixer 融合。
竞争模式 (Competitive)
多 Agent 独立回答,Response Mixer 按置信度评选最佳回答。
例:三个 Agent 分别给出 71%、65%、94% 置信度的回答。
自适应循环 (Adaptive Loop)
通过反复尝试和查询改写来优化结果。
例:"有素食的意大利餐厅" → 多轮改写搜索 → 最终输出最佳匹配。
四类多 Agent 系统对比
| 类型 | 描述 | 通信方式 | 场景 |
|---|---|---|---|
| 顺序 | 按固定顺序执行 | 单向链式 | 流水线处理 |
| 层级 | 管理 Agent 分配任务 | 上下指令 | 项目管理 |
| 协作 | 平等协作共享知识 | 多对多广播 | 科研/代码审查 |
| 竞争 | 独立解决由仲裁者选优 | 独立→仲裁 | 关键决策 |
Agent & Tool Registry 详解
注册表核心信息:
- 本体描述 — 每个 Agent/Tool 在语义空间中的位置
- 能力描述 — 结构化描述能做什么
- 性能指标 — 延迟、成功率、成本
- 版本管理 — 灰度发布和回滚
动态发现:Tool RAG(语义搜索工具)、Agent Discovery(自动发现子 Agent)
Agent 内部记忆系统详解
短期记忆 — 当前会话上下文窗口内容。
长期记忆 — 跨会话持久化:用户偏好、历史交互摘要。
"反思"机制 — Agent 周期性审视短期记忆,决定哪些存入长期记忆。类似人类睡眠时的记忆整合。
Chapter 08
Agentic RAG
传统 RAG 的静态检索已不够用——让 Agent 主动、迭代、智能地管理检索过程。
传统 RAG
静态流程:Query → 向量检索 → 注入 Prompt → 生成回答。
Agentic RAG
自主检索 Agent:迭代精化查询、多步推理、自适应选择数据源。
四大能力
上下文感知查询扩展
生成多个查询变体获取更全面结果。
多步推理
将复杂查询分解为子查询。
自适应数据源选择
动态选择 Graph DB / SQL / Vector DB。
验证与纠错
交叉检查检索知识防幻觉。
搜索优化:Better Search → Better RAG
- 语义分块 — Layout Parser 处理复杂文档布局
- 元数据增强 — 关键词、标签、日期支持过滤
- 微调 Embedding — 更好表示领域知识
- Ranker 重排序 — 对 top-N 精排
- Grounding 检查 — 每个短语都能溯源
Vertex AI Search 完整 7 步管道
- 数据收集 — Cloud Storage、BigQuery、网站爬取、第三方连接器
- 处理与标注 — Layout Parser 识别复杂布局
- 向量化 — 多语言 Embedding
- 索引与检索 — ScaNN 毫秒级搜索 + 混合检索
- 排序 — 粗排 → 精排(多维度)
- 生成与验证 — Grounding 检查 + 引用标注
- 服务 — API 和 Widget 两种接入
RAG Engine 编排详解
三种架构模式:
- 单 Agent + 多数据源 — 一个 Agent 配多个 Data Store 工具
- Router + 专业 RAG Agent — 路由到专业检索 Agent
- 迭代精化 RAG — 多轮检索-评估-重检索循环
Chapter 09
企业级 Agent
2025 是企业 Agent 之年。两类 Agent 正在改变企业工作方式。
"助手" Agent
与用户交互:安排会议、分析数据、写代码、营销优化、深度研究。
"自动化" Agent
后台运行:监听事件、自主决策行动、监控异常自动修复。
趋势
知识工作者将从"使用 Agent"进化到"管理 Agent 团队"——分配任务、监控进度、审批关键决策。
Google Agentspace
统一企业搜索
Gemini + Google 搜索,连接 Confluence、Drive、Jira 等。
Agent 创建与管理
无代码/低代码/全代码三种方式。
安全与合规
RBAC、VPC、IAM、企业级 SSO。
真实行动能力
管理异步任务、触发工作流。
Agentspace 五大架构原则
| 原则 | 核心能力 | 实现 |
|---|---|---|
| 信任 | 企业级安全 | SSO · RBAC · VPC · IAM · 审计日志 |
| 智能 | 深度语义理解 | Gemini 语义搜索 · 知识图谱 · 企业术语 |
| 连接性 | 统一数据访问 | 预建连接器 · 通用框架 · 权限保留 |
| 定制化 | 灵活适配 | 三种开发模式 · 个性化 · Agent Gallery |
| 可扩展性 | 全球化支撑 | 多区域 · 多语言 · 自动扩容 |
NotebookLM Enterprise
研究和学习工具。上传多种来源文档到统一工作空间,AI 驱动的摘要/问答,Audio Overview 音频摘要。
NotebookLM 核心能力与企业版差异
核心功能:多源统一工作空间、智能问答(带出处标注)、Audio Overview(播客风格音频摘要)、自动摘要、交叉引用。
企业版增强:组织级数据隔离、Google Workspace 集成、数据保留策略、SSO + 审计日志。
Chapter 10
从 Agent 到 Contractor:Agent 合约
Agent 从原型走向生产,需要像承包商一样——明确合同、验收标准、反馈机制。
当前 Agent 定义太简单(prompt + 工具 + 示例),导致定义不充分 → 行为不可预测 → 生产不可信。
合约核心字段
| 字段 | 说明 | 必填 |
|---|---|---|
| Task Description | 详细无歧义的任务描述 | 是 |
| Deliverables & Specs | 预期产出物 + 验收标准 | 是 |
| Scope | 范围和排除范围 | 否 |
| Expected Cost | 预期资源消耗 | 是 |
| Expected Duration | 预期完成时间 | 是 |
| Input Sources | 可使用的数据源 | 否 |
| Reporting & Feedback | 进度汇报频率和机制 | 是 |
合约生命周期详解
- 合约提交 — 请求方提交结构化任务合约
- 合约评估 — Agent 评估可行性、成本和时间
- 合约协商 — Agent 反馈定义不清晰、成本太高等
- 合约修订 — 根据反馈调整(可多轮迭代)
- 合约执行 — 生成计划,可分解为子合约
- 任务解决 — 候选方案生成 → 评审 → 打分 → 排名
- 交付物提交 — 按规格验收
子合约分解与 AlphaCode 范式
AlphaCode 范式:
- 广泛生成 — 生成大量候选方案
- 自动评审 — 按验收标准自动打分排名
- 演进改进 — 取 top-N 分析优缺点生成改进版本
- 迭代收敛 — 重复直到达标或预算耗尽
核心洞察:与其让 Agent 一次给出"完美"答案,不如让它大量试错然后筛选。
核心假设
让 LLM 以更少约束工作时会产出更高质量结果。合约机制让这成为可能:明确期望 → 允许迭代 → 自动验证 → 直到达标。
Chapter 11
实战案例
理论落地:多 Agent 架构在真实场景中的工作方式。
Automotive AI:车载多 Agent 系统
Navigation
地点 & 路线
Media
音乐 & 播客
Message
语音消息
Manual
汽车手册 RAG
Knowledge
通用知识
四种设计模式在汽车 AI 中的应用
层级模式 — Orchestrator 分析意图路由到正确 Agent。
钻石模式 — 技术输出经 Rephraser 转为友好语言。
点对点 — Agent 互相转交。
协作模式 — 三个 Agent 各出专业信息,Mixer 融合。
关键设计:关键功能设备端运行(即时响应),非关键功能云端(更丰富知识),断网设备端仍可工作。
多轮对话示例:餐厅推荐
用户:"帮我找附近的寿司店"
→ Orchestrator → Navigation Agent → Google Places API
→ Rephraser → "附近有三家寿司店。最近的是樱花寿司,开车3分钟。评分最高的是匠心寿司,4.8星。"
用户:"匠心寿司有没有停车场?"
→ "有免费停车场,约20个车位。需要开始导航吗?"
用户:"好的,顺便放点轻松的音乐"
→ 检测双意图 → Navigation 开始导航 + Media Search 选择音乐
Google Co-Scientist:科研多 Agent 系统
核心方法论:"生成、辩论、演进"。
Co-Scientist 架构与完整流程
- Generation Agent — 文献探索、模拟科学辩论,生成研究假设
- Reflection Agent — 全面审查、模拟评审、锦标赛评审、深度验证
- Ranking Agent — Elo 评分系统排名假设
- Evolution Agent — 交叉启发、简化、扩展、变异
- Proximity Check Agent — 确保假设新颖性
- Meta-review Agent — 撰写结构化研究综述
实际成果:在肝纤维化治疗研究中不仅识别出已有药物,还提出了新机制和药物候选方案。
Chapter 12
Agent Builder 与未来方向
Google 的 Agent 开发平台全景和未来研究方向。
Vertex AI Agent Builder 全景
Agent Engine
托管运行时,自动扩缩容。内置会话、追踪、评估。
Eval Service
LLM/RAG/Agent 评估,集成监控和实验平台。
Search + RAG Engine
全托管搜索,Layout Parser、Embeddings、Ranking 可独立使用。
工具生态
Gen AI Toolbox for Databases、数百 API 连接器、Apigee Hub。
各组件详解
Agent Engine — 支持任意框架部署、会话管理、追踪、自动扩缩容。
Eval Service — 三层评估、预建 autorater 模板、持续监控。
工具生态 — Gen AI Toolbox(安全数据库查询)、Application Integrations(数百 SaaS 连接器)、Apigee Hub(统一 API 管理)。
未来研究方向
高级评估方法
过程评估、AI 辅助评估、标准化 benchmark。
多 Agent 协调
改进通信协议和协作机制。
真实世界适应
动态环境适应,设备端 vs 云端平衡。
可解释性 + 长期记忆
行为透明,更复杂记忆机制。
通信协议 + 合约化
Agent 间标准、升级为 Contractor。
高效开发者周期
Build vs Buy,聚焦数据和用户。
Build vs Buy 决策框架
- Buy — 用平台方案,跟随行业进展,减少维护成本
- Build — 完全控制,深度定制,但需持续投入
- 白皮书建议 — 精力聚焦在差异化数据和用户体验上,底层基础设施尽量用平台
白皮书结语
The future of AI is agentic. 现在就是构建的时刻。