選擇代理式 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 模型的基礎架構。

以下各節將詳細分析各個元件，協助您決定如何建構架構。您選擇的元件會影響代理的效能、擴充性、成本和安全性。本文著重介紹建構及部署代理核心推論和執行邏輯時，所需的重要架構元件。負責任 AI 安全架構和代理身分管理等主題，不在本文討論範圍內。

前端框架

前端框架是一組預先建構的元件、程式庫和工具，可用來建構代理應用程式的使用者介面。您選擇的前端架構會定義後端的需求。內部展示用的簡單介面可能只需要同步 HTTP API，而正式版應用程式則需要支援串流通訊協定和強大狀態管理的後端。

請考慮下列架構類別：

  • 原型設計和內部工具框架：如要快速開發、內部示範和概念驗證應用程式，請選擇優先考量開發人員體驗和速度的框架。這些架構通常偏好簡單且同步的模型，稱為「要求-回應模型」。相較於正式版架構，要求-回應模型可讓您以最少的程式碼和更簡單的後端，建構功能性 UI。這種方法適合快速測試代理邏輯和工具整合，但可能不適用於需要即時互動、高度可擴充且面向大眾的應用程式。這類常見的架構包括 Mesop 和 Gradio。
  • 正式版架構：如要為外部使用者建構可擴充、回應迅速且功能豐富的應用程式，請選擇允許自訂元件的架構。這些架構需要能支援現代化使用者體驗的後端架構。正式環境架構應支援串流協定、無狀態 API 設計，以及強大的外部記憶體系統，以便管理多個使用者工作階段的對話狀態。正式版應用程式的常見框架包括 Streamlit、React 和 Flutter AI Toolkit。

如要管理這些架構與 AI 代理之間的通訊，可以使用代理與使用者互動 (AG-UI) 通訊協定。AG-UI 是一項開放通訊協定，可讓後端 AI 代理與前端框架互動。AG-UI 會告知前端框架何時要算繪代理的回覆、更新應用程式狀態，或觸發用戶端動作。如要建構互動式 AI 應用程式，請結合 AG-UI 與 Agent Development Kit (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 管理平台
您需要與特定內部或第三方 API 整合，但該 API 沒有 MCP 伺服器。 自訂函式工具

為代理選取工具時，請評估工具的功能和運作可靠性。優先選擇可觀測、易於偵錯，且具備強大錯誤處理機制的工具。這些功能可確保您能追蹤動作並快速解決失敗問題。此外，您也應評估代理是否能選用合適的工具，順利完成指派的工作。

內建工具

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 稽核記錄整合。如要查看 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 中心。API Hub 可讓代理透過直接 HTTP 呼叫、預先建構的連接器、在中心註冊的自訂 API，或直接存取 Google Cloud 資料來源，立即連線至資料。這樣一來，代理就能立即存取所需資訊，不必建構複雜的自訂資料載入和整合管道。

API 管理平台和 MCP 等通訊協定可解決不同的架構問題。通訊協定會標準化代理與工具之間的互動格式，確保元件可重複使用及替換。相較之下，API 管理平台會控管 API 端點的生命週期和安全性，處理驗證、頻率限制和監控等工作。這些模式相輔相成。舉例來說，代理可使用 MCP 與工具通訊，而該工具則可做為 API 中心管理及保護的安全 API 端點。

自訂函式工具

函式工具可為代理提供新功能。您可以編寫自訂函式工具，為代理提供特殊功能，例如與外部 API 或專屬業務系統整合。如要擴充代理的功能，最常見的做法是編寫自訂函式工具，提供內建工具無法提供的功能。

如要建立自訂函式工具，請使用偏好的程式設計語言編寫函式，然後以自然語言清楚說明其用途、參數和傳回值。代理的模型會根據這段說明，判斷何時需要使用工具、應提供哪些輸入內容，以及如何解讀輸出內容，以完成使用者的要求。

您也可以建立自訂函式工具，實作代理即工具函式。代理程式即工具函式會將一個代理程式公開為可呼叫函式，供其他代理程式叫用。這項技術可讓您建構複雜的多代理系統，其中代理可以協調並將專門工作委派給其他專用代理。如要進一步瞭解代理設計模式和協調多代理自動化調度管理，請參閱本文件後續的「代理設計模式」一節。

工具氾濫

如果在 AI 模型的系統提示中提供過多工具定義，就會發生工具膨脹。如果模型內容視窗中的工具、複雜參數或詳細說明過多，模型可能會不堪負荷。

當 AI 代理因工具過多而超載時，可能會發生下列問題：

  • 準確度降低：不相關的詞元會分散模型在脈絡視窗中的注意力，當模型的注意力分散時，就很難準確區分正確的工具和雜訊。
  • 成本和延遲時間增加：單一使用者要求可能會觸發多個隱藏的推論迴圈和工具執行作業。迴圈和執行次數增加，費用和工具回應時間也會隨之增加。

如要減少工具膨脹，可以採取下列策略：

  • 限制工具複雜度：以下是編寫簡潔工具定義的建議：
    • 使用原始資料類型，而非複雜的巢狀物件。
    • 工具的參數數量應少於五個。
    • 使用 enums 而非自由文字字串，限制模型的決策路徑。
  • 提供精細的工具組：將單體式伺服器拆解成精細、專注的工具組，並根據特定使用者歷程進行調整。舉例來說，您可以將大型 Cloud SQL 伺服器，分割成 DevOps 代理的管理員工具組，以及應用程式代理的資料工具組。
  • 實施逐步揭露：設計系統，僅在需要時動態解鎖相關背景資訊和功能，而非預先載入所有內容。如要採用漸進式揭露方法，請使用下列策略：
    • 搜尋工具模式：如要減少權杖用量，請實作使用單一搜尋工具的代理，動態載入相關工具結構定義。
    • Agent Skills：Agent Skills 是標準格式，可逐步探索指令、指令碼和其他資源。為盡量減少背景資訊膨脹，請定義代理技能，指示代理只在必要時擷取額外背景資訊。
    • 多代理委派：如要縮減代理的脈絡視窗，請導入多代理系統，使用協調代理將特定工作委派給專門的子代理。這種做法可確保只載入相關工具，並讓協調者代理的脈絡視窗保持簡潔。

這些策略並非互斥，應根據架構和工作負載需求結合使用。

代理記憶

代理能否記住過往互動，是提供連貫實用對話體驗的關鍵。如要建立有狀態、可感知情境的代理，您必須實作短期和長期記憶機制。以下各節將探討設計選項和 Google Cloud服務，可用於為代理實作短期和長期記憶。

短期記憶

短期記憶可讓代理在單一進行中的對話中，維持對話脈絡。如要實作短期記憶，您必須管理工作階段和相關聯的狀態。

  • 工作階段：工作階段是指使用者與代理之間的對話串，從初始互動到對話結束。
  • 狀態：狀態是代理在特定工作階段中，使用及收集的資料。收集的狀態資料包括使用者和代理之間交換的訊息記錄、任何工具呼叫的結果，以及代理需要瞭解對話情境的其他變數。

以下是使用 ADK 實作短期記憶的選項：

  • 記憶體內儲存空間：如果是開發、測試或在單一執行個體上執行的簡單應用程式，您可以直接將工作階段狀態儲存在應用程式的記憶體中。代理會使用資料結構 (例如字典或物件) 儲存鍵/值組合清單，並在整個工作階段中更新這些值。不過，使用記憶體內儲存空間時，工作階段狀態不會永久保存。如果應用程式重新啟動，所有對話記錄都會遺失。

  • 外部狀態管理：如果正式版應用程式需要擴充性和可靠性，建議您建構無狀態代理應用程式，並在外部儲存空間服務中管理工作階段狀態。在這個架構中，每當代理應用程式收到要求，就會從外部儲存庫擷取目前的對話狀態、處理新的對話輪次，然後將更新後的狀態儲存回儲存庫。這種設計可讓您水平擴充應用程式，因為任何執行個體都能處理任何使用者的要求。外部狀態管理的常見選項包括 Memorystore for Redis、Firestore 或 Gemini Enterprise Agent Platform 工作階段。

    如果使用 ADK，DatabaseSessionService 需要關聯式資料庫，例如 Cloud SQL。

長期記憶

長期記憶為代理提供持久的知識庫，可跨個別使用者的所有對話存在。長期記憶可讓代理檢索及使用外部資訊、從過往互動中學習，並提供更準確、更相關的回覆。

以下是使用 ADK 實作長期記憶的選項：

  • 記憶體內儲存空間：在開發和測試階段，您可以直接將工作階段狀態儲存在應用程式的記憶體中。這個方法很容易實作，但無法永久保存。如果應用程式重新啟動，對話記錄就會遺失。您通常會使用開發架構中的記憶體內供應器來實作這個模式，例如 ADK 內建的 InMemoryMemoryService，用於測試。
  • 外部儲存空間：如果是正式版應用程式，請在外部永久儲存空間服務中管理代理的知識庫。外部儲存空間服務可確保代理的知識持久、可擴充，且可透過多個應用程式執行個體存取。在 Google Cloud上，使用 Memory Bank 搭配任何 Agent Runtime，即可長期儲存資料。

代理設計模式

代理設計模式是建構代理應用程式的常見架構方法。這些模式提供獨特的架構，可組織系統元件、整合 AI 模型，以及自動調度管理單一或多個代理，以完成工作流程。如要判斷哪種方法最適合您的工作流程，請考量工作的複雜度和工作流程、延遲時間、效能和成本需求。

單一代理系統仰賴單一模型的推論能力，解讀使用者要求、規劃一系列步驟，並決定要使用哪些工具。這種做法是有效的起點，可讓您專注於修正核心邏輯、提示和工具定義，再增加架構複雜度。不過，隨著工作和工具數量變得更複雜，單一代理的效能可能會降低。

遇到複雜問題時，多代理系統會協調多個專門代理，達成單一代理難以達成的目標。這種模組化設計可提升系統的擴充性、可靠性和可維護性。不過，相較於單一代理系統，多代理系統也需要額外考量評估、安全性和成本。

開發多代理系統時，您必須為每個專門代理實作精確的存取控管機制、設計穩健的自動化調度管理系統，確保代理之間的通訊可靠，並管理因執行多個代理而增加的運算負擔，進而降低營運成本。如要促進代理之間的通訊，請搭配使用 Agent2Agent (A2A) 通訊協定和 ADK。A2A 是一套開放標準通訊協定，可讓 AI 代理在不同平台和框架之間通訊及協作，不受基礎技術限制。

如要進一步瞭解常見的代理設計模式，以及如何根據工作負載需求選取模式，請參閱「選擇代理式 AI 系統的設計模式」。

AI 模型

代理應用程式仰賴模型的推論和理解能力，做為主要工作自動調度管理工具。對於這個核心代理角色，建議您使用 Gemini Pro。

Google 模型 (例如 Gemini) 透過代管 API，提供最新、最強大的專屬模型。這種方法最適合用來盡量減少營運負擔。相較之下，開放式自行託管模型則提供深度控管功能，可讓您根據專屬資料進行微調。如果工作負載有嚴格的安全性和資料落地要求，也需要自行託管模型，因為這樣才能在自己的網路中執行模型。

如要提升代理效能，可以調整模型的推論能力。最新 Gemini Pro 和 Flash 模型等模型內建思考程序，可提升推論和多步驟規劃能力。如要偵錯和調整，您可以查看模型的思考摘要，或內部思考的合成版本，瞭解其推論路徑。您可以根據工作複雜度，調整思考預算或思考詞元數量，控制模型的推論能力。思考預算越高，模型在提供答案前，就能進行更詳細的推論和規劃。思考預算越高，回覆品質可能越好，但延遲時間和費用也可能增加。

為提升效能和成本效益，請實作模型路由，根據工作的複雜度、成本或延遲時間需求，動態選取最適合的模型。舉例來說，您可以將簡單的要求轉送至小型語言模型 (SLM)，處理程式碼生成或文字分類等結構化工作，並將更強大且昂貴的模型保留給複雜的推論工作。在代理應用程式中實作模型路由，即可建立符合成本效益且高效能的系統。

Google Cloud 提供多種 Google 模型、合作夥伴模型和開放式模型，可供您在代理架構中使用。如要進一步瞭解可用模型，以及如何選擇符合需求，請參閱「Gemini Enterprise Agent Platform 的 Model Garden」。

模型執行階段

模型執行階段是託管及提供 AI 模型的環境，可讓代理使用模型的推論功能。

選擇模型執行階段

如要選取最適合託管 AI 模型的執行階段，請參考下列指引：

用途 模型執行階段
您需要全代管 API，才能提供 Gemini 模型、合作夥伴模型、開放式模型或自訂模型，並享有企業級安全性、擴充性和生成式 AI 工具。 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 會管理底層基礎架構。
  • 安全性：代管安全性預設設定和標準法規遵循認證足以滿足您的需求。如要保護提示和回覆，並確保採用負責任的 AI 做法，您可以將 Model Armor 整合至 Agent Platform。
  • 模型可用性：透過代管 API 存取多種模型，包括最新的 Gemini 模型。
  • 費用：採用即付即用定價模式，可依應用程式流量調整。詳情請參閱「在 Agent Platform 建構及部署 AI 模型的成本」。

Cloud Run

Cloud Run 提供無伺服器執行階段，可在自訂容器中託管模型。Cloud Run 兼具 Agent Platform 的全代管便利性，以及 GKE 的深度基礎架構控管能力。如果需要在容器化環境中彈性執行模型，且不想管理伺服器或叢集，這個方法就很實用。

使用 Cloud Run 做為模型執行階段時，主要功能和考量事項包括：

  • 基礎架構控管：在自訂容器中執行任何模型，完全控管軟體環境，同時由平台管理底層無伺服器基礎架構。
  • 安全性：透過臨時、隔離的運算執行個體提供安全性，並可使用直連虛擬私有雲輸出或無伺服器 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 的功能和注意事項：

Agent Runtime 提供專門打造的代管環境，可處理代理運作時的許多複雜層面，例如生命週期和情境管理，因此可加快投入正式環境的速度。如果用途需要大量自訂運算環境，或需要使用 Python 以外的程式設計語言，則較不適合使用 Agent Runtime。如果工作負載對私人依附元件管理有嚴格的安全要求，Cloud Run 和 GKE 提供更直接、以 IAM 為基礎的設定路徑。

Cloud Run

Cloud Run 是全代管的無伺服器平台，可讓您在無狀態容器中執行代理程式應用程式程式碼。如要將整個代理應用程式、個別元件或自訂工具部署為可擴充的 HTTP 端點，且不想管理基礎架構，Cloud Run 是理想的選擇。

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

Cloud Run 可免除基礎架構管理作業，大幅簡化作業並提高成本效益。不過，Cloud Run 具有無狀態特性，因此您必須使用儲存空間服務，才能管理多步驟工作流程中的情境。此外，Cloud Run 服務的要求逾時時間上限為一小時，可能會限制長時間執行的代理工作。

GKE

Google Kubernetes Engine 是代管容器自動調度管理服務，可讓您精細控管代理應用程式的架構和基礎架構。GKE 適合需要強大、正式環境級功能的複雜代理系統，或者您已是 GKE 客戶，並想在現有應用程式上實作代理工作流程。

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

GKE 提供最大程度的控管能力和彈性，可讓您執行複雜的有狀態代理。不過，這項控管機制會大幅增加營運負擔和複雜度。您必須設定及管理 Kubernetes 叢集，包括節點集區、網路和資源調度政策，這需要比無伺服器平台更多的專業知識和開發工作。

後續步驟

貢獻者

作者：Samantha He | 技術文件撰稿者

其他貢獻者：