5小时整理60页《Google Agent指南》，不懂Agent的包教包会

关注

原创最新推荐文章于 2026-07-23 16:58:19 发布 1k 阅读 AI 写同款· GEO 优化 ›

Google Agent开发指南：从入门到实战 AI Agent作为智能自动化领域的核心技术，通过自主决策、记忆能力和工具调用实现复杂任务自动化。其核心原理结合了自然语言处理(NLP)和机器学习技术，能够显著提升业务流程效率。在Google技术栈中，Dialogflow CX适合对话型场景，而Vertex AI Agent Builder更适用于数据驱动的智能决策。本指南系统性地介绍了从环境搭建、意图定义到企业级部署的全流程，特别针对中文场景的实体识别和时间解析提供了实用解决方案。通过真实案例展示，如会议助手和外贸询盘处理Agent，验证了该技术在节省人阅读详情

花了五个小时，把 Google 白皮书拆解成一个可执行的 Agent 心智模型的长文。

没什么花里胡哨的新名词，但把模型、工具、编排、记忆、训练这几件核心事讲得比较完整，对于想要了解的Agent的初学者，是很不错的选择。

Google最近发布了一篇关于Agent长达60页的文件：《初创公司技术指南：AI Agents》，这份报告从宣传来说表达了自己与之前偏理论的文章不一样，他还是暴露了不少细节技巧，对正在做Agent的各位应该有些帮助。

只不过我实际读下来，技巧什么的给的很一般，但是一份非常不错的Agent入门级学习读物，所以也推荐给大家：

首先，Agent的能力基石（也就是对工具的调用能力）是模型的Function Calling，而这个识别工具是否应该被调用的能力是微调训练的结果。

比如，Agent可以使用数据库工具获取客户订单做个性化推荐、根据用户指令调用邮件 API 发送电子邮件、甚至自动执行金融交易…

上述每个功能都需要模型与外部世界（工具、数据）做交互，只要具备自主规划和多步任务执行能力的系统，就是Agent。

Agent架构概览

再次寄出这章经典Agent架构图：

现代 AI Agent 通常由四层核心组件构成：

一、模型层：

基础模型（如各类大型语言模型），负责自然语言理解与生成，在生产应用里面往往不会依赖单一模型，甚至会有很多小模型微调场景做其中简单任务。

二、工具层：

外部工具和服务，包含各种API如数据库、搜索引擎等，帮助Agent感知外部世界并执行实际操作。

现阶段来说，Tools是Agent真正的核心，而且Tools调用不准也是Agent架构最大的难点，当前我们在生产环境使用Skills技术 + 强意图也最多把准确率做到90%左右。

所以，整个Agent的成熟还任重道远。

三、编排层：

Agent的“大脑”，负责编写提示词、执行推理框架、维护对话状态和调用工具。该层实现了智能体的计划、推理、决策和反馈循环。

这样说大家可能听不懂，也就是ReAct架构就是这里的编排层了，也是主要代码组成部分：

负责组织历史对话（状态）；
决定什么时候调用模型，什么时候调用工具；
决定什么时候结束推理；
决定怎么拼提示词；

他定义“每一轮”里的语言生成结构（Thought、Action、Observation）

... → 推理(Thought) → 行动(Action) → 观察(Observation)  → ...

ReAct = Reason + Act：

Reasoning： 让LLM思考"为什么"和"如何"执行行动；
Acting： 让LLM执行具体行动并与环境交互；
循环反馈： 通过观察结果驱动下一步推理；

四、记忆层：

包括短期记忆（对话上下文、近期交互）和长期记忆（知识库、历史数据、个人偏好等）。记忆层用于存储和检索与任务相关的信息，以支持多轮交互和知识补充：

严格来说，Agent最恼火的就是记忆层的处理，这也是上下文工程的本身，他需要解决**数据应该如何与AI交互，保证每次AI都能拿到相关数据。**这里展开有三点：

每次检索能不能拿到对应的数据；
数据是不是合适，这块的合适包括会不会多、会不会少，多了费Token是小事，但可能干扰模型、少了就容易出问题；
生成对不对，这个建立在检索正确，数据组织正确的情况下，模型最终输出是不是符合预期；

这里是整体的交互架构图：

图示而言，Agent执行流程可概括为：用户输入 → 编排层处理 → 模型生成思路 → 决策调用工具或输出结果 → 工具执行获得反馈 → 更新记忆并继续循环，直至目标完成。

在 ReAct 框架下，Agent重复执行**思考（Thought）→行动（Action）→观察（Observation）**的循环，直到产生最终答案。

最后，与单纯的模型（LLM）相比，Agent有以下关键区别：

知识来源： 模型只能依赖于训练数据，知识静态；而Agent通过工具扩展知识，可以实时访问外部信息。
上下文管理： 模型单次推理没有会话记忆；Agent可以维护交互历史，实现多轮连续对话。
推理框架： 模型输出结果往往依赖单一提示；Agent具备内置的认知架构和推理策略（如链式思维、反思框架、树式思维等），能够在编排层中循环迭代推理步骤；

接下来我们具体展开说下Agent的四个核心组件：

编排层与认知架构

编排层是智能体系统的核心控制单元，负责组织信息流和执行推理循环。它模拟人类在做复杂任务时的认知过程：先获取信息、然后制定计划、执行行动、再根据反馈调整计划，不断循环直到完成目标。

一个常见的比喻是**“厨师准备复杂菜品”**：厨师会根据顾客需求获取食材信息，思考烹饪步骤，然后实际烹饪，过程中可能根据味道反馈不断调整方法。

类似的，Agent的编排层会按照设定的推理框架反复迭代，驱动模型生成“思考”并做出“行动”决策。

常见的推理框架大同小异，这里一定需要了解的是两个东西ReAct与CoT，除此之外可以延伸到ToT：

ReAct在前面我们做了基础介绍，该框架强调模型在回答前进行连续的内省和行动选择，有助于提高答案的准确度和可追溯性；

CoT（思维链）引导模型通过生成中间推理步骤来分解问题，促使其在最终答案前先列举思考过程，这种框架可以增强模型解决复杂问题时的准确性（幻觉问题）。

**ToT（思维树）**是在 CoT 的基础上，允许模型在多个备选思路间做比较，适用于需要探索多种方案的策略性任务，目的依旧是提升对复杂问题的解决能力。

篇幅有限，我们只讨论ReAct和CoT的配合即可（其他的都类似）：

ReAct和CoT

首先，ReAct与CoT都是推理策略框架也就是Agent四大组件核心的编排层具象化实现，他们都描述的是如何组织模型的推理过程、生成步骤、提示词结构。

换句话说，ReAct是代码的核心，是AI工程的核心，他会决定如何去与记忆系统、工具系统做配合。

然后，ReAct逻辑上与CoT是同级别的，但现在更多的是在组合使用，显得CoT是ReAct的一个过程产物，其实并不是的，逻辑上CoT也可以调用工具；

只不过现在从流行范式的角度来说，ReAct被用作主框架的时间会多一点，并且过程中会包含很多CoT的部分，这里的结果是：ReAct 是容器，CoT 是内容。ReAct 是最“Agent”化的、CoT 是最基础的。

ReAct 规定了：先思考（Thought）→ 行动（Action）→ 等待结果（Observation）→ 再思考…

而这个“Thought”怎么写？通常就是一个 Chain of Thought 推理块。

举个简单例子：

让 Agent 回答**“某公司员工请假流程”**的问题，Agent 需要：

读取用户的问题
从知识库中检索文档
分析内容结构
输出清晰步骤

这块的简要流程是：

User: 请问我们公司请假流程是什么？Step 1:Thought: 先查找关于“请假流程”的文档。Action: search_docs("请假流程")Observation: 找到文档《员工手册》第4章，列出了流程步骤。Step 2:Thought:首先读取这部分内容，理解流程的顺序。- 第一步是员工提交请假申请- 第二步是直属上级审批- 第三步是HR备案因此我可以组织一份清晰的回答。Action: NoneFinal Answer: 请假流程如下：1）提交申请；2）主管审批；3）HR备案。

这个 “Step 2” 的 Thought 部分就是一个简单的 CoT，模型在没有行动前，分步思考、提取、组织信息，这是典型的思维链。

为什么这么用也很简单：Agent架构中也不可能每一步都调用工具，很多时候只是在“组织思维/语言”，CoT可以有效降低幻觉率。

总而言之，ReAct 框架里可以有很多 CoT 内容穿插其中，这种组合也是最常见、最稳的做法，大家记住这点就行，这就是Agent的编排层。

再结合Google报告的案例，大家应该可以完全理解了：

```plaintext
User: 我想订一张下周从北京到上海的机票。Thought: 我需要查询航班信息并进行比较。Action: 调用【航班搜索】工具Action Input: {“from”: “北京”, “to”: “上海”, “date”: “下周”}Observation: 航班工具返回了多班次航班信息。Thought: 我应该挑选价格和时间合适的航班。Final Answer: 根据查询结果，下周从北京到上海的航班有…（列出信息）。

状态管理

除基本框架之外，编排层还负责维护交互状态和历史记忆。

与模型的单轮对话不同，Agent需要管理对话历史，将先前的对话内容、用户指令和工具反馈纳入状态，否则的话多轮对话就会胡言乱语。

例如，在咨询类对话中，Agent会记住用户之前的问题和上下文，不断积累信息，这对解决复杂问题和提供连续服务至关重要。

总之，编排层就像Agent的“大脑”，通过循环的反馈机制和提示工程框架，引导模型合理利用已有信息和工具一步步实现目标。

状态管理好坏直接关系到Agent产品的最终表现，只不过这里的状态管理极其困难，如果展开的话万字都拿不下来…

工具体系

工具是模型与外部世界之间的桥梁，使得Agent可以访问并处理真实信息

根据我之前的实践经验：Agent最难的部分是状态管理，最烦（不稳定）的部分是意图识别，工作量最大的部分是工具体系…

常见的工具类型包括扩展（Extensions）、函数调用（Functions）和数据存储（Data Stores）等，它们各自承担不同职责，共同构建了智能体与外部环境交互的能力。下面分别介绍这几种工具类型:

扩展

所谓扩展也就是提前配置好的一批可调用 API 模块 + 模型能看懂的调用说明，其底层基础是模型的Function Calling，目的是让模型不需要知道很多 API 的细节，只需要给关键词：

Action: 航班查询  Action Input: {from: "北京", to: "上海", date: "2025-12-10"}

这里再给一个配置信息：

{  "name": "search_flights","description": "查询指定日期的航班信息","params": {    "from": "出发城市",    "to": "目的城市",    "date": "出发日期（YYYY-MM-DD）"  },"example_calls": [    {      "user_input": "我想查明天从北京飞上海的航班",      "action": "search_flights",      "action_input": {        "from": "北京",        "to": "上海",        "date": "2025-12-10"      }    }  ]}

函数调用

函数调用与扩展类似（都是Function Calling），也是提供给模型调用外部功能的接口，但它更侧重于客户端（应用端）执行，而不是在智能体服务器端：

与扩展对比的主要差别在于，扩展在智能体端执行调用外部服务，而函数在客户端执行。这意味着即使模型选择了某个函数，实际的 API 调用可能会在另一个服务层面完成。

这里大家读起来可能有点绕，因为扩展和函数相似度很高，我们这里做下举例说明：

扩展属于系统自己干，你说“帮我查天气”，它自己调接口、自己拿数据、自己干：

模型：我需要查下天气Agent系统：好的，我有手，我来调 API weather.com 获取数据

函数是模型自己不做事，它只是告诉你“你去做”：

模型：我建议调用函数 playVideo({videoId: 123})应用前端：收到，我来执行这个函数（比如调播放器）

这种差异的原因是安全性、离线、异步等原因，中断式调用用函数，非中断式用扩展：

# 扩展案例：Action: query_weatherAction Input: {"city": "北京", "date": "2025-12-10"}# Agent系统逻辑（自动执行）：def agent_runtime():    if action == "query_weather":        result = requests.get(f"https://api.weather.com?city={city}&date={date}")        send_back_to_model(result)# 函数案例，中断式：Function Call: open_cameraArgs: {"resolution": "1080p"}# 客户端 / 浏览器执行（你来写）：def on_function_call(fn_name, args):    if fn_name == "open_camera":        open_webcam(args["resolution"])

数据存储

数据存储为Agent提供了“长期记忆”和知识库的功能，特别适用于需要查询大量结构化或非结构化信息的场景。

核心思想是将外部文档或数据库转换成向量索引，让模型通过检索来获取最新内容，从而扩展其知识边界。常见做法是构建向量库或知识库，将文档、网页、表格等预处理为高维嵌入存储：

例如，对于公司内部知识库问答，智能体会先将用户问题转换为向量并检索预索引的内部文档，得到的相关文档段落作为补充信息提供给模型。这样，生成的回答就基于最新的业务手册或法规文本，而不是仅凭模型训练时有限的数据。

如图示例所示，用户查询“公司在北美的最新业务规模如何？”，智能体先检索财经报告和市场数据，然后在 ReAct 循环中利用这些检索结果进行综合推理和回答：

其实从这部分内容质量来说，Google的报告写得挺一般的，作为科普读物挺不错的…

记忆系统

在Agent系统中，记忆层不仅负责保存上下文、支撑多轮对话，它更深层的职责，是回答这样一个问题：

数据如何与AI交互，才能让大模型“真正理解任务”？

这一问题的回答，近来常被包装为一个新术语：上下文工程（Context Engineering）。

但从本质看，它仍是对“如何构造有效Prompt”的深化和结构化设计，是提示词工程在复杂任务落地场景下的自然演进。

上下文工程

通常我们将 Agent 的记忆系统划分为两个层次：

一、短期记忆（Short-Term Memory）

指当前会话的上下文历史，包括用户输入、模型回复、中间推理痕迹；

多保存在编排层的对话状态中，用作 Prompt 上下文构建。

二、长期记忆（Long-Term Memory）

指跨会话的知识存储，如用户偏好、历史数据、组织内部资料、文档库等；

通常通过向量检索（RAG）等方式动态取用，实现在运行时“补全知识”。

但真实场景中，记忆系统远不止“存+取”这么简单，它的核心目标是：

为大模型提供“恰到好处”的信息，既不过多打扰模型，也不遗漏关键信息

这引出了“上下文工程”的实操三难点：

拿得到吗？ 检索逻辑是否合理，是否漏掉关键信息？
拿得准吗？ 内容是否相关？是否过多干扰模型或严重缺漏？
用得对吗？ 最终组织进 Prompt 的方式是否有效激发模型输出？

从工程角度讲，上下文就像 Prompt 的RAM，容量有限但直接决定模型运行表现。设计合理的上下文组织策略，是Agent系统最重要的竞争力之一。

根据之前的经验，可以把上下文工程操作模式分为四类：

手法	核心思路	类比	常见场景
1. 记录式（Write）	让 AI 随时把重要细节写进“随身笔记”	人类做会议速记	ChatGPT 存用户常点外卖、偏好等
2. 甄选式（Select）	从资料中挑出最 relevant 的再喂给模型	图书管理员找指定章节	Code Agent 检索函数文件、知识点
3. 精简式（Compress）	当信息爆棚，用摘要、提炼、去冗余手段减轻模型负担	给论文写摘要	Claude 快满窗口时自动压缩历史对话
4. 分隔式（Isolate）	将复杂任务拆分给多个“助手”，各自记忆不同上下文	项目经理分派子任务	Swarm Agent 中多个子模型分工协作

这些方法的组合，构成了真正能用、能落地的上下文工程，其实大家也可以看出来了，尽管上下文工程、Agent的记忆系统听起来很屌，其本质还是复杂的提示词工程…

最后回归到 Agent ReAct 框架，我们再看看四大组件的关系：

ReAct 框架中的记忆层角色

在ReAct框架中，每一个 Thought 的质量，严重依赖于CoT，而CoT又严重依赖于记忆系统提供的信息是否充足、是否准确、是否干扰最小。

在执行过程中，记忆系统负责为 Thought 构建上下文输入，即 Prompt 中的 Memory 区块。一个典型的 ReAct 调用链如下：

User: 我需要找一张明天下午从北京去上海的高铁票-----------------Thought: 我需要查询高铁票信息Action: 查询高铁 API（输入城市和时间）Observation: 返回多个班次和时间段Thought: 我挑选一个下午出发、价格合适的车次Action: NoneFinal Answer: 为您找到两张明天下午从北京到上海的高铁票...（输出结果）

在这个过程中：

若之前用户已经表达过偏好如“只要一等座”、“不坐动车”等，长期记忆需要提供这些偏好信息；
若用户此前提过“和昨天流程一样”，短期记忆要准确提取那次会话内容；
若调用查询工具返回大量内容，记忆系统需判断提取哪些 Observation 塞入下一步 Prompt；

从这里大家也可以看出ReAct的重要性和复杂度了，他是推动推理循环向前的基础。

另一方面，为什么说上下文工程是整套 Agent 架构最容易忽视、但最容易出问题的部分？因为它一旦做不好，模型生成的 Thought 将会是空转、偏离、或者幻觉的。

总而言之，这块是事实上的难点，大家好好体悟吧。

强化与训练

模型发展了三年经历了三个时代：百模大战模型训练 → 套壳为荣，提示词工程 → CoT，也就是当前业内普遍对于模型训练是十分排斥的，这意味着技术负责人说出要训练，这笔预算可能会有很大的压力…

只不过，虽然基础模型已经具备强大的能力，但要让模型在特定Agent架构中发挥最佳效果，往往需要针对性地学习使用新工具和新知识。白皮书总结了三种主要方法：

一、上下文内学习（In-context Learning）：

在推理时为模型提供任务相关的提示、工具说明和少量示例，让模型“在线”学习如何使用工具。

例如，通过几个示例对话展示在类似场景下使用哪种工具、怎样调用，可提升模型的工具调用准确率。

ReAct 本身就是一种典型的上下文示例驱动的提示框架。

二、检索式上下文学习（Retrieval-based In-context Learning）：

自动检索和选择最相关的知识片段、示例或工具说明作为提示的一部分，从外部记忆库（如“示例存储”或知识库）中动态构造提示。

这类似于给模型“提供一本动的菜谱”：让它根据查询从知识库检索示例来指导决策。

三、微调训练（Fine-tuning）：

最后就是微调了，使用大量特定任务的示例数据对模型进行微调，可以更好的提高效果。比如，为客服智能体微调模型，让它学会优先调用知识库工具而不是直接“胡乱回答”。

这里是一些训练数据案例，大家感受下就好：

{  "context": "【内部文档摘录】本公司标准退货政策为：自收货之日起 7 日内可无理由退货，超过 7 日不予受理。","question": "你们退货政策是怎样的？","answer": "根据我们的标准退货政策，自收货之日起 7 日内您可以无理由退货，超过 7 日则无法办理退货。"}{"goal": "帮用户规划一个 3 天的东京自由行，预算适中，喜欢美食和动漫文化。","tools": ["search_flights", "search_hotels", "search_attractions"],"plan": {    "steps": [      {        "step_id": 1,        "description": "确定出发和返回日期，并查询往返机票选项",        "tool": "search_flights",        "inputs": ["出发城市", "东京", "出发日期", "返回日期"]      },      {        "step_id": 2,        "description": "根据预算和地理位置搜索酒店（优先新宿、涩谷附近）",        "tool": "search_hotels",        "inputs": ["东京", "3 晚", "预算范围"]      },      {        "step_id": 3,        "description": "根据用户兴趣筛选景点（动漫文化、美食街）并按天分配",        "tool": "search_attractions",        "inputs": ["东京", "动漫", "美食"]      }    ]  }}{"messages": [  {"role": "system", "content": "你是一个任务规划助手，收到用户目标后只输出 JSON 格式的任务拆解计划。"},  {"role": "user", "content": "帮我规划一个 3 天的东京自由行，预算适中，我喜欢美食和动漫。"},  {    "role": "assistant",    "content": "{\"steps\": [\      {\"step_id\": 1, \"description\": \"确认出发/返回日期并查询机票\", \"tool\": \"search_flights\"},\      {\"step_id\": 2, \"description\": \"根据预算和位置选择酒店\", \"tool\": \"search_hotels\"},\      {\"step_id\": 3, \"description\": \"为 3 天分别安排景点和美食\", \"tool\": \"search_attractions\"}\    ]}"  }]}

在生产环境上，这三个往往会混用。