1.引言

这种结合了推理、逻辑以及连接生成式AI模型的外部信息的方式，催生了"智能体"这一概念。

人类擅长处理复杂的模式识别任务，但他们往往依赖工具——如书籍、谷歌搜索或计算器——在得出结论前补充已有知识。与人类相似，生成式AI模型也可被训练使用工具以获取实时信息或执行现实操作。例如，模型可通过数据库检索工具访问特定信息（如客户购买记录），从而生成个性化购物推荐；或根据用户查询调用多个API接口，代为发送邮件回复同事或完成金融交易。要实现这类功能，模型不仅需要接入外部工具集，还必须具备自主规划与执行任务的能力。这种将推理能力、逻辑思维与外部信息访问有机结合，并与生成式AI模型相连的理念，催生了"智能体"的概念——即对生成式AI独立功能进行拓展的程序。本白皮书将对此及相关方面展开深入探讨。

2.什么是智能体？

最基本形式的生成式AI智能体可定义为这样一种应用程序：它试图通过观察世界并利用其掌握的工具采取行动来实现目标。这类智能体具有自主性，能够在无人干预的情况下独立运作——尤其是在获得明确目标任务时。它们还能以主动进取的方式实现目标，即便没有人类输入的明确指令集，智能体仍可自主推理应当采取的后续行动以达成终极目标。尽管AI领域中的智能体概念具有普适性和强大包容性，本白皮书主要探讨当前技术条件下生成式AI模型能够构建的特定类型智能体。

为理解智能体的内部运作机制，我们首先需要介绍驱动其行为、动作及决策的基础组件。这些组件的组合可视为一种认知架构，而通过不同组件的混合搭配可实现多种此类架构。聚焦核心功能层面，如图1所示，智能体认知架构主要由三个关键组件构成。

图1. 通用智能体架构与组件

2.1模型

在智能体范畴中，模型指作为其核心决策机制所采用的语言模型（LM）。一个智能体可使用单个或多个任意规模（小型/大型）的语言模型，这些模型需具备遵循指令驱动的推理与逻辑框架能力，例如思维协同（ReAct）、思维链（Chain-of-Thought）或思维树（Tree-of-Thoughts）。模型可为通用型、多模态型或根据特定智能体架构需求微调的定制型。为获得最优生产效果，应选择最契合目标终端应用的模型，并理想情况下已在与认知架构拟用工具相关的数据特征上进行训练。需注意的是，模型通常不会基于智能体的具体配置（如工具选择、协调/推理设置）进行训练，但可通过提供示范案例（包括智能体在不同情境下使用特定工具或推理步骤的实例）来针对其任务进一步优化模型。

2.2工具

基础模型虽然能生成令人印象深刻的文本和图像，但仍受限于无法与外界交互的特性。工具填补了这一空白，使智能体能够与外部数据和服务互动，从而解锁超越基础模型本身的更广泛行动能力。工具可呈现多种形式，其复杂度也有所不同，但通常与常见的网络API方法（如GET、POST、PATCH和DELETE）保持一致。例如，某个工具可以更新数据库中的客户信息，或是获取天气数据来影响智能体为用户提供的旅行建议。借助工具，智能体可访问并处理现实世界的信息。这使得它们能够支持检索增强生成（RAG）等更专业化的系统，从而极大扩展智能体的能力边界，远超基础模型单独所能达到的水平。我们将在下文详细讨论工具，但最关键的是要理解：工具在智能体的内部能力与外部世界之间架起了桥梁，从而开启更广阔的可能性空间。

2.3编排层

协作层描述了循环式的运作机制：智能体首先接收信息，随后进行内部推理，并运用推理结果指导后续行动或决策。该循环通常持续至智能体达成目标或抵达终止节点。协作层的复杂度因智能体类型及执行任务存在显著差异——既可能是基于决策规则的简单计算循环，也可能包含链式逻辑、调用额外机器学习算法，或应用其他概率推理技术。我们将在认知架构章节深入探讨智能体协作层的具体实现方案。

2.4.代理与模型

要更清晰地理解智能体与模型之间的区别，请参考以下图表：

2.5.认知架构：智能体运作机制

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

• 他们收集信息，例如顾客的点单以及 pantry（食品储藏室）和冰箱中的现有食材。
• 根据已采集的信息，他们对可制作的菜品风味组合进行内部推演。
• 他们采取烹饪行动：切配蔬菜、混合香料、煎炙肉类。

在这一过程的每个阶段，厨师会根据需要做出调整，例如在原料耗尽或收到顾客反馈时完善计划，并利用以往一系列的操作结果来决定下一步行动方案。这种信息获取、计划制定、执行与调整的循环，体现了一位厨师为实现目标所运用的独特认知架构。

正如厨师一般，智能体也能借助认知架构实现最终目标——通过迭代处理信息、作出明智决策，并基于先前输出优化后续动作。认知架构的核心在于编排层，其负责维护记忆、状态、推理与规划功能。该层运用快速发展的提示工程领域技术及相关框架来引导推理与规划，使智能体能与环境更高效交互并完成任务。针对语言模型的提示工程框架与任务规划研究正飞速演进，已催生出多种前景广阔的方法。尽管难以穷尽列举，但以下是截至本文发表时最主流的几种框架与推理技术：

• ReAct是一种提示工程框架，通过为语言模型提供"思考-行动"的策略流程（无论是否使用上下文示例），使其能够对用户查询进行推理并采取行动。研究表明，ReAct提示方法的性能超越了多个最先进的基线模型，同时增强了人类与大型语言模型的互操作性及可信度。

• 思维链（Chain-of-Thought, CoT）是一种通过中间步骤实现推理能力的提示工程框架。CoT包含多种子技术，如自我一致性、主动提示和多模态思维链等，这些技术根据具体应用场景各有优劣。

• 思维树（Tree-of-Thoughts, ToT）是一种适用于探索性任务或战略前瞻性任务的提示工程框架。该框架对思维链提示进行了泛化，允许模型探索不同思维路径作为中间步骤，从而实现语言模型在通用问题解决方面的能力。

代理可以采用上述任一推理技术或其他多种技术，来为给定的用户请求选择最优的后续操作。例如，假设某个代理预设使用ReAct框架来为用户查询选择正确的操作与工具，其执行流程可能如下所示：

1. 用户向智能体发送查询
2. 智能体启动ReAct序列
3. 智能体向模型提供提示，要求其生成下一个ReAct步骤及对应输出：
   a. 问题：来自用户查询的输入问题（随提示提供）
   b. 思考：模型关于下一步行动的推理
   c. 行动：模型决定的下一步动作
   i. 可在此选择工具
   ii. 例如，动作可能是[航班查询、搜索、代码、无]，前3项代表模型可选的已知工具，最后一项代表“不选择工具”
   d. 行动输入：模型对工具输入的决策（如有）
   e. 观察：行动/行动输入序列的结果
   i. 该思考/行动/行动输入/观察可根据需要重复N次
   f. 最终答案：模型针对原始用户查询的最终响应
4. ReAct循环结束并向用户返回最终答案

如图2所示，模型、工具和代理配置系统协同工作，根据用户的原始查询回馈一个可靠且简洁的响应。虽然模型本可以依靠既有知识猜测答案（产生幻觉式推断），但这次它选择调用工具（航班查询）来检索实时外部信息。这些补充信息被输入模型，使其能基于真实数据做出更高信息密度的决策，并将提炼后的结果汇总回复给用户。

图2. 编排层中具备ReAct推理能力的示例代理

综上所述，智能体响应的质量直接取决于模型对这些多样化任务的推理与执行能力，包括正确选择工具的能力以及工具定义的完善程度。
正如厨师用新鲜食材烹饪并关注顾客反馈一样，智能体依赖可靠的推理与信息来交付最佳结果。下一节中，我们将深入探讨智能体实时连接新数据的多种方式。

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

尽管语言模型擅长处理信息，但它们无法直接感知并影响现实世界。这限制了其在需要与外部系统或数据交互的场景中的实用性。换言之，语言模型的能力本质上受限于其所学习的训练数据。但无论向模型灌输多少数据，其仍缺乏与外界交互的基础能力。那么我们该如何使模型具备与外部系统进行实时、情景感知交互的能力？功能模块、扩展组件、数据存储及插件机制，皆为赋予模型这一核心能力的实现路径。

虽然这些工具有多种称谓，但它们在建模范式与外部世界之间建立了关键纽带。这种与外部系统及数据的连接，使智能体能够执行更广泛的任务，同时提升操作的精确性与可靠性。例如，工具可使智能体根据预设指令调整智能家居设置、更新日程、从数据库调取用户信息或发送电子邮件。

截至本文发稿之日，Google模型可交互的主要工具类型有三种：扩展程序、功能组件与数据存储库。通过为智能体配备这些工具，我们不仅释放了它们理解世界的巨大潜力，更使其能够主动作用于现实世界，从而为无数新应用场景与可能性开启大门。

3.1 扩展

理解Extensions（扩展）最简单的方式，是将其视为以标准化方式弥合API与智能体之间差距的桥梁，使得智能体能够无缝执行各种API，无论其底层实现如何不同。假设您构建了一个旨在帮助用户预订航班的智能体，并计划通过Google Flights API获取航班信息，但不确定如何让智能体调用该API接口。

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

一种可行方案是编写定制代码，用于接收用户查询语句后解析出关键信息，进而发起API调用。以航班预订场景为例，当用户输入"我想预订从奥斯汀飞往苏黎世的航班"时，定制代码需先从查询中提取"奥斯汀"和"苏黎世"这两个关键实体才能进行API调用。但如果用户仅表述"我想预订去苏黎世的航班"却未提供出发城市呢？由于缺失必要参数，API调用将失败，这就需要额外编写代码来处理此类边界案例。这种方案缺乏扩展性，任何超出预设代码范畴的使用场景都可能导致系统中断。

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

1. 通过示例教会智能体如何使用API端点。
2. 教会智能体成功调用API端点所需的参数或 Arguments。

图4. 扩展组件将智能体与外部API相连接

扩展功能可独立于智能体开发，但需作为智能体配置的一部分提供。该智能体在运行时通过模型和示例来判断何种扩展（如有）最适合解决用户查询。这凸显了扩展功能的核心优势——其内建的示例类型使智能体能够动态选择最适合当前任务的扩展。

图5. 代理、扩展与API间的一对多关系

将此过程类比为软件开发者在解决用户问题时如何选择API端口的决策逻辑。若用户需要预订航班，开发者可能会调用谷歌航班API；若要查询当前位置附近的咖啡馆，则可能选择谷歌地图API。同理，智能代理/模型栈会通过预置的扩展程序集，判定哪一个最适合响应用户查询。

若想亲身体验扩展功能，可前往Gemini应用的设置 > 扩展程序菜单，启用任意扩展进行测试。例如启用谷歌航班扩展后，即可询问Gemini「显示下周五从奥斯汀飞往苏黎世的航班信息」。

扩展示例

为简化扩展功能的使用，Google预置了若干开箱即用的扩展程序，可快速导入项目并以最少配置投入应用。例如代码片段1中的代码解释器扩展（Code Interpreter extension），支持根据自然语言描述生成并运行Python代码。

总而言之，扩展功能使代理能够以多种方式感知、交互并影响外部世界。这些扩展的选择与调用通过示例引导，所有示例均定义为扩展配置的组成部分。

3.2 Functions

在软件工程领域，函数被定义为自成模块的代码单元，用于完成特定任务并可根据需要重复使用。软件开发人员在编写程序时，通常会创建多个函数来完成不同任务，同时定义调用函数A与函数B的逻辑，并明确其预期输入与输出。

在智能体领域中，函数的工作机制非常相似，但我们可以用模型替代软件开发者的角色。模型能够根据规范，从已知函数集中决策何时调用每个函数及其所需参数。函数与扩展的关键区别在于：

1. 模型会输出函数及其参数，但不会实时发起API调用；
2. 函数在客户端执行，而扩展则在智能体端执行。

再以我们的Google Flights示例而言，一个简单的函数设置可能类似于图7所示范例。

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

请注意，此处的核心区别在于函数（Function）和代理（agent）均未直接与Google Flights API交互。那么API调用究竟是如何实现的？

通过将调用实际API端点的逻辑和执行转移至客户端应用程序（如图8和图9所示），函数的应用使代理程序得以解脱。这为开发者提供了对应用数据流更精细的控制能力。

开发者选择使用函数而非扩展的常见场景包括：

· 需要在应用架构的其他层级（如中间件系统、前端框架等）进行API调用，而非直接通过代理架构流实现
· 由于安全认证限制，代理程序无法直接调用API（例如：API未暴露于互联网，或代理架构无法访问）
· 存在时序或操作顺序约束，导致代理无法实时调用API（如批处理操作、人工审核环节等）
· 需对API响应实施代理程序无法完成的数据转换逻辑（例如：当API端点未提供结果集数量限制的过滤机制时，客户端函数能为开发者提供额外数据处理空间）
· 开发者希望在不部署额外API基础设施的情况下迭代代理开发（函数调用可充当API"桩代码"作用）

尽管两种方法的内部架构差异在图8中显得微妙，但函数调用因其额外的控制能力及对外部基础设施的解耦依赖，使其成为开发者颇具吸引力的选择。

图8. 插件与函数调用中客户端与代理端控制的范围界定

用例

模型可被用来调用函数，以便为用户处理复杂的客户端执行流程，尤其是当开发者不希望语言模型直接管理API执行时（如扩展功能的情形）。以下是一个示例场景：假设我们正在训练一个旅行管家助手与用户交互，帮助用户预订度假行程。目标是通过助手生成一个城市列表，供中间件应用程序下载相关图片、数据等，以协助用户规划行程。用户可能会输入如下内容：

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

通常给模型的提示词，输出可能如下：

以下是一些适合家庭滑雪旅行的城市供您参考：
• 美国科罗拉多州克雷斯特德比特
• 加拿大不列颠哥伦比亚省惠斯勒
• 瑞士泽玛特

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

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

该JSON有效载荷由模型生成，随后发送至我们的客户端服务器，以执行任意后续操作。在本特定案例中，我们将调用Google Places API，提取模型提供的城市数据并检索对应图像，最终将其格式化为富内容丰富回馈给用户。请参阅图9中的序列图，该图逐步详细展示了上述交互流程。

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

图9的示例结果表明，该模型被用于“填补空白”，提供客户端UI调用Google Places API所需的参数。客户端UI通过模型在返回函数中提供的参数来管理实际的API调用。这只是函数调用的一个应用场景，但还有其他多种需考虑的情形，例如：

• 希望语言模型建议可在代码中使用的函数，但不想在代码中包含凭证。由于函数调用不执行该函数，因此无需在代码的函数信息中添加凭证。
• 正在运行可能耗时数秒以上的异步操作。此类场景非常适合函数调用，因为它本身就是异步操作。
• 需要在与生成函数调用及其参数的系统不同的设备上运行函数。

关于函数需要记住的一个关键点是，它们不仅能让开发者更好地控制API调用的执行，还能掌控应用程序中数据的整体流转流程。在图9的示例中，开发者选择不将API信息返回给代理（agent），因为这些信息与该代理后续可能采取的操作无关。不过根据应用程序的架构设计，将外部API调用的数据返回给代理可能更为合理，从而影响其后续的推理、逻辑和动作选择。最终应由应用程序开发者根据具体需求做出抉择。

函数示例代码

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

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

接下来我们将实例化模型，构建工具，随后将用户查询及相关工具传入模型。执行下方代码可得到代码片段底部显示的输出结果。

片段7. 构建工具，将其与用户查询一并发送至模型，并允许函数调用的发生

总之，函数提供了一个简洁的框架，既能让应用开发人员精准控制数据流和系统执行，又能高效利用智能体/模型生成关键输入项。开发者可根据特定应用架构需求灵活选择是否通过返回外部数据将智能体置于"循环中"，或将其完全跳过。

数据存储

想象语言模型如同一个容纳了全部训练数据的庞大图书馆。但与不断添置新书的图书馆不同，这个图书馆保持着静态，仅包含初始训练获得的知识。这就带来一项挑战：现实世界的知识始终在演进。数据存储组件通过提供动态更新的信息访问来突破这一局限，确保模型的响应始终基于事实且密切关联。

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

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

数据存储（Data Stores）允许开发者以原始格式向智能体提供额外数据，从而省去了耗时的数据转换、模型重新训练或微调步骤。数据存储将传入的文档转换为一组向量数据库嵌入（embedding），智能体可据此提取所需信息，用以增强其下一步操作或对用户的响应。

图11. 数据存储将智能代理与各类新型实时数据源相连接。

实施与应用

在生成式AI代理的背景下，数据存储通常被实现为向量数据库，开发者希望代理在运行时能够访问该数据库。虽然此处我们不会深入探讨向量数据库，但需要理解的关键点是它们以向量嵌入的形式存储数据——这是一种高维向量或所提供数据的数学表征。近期语言模型中数据存储应用最广泛的案例之一是基于检索增强生成（RAG）技术的应用实现。这类应用程序通过为模型提供访问多种格式数据的能力，试图将模型的认知广度和深度拓展至基础训练数据之外。

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

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

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

1. 用户查询被发送至嵌入模型以生成其向量表征
2. 查询向量通过SCaNN等匹配算法与向量数据库的内容进行相似性比对
3. 匹配内容以文本形式从向量数据库检索并返回至智能体
4. 智能体接收用户查询及检索内容，随后生成响应或执行动作
5. 最终响应被返回至用户

图13. 基于RAG应用的"用户请求-智能体响应"生命周期

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

一个与采用ReAct推理/规划实现RAG的智能体交互示例如图14所示。

图14. 基于RAG的样本应用（融合ReAct推理/规划）

工具回顾

总而言之，扩展功能、函数及数据存储构成了供智能体在运行时使用的几种不同工具类型。每种工具皆有其特定用途，开发者可根据实际需求决定将其组合使用或单独调用。

总而言之，扩展功能、函数及数据存储构成了供智能体在运行时使用的几种不同工具类型。每种工具皆有其特定用途，开发者可根据实际需求决定将其组合使用或单独调用。

	扩展	函数调用	数据存储
执行	代理端执行	客户端执行	代理端执行
用例	• 开发者希望由代理控制与API端点的交互 • 适用于使用原生预构建扩展的场景（如Vertex搜索、代码解释器等） • 多跳规划与API调用（即后续代理操作取决于前一个操作/API调用的输出结果）	• 安全或身份验证限制阻止代理程序直接调用API • 时间约束或操作顺序约束导致代理无法实时进行API调用（例如批量操作、人工审核循环等） • 未向互联网公开的API，或Google系统无法访问的API	开发者希望实现检索增强生成（RAG）功能，支持以下任意数据类型： • 来自预索引域名及URL的网站内容 • 结构化数据（如PDF、Word文档、CSV、电子表格等格式） • 关系型/非关系型数据库 • 非结构化数据（如HTML、PDF、TXT等格式）

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

有效使用模型的关键在于其生成输出时选择合适工具的能力，尤其在规模化生产环境中运用工具时更为重要。虽然常规训练有助于模型培养这一技能，但现实场景通常需要超出训练数据的知识。这好比基础烹饪技巧与掌握某一菜系之间的差别：二者皆需烹饪的基础知识，但后者需通过针对性学习才能获得更精妙的成果。

为帮助模型获取此类特定知识，存在多种方法：
• 上下文学习（In-context learning）：该方法在推理阶段向通用模型提供提示、工具及少量示例，使其能够动态掌握何时及如何针对特定任务使用这些工具。自然语言领域的ReAct框架便是此类方法的实例。
• 基于检索的上下文学习（Retrieval-based in-context learning）：该技术通过从外部存储检索最相关信息、工具及相关示例，动态填充模型提示。例如Vertex AI扩展中的「示例存储」（Example Store），或前文提及基于RAG架构的数据存储。
• 基于微调的学习（Fine-tuning based learning）：此方法需在推理前使用特定示例的大规模数据集训练模型，使模型在接受用户查询前预先掌握何时及如何应用特定工具。

为了进一步阐明每种目标学习方法，让我们重温烹饪的类比。

• 设想一位厨师收到顾客提供的特定菜谱（提示词）、几样关键食材（相关工具）和一些示例菜品（少量示例）。基于这些有限信息以及厨师对烹饪的常识，他们需要现场揣摩如何烹制最符合菜谱要求和顾客口味的菜肴。这正是上下文学习的工作原理。

• 现在假设我们的厨师身处一个储备丰富的厨房（外部存储库），里面堆满了各式食材（样本）和烹饪书籍（工具）。此时厨师能够动态地从储藏室选取食材和食谱，从而更精准地贴合顾客的菜谱与偏好。这使得厨师能结合既有知识与新信息，制作出更考究的菜肴。这便是基于检索的上下文学习。

• 最后，假设我们送这位厨师进修新派系或多种菜系（在特定样本的大型数据集上进行预训练）。当未来遇到陌生顾客菜谱时，厨师便能凭借更深厚的知识储备进行处理。若希望厨师精通特定菜系（知识领域），这种方法最为理想。这就是基于微调的学习。

每一种方法都在速度、成本和延迟方面各具优势与不足。然而，通过在多智能体框架中结合这些技术，我们能够充分发挥各方优势并规避其弱点，从而获得更稳健、适应性更强的解决方案。

5.LangChain智能体快速入门

为提供一个真实可执行的智能体运作示例，我们将使用LangChain和LangGraph库快速构建原型。这些流行的开源库允许用户通过将逻辑链、推理链和工具调用链"串联"起来，构建定制化智能体以响应用户查询。我们将采用gemini-1.5-flash-001模型及若干简单工具，如代码片段8所示，应对用户提出的多阶段查询需求。

片段8. 基于LangChain与LangGraph的带工具代理示例

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

片段9. 摘自代码片段8的程序输出

尽管这个智能体示例相对简单，但它展示了模型(Model)、编排(Orchestration)和工具这些基础组件如何协同工作以实现特定目标。在最后章节，我们将探讨这些组件如何在Vertex AI智能体和生成式剧本（Generative Playbooks）等谷歌级托管产品中实现集成。

6.基于Vertex AI智能体的生产应用

虽然本白皮书探讨了智能体的核心组件，但要构建生产级应用程序仍需将其与用户界面、评估框架和持续改进机制等辅助工具相集成。谷歌Vertex AI平台通过提供全面托管的运行环境（涵盖前文所述所有基础要素）大幅简化了这一流程。借助自然语言界面，开发者可以快速定义智能体的关键要素——目标、任务指令、工具、用于任务分配的次级智能体以及示例——从而轻松构建预期的系统行为。此外，该平台还配备了一套开发工具，支持测试、评估、测量智能体性能、调试及提升所开发智能体的整体质量。这使得开发者能够专注于智能体的构建与优化，而基础设施、部署维护等复杂工作均由平台自主管理。

在图15中，我们提供了一个基于Vertex AI平台构建的智能体示例架构，该架构运用了Vertex Agent Builder、Vertex Extensions、Vertex Function Calling以及Vertex Example Store等诸多功能。此架构包含了适用于生产级应用程序的各种必要组件。

图15. 基于Vertex AI平台构建的端到端代理架构示例

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

7.总结

在本白皮书中，我们探讨了生成式AI智能体的基础构建模块、组成要素，以及以认知架构形式实现它们的有效方法。本白皮书的核心观点包括：

1. 智能体通过调用工具获取实时信息、提出现实世界行动建议以及自主规划执行复杂任务，从而扩展了语言模型的能力。智能体可调用一个或多个语言模型，决定状态转移的时机与方式，并借助外部工具完成模型单独难以企及的复杂任务组合。

2. 智能体运行的核心是编排层——这一认知架构负责构建推理与规划流程，指导决策并规范行动。ReAct（推理-行动联动）、思维链、思维之树等推理技术为编排层提供了处理信息、执行内部推理及生成明智决策/响应的框架范式。

3. 工具（如扩展模块、函数与数据存储）是智能体连接外部世界的密钥，使其能与外部系统交互并获取训练数据之外的知识。扩展模块构建智能体与外部API的桥梁，支持API调用及实时数据获取；函数通过分工机制为开发者提供更精细的控制，允许智能体生成可由客户端执行的函数参数；数据存储则赋予智能体访问结构化/非结构化数据的能力，支撑数据驱动型应用。

智能体的未来充满令人振奋的进步，我们仅仅触及了其可能性的表面。随着工具日益精进与推理能力增强，智能体将能够解决日益复杂的问题。此外，"智能体链式协作"的战略方法将持续升温——通过整合各领域专精的智能体，我们将实现"专家智能体混合"模式，从而在不同行业和问题领域取得卓越成果。

必须认识到，构建复杂的智能体架构需要采用迭代方法。实验与优化是寻找满足特定业务场景和组织需求解决方案的关键。由于支撑这些架构的基础模型具有生成性质，每个智能体都不尽相同。然而，通过充分利用每个基础组件的优势，我们就能打造出具有影响力的应用程序，从而扩展语言模型的能力，并创造现实世界中的价值。