Google Cloud 中的多代理程式 AI 系統

Last reviewed 2026-10-09 UTC

本文提供參考架構，協助您在 Google Cloud中設計完善的多代理程式 AI 系統。多代理式 AI 系統會將複雜且動態的程序分割成數個獨立任務，由多個專業的 AI 代理共同執行。

這份文件適用於在雲端建構及管理 AI 基礎架構和應用程式的架構師、開發人員和管理員。本文假設您對 AI 代理和模型有基本瞭解。本文並未提供設計和編寫 AI 代理程式的具體指引。

本文的「部署」部分列出程式碼範例，可供您瞭解如何建構及部署多代理式 AI 系統。

架構

下圖顯示多代理程式 AI 系統的架構範例，該系統部署在 Google Cloud中。

Google Cloud中的多代理式 AI 系統架構。 Google Cloud中的多代理 AI 系統架構。

架構元件

上一節的範例架構包含下列元件：

前端
使用者透過前端 (例如聊天介面) 與多代理系統互動，前端會以無伺服器 Cloud Run 服務的形式執行。
代理

在本範例中，協調代理程式會控制代理式 AI 系統。協調代理會叫用適當的子代理，觸發代理流程。代理可使用 Agent2Agent (A2A) 通訊協定互相通訊，無論程式設計語言和執行階段為何，都能互通。範例架構顯示循序模式和疊代精進模式的代理程式。

如要進一步瞭解本範例中的子代理程式，請參閱「代理程式流程」一節。

Agent Runtime

AI 代理程式可以部署為 無伺服器 Cloud Run 服務、 Google Kubernetes Engine (GKE) 上的容器化應用程式， 或 Gemini Enterprise Agent Platform 上的 Agent Runtime。

ADK

Agent Development Kit (ADK) 提供工具和架構，用於開發、測試及部署代理。 ADK 可簡化代理的建立作業，讓 AI 開發人員專注於代理的邏輯和功能。

AI 模型和模型執行階段

在本範例架構中，代理會使用 Gemini Enterprise Agent Platform 的 AI 模型，提供推論服務。架構圖顯示 Cloud Run 和 GKE 是 AI 模型的替代執行階段。

Model Armor

Model Armor 可檢查並清理部署在 Agent Platform 和 GKE 中的模型輸入內容和回覆。此外，Model Armor 也可用於透過 Agent Gateway 轉送的代理程式和工具流量。詳情請參閱「Model Armor 與 Google Cloud 服務整合」。

MCP 用戶端、伺服器和工具

Model Context Protocol (MCP) 可標準化代理與工具之間的互動，方便存取工具。針對每個代理和工具配對，MCP 用戶端會透過 MCP 伺服器傳送要求，代理會透過該伺服器存取資料庫、檔案系統或 API 等工具。

代理流程

上述架構中的多代理系統範例具有下列流程：

  1. 使用者透過前端 (例如即時通訊介面) 輸入提示，前端會以無伺服器 Cloud Run 服務的形式執行。
  2. 前端會將提示轉送給協調代理程式。

  3. 協調員代理程式會根據提示中表達的意圖，啟動下列其中一個代理程式流程。

    • 依序：
      1. 「任務 A」子代理會執行任務。
      2. 任務 A 子代理會叫用任務 A.1 子代理。

    • 反覆修正：

      1. 子代理程式 B 執行工作。
      2. 品質評估子代理程式會審查工作 B 子代理程式的輸出內容。
      3. 如果輸出結果不盡理想，品質評估人員會叫用提示強化子代理程式，修正提示。
      4. 子代理程式 B 會使用強化提示再次執行工作。

      這個週期會持續進行，直到輸出內容令人滿意或達到最大疊代次數為止。

    範例架構包含human-in-the-loop路徑，讓使用者在必要時介入代理流程。

  4. 工作 A.1 子代理和品質評估子代理會各自叫用回覆生成器子代理。

  5. 回覆生成器子代理會生成回覆、執行驗證和根據事實檢查，然後透過協調器代理將最終回覆傳送給使用者。

使用的產品和工具

這項參考架構使用下列 Google Cloud 和第三方產品與工具：

  • Cloud Run：無伺服器運算平台，可讓您在 Google 可擴充的基礎架構上直接執行容器。
  • Gemini Enterprise Agent Platform：全方位平台，可建構、擴充、管理及最佳化調整企業級的 AI 代理。
  • Google Kubernetes Engine (GKE)：Kubernetes 服務，可讓您透過 Google 的基礎架構，大規模部署及操作容器化應用程式。
  • Model Armor：這項服務可保護生成式和代理式 AI 資源，防範提示詞注入、敏感資料外洩和有害內容。
  • Agent Development Kit (ADK)：一套工具和程式庫，可用於開發、測試及部署 AI 代理。
  • Agent2Agent (A2A) 通訊協定：這個開放式通訊協定可讓代理互通並進行通訊，無論代理採用何種程式設計語言和執行階段，都能順暢協作。
  • Model Context Protocol (MCP)：開放原始碼標準，可將 AI 應用程式連結至外部系統。

用途

多代理式 AI 系統適合用於複雜的用途，這類用途需要多個專業技能組合協同合作，才能達成業務目標。如要找出適合代理式 AI 系統的用途，請分析業務程序，並找出可透過 AI 輔助的特定任務。著重於實際的業務成果，例如降低成本和加快處理速度。這種做法有助於根據商機價值調整 AI 投資。

以下是多代理 AI 系統的應用實例。

財務顧問

提供個人化股票交易建議並執行交易。下圖顯示這個用途的代理流程範例。這個範例使用循序模式。

多代理系統的財務顧問應用實例。

下圖顯示下列流程：

  1. 資料擷取代理程式會從可靠來源擷取即時和歷來股價、公司財務報表和其他相關資料。
  2. 財務分析師代理程式會對資料套用適當的分析和圖表技術，找出價格變動模式並做出預測。
  3. 股票推薦代理會根據分析和圖表，根據使用者的風險偏好和投資目標，生成買賣特定股票的個人化推薦。
  4. 交易執行代理會代表使用者買賣股票。

研究助理

制定研究計畫、收集資訊、評估及修正研究內容，然後撰寫報告。下圖顯示這個用途的代理流程範例。本範例中的主要流程使用循序模式。範例也包含疊代式精修模式。

多代理系統的研究助理應用實例。

下圖顯示下列流程：

  1. 規劃者代理會制定詳細的研究計畫。

  2. 研究人員代理程式會完成下列工作：

    1. 根據研究計畫找出合適的內部和外部資料來源。
    2. 收集及分析必要資料。
    3. 準備研究摘要，並提供給評估人員代理。

    研究人員代理會重複執行這些工作，直到評估人員代理核准研究結果為止。

  3. 報告撰寫代理會建立最終研究報告。

供應鏈最佳化工具

最佳化庫存、追蹤貨運，以及與供應鏈合作夥伴通訊。 下圖顯示這個用途的代理流程範例。 這個範例使用循序模式。

多代理系統的供應鏈最佳化工具用途。

  1. 倉儲管理員代理會根據庫存、需求預測和供應商前置時間，建立補貨訂單，確保庫存量達到最佳狀態。

    • 代理會與貨運追蹤代理互動，追蹤貨物運送進度。
    • 代理程式會與供應商通訊代理程式互動，通知供應商訂單異動。

  2. 出貨追蹤代理會與供應商的物流平台和貨運公司系統整合，確保訂單及時有效率地完成。

  3. 供應商通訊員代理會代表系統中的其他代理與外部供應商通訊。

設計替代方案

您可以根據可管理性、控制權和彈性的需求，在 Google Cloud 中為 AI 代理程式和模型選擇合適的執行階段選項。詳情請參閱「選擇代理式 AI 架構元件」。

設計須知

本節說明設計因素、最佳做法和建議，供您參考這些資訊，使用這個參考架構開發拓撲，滿足安全性、可靠性、成本和效能方面的特定需求。

本節的指引僅列出部分範例。視工作負載需求和使用的 Google Cloud 及第三方產品和功能而定，您可能需要考量其他設計因素和取捨。

系統設計

本節提供指引，協助您為部署作業選擇 Google Cloud 區域，並選取適當的 Google Cloud 產品和工具。

區域選項

為 AI 應用程式選取 Google Cloud 區域時，請考量下列因素：

如要為應用程式選取適當的 Google Cloud 位置，請使用下列工具：

  • Google Cloud 區域挑選工具： 互動式網頁工具，可根據碳足跡、成本和延遲時間等因素，為應用程式和資料選取最佳 Google Cloud 區域。
  • Cloud Location Finder API： 公開 API，可透過程式輔助方式，在 Google Cloud、Google Distributed Cloud 和其他雲端供應商中尋找部署位置。

代理程式設計

本節提供設計 AI 代理的一般建議。撰寫代理程式碼和邏輯的詳細指引不在本文的討論範圍內。

  • 代理定義和設計：
    • 清楚定義代理式 AI 系統的業務目標，以及每個代理執行的工作。
    • 選擇最符合需求的代理程式設計模式。
    • 使用 ADK 輕鬆建立、部署及管理代理架構。
  • 與代理商的互動：
    • 在架構中設計面向真人服務專員的代理程式，支援自然語言互動。
    • 請確保每個代理程式都清楚向其依附用戶端傳達動作和狀態。
    • 設計代理程式，偵測及處理模稜兩可的查詢和細微的互動。
  • 背景資訊、工具和資料：
    • 請確保代理有足夠的脈絡，可追蹤多輪互動和工作階段參數。
    • 清楚說明代理程式可使用的工具用途、引數和用法。
    • 確保代理程式的回覆以可靠的資料來源為依據，減少幻覺。
    • 實作邏輯來處理不相符的情況，例如提示與主題無關。

安全性

本節說明設計拓撲時的考量事項和建議，確保拓撲符合工作負載的安全需求。 Google Cloud

代理程式的安全性考量

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

  • 人工監督：代理式 AI 系統有時可能會發生錯誤或無法正常運作。舉例來說，模型可能會生成不準確的內容，或是代理程式可能會選取不適當的工具。在業務關鍵的代理式 AI 系統中，加入人工介入迴路流程，讓人類主管監控、覆寫及暫停代理。舉例來說，人類使用者可以審查代理程式的輸出內容、核准或拒絕輸出內容，並提供進一步的指引來修正錯誤或做出策略決策。這種方法結合了代理式 AI 系統的效率，以及人類使用者的批判性思考和領域專業知識。
  • 代理程式身分和最小權限存取權：
  • 輸入和輸出流量管理：透過 Agent Gateway 轉送代理流量，在輸入和輸出邊界強制執行執行階段安全性政策。如要瞭解支援 Agent Gateway 的執行階段平台，請參閱「支援的 Agent Runtime」。
    • 用戶端至代理 (輸入)：在 Agent Runtime 前方部署 Agent Gateway。閘道會使用 Model Armor 驗證來電者身分，並即時檢查傳入的提示。
    • 代理至任意目的地 (輸出)：
      • 透過輸出模式的 Agent Gateway，轉送代理對代理 (A2A) 和代理對工具 (MCP) 的輸出要求。
      • 使用 IAM 存取政策和 Identity-Aware Proxy (IAP)，強制執行預設拒絕存取政策。
      • 確認目標代理程式和工具已在代理程式登錄中註冊。
      • 使用 Model Armor 檢查外送工具的呼叫和回覆，防範資料竊取、間接提示詞注入和工具濫用。
  • 監控：運用全方位追蹤功能監控代理的行為，清楚掌握代理採取的每個動作，包括推論過程、工具選擇和執行路徑。詳情請參閱「在 Agent Runtime 中記錄代理程式」和「在 ADK 中記錄」。

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

Agent Platform 安全性考量

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

MCP 安全性考量

為確保 MCP 實作項目符合安全規定，建議採取下列措施：

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

A2A 安全性考量

為確保 A2A 實作項目符合安全規定，建議您採取下列做法：

  • 傳輸安全：A2A 通訊協定規定，在正式環境中，所有 A2A 通訊都必須使用 HTTPS，並建議採用傳輸層安全標準 (TLS) 1.2 以上版本。
  • 驗證：A2A 通訊協定會將驗證作業委派給標準網路機制 (例如 HTTP 標頭) 和標準 (例如 OAuth2 和 OpenID Connect)。每個代理程式都會在代理程式卡片中宣傳驗證需求。詳情請參閱「A2A 驗證」。
  • 代理間管理：在 Agent Registry 中註冊 A2A 代理，並透過 Agent Gateway 轉送代理間要求。結合 Agent Gateway、Agent Identity、IAP 和 IAM 存取政策，即可加密驗證呼叫代理的身分、在協調代理和子代理之間強制執行精細授權，並透過 Model Armor 檢查代理間的酬載。

Cloud Run 安全性考量

為確保 Cloud Run 實作項目符合安全防護需求，請考慮下列建議：

  • 輸入安全 (適用於前端服務)：如要控管應用程式的存取權，請停用前端 Cloud Run 服務的預設 run.app 網址，並設定區域外部應用程式負載平衡器。除了將傳入流量負載平衡至應用程式，負載平衡器也會處理 SSL 憑證管理作業。如要加強防護，可以使用 Google Cloud Armor 安全性政策，為服務提供要求篩選、DDoS 防護和頻率限制。

  • 使用者驗證：

    • 貴機構內的使用者：如要驗證內部使用者對前端 Cloud Run 服務的存取權，請使用 IAP。使用者嘗試存取 IAP 保護的資源時，IAP 會執行驗證及授權檢查。
    • 貴機構外部使用者：如要驗證外部使用者對前端服務的存取權，請使用 Identity Platform 或 Firebase 驗證。如要管理外部使用者存取權，請設定應用程式來處理登入流程，並向 Cloud Run 服務發出已驗證的 API 呼叫。

    詳情請參閱「驗證使用者」。

  • 代理和 MCP 伺服器安全性：在 Cloud Run 託管代理或 MCP 伺服器時，請設定 Agent Platform 的 Cloud Run 功能，將受管理代理身分指派給服務，並搭配使用 IAP 和 Agent Gateway，驗證及授權代理和工具的傳入要求。

  • 容器映像檔安全性：為確保只有授權的容器映像檔會部署至 Cloud Run，您可以使用二進位授權。如要找出並降低容器映像檔中的安全風險，請使用 Artifact Analysis 自動執行安全漏洞掃描。詳情請參閱「容器掃描總覽」。

  • 資料落地：Cloud Run 可協助您符合資料落地規定。Cloud Run 服務會在所選區域中執行。

如需容器安全性的更多指引，請參閱「一般 Cloud Run 開發提示」。

架構中所有 Google Cloud 產品的安全性考量

為確保架構符合安全性規定，請參考下列一般建議：

  • 資料加密：根據預設， Google Cloud 會使用 Google-owned and Google-managed encryption keys加密靜態資料。如要使用您控管的加密金鑰保護代理程式資料，可以透過在 Cloud KMS 建立及管理的客戶自行管理的加密金鑰 (CMEK) 達成。如要瞭解與 Google Cloud Cloud KMS 相容的服務，請參閱「相容服務」。
  • 降低資料竊取風險：如要降低資料竊取風險，請在基礎架構周圍建立 VPC Service Controls 範圍。VPC Service Controls 支援這項參考架構使用的所有Google Cloud 服務。
  • 存取控管：為拓撲中的資源設定權限時，請遵循最小權限原則。
  • 雲端環境安全：使用 Security Command Center 中的工具偵測安全漏洞、找出並緩解威脅、定義及部署資安態勢，以及匯出資料以供進一步分析。
  • 部署後最佳化：在Google Cloud中部署應用程式後，使用 Active Assist 取得建議，進一步提升安全性。查看建議，並視環境需要套用。詳情請參閱「在 Active Assist 中查看建議」。

更多安全性建議

可靠性

本節說明在 Google Cloud中部署時，建構及運作可靠基礎架構的設計考量事項和建議。

代理程式的可靠性考量

為確保代理程式設定符合可靠性需求，請考慮採取下列建議做法：

  • 容錯功能：設計代理式系統時，請確保系統能容許或處理代理層級的故障。盡可能採用去中心化做法，讓代理程式獨立運作。
  • 模擬失敗：將代理式 AI 系統部署到正式環境前，請先模擬正式環境，驗證系統是否正常運作。找出並修正代理程式間的協調問題和非預期行為。
  • 錯誤處理：如要診斷及排解錯誤，請實作記錄、例外狀況處理和重試機制。

Agent Platform 可靠性考量

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

  • 容量規劃：如果要求數量超過分配的容量，系統會傳回錯誤代碼 429。對於業務關鍵且持續需要高處理量的工作負載，您可以使用「佈建輸送量」預留處理量。
  • 模型端點可用性：如果資料可跨多個區域或國家/地區共用，您可以使用模型的全域端點。

Cloud Run 可靠性，可因應可用區和區域中斷

Cloud Run 是區域性服務。這項服務會在區域內的多個可用區同步儲存資料，並自動在各可用區之間平衡流量負載。如果發生可用區中斷情形，Cloud Run 會繼續執行，資料也不會遺失。如果發生區域性服務中斷，服務就會停止運作，直到 Google 解決問題為止。

架構中所有 Google Cloud 產品的可靠性考量

在 Google Cloud中部署應用程式後，您可以使用 Active Assist 取得建議，進一步提升可靠性。請查看建議，並視環境情況套用。詳情請參閱「在 Active Assist 中尋找建議」。

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

作業

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

Agent Platform 作業考量

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

  • 使用記錄進行監控：根據預設，寫入 stdout 和 stderr 串流的代理程式記錄會傳送至 Cloud Logging。如要進行進階記錄，可以將 Python 記錄器與 Cloud Logging 整合。如要完整控管記錄和結構化記錄，請使用 Cloud Logging 用戶端。詳情請參閱「記錄代理程式」和「登入 ADK」。
  • 持續評估：定期對代理的輸出內容和軌跡 (或代理產生輸出內容所採取的步驟) 進行質性評估。如要實作代理評估功能，可以使用 Gen AI Evaluation Service，或 ADK 支援的評估方法。

MCP 作業注意事項

為確保 MCP 實作項目符合您的作業需求，請參考下列建議：

  • 資料庫工具：如要有效管理 AI 代理的資料庫工具，並確保代理安全處理連線集區和驗證等複雜作業，請使用 MCP Toolbox for Databases。這個位置可集中儲存及更新資料庫工具。您可以在代理之間共用工具，並更新工具，不必重新部署代理。工具箱包含各種工具，適用於 AlloyDB for PostgreSQL 等資料庫，以及 MongoDB 等第三方資料庫。 Google Cloud
  • 生成式 AI 模型：如要讓 AI 代理使用 Imagen 和 Veo 等 Google 生成式 AI 模型，可以搭配生成式媒體 API 專用的 MCP 伺服器 Google Cloud 。
  • Google 安全性產品和工具：如要讓 AI 代理存取 Google 安全性產品和工具，例如 Google Security Operations、Google Threat Intelligence 和 Security Command Center，請使用 Google 安全性產品的 MCP 伺服器。

架構中所有 Google Cloud 產品的作業考量

使用 Cloud Trace 持續收集及分析追蹤記錄資料。追蹤資料可協助您快速找出並診斷複雜代理工作流程中的錯誤。您可以使用 Trace Explorer 工具中的資料圖表進行深入分析。詳情請參閱「查看代理程式追蹤記錄」。

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

成本最佳化

本節提供指引，協助您盡量降低設定及運作使用這項參考架構建構的 Google Cloud 拓撲費用。

Agent Platform 費用考量

為確保 Agent Platform 設定和用量符合費用規定，建議採取下列做法：

  • 費用分析和管理：如要分析及管理 Agent Platform 成本，建議您建立每秒查詢次數 (QPS) 和每秒詞元數 (TPS) 的基準指標。然後在部署後監控這些指標。基準也有助於規劃容量。舉例來說，基準有助於判斷何時可能需要「佈建輸送量」。
  • 模型選取：您為 AI 應用程式選取的模型會直接影響成本和效能。如要找出最適合特定用途的模型，在效能和費用之間取得最佳平衡，請反覆測試模型。建議您先從最具成本效益的模型著手，然後逐步改用功能更強大的選項。
  • 經濟實惠的提示：提示 (輸入) 和生成的內容 (輸出) 長度會直接影響效能和費用。撰寫簡短、直接且提供充分背景資訊的提示。設計提示，讓模型提供簡潔的回覆。例如「用 2 句話總結」或「列出 3 個重點」。詳情請參閱「提示設計最佳做法」。
  • 脈絡快取：如要降低要求成本，請使用脈絡快取，減少要求中重複內容的輸入詞元數量。
  • 批次要求：視情況考慮批次預測。 批次要求產生的費用比標準要求低。

Cloud Run 費用考量

為確保 Cloud Run 實作項目符合成本需求，請考慮下列建議：

  • 資源分配：建立 Cloud Run 服務時，您可以指定要分配的記憶體和 CPU 數量。從預設的 CPU 和記憶體配置開始。觀察一段時間內的資源用量和成本，並視需要調整分配。詳情請參閱「為服務設定記憶體限制」和「為服務設定 CPU 限制」。
  • 費率最佳化：如果可以預測 CPU 和記憶體需求，就能透過承諾使用折扣 (CUD) 節省費用。

架構中所有 Google Cloud 產品的成本考量

在 Google Cloud中部署應用程式後，您可以使用 Active Assist 取得建議，進一步節省成本。請查看建議，並視環境情況套用。詳情請參閱「在 Active Assist 中尋找建議」。

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

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

效能最佳化

本節說明設計考量事項和建議，協助您在 Google Cloud 中設計拓撲，滿足工作負載的效能需求。

代理程式的效能考量

為確保代理程式設定符合成效需求，請參考下列建議：

  • 模型選取：為代理式 AI 系統選取模型時，請考量代理需要執行的工作所需的功能。
  • 提示最佳化：如要大規模快速改善及最佳化提示成效，並免除手動重寫提示的需要，請使用 Agent Platform 提示最佳化工具。這項工具可協助您有效調整不同模型的提示。

Agent Platform 效能注意事項

為確保 Agent Platform 設定和用量符合效能需求，請參考下列建議：

  • 模型選取：您為 AI 應用程式選取的模型會直接影響成本和效能。如要找出最適合特定用途的模型，在效能和費用之間取得最佳平衡，請反覆測試模型。建議您先從最具成本效益的模型著手，然後逐步改用功能更強大的選項。
  • 提示工程：提示 (輸入) 和生成的內容 (輸出) 長度會直接影響效能和費用。撰寫簡短、直接且提供充分背景資訊的提示。設計提示，讓模型提供簡潔的回覆。舉例來說，你可以加入「用 2 句話總結」或「列出 3 個重點」等詞句。詳情請參閱「提示設計最佳做法」。
  • 脈絡快取：如要減少要求延遲，請使用脈絡快取，這項功能適用於含有重複內容和較多輸入詞元的要求。

Cloud Run 效能注意事項

視效能需求而定，設定要分配給 Cloud Run 服務的記憶體和 CPU。詳情請參閱「為服務設定記憶體限制」和「為服務設定 CPU 限制」。

如需更多效能最佳化指南，請參閱「一般 Cloud Run 開發提示」。

架構中所有 Google Cloud 產品的效能考量

在 Google Cloud部署應用程式後，您可以使用 Active Assist 取得建議，進一步提升效能。請查看建議，並視環境情況套用。詳情請參閱「在 Active Assist 中尋找建議」。

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

部署作業

如要瞭解如何建構及部署多代理式 AI 系統，請使用下列程式碼範例。這些程式碼範例可做為學習和實驗的起點，且功能齊全。如要在正式環境中獲得最佳運作效果，您必須根據特定業務和技術需求自訂程式碼。

後續步驟

貢獻者

作者：Kumar Dhanagopal | 跨產品解決方案開發人員

其他貢獻者：