在“谷歌：Agent智能体白皮书”中，讨论了生成式人工智能Agent的基础构建块、它们的组成以及以认知架构的形式实现这些有效方法的方法。这份白皮书的一些关键要点包括：- Agent通过利用工具访问实时信息、建议现实世界中的行动并自主规划和执行复杂任务来扩展语言模型的能力。Agent可以利用一个或多个语言模型，决定何时以及如何在状态之间进行过渡，并使用外部工具完成任何数量的复杂任务，这些任务对于该模型来说可能难以完成甚至不可能完成。
- 委托人的操作核心是协调层，这是一种认知架构，它结构化推理、规划和决策，并指导其行动。各种推理技术如ReAct、Chain-of-Thought 和Tree-of-Thought 提供了协调层获取信息、进行内部推理并生成有根据的决定或响应的框架。
- 工具，例如扩展、函数和数据存储，是Agent与外部世界之间的钥匙，允许它们与其他系统交互并访问超出其训练数据的知识。扩展为Agent和外部API提供桥梁，使Agent能够执行API调用并检索实时信息。函数通过分工提供了更细致的控制，让开发人员可以生成可以在客户端执行的功能参数。数据存储为Agent提供对结构化或非结构化数据的访问权限，从而实现基于数据的应用程序。
Agent的未来充满了令人兴奋的进步，我们才刚刚开始触及可能存在的可能性。随着工具变得越来越复杂，并且推理能力得到增强，Agent人将被赋予解决日益复杂的难题的能力。此外，“Agent链”战略方法将继续获得动力。全网最全DeepSeek报告，均已经上传至“智能计算芯知识”。请参考“230+份DeepSeek技术报告合集”，严选精华技术报告，绝不以次充优，提供打包下载，内容持续更新...什么是Agent？
重点介绍了生成式AI模型能够构建的具体类型的Agent。为了了解Agent的内部运作，首先让我们介绍驱动Agent行为、行动和决策的基础组件。这些组件的组合可以描述为认知架构，并且可以通过混合匹配这些组件来实现许多这样的架构。专注于核心功能，图1中显示了Agent的认知架构中的三个基本组件。为了更清楚地了解 Agent 和模型之间的区别，考虑以下图表： | |
| |
| 基于用户查询的单一推理/预测。除非为模型显式实现，否则不存在会话历史或连续上下文的管理。聊天记录) | 管理的会话历史(即聊天记录)允许基于用户查询和编排层做出的决策进行多轮推理/预测。在这种情况下，“回合”被定义为交互系统和Agent之间的交互。1个传入事件/查询和1个Agent响应) |
| |
| 没有实现本机逻辑层。用户可以将提示作为简单的问题或用户推理框架（CoT、ReAct等）来形成复杂的提示，以指导模型进行预测。 | 本机认知架构，使用推理框架，如CoT、ReAct或其他预构建Agent框架，如LangChain。 |
Agent如何运行？
想象一个厨房里的厨师Agent。他们的目标是为餐厅顾客创造美味佳肴，这涉及一些计划、执行和调整的循环过程。- 他们根据刚刚收集到的信息，进行一些内部推理，以确定可以创建哪些菜肴和风味轮廓。
- 他们采取行动来制作这道菜：切蔬菜，混合香料，煎肉。
在每个过程中，厨师根据需要进行调整，并随着原料的耗尽或客户反馈而不断细化他们的计划。他们使用之前的成果来确定下一步行动方案。这种信息摄入、规划、执行和调整的循环描述了厨师所采用的架构，以实现其目标。就像厨师一样，Agent可以通过迭代处理信息、做出明智的决策并根据先前输出来细化下一步行动，从而使用认知架构达到他们的最终目标。Agent的认知架构的核心是协调层，负责维护记忆、状态、推理和计划。它利用快速发展的提示工程领域及其相关框架来引导推理和规划，使Agent人能够更有效地与环境互动，并完成任务。关于语言模型的提示工程框架和任务规划的研究正在迅速发展，产生了各种有前途的方法。虽然这不是一个详尽的列表，但这些都是在本文发表时最流行的框架和技术：- ReAct 是一个提示工程框架，为语言模型提供了一种推理和对用户查询采取行动的思维过程策略。ReAct 提示已显示出优于几个最先进的基准，并提高了人类与 LLM 的互操作性和信任度。
- Chain-of-Thought（CoT），一种通过中间步骤实现推理能力的提示工程框架。CoT包括各种子技术，如自我一致性、主动提示和多模态CoT，每种技术都有其优点和缺点，具体取决于特定的应用程序。
- Tree-of-thoughts（ToT），，一种适用于探索或战略前瞻任务的提示工程框架。它超越了链式思维提示，并允许模型探索各种思维链条，这些思维链条作为语言模型解决一般问题的中间步骤。
Agent可以利用上述推理技术之一，或许多其他技术来选择给定用户请求的下一个最佳操作。工具（Tools）：通往外界的钥匙
虽然语言模型擅长处理信息，但它们缺乏直接感知和影响现实世界的能力。这限制了它们在需要与外部系统或数据交互的情况下使用性。这意味着，在某种程度上，一个语言模型只取决于它从训练数据中学习到的东西有多好。但是无论我们向模型扔多少数据，它们仍然缺乏与外界互动的基本能力。那么如何才能让我们的模型具备实时、上下文意识的对外部系统的交互能力呢？功能、扩展程序、数据存储和插件都是提供这种关键能力给模型的方法。虽然它们有很多名字，但工具是将我们的基础模型与外部世界联系起来的东西。这个对外部系统和数据的链接允许我们的Agent执行更广泛的任务，并且更加准确可靠地完成这些任务。例如，工具可以使得Agent能够调整智能家居设置、更新日历、从数据库中获取用户信息或根据特定指令发送电子邮件。截至本文发布日期，谷歌模型能够与三种主要工具类型进行交互：扩展、函数和数据存储。通过为Agent配备工具，我们解锁了他们不仅理解世界而且还能行动的巨大潜力，打开了无数新的应用程序和可能性的大门。扩展（Extensions）
要理解扩展，最简单的方法是将它们视为以标准化方式在API和Agent之间建立桥梁的方式，允许Agent无缝执行API而无需考虑其底层实现。假设您已经构建了一个具有帮助用户预订航班目标的Agent。你知道你想使用Google Flights API来检索航班信息，但你不确定你的Agent如何会调用这个API端点。一种方法是实施自定义代码，该代码会处理传入的用户查询、解析查询以获取相关信息，并然后调用API。例如，在航班预订使用案例中，用户可能会说“我想从奥斯汀预订到苏黎世的航班。”在这种情况下，我们的自定义代码解决方案需要在尝试调用API之前提取出“奥斯汀”和“苏黎世”作为相关的实体来自用户的查询。但是，如果用户说“我想预订飞往苏黎世的航班”，并且从未提供出发城市呢？如果没有所需的必要数据，API调用将失败，并且还需要更多代码来捕获像这种情况这样的边缘和角落情况。这种方法不可扩展，并且很容易在任何超出已实现的自定义代码范围的情景下崩溃。- 教给Agent需要成功调用API端点的哪些参数或参数。
扩展可以独立于Agent进行构建，但应作为Agent配置的一部分提供。Agent在运行时使用模型和示例来决定是否适合解决用户的查询。这突出了扩展的关键优势之一——其内置的示例类型，允许Agent动态选择最合适的扩展以完成任务。想想软件开发人员在解决和解决方案时如何决定使用哪个API端点。如果用户想预订航班，开发者可能会使用Google Flights API；如果用户想知道离他们当前位置最近的咖啡店在哪里，开发者可能会使用Google Maps API。同样地，在这个层面上，Agent/模型堆栈会使用一组已知扩展来决定哪一个最适合用户的查询。如果你想看看这些扩展的实际效果，你可以通过进入设置>扩展并启用你想要测试的任何内容来尝试Gemini应用程序中的它们。例如，您可以启用Google Flights扩展然后询问Gemini“显示从奥斯汀到苏黎世的航班，下周五离开。”这里的主要区别在于函数或Agent都不会直接与Google Flights API交互。那么API调用是如何发生的呢？通过功能，调用实际API端点的逻辑和执行被从Agent卸载到客户端应用程序上，如图8和图9所示。这为开发人员提供了更精细的数据流控制权。选择使用函数而不是扩展的原因有很多，但一些常见的用例包括：- 需要在应用程序堆栈的另一层进行API调用，而不能在直接Agent架构流之外（例如中间件系统、前端框架等）
- 安全或身份验证限制，这些限制阻止Agent直接调用API（例如，API未暴露到互联网上，或者无法通过Agent基础架构访问）
- 时间或操作顺序约束，这些约束会阻止Agent在实时情况下调用API。（例如批处理作业、人机交互审核等）
- 需要对Agent无法执行的API响应应用额外的数据转换逻辑。例如，考虑一个不提供限制返回结果数量过滤机制的API端点。在客户端使用函数为开发人员提供了更多机会来实现这些转换。
- 开发人员希望在不部署额外基础设施的情况下迭代Agent开发（即，函数调用可以像“API端点的占位符”一样工作）
如图8所示，两种方法之间的内部架构差异微妙。但是，额外的控制和对外部基础设施的解耦依赖使函数调用成为开发人员的一个有吸引力的选择。图8：客户界定 vs Agent侧控制扩展和功能调用一个模型可以用来调用函数，以处理复杂的客户端执行流程，其中Agent开发人员可能不希望语言模型管理API的执行（如扩展）。让我们考虑以下示例，在该示例中，正在训练一个Agent作为旅行顾问与想要预订度假行程的用户进行交互。目标是让Agent生成我们可以在我们的中间件应用程序中下载图像、数据等的城市列表，用于用户的行程规划。用户可能会说类似的话：在典型的提示模型中，输出可能看起来像以下内容：当然可以，这里有一份您可以考虑的家庭滑雪旅行的城市列表。虽然上面的输出包含我们所需的数据（城市名称），但格式并不适合解析。通过函数调用，我们可以教模型以一种更方便其他系统解析的结构化风格（如JSON）来格式化此输出。图9中的示例结果是，模型被用来“填补空白”，以满足客户端UI所需的参数来调用Google Places API。客户端UI使用由模型在返回的函数中提供的参数管理实际API调用。这只是一个函数调用的应用场景，但还有许多其他需要考虑的情况：- 您希望语言模型建议您在代码中可以使用的功能，但不想将凭证包含在您的代码中。因为函数调用不会运行该函数，因此您不需要在带有函数信息的代码中包括凭证。
- 您正在运行需要超过几秒钟的异步操作。这些场景与函数调用配合得很好，因为它是异步操作。
- 您想要在与产生函数调用及其参数的系统不同的设备上运行功能。
关于函数的一个关键点是，它们旨在为开发人员提供对不仅API调用的执行，而且整个应用程序的数据流的更多控制。在图9中的示例中，开发人员选择不将API信息返回给Agent，因为这与Agent可能采取的未来行动无关。然而，根据应用程序的架构，将外部API调用数据返回到Agent以影响未来的推理、逻辑和操作选择可能是有意义的。最终，应用程序开发人员需要决定什么最适合特定的应用程序。数据存储（Data stores）
想象一下，语言模型就像一个庞大的图书馆，包含其训练数据。但与不断获得新卷的图书馆不同，这个图书馆保持静止不动，只保留了最初培训的知识。这提出了一个问题，因为现实世界中的知识一直在不断发展。数据存储通过提供对更动态和更新信息的访问来解决这一限制，并确保模型的回答始终基于事实性和相关性。考虑一个常见的场景，开发人员可能需要向模型提供少量额外数据，也许是以电子表格或PDF的形式。图10：Agent如何与结构化和非结构化数据交互？数据存储允许开发人员以原始格式向Agent提供额外的数据，从而消除了耗时的数据转换、模型重新训练或精细调整的需要。数据存储将传入文档转换为一组向量数据库嵌入，这些嵌入是Agent可以用来提取其下一步操作或对用户响应所需的信息。图11：数据存储连接Agent到各种类型的新实时数据源在生成型人工智能Agent的背景下，数据存储通常被实现为开发人员希望Agent在运行时访问的向量数据库。虽然我们不会在这里深入探讨向量数据库，但关键要点是它们以矢量嵌入的形式存储数据，这是一种高维向量或对提供的数据进行数学表示的方式。最近使用语言模型的一个最常见示例就是检索增强的应用程序。基于 RAG 的应用程序。这些应用程序旨在通过向模型提供各种格式的数据，从而扩展模型知识的广度和深度，超越基础训练数据：- 结构化数据，如PDF、Word文档、CSV、电子表格等格式。
- 未结构化的数据，如HTML、PDF、TXT等格式。
图12：Agent和数据存储之间的一对多关系，可以表示各种类型的预索引数据每个用户请求和Agent响应循环的底层过程通常如图13所示进行建模。- 接下来，查询嵌入向量将与矢量数据库中的内容使用匹配算法（如SCaNN）进行匹配。
- 匹配的内容以文本格式从向量数据库中检索并发送回Agent。
- Agent程序接收用户查询和检索内容，然后制定响应或操作。
图13：基于RAG的应用程序中用户请求和Agent响应的生命周期最终结果是一个应用程序，允许Agent通过矢量搜索匹配用户的查询到已知的数据存储，并检索原始内容并将其提供给编排层和模型进行进一步处理。下一步可能是向用户提供最终答案，或者执行额外的矢量搜索以进一步细化结果。一个使用ReAct推理/规划实现RAG的Agent样本交互可以在图14中看到。图14：基于RAG的应用程序示例，带有ReAct推理和计划工具总结（Tools recap）
总结一下，扩展、功能和数据存储构成了可供Agent在运行时使用的几种不同工具类型。每个都有自己的目的，并且可以根据Agent开发人员的意愿一起或独立使用。 | | | |
| | | |
| • 开发者希望Agent能够控制与 API 端点的交互• 在利用原生预构建扩展（例如 Vertex 搜索、代码解释器等）时很有用• 多跳规划和 API 调用（即Agent的下一个操作取决于前一个操作/ API 调用的输出） | • 安全或身份验证限制使Agent无法直接调用 API。• 时间限制或操作顺序限制使Agent无法实时调用 API。（例如：批处理操作、人工审核等）• 未向互联网公开的 API，或 Google 系统无法访问的 API。 | 开发人员希望使用以下任何一种数据类型来实现检索增强生成（RAG）：• 以 PDF、Word 文档、CSV、电子表格等格式存在的结构化数据• 以 HTML、PDF、TXT 等格式存在的非结构化数据 |
通过目标学习增强模型性能（Enhancing model performance with targeted learning）
有效使用模型的关键方面之一是它们在生成输出时选择正确工具的能力，尤其是在生产中大规模使用工具的情况下。虽然一般培训有助于模型发展这种技能，但现实世界场景往往需要超出训练数据的知识。想象一下这就像基本烹饪技巧和掌握特定菜系之间的区别。两者都需要基础的烹饪知识，但是后者要求有针对性的学习以获得更细致的结果。在上下文中学习：这种方法在推理时提供了一个带有提示、工具和少量示例的通用模型，这使它能够“实时”学习如何以及何时使用这些工具来完成特定任务。ReAct 框架是自然语言中这种方法的一个例子。
基于检索的上下文学习：该技术通过从外部内存中检索最相关的信息、工具和关联示例，动态地将模型提示填充为最相关的信息。一个例子是Vertex AI扩展中的“示例存储”或前面提到过的基于RAG架构的数据存储。
精确调整学习：这种方法涉及在推理之前使用特定示例的大数据集对模型进行训练。这有助于模型了解何时以及如何在收到任何用户查询之前应用某些工具。
为了提供对每个目标学习方法的额外见解，让我们重新审视我们的烹饪类比。想象一下，一位厨师从客户那里收到了特定的食谱（提示）、一些关键食材（相关工具）和几道示例菜肴（少量示例）。基于这些有限的信息以及厨师对烹饪的一般知识，他们需要根据食谱和客户的偏好来确定如何“即兴”准备最接近的菜肴。这就是在上下文中学习。
现在让我们想象一下我们的厨师在一个厨房里，这个厨房有一个装满各种配料和食谱（示例和工具）的储藏室（外部数据存储）。现在厨师可以动态地从储藏室中选择配料和食谱，并更好地与客户的配方和偏好保持一致。这使厨师能够利用现有知识和新知识来创建更知情且精炼的菜肴。这是一种基于检索的上下文学习。
最后，让我们想象一下我们把厨师送回学校学习新的烹饪或一系列的烹饪（在特定示例的大数据集上进行预训练）。这使厨师能够以更深入的理解来应对未来的未见过的客户食谱。如果我们要让厨师精通于特定的烹饪知识领域，则这种方法是完美的。这是一种基于微调的学习方法。
这些方法在速度、成本和延迟方面都具有独特的优点和缺点。然而，通过将这些技术结合到Agent框架中，我们可以利用各种优势并最小化其劣势，从而实现更稳健且可适应性强的解决方案。
使用 Vertex AI Agent的生产应用程序（Production applications with Vertex AI agents）
虽然这篇白皮书探讨了Agent的核心组件，但构建生产级应用程序需要将它们与用户界面、评估框架和持续改进机制等其他工具集成在一起。Google的Vertex AI平台通过提供涵盖所有早期基本要素的完全托管环境简化了这一过程。使用自然语言接口，开发人员可以快速定义其Agent的关键元素 - 目标、任务说明、工具、用于任务委派的子Agent以及示例 - 以轻松构造所需系统行为。此外，该平台还附带了一组开发工具，允许进行测试、评估、测量Agent性能、调试并提高开发Agent的整体质量。这使开发人员能够专注于构建和完善他们的Agent，而基础设施、部署和维护的复杂性则由平台本身管理。图15：基于Vertex AI平台构建的端到端Agent架构示例在图 15 中，我们提供了一个使用诸如 Vertex Agent Builder、Vertex 扩展程序、Vertex 函数调用和 Vertex 示例存储等特性构建的Agent的示例架构。该架构包括许多生产就绪应用程序所需的各个组件。3、《14份半导体“AI的iPhone时刻”系列合集》8、《3+份技术系列基础知识详解（星球版）》
亚太芯谷科技研究院：2024年AI大算力芯片技术发展与产业趋势
本号资料全部上传至知识星球，更多内容请登录智能计算芯知识（知识星球）星球下载全部资料。
免责申明：本号聚焦相关技术分享，内容观点不代表本号立场，可追溯内容均注明来源，发布文章若存在版权等问题，请留言联系删除，谢谢。
温馨提示：
请搜索“AI_Architect”或“扫码”关注公众号实时掌握深度技术分享，点击“阅读原文”获取更多原创技术干货。
