人类非常擅长处理复杂的模式识别任务。然而, 在得出结论之前, 他们常常需要借助书籍、Google 搜索或计算器等工具来补充已有的知识。与人类相似, 生成式 AI (Generative AI) 模型也可以通过训练来学会使用工具, 从而获取实时信息或执行现实世界中的操作。例如, 模型可以利用数据库检索工具来访问客户购买历史等特定信息, 进而生成个性化的购物推荐。此外, 模型还可以根据用户的请求, 调用各种 API 来代您回复同事的邮件或完成一笔金融交易。要实现这些功能, 模型不仅需要能调用一系列外部工具, 还必须具备自主规划和执行任务的能力。

当一个生成式 AI 模型集推理、逻辑和外部信息访问能力于一身时, 便构成了 AI 智能体 (AI Agent) 的概念 – 这是一种超越了生成式 AI 模型自身独立能力的新程序。本白皮书将深入探讨这些概念及其相关方面。

什么是智能体？

从本质上讲, 生成式 AI 智能体是一种应用程序, 它通过观察世界, 并利用其掌握的工具采取行动, 以达成特定目标。智能体是自主的, 可以在没有人类干预的情况下独立运作, 尤其是在被赋予了明确的目标时。在实现目标的过程中, 智能体也可以表现得积极主动。即便没有人类的明确指令, 智能体也能自行推理出下一步该做什么, 以便最终达成目标。虽然 AI 智能体的概念非常宽泛且强大, 但本白皮书将重点关注在发布时, 生成式 AI 模型能够构建的特定类型的智能体。

为了理解智能体的内部工作原理, 我们首先需要了解驱动其行为、行动和决策的基础组件。这些组件的组合被称为认知架构 (cognitive architecture), 通过对这些组件的不同搭配组合, 可以实现多种多样的架构。聚焦于核心功能, 一个智能体的认知架构主要包含三个基本组件, 如图 1 所示。

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

模型

在智能体的语境中, 模型指的是作为其决策中枢的语言模型 (LM)。智能体可以使用一个或多个任意大小 (小型或大型) 的语言模型, 这些模型需要能够遵循基于指令的推理和逻辑框架, 例如 ReAct、思维链 (Chain-of-Thought) 或思维树 (Tree-of-Thoughts)。根据特定智能体架构的需求, 模型可以是通用的、多模态的, 或是经过微调的。为了在实际应用中达到最佳效果, 您应当选择最适合最终应用场景的模型, 理想情况下, 该模型还应使用与您计划在认知架构中使用的工具有关的数据特征 (data signatures) 进行过训练。值得注意的是, 模型通常不会针对智能体的特定配置 (如工具选择、编排与推理设置) 进行训练。但是, 我们可以通过提供一些展示智能体能力的示例 (例如智能体在不同场景下使用特定工具或推理步骤的实例) 来进一步优化模型, 使其更好地完成任务。

工具

基础模型 (Foundational models) 尽管在文本和图像生成方面表现出色, 但它们无法直接与外部世界互动, 这限制了其能力。工具正是为了弥合这一差距而生, 它赋予智能体与外部数据和服务交互的能力, 使其能够执行远超底层模型本身能力的广泛操作。工具的形式多种多样, 复杂程度也各不相同, 但通常与常见的 Web API 方法 (如 GET、POST、PATCH 和 DELETE) 相对应。例如, 工具可以更新数据库中的客户信息, 或者获取天气数据来为智能体给用户的旅行建议提供参考。借助工具, 智能体可以访问和处理现实世界的信息。这使得它们能够支持像检索增强生成 (RAG) 这样的更专业的系统, 从而显著扩展智能体的能力, 达到基础模型自身无法企及的高度。下文我们将更详细地探讨工具, 但最关键的一点是: 工具是连接智能体内部能力与外部世界的桥梁, 为其开启了更广阔的可能性。

编排层

编排层描述了一个循环过程, 该过程控制着智能体如何接收信息、进行内部推理, 并根据推理结果来决定下一步的行动。通常, 这个循环会持续进行, 直到智能体达成目标或满足某个终止条件。编排层的复杂性因智能体及其执行的任务而异。有些循环可能只是包含决策规则的简单计算, 而另一些则可能包含逻辑链、涉及额外的机器学习算法或采用其他概率推理技术。我们将在认知架构一节中更详细地讨论智能体编排层的具体实现。

**模型**	**智能体**
知识局限于其训练数据中的内容。	通过工具与外部系统连接, 知识得以扩展。
基于用户查询进行单轮推理/预测。除非为模型特别实现, 否则不管理会话历史或连续上下文 (如聊天历史)。	可管理会话历史 (如聊天历史), 允许基于用户查询和编排层中的决策进行多轮推理/预测。这里的“轮”指交互系统与智能体之间的一次互动 (即 1 次传入事件/查询和 1 次智能体响应)。
没有内置的工具实现。	工具被原生集成在智能体架构中。
	拥有原生的认知架构, 该架构使用 CoT、ReAct 等推理框架或其他预构建的智能体框架 (如 LangChain)。

认知架构: 智能体如何运作

想象一位在繁忙厨房里的大厨。他的目标是为餐厅的顾客烹制美味佳肴, 这需要经历一个规划、执行和调整的循环过程。

• • 他会收集信息, 比如顾客的点单, 以及储藏室和冰箱里有哪些食材。
• • 他会根据收集到的信息进行内部思考, 构思可以制作哪些菜肴, 搭配何种风味。
• • 他会采取行动来烹制菜肴: 切菜、调配香料、煎肉。

在这个过程的每个阶段, 大厨都会根据需要随时调整, 比如食材用完了或者收到了顾客的反馈, 他会相应地完善计划, 并根据之前的结果来决定下一步的行动。这种信息获取、规划、执行和调整的循环, 描绘了这位大厨为达成目标所采用的独特认知架构。

与大厨一样, 智能体也通过认知架构来达成最终目标, 它们迭代地处理信息, 做出明智决策, 并根据先前的输出来优化下一步行动。智能体认知架构的核心是编排层, 它负责维护记忆、状态、推理和规划。编排层利用了快速发展的提示工程 (prompt engineering) 领域及其相关框架来指导推理和规划, 使智能体能够更有效地与环境互动并完成任务。针对语言模型的提示工程框架和任务规划的研究正在飞速发展, 涌现出多种前景广阔的方法。以下是截至本白皮书发布时, 几种最流行的框架和推理技术 (并非详尽无遗):

• • ReAct, 一种提示工程框架, 它为语言模型提供了一套思考过程策略, 使其能够根据用户查询进行推理并采取行动, 无论是否提供上下文示例。实践证明, ReAct 提示在性能上超越了多个 SOTA 基线, 并提升了大语言模型的人机协作能力和可信度。
• • 思维链 (CoT), 一种提示工程框架, 它通过引入中间步骤来赋予模型推理能力。CoT 包含多种衍生技术, 如自洽性、主动提示和多模态 CoT, 每种技术在不同应用场景下各有优劣。
• • 思维树 (ToT), 一种提示工程框架, 特别适用于需要探索或战略性预判的任务。它扩展了思维链提示的思路, 允许模型探索多个不同的思考路径, 这些路径可以作为语言模型解决通用问题的中间步骤。

智能体可以利用上述的一种或多种推理技术来为用户的请求选择最佳的下一步行动。例如, 假设一个智能体被设定为使用 ReAct 框架来为用户查询选择正确的行动和工具, 那么其事件序列可能如下:

1. 1. 用户向智能体发送查询。
2. 2. 智能体启动 ReAct 序列。
3. 3. 智能体向模型提供一个提示, 要求其生成 ReAct 的一个后续步骤及其对应输出:
4. 1. 问题: 来自用户查询的输入问题, 与提示一同提供。
5. 2. 思考: 模型关于下一步该做什么的想法。
6. 3. 行动: 模型决定下一步要采取的行动。
7. 1. 此时可能会发生工具选择。
8. 2. 例如, 行动可以是 [Flights, Search, Code, None] 之一, 前 3 个代表模型可选择的已知工具, 最后一个代表“不选择工具”。
9. 4. 行动输入: 模型决定为所选工具提供哪些输入 (如果有)。
10. 5. 观察: 执行行动/行动输入后得到的结果。
11. 1. 这个“思考-行动-行动输入-观察”的循环可以根据需要重复 N 次。
12. 6. 最终答案: 模型针对原始用户查询给出的最终答案。
13. 4. ReAct 循环结束, 最终答案返回给用户。

图 2: 在编排层中使用 ReAct 推理的智能体示例

如图 2 所示, 模型、工具和智能体配置协同工作, 根据用户的原始查询, 为用户提供一个有理有据且简洁的答复。尽管模型本可以基于其已有知识猜测 (或“幻觉出”) 一个答案, 但它选择使用一个工具 (Flights) 来搜索实时的外部信息。这些额外的信息被提供给模型, 使其能够基于真实数据做出更明智的决策, 并将信息汇总后反馈给用户。

工具: 我们通往外部世界的钥匙

虽然语言模型擅长处理信息, 但它们缺乏直接感知和影响现实世界的能力, 这限制了它们在需要与外部系统或数据交互的场景中的应用价值。从某种意义上说, 语言模型的水平受限于其训练数据。但无论我们为模型提供多少数据, 它们仍然缺乏与外部世界互动的基本能力。那么, 我们如何才能赋予模型与外部系统进行实时、具备上下文感知能力的交互呢？函数、扩展、数据存储和插件都是为模型提供这种关键能力的方式。

尽管名称各异, 但工具的本质是在我们的基础模型与外部世界之间建立一座桥梁。通过连接外部系统和数据, 工具使我们的智能体能够执行更多样化的任务, 并且完成得更准确、更可靠。例如, 工具能让智能体调整智能家居设置、更新日历、从数据库中获取用户信息, 或者根据特定指令发送电子邮件。

截至本白皮书发布之日, Google 模型主要能与三种类型的工具互动: 扩展 (Extensions)、函数 (Functions) 和数据存储 (Data Stores)。通过为智能体配备工具, 我们释放了其巨大的潜力, 使它们不仅能理解世界, 还能对世界采取行动, 这为无数新的应用和可能性打开了大门。

扩展

要理解扩展, 最简单的方式是将其想象成一座以标准化方式连接 API 和智能体的桥梁, 它允许智能体无缝执行 API, 而无需关心其底层实现。假设您构建了一个旨在帮助用户预订航班的智能体, 并且您打算使用 Google Flights API 来检索航班信息, 但不确定如何让智能体调用这个 API 端点。

图 3: 智能体如何与外部 API 互动？

一种方法是编写自定义代码, 用于接收用户查询, 解析出相关信息, 然后再调用 API。例如, 在航班预订场景中, 用户可能会说:“我想订一张从 Austin 到 Zurich 的机票。” 我们的自定义代码就需要从查询中提取出“Austin”和“Zurich”这两个关键实体, 然后才能尝试调用 API。但如果用户只说“我想订一张去 Zurich 的机票”, 却没提供出发城市呢？由于缺少必要数据, API 调用将会失败。为了处理这类边缘情况, 我们需要编写更多代码。这种方法不仅难以扩展, 而且在任何超出预设代码逻辑的场景下都容易出错。

一种更可靠的方法是使用扩展。扩展通过以下两种方式连接了智能体和 API:

1. 1. 通过示例教会智能体如何使用 API 端点。
2. 2. 告诉智能体成功调用 API 端点需要哪些参数。

图 4: 扩展连接了智能体与外部 API

扩展可以独立于智能体进行开发, 但需要作为智能体配置的一部分提供给它。在运行时, 智能体会利用模型和这些示例来判断哪个扩展 (如果有的话) 最适合解决用户的查询。这凸显了扩展的一个关键优势 – 其内置的示例类型, 这使得智能体能够根据任务动态选择最合适的扩展。

图 5: 智能体、扩展和 API 之间的“一对多”关系

您可以像软件开发者解决用户问题时那样来理解这个过程。当开发者需要为用户预订航班时, 他可能会选择 Google Flights API; 当需要查找最近的咖啡店时, 他可能会使用 Google Maps API。同样地, 智能体/模型技术栈会利用一组已知的扩展, 来决定哪一个最适合用户的查询。如果您想亲身体验扩展的功能, 可以在 Gemini 应用中尝试: 前往“设置 > 扩展”, 然后启用您想测试的任何扩展。例如, 您可以启用 Google Flights 扩展, 然后问 Gemini:“帮我查一下下周五从 Austin 到 Zurich 的航班。”

示例扩展

为了简化扩展的使用, Google 提供了一些开箱即用的扩展, 您可以快速将其导入项目, 只需少量配置即可使用。例如, 代码片段 1 中的代码解释器扩展, 允许您通过自然语言描述来生成并运行 Python 代码。

import vertexaiimport pprintPROJECT_ID = "YOUR_PROJECT_ID"REGION = "us-central1"vertexai.init(project=PROJECT_ID, location=REGION)from vertexai.preview.extensions import Extensionextension_code_interpreter = Extension.from_hub("code_interpreter")CODE_QUERY = """Write a python method to invert a binary tree in O(n) time."""response = extension_code_interpreter.execute(    operation_id = "generate_and_execute",    operation_params = {"query": CODE_QUERY})print("Generated Code:")pprint.pprint({response['generated_code']})# The above snippet will generate the following code.```Generated Code:class TreeNode:    def __init__(self, val=0, left=None, right=None(:        self.val = val        self.left = left        self.right = rightdef invert_binary_tree(root):    """    Inverts a binary tree.    Args:        root: The root of the binary tree.    Returns:        The root of the inverted binary tree.    """    if not root:        return None        # Swap the left and right children recursively    root.left, root.right = \        invert_binary_tree(root.right), invert_binary_tree(root.left)        return root# Example usage:# Construct a sample binary treeroot = TreeNode(4)root.left = TreeNode(2)root.right = TreeNode(7)root.left.left = TreeNode(1)root.left.right = TreeNode(3)root.right.left = TreeNode(6)root.right.right = TreeNode(9)# Invert the binary treeinverted_root = invert_binary_tree(root)```

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

函数

总而言之, 扩展为智能体提供了多种感知、互动和影响外部世界的方式。这些扩展的选择和调用都由示例来指导, 而这些示例都定义在扩展的配置中。

在软件工程领域, 函数被定义为能够完成特定任务、可根据需要重复使用的独立代码模块。软件开发者在编写程序时, 通常会创建许多函数来执行各种任务, 并定义何时调用函数 A 或函数 B 的逻辑, 以及它们的预期输入和输出。

在智能体的世界里, 函数的工作方式非常相似, 只不过这里的“软件开发者”换成了“模型”。模型可以根据一组已知函数的规范, 来决定何时使用哪个函数以及需要传递什么参数。函数与扩展有几点不同, 其中最显著的是:

1. 1. 模型只输出要调用的函数及其参数, 而不直接进行实时的 API 调用。
2. 2. 函数在客户端执行, 而扩展在智能体端执行。

再次以 Google Flights 为例, 一个简单的函数设置可能如图 7 所示。

图 7: 函数如何与外部 API 互动？

请注意, 这里的主要区别在于, 无论是函数还是智能体, 都不直接与 Google Flights API 互动。那么, API 调用究竟是如何发生的呢？

使用函数时, 调用实际 API 端点的逻辑和执行过程从智能体端转移回客户端应用程序来处理, 如下图 8 和图 9 所示。这让开发者可以对应用程序中的数据流进行更精细的控制。开发者选择使用函数而非扩展的原因有很多, 以下是一些常见的用例:

• • API 调用需要在应用程序技术栈的另一层进行, 而非在智能体架构的直接流程中 (例如, 在中间件系统、前端框架等)。
• • 存在安全或身份验证限制, 导致智能体无法直接调用 API (例如, API 未对公网开放, 或智能体基础设施无法访问)。
• • 存在时间或操作顺序上的约束, 使智能体无法实时进行 API 调用 (例如, 批量操作、需要人工审核的环节等)。
• • 当智能体本身无法处理某些 API 返回的数据时，就需要额外的逻辑来进行数据转换。举个例子，某个 API 接口可能不提供筛选功能来限制返回结果的数量。在这种情况下，开发者可以在客户端利用函数 (Functions) 来实现这些数据转换。
• • 开发者希望在不为 API 接口部署额外基础设施的情况下，快速迭代智能体的开发 (比如，函数调用此时可以扮演 API “模拟接口”的角色)。

尽管这两种方法在内部架构上的差异很细微 (如图 8 所示)，但函数调用为开发者提供了额外的控制权，并降低了对外部基础设施的依赖，使其成为一个极具吸引力的选择。

图 8: 扩展与函数调用在客户端和智能体端控制权的划分

用例

模型可以调用函数来为最终用户处理复杂的客户端执行流程，尤其是在智能体开发者不希望由大语言模型来管理 API 执行时 (这正是扩展 (Extensions) 的处理方式)。让我们来看一个例子：假设我们正在训练一个智能体，让它扮演旅行顾问的角色，帮助用户预订度假行程。我们的目标是让这个智能体生成一个城市列表，以便我们的中间件应用程序能够利用这个列表去下载图片、数据等，帮助用户规划行程。用户可能会这样说：

我想和家人去滑雪，但还没想好去哪里。

如果直接向模型发出这样的提示，得到的输出可能如下：

当然，这里有一些适合家庭滑雪旅行的城市供您参考：

• • 美国科罗拉多州，克雷斯特德比特 (Crested Butte)
• • 加拿大不列颠哥伦比亚省，惠斯勒 (Whistler)
• • 瑞士，采尔马特 (Zermatt)

虽然上面的输出包含了我们需要的数据 (城市名称)，但这种格式并不利于程序解析。借助函数调用 (Function Calling)，我们可以教会模型以一种结构化的格式 (例如 JSON) 输出结果，这样更便于其他系统处理。对于同样的用户输入，使用函数调用生成的 JSON 输出可能如代码片段 5 所示。

function_call {  name: "display_cities"  args: {    "cities": ["Crested Butte", "Whistler", "Zermatt"],    "preferences": "skiing"  }}

代码片段 5: 用于显示城市列表和用户偏好的函数调用数据包示例

这个 JSON 数据包由模型生成，然后发送到我们的客户端服务器，我们便可以对其进行任何我们想要的操作。在这个具体案例中，我们会调用 Google Places API，利用模型提供的城市列表来查找图片，然后将这些图文并茂的格式化内容返回给用户。图 9 的序列图详细展示了上述交互的每一个步骤。

图 9: 函数调用的生命周期序列图

图 9 示例的结果是，我们利用模型来“填空”，即填充客户端用户界面 (UI) 调用 Google Places API 所需的参数。客户端的用户界面会使用模型在返回的函数中提供的参数来管理实际的 API 调用。这只是函数调用的一个应用场景，还有许多其他情况也值得考虑，例如：

• • 你希望大语言模型为你推荐一个可以在代码中使用的函数，但又不想在代码中暴露凭证信息。由于函数调用本身并不执行函数，因此你无需将凭证与函数信息一起写在代码里。
• • 你正在运行一些耗时可能超过几秒的异步操作。函数调用是异步的，因此非常适合这类场景。
• • 你希望在一个设备上运行函数，而生成函数调用及其参数的却是另一个系统。

关于函数，需要记住一个关键点：它们旨在让开发者不仅能更好地控制 API 调用的执行，还能掌控整个应用程序的数据流。在图 9 的例子中，开发者选择不将 API 信息返回给智能体，因为这些信息与智能体接下来的行动无关。然而，根据应用程序的架构，将外部 API 的调用数据返回给智能体，用以影响其未来的推理、逻辑和行动选择，可能也是有意义的。最终，如何选择取决于应用程序的开发者，他们需要为特定的应用场景做出最合适的决定。

函数示例代码

为了在我们的滑雪度假场景中实现上述输出，让我们来逐步构建各个组件，并让它们与我们的 gemini-2.0-flash-001 模型协同工作。

首先，我们将 display_cities 函数定义为一个简单的 Python 方法。

from typing import Optionaldef display_cities(cities: list[str], preferences: Optional[str] = None):    """Provides a list of cities based on the user's search query and preferences.    Args:        preferences (str): The user's preferences for the search, like skiing,        beach, restaurants, bbq, etc.        cities (list[str]): The list of cities being recommended to the user.    Returns:        list[str]: The list of cities being recommended to the user.    """    return cities

代码片段 6: 用于显示城市列表的函数示例 Python 方法

接下来，我们初始化模型，构建工具 (Tool)，然后将用户的查询和工具一起传递给模型。执行下面的代码，将得到如代码片段底部所示的输出。

from google.genai import Client, typesclient = Client(    vertexai=True,    project="PROJECT_ID",    location="us-central1")res = client.models.generate_content(    model="gemini-2.0-flash-001",    model="I'd like to take a ski trip with my family but I'm not sure where to go?",    config=types.GenerateContentConfig(        tools=[display_cities],        automatic_function_calling=types.AutomaticFunctionCallingConfig(disable=True),        tool_config=types.ToolConfig(            function_calling_config=types.FunctionCallingConfig(mode='ANY')        )    ))print(f"Function Name: {res.candidates[0].content.parts[0].function_call.name}")print(f"Function Args: {res.candidates[0].content.parts[0].function_call.args}")> Function Name: display_cities> Function Args: {'preferences': 'skiing', 'cities': ['Aspen', 'Park City', 'Whistler']}

代码片段 7: 构建一个工具，将其与用户查询一同发送给模型，并触发函数调用

数据存储

总而言之，函数提供了一个简洁的框架，它赋予应用程序开发者对数据流和系统执行进行精细控制的能力，同时能有效利用智能体或模型来生成关键输入。开发者可以根据具体的应用架构需求，选择性地决定是否通过返回外部数据让智能体“参与决策”，或是将其排除在外。

想象一下，一个大语言模型就像一座巨大的图书馆，馆藏是它的训练数据。但与现实中不断有新书入库的图书馆不同，这座图书馆是静态的，它只拥有最初训练时所获得的知识。这就带来了一个挑战，因为现实世界的知识总在不断变化。数据存储 (Data Stores) 正是为了解决这一局限性而生，它能提供更动态、更新的信息，确保模型的回答既基于事实又具有相关性。

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

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

数据存储允许开发者将额外数据以原始格式提供给智能体，从而省去了耗时的数据转换、模型重训练或微调 (fine-tuning) 过程。数据存储会将传入的文档转换成一组向量数据库的嵌入向量 (embeddings)，智能体可以利用这些向量来提取所需信息，以辅助其下一步行动或对用户的回应。

图 11: 数据存储将智能体连接到各种类型的实时新数据源

实现与应用

在生成式 AI 智能体的背景下，数据存储通常以向量数据库的形式实现，开发者希望智能体在运行时能够访问它。虽然我们在此不深入探讨向量数据库，但关键在于理解它们以向量嵌入 (vector embeddings) 的形式存储数据 – 这是一种高维向量，也是所提供数据的一种数学表示。近年来，数据存储与大语言模型结合最广泛的应用之一，便是基于检索增强生成 (Retrieval Augmented Generation, RAG) 的应用程序。这类应用旨在通过让模型访问各种格式的数据，来扩展其知识的广度和深度，使其超越原有的基础训练数据。这些数据格式包括：

• • 网站内容
• • 结构化数据，如 PDF、Word 文档、CSV、电子表格等格式。
• • 非结构化数据，如 HTML、PDF、TXT 等格式。

图 12: 智能体与数据存储之间的一对多关系，数据存储可以代表各种类型的预索引数据

每个用户请求与智能体响应循环的底层流程，通常可以参考图 13 的模型。

1. 1. 用户查询被发送到一个嵌入模型，以生成该查询的嵌入向量。
2. 2. 接着，系统使用像 SCANN 这样的匹配算法，在向量数据库中匹配查询的嵌入向量。
3. 3. 匹配到的内容以文本格式从向量数据库中检索出来，并发送回智能体。
4. 4. 智能体接收到用户查询和检索到的内容后，构思出相应的回应或行动。
5. 5. 最终的回应被发送给用户。

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

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

图 14 展示了一个实现了 RAG 和 ReAct 推理/规划框架的智能体的交互示例。

图 14: 结合了 ReAct 推理/规划框架的 RAG 应用示例

工具总结

总而言之，扩展、函数和数据存储是智能体在运行时可用的几种不同类型的工具。它们各有其用，开发者可以根据需要将它们组合使用或独立使用。

	**扩展功能 (Extensions)**	**函数调用 (Function Calling)**	**数据存储 (Data Stores)**
**执行方式**	智能体端执行	客户端执行	智能体端执行
**适用场景**	- 开发者希望智能体控制与 API 接口的交互 - 适用于使用原生预构建扩展（例如 Vertex Search、Code Interpreter 等） - 支持多跳规划和 API 调用（即下一步操作依赖前一步的执行结果或 API 调用输出）	- 出于安全或身份验证的限制，智能体无法直接调用 API - 存在时间或操作顺序上的限制，智能体无法实时调用 API（例如批量操作、人类审核流程等） - API 无法连接互联网，或 Google 系统无法访问该 API	-开发者希望通过以下任意类型的数据实现增强检索生成 (Retrieval Augmented Generation，简称 RAG)： - 来自预索引网站域名和 URL 的网页内容 - 结构化数据（如 PDF、Word 文档、CSV、电子表格等格式） - 关系型或非关系型数据库 - 非结构化数据（如 HTML、PDF、TXT 等格式）

通过针对性学习提升模型性能

有效使用模型的一个关键在于，它们在生成输出时能否选择正确的工具，尤其是在生产环境中大规模使用工具时。虽然通用训练能帮助模型发展这项技能，但现实世界的场景往往需要超越训练数据的知识。这就像是基本烹饪技巧与精通某一特定菜系之间的区别：两者都需要基础的烹饪知识，但后者要求通过针对性的学习才能做出更细致入微的成果。

为了帮助模型获取这类特定知识，现有几种方法：

• • 上下文学习 (In-context learning): 这种方法在推理时，向一个通用模型提供提示、工具和一些少样本 (Few-shot) 示例，使其能够“即时学习”如何以及何时使用这些工具来完成特定任务。ReAct 框架就是这种方法在自然语言处理领域的一个例子。
• • 基于检索的上下文学习: 这种技术通过从外部记忆库中检索最相关的信息、工具和相关示例，来动态地填充模型的提示。Vertex Al 扩展中的“示例存储”或前文提到的基于 RAG 的数据存储架构都属于这类例子。
• • 基于微调的学习: 这种方法在推理之前，使用一个更大的特定示例数据集来训练模型。这有助于模型在收到任何用户查询之前，就理解何时以及如何应用某些工具。

为了更深入地理解每种针对性学习方法，让我们再次回到烹饪的类比。

• • 想象一位厨师从顾客那里收到了一个特定的食谱 (提示)、几样关键食材 (相关工具) 和一些菜品范例 (少样本示例)。基于这些有限的信息和自己的一般烹饪知识，厨师需要“即时”想出如何烹饪出一道最符合食谱和顾客口味的菜。这就是上下文学习。
• • 现在，想象我们的厨师身处一个拥有储备充足的食品储藏室 (外部数据存储) 的厨房，里面有各种食材和食谱 (示例和工具)。厨师现在可以动态地从储藏室中挑选食材和参考食谱，从而更好地满足顾客的要求。这使得厨师能够利用现有知识和新获取的信息，创造出更具创意、更精致的菜肴。这就是基于检索的上下文学习。
• • 最后，想象我们把厨师送回烹饪学校，去学习一门或多门新的菜系 (在更大的特定示例数据集上进行预训练)。这使得厨师在未来面对陌生的顾客食谱时，能有更深刻的理解。如果我们希望厨师在特定菜系 (知识领域) 上表现出色，这种方法是完美的选择。这就是基于微调的学习。

这几种方法在速度、成本和延迟方面各有优劣。然而，通过在一个智能体框架中结合这些技术，我们可以扬长避短，从而实现一个更强大、适应性更强的解决方案。

使用 LangChain 快速入门 AI 智能体

为了提供一个真实可执行的 AI 智能体示例，我们将使用 LangChain 和 LangGraph 这两个库来构建一个快速原型。这些流行的开源库允许用户通过将逻辑、推理和工具调用“链接”在一起，来构建自定义智能体以回答用户的查询。我们将使用我们的 gemini-2.0-flash-001 模型和一些简单的工具，来回答一个来自用户的多阶段查询，如代码片段 8 所示。

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

from langgraph.prebuilt import create_react_agentfrom langchain_core.tools import toolfrom langchain_community.utilities import SerpAPIWrapperfrom langchain_community.tools import GooglePlacesToolos.environ["SERPAPI_API_KEY"] = "XXXXX"os.environ["GPLACES_API_KEY"] = "XXXXX"@tooldef search(query: str):    """Use the SerpAPI to run a Google Search."""    search = SerpAPIWrapper()    return search.run(query)@tooldef places(query: str):    """Use the Google Places API to run a Google Places Query."""    places = GooglePlacesTool()    return places.run(query)model = ChatVertexAI(model="gemini-2.0-flash-001")tools = [search, places]query = "Who did the Texas Longhorns play in football last week? What is the address of the other team's stadium?"agent = create_react_agent(model, tools)input = {"messages": [("human", query)]}for s in agent.stream(input, stream_mode="values"):    message = s["messages"][-1]    if isinstance(message, tuple):        print(message)    else:        message.pretty_print()

代码片段 8: 一个基于 LangChain 和 LangGraph 并带有工具的 AI 智能体示例

================================== Human Message ===================================Who did the Texas Longhorns play in football last week? What is the addressof the other team's stadium?=================================== Ai Message =====================================Tool Calls: searchArgs:    query: Texas Longhorns football schedule================================== Tool Message ====================================Name: search{...Results: "NCAA Division I Football, Georgia, Date..."}=================================== Ai Message =====================================The Texas Longhorns played the Georgia Bulldogs last week.Tool Calls: placesArgs:    query: Georgia Bulldogs stadium================================== Tool Message ====================================Name: places{...Sanford Stadium Address: 100 Sanford...}=================================== Ai Message =====================================The address of the Georgia Bulldogs stadium is 100 Sanford Dr, Athens, GA30602, USA.

代码片段 9: 代码片段 8 中程序的输出

虽然这是一个相当简单的智能体示例，但它展示了模型、编排和工具这几个基础组件如何协同工作以实现一个特定目标。在最后一节，我们将探讨这些组件如何在 Google 规模的托管产品 (如 Vertex Al 智能体和 Generative Playbooks) 中整合在一起。

使用 Vertex Al 智能体构建生产级应用

虽然本白皮书探讨了智能体的核心组件，但构建生产级别的应用需要将它们与用户界面、评估框架和持续改进机制等额外工具相集成。Google 的 Vertex Al 平台通过提供一个完全托管的环境，涵盖了前面讨论的所有基本要素，从而简化了这一过程。开发者可以使用自然语言界面，快速定义其智能体的关键元素 – 目标、任务指令、工具、用于任务委派的子智能体以及示例 – 从而轻松构建出所需的系统行为。此外，该平台还附带一套开发工具，可用于测试、评估、衡量智能体性能、调试以及提升所开发智能体的整体质量。这使得开发者可以专注于构建和完善他们的智能体，而将基础设施、部署和维护的复杂性交给平台本身来管理。

在图 15 中，我们提供了一个在 Vertex Al 平台上构建的智能体示例架构，它利用了 Vertex Agent Builder、Vertex Extensions、Vertex Function Calling 和 Vertex Example Store 等多项功能。该架构包含了生产就绪应用所需的众多组件。

图 15: 在 Vertex Al 平台上构建的端到端智能体架构示例

你可以从我们的官方文档中尝试这个预构建的智能体架构示例。

总结

在本白皮书中，我们探讨了生成式 AI 智能体的基本组成部分、它们的构成方式，以及如何以认知架构 (cognitive architectures) 的形式有效实现它们。本白皮书的一些关键要点包括：

1. 1. AI 智能体 (AI Agent) 通过利用各种工具来获取实时信息、提出能在现实世界执行的行动建议，并自主地规划和执行复杂任务，极大地扩展了大语言模型 (Large Language Model) 的能力。AI 智能体可以借助一个或多个大语言模型来决定何时以及如何切换任务状态，并使用外部工具来完成那些仅靠模型自身难以甚至无法完成的各种复杂任务。
2. 2. AI 智能体运作的核心是一个被称为“编排层” (orchestration layer) 的认知架构，它负责组织推理、规划和决策过程，并指导 AI 智能体的所有行动。诸如 ReAct、思维链 (Chain-of-Thought) 和思维树 (Tree-of-Thoughts) 等多种推理技术，为这个编排层提供了一个基本框架，使其能够接收信息、进行内部推理，并最终生成有理有据的决策或响应。
3. 3. 扩展 (Extensions)、函数 (Functions) 和数据存储 (Data Stores) 等工具，是 AI 智能体通往外部世界的钥匙，让它们能够与外部系统交互，并获取其训练数据之外的知识。扩展在 AI 智能体和外部 API 之间架起了一座桥梁，使其能够调用 API 并检索实时信息。函数则通过任务分解，让开发者可以进行更精细的控制，即允许 AI 智能体生成函数参数，然后在客户端执行这些参数。数据存储则让 AI 智能体能够访问结构化或非结构化数据，为开发数据驱动的应用提供了可能。

AI 智能体的未来充满了激动人心的可能性，而我们目前所见的还只是冰山一角。随着工具变得越来越先进，推理能力不断增强，AI 智能体将被赋予解决日益复杂问题的强大能力。此外，“智能体链” (agent chaining) 这一策略性方法也将愈发受到关注。通过将各有所长的专用 AI 智能体组合起来，我们可以创建一种“智能体专家混合”模式，从而在不同行业和问题领域中取得卓越的成果。

我们必须认识到，构建复杂的 AI 智能体架构是一个需要反复迭代的过程。不断地实验和优化，才是根据特定业务场景和组织需求找到解决方案的关键。由于支撑 AI 智能体架构的基础模型具有生成式 (Generative) 的特性，因此没有两个 AI 智能体是完全一样的。然而，只要我们能充分利用这些基础组件各自的优势，就能够创造出富有影响力的应用，进一步扩展大语言模型的能力，并创造出真正的现实世界价值。

想入门 AI 大模型却找不到清晰方向？备考大厂 AI 岗还在四处搜集零散资料？别再浪费时间啦！2025 年 AI 大模型全套学习资料已整理完毕，从学习路线到面试真题，从工具教程到行业报告，一站式覆盖你的所有需求，现在全部免费分享！

👇👇扫码免费领取全部内容👇👇

​

一、学习必备：100+本大模型电子书+26 份行业报告 + 600+ 套技术PPT，帮你看透 AI 趋势

想了解大模型的行业动态、商业落地案例？大模型电子书？这份资料帮你站在 “行业高度” 学 AI：

1. 100+本大模型方向电子书

2. 26 份行业研究报告：覆盖多领域实践与趋势

报告包含阿里、DeepSeek 等权威机构发布的核心内容，涵盖：

• 职业趋势：《AI + 职业趋势报告》《中国 AI 人才粮仓模型解析》；
• 商业落地：《生成式 AI 商业落地白皮书》《AI Agent 应用落地技术白皮书》；
• 领域细分：《AGI 在金融领域的应用报告》《AI GC 实践案例集》；
• 行业监测：《2024 年中国大模型季度监测报告》《2025 年中国技术市场发展趋势》。

3. 600+套技术大会 PPT：听行业大咖讲实战

PPT 整理自 2024-2025 年热门技术大会，包含百度、腾讯、字节等企业的一线实践：

• 安全方向：《端侧大模型的安全建设》《大模型驱动安全升级（腾讯代码安全实践）》；
• 产品与创新：《大模型产品如何创新与创收》《AI 时代的新范式：构建 AI 产品》；
• 多模态与 Agent：《Step-Video 开源模型（视频生成进展）》《Agentic RAG 的现在与未来》；
• 工程落地：《从原型到生产：AgentOps 加速字节 AI 应用落地》《智能代码助手 CodeFuse 的架构设计》。

二、求职必看：大厂 AI 岗面试 “弹药库”，300 + 真题 + 107 道面经直接抱走

想冲字节、腾讯、阿里、蔚来等大厂 AI 岗？这份面试资料帮你提前 “押题”，拒绝临场慌！

1. 107 道大厂面经：覆盖 Prompt、RAG、大模型应用工程师等热门岗位

面经整理自 2021-2025 年真实面试场景，包含 TPlink、字节、腾讯、蔚来、虾皮、中兴、科大讯飞、京东等企业的高频考题，每道题都附带思路解析：

2. 102 道 AI 大模型真题：直击大模型核心考点

针对大模型专属考题，从概念到实践全面覆盖，帮你理清底层逻辑：

3. 97 道 LLMs 真题：聚焦大型语言模型高频问题

专门拆解 LLMs 的核心痛点与解决方案，比如让很多人头疼的 “复读机问题”：

三、路线必明： AI 大模型学习路线图，1 张图理清核心内容

刚接触 AI 大模型，不知道该从哪学起？这份「AI大模型 学习路线图」直接帮你划重点，不用再盲目摸索！

路线图涵盖 5 大核心板块，从基础到进阶层层递进：一步步带你从入门到进阶，从理论到实战。

L1阶段:启航篇丨极速破界AI新时代

L1阶段：了解大模型的基础知识，以及大模型在各个行业的应用和分析，学习理解大模型的核心原理、关键技术以及大模型应用场景。

L2阶段：攻坚篇丨RAG开发实战工坊

L2阶段：AI大模型RAG应用开发工程，主要学习RAG检索增强生成：包括Naive RAG、Advanced-RAG以及RAG性能评估，还有GraphRAG在内的多个RAG热门项目的分析。

L3阶段：跃迁篇丨Agent智能体架构设计

L3阶段：大模型Agent应用架构进阶实现，主要学习LangChain、 LIamaIndex框架，也会学习到AutoGPT、 MetaGPT等多Agent系统，打造Agent智能体。

L4阶段：精进篇丨模型微调与私有化部署

L4阶段：大模型的微调和私有化部署，更加深入的探讨Transformer架构，学习大模型的微调技术，利用DeepSpeed、Lamam Factory等工具快速进行模型微调，并通过Ollama、vLLM等推理部署框架，实现模型的快速部署。

L5阶段：专题集丨特训篇 【录播课】

四、资料领取：全套内容免费抱走，学 AI 不用再找第二份

不管你是 0 基础想入门 AI 大模型，还是有基础想冲刺大厂、了解行业趋势，这份资料都能满足你！
现在只需按照提示操作，就能免费领取：

👇👇扫码免费领取全部内容👇👇

​

2025 年想抓住 AI 大模型的风口？别犹豫，这份免费资料就是你的 “起跑线”！