多租户智能体 AI 系统

Last reviewed 2026-06-18 UTC

本文档提供了一个参考架构，可帮助您在 Google Cloud上设计和部署多租户智能体 AI 系统。随着组织扩大生成式 AI 部署规模，不同的业务部门需要专门的 AI 智能体，这些智能体可以访问独特的工具、遵循特定的运营规则并处理敏感数据。业务部门可能会在组织内开发分散的应用孤岛，这可能会导致运营开销过高、治理严重不足以及数据暴露风险。此架构展示了如何构建集中式系统，让您能够为分散式团队提供自主 AI 功能，同时保持统一的安全性和合规性。

本文档的目标受众群体包括在云端构建和管理企业级多智能体系统的架构师、开发者和管理员。本文档假定您对 AI、机器学习和 LLM 概念以及智能体 AI 有基本的了解。

本文档的部署部分提供了一种实现策略，可帮助您构建和部署多租户智能体 AI 系统。

架构

下图展示了遵循枢辐模型的多租户代理 AI 系统的架构。 中心辐射型模型是一种网络设计，其中中央环境（称为中心）连接到多个隔离的环境（称为辐条）。

一种显示多租户智能体 AI 系统的架构。

该架构包含以下组件：

组件 说明
VPC Service Controls 该架构使用 VPC Service Controls 在组织级层配置服务边界。此服务边界可提供严格的安全边界，并防止数据渗漏。
路线规划中心

路由中心充当架构的中央入站点，包含以下组件：
集中式治理和安全中心

中央治理和安全中心是一个专用 Google Cloud 项目，可为整个平台提供集中式 Identity and Access Management (IAM)、日志记录、监控和安全性。此 Hub 包含以下组件：

  • Security Command Center：一项可监控整个多租户智能体 AI 系统是否存在安全风险的服务。
  • IAM：一种访问权限控制框架，用于管理共享中心和租户项目中的身份和权限。此组件可为所有人类和机器身份提供集中式治理。
  • Cloud Logging：一种将共享中心和隔离租户项目中的日志汇总到中央治理和安全中心的系统。
租户项目

每个租户项目都是一个专为每个业务单位设计的 Google Cloud 项目。各个租户项目是隔离的环境，包含以下组件：

智能体流程

上述架构中的多租户系统具有以下流程：

  1. 用户的请求通过外部应用负载平衡器进行路由。在路由中心内，系统会完成以下检查，以帮助确保只有经过身份验证的安全流量到达前端门户：
    1. Cloud Armor 会应用安全政策来吸收任何初始的基于第 4 层网络协议的分布式拒绝服务 (DDoS 攻击) 攻击。Cloud Armor 会检查请求并过滤恶意流量，例如 SQL 注入 (SQLi)、跨站脚本攻击 (XSS) 和已知的机器人签名。
    2. Model Armor 会拦截载荷，以检测并拒绝提示注入攻击或恶意意图。
    3. 如果任何一层检测到威胁或未经授权的访问，负载均衡器都会在网络边缘丢弃相应请求。
    4. 如果安全层未检测到任何威胁，并且验证了用户的访问权限，则负载均衡器会将流量路由到后端服务。
  2. 如果请求通过了所有检查，负载均衡器会将请求路由到前端平台，该平台会执行以下操作：
    1. 提取用户的身份，例如用户的业务部门或租户 ID。
    2. 使用 IAP 验证用户的公司身份和设备健康状况。
    3. 使用动态维护的注册表来确定正确的目标租户。
  3. 前端门户网站将请求路由到租户。为确保代理无法访问其他租户项目或未经授权的 Google Cloud服务，Agent Runtime 使用 PAB 政策来限制代理可访问的资源。
  4. Model Armor 使用Sensitive Data Protection来检查并动态遮盖任何个人身份信息 (PII) 或受限内容。Model Armor 会对请求中的恶意提示注入执行额外检查，以确保代理仅处理安全数据。

  5. Gemini 会执行以下任务来生成回答：

    1. 执行初始推理传递，以了解用户意图。
    2. 如果 Gemini 确定自己缺乏具体的事实，则会生成一个计划来调用租户的特定数据工具：
      1. 为了验证用户是否有权访问数据资源，代理会验证用户的身份和 IAM 角色绑定。
      2. 为了检索上下文，代理通过 MCP 服务器向租户数据存储区执行工具调用。
      3. 代理会将其内部逻辑与新检索到的特定于租户的事实相结合，从而生成有依据的回答。

    如果 Gemini 不需要其他事实，则会生成回答并将其发送给 Model Armor。

  6. Model Armor 会检查并动态屏蔽任何 PII 或受限内容，然后将清理后的回答发送给租户代理。此最终检查有助于确保输出中不会泄露任何敏感数据。

  7. 响应从租户代理通过前端平台和负载均衡器路由回用户。

使用的产品

此参考架构使用以下 Google Cloud 和开源产品及工具，这些产品和工具因其无服务器特性、可伸缩性和安全功能而被选中：

使用场景

多租户智能体 AI 系统适合希望将生成式 AI 部署扩展到单个应用之外的企业组织。如需确定此架构适合哪些使用情形，请分析您的业务流程，并确定需要自己的专用 AI 代理（可访问独特工具和敏感数据）的不同团队。这种方法可帮助您为分散式团队提供自主 AI 功能，同时保持统一的安全性和企业合规性。

以下是多租户智能体 AI 系统的用例示例。

企业级客户服务

您可以调整此参考架构，以便在不同的业务部门提供 AI 赋能的客户服务。例如，为了支持电子产品部门和家居用品部门，您可以在不同的租户项目中将电子产品智能体和家居用品智能体部署为两个单独的智能体。这些专业 AI 智能体充当智能助理，通过访问独特的技术规范、保修或退货政策来处理部门特定的支持咨询。通过自动化，人工支持团队可以专注于更复杂的客户升级问题。

在此使用情形下，该架构可提供以下优势：

  • 严格的数据隔离：多租户设计可确保每个部门的支持知识严格隔离。PAB 政策提供了一些安全措施，有助于确保一个租户中的代理身份无法访问另一个租户中的数据。
  • 专业代理知识：由于每个代理都位于隔离的租户项目中，因此代理只会从其部门特定的数据存储区检索上下文。这种有针对性的检索可确保高准确性，并防止代理混淆不同业务部门的政策。
  • 降低跨网域风险：该架构有助于消除业务部门之间的数据暴露风险。即使代理身份遭到入侵，代理也无法访问未经授权的 Google Cloud 资源。

此架构非常适合管理多个不同品牌或业务部门且需要严格的数据主权的大型零售组织和企业。

设计替代方案

本部分介绍了您可以在 Google Cloud中为多租户智能体 AI 部署考虑的其他设计方法。

专用访问通道部署

在本文档介绍的架构中，用户通过集中公开的外部应用负载平衡器，经由公共互联网访问多租户智能体 AI 系统。如果您的组织需要一个无法通过公共互联网访问的系统，则可以调整架构，以使用以下任一专用访问策略。

使用边缘安全政策阻止流量

如需仅允许来自组织已验证的企业 IP 地址的流量，您可以配置 Cloud Armor 安全政策来拒绝任何其他流量。此高优先级安全规则会在网络边缘阻止所有未经授权的请求。为了再加一道安全保障，您可以使用 IAP 来要求有效的企业身份会话，并为所有用户配置 IAM 权限。

这种方法可让您利用 Cloud Armor 边缘安全政策来分流 DDoS 攻击缓解和 WAF 过滤（例如 SQLi 和 XSS），并提供零信任体验。不过，外部应用负载平衡器的前端 IP 地址仍然是公开的，可能无法满足某些组织的合规性要求。

通过内部应用负载平衡器路由流量

本文档中的架构使用外部应用负载平衡器，与内部负载平衡器相比，该负载平衡器可提供强大的 Cloud Armor 政策、更高级的安全功能，并且操作复杂性更低。不过，使用外部负载均衡器意味着流量会通过公共互联网。

如需将流量完全保留在专用 Google 网络中，您可以使用内部应用负载平衡器。使用内部应用负载平衡器支持通过 IAP 进行身份验证。全球外部应用负载平衡器会在边缘层评估 IAP 政策。 相比之下，内部应用负载平衡器会在内部网络层评估政策。由于流量永远不会遍历公共互联网，因此使用内部应用负载平衡器有助于您满足严格的数据主权和零公共 IP 地址要求。

为了保持低延迟并遵守区域数据驻留要求，请在每个主要区域中部署一个区域级内部应用负载平衡器。借助区域级内部应用负载均衡器，您可以通过 Cloud Interconnect 或 Cloud VPN 将来自本地环境的流量直接路由到负载均衡器的内部 IP 地址。区域级内部应用负载平衡器支持区域级 Cloud Armor，以提供内部 WAF 保护。不过，与外部应用负载平衡器相比，区域级内部应用负载平衡器支持的 Cloud Armor 安全政策有限，缺少高级安全功能，并且会增加运营复杂性。

为了进一步缩短延迟时间并确保高可用性，以满足灾难恢复要求，您可以部署跨区域内部应用负载平衡器。借助跨区域内部应用负载平衡器，您可以搭配使用 Cloud DNS 和地理位置路由政策，将应用的内部网址解析为最接近用户的Google Cloud 区域中的跨区域内部应用负载平衡器。不过，跨区域配置不支持任何 Cloud Armor 集成。

计算基础架构

为了优先采用无服务器优先的方法，以便更轻松地进行管理并降低运营开销，本文档中的架构使用 Cloud Run 作为其计算基础设施。您还可以在 GKE 集群上运行容器化应用。Google Kubernetes Engine (GKE) 是一种容器编排引擎，可自动执行容器化应用的部署、伸缩和管理。GKE 完全支持内部和外部应用负载平衡器。如需了解如何为 Google Cloud上的工作负载选择计算服务，请参阅在Google Cloud上托管应用。

Model Context Protocol (MCP) 服务器

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

如需将租户代理连接到数据存储区，请根据应用要求从以下 MCP 服务器部署选项中进行选择。在选择本地 MCP 部署和共享 MCP 部署时，请考虑数据隔离和运营效率之间的权衡取舍。

  • 本地 MCP 服务器：本地 MCP 服务器或租户专用 MCP 服务器是指您在每个租户项目中部署的 MCP 服务器，可让代理访问特定于相应业务部门的数据存储区和工具。

    以下是本地 MCP 服务器的主要功能和注意事项：

    • 网络：项目级 VPC Service Controls 边界和 PAB 政策可提供固有的安全性和隔离性，有助于确保不会发生跨租户访问。
    • 管理：各个开发者和运维团队独立管理租户项目。这种隔离可为每个业务部门提供自主权。
    • 安全性：租户项目的固定 IAM 边界有助于最大限度地减少横向风险面，并且不需要复杂的身份映射。

    本地 MCP 服务器可提供最大程度的隔离，并且可以处理高度敏感或受监管的数据访问权限。不过，如果您部署多个本地 MCP 服务器，则会增加运营负荷。对于需要严格限制对可能包含敏感信息的数据库的访问权限的应用，我们建议使用本地 MCP 服务器。

  • 共享 MCP 服务器：共享 MCP 服务器（也称为全局 MCP 服务器）是指您在共享服务项目中部署的 MCP 服务器。共享 MCP 服务器可提供对多个租户共用的工具和系统的访问权限。

    以下是共享 MCP 服务器的主要功能和注意事项：

    • 网络：为确保流量不会遍历公共互联网，共享 MCP 服务器需要专用连接，例如 Private Service Connect 或 VPC 网络对等互连。
    • 管理：集中式运营团队负责管理整个系统的实施。这种整合式管理可优化运营效率，并消除了在多个租户中重复本地实现的需求。
    • 安全性：您可以安全地将最终用户身份从租户项目中的代理传播到共享 MCP 服务器。为了帮助确保用户只能访问或修改他们有权访问或修改的数据，共享 MCP 服务器使用传播的用户身份在后端系统上强制执行精细的访问权限控制。

    共享 MCP 服务器可集中管理常用工具，从而减少重复并优化运营效率。虽然共享 MCP 服务器可减少管理开销，但需要强大的身份传播和授权逻辑来维持安全访问。我们建议使用共享 MCP 服务器来与常见的公司系统和工具（例如费用报告工具、人力资源 (HR) 系统、公司范围内的知识库或考勤管理系统）进行互动。

在此架构中，您可以使用 MCP 服务器来标准化租户代理与数据存储区之间的连接。根据工作负载要求，您可以使用其他类型的代理工具将代理与特定的外部 API 和系统相关联。如需详细了解代理工具互动，请参阅代理工具。

设计考虑事项

以下部分介绍了一些设计因素、最佳实践和建议，您在使用此参考架构开发满足特定安全性、可靠性、费用和性能要求的拓扑时应考虑这些内容。本部分中的指导并非详尽无遗。根据工作负载的要求以及您使用的产品和功能，您可能还需要考虑其他设计因素和权衡因素。

安全性、隐私权和合规性

本部分介绍了设计注意事项和建议，可帮助您在 Google Cloud 中设计满足工作负载的安全性、隐私权和合规性要求的拓扑。

组件 设计注意事项和建议
Virtual Private Cloud (VPC) 租户隔离：在此架构中，您可以在专用 Google Cloud 项目中部署每个租户。如需创建严格的安全边界，请将租户项目级隔离与组织级 PAB 政策和 VPC Service Controls 相结合。
IAM 访问权限控制：为了实现最小权限原则，请使用基于角色的访问权限模型。例如，您可以定义自定义 IAM 角色，以确保在一个租户中构建代理的开发者无法访问另一个租户中的数据。
Cloud Armor

边缘和内部 WAF 防护：Cloud Armor 提供安全和 WAF 防护，以防御前端门户免受 DDoS 攻击和 Web 漏洞的侵害。全球外部应用负载平衡器支持全套高级边缘功能，例如机器人管理和 Google Cloud Armor 自适应防护。

如果您部署区域级内部应用负载平衡器，则 Cloud Armor 会使用一组受限的标准 WAF 政策运行。受限政策集是针对内部网络边界量身定制的，其中包括 SQLi 和 XSS 保护等政策。如需了解详情，请参阅将 Cloud Armor 与其他 Google 产品集成。
Agent Platform

共享模型端点：为防止滥用并确保公平使用共享模型端点，请实施以下策略之一：

  • 租户级速率限制：在请求到达共享端点之前，在前端门户中为每个租户强制执行配额。通过执行以下操作来强制执行配额：
    1. 从 IAP 上下文中提取租户身份。
    2. 使用外部存储区（例如 Memorystore for Redis）跟踪每个租户的用量是否超出预定义限额。
    3. 拒绝来自超出限额的租户的请求。
  • API Gateway：如需使用 API 密钥和使用情况方案来强制执行租户级配额，请在共享端点之前实现 API Gateway。
Cloud Run

内容渲染：为了增强前端门户的安全性，请优先考虑使用服务器端渲染 (SSR)，而不是客户端渲染 (CSR)。与 CSR 相比，SSR 具有以下优势：

  • 在受控的 Google Cloud 环境中执行应用逻辑并管理密钥。
  • 减少客户端攻击面，并防止敏感数据泄露到用户的不受信任的浏览器。
  • 通过仅向客户端发送必要的 HTML 来限制数据暴露。
  • 提供集中式输出编码，以防御跨站脚本攻击 (XSS)。
Security Command Center 集中式安全监控：如需监控威胁并强制执行安全政策（例如多重身份验证 [MFA] 和数据加密），请使用Security Command Center中的工具。

更多安全建议

可靠性

本部分介绍在 Google Cloud中为部署构建和运营可靠的基础设施时应考虑的设计因素和建议。

组件 设计注意事项和建议
Cloud Load Balancing 全球路由：全球外部应用负载平衡器提供单个 Anycast IP 地址，可自动将用户流量路由到地理位置上最近的 Google 边缘。此配置通过边缘 Secure Sockets Layer (SSL) 终止来缩短延迟时间。此外，如果某个区域发生服务中断，它还会智能地将流量重新路由到健康状况良好的区域后端，从而确保高可用性。
租户 容错：为了容忍或处理代理级故障，请在隔离的租户项目中部署代理。这种隔离有助于确保运营问题或安全事件仅限于单个业务部门，而不会影响其他资源或业务部门。
Agent Platform 容量规划：如果对模型的请求数量超出分配的容量，则模型会返回错误代码 429。对于业务关键型且需要持续高吞吐量的工作负载，您可以使用预配吞吐量来预留吞吐量。
Agent Runtime

无服务器可伸缩性：部署在 Agent Runtime 上的智能体可根据需求独立扩缩。一个租户的用量突然激增不会耗尽计算资源，也不会影响另一个租户项目中的代理可用性。

错误处理：为了处理暂时性错误（例如错误代码 429 速率限制），代理编排逻辑使用指数退避。如果超出上下文截止时间，则智能体会执行安全关停，并向用户报告部分进度。例如，由于工具调用缓慢、第三方 API 延迟、处理海量数据集或计算密集型处理，可能会超出上下文截止时间。

如需了解特定于 AI 和机器学习工作负载的可靠性原则和建议，请参阅 Well-Architected Framework 中的 AI 和机器学习视角：可靠性。

运营效率

本部分介绍使用此参考架构设计可高效运营的 Google Cloud 拓扑时应考虑的因素。

组件 设计注意事项和建议
Google Cloud Observability 集中式监控：借助 Logging 和 Monitoring，您可以监控整个平台的健康状况和性能。您可以设置提醒，以便主动检测和排查问题，而无需允许访问敏感数据。
架构中的所有产品 标准化部署：在标准化租户架构模式中使用代理平台，可在新租户加入时建立一致的基准。为了减轻运营负担，请使用 Infrastructure as Code (IaC) 工具（如 Terraform）自动执行部署流程。如需查看可用于构建和部署多租户智能体 AI 系统的 Terraform 代码，请参阅本文档的部署部分。

如需了解特定于 AI 和机器学习工作负载的卓越运营原则和建议，请参阅 Well-Architected Framework 中的 AI 和机器学习视角：卓越运营。

费用优化

本部分将指导您优化您使用此参考架构构建的 Google Cloud 拓扑的设置和操作费用。

组件 设计注意事项和建议
Agent Platform

词元消耗：为了控制费用并防止 AI 模型超出上下文窗口，请使用以下策略来管理 AI 模型的上下文：

  • 上下文总结：不将整个会话对话保存为上下文，而是使用 AI 模型总结较旧的对话和不太重要的信息。
  • 精简输出： 识别并移除工具输出或检索到的上下文信息中不太相关或过于冗长的部分。例如，如果您只需要数据中的列名称，可以从数据库架构提取中移除过多的元数据。 此策略需要使用启发式方法、过滤或小语言模型 (SLM) 来提取最重要信息的自定义逻辑。
  • token 上限：为防止无限循环并帮助控制费用，强制执行会话 token 上限。

模型端点：为了管理 API 配额和资源利用率，您可以采用专用配置或共享配置来部署 Agent Platform 端点：

  • 专用端点：在每个租户项目中部署端点时，您会提供固有的配额隔离。每个租户的用量都会计入其自己的项目配额，从而避免租户间相互影响。 与共享端点相比，专用端点可简化配额管理。不过，专用端点会使您无法享受共享端点可能带来的成本节省。
  • 共享端点：为了优化成本，您可以在中央治理和安全中心托管共享端点。由于所有租户共享相同的配额池，为防止恶意攻击，您必须实施缓解策略，例如使用 API Gateway 进行租户级速率限制或配额强制执行。与专用端点相比，共享端点更经济实惠。不过，共享端点需要付出额外的工程资源，并且可能会导致延迟和管理开销。

如需了解 Agent Platform 上的费用，请参阅 Agent Platform 中构建和部署 AI 模型的费用。
Cloud Run 插桩：插桩可让您监控性能、排查问题，以及跟踪每个租户的资源使用情况。为了确定每个请求的租户，请从 IAP 提供的上下文中提取用户身份。如需了解如何对应用进行插桩，请参阅选择插桩方法。
Model Armor 集中式提示过滤：为了实施严格的治理和零信任安全态势，此架构在两个层级部署了 Model Armor：在路由 hub 中和每个租户项目内。虽然这种双层方法有助于确保数据主权，但会增加延迟和运营成本。为了降低成本和系统复杂性，请仅在路由中心部署 Model Armor，以过滤所有提示和回答。
架构中的所有产品

共享基础设施：与为每个代理构建单独的自定义堆栈相比，共享核心基础设施组件（例如前端门户、中央治理和安全中心以及 Agent Platform）可以降低成本。

平台开销：为了分摊中央治理和安全中心的共享费用，请使用适合您的跟踪能力和使用模式的分配模型。我们建议您使用以下任一费用分摊模型：

  • 平均分配：平均分配模型会将共享费用平均分配给所有租户。如果平台是基本实用程序，或者细化跟踪的开销超过了成本效益，请使用此模型。
  • 按比例分配：按比例分配模型或费用返还流程会根据每个租户产生的直接费用比例来分配共享费用。如果租户消耗量差异很大，并且您拥有强大的遥测功能（例如 Resource Manager 标签和日志解析），可以准确归因费用，请使用此模型。
  • 固定分配：固定或分层模型会根据业务定义的系数分配共享费用。 如果租户需要不同的服务等级协议 (SLA)，请使用此模型。采用固定模式分配时，您可以针对高级专用功能收取固定费率，而不是标准共享功能。

如需详细了解如何分配共享服务费用，请参阅 Cloud FinOps：共享服务费用分配。

集中式费用管理：如需准确跟踪智能体 AI 系统的总拥有成本 (TCO)，并将费用归因于各个业务部门，请使用标签和 Cloud Billing 导出数据。如需详细了解如何使用标签来培养费用意识，请参阅培养费用意识文化。

如需估算 Google Cloud 资源的费用，请使用Google Cloud 价格计算器。

如需了解特定于 AI 和机器学习工作负载的费用优化原则和建议，请参阅 Well-Architected Framework 中的AI 和机器学习视角：费用优化。

部署

如需部署此参考架构，请使用 GitHub 中提供的多租户智能体 AI Terraform 示例。

后续步骤

贡献者

作者：

其他贡献者：