多租戶代理式 AI 系統

Last reviewed 2026-10-16 UTC

本文件提供參考架構，協助您在 Google Cloud上設計及部署多租戶代理式 AI 系統。隨著組織擴大生成式 AI 部署，不同的業務單位需要專門的 AI 代理，才能存取獨特工具、遵循特定作業規則，以及處理機密資料。業務單位可能會在組織內開發分散的應用程式孤島，導致高昂的營運負擔、嚴重的管理落差，以及資料外洩風險。本架構說明如何建構集中式系統，讓分散式團隊能自主運用 AI 功能，同時維持統一的安全性和法規遵循。

這份文件的目標對象包括架構師、開發人員和管理員，他們負責在雲端建構及管理企業級多代理系統。本文件假設您已具備 AI、機器學習和LLM概念，以及代理式 AI 的基礎知識。

本文的部署一節提供實作策略，協助您建構及部署多租戶代理式 AI 系統。

架構

下圖顯示多租戶代理式 AI 系統的架構，採用中樞與輪輻模型。軸輻式模型是一種網路設計，其中中央環境 (稱為「中樞」) 會連線至多個獨立環境 (稱為「輪輻」)。

多租戶代理式 AI 系統架構。

這個架構包含下列元件：

VPC Service Controls
這個架構使用 VPC Service Controls，在組織層級設定 service perimeter。這個 service perimeter 提供嚴格的安全邊界，有助於防止資料竊取。
轉送中樞

轉送中樞是架構的中央輸入點，包含下列元件：

集中式管理和安全中心

中央管理和安全中心是專屬的 Google Cloud專案，可為整個平台提供集中式 Identity and Access Management (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 會檢查並動態遮蓋任何 PII 或限制內容，然後將經過清理的回覆傳送給租戶代理。這項最終檢查有助於確保輸出內容不會洩漏機密資料。

  7. 回應會從租戶代理程式，依序透過前端平台和負載平衡器，傳回給使用者。

使用的產品

這個參考架構使用下列 Google Cloud 和開放原始碼產品和工具，這些產品和工具因其無伺服器性質、擴充性和安全性功能而獲選：

  • VPC Service Controls：代管網路功能，可盡量降低 Google Cloud 資源的資料竊取風險。
  • Cloud Load Balancing：高效能、可擴充的全球和區域負載平衡器組合。
  • Google Cloud Armor：這項網路安全服務提供網頁應用程式防火牆 (WAF) 規則，可協助防範 DDoS 和應用程式攻擊。
  • Model Armor：這項服務可保護生成式和代理式 AI 資源，防範提示詞注入、敏感資料外洩和有害內容。
  • Identity-Aware Proxy (IAP)：這項服務可為應用程式和虛擬機器啟用零信任存取模型。
  • Identity and Access Management (IAM)：這個系統可讓您建立及管理 Google Cloud 資源的權限。
  • Cloud Run：無伺服器運算平台，可讓您直接在 Google 可擴充的基礎架構上執行容器。
  • Gemini Enterprise Agent Platform：全方位平台，可建構、擴充、管理及最佳化企業級 AI 代理。
  • Gemini：Google 開發的多模態 AI 模型系列。
  • Model Context Protocol (MCP)：開放原始碼標準，用於將 AI 應用程式連結至外部系統。
  • Cloud Logging：即時記錄管理系統，提供儲存、搜尋、分析和警告通知功能。

用途

多租戶代理式 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上代管應用程式」。

本機和共用 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 或虛擬私有雲網路對接。
    • 管理：由集中式營運團隊管理整個系統的實作。這種整合式管理方式可提高作業效率，且不必在多個租戶中重複執行本機實作。
    • 安全性：您會安全地將使用者身分從租戶專案中的代理，傳播至共用 MCP 伺服器。為確保使用者只能存取或修改有權限的資料，共用 MCP 伺服器會使用傳播的使用者身分，在後端系統強制執行精細的存取控管。

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

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

設計須知

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

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

本節說明設計考量和建議，協助您在 Google Cloud 中設計符合工作負載安全性、隱私權和法規遵循需求的拓撲。

代理的安全性考量

AI 代理會帶來某些獨特且嚴重的安全風險，傳統的確定性安全做法可能無法充分降低這些風險。Google 建議採用安全 AI 代理的做法，結合確定性安全控管措施和動態推論防禦機制的優勢。這項做法基於三項核心原則：人類監督、明確定義代理自主權，以及可觀測性。以下是符合這些核心原則的具體建議：

  • 人工監督：代理式 AI 系統有時可能會失敗或未如預期運作。例如，模型可能會生成不準確的內容，或代理可能會選取不適當的工具。在業務關鍵的代理式 AI 系統中，請加入人工介入迴路流程，讓人類監督者監控、覆寫及暫停代理。例如，人類使用者可以審查代理的輸出內容、核准或拒絕輸出內容，並提供進一步指引來修正錯誤或制定策略決策。這種做法結合了代理式 AI 系統的效率，以及人類使用者的批判性思考和領域專業知識。
  • 代理身分和最小權限存取權：

  • 輸入和輸出流量管理：透過 Agent Gateway 轉送代理流量，在輸入和輸出邊界強制執行執行階段安全性政策。如要瞭解支援 Agent Gateway 的 Agent Runtime 平台，請參閱「支援的 Agent Runtime」。

    • 用戶端至代理 (輸入)：在 Agent Runtime 前方部署 Agent Gateway。閘道會使用 Model Armor 驗證呼叫端，並即時檢查傳入的提示。

    • 代理至任意目的地 (輸出)：

      • 在輸出模式下，透過 Agent Gateway 轉送傳出的代理對代理 (A2A) 和代理對工具 (MCP) 要求。
      • 使用 IAM 存取政策和 IAP，強制執行預設拒絕存取政策。
      • 確認目標代理和工具已在 Agent Registry 中註冊。
      • 使用 Model Armor 檢查傳出的工具叫用和回覆，防止資料竊取、間接提示詞注入和工具濫用。

  • 監控：運用全方位追蹤功能監控代理行為，清楚掌握代理採取的每個動作，包括推論過程、工具選擇和執行路徑。詳情請參閱「在 Agent Runtime 中記錄代理」和「在 ADK 中記錄」。

如要進一步瞭解如何保護 AI 代理，請參閱「AI 代理的安全防護」。

虛擬私有雲 (VPC) 安全性考量

在這種架構中，您會在專屬的Google Cloud 專案中部署每個租戶。如要建立嚴格的安全邊界，請將租戶專案層級隔離與組織層級的 PAB 政策和 VPC Service Controls 結合。

IAM 安全性考量

如要實施最小權限原則，請使用角色型存取權模型。舉例來說，您可以定義自訂 IAM 角色，確保在某個租戶中建構代理的開發人員，無法存取其他租戶中的資料。

Cloud Armor 安全性考量

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

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

Agent Platform 安全性考量

為確保 Agent Platform 設定和使用方式符合安全性需求，請考慮下列建議：

  • 共同責任：維護安全是共同的責任。Agent Platform 可保護基礎架構，並提供工具和安全控管機制，協助您保護資料、程式碼和模型。您必須負責正確設定服務、管理存取控管機制，以及保護應用程式。詳情請參閱「Agent Platform 共同責任」。
  • 安全控管：Agent Platform 支援 Google Cloud 安全控管，可滿足資料落地、客戶自行管理的加密金鑰 (CMEK)、使用 VPC Service Controls 控管網路安全，以及資料存取透明化控管機制等需求。詳情請參閱下列說明文件：
  • 安全性：AI 模型可能會產生有害的回覆，有時是為了回應惡意提示。
    • 為提升安全性並降低代理式 AI 系統遭濫用的風險，您可以設定內容篩選器，阻擋有害的輸入內容和回覆。詳情請參閱「安全和內容篩選器」。
    • 如要檢查及清理推論要求、代理提示詞、工具呼叫和回覆，防範提示詞注入和有害內容等威脅，您可以透過 Model Armor 直接呼叫模型 API，以及處理透過 Agent Gateway 轉送的要求。Model Armor 可協助您防範惡意輸入、驗證內容安全性、保護敏感資料、維持法規遵循，以及一致地強制執行安全和資安政策。
  • 模型存取權：您可以設定組織政策，限制 Google Cloud 專案中可使用的 AI 模型類型和版本。詳情請參閱「控管 Model Garden 模型的存取權」。
  • 資料保護：如要探索提示、回覆和記錄資料中的機密資料，並進行去識別化，請使用 Cloud Data Loss Prevention API。詳情請觀看這部影片：保護 AI 應用程式中的機密資料。

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

    • 租戶層級頻率限制：在要求到達共用端點之前，在前端入口網站中為每個租戶強制執行配額。請按照下列步驟強制執行配額：

      1. 從 IAP 情境中擷取租戶身分。
      2. 使用 Memorystore for Redis 等外部儲存庫，追蹤每個租戶的用量是否超出預先定義的限制。
      3. 拒絕超出限制的租戶要求。

    • API Gateway：如要使用 API 金鑰和用量方案強制執行各租戶配額，請在共用端點前實作 API Gateway。

MCP 安全性考量

為確保 MCP 實作符合安全性需求，請考慮下列建議：

  • 工具註冊與探索：在 Agent Registry 中註冊 MCP 伺服器和工具，確保代理只會連線至已列入清單且經管理員核准的 MCP 端點。
  • 存取控管和流量檢查：在「代理到任何位置 (輸出)」模式下，透過 Agent Gateway 轉送代理到 MCP 的流量，並使用 IAP 和 IAM 存取權政策，保護 MCP 伺服器 (例如託管於 Cloud Run 的 MCP 伺服器)。在 Agent Gateway 設定 Model Armor 或語意管理政策，檢查 MCP 工具輸入和輸出內容，防範敏感資料外洩和間接提示詞注入。
  • 一般 MCP 安全性：設定代理使用 MCP 時，請確保外部資料和工具的存取權已獲授權、實施加密等隱私權控制項、套用篩選器保護機密資料，以及監控代理互動。詳情請參閱「MCP 和安全性」。

Cloud Run 安全性考量

如要強化前端入口網站的資安態勢，請優先採用伺服器端算繪 (SSR)，而非用戶端算繪 (CSR)。與 CSR 相比，SSR 有以下優點：

  • 在受控的Google Cloud 環境中執行應用程式邏輯及管理密鑰。
  • 減少用戶端攻擊面，並防止機密資料外洩至使用者不受信任的瀏覽器。
  • 只將必要的 HTML 傳送至用戶端，限制資料曝光。
  • 提供集中式輸出編碼，防範跨網站指令碼攻擊 (XSS)。

Security Command Center 安全性考量

如要監控威脅並強制執行多重驗證 (MFA) 和資料加密等安全性政策，請使用 Security Command Center 中的工具。

更多安全性建議

可靠性

本節說明設計考量和建議，協助您在 Google Cloud中建構及運作可靠的基礎架構。

Cloud Load Balancing 可靠性注意事項

全域外部應用程式負載平衡器提供單一任意傳播 IP 位址，可自動將使用者流量轉送至地理位置最近的 Google 邊緣。這項設定會透過邊緣安全資料傳輸層 (SSL) 終止來縮短延遲時間。如果某個區域發生服務中斷，這項功能還能以智慧方式將流量重新轉送至健康狀態良好的區域性後端，確保高可用性。

租戶可靠性考量

如要容許或處理代理層級的故障，請在獨立的租戶專案中部署代理。這種隔離機制有助於確保營運問題或安全事件僅限於單一業務單位，不會影響其他資源或業務單位。

Agent Platform 可靠性考量

如果模型收到的要求數量超過分配的容量，模型會傳回錯誤代碼 429。如果工作負載對業務至關重要，且需要持續高處理量，您可以使用佈建輸送量預留處理量。

Agent Runtime 可靠性考量

為確保 Agent Runtime 設定和用量符合可靠性需求，建議您採取下列做法：

  • 無伺服器擴充性：部署在 Agent Runtime 的代理會根據需求獨立擴充。某個租戶的用量突然暴增，不會耗盡運算資源，也不會影響其他租戶專案中代理的可用性。
  • 錯誤處理：為處理暫時性錯誤 (例如錯誤代碼 429 頻率限制)，代理協調邏輯會使用指數輪詢。如果超過情境期限，代理會正常關機，並向使用者回報部分進度。舉例來說，工具呼叫速度緩慢、第三方 API 延遲、處理大量資料集，或需要大量運算資源的處理作業，都可能導致 context deadline exceeded。

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

提升作業效率

本節說明使用這個參考架構設計可有效運作的 Google Cloud 拓撲時，應考量的因素。

Google Cloud Observability 考量事項

Logging 和 Cloud Monitoring 可讓您監控整個平台的健康狀態和效能。您可以設定快訊，主動偵測及排解問題，不必授予機密資料存取權。

架構中所有產品的作業效率考量

在標準化租戶架構模式中使用 Agent Platform，可讓您在加入新租戶時建立一致的基準。為減輕營運負擔，請使用 Terraform 等基礎架構即程式碼 (IaC) 工具，自動執行部署程序。如需可用於建構及部署多租戶代理式 AI 系統的 Terraform 程式碼，請參閱本文的「部署」一節。

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

成本最佳化

本節提供指引，說明如何降低使用這項參考架構建構及操作 Google Cloud 拓撲的成本。

Agent Platform 費用考量

為確保 Agent Platform 設定和用量符合成本要求，建議您採取下列做法：

  • 詞元消耗量：為管理成本並防止 AI 模型超出脈絡窗口，請採用下列策略管理 AI 模型的脈絡：
    • 內容摘要：使用 AI 模型總結較舊的對話和較不重要的資訊，而非將整個工作階段對話儲存為內容。
    • 精簡輸出內容：找出並移除工具輸出內容或檢索到的背景資訊中，關聯性較低或冗長的部分。舉例來說，如果您只需要資料中的資料欄名稱，可以從資料庫結構定義擷取作業中移除過多的中繼資料。這項策略需要自訂邏輯，使用啟發法、篩選或小型語言模型 (SLM) 擷取最重要的資訊。
    • 詞元數量上限：為避免無限迴圈並控管成本，請強制執行工作階段詞元數量上限。

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

    • 專用端點：在各個租戶專案中部署端點時，系統會提供固有的配額隔離。每個租戶的用量都會計入各自的專案配額，避免租戶之間相互影響。與共用端點相比，專屬端點的配額管理更簡單。不過，專用端點無法讓您享有共用端點可能帶來的成本節省效益。
    • 共用端點：如要盡可能降低成本，您可以在中央管理和安全中心託管共用端點。由於所有租戶共用相同的配額集區，為防範惡意攻擊，您必須實施緩解策略，例如租戶層級的頻率限制，或透過 API Gateway 強制執行配額。與專屬端點相比，共用端點更具成本效益。不過，共用端點需要額外的工程作業，而且可能會增加延遲時間和管理負擔。

    如要瞭解 Agent Platform 的費用，請參閱「在 Agent Platform 建構及部署 AI 模型的成本」。

Cloud Run 成本考量

檢測功能可讓您監控效能、排解問題，以及追蹤各租戶的資源用量。如要識別每個要求的租戶，請從 IAP 提供的內容中擷取使用者身分。如要瞭解如何檢測應用程式，請參閱「選擇檢測方法」。

Model Armor 成本考量

為強制執行嚴格的管理機制和零信任機制，這個架構會在兩個層級部署 Model Armor：轉送中樞和各個租戶專案。雖然這種雙層做法有助於確保資料主權，但會增加延遲時間和營運成本。如要降低成本和系統複雜度，請只在轉送中樞部署 Model Armor，篩選所有提示和回覆。

架構中所有產品的費用考量

為確保架構符合成本需求，請考量下列一般建議：

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

  • 平台負擔：如要分配中央管理和安全中心的共用費用，請使用符合追蹤能力和使用模式的分配模式。建議您使用下列其中一種成本分配模式：

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

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

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

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

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

部署作業

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

後續步驟

貢獻者

作者：

其他貢獻者：