10 个常见问题解答
本文是我推出的一个名为“10 个常见问题解答”的新系列的一部分。在本系列中，我旨在通过回答关于该主题的十个最常见问题来分解复杂的概念。我的目标是使用简单的语言和相关的类比，使这些想法易于理解。
图片来自 Solen Feyissa 在 Unsplash
如果您喜欢听，这里有一个我使用 Notebook LM 制作的关于同一主题的 AI 生成的播客
简介
Google 于 2024 年 9 月发表了一篇名为“Agents”的论文，作者是 Julia Wiesinger、Patrick Marlow 和 Vladimir Vuskovic。最近，这篇论文在 Twitter 上疯传。我通读了整篇论文（所以您不必这样做），并回答了十个关键问题，以帮助您深入了解 AI 代理。这篇文章是您开始并对 AI 代理感到兴奋所需要的一切。
1. 什么是代理，我为什么要了解它们？
生成式 AI 代理可以定义为试图通过观察世界并利用它们所拥有的工具采取行动来实现目标的应用程序。代理是自主的，可以独立于人为干预而行动。您可以通过人类的简单例子来理解它。我们人类非常擅长学习复杂的主题和混乱的模式识别，但我们使用外部工具，如书籍、互联网等。同样，我们可以训练基础 AI 模型来访问实时信息并据此采取行动。
像 Mark Zuckerberg（META 首席执行官）、Jensen Huang（NVIDIA 首席执行官）这样的行业领导者一直在称赞 AI 代理。Mark Zuckerberg 评论说
AI 代理的数量将超过人类，因为企业和个人会创建反映其价值观并代表他们与世界互动的 AI 代理
同样，Jensen Huang 将 AI 代理称为
可以彻底改变各个行业领域的“数字劳动力”，再加上它们的自主程度，可以帮助部署它们的公司在无需人为干预的情况下顺利运行其业务和工作空间
了解 AI 代理至关重要，因为它们代表了语言模型与外部世界交互方式的革命性转变。这些代理可以对医疗保健、金融、零售等行业产生变革性影响，从而塑造我们的生活和工作方式。
2. 什么是认知架构，认知架构由哪些组件构成？
代理可以推理出为了实现其目标接下来应该做什么，即使没有来自人类的明确信息。驱动代理行为、行动和决策的组件组合可以描述为_认知架构_。
认知架构及其组件
认知架构由三个组件构成：
1. 编排 2. 模型 3. 工具
3. 简要解释认知架构的组件。
模型
• 在代理的上下文中，模型指的是语言模型 (LM)。 • 此 LM 可用于集中式决策。 • 此 LM 可以是任何大小（小/大）的单个或多个 LM。 • 这些 LM 应该能够遵循基于指令的推理和逻辑框架，如 ReAct、Chain-of-Thought 和 Tree-of-Thought。 • LM 可以是通用、多模态或根据特定代理进行微调。 • 这里需要注意的是，LM 通常不会在特定的配置设置（即工具选择、编排等）上进行训练 • 但是，可以通过向模型提供展示代理功能的示例来改进代理任务的模型。
工具
• 工具弥合了传统基础模型之间的差距，允许它们与外部世界交互。 • 工具可以采取各种形式，并且具有不同程度的复杂性，但通常与常见的 Web API 方法（如 GET、POST、PATCH 和 DELETE）保持一致。 • 工具允许代理访问真实世界的信息；这使它们能够支持更专业的系统，如检索增强生成 (RAG)。
编排层
• 编排层描述了一个循环过程，该过程控制代理如何获取信息、执行一些内部推理，并使用该推理来告知其下一个行动或决策。 • 一般来说，这个循环将持续到代理达到其目标。 • 编排层的复杂性取决于代理及其执行的任务。
4. 传统模型和 AI 代理之间有什么区别（请参阅第 8 页了解详情）
• 在传统模型中，知识仅限于其训练数据中可用的内容，但在代理的情况下，知识通过与外部系统通过工具连接而得到扩展。 • 在传统模型中，没有实现原生逻辑层，但在代理的情况下，有 ReAct、Chain-of-Thought (CoT) 和 Tree of Thought (ToT) 等推理框架。 • 在传统模型中，没有内存管理（聊天记录）的概念，但在代理的情况下，会管理聊天记录以获得更准确的回复。 • 在传统模型中，没有工具的概念，但在代理的情况下，工具在代理架构中是原生实现的。
5. 代理如何操作以及最流行的框架（ReAct、Chain-of-Thought、Tree-of-Thought）的简要说明
ReAct 框架示例
正如您在上面的图中看到的，代理使用 ReAct 等推理框架来达到其最终目标。这是一个迭代过程，它提取信息、做出明智的决策，并根据先前的输出完善后续行动。
认知架构的核心是编排层，它负责维护内存、状态、推理和规划。
6. 什么是工具，Google 支持什么类型的工具（扩展、函数和数据存储）？
工具弥合了基础模型与外部世界之间的差距。无论您向模型投入多少训练数据，它仍然缺乏与外部世界交互的技能。函数、扩展、数据存储和插件都是为模型提供这种关键能力的方式。
截至该论文的发布日期（2024 年 9 月），Google 支持三种主要类型的工具，这些工具能够与模型交互：
1. 扩展 2. 函数 3. 数据存储
7. Extensions 与 Functions 的区别以及何时使用它们？
Extensions 与 API 交互
Extensions 允许 agents 无缝地执行 APIs，而不管其底层实现如何。Extensions 通过以下方式弥合了 agent 和 API 之间的差距：
1. 通过示例教 agent 如何使用 API 终端节点。 2. 教 agent 成功调用 API 终端节点需要哪些参数或 parameters。
使用 extensions 的关键优势在于，agent 可以根据运行时的示例决定哪个 extension（如果有）适合解决用户的查询。
Agent、Extensions 和 API 之间的一对多关系
另一方面，functions 为开发人员提供了对应用程序中数据流更细粒度的控制。一个模型可以获取一组未知的 functions，并根据其 specification 决定何时使用每个 function 以及 function 需要哪些参数。
Extension 和 function 调用的客户端与 Agent 端控制
Functions 与 Extensions 在几个方面有所不同，最显着的是：
1. 一个模型输出一个 function 及其参数，但不会进行实时的 API 调用。 2. Functions 在客户端执行，而 extensions 在 agent 端执行。
选择 functions 而不是 extensions 的原因：
1. API 调用需要在应用程序堆栈的另一层进行，而不是直接的 agent 架构流程中。 2. 阻止 agent 直接调用 API 的安全或身份验证限制。 3. 阻止 agent 实时进行 API 调用的时序或操作顺序约束。 4. 需要将额外的数据转换逻辑应用于 agent 无法执行的 API 响应。 5. 开发人员希望迭代 agent 开发，而无需为 API 终端节点部署额外的基础设施。
注意：如果您想详细了解 function 调用及其示例，请参考原始论文的第 23 页（底部链接）。
8. 什么是 Data Stores 以及何时使用 Data Stores (RAG)？
基础语言模型由于未接触到实时信息而具有知识截止。假设一个模型在 2024 年 9 月之前的数据上进行训练；它将无法回答有关 2024 年 9 月之后发生的事件的问题。为了解决这个问题，我们可以使用 Data Stores。
Data store 将 agent 连接到不同的信息来源
Data stores 允许开发人员以原始格式向 agent 提供额外的数据，从而消除了耗时的数据转换、模型重新训练或微调的需求。Data stores 将传入的文档转换为一组 vector database embeddings (一种数据的高维或数学表示)，agent 可以在运行时使用这些 embeddings 来提取其需要的信息，以补充其下一个操作或对用户的响应。Data stores 实现最著名的例子之一是基于 Retrieval Augmented Generation (RAG) 的应用程序。
基于 RAG 的示例应用程序，具有 ReAct 推理/规划
注意：RAG 应用程序的详细生命周期在原始论文中提供（参考第 29 页和图 13）
9. 如何提高模型性能以及用于实现此目的的技术类型？
使用模型的一个关键方面是它们在生成输出时选择正确工具的能力。为了实现最佳模型性能并帮助模型获得对特定类型知识的访问权限，存在几种方法：
• In Context learning • Retirement-based in-context learning • Fine-tuning based learning.
**In-Context Learning：**此方法在推理时为通用模型提供 prompt、工具和少量示例，这使其可以即时学习如何以及何时将工具用于特定任务。例如，ReAct 框架。
**Retrieval-based in-context learning：**此技术通过从外部内存中检索与工具和相关示例最相关的信息来动态填充模型 prompt。
**Fine-tuning based learning：**此方法涉及在推理之前使用更大规模的特定示例数据集来训练模型。这有助于模型在接收任何用户查询之前了解何时以及如何应用某些工具。
如果这对于您来说太技术性了，我们可以用一个简单的类比来理解这三种方法：
• 想象一下，一位厨师收到了一个特定的食谱（prompt）、一些关键的食材（相关工具）和一些示例菜肴（少量示例）来自顾客。基于这些有限的信息和厨师对烹饪的普遍知识，他们将需要在“即时”弄清楚如何准备最符合食谱和顾客偏好的菜肴。这就是 in-context learning。 • 现在，让我们想象一下，我们的厨师在一个厨房里，厨房里有一个储藏丰富的食品储藏室（外部数据存储），里面装满了各种食材和食谱（示例和工具）。厨师现在能够从储藏室中动态选择食材和食谱，并更好地与顾客的食谱和偏好保持一致。这使得厨师能够利用现有知识和新知识来制作更明智和更精致的菜肴。这就是 retrieval-based in-context learning。 • 最后，让我们想象一下，我们把厨师送回学校学习一种新的菜系或一套菜系（在更大规模的特定示例数据集上进行预训练）。这使得厨师能够以更深入的理解来处理未来未见的顾客食谱。如果我们希望厨师在特定菜系（知识领域）中表现出色，这种方法非常完美。这就是 fine-tuning based learning。
10. 如何构建 AI Agent？
到目前为止，我们探讨了 AI Agent 的核心概念，但构建生产级 AI Agent 需要将它们与额外的工具集成，例如用户界面、评估框架和持续改进机制。Google 的 _Vertex AI_ 平台通过提供完全托管的环境来简化此过程，其中涵盖了前面提到的所有基本要素。我们还可以利用开源库，如 _LangChain_ 和 _LangGraph_ 来制作原型 Agent。这些流行的开源库允许用户通过将逻辑、推理和工具调用序列 “链接” 在一起以回答用户的查询来构建客户 Agent。
基于 Vertex AI 平台构建的端到端 Agent 架构示例
• 使用 自然语言 界面，开发人员可以快速定义其 Agent 的关键要素——目标、任务说明、工具、用于任务委派的子 Agent 和示例——以轻松构建所需的系统行为。 • 该平台还附带一套开发工具，可用于测试、评估、衡量 Agent 性能、调试和提高已开发 Agent 的整体质量。 • 这使得开发人员可以专注于构建和完善他们的 Agent，而基础设施、部署和维护的复杂性则由平台本身管理。
注意：如果您想使用 Vertex AI 平台构建自定义 AI Agent，可以参考他们的文档 here。
结论
AI Agent 的未来充满了令人兴奋的进步，我们才刚刚触及了可能性的皮毛。随着工具变得越来越复杂，推理能力得到增强，Agent 将能够解决越来越复杂的问题。
此外，“Agent 链接” 的战略方法将继续获得发展势头。通过结合专业的 Agent——每个 Agent 都擅长于其特定行业或任务——我们可以创建一个 Agent 专家组合方法，能够跨各种行业和问题领域提供卓越的结果。
