多租戶代理式 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 專案，可為整個平台提供集中式身分與存取權管理 (IAM)、記錄、監控和安全防護。這個中樞包含下列元件：

  • 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 會檢查並動態遮蓋任何個人識別資訊或受限內容，然後將經過清理的回覆傳送給租戶代理程式。這項最終檢查可確保輸出內容不會洩漏任何私密資料。

  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 伺服器的重要功能和注意事項：

    • 網路：專案層級的 VPC Service Controls perimeter 和 PAB 政策提供固有的安全性和隔離功能，有助於確保不會發生跨租戶存取。
    • 管理：個別開發人員和營運團隊可獨立管理房客專案。這種隔離方式可讓每個業務單位享有自主權。
    • 安全性：租戶專案的固定 IAM 邊界有助於盡量縮小橫向風險面，且不需要複雜的身分對應。

    本機 MCP 伺服器可提供最高程度的隔離，並處理高度機密或受監管的資料存取權。不過，如果部署多個本機 MCP 伺服器，就會增加作業負載。如果應用程式需要限制對資料儲存區的存取權，而這些儲存區可能含有私密資訊，建議使用本機 MCP 伺服器。

  • 共用 MCP 伺服器：共用 MCP 伺服器或全域 MCP 伺服器，是指您在共用服務專案中部署的 MCP 伺服器。共用 MCP 伺服器可存取多個房客通用的工具和系統。

    以下是共用 MCP 伺服器的主要功能和注意事項：

    • 網路：為確保流量不會經過公開網際網路，共用 MCP 伺服器需要私人連線，例如 Private Service Connect 或 VPC Network Peering。
    • 管理：集中式作業團隊負責管理整個系統的實作程序。集中管理可提升作業效率，且不必在多個租戶中重複實作本機設定。
    • 安全性：您可以安全地將租戶專案中代理程式的使用者身分，傳播至共用 MCP 伺服器。為確保使用者只能存取或修改獲准的資料，共用的 MCP 伺服器會使用傳播的使用者身分，在後端系統上強制執行精細的存取控管措施。

    共用 MCP 伺服器可集中管理常用工具，減少重複作業並提升作業效率。雖然共用 MCP 伺服器可減少管理負擔，但需要健全的身分傳播和授權邏輯，才能維持安全存取。建議您使用共用的 MCP 伺服器，與常見的公司系統和工具互動，例如費用回報工具、人力資源 (HR) 系統、全公司知識庫或出席管理員。

在這個架構中，您會使用 MCP 伺服器，標準化租戶代理和資料存放區之間的連線。視工作負載需求而定，您可能會使用其他類型的代理工具，將代理與特定外部 API 和系統連結。如要進一步瞭解代理程式工具互動，請參閱「代理程式工具」。

設計須知

以下章節將說明設計因素、最佳做法和建議，供您參考這些資訊開發拓撲，以滿足安全性、可靠性、成本和效能方面的特定需求。本節的指引僅列出部分範例。視工作負載需求和使用的產品與功能而定，您可能還需要考量其他設計因素和取捨。

安全性、隱私權和法規遵循

本節將說明設計拓撲時的考量事項和建議，以符合工作負載的安全、隱私權和法規遵循需求。 Google Cloud

元件 設計注意事項和建議
虛擬私有雲 (VPC) 租戶隔離：在這個架構中，您會在專屬 Google Cloud 專案中部署每個租戶。如要建立嚴格的安全邊界，請在機構層級結合租戶專案層級隔離、PAB 政策和 VPC Service Controls。
IAM 存取控管：如要實作最小權限原則，請使用以角色為基礎的存取模式。舉例來說，您可以定義自訂 IAM 角色，確保在一個租戶中建構代理程式的開發人員，無法存取另一個租戶中的資料。
Cloud Armor

邊緣和內部 WAF 防護： Cloud Armor 提供安全防護和 WAF 防護，可防範 DDoS 攻擊和網路安全漏洞，保護前端入口網站。全域外部應用程式負載平衡器支援全套進階邊緣功能，例如機器人管理和 Google Cloud Armor 適應性防護。

如果您部署區域性內部應用程式負載平衡器，Cloud Armor 會使用一組受限的標準 WAF 政策運作。這組受限政策專為內部網路邊界量身打造，包括 SQLi 和 XSS 防護等政策。詳情請參閱「整合 Cloud Armor 與其他 Google 產品」。
Agent Platform

共用模型端點：為防止濫用行為，並確保共用模型端點的公平使用，請實作下列其中一項策略：

  • 租戶層級的頻率限制：在前端入口網站中，為每個租戶強制執行配額，避免要求抵達共用端點。如要強制執行配額，請完成下列步驟：
    1. 從 IAP 情境中擷取租戶 ID。
    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 邊緣。這項設定可透過邊緣安全資料傳輸層 (SSL) 終止，縮短延遲時間。此外，如果某個區域發生服務中斷問題，系統會將流量重新導向至運作正常的區域後端，確保高可用性。
用戶群 容錯：如要容許或處理代理程式層級的故障，請在獨立的租戶專案中部署代理程式。這種隔離措施可確保營運問題或安全事件不會影響其他資源或業務單位，只會發生在單一業務單位內。
Agent Platform 容量規劃：如果對模型發出的要求數量超過分配的容量，模型會傳回錯誤代碼 429。對於需要持續高處理量的重要業務工作負載，您可以使用「佈建輸送量」預留輸送量。
Agent Runtime

無伺服器擴充性：部署在 Agent Runtime 的代理會根據需求獨立調度資源。即使某個租戶的用量突然暴增，也不會耗盡運算資源，或影響其他租戶專案中代理程式的可用性。

錯誤處理：為處理暫時性錯誤 (例如錯誤代碼 429 速率限制)，代理程式協調邏輯會使用指數輪詢。如果超過內容期限，代理程式會正常關機，並向使用者回報部分進度。舉例來說，工具呼叫速度緩慢、第三方 API 延遲、處理大量資料集或需要大量運算資源的處理作業，都可能導致超過內容期限。

如要瞭解 AI 和機器學習工作負載專用的可靠性原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：可靠性」。

提升作業效率

本節說明使用這項參考架構設計拓撲時，需要考量的因素，以便有效率地運作。 Google Cloud

元件 設計注意事項和建議
Google Cloud Observability 集中式監控：透過 Logging 和 Monitoring，您可以監控整個平台的健康狀態和效能。您可以設定快訊，主動偵測及排解問題，不必存取敏感資料。
本架構中的所有產品 標準化部署：在標準化租戶架構模式中使用 Agent Platform，可讓您在導入新租戶時，建立一致的基準。為減輕作業負擔，請使用 Terraform 等基礎架構即程式碼 (IaC) 工具，自動執行部署程序。如要瞭解如何使用 Terraform 程式碼建構及部署多租戶代理式 AI 系統，請參閱本文的「部署」一節。

如要瞭解 AI 和機器學習工作負載的卓越營運原則和建議，請參閱 Well-Architected Framework 中的「AI and ML perspective: Operational excellence」。

成本最佳化

本節提供指引，說明如何盡量降低設定及運作 Google Cloud 拓撲的成本。您可使用本參考架構建構拓撲。

元件 設計注意事項和建議
Agent Platform

詞元消耗量：如要控管費用，並避免 AI 模型超出脈絡視窗，請使用下列策略管理 AI 模型的脈絡：

  • 摘要對話內容：不必將整個工作階段的對話儲存為背景資訊，而是使用 AI 模型摘要較舊的對話和不重要的資訊。
  • 刪除輸出內容： 找出並移除工具輸出內容或擷取內容中較不相關或冗長的部分。舉例來說，如果您只需要資料中的欄名，可以從資料庫結構定義擷取中移除過多的中繼資料。這項策略需要自訂邏輯，使用啟發式方法、篩選或小型語言模型 (SLM) 擷取最重要的資訊。
  • 權杖上限：為避免無限迴圈並控管費用，請強制執行工作階段權杖上限。

模型端點：如要管理 API 配額和資源用量，您可以透過專用設定或共用設定部署 Agent Platform 端點：

  • 專屬端點：在每個租戶專案中部署端點時，您會提供固有的配額隔離。每個房客的用量都會計入各自的專案配額，避免房客間相互影響。相較於共用端點，專屬端點可簡化配額管理作業。不過，專屬端點會導致您無法享有共用端點的潛在成本節省優勢。
  • 共用端點：為盡量降低成本，您可以在中央控管和安全中心代管共用端點。由於所有租戶共用相同的配額集區，為防範惡意攻擊，您必須實作緩解策略，例如透過 API 閘道強制執行租戶層級的頻率限制或配額。相較於專屬端點，共用端點的成本效益較高。不過，共用端點需要額外的工程工作，而且可能會導致延遲和管理負擔。

如要瞭解 Agent Platform 的費用，請參閱「在 Agent Platform 中建構及部署 AI 模型的費用」。
Cloud Run 檢測：檢測可讓您監控效能、疑難排解問題，以及追蹤每個租戶的資源用量。如要找出每個要求的租戶，請從 IAP 提供的內容中擷取使用者身分。如要瞭解如何檢測應用程式，請參閱「選擇檢測方法」。
Model Armor 集中式提示篩選：為落實嚴格的治理措施和零信任安全狀態，這項架構會在兩個層級部署 Model Armor：在路由中樞和每個租戶專案中。雖然這種雙層做法有助於確保資料主權，但會增加延遲時間和營運成本。如要降低成本和系統複雜度，請只在路由中心部署 Model Armor，篩選所有提示詞和回覆。
本架構中的所有產品

共用基礎架構：共用核心基礎架構元件 (例如前端入口網站、中央控管和安全中心，以及 Agent Platform)，可降低成本，相較於為每個代理程式建立個別的自訂堆疊，更具成本效益。

平台額外負荷：如要分配中央控管和安全中心的分攤費用，請使用符合追蹤功能和使用模式的分配模型。建議您使用下列其中一種成本分配模型：

  • 平均分配配置：平均分配模式會將共用費用平均分配給所有房客。如果平台是基本公用程式，或是細部追蹤的負擔超過成本效益，請使用這個模型。
  • 按比例分配：按比例模式或費用退還程序會根據每個租戶產生的直接費用比例，分配共用費用。如果租戶用量差異極大，且您有健全的遙測功能 (例如 Resource Manager 標籤和記錄剖析)，可準確歸因成本，請使用這個模型。
  • 固定分配：固定或分層模型會根據業務定義的係數分配共用成本。如果房客需要不同的服務水準協議 (SLA)，請使用這個模型。固定模型分配可讓您針對進階專屬功能收取固定費率，而非標準共用功能。

如要進一步瞭解如何分配共用服務費用，請參閱「雲端 FinOps：共用服務費用分配」。

集中管理成本：如要準確追蹤代理式 AI 系統的總持有成本 (TCO)，並將成本歸因於個別業務單位，請使用標籤和 Cloud Billing 匯出資料。如要進一步瞭解如何使用標籤掌握費用，請參閱「培養費用意識文化」一文。

如要估算 Google Cloud 資源的費用，請使用 Google Cloud Pricing Calculator。

如要瞭解 AI 和機器學習工作負載專用的成本最佳化原則和建議，請參閱 Well-Architected Framework 中的「AI 和機器學習觀點：成本最佳化」。

部署作業

如要部署這個參考架構，請使用 GitHub 中提供的多租戶代理式 AI Terraform 範例。

後續步驟

貢獻者

作者：

其他貢獻者：