选择智能体 AI 架构组件

Last reviewed 2026-04-21 UTC

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

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

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

如需了解非智能体 AI 替代解决方案，请参阅以下资源：

智能体架构概览

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

下图简要介绍了智能体系统的架构组件：

智能体系统的架构组件。

智能体系统架构包含以下组件：

  • 前端框架：一系列预构建的组件、库和工具，用于为应用构建界面 (UI)。
  • 智能体开发框架：用于构建和构造智能体逻辑的框架和库。
  • 智能体工具：一组工具，包括用于提取数据和执行操作或事务的 API、服务和函数。
  • 智能体记忆：智能体用于存储和回忆信息的系统。
  • 智能体设计模式：用于构建智能体应用的常见架构方法。
  • Agent runtime：智能体应用逻辑运行所在的计算环境。
  • 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 集成。 自定义函数工具

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

内置工具

ADK 提供了多个直接集成到智能体运行时的内置工具。您可以将这些工具作为函数调用，而无需配置外部通信协议。这些工具提供常见功能，包括从网络访问实时信息、在安全环境中以编程方式执行代码、从私有企业数据中检索信息以实现 RAG，以及与云数据库中的结构化数据进行交互。内置工具可与您创建的任何自定义工具搭配使用。

MCP

如需使智能体系统的组件能够交互，您需要建立清晰的通信协议。MCP 是一种开放协议，可为智能体提供标准化接口，以便其访问和使用必要的工具、数据和其他服务。

MCP 将智能体的核心推理逻辑与其工具的具体实现分离开来，类似于标准硬件端口允许不同外围设备连接到设备。

MCP 具有以下优势：

  • 提供预构建的连接器，简化工具集成。向 MCP 服务器添加更多工具后，智能体无需额外配置即可发现这些工具。
  • 提供了一种构建自定义集成的一致方式。
  • 提供灵活性，并促进不同模型和工具之间的互操作性。

您可以使用以下方法在智能体 AI 系统中实现 MCP 服务器：

  • Google Cloud MCP 服务器：如需连接到 Google 和 Google Cloud 服务，请连接到由 Google 全托管式管理的远程 MCP 服务器。这些服务器通过在您使用的所有 Google 和 Google Cloud 服务之间提供统一层，增强了您现有的基础设施。这些服务器提供无状态伸缩功能，并与 Identity and Access Management (IAM) 和 Cloud Audit Logs 集成。如需查看 Google Cloud MCP 服务器的列表，请参阅支持的产品。
  • 远程 MCP 服务器：如需连接到外部 API，请连接到由第三方托管和管理的远程 MCP 服务器。
  • 自托管 MCP 服务器：如需实现您自己的智能体逻辑和自定义工具，请托管您自己的 MCP 服务器。您可以完全控制如何向智能体公开专有或第三方 API。如需托管您自己的自定义 MCP 服务器，请将其作为容器化应用部署在 Cloud Run 或 Google Kubernetes Engine (GKE) 上。

API 管理平台

API 管理平台是一个集中式系统，可让您通过 API 保护、监控和控制内部或外部服务。API 管理平台提供了一个集中位置来对组织的所有 API 进行编目，简化了数据公开方式，并通过用量监控提供了可观测性。

如需在 Google Cloud上以企业规模管理代理的基于 API 的工具，我们建议您使用 Apigee API Hub。借助 API Hub，智能体可以通过直接 HTTP 调用、预构建连接器、在 Hub 中注册的自定义 API 或直接访问 Google Cloud 数据源，即时连接到数据。通过这种方法，您的智能体可以立即访问所需信息，而无需构建自定义数据加载和集成流水线，从而避免了复杂性。

API 管理平台和 MCP 等通信协议解决的是不同的架构问题。通信协议可标准化智能体与工具之间的交互格式，从而确保组件可重复使用和可交换。相比之下，API 管理平台负责管理 API 端点的生命周期和安全性，处理身份验证、速率限制和监控等任务。这些模式是互补的。例如，代理可以使用 MCP 与工具通信，而该工具又可以是 API Hub 管理和保护的安全 API 端点。

自定义函数工具

函数工具可为智能体提供新功能。您可以编写自定义函数工具，为智能体提供专门的功能，例如与外部 API 或专有业务系统集成。编写自定义函数工具是最常见的模式，可用于扩展智能体的能力，使其超越内置工具所能提供的功能。

如需创建自定义函数工具，您需要使用首选编程语言编写函数，然后用自然语言清晰地描述其用途、参数和返回值。智能体的模型会使用此说明来推断何时需要该工具、要提供哪些输入，以及如何解读输出以完成用户的请求。

您还可以创建实现智能体即工具函数的自定义函数工具。智能体即工具函数会将一个智能体公开为可调用函数，供另一个智能体调用。借助此技术，您可以构建复杂的多智能体系统，其中一个智能体可以协调专门任务并将其委托给其他专门智能体。如需详细了解智能体设计模式和协调多智能体编排，请参阅本文档后面的智能体设计模式部分。

工具臃肿

如果您在 AI 模型的系统提示中提供了过多工具定义，就会发生工具膨胀。如果模型上下文窗口中的工具、复杂参数或详细说明过多，模型可能会不堪重负。

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

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

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

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

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

智能体记忆

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

短期记忆

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

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

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

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

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

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

长期记忆

长期记忆为代理提供了一个持久性知识库，该知识库存在于各个用户的所有对话中。长期记忆使智能体能够检索和使用外部信息，从过去的互动中学习，并提供更准确、更相关的回答。

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

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

智能体设计模式

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

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

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

开发多智能体系统时，您必须为每个专用智能体实现精确的访问权限控制，设计强大的编排系统以确保可靠的智能体间通信，并管理因运行多个智能体的计算开销而增加的运营成本。如需促进智能体之间的通信，请将 Agent2Agent (A2A) protocol 与 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，以便通过企业级安全性、伸缩和生成式 AI 工具来提供 Gemini 模型、合作伙伴模型、开放模型或自定义模型。 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) 产品，适用于旧版应用。与基于容器的现代运行时相比，它会带来巨大的运营开销。

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

Agent Platform

Agent Platform 提供了一个全代管式式无服务器环境，用于托管 AI 模型。您可以通过安全且可伸缩的 API 提供和微调 Google 模型、合作伙伴模型和开放模型。这种方法无需进行任何基础设施管理，让您可以专注于将模型智能集成到应用中。

将 Agent Platform 用作模型运行时时，主要功能和注意事项包括：

  • 基础架构控制：适用于模型的全代管式 API。Google 负责管理底层基础设施。
  • 安全性：托管式安全默认设置和标准合规性认证足以满足您的需求。为了提供提示和回答保护并确保 Responsible AI 实践，您可以将 Model Armor 集成到 Agent Platform 中。
  • 模型可用性：通过托管式 API 访问各种模型，包括最新的 Gemini 模型。
  • 费用：按用量付费的价格模式，可根据应用流量进行扩缩。如需了解详情，请参阅在 Agent Platform 中构建和部署 AI 模型的费用。

Cloud Run

Cloud Run 提供了一个无服务器运行时，用于在自定义容器中托管模型。Cloud Run 既有 Agent Platform 的全代管式简便性，又有 GKE 的深度基础设施控制能力，两者兼而有之。如果您需要灵活地在容器化环境中运行模型，而无需管理服务器或集群，则此方法非常适合。

将 Cloud Run 用作模型运行时时，主要功能和注意事项包括：

  • 基础设施控制：在自定义容器中运行任何模型，从而完全控制软件环境，而平台则管理底层无服务器基础设施。
  • 安全性：通过临时、隔离的计算实例提供安全性，并允许使用直接 VPC 出站流量或无服务器 VPC 访问通道连接器安全地连接到私有资源。如需了解详情，请参阅专用网络和 Cloud Run。
  • 模型可用性：提供 Gemma 等开放模型或您自己的自定义模型。您无法在 Cloud Run 上托管或提供 Gemini 模型。
  • 费用：采用按用量付费、基于请求的定价模式，可缩减至零，因此对于流量不规律或不稳定的模型来说，具有极高的成本效益。如需了解详情，请参阅 Cloud Run 价格。

GKE

GKE 为托管 AI 模型提供了最大的控制力和灵活性。如需使用此方法，您需要在您配置和管理的 GKE 集群上的容器中运行模型。如果您需要在专用硬件上运行模型、将模型与应用共置以最大限度地减少延迟，或者需要对服务环境的各个方面进行精细控制，GKE 是理想之选。

将 GKE 用作模型运行时时，主要功能和注意事项包括：

  • 基础架构控制：提供对整个服务环境（包括节点配置、专用机器加速器和特定模型部署软件）的最大限度精细控制。
  • 安全性：可实现最高级别的安全性和数据隔离，因为它可让您完全在网络中运行模型，并应用精细的 Kubernetes 安全政策。如需筛查进出 GKE 集群的流量并保护与 AI 模型的所有互动，您可以将 Model Armor 与 GKE 集成。
  • 模型可用性：提供 Gemma 等开放模型，或提供您自己的自定义模型。您无法在 GKE 上托管或应用 Gemini 模型。
  • 费用：采用基于您使用的底层计算和集群资源的费用模型，因此，当您使用承诺使用折扣 (CUD) 时，该模型针对可预测的大容量工作负载进行了高度优化。如需了解详情，请参阅 Google Kubernetes Engine 价格。

Agent Runtime

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

选择智能体运行时

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

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

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

以下部分简要介绍了每个 Agent Runtime，包括关键功能和设计注意事项。

Agent Runtime

Agent Runtime 是一种全托管式、有特定设计理念的运行时，可用于部署、运行和扩缩智能体应用。Agent Runtime 抽离了底层基础设施，让您可以专注于智能体逻辑，而无需担心运维。

以下是 Agent Runtime 的功能和注意事项：

  • 编程语言和框架灵活性：使用任何受支持的框架以 Python 语言开发智能体。
  • 通信协议：编排使用 MCP 和 A2A 的智能体和工具。Agent Runtime 可高效管理这些组件的运行时，但不支持托管自定义 MCP 服务器。

  • 记忆：提供内置的代管式记忆功能，无需为核心智能体记忆配置外部数据库。

  • 可扩缩性：自动扩缩以满足智能体工作负载的需求，无需手动配置。
  • 可观测性：通过 Google Cloud Observability 服务提供集成的日志记录、监控和跟踪。
  • 安全性：提供以下企业级可靠性、可伸缩性和合规性：

    如需了解 Agent Runtime 安全功能，请参阅企业级安全性。

Agent Runtime 可加快投入生产环境的速度，因为它提供了一个专门构建的托管式环境，可处理您在操作智能体时遇到的许多复杂问题，例如生命周期和上下文管理。Agent Runtime 不太适合需要对计算环境进行大量自定义或需要使用 Python 以外的编程语言的用例。对于在私有依赖项管理方面有严格安全要求的工作负载，Cloud Run 和 GKE 提供了更直接、基于 IAM 的配置路径。

Cloud Run

Cloud Run 是一个全代管式无服务器平台，可让您在无状态容器中运行智能体应用代码。如果您希望将整个智能体应用、各个组件或自定义工具部署为可伸缩的 HTTP 端点，而无需管理底层基础架构，那么 Cloud Run 是理想之选。

以下是 Cloud Run 的功能和注意事项：

Cloud Run 无需管理基础设施，因此可显著简化运营并提高成本效益。不过，由于 Cloud Run 具有无状态特性，您需要使用存储服务来管理多步工作流中的上下文。 此外，Cloud Run 服务的请求超时上限为 1 小时，这可能会限制长时间运行的智能体任务。

GKE

Google Kubernetes Engine 是一项代管式容器编排服务，可让您对智能体应用的架构和基础设施进行精细控制。GKE 适用于需要强大的生产级功能的复杂智能体系统，或者如果您已经是 GKE 客户，并且希望在现有应用之上实现智能体工作流。

以下是 GKE 上提供的功能和注意事项：

GKE 提供最大程度的控制力和灵活性，让您能够运行复杂的有状态智能体。不过，这种控制会带来巨大的运营开销和复杂性。您必须配置和管理 Kubernetes 集群，包括节点池、网络和伸缩政策，这比无服务器平台需要更多的专业知识和开发工作。

后续步骤

贡献者

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

其他贡献者：