致谢

审稿人和投稿人

Evan Huang

Emily Xue

Olcan Sercinoglu

Sebastian Riedel

Satinder Baveja

Antonio Gulli

Anant Nawalgaria

策展人和编辑

安东尼奥-古利

Anant Nawalgaria

Grace Mollison

技术撰稿人

乔伊-海莫克

设计师

迈克尔-朗宁

获取《谷歌智能体Agent白皮书》PDF原文件，扫码关注回复： 20250108

推理、逻辑和外部信息的获取都与生成式人工智能模型相关联，这种组合引用了代理的概念。

导言

人类擅长处理杂乱无章的模式识别任务。然而，他们往往依赖工具 – 在得出结论之前，人工智能模型可以使用书籍、谷歌搜索或计算器等工具来补充其已有知识。就像人类一样，生成式人工智能模型也可以训练使用工具来获取实时信息或建议现实世界中的行动。例如，模型可以利用数据库检索工具访问特定信息，如客户的购买历史，从而生成量身定制的购物建议。或者，根据用户的查询，模型可以进行各种 API 调用，向同事发送电子邮件回复或代表您完成金融交易。要做到这一点，模型不仅必须能够访问一系列外部工具，还需要有能力以自我指导的方式计划和执行任何任务。这种推理、逻辑和外部信息访问的组合都与生成式人工智能模型相关联，这就产生了代理的概念，或者说是一种超越了生成式人工智能模型独立能力的程序。本白皮书将对所有这些方面及相关方面进行更详细的介绍。

什么是Agent

就其最基本的形式而言，生成式人工智能代理可定义为一种应用程序，它试图通过观察世界并利用掌握的工具采取行动来实现目标。代理是自主的，可以在没有人类干预的情况下独立行动，尤其是在有适当的目标或目的的情况下。代理还可以积极主动地实现目标。即使没有来自人类的明确指令集，代理也能推理出下一步应该做什么，以实现其最终目标。虽然人工智能中的代理概念非常普遍且功能强大，但本白皮书在发布时主要关注的是生成式人工智能模型能够构建的特定类型的代理。

为了了解代理的内部运作，我们首先来介绍一下驱动代理行为、行动和决策的基础组件。这些组件的组合可以被描述为认知架构，而通过这些组件的混合和匹配，可以实现许多这样的架构。重点关注核心功能，如图 1 所示，代理的认知架构有三个基本组件。

图 1.一般代理架构和组件

模型

在代理范围内，模型指的是语言模型（LM），它将被用作代理流程的集中决策制定器。代理使用的模型可以是一个或多个 LM，大小不限（小/大），能够遵循基于指令的推理和逻辑框架，如 ReAct、Chain-of-Thought 或 Tree-of-Thoughts。模型可以是通用的、多模态的，也可以根据具体代理架构的需要进行微调。为了获得最佳的生产效果，您应该使用最适合您所需的最终应用的模型，而且最好是在与您计划在认知架构中使用的工具相关联的数据特征上经过训练的模型。值得注意的是，模型通常不会根据代理的具体配置设置（如工具选择、协调/推理设置）进行训练。不过，可以通过提供展示代理能力的示例，包括代理在不同情境下使用特定工具或推理步骤的实例，进一步完善代理任务的模型。

工具

基础模型尽管能生成令人印象深刻的文本和图像，但仍然受到无法与外部世界交互的限制。工具弥补了这一缺陷，使代理能够与外部数据和服务进行交互，同时释放出底层模型之外的更多行动。工具的形式多种多样，其功能也各不相同。复杂程度不一，但通常与 GET、POST、PATCH 和 DELETE 等常见网络 API 方法一致。例如，工具可以更新数据库中的客户信息或获取天气数据，以影响代理向用户提供的旅行建议。通过工具，代理可以访问和处理真实世界的信息。这使他们能够支持更专业的系统，如检索增强生成（RAG），从而大大扩展了代理的能力，使其超越了基础模型本身所能实现的范围。下面我们将详细讨论工具，但最重要的是我们需要理解的是，工具是沟通代理的内部能力和外部世界的桥梁，它能开启更广泛的可能性。

协调层

协调层描述了一个循环过程，该过程控制着代理如何接收信息、执行一些内部推理，并利用这些推理为下一步行动或决策提供信息。一般来说，这个循环将一直持续到代理达到目标或停止点为止。协调层的复杂程度会因代理及其执行的任务不同而有很大差异。有些循环可以是带有决策规则的简单计算，而有些循环则可能包含连锁逻辑，涉及额外的机器学习算法，或实施其他概率推理技术。我们将在认知架构部分详细讨论代理协调层的实现。

代理与模型

为了更清楚地理解代理人与模型之间的区别，请看下面的 Chafi：

机型代理他们的知识仅限于训练数据中的内容。通过工具与外部系统连接，知识得以扩展基于用户查询的单一推理/预测。除非为模型明确实施，否则不会对会话进行管理。历史或连续上下文。（即聊天记录）管理会话历史（即聊天历史），以便根据协调层中的用户查询和决策进行多轮推理/预测。在这种情况下，一个“回合”被定义为交互系统与代理之间的一次交互。（即1个传入事件/查询和1个代理响应）没有本地工具实施。工具是在代理架构中实现的。无本地逻辑层。用户可以以简单问题的形式发出提示，也可以使用推理框架（CoT、ReAct等）发出复杂的提示，以指导模型进行预测。使用CoT、ReAct等推理框架或LangChain等其他预建代理框架的本地认知架构。

认知架构：代理如何运作

想象一下厨师在忙碌的厨房里的情景。他们的目标是为餐厅顾客制作美味佳肴，这就涉及到计划、执行和调整的循环。

他们收集信息，如顾客的订单以及储藏室和冰箱里的配料。他们会根据刚刚收集到的信息进行一些内部推理，以确定可以制作哪些菜肴和口味。他们动手制作菜肴：切菜、调料、烤肉。

在这一过程的每个阶段，厨师都会根据需要做出调整，在食材耗尽或收到顾客反馈时完善他们的计划，并利用之前的一系列结果来决定下一步的行动计划。这种信息摄取、计划、执行和调整的循环描述了厨师为实现目标而采用的独特认知结构。 就像厨师一样，代理可以使用认知架构，通过迭代处理信息、做出明智的决策，并根据先前的产出完善下一步行动，从而实现其最终目标。代理认知架构的核心是协调层，负责维护记忆、状态、推理和规划。它利用快速发展的提示工程领域和相关框架来指导推理和规划，使代理能够更有效地与环境互动并完成任务。针对语言模型的提示工程框架和任务规划领域的研究正在迅速发展，并产生了各种有前途的方法。虽然这并不是一个详尽的清单，但在本报告发表时，这些都是一些最流行的框架和推理技术：

ReAct 是一个提示工程框架，它为语言模型提供了一种思维过程策略，以便在有或没有上下文示例的情况下，对用户查询进行推理并采取行动。事实证明，ReAct 提示的效果优于几种 SOTA 基线，并提高了 LLM 的人类互操作性和可信度。思维链（CoT）是一种通过中间步骤实现推理能力的提示工程框架。CoT 有多种子技术，包括自洽、主动提示和多模式 CoT，根据具体应用的不同，各有优缺点。思维树（ToT）是一个提示工程框架，非常适合探索或战略性前瞻任务。它对思维链提示进行了概括，允许模型探索各种思维链，作为使用语言模型解决一般问题的中间步骤。

代理可以利用上述推理技术之一或许多其他技术，为给定的用户请求选择下一个最佳操作。例如，让我们来考虑一个被编程为使用 ReAct 框架来为用户查询选择正确操作和工具的代理。事件的顺序可能是这样的

用户向代理发送查询代理开始 ReAct 序列代理向模型发出提示，要求它生成下一个 ReAct 步骤及其相应的输出：a. 问题问题： 用户查询的输入问题，提供提示b. 思考：模型对下一步行动的思考c. 行动：模型决定下一步采取什么行动i. 这就是选择工具的地方ii. 例如，一个操作可以是[飞行、搜索、代码、无]中的一个，其中前三个代表模型可以选择的已知工具，最后一个代表 “无工具选择”。d. 行动输入：模型决定向工具提供哪些输入（如果有的话）e. 观察结果：行动/行动输入序列的结果i. 这种思考/行动/行动输入/观察可以根据需要重复 N 次f. 最终答案：模型为原始用户查询提供的最终答案ReAct 循环结束，并向用户提供最终答案

图 2.在协调层中使用 ReAct 推理的代理示例

如图 2 所示，模型、工具和代理配置协同工作，根据用户的原始查询，向用户提供有根有据、简明扼要的回复。虽然模型可以根据自己的先验知识猜测答案（幻觉），但它却使用了一种工具（飞行）来搜索实时外部信息。这种额外的向模型提供信息，使其能够根据实际数据做出更明智的决定，并将这些信息汇总反馈给用户。

总之，代理响应的质量可以直接与模型对这些不同任务的推理和行动能力联系起来，包括选择正确工具的能力，以及工具定义的完善程度。就像厨师使用新鲜食材烹制菜肴并关注客户反馈一样，代理依靠合理的推理和可靠的信息来提供最佳结果。在下一节中，我们将深入探讨座席人员与新鲜数据连接的各种方式。

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

虽然语言模型擅长处理信息，但它们缺乏直接感知和影响现实世界的能力。这就限制了它们在需要与外部系统或数据交互的情况下的作用。这意味着，从某种意义上说，语言模型的好坏取决于它从训练数据中学到了什么。但无论我们向模型抛出多少数据，它们仍然缺乏与外部世界交互的基本能力。那么，如何才能使我们的模型与外部系统进行实时、上下文感知的交互呢？函数、扩展、数据存储和插件都是为模型提供这种关键能力的方法。

工具有很多名称，但它们是我们的基础模型与外部世界之间的纽带。这种与外部系统和数据的连接使我们的代理能够执行更多种类的任务，并且更加准确可靠。例如，工具可以让代理调整 smafi 主页设置、更新日历、从数据库获取用户信息，或根据特定指令发送电子邮件。

截至本出版物发布之日，Google 模型可以与三种主要工具类型进行交互：扩展、函数和数据存储。通过为代理配备工具，我们为他们释放了巨大的潜力，使他们不仅能理解世界，还能根据世界采取行动，为无数新应用和新可能性打开大门。

扩展

理解扩展的最简单方法是将其视为以标准化方式在应用程序接口和代理之间架起的桥梁，使代理能够无缝执行应用程序接口，无论其底层实现如何。比方说，你创建了一个以帮助用户预订航班为目标的代理。你知道要使用 Google Flights API 来检索航班信息，但不确定如何让代理调用该 API 端点。

图 3.代理如何与外部 API 交互？

一种方法是执行自定义代码，接收传入的用户查询，解析查询的相关信息，然后进行 API 调用。例如，在航班预订使用案例中，用户可能会说 “我想预订从奥斯汀到苏黎世的航班”。在这种情况下，我们的自定义代码解决方案需要从用户查询中提取 “奥斯汀 “和 “苏黎世 “作为相关实体，然后再尝试进行 API 调用。但是，如果用户说 “我想预订飞往苏黎世的航班”，却没有提供目的地城市，会发生什么情况呢？如果没有所需的数据，API 调用就会失败，而且还需要执行更多代码才能捕捉到类似边缘和角落情况。这种方法不具备可扩展性，而且在任何超出自定义代码实现范围的情况下都很容易出错。

更有弹性的方法是使用扩展。扩展通过以下方式在代理和应用程序接口之间架起了桥梁：

使用示例教代理如何使用 API 端点。告诉代理成功调用 API 端点需要哪些参数。

图 4.扩展将代理与外部应用程序接口连接起来

扩展可以独立于代理而设计，但应作为代理配置的一部分提供。代理在运行时使用模型和示例来决定哪个扩展（如果有的话）适合解决用户的查询。这就凸显了扩展的一个关键优势，即其内建的示例类型允许代理为任务动态选择最合适的扩展。

图 5.代理、扩展与应用程序接口之间的1对多关系

就像软件开发人员在解决用户问题时决定使用哪个 API 端点一样。如果用户想预订机票，开发人员可能会使用 Google Flights API。如果用户想知道离自己最近的咖啡店在哪里，开发人员可能会使用谷歌地图 API。同样，代理/模型堆栈会使用一组已知的扩展来决定哪一个最适合用户的查询。如果您想了解扩展的运行情况，可以在 Gemini 应用程序中进入 “设置”>”扩展”，然后启用任何您想测试的扩展。例如，您可以启用 Google Flights 扩展，然后询问双子座 “向我显示下周五从奥斯汀飞往苏黎世的航班”。

扩展样本

为了简化扩展的使用，Google 提供了一些开箱即用的扩展，只需进行最少的配置就能快速将其植入项目并使用。，Snippet 1 中的代码解释器扩展允许你根据自然语言描述生成并运行 Python 代码。

Python 导入 vertexai 导入 pprint project_id= "your_project_id" REGION = "us-central1" vertexai.init(project=PROJECT_ID, location=REGION) from vertexai.preview.extensions import Extension extension_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"]})#上述代码段将生成以下代码。 生成代码：类 TreeNode：def init（self，val=0，left=None，right=None）：self.val = val self.left = left self.right= rightdef invert_binary_tree(root)："""反转二叉树参数根：二叉树的根返回：倒置二叉树的根。"""如果不是 root：返回 None# 递归交换左右子代 root.left、root.right =invert_binary_tree(root.right), invert_binary_tree(root.left)返回根# 示例用法：# 构建二叉树样本 root = 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)# 反转二叉树inverted_root= invert_binary_tree(root) ```

代码片段 1.代码解释器扩展可生成和运行 Python 代码

总之，扩展为代理提供了一种感知、交互和影响外部世界的方式。这些扩展功能的选择和调用都是在实例的指导下进行的，所有实例都被定义为扩展配置的 pafi。

功能

在软件工程领域，函数被定义为独立的代码模块，可完成特定任务，并可根据需要重复使用。软件开发人员在编写程序时，通常会创建许多函数来完成各种任务。他们还将定义何时调用 function_a 与 function_b 的逻辑，以及预期的输入和输出。

函数在代理世界中的工作原理非常相似，但我们可以用模型来代替软件开发人员。模型可以接受一组已知函数，并根据其规范决定何时使用每个函数以及函数需要哪些参数。函数与扩展有一些不同之处，其中最明显的是

1. 模型会输出一个函数及其参数，但不会调用实时 API。

2. 功能在客户端执行，而扩展在代理端执行。

再以 Google Flights 为例，简单的功能设置可能与图 7 中的示例相似。

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

请注意，这里的主要区别在于，功能和代理都不直接与 Google Flights API 交互。那么，API 调用究竟是如何发生的呢？

如下图 8 和图 9 所示，使用函数后，调用实际应用程序接口端点的逻辑和执行将从代理卸载到客户端应用程序。这样，开发人员就能对应用程序中的数据流进行更精细的控制。开发人员选择使用函数而不是扩展功能的原因有很多，但常见的使用案例有以下几种：

应用程序接口调用需要在直接代理架构流程之外的应用堆栈的另一层进行（如中间件系统、前端框架等）。阻止代理直接调用应用程序接口的安全或身份验证限制（例如，应用程序接口未暴露于互联网，或代理基础设施无法访问）妨碍代理实时调用 API 的时间或操作顺序限制。（即批量操作、人工在环审查等）。需要对 API 响应应用代理无法执行的附加数据转换逻辑。例如，考虑到 API 端点不提供用于限制返回结果数量的过滤机制。在客户端使用函数为开发人员提供了进行这些转换的额外机会。开发人员希望迭代代理开发，而无需为应用程序接口端点部署额外的基础设施（例如，函数调用就像应用程序接口的 “存根”）。

如图 8 所示，这两种方法在内部架构上的差异很微妙，但额外的控制和对外部基础架构的脱钩依赖使得功能调用对开发人员来说是一个很有吸引力的选择。

图 8.扩展与函数调用的客户端与代理端控制划分

使用案例

可以使用模型来调用函数，以便为最终用户处理复杂的客户端执行流，在这种情况下，代理开发人员可能不希望语言模型来管理 API 的执行（扩展程序就是这种情况）。让我们来看看下面的示例：一个代理正被训练成一名旅游礼宾，与想要预订度假行程的用户进行交互。我们的目标是让代理生成一个城市列表，以便我们在中间件应用程序中使用，为用户的旅行计划下载图片、数据等。用户可能会说

我想和家人一起去滑雪，但不知道去哪里。 在对模型的典型提示中，输出结果可能如下：当然，这里有一份您可以考虑全家滑雪旅行的城市列表：

美国科罗拉多州克雷斯特布特加拿大不列颠哥伦比亚省惠斯勒瑞士采尔马特

虽然上述输出包含我们需要的数据（城市名称），但其格式并不适合解析。通过函数调用，我们可以教模型将输出格式化为结构化的样式（如 JSON），这样更便于其他系统进行解析。在用户输入相同提示的情况下，函数的 JSON 输出示例可能如下所示

代码段 5.显示城市和用户偏好列表的函数调用有效载荷示例

这个 JSON 有效负载由模型生成，然后发送到我们的客户端服务器，以完成我们想做的任何事情。在这个具体案例中，我们将调用 Google Places API 来获取模型提供的城市并查找图片，然后将其作为格式化的丰富内容反馈给我们的用户。图 9 中的序列图详细展示了上述交互过程。

图 9.显示函数调用生命周期的序列图

图 9 示例的结果是，模型被用来 “填空 “客户端用户界面调用 Google Places API 所需的参数。客户端用户界面使用模型在返回的 Function 中提供的参数来管理实际的 API 调用。这只是函数调用的一个使用案例，但还有许多其他场景值得考虑，例如

您希望语言模型建议您在代码中使用的函数，但又不想在代码中包含凭证。因为函数调用并不运行函数，所以您不需要在代码中包含证书和函数信息。您正在运行异步操作，耗时可能超过几秒钟。由于函数调用是一种异步操作，因此很好地处理这些情况。您希望在不同于产生函数调用及其参数的系统的设备上运行函数。

关于函数，需要记住的一个关键点是，它们不仅能为开发人员提供更多对 API 调用执行的控制，还能控制整个应用程序中的整个数据流。在图 9 的示例中，开发人员选择不将 API 信息返回给代理，因为这些信息对代理未来可能采取的行动并不重要。不过，根据应用程序的架构，将外部 API 调用数据返回给代理以影响未来的推理、逻辑和操作选择可能是有意义的。最终，应用程序开发人员还是要根据具体的应用程序来选择合适的方法。

功能示例代码

为了在滑雪度假场景中实现上述输出，让我们利用 gemini-1.5-flash-001 模型构建出实现这一目标的各个组件。

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

代码段 6.显示城市列表函数的 python 方法示例。

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

代码段 7.创建工具，向模型发送用户查询并允许函数调用

总之，函数提供了一个简单明了的框架，使应用程序开发人员能够对数据流和系统执行进行细粒度控制，同时有效利用代理/模型生成关键输入。开发人员可以根据具体的应用架构要求，有选择性地选择是否通过返回外部数据让代理 “参与循环”，或者省略代理。

数据存储

把语言模型想象成一个藏书丰富的图书馆，里面有它的训练数据。但与不断获取新书的图书馆不同的是，这个模型始终保持静态，只保存最初训练时的知识。这就提出了一个挑战，因为现实世界的知识是不断演变。数据存储通过提供更多动态和最新的信息来解决这一局限性，并确保模型的响应始终以事实和相关性为基础。 考虑一种常见的情况，开发人员可能需要向模型提供少量额外数据，可能是电子表格或 PDF 格式的数据。

图 10.代理如何与结构化和非结构化数据交互？

数据存储允许开发人员以原始格式向代理提供额外数据，从而省去了耗时的数据转换、模型再训练或微调。数据存储将传入的文档转换成一组矢量数据库嵌入，代理可利用这些嵌入提取所需的信息，以补充其下一步行动或对用户的响应。

图 11.数据存储将代理与各种类型的新实时数据源连接起来。

实施与应用

在生成式人工智能代理的背景下，数据存储通常以矢量数据库的形式实现，开发者希望代理在运行时能够访问该数据库。虽然我们不会在此深入介绍矢量数据库，但需要了解的关键一点是，它们以矢量嵌入的形式存储数据，而矢量嵌入是一种高维矢量或数学嵌入。

所提供数据的表示。近来，数据存储与语言模型结合使用的最多的例子之一是检索增强语言模型（Retrieval Augmented）的实施。

生成（RAG）为基础的应用。这些应用旨在通过让模型访问各种格式的数据，从而扩展模型知识的广度和深度，使其超越基础训练数据：

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

图 12.代理与数据存储之间的 1 对多关系，可代表各种类型的预索引数据

每个用户请求和代理响应循环的基本流程建模一般如图 13 所示。

用户查询被发送到嵌入模型，以生成查询的嵌入信息然后，使用 SCaNN 等匹配算法将查询嵌入与矢量数据库的内容进行匹配。匹配的内容以文本格式从矢量数据库中检索出来，并发送回代理代理接收用户查询和检索到的内容，然后制定响应或行动向用户发送最终回复

图 13.基于 RAG 的应用程序中用户请求和代理响应的生命周期

最终的应用结果是让代理通过矢量搜索将用户的查询与已知的数据存储相匹配，检索原始内容，并将其提供给协调层和模型进行进一步处理。下一步操作可能是向用户提供最终答案，或执行额外的矢量搜索以进一步完善结果。

图 14 展示了一个与使用 ReAct 推理/规划功能实施 RAG 的代理进行交互的示例。

工具回顾

总而言之，扩展、函数和数据存储构成了几种不同的工具类型，供代理在运行时使用。每种工具都有自己的用途，它们可以一起使用，也可以独立使用，由代理开发人员自行决定。

通过有针对性的学习提高模型性能

有效使用模型的一个重要方面是模型在生成输出时选择正确工具的能力，尤其是在生产中大规模使用工具时。虽然一般培训有助于模型开发这一技能，但真实世界的场景往往需要培训数据以外的知识。把这想象成基本烹饪技能和掌握烹饪技巧之间的区别一种特定的菜肴。两者都需要基础烹饪知识，但后者需要有针对性的学习，以获得更细致入微的效果。

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

情境学习：这种方法在推理时为通用模型提供提示、工具和少量示例，使其能够 “即时 “学习如何以及何时在特定任务中使用这些工具。ReAct 框架就是这种方法在自然语言中的应用实例。基于检索的上下文学习：这种技术通过从外部存储器中检索最相关的信息、工具和相关示例，动态填充模型提示。例如，Vefiex 人工智能扩展中的 “示例存储 “或前面提到的基于 RAG 架构的数据存储。基于微调的学习：这种方法包括在推理之前使用特定示例的较大数据集来训练模型。这有助于模型在接收任何用户查询之前，了解何时以及如何应用 cefiain 工具。

为了进一步了解每种有针对性的学习方法，让我们重温一下烹饪的比喻。

试想一下，厨师从顾客那里得到一份特定的食谱（提示）、一些关键配料（相关工具）和一些菜肴示例（少量示例）。根据这些有限的信息和厨师的烹饪常识，他们需要想出如何 ” “烹制出最符合食谱和顾客喜好的菜肴。这就是情境学习。现在，让我们想象一下厨师在厨房里的情景，厨房里有一个储藏丰富的储藏室（外部数据存储），里面装满了各种配料和烹饪书（示例和工具）。现在，厨师可以从储藏室中动态地选择配料和烹饪书，并更好地调整根据客户的食谱和喜好。这样，厨师就能利用现有的和新的知识，制作出更明智、更精致的菜肴。这是基于检索的情境学习。最后，让我们设想一下，我们把厨师送回学校去学习一种或一组新的菜肴（在更大的特定示例数据集上进行预培训）。这样，厨师就能以更深入的理解来处理未来未见过的客户菜谱。如果我们希望厨师在特定菜肴（知识领域）中表现出色，那么这种方法就再好不过了。这就是基于微调的学习。

这些方法在速度、成本和延迟方面各有利弊。不过，通过将这些技术结合到一个代理框架中，我们可以充分利用它们的各种优势，最大限度地减少它们的劣势，从而获得更强大、适应性更强的解决方案。

使用 LangChain 的代理快速 stafi

为了提供真实世界中可执行的代理操作示例，我们将使用 LangChain 和 LangGraph 库构建一个快速原型。这些流行的开源库允许用户通过将逻辑、推理和工具调用的序列 “链”在一起来构建客户代理，从而回答用户的询问。我们将使用 gemini-1.5-flash-001 模型和一些简单的工具来回答用户的多阶段查询，如片段 8 所示。

我们使用的工具是 SerpAPI（用于谷歌搜索）和 Google Places API。执行完代码段 8 中的程序后，您可以看到代码段 9 中的示例输出。

代码段 8.基于 LangChain 和 LangGraph 的代理示例与工具

代码段 9.图示 8 中程序的输出结果

虽然这是一个相当简单的代理示例，但它展示了模型、协调和工具等基础组件共同实现特定目标的过程。在最后一节，我们将探讨这些组件是如何在 Google 规模的托管产品（如 Vefiex 人工智能代理和生成式游戏本）中结合在一起的。

使用 Vefiex 人工智能代理的生产应用

本白皮书探讨了代理的核心组件，但要构建生产级应用，还需要将代理与用户界面、评估框架和持续改进机制等其他工具集成。谷歌的 Vekex 人工智能平台提供了一个完全可管理的环境，包含了前面提到的所有基本要素，从而简化了这一过程。通过使用自然语言界面，开发人员可以快速用户可以定义其代理的关键要素–目标、任务指令、工具、任务委托子代理和示例–从而轻松构建所需的系统行为。此外，该平台还配备了一套开发工具，可用于测试、评估、测量代理性能、调试和提高所开发代理的整体质量。这样，开发人员就可以专注于构建和完善他们的代理，而复杂的基础架构、部署和维护工作则由平台本身来管理。

在图 15 中，我们提供了一个在 Vefiex 人工智能平台上构建的代理架构示例，该代理使用了 Vefiex Agent Builder、Vefiex Extensions、Vefiex AI Agent Builder 等多种功能。例如，函数调用和 Vefiex 示例存储。该架构包括许多生产就绪应用程序所需的各种组件。

图 15.基于 Vefiex 人工智能平台构建的端到端代理架构示例

您可以从我们的官方文档中试用这种预构建代理架构的示例。

摘要

在本白皮书中，我们讨论了生成式人工智能代理的基础构件、它们的组成以及以认知架构的形式实现它们的有效方法。本白皮书的一些主要内容包括

代理可以利用一个或多个语言模型来决定何时以及如何进行状态转换，并使用外部工具来完成任何数量的复杂任务，而这些任务对模型来说是很难或不可能独立完成的。代理运行的核心是协调层，这是一种认知架构，用于构建推理、规划和决策，并指导代理的行动。各种推理技术，如 ReAct、Chain-of-Thought 和 Tree-of-Thoughts 等，为协调层提供了一个接收信息、执行内部推理和生成明智决策或响应的框架。扩展、函数和数据存储等工具是代理通向外部世界的钥匙，使他们能够与外部系统交互，并获取训练数据以外的知识。扩展在代理和外部应用程序接口之间架起了一座桥梁，使应用程序接口调用的执行和实时信息的检索成为可能。生成可在客户端执行的功能参数。数据存储可让代理访问结构化或非结构化数据，从而实现数据驱动型应用。

未来的代理技术将取得令人兴奋的进步，而我们才刚刚开始了解其可能性的表面。随着工具越来越先进，推理能力越来越强，代理将有能力解决越来越复杂的问题。此外，”代理链 “的战略方法将继续得到。通过将专业代理（每个代理都擅长某一特定领域或任务）结合起来，我们就能创造出一种 “混合代理经验 “的方法，能够在各个行业和问题领域取得卓越的成果。

重要的是要记住，建立复杂的代理架构需要一种迭代方法。实验和改进是为特定业务案例和组织需求找到解决方案的关键。由于支撑代理架构的基础模型具有生成性，因此没有两个代理是相同的。但是，通过利用每个基础组件的优势，我们可以创建有影响力的应用程序，从而扩展语言模型的功能并推动现实世界的价值。

尾注

Shafran, I., Cao, Y. et al., 2022, ‘ReAct：语言模型中推理与行动的协同”。Available at：hflps://arxiv.org/abs/2210.03629Wei，J.，Wang，X.等，2023，《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》。见 hflps://arxiv.org/pdf/2201.11903.pdf。Wang, X. et al., 2022, ‘Self-Consistency Improves Chain of Thought Reasoning in Language Models’.见 hflps://arxiv.org/abs/2203.11171。Diao, S. et al., 2023, “Active Prompting with Chain-of-Thought for Large Language Models”。见 hflps://arxiv.org/pdf/2302.12246.pdf.Zhang, H. et al., 2023, ‘Multimodal Chain-of-Thought Reasoning in Language Models’。见 hflps://arxiv.org/abs/2302.00923.Yao, S. et al., 2023, “Tree of Thoughts：用大型语言模型慎重解决问题》。Available at：hflps://arxiv.org/abs/2305.10601.Long, X., 2023, “Large Language Model Guided Tree-of-Thought”.见 hflps://arxiv.org/abs/2305.08291.谷歌。谷歌双子座应用程序”。网址：hflp://gemini.google.com。Swagger。OpenAPI 规范”。网址：hflps://swagger.io/specification/。Xie, M., 2022, 《情境学习是如何运作的？理解与传统监督学习差异的框架》。见 hflps://ai.stanford.edu/blog/understanding-incontext/。谷歌研究。ScaNN (Scalable Nearest Neighbors)’.请访问 hflps://github.com/google-research/google-research/tree/master/scann.LangChain.LangChain。可查阅：hflps://python.langchain.com/v0.2/docs/introduction/。

获取《谷歌智能体Agent白皮书》PDF原文件，扫码关注回复： 20250108