2025年AI Agent白皮书：AI智能体时代来临

作者：Julia Wiesinger，Patrick Marlow和Vladimir Vuskovic 致谢 审稿人和贡献者 黄岩 岛雪 奥尔坎·谢辛奥卢 赛巴斯蒂安·里德尔 桑蒂尔·巴维贾 安东尼奥·古利 阿南特·纳瓦格拉里亚 策展人和编辑Antonio Gulli, Anant N awalgaria, Grace Mollison 技术作家乔伊·海梅克 设计师迈克尔·兰宁 目录 5677881213151821242728323335384042引言 4什么是代理？模型工具orchestration layer代理商与模型认知架构：代理如何运作工具：我们通往外界的关键扩展样本扩展函数用例功能示例代码数据存储实施与应用工具回顾通过针对性学习提升模型性能。代理快速入门指南：LangChain生产应用与Vertex AI代理摘要脚注 这种推理组合，逻辑和外部访问所有信息都是相互关联的。对生成式AI模型的调用代理的概念。 引言 人类擅长进行混乱模式的识别任务。然而，他们在得出结论之前，常常依赖工具——如书籍、谷歌搜索或计算器——来补充他们已有的知识。正如人类一样，生成式AI模型可以被训练来利用工具访问实时信息或提出现实世界中的行动建议。例如，一个模型可以利用数据库检索工具来访问特定信息，例如客户的购买历史，以便生成个性化的购物建议。或者，基于用户的查询，一个模型可以调用不同的API来向同事发送电子邮件回复或代表你完成一项金融交易。要这样做，模型不仅要能够访问一系列的外部工具，它还需要具备以自主的方式规划和执行任何任务的能力。这种将推理、逻辑与连接到生成式AI模型的对外部信息的组合，引发了“代理”或“超出生成式AI模型独立能力的程序”的概念。本白皮书深入探讨了这些及相关方面的更多详细内容。 什么是代理？ 在其最基本的形式中，一个生成式人工智能代理可以被定义为一种通过观察世界并利用其可用的工具采取行动以实现目标的应用程序。代理是自主的，可以在不依赖人类干预的情况下独立行动，特别是在提供了它们旨在实现的目标或任务时。代理还可以在其实现目标的方法上采取主动。即使在缺乏人类明确指令的情况下，代理也能对其下一步应采取什么行动进行推理，以实现其最终目标。虽然人工智能中的代理概念相当通用且强大，但这份白皮书专注于生成式人工智能模型在出版时能够构建的具体类型的代理。 为了理解一个智能代理的内在运作机制，首先让我们介绍一些基础组件，这些组件驱动着代理的行为、动作和决策过程。这些组件的组合可以被描述为认知架构，并且有众多这样的架构可以通过这些组件的混合与搭配来实现。聚焦于核心功能，智能代理的认知架构中有三个基本组件，如图1所示。 模型 在代理的范围内，一个模型指的是将作为代理过程的集中决策者所使用的语言模型（LM）。代理所使用的模型可以是一个或多个任何大小（小型/大型）的LM，这些模型能够遵循基于指令的推理和逻辑框架，如ReAct、思维链或思维树。模型可以是通用型、多模态或根据特定代理架构的需求进行微调。为了获得最佳的生产结果，您应该利用最适合您期望的最终应用的模型，理想情况下，这些模型是在与您计划在认知架构中使用的工具相关的数据签名上训练的。需要注意的是，该模型通常不会使用与代理的具体配置设置（即工具选择、编排/推理设置）相关的特定配置进行训练。然而，通过向模型提供展示代理能力、包括代理在各种场景下使用特定工具或推理步骤的示例，可以进一步细化模型以适应代理的任务。 工具 基础模型尽管在文本和图像生成方面表现出色，但仍受限于无法与外界互动。工具架设这个差距，使代理能够与外部数据和服务交互，同时解锁超越底层模型本身范围的一系列动作。工具可以采取多种形式，并具有不同深度的复杂性，但通常与常见的Web API方法（如GET、POST、PATCH和DELETE）相一致。例如，一个工具可以更新数据库中的客户信息或获取天气数据，以影响代理提供给用户的旅行建议。借助工具，代理可以访问和处理现实世界的信息。这使得他们能够支持更多专业化的系统，如检索增强生成（RAG），这显著扩展了代理的能力，超出了基础模型本身所能实现的范围。我们将在下面更详细地讨论工具，但最重要的是要理解工具填补了代理内部能力与外部世界之间的差距，解锁了更广泛的可能。 orchestration layer 调度层描述了一个循环过程，该过程决定了智能体如何获取信息，进行内部推理，并利用这些推理来指导其下一步的行动或决策。一般来说，这个循环将持续进行，直到智能体达到其目标或停止点。调度层的复杂性可以根据执行任务和智能体的不同而有很大差异。一些循环可能是简单的计算与决策规则，而其他循环可能包含链式逻辑，涉及额外的机器学习算法，或实施其他概率推理技术。我们将在认知架构部分更详细地讨论智能体调度层的实现细节。 代理商与模型 为了更清晰地理解代理商和模型之间的区别，请考虑以下图表： 认知架构：代理如何运作 想象一位在繁忙厨房中的厨师。他们的目标是为餐厅顾客制作美味的菜肴，这涉及到一些规划、执行和调整的循环。 • 他们收集信息，例如顾客的订单以及储藏室和冰箱中的食材。 • 他们基于刚刚收集到的信息，进行一些内部推理，以确定他们可以创造出哪些菜肴和口味特征。 他们采取措施制作菜肴：切菜、调和香料、烹饪肉类。 在过程的每个阶段，厨师根据需要做出调整，在原料耗尽或收到顾客反馈时完善其计划，并使用先前结果的集合来决定下一项行动计划。这一信息收集、计划、执行和调整的周期描述了厨师用以达成目标的一种独特认知架构。 就像厨师一样，代理人可以通过迭代处理信息、做出明智的决策以及根据先前的输出细化后续行动来使用认知架构实现其最终目标。代理人认知架构的核心是编排层，负责维持记忆、状态、推理和规划。它利用快速发展的提示工程领域及其相关框架来引导推理和规划，使代理人能够更有效地与其环境互动并完成任务。在提示工程框架和语言模型任务规划领域的研究正在迅速发展，产生了各种有前景的方法。虽然这不是一个详尽的列表，但这些是在本出版物发布时最流行的框架和推理技术之一： •ReAct一个提供语言模型进行推理并针对用户查询采取行动的思考过程策略的即时工程框架，无论是否有上下文示例。ReAct提示方法已被证明优于多个SOTA基线，并提高了LLMs的人类交互性和可靠性。 •思维链（CoT）一个通过中间步骤实现推理能力的即时工程框架。CoT（提示学习）有各种子技术，包括自洽性、主动提示和多模态CoT，每种技术根据具体应用都有其优点和缺点。 •思维树（ToT）,,一个适用于探索或战略前瞻性任务的即时工程框架。它泛化了对思维链提示的应用，并允许模型探索各种作为语言模型一般问题解决中间步骤的思想链。 代理商可以利用上述推理技术之一，或许多其他技术，来选择针对给定用户请求的最佳下一步行动。例如，让我们考虑一个被编程为使用……的代理商。ReAct框架用于选择用户查询的正确动作和工具。事件序列可能如下： 1. 用户向代理发送查询 代理开始执行ReAct序列 3. 代理商向模型提供提示，要求它生成下一个ReAct步骤及其相应的输出： b. 思想：模型对于其下一步应该采取何种行动的思考c. 行动：模型关于下一步采取何种行动的决定问题：用户查询中提供的输入问题，与提示一起提供a. i. 这就是工具选择可能发生的地方 例如，一个动作可以是以下之一[Flights, Search, Code, None]，其中前三个代表模型可以选择的已知工具，最后一个代表“无工具选择”。 d. 行动输入：模型决定提供给工具（如果有）哪些输入 e. 观察结果：动作/动作输入序列的结果 这种思想/行为/行为输入/观察可以在需要的情况下重复N次。i. f.最终答案：该模型最终提供的用于回应原始用户查询的答案 4. ReAct循环结束，并提供最终答案给用户 如图2所示，模型、工具和代理配置协同工作，基于用户的原始查询提供基于事实的简洁响应。虽然模型可以根据先前的知识猜测答案（幻想），但它却使用工具（航班信息）搜索实时外部信息。这些额外信息被提供给模型，使其能够根据真实事实数据作出更明智的决定，并将此信息总结回送给用户。 总之，代理响应的质量可以直接关联到模型处理和执行这些各种任务的能力，包括选择正确工具的能力以及这些工具定义的完善程度。就像厨师使用新鲜食材并关注顾客反馈来制作菜肴一样，代理依赖于合理的推理和可靠的信息来提供最佳结果。在下一节中，我们将深入探讨代理如何与新鲜数据建立联系。 工具：我们通往外界的关键 虽然语言模型在处理信息方面表现出色，但它们缺乏直接感知和影响现实世界的能力。这限制了它们在外部系统或数据交互所需情况下的实用性。这意味着，从某种意义上说，语言模型的好坏取决于其从训练数据中学到的东西。但无论我们向模型投入多少数据，它们仍然缺乏与外部世界互动的基本能力。那么，我们如何使我们的模型能够与外部系统进行实时、上下文感知的交互呢？函数、扩展、数据存储和插件都是为模型提供这种关键能力的方式。 虽然它们有许多名称，工具是连接我们基础模型和外部世界的桥梁。这一外部系统和数据链接使得我们的代理能够执行更多样化的任务，并以更高的准确性和可靠性完成。例如，工具可以使代理调整智能家居设置、更新日历、从数据库中检索用户信息，或根据特定指令发送电子邮件。 截至本出版物发布日期，Google模型能够与之交互的三种主要工具类型为：扩展、函数和数据存储。通过为代理配备工具，我们释放了它们巨大的潜力，不仅能够理解世界，还能够采取行动，为无数新的应用和可能性打开大门。 扩展 最容易理解扩展的方式就是将它们视为以标准化的方式弥合API和代理之间的差距，使代理能够无缝执行API，而不论其底层实现。假设您已经构建了一个以帮助用户预订航班为目标的代理。您知道您想要使用Google Flights API来检索航班信息，但您不确定如何让您的代理调用此API端点。 一种方法可能是实现自定义代码，该代码将接收到的用户查询提取相关信息，然后调用API。例如，在航班预订场景中，用户可能会说“我想预订一个航班”从奥斯汀到苏黎世在这个场景中，我们的定制代码解决方案需要从用户查询中提取“Austin”和“Zürich”作为相关实体，然后再尝试进行API调用。但是，如果用户说“我想预订一张机票”，会发生什么情况？前往苏黎世并且从未提供出发城市？在没有必要数据的API调用中会失败，并且需要实现更多的代码来捕捉这类边缘和特殊情况。这种方法不可扩展，并且容易在任何超出已实施自定义代码的情境中崩溃。 更具有弹性的方法是通过使用扩展来实现。扩展通过以下方式在代理和API之间架起桥梁： 1. 通过示例教授代理如何使用API端点。 2. 教导代理所需使用哪些参数或论证才能成功调用API端点。 扩展可以独立于代理来创建，但应作为代理配置的一部分提供。代理在运行时使用模型和示例来决定哪个扩展（如果有的话）适合解决用户的查询。这突出了扩展的关键优势，即它们的内置示例类型允许代理动态选择最适合任务的扩展。 将此视为软件开发者决定在解决用户问题时使用哪些API端点的方式相同。如果用户想要预订航班，开发者可能会使用Google Flights API。如果用户想知道离他们最近咖啡馆的位置，开发者可能会使用Google Maps API。以同样的方式，代理/模型堆栈使用一组已知的扩展来决定哪个将是用户查询的最佳匹配。如果您想看到扩展的实际应用，您可以在Gemini应用程序的设置>扩展中尝试它们，然后启用您想要测试的任何扩展。例如，您可以使用Google Flights扩展，然后向Gemini询问“下周五从奥斯汀到苏黎世的航班。” 样本扩展 为了简化扩展插件的使用，Google提供了一些即插即用的扩展，可以快速导入项目并在最少配置的情况下使用。例如，片段1中的代码解释器扩展允许您从自然语言描述生成并运行Python代码。 导入顶点