中智凯灵 2025年01月16日 11:22 北京

以下文章来源于青哥谈AI ，作者杨青

青哥谈AI.

人工智能最新产品调研与前沿技术分享

从定义到架构，从工具到应用，前不久发布的谷歌AI Agent白皮书全面解析了AI Agent的核心要素与未来发展方向。白皮书不仅深入阐释了模型、工具、编排层等关键组件，还详细阐述了扩展、函数、数据存储等重要工具的功能与应用场景。此外，白皮书还介绍了如何通过针对性学习提升模型性能，并提供了基于LangChain的构建示例以及Vertex AI代理在生产环境中的实际应用案例。本文对这份白皮书进行了全文编译。

关注本公众号，私信后台回复【白皮书】免费获取原版谷歌AI Agent白皮书。

1. 引言

人类在复杂的模式识别任务中表现出色。然而，他们通常依赖工具——如书籍、谷歌搜索或计算器——来补充他们的先验知识，然后得出结论。就像人类一样，生成式AI模型也可以被训练使用工具来访问实时信息或建议现实世界的行动。例如，模型可以利用数据库检索工具访问特定信息，如客户的购买历史，从而生成定制的购物推荐。或者，根据用户的查询，模型可以调用各种API来发送电子邮件回复给同事或代表用户完成金融交易。要做到这一点，模型不仅需要访问一组外部工具，还需要具备规划和执行任何任务的自我导向能力。这种将推理、逻辑和访问外部信息与生成式AI模型结合的概念，引出了代理的概念，即超越生成式AI模型独立能力的程序。本白皮书将详细探讨这些及相关内容。

2 什么是Agent？ 

在最基本的形式中，生成式AI agent可以定义为一个应用程序，它通过观察世界并使用其可用的工具来采取行动，试图实现一个目标。agent是自主的，可以在没有人类干预的情况下独立行动，特别是在提供了适当的目标或目标时。agent也可以主动地采取行动来实现其目标。即使在没有人类明确指令的情况下，agent也可以推理下一步该做什么以实现其最终目标。虽然AI中的agent概念非常广泛且强大，但本白皮书重点介绍生成式AI模型在发布时能够构建的特定类型的agent。

为了理解agent的内部工作原理，我们首先介绍驱动agent行为、行动和决策的基本组件。这些组件的组合可以描述为认知架构，通过混合和匹配这些组件可以实现许多这样的架构。专注于核心功能，agent的认知架构中有三个基本组件，如图1所示。

图1 通用agent架构及组件

模型

在agent的范围内，模型指的是将用作agent过程集中决策者的语言模型（LM）。agent使用的模型可以是一个或多个任何大小（小/大）的LM，能够遵循基于指令的推理和逻辑框架，如ReAct、Chain-of-Thought或Tree-of-Thoughts。模型可以是通用的、多模态的，也可以根据特定agent架构的需求进行微调。为了获得最佳的生产结果，您应该利用最适合您最终应用需求的模型，理想情况下，该模型已经过与您计划在认知架构中使用的工具相关的数据签名训练。需要注意的是，模型通常不会使用agent的特定配置设置（即工具选择、编排/推理设置）进行训练。然而，通过提供展示agent能力的示例，包括agent在各种上下文中使用特定工具或推理步骤的实例，可以进一步优化模型以适应agent的任务。

工具

尽管基础模型在文本和图像生成方面表现出色，但它们仍然受到无法与外部世界互动的限制。工具弥补了这一差距，使agent能够与外部数据和服务互动，从而解锁比底层模型单独所能实现的更广泛的行动。工具可以采取多种形式，并具有不同的复杂性，但通常与常见的Web API方法（如GET、POST、PATCH和DELETE）保持一致。例如，工具可以更新数据库中的客户信息或获取天气数据以影响agent向用户提供的旅行建议。通过工具，agent可以访问和处理现实世界的信息。这使它们能够支持更专业的系统，如检索增强生成（RAG），这显著扩展了agent的能力，超越了基础模型单独所能实现的范围。我们将在下面详细讨论工具，但最重要的是要理解，工具弥补了agent内部能力与外部世界之间的差距，解锁了更广泛的可能性。

编排层

编排层描述了一个循环过程，该过程管理agent如何接收信息、执行一些内部推理，并使用该推理来通知其下一步行动或决策。通常，这个循环将持续到agent达到其目标或停止点。编排层的复杂性可以根据agent及其执行的任务而有很大差异。一些循环可以是简单的计算和决策规则，而其他循环可能包含链式逻辑、涉及额外的机器学习算法或实现其他概率推理技术。我们将在认知架构部分详细讨论agent编排层的实现。

agent与模型的区别

为了更清楚地理解agent与模型之间的区别，参考以下图表：

认知架构：agent如何运作

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

• 他们收集信息，如顾客的订单以及厨房和冰箱中的食材。

• 他们根据刚刚收集到的信息进行一些内部推理，思考可以制作哪些菜肴和风味。

• 他们采取行动制作菜肴：切蔬菜、混合香料、煎肉。

在过程的每个阶段，厨师根据需要做出调整，随着食材的消耗或顾客反馈的接收，细化他们的计划，并使用之前的结果集来确定下一步的行动计划。这种信息收集、计划、执行和调整的循环描述了厨师为实现目标所采用的独特认知架构。

就像厨师一样，agent可以使用认知架构通过迭代处理信息、做出明智决策并根据之前的输出细化下一步行动来实现其最终目标。在agent认知架构的核心是编排层，负责维护记忆、状态、推理和计划。它利用快速发展的提示工程领域及相关框架来指导推理和计划，使agent能够更有效地与环境互动并完成任务。提示工程框架和任务规划的研究正在迅速发展，产生了许多有前景的方法。虽然不是详尽无遗的列表，但这些是发布时最流行的框架和推理技术：

• ReAct，一种提示工程框架，为语言模型提供了一种思维过程策略，以推理并采取行动响应用户查询，无论是否有上下文示例。ReAct提示已显示出优于多个SOTA基线，并提高了LLM的人类互操作性和可信度。

• Chain-of-Thought (CoT)，一种提示工程框架，通过中间步骤实现推理能力。CoT有多种子技术，包括自一致性、主动提示和多模态CoT，每种技术根据具体应用具有不同的优缺点。

• Tree-of-Thoughts (ToT)，一种提示工程框架，非常适合探索或战略前瞻任务。它概括了链式思维提示，并允许模型探索各种思维链，作为语言模型通用问题解决的中间步骤。

Agents可以利用上述推理技术之一，或许多其他技术，为给定的用户请求选择下一步最佳行动。例如，考虑一个被编程为使用ReAct框架来为用户查询选择正确行动和工具的agent。事件序列可能如下：

1. 用户向agent发送查询

2. agent开始ReAct序列

3. agent向模型提供提示，要求其生成下一个ReAct步骤及其相应的输出：

 a. 问题：来自用户查询的输入问题，随提示提供

 b. 思考：模型关于下一步该做什么的思考

 c. 行动：模型关于下一步采取什么行动的决定

   i. 这里可以选择工具

   ii. 例如，行动可以是[Flights, Search, Code, None]之一，其中前三个代表模型可以选择的一个已知工具，最后一个代表“无工具选择”

  d. 行动输入：模型关于向工具提供什么输入的决定（如果有） 

  e. 观察：行动/行动输入序列的结果

    i. 这个思考/行动/行动输入/观察可以根据需要重复N次

  f. 最终答案：模型提供给原始用户查询的最终答案

4. ReAct循环结束，并向用户提供最终答案

图2 使用ReAct推理的agent示例

如图2所示，模型、工具和agent配置共同作用，根据用户的原始查询提供基于事实的简明响应。虽然模型可能根据其先验知识猜测答案（幻觉），但它使用了一个工具（Flights）来搜索实时外部信息。这些额外信息被提供给模型，使其能够基于真实的事实数据做出更明智的决策，并将这些信息总结给用户。

总之，agent响应的质量直接与模型推理和行动这些各种任务的能力相关，包括选择正确工具的能力，以及工具定义的好坏。就像厨师用新鲜食材制作菜肴并关注顾客反馈一样，agent依赖于合理的推理和可靠的信息来提供最佳结果。在下一节中，我们将深入探讨agent与新鲜数据连接的各种方式。

3 工具：Agent与外部世界的桥梁

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

虽然它们的名称各式各样，但工具是在我们的基础模型和外部世界之间建立联系的东西。在外部系统和数据的这种联系之下，我们的智能体能够执行更广泛的任务，并且更加准确和可靠。例如，工具可以使智能体能够调整智能家居设置、更新日历、从数据库中获取用户信息或根据特定指令发送电子邮件。

截至目前，谷歌模型能够与之交互的主要工具类型有三种：扩展（Extensions）、函数（Functions）和数据存储（Data Stores）。通过为智能体配备工具，我们释放了它们巨大的潜力，使其不仅能够理解世界，还能与世界交互，从而开启了无数新应用和可能性的大门。

扩展（Extensions）

理解扩展（Extensions）的最简单方法是将其视为以一种标准化的方式弥合 API 与智能体之间的差距，使智能体能够无缝执行 API，而不论其底层实现如何。假设你构建了一个旨在帮助用户预订航班的智能体。你知道你想使用谷歌航班 API 来检索航班信息，但你不确定如何让你的智能体调用这个 API 端点。

图3 智能体如何与外部应用程序编程接口（API）进行交互？

一种方法可以是编写自定义代码，该代码接收传入的用户查询，解析查询以获取相关信息，然后进行API调用。例如，在航班预订用例中，用户可能会说 “我想预订从奥斯汀到苏黎世的航班”。在这种情况下，我们的自定义代码解决方案需要从用户查询中提取 “奥斯汀” 和 “苏黎世” 作为相关实体，然后再尝试进行API调用。但如果用户说 “我想预订去苏黎世的航班”，却始终未提供出发城市，会发生什么情况呢？没有所需的数据，API调用将会失败，并且需要编写更多代码来处理此类极端和特殊情况。这种方法不具备可扩展性，在任何超出已编写自定义代码范围的场景中都很容易出现问题。

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

1. 通过示例向智能体传授如何使用API端点。

2. 向智能体传授成功调用API端点所需的参数。

图4  扩展将智能体与外部应用程序编程接口（API）相连

扩展可以独立于智能体进行构建，但应作为智能体配置的一部分提供。智能体在运行时利用模型和示例来决定（若有）哪个扩展适合解决用户的查询。这凸显了扩展的一个关键优势，即其内置的示例类型，这使得智能体能够为任务动态选择最合适的扩展。

图5 智能体、扩展和应用程序编程接口（API）之间的一对多关系

可以这样理解，就如同软件开发人员在为用户解决问题并设计解决方案时，会决定使用哪些API端点。如果用户想要预订航班，开发人员可能会使用谷歌航班API。如果用户想知道离他们位置最近的咖啡店在哪，开发人员可能会使用谷歌地图API。同样，智能体/模型组合会利用一组已知的扩展，来确定哪一个最适合用户的查询。如果你想看看扩展的实际运行效果，可以在Gemini应用程序中进行尝试，路径为：设置>扩展，然后启用任何你想测试的扩展。例如，你可以启用谷歌航班扩展，然后问Gemini “显示下周五从奥斯汀到苏黎世的航班”。

为简化扩展的使用，谷歌提供了一些开箱即用的扩展，可快速导入到您的项目中，只需极少配置即可使用。例如，代码片段1中的代码解释器扩展，能让您根据自然语言描述生成并运行Python代码.

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

总而言之，扩展为智能体提供了一种以多种方式感知、交互和影响外部世界的途径。这些扩展的选择和调用是由示例的使用来引导的，所有示例都被定义为扩展配置的一部分。

函数（Functions）

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

在智能体领域，函数的工作方式非常相似，但我们可以用模型来替代软件开发人员。模型可以获取一组已知函数，并根据其规范决定何时使用每个函数以及该函数需要哪些参数。函数与扩展在几个方面有所不同，最显著的是：

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

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

我们再以谷歌航班为例，函数的一个简单设置可能如图7中的示例所示。

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

这里的主要区别在于，无论是函数还是智能体都不会直接与谷歌航班API进行交互。那么，API调用实际上是如何发生的呢？

使用函数时，调用实际API端点的逻辑和执行从智能体转移回客户端应用程序，如下图8和图9所示。这使开发人员能够更精细地控制应用程序中的数据流。开发人员选择使用函数而非扩展有诸多原因，常见用例如下：

• API调用需要在应用程序栈的另一层进行，不在智能体的直接架构流程内（例如，中间件系统、前端框架等）。

• 存在安全或认证限制，导致智能体无法直接调用 API（例如，API 未对外开放，或者智能体所在基础设施无法访问该 API ）

• 时间安排或操作顺序方面的限制，使得智能体无法实时进行 API 调用。（例如批量操作、人工介入审核等）

• 还需要对 API 响应应用智能体无法执行的额外数据转换逻辑。例如，假设有一个 API 端点没有提供用于限制返回结果数量的过滤机制。在客户端使用函数，能为开发人员提供进行此类转换的更多机会

• 开发人员希望在不针对 API 端点部署额外基础设施的情况下，进行智能体开发的迭代（即函数调用可起到类似 API “存根” 的作用）

如图 8 所示，尽管这两种方法在内部架构上的差异很细微，但函数调用在对外部基础设施方面提供了更多控制和依赖解耦，这使其对开发人员而言颇具吸引力。

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

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

我想和家人一起去滑雪旅行，但不确定该去哪里。

在向模型提出的典型提示下，输出可能如下：

当然，以下是一些你可以考虑与家人一起去滑雪旅行的城市：

• 美国科罗拉多州克雷斯特德比特

• 加拿大不列颠哥伦比亚省惠斯勒

• 瑞士采尔马特

虽然上述输出包含了我们需要的数据（城市名称），但其格式不利于解析。通过函数调用，我们可以教会模型以结构化的风格（如JSON）来格式化此输出，这样更便于其他系统进行解析。对于用户给出的相同输入提示，函数输出的示例JSON可能如代码片段5所示。

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

此JSON有效载荷由模型生成，然后发送到我们的客户端服务器，以便我们根据需要对其进行处理。在这种特定情况下，我们将调用谷歌地点API，获取模型提供的城市信息并查找相关图片，然后将其作为格式化的富内容提供给用户。请参考图9中的序列图，它详细展示了上述交互的逐步过程。

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

图9中示例的结果是，利用模型来“填空”，提供客户端用户界面（UI）调用谷歌地点API所需的参数。客户端UI使用模型在返回的函数中提供的参数来管理实际的API调用。这只是函数调用的一个用例，但还有许多其他场景可以考虑，比如：

• 你希望语言模型推荐一个可在代码中使用的函数，但又不想在代码中包含凭证信息。由于函数调用并不实际运行函数，所以你无需在代码中随函数信息一同包含凭证。

• 你正在运行可能需要数秒以上时间的异步操作。这些场景很适合使用函数调用，因为它本身就是一种异步操作。

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

关于函数，需要记住的一个关键要点是，它不仅旨在让开发者对API调用的执行拥有更多控制权，还能让开发者更好地掌控整个应用程序中的数据流动。在图9的示例中，开发者选择不将API信息返回给智能体，因为这与智能体未来可能采取的行动无关。然而，根据应用程序的架构，为了影响智能体未来的推理、逻辑和行动选择，将外部API调用数据返回给智能体或许是有意义的。最终，具体如何选择要取决于应用程序开发者，需根据特定应用的需求来决定。

为了在我们的滑雪度假场景中实现上述输出，让我们构建各个组件，使其能与我们的gemini - 1.5 - flash - 001模型协同工作。

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

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

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

代码片段7 构建工具，将其与用户查询一起发送给模型，并允许函数调用发生

总之，函数提供了一个简单明了的框架，使应用程序开发人员能够精细地控制数据流和系统执行，同时有效地利用智能体 / 模型来生成关键输入。开发人员可以根据特定的应用程序架构要求，有选择地决定是通过返回外部数据让智能体 “参与其中”，还是将其省略。

数据存储

可以将语言模型想象成一个包含其训练数据的大型图书馆。但与不断获取新书的图书馆不同，这个图书馆是静态的，仅包含它最初接受训练时的知识。这带来了一个挑战，因为现实世界的知识在不断发展。数据存储通过提供对更动态和最新信息的访问，解决了这一限制，并确保模型的响应基于事实且具有相关性。

考虑一个常见的场景，开发者可能需要向模型提供少量额外的数据，也许是以电子表格或 PDF 的形式。

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

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

图11 数据存储将智能体与各类新的实时数据源连接起来

在生成式人工智能智能体的背景下，数据存储通常被实现为一个向量数据库，开发者希望智能体在运行时能够访问该数据库。虽然我们在此不会深入探讨向量数据库，但关键要理解的是，它们以向量嵌入的形式存储数据，这是一种对所提供数据的高维向量或数学表示。近年来，语言模型使用数据存储的一个极为常见的例子是检索增强的实现。

基于检索增强生成（RAG）的应用程序。这些应用程序旨在通过让模型能够访问各种格式的数据，突破基础训练数据的限制，拓宽和加深模型的知识广度与深度，这些数据格式包括：

• 网站内容

• 结构化数据，格式如 PDF、Word 文档、CSV、电子表格等

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

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

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

1. 用户查询被发送到一个嵌入模型，为该查询生成嵌入向量。

2. 然后，使用如 SCaNN 这样的匹配算法，将查询嵌入向量与向量数据库中的内容进行匹配。

3. 从向量数据库中以文本格式检索出匹配的内容，并将其发送回智能体。

4. 智能体接收用户查询和检索到的内容，然后生成回应或采取行动。

5. 最终的回复会发送给用户。

图13 基于检索增强生成（RAG）应用中用户请求与智能体响应的生命周期

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

图14展示了一个与智能体的示例交互，该智能体结合了检索增强生成（RAG）与ReAct推理/规划。

图14 基于检索增强生成（RAG）并结合ReAct推理/规划的示例应用

总而言之，扩展、函数和数据存储构成了智能体在运行时可使用的几种不同工具类型。每种工具都有其独特用途，智能体开发者可酌情决定将它们结合使用或单独使用。

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

有效使用模型的一个关键方面是它们在生成输出时选择正确工具的能力，尤其是在生产中大规模使用工具时。虽然一般训练有助于模型发展这种技能，但现实世界的场景通常需要超越训练数据的知识。想象一下，这就像基本烹饪技能与掌握特定菜系之间的区别。两者都需要基础的烹饪知识，但后者需要针对性学习以获得更细致的结果。

为了帮助模型获得这种特定知识，存在几种方法：

• 上下文学习：这种方法在推理时向通用模型提供提示、工具和少量示例，使其能够“即时”学习如何以及何时使用这些工具来完成特定任务。ReAct框架是自然语言中这种方法的一个示例。

• 基于检索的上下文学习：这种技术通过从外部存储器中检索最相关的信息、工具和相关示例来动态填充模型提示。例如，Vertex AI扩展中的“示例存储”或之前提到的RAG架构中的数据存储。

• 基于微调的学习：这种方法涉及在推理之前使用更大的特定示例数据集训练模型。这有助于模型在接收任何用户查询之前理解何时以及如何应用某些工具。

为了提供关于每种针对性学习方法的更多见解，让我们重新审视我们的烹饪类比。

• 想象一下，一位厨师收到了一个特定的食谱（提示）、一些关键食材（相关工具）和几道示例菜肴（少量示例）来自顾客。基于这些有限的信息和厨师对烹饪的一般知识，他们需要“即时”准备一道最符合食谱和顾客偏好的菜肴。这就是上下文学习。

• 现在想象一下，我们的厨师在一个备有各种食材和食谱（示例和工具）的厨房里。厨师现在能够从食品储藏室中动态选择食材和食谱，并更好地与顾客的食谱和偏好对齐。这使得厨师能够利用现有和新知识创建更明智和精致的菜肴。这就是基于检索的上下文学习。

• 最后，想象一下，我们送我们的厨师回学校学习一种新菜系或一组菜系（在更大的特定示例数据集上进行预训练）。这使得厨师能够以更深入的理解处理未来未见的顾客食谱。如果我们希望厨师在特定菜系（知识领域）中表现出色，这种方法非常完美。这就是基于微调的学习。

每种方法在速度、成本和延迟方面都有独特的优势和劣势。然而，通过在agent框架中结合这些技术，我们可以利用各种优势并最小化其劣势，从而实现更强大和适应性更强的解决方案。

5 使用LangChain快速启动Agent

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

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

代码片段8 使用LangChain和LangGraph构建的带有工具的agent示例

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

虽然这是一个相当简单的agent示例，但它展示了模型、编排和工具共同工作以实现特定目标的基本组件。在最后一节中，我们将探讨这些组件如何在Google规模的管理产品（如Vertex AIagent和生成式剧本）中结合在一起。

6 使用Vertex AI agents的生产应用

虽然本白皮书探讨了agents的核心组件，但构建生产级应用程序需要将它们与用户界面、评估框架和持续改进机制等附加工具集成。Google的Vertex AI平台通过提供一个完全托管的环境简化了这一过程，其中包含所有前面介绍的基本元素。使用自然语言界面，开发人员可以快速定义其agent的关键元素——目标、任务指令、工具、用于任务委派的子agent和示例——以轻松构建所需的系统行为。此外，该平台附带一组开发工具，允许测试、评估、测量agent性能、调试和提高开发agent的整体质量。这使得开发人员能够专注于构建和完善他们的agent，而基础设施、部署和维护的复杂性则由平台本身管理。

在图15中，我们提供了一个在Vertex AI平台上构建的agent的示例架构，使用了各种功能，如Vertexagent构建器、Vertex扩展、Vertex函数调用和Vertex示例存储等。该架构包括许多生产就绪应用程序所需的各种组件。

图15 在Vertex AI平台上构建的端到端agent架构示例

您可以从我们的官方文档中尝试此预构建agent架构的示例。

7 总结

1.  agents通过利用工具扩展了语言模型的能力，以访问实时信息、建议现实世界的行动，并自主规划和执行复杂任务。agents可以利用一个或多个语言模型来决定何时以及如何通过状态转换，并使用外部工具完成模型单独难以或无法完成的任何数量的复杂任务。

2.  agent操作的核心是编排层，这是一种认知架构，它构建推理、计划、决策并指导其行动。各种推理技术，如ReAct、Chain-of-Thought和Tree-of-Thoughts，为编排层提供了一个框架，以接收信息、执行内部推理并生成明智的决策或响应。

3.  工具，如扩展、函数和数据存储，作为agent与外部世界的桥梁，使它们能够与外部系统交互并访问超越其训练数据的知识。扩展提供了agent与外部API之间的桥梁，使API调用和实时信息的检索成为可能。函数通过分工为开发人员提供了更细致的控制，允许agent生成可以在客户端执行的函数参数。数据存储为agent提供了对结构化和非结构化数据的访问，使数据驱动的应用程序成为可能。

agents的未来充满了令人兴奋的进步，我们才刚刚开始触及可能的表面。随着工具变得更加复杂，推理能力得到增强，agent将能够解决日益复杂的问题。此外，“agent chaining”的战略方法将继续获得动力。通过结合擅长特定领域或任务的专门agent，我们可以创建一种“mixture of agent experts”方法，能够在各个行业和问题领域提供卓越的结果。

重要的是要记住，构建复杂的agent架构需要迭代方法。实验和细化是找到特定业务案例和组织需求解决方案的关键。由于支撑其架构的基础模型的生成性质，没有两个agent是相同的。然而，通过利用这些基本组件的优势，我们可以创建扩展语言模型能力并推动现实世界价值的应用程序。