Google揭秘Agent架构三大核心：工具、模型与编排层实战指南

由推理、逻辑及访问外部信息所组成的、均连接至生成式AI模型的组合，引发了智能体这一概念。

人类在处理复杂的模式识别任务方面非常出色。然而，他们在得出结论之前通常会依赖工具——例如书籍、谷歌搜索或计算器——来补充自身的先验知识。与人类类似，生成式AI模型也可以被训练为使用工具，以获取实时信息或提出现实世界的操作建议。例如，模型可以借助数据库检索工具访问特定信息（如客户的购买历史），从而生成个性化的购物推荐。或者，根据用户的查询，模型可以通过调用多个API来代表你向同事发送电子邮件回复，或完成一笔金融交易。要做到这一点，模型不仅需要访问一组外部工具，还需要具备以自主方式规划和执行任务的能力。这种将推理、逻辑与外部信息访问能力相结合，并连接至生成式AI模型的组合，引发了“智能体”的概念——即一种超越生成式AI模型独立功能的程序。本白皮书将更详细地探讨上述内容及相关议题。

最基础的生成式AI智能体可被定义为一种应用：它通过观察环境并利用可用工具采取行动，以实现特定目标。智能体具备自主性，能够在无需人类干预的情况下独立行动，尤其是在被赋予明确目标或任务的情况下。智能体在实现目标时也可以是主动的——即使没有人类给出明确指令，它也能通过推理判断下一步应采取什么行动以达成最终目标。尽管人工智能领域对智能体的概念较为宽泛且强大，但本白皮书将聚焦于生成式AI模型在出版时所能构建的特定类型智能体。

要理解智能体的运作机制，首先需介绍驱动其行为、行动和决策的核心组件。这些组件的组合可被描述为一种“认知架构”，通过不同组件的组合可形成多种架构方案。从核心功能出发，智能体的认知架构包含三个基本组件，如图1所示

图1：通用智能体架构及其组件构成

在智能体的范畴中，模型指的是作为智能体流程中心决策者的LM。智能体使用的模型可以是任意大小（小型/大型）的一个或多个LM，只要它们能够遵循基于指令的推理和逻辑框架（如ReAct、思维链或思维树）。模型可以是通用型、多模态或根据特定智能体架构的需求进行微调。为获得最佳生产效果，应选择最契合预期终端应用的模型，并理想化地选用已针对认知架构中计划使用的工具进行过数据特征训练的模型。需要注意的是，模型通常不会基于智能体的具体配置参数（例如工具选择、编排/推理设置）进行训练。不过，可通过提供展示智能体能力的示例（包括智能体在不同场景下使用特定工具或推理步骤的实例）进一步优化模型以适配任务需求。

基础模型尽管在文本和图像生成方面表现出色，但仍受限于无法与外部世界交互的能力。工具填补了这一缺口，使智能体能够与外部数据和服务互动，从而解锁超越基础模型自身能力范围的更多操作可能性。工具的形式多样，复杂程度不一，但通常与常见的Web API方法（如GET、POST、PATCH和DELETE）保持一致。例如，工具可以更新数据库中的客户信息，或获取天气数据以影响智能体向用户提供的旅行建议。借助工具，智能体能够访问并处理现实世界的信息，这使其能够支持更专业的系统，例如RAG，显著扩展智能体的能力边界，远超基础模型的独立功能。下文将进一步详细探讨工具的作用，但最重要的是理解：工具弥合了智能体内部能力与外部世界之间的鸿沟，解锁了更广阔的应用可能性。

编排层描述了一个循环过程，用于管理智能体如何接收信息、进行内部推理，并通过该推理指导下一步行动或决策。通常情况下，这一循环将持续至智能体达成目标或达到某个停止节点。编排层的复杂程度会因智能体及其执行任务的不同而存在显著差异：有些循环可能是基于决策规则的简单计算，而另一些可能包含链式逻辑、涉及额外的机器学习算法，或采用其他概率推理技术。我们将在认知架构章节进一步探讨智能体编排层的具体实现细节。

为了更清晰地区分智能体与模型之间的差异，建议参考下图：

想象一位厨师在繁忙的厨房中忙碌。他们的目标是为餐厅顾客制作美味佳肴，这一过程涉及一个规划、执行与调整的循环过程。

他们收集信息，例如顾客的订单、储藏室和冰箱中的可用食材；

• 基于已收集的信息，他们进行内部推理以确定可制作的菜品及风味组合；

• 他们采取行动完成菜品制作：切菜、调配香料、煎肉等。

在整个流程中，厨师会根据需要调整操作——例如当食材耗尽或收到顾客反馈时，优化计划并利用过往结果决定下一步行动。这种信息输入、规划、执行与调整的循环过程，描述了厨师为实现目标所采用的独特认知架构。

与厨师类似，智能体可通过认知架构达成目标：通过迭代处理信息、做出决策，并基于历史输出优化下一步行动。智能体认知架构的核心是orchestration layer，负责维护记忆、状态、推理与规划。它借助快速发展的prompt engineering及相关框架引导推理与规划，使智能体能更高效地与环境交互并完成任务。目前提示工程框架与任务规划的研究进展迅速，已形成多种方法（以下列举部分主流框架与推理技术）：

•ReAct：一种提示工程框架，为语言模型提供“推理并行动”的思维策略，支持在有/无上下文示例的情况下处理用户查询。ReAct提示技术已证明优于多项SOTA基线模型，并提升了LLM的人机协作性与可信度。

•CoT：通过中间步骤实现推理能力的提示工程框架。其子技术包括self-consistency、active-prompt和multimodal CoT，各自针对特定应用场景有不同优劣。

•ToT：适用于探索性或战略前瞻任务的提示工程框架。它扩展了思维链提示技术，允许模型探索多种思维链作为中间步骤，从而通过语言模型实现通用问题求解。

智能体可选择上述任一推理技术或其他方法，为用户请求选择最佳下一步行动。例如，假设一个智能体被编程为使用ReAct框架处理用户查询，其流程可能如下：

1. 用户向智能体发送查询

2. 智能体启动ReAct序列

3. 智能体向模型提供提示，要求生成下一步ReAct步骤及其输出：
   a. 问题 ：用户查询的输入问题（包含在提示中）
   b. 思考 ：模型对下一步行动的推理
   c. 行动 ：模型决定的具体行动（此处可能发生工具选择）
   d. 例如，行动选项可为[航班查询、搜索、代码生成、无工具选择]，前3项代表可用工具，最后一项表示“无需工具”
   e. 行动输入 ：模型为工具提供的具体输入参数（如有）
   f. 观察 ：行动/输入序列执行后的结果
   j. 此“思考-行动-输入-观察”过程可根据需要重复N次
   h. 最终答案 ：模型对原始用户查询的最终回应

4. ReAct循环结束，最终答案返回给用户

图2：编排层中采用ReAct推理的智能体示例

综上所述，智能体响应的质量直接取决于模型对各类任务的推理与行动能力，包括其选择合适工具的能力以及工具定义的完善程度。就像厨师通过严谨推理（如判断食材搭配）和可靠信息（如顾客反馈）精心制作一道佳肴，智能体也需要通过严谨的推理和可靠信息实现最佳结果。下一节将深入探讨智能体与最新数据连接的多种方式。如图2所示，模型、工具与智能体配置协同工作，根据用户的原始查询提供有事实依据且简洁的回复。尽管模型本可通过先验知识臆测答案（产生幻觉），但它转而使用工具（航班查询）来搜索实时外部信息。该附加信息提供给模型后，使其能够基于真实事实数据做出更明智的决策，并向用户总结相关信息。

尽管语言模型在信息处理方面表现出色，但它们缺乏直接感知和影响现实世界的能力。这限制了其在需要与外部系统或数据交互的场景中的实用性。从某种意义上说，语言模型的能力仅与其训练数据所涵盖的内容相当。然而无论我们向模型输入多少数据，它们始终缺乏与外部世界交互的基本能力。那么，我们如何赋予模型实时、情境感知的外部交互能力？Functions、Extensions、Data Stores和Plugins均为实现这一关键能力的可行方式。

尽管这些功能名称各异，但工具正是建立基础模型与外部世界之间连接的桥梁。这种与外部系统和数据的连接，使智能体能够执行更广泛的多样化任务，并以更高的准确性和可靠性完成操作。例如，工具可支持智能体调整智能家居设置、更新日历、从数据库中检索用户信息，或根据特定指令集发送邮件。

截至本白皮书发布日期，谷歌模型可交互的三类主要工具为：Extensions、Functions和Data Stores。通过为智能体配备工具，我们解锁了其巨大的潜力——不仅能够理解世界，还能主动影响世界，从而打开通往无数新应用场景的大门。

理解Extensions最直观的方式是将其视为一种标准化的桥梁，弥合API与智能体之间的鸿沟，使智能体能够无缝执行各类API操作，无论其底层实现细节如何。假设你构建了一个旨在协助用户预订航班的智能体，已知需要通过Google Flights API检索航班信息，但尚未明确如何让智能体调用该API接口。

图3：智能体如何与外部API交互？

一种方法是编写自定义代码，接收用户输入的查询，解析其中的相关信息，然后执行API调用。例如，在航班预订场景中，用户可能输入“我想预订从奥斯汀到苏黎世的航班”。此时，我们的自定义代码需要从查询中提取“奥斯汀”和“苏黎世”作为关键实体后才能发起API请求。但如果用户仅表示“我想预订到苏黎世的航班”而未提供出发城市，API调用会因缺少必要数据而失败。为处理此类边缘情况和极端场景，需要额外编写更多代码。这种方法不具备可扩展性，且在任何超出自定义代码覆盖范围的场景中都可能失效。

一种更具弹性的方法是使用Extension。扩展通过以下方式弥合智能体与API之间的鸿沟：

1. 通过示例教会智能体如何使用API端点；

2. 教会智能体调用API端点时所需的参数或参数。

图4：扩展将智能体连接至外部API

Extensions可以独立于智能体构建，但需作为智能体配置的一部分提供。智能体在运行时通过模型和示例决定调用哪个扩展（如有）以解决用户查询。这突显了扩展的核心优势——其内置的示例类型使智能体能够根据任务需求动态选择最合适的扩展。

图5：智能体、扩展与API的一对多关系

可以将这一过程类比为软件开发者在解决用户问题时选择API端点的方式。如果用户需要预订航班，开发者可能会调用Google Flights API；如果用户想了解当前位置附近的咖啡店，开发者则可能使用Google Maps API。同理，智能体/模型堆栈会通过一组已知的Extensions判断哪个最适合当前用户查询。若想实际体验扩展功能，可在Gemini应用中通过“设置 > 扩展”启用测试扩展。例如，启用Google Flights扩展后，向Gemini询问“显示下周五从奥斯汀飞往苏黎世的航班”即可触发扩展功能 。

为简化扩展的使用流程，Google提供了一些开箱即用的扩展，可快速导入项目并仅需少量配置即可使用。例如，代码片段1中的Code Interpreter扩展允许用户通过自然语言描述生成并运行Python代码 。

代码片段1：代码解释器扩展可以生成并运行Python代码

总结而言，Extensions为智能体提供了一种多维度感知、交互并影响外部世界的途径。扩展的选择与调用依赖于示例的引导，而这些示例均定义在扩展配置中。

在软件工程领域，函数被定义为可独立完成特定任务的代码模块，且可按需复用。当软件开发者编写程序时，通常会创建多个函数执行不同任务，并定义调用函数A或函数B的逻辑，同时明确其输入与输出规范。

在智能体领域，函数的工作原理高度相似，但开发者角色被模型取代。模型可基于已知函数列表，自主判断何时调用具体函数及其所需的参数。函数与扩展的主要区别体现在以下方面：

1. 模型仅输出函数及其参数，但不执行实时API调用 ；

2. 函数在客户端执行，而扩展在智能体端执行 。

再次以Google Flights为例，函数的简单架构示例如图7所示。

图7：函数如何与外部API交互？

需要注意的主要区别在于，Function和智能体均不直接与Google Flights API交互。那么，API调用究竟是如何发生的呢？

通过函数，实际API端点的调用逻辑从智能体转移至客户端应用（如图8和图9所示）。这种方式使开发者对应用程序中的数据流拥有更细粒度的控制。开发者选择使用函数而非扩展的常见原因包括：

• API调用需在应用栈的另一层执行 （例如中间件系统、前端框架等），超出智能体架构的直接流程；

• 安全或身份验证限制 导致智能体无法直接调用API（例如API未暴露于互联网，或智能体基础设施无法访问）；

• 时间或操作顺序约束 阻碍智能体实时调用API（例如批处理操作、需人工审核的环节）；

• 需要对API响应附加数据转换逻辑 （智能体无法完成此类处理）。例如，若某API端点未提供结果过滤机制，客户端的函数调用可为开发者提供额外的数据转换机会；

• 开发者希望在不部署额外API基础设施的前提下迭代智能体开发 （函数调用可模拟API的“存根”功能）。

尽管两种方法在内部架构上的差异较为细微（见图8），但函数调用提供的额外控制能力及其对外部基础设施的解耦依赖，使其成为开发者更具吸引力的选择。

图8：扩展与函数调用中客户端与智能体端的控制权区分

模型可通过调用函数处理复杂的客户端执行流程，以满足终端用户需求——此时智能体开发者可能不希望语言模型直接管理API执行（而Extensions正是为此设计的）。例如，假设一个智能体被训练为旅行礼宾服务，需与希望预订假期行程的用户交互。目标是让智能体生成一份城市列表，供我们的中间件应用下载图片、数据等用户行程规划所需的资源。用户可能提出类似请求：

“我想和家人去滑雪，但不确定去哪里。”

在常规提示中，模型输出可能如下：

“当然，以下是适合家庭滑雪的城市列表：

• 美国科罗拉多州Crested Butte

• 加拿大不列颠哥伦比亚省Whistler

• 瑞士Zermatt”

尽管上述输出包含所需数据（城市名称），但格式并不理想，难以解析。通过Function Calling，我们可教会模型以结构化格式（如JSON）输出数据，便于其他系统解析。若用户提供相同输入提示，函数生成的JSON输出示例可能如代码片段5所示。

代码片段5：显示城市列表及用户偏好的示例函数调用负载

该JSON负载由模型生成后，将发送至我们的客户端服务器以执行所需操作。在本例中，我们将调用Google Places API接口，将模型提供的城市列表作为参数进行检索，获取对应图片，并将其格式化为富文本内容返回给用户。请参见图9中的序列图，其中逐步展示了上述交互细节。

图9：展示函数调用生命周期的序列图

图9的示例结果表明，模型被用于补全客户端UI调用Google Places API所需的参数 （即“填空”）。客户端UI通过模型返回的函数参数管理实际的API调用。这只是函数调用的一个用例，其他常见场景还包括：

• 希望语言模型推荐代码中可用的函数，但不希望将credentials硬编码到代码中 。由于函数调用本身不执行函数，因此无需在代码中包含凭证信息。

• 您正在运行可能耗时超过几秒的异步操作。这类场景非常适合使用函数调用，因为这属于异步操作。

• 您希望在与生成函数调用及其参数的系统不同的设备上执行函数。

关于函数，需要牢记的一个关键点是：它旨在为开发者提供更多控制权，不仅限于API调用的执行，还包括整个应用的数据流。以图9的示例为例，开发者选择不将API信息返回给智能体，因为这些信息对智能体后续操作无实际意义。然而，基于应用架构设计，也可能需要将外部API调用的数据返回给智能体，以影响其未来的推理、逻辑和行动决策。最终，具体应用的适配性由开发者决定。

为实现上述滑雪假期场景的输出效果，我们需要构建gemini-1.5-flash-001模型所需的各个组件。首先，将display_cities函数定义为一个简单的Python方法。

代码片段6：显示城市列表的示例Python方法

接下来，我们将实例化我们的模型，构建Tool，然后将用户的查询和工具传入模型。执行以下代码后，将生成如代码片段底部所示的输出结果。

代码片段7：构建工具、将用户查询传递给模型并触发函数调用

综上所述，函数提供了一个简洁的框架，使应用开发者能够对数据流和系统执行进行细粒度控制 ，同时充分利用智能体/模型生成关键输入的能力。开发者可选择性地决定是否通过返回外部数据让智能体持续参与流程 ，或根据具体应用架构需求省略这一环节。

将语言模型想象为一座藏书浩瀚的图书馆，其中存储着其训练数据。但与不断新增藏书的图书馆不同，这座图书馆的知识是静态的，仅保留其初始训练时所掌握的知识。这带来了挑战——现实世界的知识在持续演进。Data Stores通过提供动态且最新的信息解决了这一限制，确保模型响应始终基于事实性和相关性 。

考虑一个常见场景：开发者可能需要向模型提供少量额外数据，例如电子表格或PDF文件 。

图10：智能体如何与结构化和非结构化数据交互？

数据存储允许开发者以原始格式向智能体提供额外数据，从而无需进行耗时的数据格式转换、模型重新训练或微调。数据存储会将输入文档转换为一组向量数据库嵌入，供智能体提取所需信息，以补充其下一步行动或对用户的响应。

图11：数据存储将智能体连接至多种类型的实时数据源

在生成式AI智能体框架中，数据存储通常以向量数据库的形式实现，开发者希望智能体在运行时能够访问该数据库。尽管此处不对向量数据库展开深入讨论，但关键在于它们以向量嵌入（即一种高维向量或数学形式）存储数据，反映所提供的数据特征。近年来，数据存储与语言模型结合的典型案例之一是RAG类应用的实现。这类应用旨在通过为模型提供以下格式的实时数据，扩展其基础训练数据的知识广度与深度：

• 网站内容

• 结构化数据（如PDF、Word文档、CSV表格等格式）

• 非结构化数据（如HTML、PDF、TXT等格式）

图12：智能体与数据存储之间的一对多关系，后者可表示多种类型的预索引数据

每个用户请求与智能体响应循环的核心流程通常如图13所示：

1. 用户查询被发送至嵌入模型，生成对应的嵌入向量；

2. 利用SCaNN等匹配算法，将查询嵌入向量与向量数据库中的内容进行匹配；

3. 从向量数据库中检索匹配内容（以文本格式），并返回给智能体；

4. 智能体同时接收用户查询和检索内容，最终生成响应或行动方案。

5. 最终响应将返回给用户

图13：基于RAG应用中用户请求与智能体响应的生命周期

最终结果是一个应用：智能体可通过向量搜索将用户查询匹配至已知数据存储，检索原始内容，并将其提供给编排层与模型进行进一步处理。下一步操作可能是向用户提供最终答案，或执行额外的向量搜索以进一步优化结果。

图14展示了智能体结合ReAct推理/规划实现RAG的交互示例。

图14：结合ReAct推理/规划的基于RAG的应用示例

总结而言，Extensions、Functions与Data Stores构成了智能体在运行时可使用的几种不同工具类型。每种工具均有其特定用途，开发者可根据需求自主决定组合使用或独立使用。

有效使用模型的一个关键方面是其在生成输出时选择正确工具的能力，尤其是在生产环境中大规模使用工具时。尽管通用训练有助于模型发展这一技能，但现实场景往往需要超出训练数据的知识。可以将其想象为基础烹饪技能与精通某一特定菜系之间的区别：两者均需基础烹饪知识，但后者要求针对特定领域的深入学习以实现更精细的结果。

为帮助模型获取此类具体知识，存在以下几种方法：

•In-context Learning：这种方法在推理阶段为通用模型提供prompt、工具及少量示例，使其能够即时学习如何针对特定任务使用这些工具。自然语言领域中，ReAct框架便是此类方法的典型案例。

• 基于Retrieval-based In-context Learning：该技术通过从外部记忆库中检索相关信息、工具及关联示例，动态填充模型提示。例如，Vertex AI扩展中的Example Store或前述数据存储结合RAG架构便属于此类应用 。

• 基于Fine-tuning-based Learning ：此方法通过在推理前使用包含更多具体示例的数据集对模型进行训练，使其预先掌握特定工具的应用场景与方式。

为更深入理解上述目标学习方法，我们可通过烹饪类比进一步展开说明。

设想一位厨师收到客户提供的具体食谱（提示词）、几样关键食材（相关工具）以及少量示例菜品（少量示例）。基于这些有限信息和厨师自身的烹饪常识，他需要即兴构思如何制作一道最贴近食谱要求和客户偏好的菜肴。这便是In-context Learning。

• 基于Retrieval-based In-context Learning：

假设厨师身处一个储备丰富的储物柜（外部数据存储）环境，其中备有各类食材和烹饪手册（示例及工具）。此时厨师可动态挑选储物柜中的食材和手册，更精准地匹配客户食谱与偏好。通过结合既有知识与新获取的信息，厨师能制作出更精准且精致的菜品。

• 基于Fine-tuning-based Learning：

若我们让厨师重返学校系统学习特定菜系（基于更大规模具体示例的预训练），他便能以更深厚的理解应对未来未知的客户食谱需求。这种方法尤其适合要求厨师在特定菜系（知识领域）达到精通的场景。

上述方法在速度、成本和延迟性方面各有优劣。然而，通过在智能体框架中整合这些技术，可最大化其优势并弱化短板，从而构建更稳健且灵活的解决方案。

为了提供一个实际可运行的智能体示例，我们将使用LangChain和LangGraph库构建一个快速原型。这些流行的开源库允许用户通过“链式组合”逻辑、推理和工具调用序列来回答用户查询，从而构建定制化智能体。

我们将使用gemini-1.5-flash-001模型和一些简单工具来处理代码片段8中展示的多阶段查询。

我们使用的工具包括SerpAPI用于Google搜索和Google Places API。执行代码片段8中的程序后，可以在代码片段9中看到示例输出。

代码片段8：基于LangChain和LangGraph的智能体及工具示例

代码片段9：代码片段8程序输出结果

尽管这是一个相对简单的智能体示例，但它展示了Model、Orchestration和Tools这三个核心组件如何协同工作以实现特定目标。在最后一节中，我们将探讨这些组件在谷歌规模化托管产品（如Vertex AI智能体和生成式操作手册）中的整合应用。

虽然本白皮书探讨了智能体的核心组件，但构建生产级应用还需要将其与用户界面、评估框架和持续优化机制等附加工具集成。Google 的 Vertex AI 平台通过提供一个全托管环境简化了这一过程，涵盖了前文提到的所有基础要素。通过自然语言界面，开发者可以快速定义智能体的关键元素——目标、任务指令、工具、用于任务委派的子智能体及示例——从而轻松构建所需系统行为。此外，该平台还配备了一系列开发工具，支持测试、评估智能体性能、调试以及提升所开发智能体的整体质量。这使开发者能够专注于构建和优化智能体，而基础设施、部署及维护的复杂性则由平台本身自动管理。

图15展示了一个基于 Vertex AI 平台构建的智能体示例架构，该架构综合运用了 Vertex Agent Builder、Vertex Extensions、Vertex Function Calling 和 Vertex Example Store 等多项功能。该架构包含了生产级应用所需的多种关键组件。

图15：基于Vertex AI平台构建的端到端智能体架构示例

您可从我们的官方文档中尝试该预构建智能体架构的示例。