Goolge AI Agent Whitepaper阅读笔记

type

status

date

slug

summary

一、What is an agent?

There are three essential components in an agent’s cognitive architecture.

这张图展示了一个通用智能体（Agent）的架构和组成部分，它描述了智能体如何接收用户查询、进行推理和规划，并最终生成响应的过程。

1. 用户查询 (user_query)：

这是智能体接收到的外部输入，通常是用户的指令、问题或请求。它可以是文本、语音、图像或其他形式的数据。例如，“帮我预订明天北京到上海的机票”、“播放周杰伦的歌”、“识别这张图片中的物体”等。

2. 智能体运行时 (Agent Runtime)：

这是智能体的核心执行环境，负责协调和管理各个组成部分，包括：

编排 (Orchestration)： 这是智能体的控制中心，负责协调和调度其他模块的工作。它接收用户查询，并根据查询内容选择合适的工具和模型进行处理。编排模块包含以下关键组成部分：

配置文件、目标和指令 (Profile, goals, & instructions)： 存储了智能体的基本信息、目标和执行指令。例如，智能体的角色设定、允许执行的操作、需要遵循的规则等。
内存 (Memory)： 存储了智能体在运行过程中产生的各种信息，包括短期记忆和长期记忆。

短期记忆 (short-term)： 存储当前任务相关的临时信息，例如用户查询的上下文、中间计算结果等。
长期记忆 (long-term)： 存储智能体学习到的知识和经验，例如事实、规则、模型参数等。

基于模型的推理/规划 (Model based Reasoning/Planning)： 这是智能体的核心智能部分，负责根据用户查询、配置文件、记忆和模型进行推理和规划。它使用各种推理和规划算法，例如搜索算法、规划算法、逻辑推理等，来确定需要执行的步骤和操作。

模型 (Model)： 这是智能体的知识库和能力来源，包括各种机器学习模型、深度学习模型、知识图谱等。例如，语言模型、图像识别模型、对话模型等。

工具 (Tools)： 这是智能体执行操作的接口，包括各种API、函数、程序等。例如，搜索API、地图API、数据库查询接口等。

3. 智能体响应 (agent_response)：

这是智能体最终生成的输出，是对用户查询的回答、执行结果或操作反馈。它可以是文本、语音、图像或其他形式的数据。例如，预订成功的确认信息、搜索结果列表、图像识别结果等。

工作流程：

整个工作流程如下：

用户向智能体发出查询 (user_query)。

智能体运行时接收到查询，并将其传递给编排模块。

编排模块根据查询内容、配置文件、记忆和模型，进行推理和规划，确定需要执行的步骤和操作。

编排模块调用相应的工具和模型来执行操作，并将结果存储在内存中。

编排模块根据执行结果生成响应 (agent_response)，并将其返回给用户。

举例说明：

假设用户查询是“今天北京天气怎么样？”

用户通过语音输入查询“今天北京天气怎么样？”

智能体运行时接收到语音查询，并将其转换为文本。

编排模块分析查询内容，确定需要调用天气查询API。

编排模块调用天气查询API，获取北京的天气信息。

编排模块将获取到的天气信息整理成自然语言文本，例如“今天北京晴，气温20-30摄氏度”。

编排模块将文本响应转换为语音，并播放给用户。

关键概念：

记忆 (Memory)： 记忆对于智能体的长期运行和学习至关重要。短期记忆用于存储当前任务的信息，而长期记忆用于存储学习到的知识和经验。

模型 (Model)： 模型是智能体的核心能力来源，不同的模型可以赋予智能体不同的能力，例如语言理解、图像识别、推理规划等。

工具 (Tools)： 工具是智能体与外部环境交互的接口，通过调用工具，智能体可以执行各种操作，例如搜索信息、控制设备、访问数据库等。

编排 (Orchestration)： 编排是智能体的控制中心，负责协调和管理各个组成部分，使它们协同工作，完成复杂的任务。

1. The Model

It’s important to note that the model is typically not trrained with the specific configuration setting(i.e. tool choices, orchestration/reasioning setup) of the agent. However, it’s possible to further refine the model for the agent’s task by providing it with examples that showcase the agent’s capabilities, including instances of the agent using specific tools or reasoning steps in various contexts.

2. The Tools

The most important thing to understand is that tools bridge the gap between the agent’s internal capabilities and the external world, unlocking a broader range of possibilities.

3. The orchestration layer

The orchestration layer describes a cyclical process that governs how the agent takes in information, performs some internal reasoning, and uses that reasoning to inform its next action or decision. In general, this loop will continue until an agent has reached its goal or a stopping point.

核心概念：编排层的循环过程（Orchestration Loop）。

1. 编排层描述了一个循环过程：

编排层是智能体的控制中心，它通过一个循环过程来驱动智能体的行为。这个循环过程包含以下步骤：

接收信息 (takes in information)： 接收来自用户或其他来源的输入，例如用户查询、环境感知数据等。

执行内部推理 (performs some internal reasoning)： 基于接收到的信息、存储在内存中的知识和模型，进行推理和规划。这包括理解用户意图、选择合适的工具、制定执行步骤等。

基于推理结果采取下一步行动或决策 (uses that reasoning to inform its next action or decision)： 根据推理结果，执行相应的操作，例如调用工具、更新内存、生成响应等。

2. 循环持续进行直到达到目标或停止点：

这个循环过程会持续进行，直到智能体达到预定的目标或遇到停止条件。

达到目标 (reached its goal)： 智能体成功完成了用户请求的任务，例如成功预订了机票、找到了所需的信息等。

停止点 (stopping point)： 智能体无法继续执行任务，例如遇到错误、超时、用户取消等。

3. 编排层的复杂性各不相同：

编排层的具体实现可以非常灵活，其复杂性取决于智能体和其执行的任务。

简单计算与决策规则 (simple calculations with decision rules)： 对于简单的任务，编排层可能只包含一些简单的计算和基于规则的决策。例如，根据温度传感器的数据判断是否需要开启空调。

链式逻辑 (chained logic)： 对于更复杂的任务，编排层可能需要执行一系列的逻辑步骤，每个步骤的输出作为下一个步骤的输入。例如，为了预订机票，智能体需要先搜索航班信息，然后选择合适的航班，最后进行预订。

额外的机器学习算法 (additional machine learning algorithms)： 编排层可以使用机器学习算法来辅助推理和决策。例如，使用强化学习算法来学习如何更好地选择工具和制定策略。

概率推理技术 (probabilistic reasoning techniques)： 编排层可以使用概率推理技术来处理不确定性信息。例如，使用贝叶斯网络来估计不同行动的成功概率。

二、Cognitive architectures: How agents operate

Agents can use cognitive architectures to reach their end goals by iteratively processing information, making informed decisions, and refining next actions based on previous outputs.

At the core of agent cognitive architectures lies the orchestration layer, responsible for maintaining memory, state, reasoning and planning. It uses the rapidly evolving field of prompt engineering and associated frameworks to guide reasoning and planning, enabling the agent to interact more effectively with its environment and complete tasks.

ReAct/COT/TOT

ReAct = Reasoning + Acting（推理 + 行动）

CoT: Chain-of-Thought

TOT: Tree-of-thoughts

特性	ReAct	CoT	ToT
核心思想	推理和行动交替进行	通过中间步骤进行推理	探索多个思维链条进行问题求解
提示方式	提供指令，引导模型进行推理和行动	提供包含推理步骤的示例	将问题分解为多个步骤，并生成多个想法
适用任务	需要推理和与环境交互的任务，例如问答、导航等	需要多步推理的任务	需要探索和回溯的任务，例如博弈、规划等
复杂度	中等	相对简单	较复杂
优点	提高推理能力、人机交互性和可信度，可以与环境交互	提高推理能力，易于实现	更灵活，更适合复杂问题
缺点	需要设计合适的行动空间和观察方式	需要精心设计的示例，长链条计算成本高	计算成本高，需要设计有效的搜索策略
与环境交互	强，可以调用工具与环境交互	较弱	较弱
记忆	可以使用记忆来存储中间结果和知识	通常不显式使用记忆	通常不显式使用记忆

要启用 Chain-of-Thought (CoT)、Tree-of-Thoughts (ToT) 和 ReAct 这三种提示工程框架，你需要使用特定的 prompt 结构和指令来引导语言模型。下面我将分别举例说明如何设计 prompt：

1. Chain-of-Thought (CoT) 链式思考：

CoT 的核心是提供包含中间推理步骤的示例，或者使用指令引导模型逐步思考。

Few-shot CoT (提供少量示例)：

问题：小明有 5 个苹果，他给了小红 2 个，然后又从树上摘了 3 个，现在他有多少个苹果？

解答：
首先，小明有 5 个苹果。
然后，他给了小红 2 个，所以剩下 5 - 2 = 3 个苹果。
之后，他又摘了 3 个，所以现在有 3 + 3 = 6 个苹果。
答案是 6。

---

问题：一个书架上有 12 本书。你拿走了 4 本，然后又放回了 2 本。现在书架上有多少本书？

解答：

在这个 prompt 中，我们提供了一个类似的例题和详细的解题步骤，这有助于模型学习如何一步一步地进行推理。

Zero-shot CoT (不提供示例，仅使用指令)：

问题：一个农民有 15 头牛。他卖掉了 7 头，然后又买回了 9 头。现在他有多少头牛？

让我们一步一步思考。

或者更明确的指令：

问题：一个农民有 15 头牛。他卖掉了 7 头，然后又买回了 9 头。现在他有多少头牛？

请按以下步骤解答：
1. 计算卖掉牛后剩余的数量。
2. 计算买回牛后最终的数量。
3. 给出最终答案。

这种方法简单易用，但效果可能不如 Few-shot CoT 好。

2. Tree-of-Thoughts (ToT) 树状思考：

ToT 需要引导模型生成多个想法，并进行评估。这需要更复杂的 prompt 结构。

基本 ToT Prompt：

问题：我需要把 5 个不同的包裹送到 5 个不同的地址。我应该如何规划送货路线，以最大限度地减少行驶距离？

请生成至少 3 个不同的送货路线方案，并对每个方案进行简要评估。然后选择最佳方案。

更详细的 ToT Prompt (包含更明确的指令)：

问题：我需要把 5 个不同的包裹送到 5 个不同的地址：A, B, C, D, E。我应该如何规划送货路线，以最大限度地减少行驶距离？

请按以下步骤进行：
1. 生成至少 3 个不同的送货路线方案（例如：A->B->C->D->E）。
2. 对每个方案进行简要评估，考虑行驶距离、交通状况等因素。
3. 从生成的方案中选择最佳方案，并给出选择理由。

输出格式：
方案 1：[路线] 评估：[评估内容]
方案 2：[路线] 评估：[评估内容]
方案 3：[路线] 评估：[评估内容]
最佳方案：[路线] 理由：[理由]

这个 prompt 提供了更清晰的指令和输出格式，有助于模型更好地执行 ToT 策略。

3. ReAct (Reasoning + Acting) 推理 + 行动：

ReAct 需要引导模型交替进行推理和行动，并观察环境的反馈。

基本 ReAct Prompt：

问题：金门大桥是什么时候建成的？

请使用搜索工具查找答案。

更详细的 ReAct Prompt (包含更明确的指令和输出格式)：

问题：金门大桥是什么时候建成的？

请按以下步骤进行：
1. 思考：描述你需要做什么来回答这个问题。
2. 行动：执行一个操作来获取信息（例如：调用搜索工具）。
3. 观察：记录你从操作中获得的信息。

重复步骤 1-3，直到你找到答案。

输出格式：
思考：[你的思考]
行动：[你执行的行动]
观察：[你观察到的结果]

最终答案：[最终答案]

这个 prompt 明确要求模型按照“思考-行动-观察”的顺序进行，并使用指定的格式输出结果。

包含工具信息的 ReAct Prompt：

如果需要使用特定的工具，需要在 prompt 中提供工具的描述和使用方法。例如：

问题：巴黎卢浮宫里有哪些著名的画作？

工具：
搜索工具：可以用来在互联网上搜索信息。使用方法：`search[查询内容]`

请按以下步骤进行：
1. 思考：描述你需要做什么来回答这个问题。
2. 行动：执行一个操作来获取信息（例如：调用搜索工具）。
3. 观察：记录你从操作中获得的信息。

重复步骤 1-3，直到你找到答案。

输出格式：
思考：[你的思考]
行动：[你执行的行动]
观察：[你观察到的结果]

最终答案：[最终答案]

在这个 prompt 中，我们明确告诉模型可以使用“搜索工具”，并说明了如何使用它（search[查询内容]）。

总结：

设计有效的 prompt 是应用这些框架的关键。你需要根据具体的任务和模型能力，选择合适的 prompt 结构和指令。对于 CoT，提供清晰的推理示例或指令；对于 ToT，引导模型生成多个想法并进行评估；对于 ReAct，引导模型交替进行推理和行动，并观察环境的反馈。通过不断地尝试和调整 prompt，你可以最大限度地发挥这些框架的潜力。

三、Tools: Our Key to the outside world

LLM excel at processing information, they lack the ability to directly perceive and influence the real world. This limits their usefulness in situations requiring interaction with external systems or data. Functions, Extensions, Data Stores and Plugins are all ways to provide this critical capability to the model.

Three primary tool types that Google models are able to interact with: Extensions, Functions, Data Stores.

1. Extensions

Bridging the gap between an API and an agent in a standardized way, allowing agents to seamlessly execute APIs regardless of their underlying implementation.

为什么扩展更好？

使用扩展的方法比自定义代码方法更好，主要体现在以下几个方面：

更强的泛化能力 (Better generalization)： 扩展通过示例“教”智能体如何使用 API，而不是编写硬编码的解析代码。这使得智能体能够更好地泛化到新的用户查询和输入，即使这些查询与示例略有不同。而自定义代码只能处理预先编写好的规则，缺乏泛化能力。

更少的代码维护 (Less code maintenance)： 使用扩展只需要提供 API 的描述和使用示例，而不需要编写大量的自定义代码来解析用户查询。这大大减少了代码的维护工作量。当 API 发生变化时，只需要更新扩展中的描述和示例即可，而不需要修改大量的代码。

更好的鲁棒性 (Better robustness)： 扩展可以处理更广泛的用户输入，包括缺少必要信息、信息不明确、表达方式多样等情况。智能体可以根据扩展提供的 API 描述和示例，灵活地调整其行为，并尝试从用户查询中提取尽可能多的信息。即使某些信息缺失，智能体也可以通过其他方式（例如提问）来获取缺失的信息，而不是直接失败。

更高的可扩展性 (Better scalability)： 添加新的 API 或修改现有 API 变得更加容易。只需要创建或更新相应的扩展即可，而不需要修改大量的代码。这使得该方法更具可扩展性，能够适应不断变化的应用需求。

利用了 LLM 的理解能力 (Leverages LLM's understanding)： 扩展利用了大型语言模型强大的自然语言理解能力。LLM 可以根据扩展提供的描述和示例，理解 API 的功能和使用方式，并将其应用于新的用户查询。这比编写硬编码的规则更加灵活和强大。

举例说明：

假设有一个航班预订 API，需要出发城市和到达城市作为参数。

使用自定义代码的方法： 需要编写代码来解析用户查询，提取出发城市和到达城市。如果用户只说“我想预订到苏黎世的航班”，代码就无法提取出发城市，导致 API 调用失败。

使用扩展的方法： 可以创建一个扩展，描述航班预订 API，并提供以下示例：

API 名称：航班预订 API
参数：
- 出发城市：字符串
- 到达城市：字符串

示例 1：
用户查询：我想预订从奥斯汀到苏黎世的航班
API 调用：book_flight(departure_city="奥斯汀", arrival_city="苏黎世")

示例 2：
用户查询：我想飞往伦敦
API 调用：book_flight(arrival_city="伦敦") # 出发城市未知

通过这个扩展，智能体可以学习到调用 book_flight API 需要哪些参数。即使缺少出发城市，智能体也可以通过提问等方式来获取缺失的信息，例如：“您从哪里出发？”。

总结：

使用扩展是连接智能体和 API 的一种更有效、更鲁棒的方法。它通过示例和描述“教”智能体如何使用 API，而不是编写硬编码的解析代码。这使得智能体能够更好地泛化到新的用户查询，并更易于维护和扩展。这种方法充分利用了大型语言模型的理解能力，是构建更智能、更灵活的智能体系统的关键

2. Functions

Funcitons differ from Extension in a few ways, most notably:

A model outputs a Function and its arguments, but doesn’t make a live API call.

Funcitons are executed on the client-side, while Extensions are executed on the agent-side.

Functions与 Extension核心区别：API 调用的执行位置。

1. 扩展（Extensions）：

API 调用由智能体直接执行： 智能体内部集成了调用 API 的逻辑。当智能体需要使用某个 API 时，它会直接构造 API 请求并发送到服务器，然后接收 API 响应并进行处理。

智能体与 API 直接交互： 智能体是 API 的直接调用者。

2. 函数调用（Function Calling）：

API 调用委托给客户端应用程序执行： 智能体只负责生成调用 API 的指令（即“函数调用”），而实际的 API 调用由客户端应用程序负责执行。智能体将需要调用的函数名称和参数传递给客户端，客户端执行实际的 API 调用，并将结果返回给智能体。

智能体不直接与 API 交互： 智能体只是发出指令，不负责执行实际的 API 调用。

为什么选择函数调用？

这段话列举了开发者可能选择使用函数调用而不是扩展的几个常见原因：

API 调用需要在应用程序堆栈的另一层进行 (API calls need to be made at another layer of the application stack)： 有些情况下，API 调用需要在智能体架构之外的组件中执行，例如中间件系统、前端框架等。这时，使用函数调用可以将 API 调用委托给这些组件。

安全或身份验证限制 (Security or Authentication restrictions)： 有些 API 可能由于安全或身份验证的原因，不允许智能体直接调用。例如，API 可能没有暴露在互联网上，或者智能体的基础设施无法访问该 API。这时，可以使用客户端应用程序作为中间层来调用 API，并处理身份验证等问题。

时序或操作顺序约束 (Timing or order-of-operations constraints)： 有些 API 调用可能需要满足特定的时序或操作顺序约束，例如需要进行批量操作或人工审核。智能体可能无法实时地进行这些操作。这时，可以使用函数调用将 API 调用委托给客户端应用程序，由客户端按照特定的时序或顺序执行操作。

需要对 API 响应应用额外的数据转换逻辑 (Additional data transformation logic needs to be applied to the API Response)： 有些 API 返回的数据格式可能不适合智能体直接使用，需要进行额外的转换。使用函数调用可以将 API 响应传递给客户端应用程序，由客户端进行数据转换后再返回给智能体。例如，API 可能没有提供结果数量限制，客户端可以进行过滤。

开发者希望在不部署额外基础设施的情况下迭代智能体开发 (The developer wants to iterate on agent development without deploying additional infrastructure for the API endpoints)：函数调用可以模拟 API 的行为，而无需实际部署 API 端点。这有助于开发者在早期开发阶段快速迭代智能体，并减少对外部基础设施的依赖。这类似于“桩代码”（stubbing）。

总结：

扩展和函数调用是两种不同的 API 集成方法，它们的主要区别在于 API 调用的执行位置。函数调用是一种强大的机制，它允许智能体利用外部功能，同时保持代码的安全性、可维护性和可扩展性。通过将 API 调用委托给客户端执行，开发者可以更好地控制应用程序的数据流和执行流程。选择使用函数调用还是扩展，取决于具体的应用场景和需求。如果需要更大的控制力、处理异步操作、保护凭据或在不同设备上运行函数，函数调用通常是更好的选择。

更简洁的总结：

扩展 (Extensions)： 智能体直接调用 API，类似于智能体自带了工具。

函数调用 (Function Calling)： 智能体发出指令（调用函数），由客户端执行实际的 API 调用，类似于智能体请求助手帮忙使用工具。

3. Data Stores

Data Stores providing access to more dynamic and up-to-data information, and ensuring a model’s responses remain grounded in factuality and relevance.

Data Stores allow developers to provide additional data in its original format to an agent, eliminating the need for time-consuming data transformations, model retraining, or fine-tuning. The Data Store converts the incoming document into a set of vector database embeddings that the agent can use to extract the information it needs to supplement its next action or response to the user.

One of the most prolific examples of Data Store usage with language models in recent times has been the implementation of Retrieval Augmented Generation(RAG) based applications. These applications seek to extend the breadth and depth of a model’s knowledge beyond the foundational training data by giving the model access to data in various formats like:

Website content

Structured Data in formats like PDF, Word Docs, CSV, Spreadsheets, etc.

Unstructured Data in formats like HTML, PDF, TXT, etc.

A user query is sent to an embedding model to generate embeddings for the query

The query embeddings are then matched against the contents of the vector database using a matching algorithm like SCaNN

The matched content is retrieved from the vector database in text format and sent back to the agent

The agent receives both the user query and retrieved content, then formulates a response or action

A final response is sent to the user

四、Targeted Learning

如何提高模型在生成输出时选择正确工具的能力，尤其是在生产环境中大规模使用工具时。它将通用训练比作基础烹饪技能，而实际应用则需要针对特定领域（例如特定菜系）的深入学习。为了使模型获得这种特定领域的知识，介绍了三种方法：上下文学习、基于检索的上下文学习和基于微调的学习。我将以研发专家的角度进行详细解读：

核心思想：模型需要针对特定任务进行学习，以更好地选择工具。

1. 通用训练与特定领域学习的类比：

这段文字用烹饪技能做了一个很好的类比：

通用训练 (General training) ≈ 基础烹饪技能 (Basic cooking skills)： 通用训练使模型掌握基本的语言理解、推理和生成能力，就像基础烹饪技能使厨师掌握基本的烹饪方法和技巧。

实际应用 (Real-world scenarios) ≈ 掌握特定菜系 (Mastering a specific cuisine)： 实际应用通常需要模型处理特定领域的问题，并使用特定的工具。这就像掌握特定菜系需要针对该菜系的食材、调料和烹饪方法进行深入学习。

这个类比强调了通用训练的局限性，以及针对特定领域进行学习的重要性。

2. 提高模型工具选择能力的三种方法：

为了使模型更好地选择工具，这段文字介绍了三种方法：

上下文学习 (In-context learning)：

工作方式： 在推理时，通过在 prompt 中提供工具的描述、使用方法以及少量示例，使模型能够“即时学习”如何使用这些工具。
优点： 灵活、快速，不需要重新训练模型。
缺点： 效果受 prompt 中示例的影响较大，对于复杂的任务可能需要大量的示例。
示例： ReAct 框架就是一种基于上下文学习的方法，它通过在 prompt 中引导模型进行推理和行动，并观察环境的反馈，使模型能够有效地使用工具。

基于检索的上下文学习 (Retrieval-based in-context learning)：

工作方式： 通过外部记忆（例如“示例商店”或数据存储），动态地检索与当前任务最相关的信息、工具和示例，并将其添加到 prompt 中。
优点： 可以利用大量的外部知识和示例，提高模型的性能。
缺点： 需要维护和管理外部记忆，检索过程可能会增加计算成本。
示例： Vertex AI 扩展中的“示例商店”和之前提到的基于 RAG（Retrieval Augmented Generation）的架构都属于这种方法。

基于微调的学习 (Fine-tuning based learning)：

工作方式： 在推理之前，使用大量的特定领域示例对模型进行微调，使其预先学习如何使用工具。
优点： 可以显著提高模型的性能，推理速度快。
缺点： 需要大量的训练数据和计算资源，重新训练模型的成本较高。

三种方法的对比：

方法	工作方式	优点	缺点
上下文学习	在 prompt 中提供工具描述、使用方法和少量示例	灵活、快速，无需重新训练模型	效果受 prompt 中示例影响较大，复杂任务可能需要大量示例
基于检索的上下文学习	从外部记忆检索相关信息、工具和示例，并添加到 prompt 中	可以利用大量外部知识和示例，提高模型性能	需要维护和管理外部记忆，检索过程可能增加计算成本
基于微调的学习	使用大量特定领域示例对模型进行微调	显著提高模型性能，推理速度快	需要大量训练数据和计算资源，重新训练成本较高