目录
- 一、引言
-
- 1-1、什么是Agent?
- 1-2、Agent的核心组件
-
- [1-2-1、模型(The Model)](#1-2-1、模型(The Model))
- [1-2-2、工具(The Tools)](#1-2-2、工具(The Tools))
- [1-2-3、编排层(The Orchestration Layer)](#1-2-3、编排层(The Orchestration Layer))
- [1-3、Agent vs. 模型](#1-3、Agent vs. 模型)
- 二、认知架构:Agent如何运作
-
- 2-1、Agent推理框架
-
- 2-1-1、ReAct框架
- [2-1-2、思维链(Chain-of-Thought, CoT)](#2-1-2、思维链(Chain-of-Thought, CoT))
- [2-1-3、思维树(Tree-of-Thoughts, ToT)](#2-1-3、思维树(Tree-of-Thoughts, ToT))
- 2-2、ReAct工作流程示例
- 三、工具:通往外部世界的钥匙
-
- 3-1、扩展(Extensions)
- 3-2、函数(Functions)
-
- [3-2-1、函数 vs 扩展](#3-2-1、函数 vs 扩展)
- 3-2-2、为什么使用函数?
- 3-2-3、函数用例示例
- 3-2-4、函数调用生命周期
- 3-2-5、函数示例代码
- [3-3、数据存储(Data Stores)](#3-3、数据存储(Data Stores))
-
- 3-3-1、问题场景
- 3-3-2、数据存储解决方案
- 3-3-3、实现和应用
- 3-3-4、RAG应用程序的工作流程
- [3-3-5、RAG + ReAct示例](#3-3-5、RAG + ReAct示例)
- 3-4、工具总结
- 四、通过针对性学习增强模型性能
-
- 4-1、针对性学习方法
-
- [4-1-1、上下文学习(In-context Learning)](#4-1-1、上下文学习(In-context Learning))
- [4-1-2、基于检索的上下文学习(Retrieval-based In-context Learning)](#4-1-2、基于检索的上下文学习(Retrieval-based In-context Learning))
- [4-1-3、基于微调的学习(Fine-tuning Based Learning)](#4-1-3、基于微调的学习(Fine-tuning Based Learning))
- 4-2、组合方法的优势
- 五、使用LangChain快速开始Agent开发
- [六、使用Vertex AI Agent的生产应用](#六、使用Vertex AI Agent的生产应用)
-
- [6-1、Vertex AI平台优势](#6-1、Vertex AI平台优势)
- 6-2、端到端架构示例
- 七、总结
- 总结
一、引言
人类在处理复杂的模式识别任务时表现出色。然而,他们经常依赖工具------比如书籍、Google搜索或计算器------来补充现有知识,然后才能得出结论。就像人类一样,生成式AI模型可以被训练使用工具来访问实时信息或建议现实世界的行动。例如,模型可以利用数据库检索工具访问特定信息(如客户的购买历史),从而生成个性化的购物推荐。或者,基于用户的查询,模型可以进行各种API调用,代表您向同事发送电子邮件响应或完成金融交易。
要做到这一点,模型不仅需要访问一组外部工具,还需要能够以自主方式规划和执行任何任务。这种推理、逻辑和对外部信息访问的组合,都连接到生成式AI模型,引出了**Agent(智能体)**的概念------一个超越独立生成式AI模型能力的程序。本白皮书将深入探讨所有这些相关方面的更多细节。
核心定义
推理、逻辑和对外部信息访问的组合,都连接到生成式AI模型,引出了Agent的概念。
LLM在进行某些复杂任务时,不仅需要访问外部工具,还需要能够自主规划、执行,这种具备了推理、逻辑、访问外部信息的LLM,就是Agent,换句话说,Agent是LLM的Plus版本。
1-1、什么是Agent?
从最基本的形式来看,生成式AI Agent可以定义为一个应用程序,它通过观察世界并使用其可用的工具对其采取行动来尝试实现目标。
Agent具有以下特征:
- 自主性: Agent是自主的,可以独立于人工干预行动,特别是在为其提供适当的目标或它们应该实现的目标时
- 主动性: Agent在实现目标的方法上可以是主动的。即使在没有人类明确指令集的情况下,Agent也可以推理下一步应该做什么来实现其最终目标
1-2、Agent的核心组件
为了理解Agent的内部工作原理,让我们首先介绍驱动Agent行为、行动和决策制定的基础组件。这些组件的组合可以被描述为认知架构(cognitive architecture),通过混合和匹配这些组件可以实现许多这样的架构。
专注于核心功能,Agent的认知架构中有三个基本组件,如下图所示:

1-2-1、模型(The Model)
在Agent的范围内,模型指的是将被用作Agent过程的集中决策者的语言模型(LM)。Agent使用的模型可以是:
- 一个或多个任何大小(小型/大型)的LM
- 能够遵循基于指令的推理和逻辑框架,如ReAct、思维链(Chain-of-Thought)或思维树(Tree-of-Thoughts)
- 可以是通用的、多模态的,或根据特定Agent架构的需求进行微调的
为了获得最佳的生产结果,您应该利用最适合您期望的最终应用程序的模型,理想情况下,该模型已经在与您计划在认知架构中使用的工具相关的数据签名上进行了训练。
重要说明: 模型通常不会使用Agent的特定配置设置(即工具选择、编排/推理设置)进行训练。但是,可以通过向模型提供展示Agent能力的示例(包括Agent在各种上下文中使用特定工具或推理步骤的实例)来进一步优化模型以适应Agent的任务。
1-2-2、工具(The Tools)
基础模型尽管在文本和图像生成方面令人印象深刻,但仍受到无法与外部世界交互的限制。工具弥合了这一差距,使Agent能够与外部数据和服务交互,同时解锁比单独使用底层模型更广泛的操作范围。
工具可以采取多种形式并具有不同的复杂程度,但通常与常见的Web API方法(如GET、POST、PATCH和DELETE)保持一致。例如:
- 工具可以更新数据库中的客户信息
- 获取天气数据以影响Agent向用户提供的旅行推荐
使用工具,Agent可以访问和处理现实世界的信息。这使它们能够支持更专业的系统,如检索增强生成(RAG),这大大扩展了Agent的能力,超越了基础模型单独可以实现的范围。
工具是Agent内部能力和外部世界之间的桥梁,解锁了更广泛的可能性。
1-2-3、编排层(The Orchestration Layer)
编排层描述了一个循环过程,它管理Agent如何:
- 接收信息
- 执行一些内部推理
- 使用该推理来告知其下一个操作或决策
一般来说,这个循环将持续到Agent达到其目标或停止点。编排层的复杂性可能会根据Agent及其执行的任务而有很大差异:
- 一些循环可以是带有决策规则的简单计算
- 其他循环可能包含链式逻辑、涉及额外的机器学习算法或实现其他概率推理技术
1-3、Agent vs. 模型
为了更清楚地理解Agent和模型之间的区别,请考虑以下对比:
| 特性 | 模型(Models) | Agent(Agents) |
|---|---|---|
| 知识范围 | 知识仅限于训练数据中可用的内容 | 通过工具与外部系统的连接扩展知识 |
| 推理模式 | 基于用户查询的单次推理/预测。除非为模型明确实现,否则没有会话历史或持续上下文的管理 | 管理会话历史(即聊天历史),允许基于用户查询和编排层做出的决策进行多轮推理/预测。在这种情况下,"轮次"被定义为交互系统和Agent之间的交互(即1个传入事件/查询和1个Agent响应) |
| 工具使用 | 没有原生工具实现 | 工具在Agent架构中原生实现 |
| 逻辑层 | 没有原生逻辑层实现。用户可以将提示构建为简单问题或使用推理框架(CoT、ReAct等)来构建复杂提示以指导模型预测 | 使用CoT、ReAct或其他预构建Agent框架(如LangChain)等推理框架的原生认知架构 |
二、认知架构:Agent如何运作
想象一下繁忙厨房中的厨师。他们的目标是为餐厅顾客创造美味的菜肴,这涉及一些规划、执行和调整的循环:
- 他们收集信息,比如顾客的订单和储藏室和冰箱里有什么食材
- 他们根据刚刚收集的信息对可以创造什么菜肴和风味进行一些内部推理
- 他们采取行动来创造菜肴:切菜、混合香料、煎肉
在过程的每个阶段,厨师都会根据需要进行调整,随着食材的消耗或收到顾客反馈而完善他们的计划,并使用之前的结果集来确定下一个行动计划。这个信息摄取、规划、执行和调整的循环描述了厨师用来达到目标的独特认知架构。
就像厨师一样,Agent可以使用认知架构通过迭代处理信息、做出明智决策并根据先前输出优化下一步行动来达到其最终目标。
2-1、Agent推理框架
在Agent认知架构的核心是编排层,负责维护记忆、状态、推理和规划。它使用快速发展的提示工程领域和相关框架来指导推理和规划,使Agent能够更有效地与其环境交互并完成任务。
虽然不是详尽的列表,但这里有一些在发布时最流行的框架和推理技术:
2-1-1、ReAct框架
ReAct 是一个提示工程框架,为语言模型提供思考过程策略,以便对用户查询进行推理并采取行动,无论是否有上下文示例。ReAct提示已被证明优于几个SOTA基线,并提高了LLM的人类互操作性和可信度。
2-1-2、思维链(Chain-of-Thought, CoT)
**思维链(CoT)**是一个提示工程框架,通过中间步骤实现推理能力。CoT有各种子技术,包括:
- 自洽性(self-consistency)
- 主动提示(active-prompt)
- 多模态CoT
每种技术根据具体应用都有优缺点。
2-1-3、思维树(Tree-of-Thoughts, ToT)
**思维树(ToT)**是一个提示工程框架,非常适合探索或战略前瞻性任务。它概括了思维链提示,允许模型探索各种思维链,这些思维链作为使用语言模型进行一般问题解决的中间步骤。
2-2、ReAct工作流程示例
Agent可以利用上述推理技术之一或许多其他技术来为给定的用户请求选择下一个最佳操作。例如,让我们考虑一个被编程为使用ReAct框架的Agent,以便为用户查询选择正确的操作和工具。事件序列可能如下:
- 用户向Agent发送查询
- Agent开始ReAct序列
- Agent向模型提供提示 ,要求它生成下一个ReAct步骤及其对应的输出:
- Question(问题): 来自用户查询的输入问题,与提示一起提供
- Thought(思考): 模型关于下一步应该做什么的思考
- Action(行动) : 模型关于下一步采取什么行动的决策
- 这是可以进行工具选择的地方
- 例如,行动可以是[Flights, Search, Code, None]之一,前3个代表模型可以选择的已知工具,最后一个代表"无工具选择"
- Action Input(行动输入): 模型关于向工具提供什么输入的决策(如果有)
- Observation(观察) : 行动/行动输入序列的结果
- 这个思考/行动/行动输入/观察可以根据需要重复N次
- Final Answer(最终答案): 模型提供给原始用户查询的最终答案
- ReAct循环结束,向用户提供最终答案
如下图所示:

示例场景:
用户查询: "我想预订从奥斯汀到苏黎世的航班。"
Agent推理过程:
├─ Question: 我想预订从奥斯汀到苏黎世的航班
├─ Thought: 我应该搜索航班...
├─ Action: Flights工具
├─ Action Input: 从奥斯汀到苏黎世的航班
├─ Observation: Flights工具返回多个选项
├─ Thought: 我应该向用户展示这些...
└─ Final Answer: 这是一些航班...
如图所示,模型、工具和Agent配置共同工作,根据用户的原始查询向用户提供一个有根据的、简洁的响应。虽然模型可以根据其先验知识猜测答案(产生幻觉),但它转而使用工具(Flights)来搜索实时外部信息。这些额外的信息被提供给模型,使其能够根据真实事实数据做出更明智的决策,并将这些信息总结回用户。
总结:Agent响应的质量可以直接与模型推理和对这些各种任务采取行动的能力相关联,包括选择正确工具的能力,以及该工具定义的好坏。就像厨师用新鲜食材制作菜肴并关注顾客反馈一样,Agent依赖于良好的推理和可靠的信息来提供最佳结果。
三、工具:通往外部世界的钥匙
虽然语言模型在处理信息方面表现出色,但它们缺乏直接感知和影响现实世界的能力。这限制了它们在需要与外部系统或数据交互的情况下的实用性。这意味着,从某种意义上说,语言模型的好坏取决于它从训练数据中学到的东西。
但无论我们向模型投入多少数据,它们仍然缺乏与外部世界交互的基本能力。那么,我们如何赋予模型与外部系统实时、上下文感知的交互能力呢?
函数(Functions)、扩展(Extensions)、数据存储(Data Stores)和插件(Plugins)都是向模型提供这一关键能力的方式。
虽然它们有很多名称, 但是他们都统称之为工具。这种与外部系统和数据的链接使我们的Agent能够执行更广泛的任务,并且以更高的准确性和可靠性来完成。例如,工具可以使Agent能够:
- 调整智能家居设置
- 更新日历
- 从数据库获取用户信息
- 根据一组特定指令发送电子邮件
截至本出版日期,Google模型能够交互的主要工具类型有三种:扩展(Extensions)、函数(Functions)和数据存储(Data Stores)。
通过为Agent配备工具,我们释放了它们不仅理解世界而且对其采取行动的巨大潜力,为无数新应用和可能性打开了大门。
3-1、扩展(Extensions)
理解扩展的最简单方法是将它们视为以标准化方式在API和Agent之间架起桥梁 ,允许Agent无缝执行API,而不管其底层实现如何。

3-1-1、问题场景
假设您已经构建了一个Agent,目标是帮助用户预订航班。您知道您想使用Google Flights API来检索航班信息,但您不确定如何让您的Agent调用此API端点。
一种方法可能是实现自定义代码,该代码将接收传入的用户查询,解析查询以获取相关信息,然后进行API调用。例如,在航班预订用例中,用户可能会说"我想预订从奥斯汀到苏黎世的航班"。在这种情况下,我们的自定义代码解决方案需要在尝试进行API调用之前从用户查询中提取"奥斯汀"和"苏黎世"作为相关实体。
但是,如果用户说"我想预订去苏黎世的航班"而从未提供出发城市怎么办?API调用将在没有所需数据的情况下失败,需要实现更多代码来捕获这样的边缘和角落情况。这种方法不可扩展,并且可能在任何超出已实现自定义代码的场景中轻易失败。 (以上是传统方式,写代码解析参数失败的情况)
3-1-2、扩展解决方案

更具弹性的方法是使用扩展。扩展通过以下方式在Agent和API之间架起桥梁:
- 使用示例教Agent如何使用API端点
- 教Agent成功调用API端点需要哪些参数或参数
扩展可以独立于Agent制作,但应作为Agent配置的一部分提供。Agent在运行时使用模型和示例来决定哪个扩展(如果有)适合解决用户的查询。
这突出了扩展的一个关键优势------它们的内置示例类型,允许Agent动态选择最适合任务的扩展。
示例:
[1] "get_flights方法可用于获取最新的..."
[2] "当用户想要搜索航班时,调用get_flights..."
[3] "get_flights的输入参数是arg1、arg2、..."

可以将这种方式想象成软件开发人员在解决用户问题时决定使用哪些API端点的方式:
- 如果用户想预订航班,开发人员可能使用Google Flights API
- 如果用户想知道相对于他们位置最近的咖啡店在哪里,开发人员可能使用Google Maps API
以同样的方式,Agent/模型堆栈使用一组已知的扩展来决定哪一个最适合用户的查询。
3-1-3、示例扩展
为了简化扩展的使用,Google提供了一些开箱即用的扩展,可以快速导入到您的项目中并以最少的配置使用。例如,代码解释器扩展允许您从自然语言描述生成和运行Python代码。
python
import vertexai
from vertexai.preview.extensions import Extension
PROJECT_ID = "YOUR_PROJECT_ID"
REGION = "us-central1"
vertexai.init(project=PROJECT_ID, location=REGION)
# 导入代码解释器扩展
extension_code_interpreter = Extension.from_hub("code_interpreter")
CODE_QUERY = """编写一个Python方法以O(n)时间反转二叉树。"""
response = extension_code_interpreter.execute(
operation_id="generate_and_execute",
operation_params={"query": CODE_QUERY}
)
print("生成的代码:")
print(response['generated_code'])
输出示例:
python
class TreeNode:
def __init__(self, val=0, left=None, right=None):
self.val = val
self.left = left
self.right = right
def invert_binary_tree(root):
"""
反转二叉树。
Args:
root: 二叉树的根。
Returns:
反转后二叉树的根。
"""
if not root:
return None
# 递归交换左右子节点
root.left, root.right = invert_binary_tree(root.right), invert_binary_tree(root.left)
return root
总结:扩展提供了一种方式,让Agent以无数种方式感知、交互和影响外部世界。这些扩展的选择和调用由示例指导,所有这些都定义为扩展配置的一部分。
3-2、函数(Functions)
在软件工程领域,函数被定义为完成特定任务并可根据需要重用的独立代码模块。当软件开发人员编写程序时,他们通常会创建许多函数来执行各种任务。他们还会定义何时调用function_a与function_b的逻辑,以及预期的输入和输出。
函数在Agent世界中的工作方式非常相似,但我们可以用模型替换软件开发人员。模型可以接受一组已知函数,并根据其规范决定何时使用每个函数以及函数需要什么参数。
3-2-1、函数 vs 扩展

函数在几个方面与扩展不同,最值得注意的是:
- 模型输出函数及其参数,但不进行实时API调用
- 函数在客户端执行,而扩展在Agent端执行

使用我们的Google Flights示例,函数的简单设置可能如下所示:
Agent ←→ Function ? → Google Flights API
3-2-2、为什么使用函数?
开发人员可能选择使用函数而不是扩展的原因有很多,但一些常见用例包括:
-
API调用需要在应用程序堆栈的另一层进行,在直接Agent架构流之外(例如中间件系统、前端框架等)
-
安全或身份验证限制阻止Agent直接调用API(例如API未暴露于互联网,或Agent基础设施无法访问)
-
时序或操作顺序约束阻止Agent实时进行API调用(即批处理操作、人在回路审查等)
-
需要对API响应应用额外的数据转换逻辑,而Agent无法执行。例如,考虑一个不提供过滤机制来限制返回结果数量的API端点。在客户端使用函数为开发人员提供了进行这些转换的额外机会
-
开发人员希望在不部署API端点的额外基础设施的情况下迭代Agent开发(即函数调用可以充当API的"存根")
虽然两种方法之间的内部架构差异很细微,但通过劳动分工提供的额外控制和解耦对外部基础设施的依赖使函数调用成为开发人员的一个有吸引力的选择。
3-2-3、函数用例示例
模型可以用来调用函数,以便为最终用户处理复杂的客户端执行流程,其中Agent开发人员可能不希望语言模型管理API执行(就像扩展的情况一样)。
场景:让我们考虑以下示例,其中正在训练Agent作为旅行礼宾与想要预订度假旅行的用户互动。目标是让Agent生成一个城市列表,我们可以在中间件应用程序中使用它来下载图像、数据等,以便用户进行旅行规划。
用户可能会说这样的话:
"我想和家人一起滑雪旅行,但我不确定去哪里。"
在模型的典型提示中,输出可能如下所示:
"当然,这是您可以考虑的家庭滑雪旅行城市列表:
- 科罗拉多州Crested Butte,美国
- 加拿大不列颠哥伦比亚省Whistler
- 瑞士Zermatt"
虽然上面的输出包含我们需要的数据(城市名称),但格式对于解析并不理想。通过函数调用,我们可以教模型以结构化样式(如JSON)格式化此输出,这对于另一个系统解析更方便。
给定来自用户的相同输入提示,来自函数的示例JSON输出可能如下所示:
json
{
"function_call": {
"name": "display_cities",
"args": {
"cities": ["Crested Butte", "Whistler", "Zermatt"],
"preferences": "skiing"
}
}
}
Agent的整体流程如下所示:

3-2-4、函数调用生命周期
这个JSON负载由模型生成,然后发送到我们的客户端服务器,以便我们想要用它做什么。在这个特定情况下,我们将调用Google Places API,使用模型提供的城市查找图像,然后将它们作为格式化的富内容提供回我们的用户。
完整流程:
用户 → 客户端UI → Agent → 模型
↑ ↓
| 生成JSON输出
| ↓
| ← Google Places API ← 客户端UI
└─────── Agent响应 ─────────┘
详细步骤:
- 用户: "...滑雪旅行..."
- 用户查询 → 客户端UI
- Agent向模型发送提示+示例
- 模型使用提示+示例生成JSON输出
- 返回JSON: Function: "display_cities"
- 客户端拦截JSON并调用Google Places API
- Google Places API以预期格式返回
- 返回结果
- Agent响应 → 用户: "...这是一些带图像的滑雪胜地..."
结果是模型被用来"填空",填充客户端UI进行Google Places API调用所需的参数。客户端UI使用模型在返回的函数中提供的参数管理实际的API调用。
3-2-5、函数示例代码
为了实现上述滑雪度假场景的输出,让我们使用gemini-1.5-flash-001模型构建每个组件。
第一步:定义函数
python
def display_cities(cities: list[str], preferences: Optional[str] = None):
"""根据用户的搜索查询和偏好提供城市列表。
Args:
preferences (str): 用户对搜索的偏好,如滑雪、海滩、餐厅、烧烤等。
cities (list[str]): 推荐给用户的城市列表。
Returns:
list[str]: 推荐给用户的城市列表。
"""
return cities
第二步:构建工具并调用模型
python
from vertexai.generative_models import GenerativeModel, Tool, FunctionDeclaration
model = GenerativeModel("gemini-1.5-flash-001")
# 从函数创建函数声明
display_cities_function = FunctionDeclaration.from_func(display_cities)
# 创建工具
tool = Tool(function_declarations=[display_cities_function])
# 用户消息
message = "我想和家人一起滑雪旅行,但我不确定去哪里。"
# 生成内容
res = model.generate_content(message, tools=[tool])
print(f"函数名称: {res.candidates[0].content.parts[0].function_call.name}")
print(f"函数参数: {res.candidates[0].content.parts[0].function_call.args}")
# 输出:
# > 函数名称: display_cities
# > 函数参数: {'preferences': 'skiing', 'cities': ['Aspen', 'Vail', 'Park City']}
总结 :函数提供了一个直接的框架,使应用程序开发人员能够对数据流和系统执行进行细粒度控制 ,同时有效地利用Agent/模型进行关键输入生成。开发人员可以选择性地选择是否通过返回外部数据来保持Agent"在循环中",或根据特定应用程序架构要求省略它。
3-3、数据存储(Data Stores)
将语言模型想象成一个庞大的图书馆,包含其训练数据。但与不断获取新卷的图书馆不同,这个图书馆保持静态,只保存最初训练的知识。这带来了挑战,因为现实世界的知识在不断发展。
数据存储通过提供对更动态和最新信息的访问来解决这一限制,确保模型的响应保持基于事实和相关性。

3-3-1、问题场景
考虑一个常见场景,开发人员可能需要向模型提供少量额外数据,可能是电子表格或PDF的形式:
Agent → ? → [私有文档、网站、结构化数据]
3-3-2、数据存储解决方案
数据存储允许开发人员以其原始格式向Agent提供额外数据,无需耗时的数据转换、模型重新训练或微调。数据存储将传入文档转换为一组向量数据库嵌入,Agent可以使用这些嵌入来提取所需的信息,以补充其下一步操作或对用户的响应。
Agent → Data Store → [私有文档、网站、结构化数据]

3-3-3、实现和应用
在生成式AI Agent的上下文中,数据存储通常实现为向量数据库,开发人员希望Agent在运行时可以访问该数据库。虽然我们不会在这里深入介绍向量数据库,但要理解的关键点是它们以向量嵌入的形式存储数据,向量嵌入是所提供数据的一种高维向量或数学表示。

数据存储使用与语言模型的最多产示例之一是实现基于检索增强生成(RAG)的应用程序。这些应用程序寻求通过为模型提供各种格式的数据访问来扩展模型知识的广度和深度,超越基础训练数据,例如:
- 网站内容
- 结构化数据:PDF、Word文档、CSV、电子表格等格式
- 非结构化数据:HTML、PDF、TXT等格式
Agent与数据存储的关系:
Agent
├─ Reasoning Loop
├─ Model
└─ Tools
├─ unstructured_data_store → 入职PDF
├─ website_data_store → cloud.google.com/blog
└─ structured_data_store → 财务电子表格
3-3-4、RAG应用程序的工作流程
每个用户请求和Agent响应循环的底层过程通常如下建模:
- 用户查询被发送到嵌入模型以生成查询的嵌入
- 查询嵌入然后使用匹配算法(如SCaNN)与向量数据库的内容进行匹配
- 从向量数据库检索匹配的内容,以文本格式发送回Agent
- Agent接收用户查询和检索到的内容,然后制定响应或操作
- 向用户发送最终响应
完整流程图:

用户请求------》生成用户问题的Embedding------》与向量数据库进行匹配 ------》检索相关内容,将相似度比较高的内容以文本格式返回------》返回检索信息到Agent,Agent决定下一步如何进行,决策------》返回最终结果。
3-3-5、RAG + ReAct示例
场景:使用ReAct推理/规划的基于RAG的应用程序示例
Agent
├─ Question: "我们的育儿假政策是什么?"
├─ Thought: 我应该搜索最佳数据存储匹配...
├─ Action: 向量搜索
├─ Action Input: Google的育儿假政策是什么?
├─ Observation: pdf_dstore包含最佳库结果...
│ Results: [snippet_1, snippet_2, snippet_3...]
├─ Thought: 总结并呈现给用户...
└─ Final Answer: Google的休假政策...
Tools:
├─ pdf_dstore
├─ website_dstore
└─ sheets_dstore
结果:这是一个允许Agent通过向量搜索将用户查询与已知数据存储匹配,检索原始内容,并将其提供给编排层和模型以进行进一步处理的应用程序。下一步操作可能是向用户提供最终答案,或执行额外的向量搜索以进一步优化结果。

3-4、工具总结
总而言之,扩展、函数调用和数据存储构成了Agent在运行时可用的几种不同工具类型。每种都有其自己的目的,它们可以根据Agent开发人员的决定一起使用或独立使用。
| 特性 | 扩展(Extensions) | 函数调用(Function Calling) | 数据存储(Data Stores) |
|---|---|---|---|
| 执行位置 | Agent端执行 | 客户端执行 | Agent端执行 |
| 主要用例 | • 开发人员希望Agent控制与API端点的交互 • 利用原生预构建扩展时很有用(如Vertex Search、Code Interpreter等) • 多跳规划和API调用(即下一个Agent操作取决于先前操作/API调用的输出) | • 安全或身份验证限制阻止Agent直接调用API • 时序约束或操作顺序约束阻止Agent实时进行API调用(即批处理操作、人在回路审查等) • API未暴露于互联网,或Google系统无法访问 | 开发人员希望使用以下任何数据类型实现检索增强生成(RAG): • 来自预索引域和URL的网站内容 • PDF、Word文档、CSV、电子表格等格式的结构化数据 • 关系/非关系数据库 • HTML、PDF、TXT等格式的非结构化数据 |
四、通过针对性学习增强模型性能
有效使用模型的一个关键方面是它们在生成输出时选择正确工具的能力,特别是在生产中大规模使用工具时。虽然一般训练帮助模型发展这种技能,但现实世界场景通常需要超出训练数据的知识。
将这想象成基本烹饪技能和掌握特定美食之间的区别。两者都需要基础烹饪知识,但后者需要针对性学习以获得更细腻的结果。
4-1、针对性学习方法
为了帮助模型获得这种类型的特定知识,存在几种方法:
4-1-1、上下文学习(In-context Learning)
这种方法在推理时为通用模型提供提示、工具和少量示例,使其能够"即时"学习如何以及何时将这些工具用于特定任务。ReAct框架是这种方法在自然语言中的一个例子。
类比:想象一位厨师从顾客那里收到了特定的食谱(提示)、一些关键食材(相关工具)和一些示例菜肴(少量示例)。基于这些有限的信息和厨师的一般烹饪知识,他们需要弄清楚如何"即时"准备最符合食谱和顾客偏好的菜肴。
4-1-2、基于检索的上下文学习(Retrieval-based In-context Learning)
这种技术通过从外部存储器检索最相关的信息、工具和相关示例来动态填充模型提示。
示例:Vertex AI扩展中的"示例存储"或前面提到的基于数据存储的RAG架构。
类比:现在让我们想象我们的厨师在一个有储备充足的储藏室(外部数据存储)的厨房里,里面装满了各种食材和食谱(示例和工具)。厨师现在能够从储藏室动态选择食材和食谱,更好地符合顾客的食谱和偏好。这使厨师能够利用现有和新知识创造更明智和精致的菜肴。
4-1-3、基于微调的学习(Fine-tuning Based Learning)
这种方法涉及在推理之前使用更大的特定示例数据集训练模型。这有助于模型在接收任何用户查询之前理解何时以及如何应用某些工具。
类比:最后,让我们想象我们把厨师送回学校学习新的美食或一组美食(在更大的特定示例数据集上进行预训练)。这使厨师能够以更深入的理解来处理未来未见过的顾客食谱。如果我们希望厨师在特定美食(知识领域)中表现出色,这种方法是完美的。
4-2、组合方法的优势
这些方法中的每一种都在速度、成本和延迟方面提供独特的优势和劣势。然而,通过在Agent框架中结合这些技术,我们可以利用各种优势并最大限度地减少它们的劣势,从而实现更强大和适应性强的解决方案。
五、使用LangChain快速开始Agent开发
为了提供一个实际可执行的Agent示例,我们将使用LangChain和LangGraph库构建一个快速原型。这些流行的开源库允许用户通过"链接"逻辑、推理和工具调用序列来构建自定义Agent,以回答用户的查询。
5-1、示例代码
我们将使用gemini-1.5-flash-001模型和一些简单的工具来回答来自用户的多阶段查询。
使用的工具:
- SerpAPI(用于Google搜索)
- Google Places API
python
from langgraph.prebuilt import create_react_agent
from langchain_core.tools import tool
from langchain_community.utilities import SerpAPIWrapper
from langchain_community.tools import GooglePlacesTool
import os
# 设置API密钥
os.environ["SERPAPI_API_KEY"] = "XXXXX"
os.environ["GPLACES_API_KEY"] = "XXXXX"
@tool
def search(query: str):
"""使用SerpAPI运行Google搜索。"""
search = SerpAPIWrapper()
return search.run(query)
@tool
def places(query: str):
"""使用Google Places API运行Google Places查询。"""
places = GooglePlacesTool()
return places.run(query)
# 初始化模型和工具
model = ChatVertexAI(model="gemini-1.5-flash-001")
tools = [search, places]
# 用户查询
query = "德克萨斯长角牛队上周在足球比赛中对阵谁?另一支球队的体育场地址是什么?"
# 创建Agent
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()
5-2、输出示例
=============================== Human Message ================================
德克萨斯长角牛队上周在足球比赛中对阵谁?另一支球队的体育场地址是什么?
================================= AI Message =================================
Tool Calls: search
Args:
query: Texas Longhorns football schedule
================================ Tool Message ================================
Name: search
{...Results: "NCAA Division I Football, Georgia, Date..."}
================================= AI Message =================================
德克萨斯长角牛队上周对阵乔治亚斗牛犬队。
Tool Calls: places
Args:
query: Georgia Bulldogs stadium
================================ Tool Message ================================
Name: places
{...Sanford Stadium Address: 100 Sanford...}
================================= AI Message =================================
乔治亚斗牛犬队体育场的地址是100 Sanford Dr, Athens, GA 30602, USA。
虽然这是一个相当简单的Agent示例,但它展示了模型、编排和工具一起工作以实现特定目标的基础组件。
六、使用Vertex AI Agent的生产应用
虽然本白皮书探讨了Agent的核心组件,但构建生产级应用程序需要将它们与其他工具集成 ,如用户界面、评估框架和持续改进机制。

6-1、Vertex AI平台优势
Google的Vertex AI平台通过提供一个完全托管的环境来简化这个过程,该环境包含前面介绍的所有基本元素。使用自然语言界面,开发人员可以快速定义其Agent的关键元素:
- 目标
- 任务指令
- 工具
- 用于任务委派的子Agent
- 示例
此外,该平台还配备了一套开发工具,允许:
- 测试
- 评估
- 衡量Agent性能
- 调试
- 提高开发的Agent的整体质量
这使开发人员能够专注于构建和完善他们的Agent,而基础设施、部署和维护的复杂性由平台本身管理。
6-2、端到端架构示例
下图提供了使用各种功能(如Vertex Agent Builder、Vertex Extensions、Vertex Function Calling和Vertex Example Store等)在Vertex AI平台上构建的Agent的示例架构。该架构包括生产就绪应用程序所需的许多各种组件。
架构组件:
① 用户 → ② 自定义UI → ③ Agent
├─ Prompt: "这里有一些函数..."
├─ Tool Definitions
│ └─ Tool1, Tool2, Tool3...
└─ Prompt: "用户滑雪旅行Agent: get_cities()"
↓ ⑤ 函数执行循环
⑥ Google Places API ← Function
④ Model ↔ Extensions → Vector Search API
关键特性:
- 用户通过自定义UI与Agent交互
- Agent配置包含提示、工具定义和示例
- 模型处理推理和决策
- 函数在客户端执行
- 扩展在Agent端执行
- 与外部API(如Google Places、Vector Search)集成
您可以从我们的官方文档中尝试此预构建Agent架构的示例。
七、总结
7-1、核心要点
在本白皮书中,我们讨论了生成式AI Agent的基础构建块、它们的组成以及以认知架构形式实现它们的有效方法。一些关键要点包括:
7-1-1、Agent扩展模型能力
Agent通过利用工具扩展语言模型的能力,以访问实时信息、建议现实世界的行动,并自主规划和执行复杂任务。Agent可以利用一个或多个语言模型来决定何时以及如何在状态之间转换,并使用外部工具完成模型单独难以或不可能完成的任意数量的复杂任务。
7-1-2、编排层是核心
在Agent操作的核心是编排层------一个构建推理、规划、决策制定并指导其行动的认知架构。各种推理技术,如ReAct、思维链和思维树,为编排层提供了一个框架来:
- 接收信息
- 执行内部推理
- 生成明智的决策或响应
7-1-3、工具是外部世界的钥匙
工具 (如扩展、函数和数据存储)充当Agent通往外部世界的钥匙,使它们能够与外部系统交互并访问超出训练数据的知识:
- 扩展:在Agent和外部API之间提供桥梁,实现API调用的执行和实时信息的检索
- 函数:通过劳动分工为开发人员提供更细腻的控制,允许Agent生成可以在客户端执行的函数参数
- 数据存储:为Agent提供对结构化或非结构化数据的访问,实现数据驱动的应用程序
7-2、未来展望
Agent的未来充满令人兴奋的进步,我们才刚刚开始触及可能性的表面:
7-2-1、工具和推理的演进
随着工具变得更加复杂,推理能力得到增强,Agent将被赋予解决日益复杂问题的能力。
7-2-2、Agent链接策略
此外,"Agent链接"的战略方法将继续获得动力。通过组合专门的Agent(每个在特定领域或任务中表现出色),我们可以创建一种"混合Agent专家"方法,能够在各个行业和问题领域提供卓越的结果。
7-2-3、迭代开发的重要性
重要的是要记住,构建复杂的Agent架构需要迭代方法。实验和改进是找到特定业务案例和组织需求解决方案的关键。由于支撑其架构的基础模型的生成性质,没有两个Agent是完全相同的。
然而,通过利用这些基础组件的优势,我们可以创建有影响力的应用程序,扩展语言模型的能力并推动现实世界的价值。
参考文献:
- Shafran, I., Cao, Y. et al., 2022, 'ReAct: Synergizing Reasoning and Acting in Language Models'
- Wei, J., Wang, X. et al., 2023, 'Chain-of-Thought Prompting Elicits Reasoning in Large Language Models'
- Wang, X. et al., 2022, 'Self-Consistency Improves Chain of Thought Reasoning in Language Models'
- Yao, S. et al., 2023, 'Tree of Thoughts: Deliberate Problem Solving with Large Language Models'
- Google Gemini Application
- LangChain Documentation
- Vertex AI Documentation
- 官方文档:https://drive.google.com/file/d/1oEjiRCTbd54aSdB_eEe3UShxLBWK9xkt/view?pli=1
- 参考其他大佬的文章:https://arthurchiao.art/blog/ai-agent-white-paper-zh/
总结
从前不回头,往后不将就。❀