选择智能体 AI 架构组件

本文档提供了一些指导，可帮助您在 Google Cloud中为智能体 AI 应用选择架构组件。本文介绍了如何评估应用和工作负载的特征，以便选择最符合您需求的合适产品或服务。设计智能体 AI 架构的过程是迭代的。随着工作负载特征的变化、要求的演变或新 Google Cloud 产品和功能的推出，您应定期重新评估架构。

AI 智能体非常适合用于解决开放式问题的应用，这类应用可能需要自主决策和复杂的多步骤工作流管理。智能体擅长使用外部数据实时解决问题，也擅长自动执行知识密集型任务。与 AI 模型的辅助功能和生成功能相比，这些功能可让代理提供更高的商业价值。

对于具有预定义步骤的确定性问题，您可以使用 AI 代理。 不过，其他方法可能更高效且更具成本效益。例如，对于总结文档、翻译文本或对客户反馈进行分类等任务，您不需要使用智能体工作流。

如需了解其他非代理型 AI 解决方案，请参阅以下资源：

• AI 智能体、AI 助理和聊天机器人有什么区别？
• 为您的生成式 AI 应用选择模型和基础架构

代理架构概览

智能体是一种应用，它通过处理输入、使用可用工具进行推理，并根据推理结果采取行动来实现目标。智能体使用 AI 模型作为其核心推理引擎来自动执行复杂任务。智能体使用一组工具，让 AI 模型与外部系统和数据源进行交互。智能体可以使用记忆系统来保持上下文并从互动中学习。智能体架构的目标是创建一个自治系统，该系统能够理解用户意图、制定多步骤计划，并使用可用工具执行该计划。

下图高度概括地展示了代理系统的架构组件：

代理系统架构包括以下组件：

• 前端框架：一组预构建的组件、库和工具，用于构建应用的用户界面 (UI)。
• 智能体开发框架：用于构建和构造智能体逻辑的框架和库。
• 智能体工具：一组用于提取数据和执行操作或事务的工具，例如 API、服务和函数。
• 智能体记忆：智能体用于存储和回忆信息的系统。
• 智能体设计模式：用于构建智能体应用的常见架构方法。
• 代理运行时：代理的应用逻辑运行所在的计算环境。
• AI 模型：为代理的决策制定能力提供支持的核心推理引擎。
• 模型运行时：用于托管和部署 AI 模型的基础设施。

以下各部分详细分析了各个组件，可帮助您决定如何构建架构。您选择的组件会影响代理的性能、可伸缩性、成本和安全性。本文档重点介绍用于构建和部署代理的核心推理和执行逻辑的基本架构组件。Responsible AI 安全框架和代理身份管理等主题不在本文档的讨论范围内。

前端框架

前端框架是一组预构建的组件、库和工具，可用于构建代理应用的界面。您选择的前端框架决定了后端的要求。内部演示的简单接口可能只需要同步 HTTP API，而生产级应用则需要支持流式传输协议和稳健状态管理的后端。

请考虑以下类别的框架：

• 原型设计和内部工具框架：为了快速开发、进行内部演示和开发概念验证应用，请选择优先考虑开发者体验和开发速度的框架。这些框架通常倾向于采用一种简单且同步的模型，称为请求-响应模型。与生产框架相比，请求-响应模型可让您以最少的代码和更简单的后端构建功能性界面。此方法非常适合快速测试智能体逻辑和工具集成，但可能不适合需要实时互动的高度可伸缩的面向公众的应用。此类别中的常见框架包括 Mesop 和 Gradio。
• 生产框架：对于面向外部用户的可伸缩、响应迅速且功能丰富的应用，请选择允许使用自定义组件的框架。这些框架需要能够支持现代用户体验的后端架构。生产框架应包括对流式传输协议的支持、无状态 API 设计，以及用于管理多个用户会话中的对话状态的强大外部化内存系统。生产应用常用的框架包括 Streamlit、React 和 Flutter AI 工具包。

如需管理这些框架与 AI 智能体之间的通信，您可以使用智能体-用户互动 (AG-UI) 协议。AG-UI 是一种开放协议，可让后端 AI 智能体与前端框架进行互动。AG-UI 会告知前端框架何时渲染代理的回答、更新应用状态或触发客户端操作。如需构建交互式 AI 应用，请将 AG-UI 与智能体开发套件 (ADK) 结合使用。如需了解 ADK，请继续阅读下一部分“代理开发框架”。

智能体开发框架

智能体开发框架是一些库，可简化智能体 AI 应用的构建、测试和部署流程。这些开发工具为核心代理功能（包括推理循环、内存和工具集成）提供预构建的组件和抽象。

为了加快 Google Cloud中的智能体开发速度，我们建议您使用 ADK。 ADK 是一个开源的模块化框架，可为构建和编排工作流提供高级别的抽象，涵盖从简单任务到复杂的多智能体系统。

ADK 针对 Gemini 模型和 Google Cloud进行了优化，但它仍可与其他框架兼容。ADK 支持其他 AI 模型和运行时，因此您可以将其与任何模型或部署方法搭配使用。对于多智能体系统，ADK 支持通过共享会话状态进行交互、通过模型驱动的委托在智能体之间路由任务，以及通过显式调用让一个智能体将另一个智能体作为函数或工具来调用。

为了帮助您快速入门，ADK 提供了 Python、Java 和 Go 代码示例，这些示例展示了多个行业中的各种应用场景。虽然许多示例都突出了对话流程，但 ADK 也非常适合构建执行后端任务的自主代理。 对于这些非互动型使用情形，请选择一种擅长处理单个自包含请求并实现稳健的错误处理的智能体设计模式。

如需构建自定义智能体架构，您还可以使用 Genkit 等通用 AI 框架。Genkit 提供了一些基元，让您可以精细控制代理逻辑，而无需使用 ADK 提供的高级抽象。不过，像 ADK 这样的专用智能体框架提供了用于开发智能体应用的专用工具。

代理工具

智能体通过工具与外部系统互动的能力决定了其有效性。智能体工具是 AI 模型可用的函数或 API，智能体使用这些工具来增强输出并实现任务自动化。将 AI 智能体连接到外部系统后，工具会将智能体从简单的文本生成工具转变为能够自动执行复杂的多步骤任务的系统。

如需启用工具互动，请从以下工具使用模式中进行选择：

使用场景	工具使用模式
您需要执行网页搜索、运行计算或执行代码等常见任务，并希望加快初始开发速度。	内置工具
您希望构建模块化或多智能体系统，该系统需要可互操作且可重用的工具。	Model Context Protocol (MCP)
您需要以企业级规模管理、保护和监控大量基于 API 的工具。	API 管理平台
您需要与没有 MCP 服务器的特定内部或第三方 API 集成。	自定义函数工具

为智能体选择工具时，请评估这些工具的功能和运行可靠性。优先选择可观测、易于调试且包含强大错误处理功能的工具。这些功能有助于确保您可以跟踪操作并快速解决故障。此外，还要评估智能体选择合适工具以成功完成分配任务的能力。

工具臃肿

当您在 AI 模型的系统提示中提供过多的工具定义时，就会出现工具臃肿问题。如果模型上下文窗口中的工具数量过多、参数过于复杂或说明过于详细，模型可能会不堪重负。

当 AI 智能体因工具臃肿而过载时，可能会出现以下问题：

• 准确率降低：无关的 token 会分散模型在整个上下文窗口中的注意力。当模型的注意力被分散时，模型很难准确区分正确的工具和噪声。
• 成本和延迟时间增加：单个用户请求可能会触发多个隐藏的推理循环和工具执行。循环和执行次数的增加会导致费用和工具响应时间相应增加。

为缓解工具臃肿问题，您可以实施以下策略：

• 限制工具复杂性：以下是编写简洁工具定义的建议：
  • 使用原始数据类型，而不是复杂的嵌套对象。
  • 将工具限制为少于 5 个形参。
  • 使用 enums 而不是自由文本字符串来限制模型的决策路径。
• 提供精细化的工具集：将单体服务器拆分为精细化、专注的工具集，这些工具集基于特定的用户体验历程。例如，可以将一个大型 Cloud SQL 服务器分离为面向 DevOps 代理的管理工具集和面向应用代理的数据工具集。
• 实现逐步呈现：设计系统以仅在需要时动态解锁相关情境和功能，而不是预先加载所有内容。如需实现逐步披露方法，请使用以下策略：
  • 搜索工具模式：为了减少令牌消耗，请实现一个仅使用单个搜索工具动态加载相关工具架构的代理。
  • 智能体技能：智能体技能是一种标准格式，可逐步发现指令、脚本和其他资源。为了最大限度地减少上下文膨胀，请定义一种代理技能，使代理仅在必要时检索其他上下文。
  • 多智能体委托：为了减小智能体的上下文窗口，请实现一个多智能体系统，该系统使用协调器智能体将特定任务委托给专业化的分代理。这种方法可确保仅加载相关工具，并使协调器代理的上下文窗口保持简洁。

这些策略并非互斥，应根据您的架构和工作负载要求进行组合。

智能体记忆

智能体记住过往互动内容的能力对于提供连贯且实用的对话式体验至关重要。如需创建有状态、情境感知的代理，您必须实现短期记忆和长期记忆机制。以下部分探讨了可用于为代理实现短期记忆和长期记忆的设计选择和 Google Cloud服务。

短期记忆

短期记忆使智能体能够在单次正在进行的对话中保持上下文连贯。如需实现短期记忆，您必须同时管理会话及其关联的状态。

• 会话：会话是指用户与代理之间的对话消息串，从初始互动到对话结束。
• 状态：状态是指代理在特定会话中使用的和收集的数据。收集的状态数据包括用户和代理之间交换的消息历史记录、任何工具调用的结果，以及代理为了了解对话上下文而需要的其他变量。

以下是使用 ADK 实现短期记忆的选项：

• 内存存储：对于在单个实例上运行的开发、测试或简单应用，您可以将会话状态直接存储在应用的内存中。代理使用数据结构（例如字典或对象）来存储键值对列表，并在整个会话期间更新这些值。不过，当您使用内存中存储时，会话状态不是持久的。如果应用重启，则会丢失所有对话记录。

• 外部状态管理：对于需要可伸缩性和可靠性的生产应用，我们建议您构建无状态代理应用，并在外部存储服务中管理会话状态。在此架构中，每次代理应用收到请求时，都会从外部存储区检索当前对话状态，处理新的对话轮次，然后将更新后的状态保存回存储区。这种设计可让您横向扩缩应用，因为任何实例都可以处理任何用户的请求。外部状态管理的常见选择包括 Memorystore for Redis、Firestore 或 Gemini Enterprise Agent Platform 会话。

  如果您使用 ADK，则 DatabaseSessionService 需要关系型数据库，例如 Cloud SQL。

长期记忆

长期记忆可为代理提供持久的知识库，该知识库存在于每位用户的全部对话中。借助长期记忆，智能体可以检索和使用外部信息，从以往的互动中汲取经验，并提供更准确、更相关的回答。

以下是使用 ADK 实现长期记忆的选项：

• 内存中存储：在开发和测试期间，您可以将会话状态直接存储在应用的内存中。此方法易于实现，但无法持久。如果应用重启，则会丢失对话记录。您通常通过在开发框架中使用内存中提供程序来实现此模式，例如 ADK 中包含的 InMemoryMemoryService（用于测试）。
• 外部存储空间：对于生产应用，请在外部持久性存储服务中管理代理的知识库。外部存储服务可确保智能体的知识持久、可伸缩，并且可在多个应用实例中访问。将记忆库用于 Google Cloud上任何代理运行时的长期存储。

代理设计模式

智能体设计模式是构建智能体应用的常见架构方法。这些模式提供了一个独特的框架，用于组织系统组件、集成 AI 模型，以及编排单个或多个智能体来完成工作流。如需确定哪种方法最适合您的工作流程，您必须考虑任务的复杂程度和工作流程、延迟时间、性能和费用要求。

单智能体系统依赖于一个模型的推理能力来解读用户请求、规划一系列步骤并决定使用哪些工具。这种方法是一个有效的起点，可让您在增加架构复杂性之前，专注于优化核心逻辑、提示和工具定义。不过，随着任务和工具数量的增加，单个代理的性能可能会下降。

对于复杂问题，多智能体系统会协调多个专业智能体，以实现单个智能体无法轻松实现的目标。这种模块化设计可以提高系统的可伸缩性、可靠性和可维护性。不过，与单智能体系统相比，多智能体系统还带来了额外的评估、安全和成本方面的考虑因素。

在开发多智能体系统时，您必须为每个专用智能体实现精确的访问权限控制，设计可靠的编排系统以确保可靠的智能体间通信，并管理因运行多个智能体而产生的计算开销所带来的运营成本增加。如需促进智能体之间的通信，请将 Agent2Agent (A2A) 协议与 ADK 搭配使用。 A2A 是一种开放标准协议，可让 AI 智能体在不同平台和框架之间进行通信和协作，而无需考虑其底层技术。

如需详细了解常见的智能体设计模式以及如何根据工作负载要求选择模式，请参阅为智能体 AI 系统选择设计模式。

AI 模型

智能体应用依赖于模型的推理和理解能力，充当主要任务编排器。对于此核心代理角色，我们建议您使用 Gemini Pro。

Google 模型（例如 Gemini）通过受管理的 API 提供对最新、最强大的专有模型的访问权限。这种方法非常适合最大限度地减少运营开销。相比之下，开放的自托管模型可提供在专有数据上进行微调时所需的深度控制。对于具有严格安全性和数据驻留要求的工作负载，也需要自托管模型，因为这样您可以在自己的网络中运行模型。

如需提高代理的性能，您可以调整模型的推理能力。最新 Gemini Pro 和 Flash 模型等模型具有内置的思考过程，可提升推理能力和多步规划能力。为了进行调试和优化，您可以查看模型的思维总结（即其内部思维的合成版本），以了解其推理路径。您可以根据任务的复杂程度，调整思考预算（即思考 token 的数量），从而控制模型的推理能力。较高的思考预算可让模型在提供答案之前进行更详细的推理和规划。较高的思考预算可以提高回答质量，但同时也可能会增加延迟时间和费用。

为了优化性能和成本，请实现模型路由，根据任务的复杂性、成本或延迟要求，为每个任务动态选择最合适的模型。例如，您可以将简单的请求路由到小语言模型 (SLM)，以执行代码生成或文本分类等结构化任务，并预留功能更强大且更昂贵的模型用于复杂的推理任务。如果您在智能体应用中实现模型路由，则可以创建一个经济高效且保持高性能的系统。

Google Cloud 可让您访问各种 Google 模型、合作伙伴模型和开放模型，以便在智能体架构中使用这些模型。 如需详细了解可用的模型以及如何选择适合您需求的模型，请参阅 Gemini Enterprise Agent Platform 上的 Model Garden。

模型运行时

模型运行时是指用于托管和部署 AI 模型并向代理提供推理能力的环境。

选择模型运行时

在托管 AI 模型时，如需选择最佳运行时，请遵循以下指南：

使用场景	模型运行时
您需要一个全代管式 API 来提供 Gemini 模型、合作伙伴模型、开放模型或自定义模型，并具备企业级安全性、可伸缩性和生成式 AI 工具。	Agent Platform
您需要部署开放式或自定义容器化模型，并优先考虑无服务器的简易性和成本效益，以应对多变的网络流量。	Cloud Run
您需要最大限度地控制基础设施，以便在专用硬件上运行开放式或自定义容器化模型，或满足复杂的安全和网络要求。	GKE

以下部分概述了上述模型运行时，包括主要功能和设计注意事项。本文档重点介绍 Agent Platform、Cloud Run 和 Google Kubernetes Engine (GKE)。不过， Google Cloud 还提供其他服务，您不妨考虑将其用于模型运行时：

• Gemini API：Gemini API 专为需要快速直接访问 Gemini 模型，但不需要复杂代理系统通常需要的企业治理功能的开发者而设计。
• Compute Engine：Compute Engine 是一款基础设施即服务 (IaaS) 产品，适合用于旧版应用。与基于容器的现代运行时相比，它会带来显著的运营开销。

如需详细了解区分所有模型运行时服务选项的功能，请参阅模型托管基础架构。

智能体运行时

如需托管和部署代理应用，您必须选择代理运行时。 此服务会运行您的应用代码，即您在使用代理开发框架时编写的业务逻辑和编排。在此运行时中，您的应用会向您选择的模型运行时托管和管理的模型发出 API 调用。

选择代理运行时

如需在托管 AI 智能体时选择运行时，请参考以下指南：

使用场景	智能体运行时
您的应用是 Python 代理，需要完全托管的体验，并且运营开销极低。	Gemini Enterprise Agent Platform 上的 Agent Runtime
您的应用已容器化，并且需要无服务器、事件驱动型伸缩，同时具有语言灵活性。	Cloud Run
您的应用已容器化，具有复杂的状态要求，并且需要精细的基础架构配置。	GKE

如果您已在 Cloud Run 或 GKE 上管理应用，则可以使用同一平台来管理智能体工作负载，从而加快开发速度并简化长期运营。

以下部分概述了每种代理运行时，包括主要功能和设计注意事项。

后续步骤

• 智能体工具：
  • 为智能体构建自定义工具。
  • 工具赋能智能体：使用 ADK 从零开始构建智能助理。
  • Agent Factory 回顾：深入探讨智能体评估、实用工具和多智能体系统。
  • 如何在 Cloud Run 上部署安全的 MCP 服务器。
• 智能体记忆：
  • 记住我，智能体中的记忆。
  • Remember this: Agent state and memory with ADK。
• 智能体设计模式：
  • 为智能体 AI 系统选择设计模式。
  • 多智能体系统、概念和模式。
  • ADK 中的多智能体系统。
  • 使用 ADK 的智能体模式。
• 智能体运行时：
  • 在 Agent Runtime 上开发和部署智能体。
  • 在 Cloud Run 上托管 AI 应用和代理。
• Google Cloud上有关智能体 AI 的其他资源：
  • Google 的安全 AI 智能体方法。
  • 《Agent Factory》回顾：保护已投入使用的 AI 智能体。
  • 负责任的智能体： Google Cloud上的分阶段方法。
  • “The Agent Factory”播放列表。
• 如需查看更多参考架构、图表和最佳做法，请浏览云架构中心。

贡献者

作者：Samantha He | 技术文档工程师

其他贡献者：

• Amina Mansour | Cloud Platform 评估团队主管
• Amit Maraj | 开发者关系工程师
• Casey West | 架构技术推广工程师， Google Cloud
• Jack Wotherspoon | 开发技术推广工程师
• Joe Fernandez | 员工技术文档撰写人
• Joe Shirey | Cloud 开发者关系经理
• Karl Weinmeister | 云产品开发者关系总监
• Kumar Dhanagopal | 跨产品解决方案开发者
• Kurtis Van Gent | 资深软件工程师
• Lisa Shen | 高级对外产品经理， Google Cloud
• Mandy Grover | 架构中心主管
• Megan O'Keefe | 开发技术推广工程师
• Olivier Bourgeois | 开发者关系工程师
• Polong Lin | 开发者关系工程经理
• Ryan Pei | Google Cloud 产品经理
• Shir Meir Lador | 开发者关系工程经理
• Vlad Kolesnikov | 开发者关系工程师