選擇代理式 AI 架構元件

本文將提供指引，協助您在 Google Cloud中為代理式 AI 應用程式選擇架構元件。本文說明如何評估應用程式和工作負載的特性，以便選擇最符合需求的產品或服務。設計代理程式 AI 架構的過程是反覆的。隨著工作負載特性改變、需求演進，或是新 Google Cloud 產品和功能推出，您應定期重新評估架構。

AI 代理適合用於解決開放式問題的應用程式，這類問題可能需要自主決策，以及管理複雜的多步驟工作流程。代理程式擅長使用外部資料即時解決問題，並自動執行需要大量知識的工作。與 AI 模型的輔助和生成功能相比，這些功能可讓服務專員提供更多商務價值。

對於有預先定義步驟的確定性問題，您可以使用 AI 代理程式。不過，其他做法可能更有效率且符合成本效益。舉例來說，摘要文件、翻譯文字或分類顧客意見回饋等工作，不需要代理工作流程。

如要瞭解其他非代理程式 AI 解決方案，請參閱下列資源：

代理程式架構總覽

代理是一種應用程式，會處理輸入內容、運用可用工具進行推論，並根據決策採取行動，以達成目標。代理會使用 AI 模型做為核心推論引擎，自動執行複雜工作。代理程式會使用一組工具，讓 AI 模型與外部系統和資料來源互動。代理程式可使用記憶體系統來維持脈絡，並從互動中學習。代理式架構的目標是建立自主系統，這類系統能夠瞭解使用者意圖、制定多步驟計畫，並使用可用工具執行該計畫。

下圖顯示代理程式系統架構元件的概要總覽：

代理程式系統的架構元件。

代理系統架構包含下列元件：

  • 前端架構：預先建構的元件、程式庫和工具集合，可用於建構應用程式的使用者介面 (UI)。
  • 代理程式開發架構：您用來建構及架構代理程式邏輯的架構和程式庫。
  • 代理工具：工具集合，例如 API、服務和函式，可擷取資料及執行動作或交易。
  • 代理記憶體：代理用來儲存及回想資訊的系統。
  • 代理程式設計模式：建構代理程式應用程式的常見架構方法。
  • 代理程式執行階段：代理程式應用程式邏輯執行的運算環境。
  • AI 模型：驅動代理決策能力的核心推論引擎。
  • 模型執行階段：用於代管及提供 AI 模型的基礎架構。

以下各節將詳細分析各個元件，協助您決定如何建構架構。您選擇的元件會影響代理程式的效能、擴充性、費用和安全性。本文著重於建構及部署代理程式核心推理和執行邏輯時使用的重要架構元件。本文件不涵蓋負責任的 AI 安全架構和代理程式身分管理等主題。

前端架構

前端架構是一系列預先建構的元件、程式庫和工具，可用於建構代理式應用程式的 UI。您選擇的前端架構會定義後端需求。內部展示的簡單介面可能只需要同步 HTTP API，但正式版應用程式需要支援串流通訊協定和健全狀態管理的後端。

請考慮下列架構類別：

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

如要管理這些架構與 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 也非常適合建構執行後端工作的自主代理。針對這些非互動式用途，請選擇擅長處理單一獨立請求，並實作健全錯誤處理機制的代理程式設計模式。

雖然您可以選擇使用一般用途的 AI 架構 (如 Genkit)，但我們建議使用 ADK。Genkit 提供可用於開發自家代理程式架構的基元。不過，ADK 等專用代理程式架構提供更專業的工具。

服務專員工具

代理透過工具與外部系統互動的能力，決定了代理的效用。代理程式工具是 AI 模型可用的功能或 API，代理程式會使用這些工具來提升輸出內容品質，並自動執行工作。將 AI 代理程式連結至外部系統後，工具會將代理程式從單純的文字生成器，轉變成可自動執行複雜多步驟工作的系統。

如要啟用工具互動，請選擇下列工具使用模式：

用途 工具使用模式
您需要執行常見工作，例如完成網路搜尋、執行計算或執行程式碼，並希望加快初始開發速度。 內建工具
您想建構模組化或多代理程式系統，需要可互通且可重複使用的工具。 Model Context Protocol (MCP)
您需要在企業規模下管理、保護及監控大量 API 型工具。 使用 API 管理平台
您需要與沒有 MCP 伺服器的特定內部或第三方 API 整合。 自訂函式工具

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

內建工具

ADK 提供多種內建工具，可直接整合至代理程式的執行階段。您可以將這些工具視為函式呼叫，不必設定外部通訊協定。這些工具提供常見功能，包括從網路上存取即時資訊、在安全環境中以程式輔助方式執行程式碼、從私人企業資料擷取資訊來實作 RAG，以及與雲端資料庫中的結構化資料互動。內建工具可與您建立的任何自訂工具搭配使用。

MCP

如要讓代理程式系統的元件互動，您需要建立明確的通訊協定。 MCP 是一項開放通訊協定，可為代理提供標準化介面，方便存取及使用必要工具、資料和其他服務。

MCP 會將代理程式的核心推理邏輯與工具的具體實作方式分離，就像標準硬體連接埠允許不同周邊裝置連線至裝置一樣。MCP 提供不斷擴充的預建連接器清單，以及建構自訂整合項目的統一方式，因此可簡化工具整合程序。整合工具的彈性可促進不同模型和工具之間的互通性。

您可以連線至可用的遠端 MCP 伺服器，也可以代管自己的 MCP 伺服器。自行代管 MCP 伺服器時，您可以全權控管如何向代理程式公開專屬或第三方 API。如要託管自己的自訂 MCP 伺服器，請將其部署為容器化應用程式，並在 Cloud Run 或 GKE 上執行。

使用 API 管理平台

API 管理平台是集中式系統，可讓您透過 API 保護、監控及控管內部或外部服務。API 管理平台可集中列出貴機構的所有 API，簡化資料公開方式，並透過用量監控提供可觀測性。

如要在 Google Cloud上大規模管理代理程式的 API 工具，建議使用 Apigee API 中心。透過 API 中心，服務專員可以透過直接 HTTP 呼叫、預先建構的連線器、在中心註冊的自訂 API，或直接存取 Google Cloud 資料來源，立即連結資料。採用這種做法，客服人員就能立即存取所需資訊，不必再費心建構自訂資料載入和整合管道。

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

自訂函式工具

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

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

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

代理程式記憶體

代理程式必須能夠記住先前的互動，才能提供連貫且實用的對話體驗。如要建立具備狀態的背景資訊感知代理程式，您必須實作短期記憶和長期記憶機制。以下各節將探討設計選項和 Google Cloud 服務，協助您為代理程式實作短期和長期記憶體。

短期記憶

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

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

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

  • 記憶體內儲存空間：如要開發、測試或建立在單一例項上執行的簡單應用程式，可以直接將工作階段狀態儲存在應用程式的記憶體中。代理程式會使用資料結構 (例如字典或物件) 儲存鍵/值組合清單，並在整個工作階段中更新這些值。不過，使用記憶體內儲存空間時，工作階段狀態不會持續存在。如果應用程式重新啟動，所有對話記錄都會遺失。
  • 外部狀態管理：對於需要擴充性和可靠性的正式版應用程式，建議您建構無狀態的代理程式應用程式，並在外部儲存空間服務中管理工作階段狀態。在這個架構中，每當代理程式應用程式收到要求，就會從外部商店擷取目前的對話狀態、處理新的輪次，然後將更新後的狀態儲存回商店。這種設計可讓您水平擴充應用程式，因為任何執行個體都能處理任何使用者的要求。外部狀態管理常見的選擇包括 Memorystore for Redis、Firestore 或 Vertex AI Agent Engine 工作階段。

長期記憶

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

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

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

代理程式設計模式

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

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

如果問題較為複雜，多代理系統會協調多個專業代理，以達成單一代理難以管理的目標。這種模組化設計可提升系統的擴充性、可靠性和可維護性。不過，與單一代理程式系統相比，多代理程式系統也帶來了額外的評估、安全性和成本考量。

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

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

AI 模型

代理式應用程式會依據模型的推論和理解能力，擔任主要工作協調器。對於這個核心代理程式角色，我們建議使用 Gemini Pro。

透過受管理的 API，即可存取 Google 模型 (例如 Gemini) 的最新專有模型，這種做法最適合盡量減少作業負擔。相較之下，開放原始碼的自架模型可提供深入控制功能，讓您根據專有資料微調模型。如果工作負載有嚴格的安全性和資料落地需求，也需要自行託管模型，因為這樣您就能在自己的網路中執行模型。

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

為盡量提升效能和降低成本，請實作模型路徑，根據工作複雜度、成本或延遲時間需求，為每項工作動態選取最合適的模型。舉例來說，您可以將簡單的請求轉送至小型語言模型 (SLM)，處理程式碼生成或文字分類等結構化工作，並保留功能更強大且成本較高的模型，用於複雜的推理工作。如果您在代理程式應用程式中實作模型路徑，就能建立高成效的經濟實惠系統。

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

模型執行階段

模型執行階段是代管及提供 AI 模型的環境，可讓代理程式運用模型的推理能力。

選擇模型執行階段

如要選取代管 AI 模型時的最佳執行階段，請參考下列指引：

用途 模型執行階段
您需要全代管 API，才能提供 Gemini 模型、合作夥伴模型、開放式模型或自訂模型，並享有企業級安全性、擴充性和生成式 AI 工具。 Vertex AI
您需要部署開放或自訂的容器化模型，並優先考量無伺服器的簡便性與成本效益，以因應流量變化。 Cloud Run
您需要盡可能控管基礎架構，才能在專用硬體上執行開放式或自訂容器化模型，或是滿足複雜的安全性和網路需求。 GKE

以下各節將概述上述模型執行階段，包括主要功能和設計考量。本文著重介紹 Vertex AI、Cloud Run 和 GKE。不過， Google Cloud 提供其他服務，您或許可以考慮用於模型執行階段：

  • Gemini API： Gemini API 專為需要快速直接存取 Gemini 模型，但不需要複雜代理系統常用企業管理功能的開發人員設計。
  • Compute Engine： Compute Engine 是基礎架構即服務 (IaaS) 產品，適合用於舊版應用程式。相較於以容器為基礎的現代執行階段，這會造成顯著的作業負擔。

如要進一步瞭解模型執行階段的所有服務選項，請參閱「模型代管基礎架構」。

Vertex AI

Vertex AI 提供全代管的無伺服器環境，可託管 AI 模型。您可以透過安全且可擴充的 API，提供及微調 Google 模型、合作夥伴模型和開放模型。這種做法可省去所有基礎架構管理工作，讓您專心將模型智慧整合至應用程式。

使用 Vertex AI 做為模型執行階段時，主要功能和注意事項包括：

  • 基礎架構控制項：模型專用的全代管 API。Google 會管理底層基礎架構。
  • 安全性：管理式安全預設值和標準法規遵循認證足以滿足您的需求。如要保護提示和回覆，並確保遵循負責任的 AI 做法，您可以將 Model Armor 整合至 Vertex AI。
  • 模型可用性：透過代管 API 存取各種模型，包括最新的 Gemini 模型。
  • 費用：按用量計費模式，費用會隨著應用程式流量調整。詳情請參閱「在 Vertex AI 中建構及部署 AI 模型的費用」。

Cloud Run

Cloud Run 提供無伺服器執行階段，可在自訂容器中代管模型。Cloud Run 兼具 Vertex AI 的全代管簡便性，以及 GKE 的基礎架構深度控制功能。如果您需要在容器化環境中彈性執行模型，但不想管理伺服器或叢集，這個方法就非常適合。

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

  • 基礎架構控制：在自訂容器中執行任何模型，全面控管軟體環境，同時讓平台管理底層無伺服器基礎架構。
  • 安全性：透過暫時性、獨立的運算執行個體提供安全性，並允許使用直接虛擬私有雲輸出或無伺服器虛擬私有雲存取連接器，安全地連線至私人資源。詳情請參閱私有網路和 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 價格。

代理程式執行階段

如要代管及部署代理程式應用程式，您必須選擇代理程式執行階段。這項服務會執行應用程式程式碼，也就是您使用代理程式開發架構時編寫的商業邏輯和協調流程。應用程式會從這個執行階段向所選模型執行階段代管及管理的模型發出 API 呼叫。

選擇代理程式執行階段

如要在代管 AI 代理程式時選取執行階段，請按照下列指引操作：

用途 代理程式執行階段
您的應用程式是 Python 代理程式，需要完全受管理的體驗，且作業管理負擔極小。 Vertex AI Agent Engine
您的應用程式已容器化，且需要無伺服器、事件導向的擴充功能，並具備語言彈性。 Cloud Run
您的應用程式已容器化，具有複雜的有狀態需求，且需要精細的基礎架構設定。 GKE

如果您已在 Cloud Run 或 GKE 上管理應用程式，則可使用相同的平台處理代理程式工作負載，加快開發速度並簡化長期作業。

以下各節將概述各個代理程式執行階段，包括主要功能和設計考量。

Vertex AI Agent Engine

Vertex AI Agent Engine 是全代管的執行階段，可讓您部署、運作及調度代理應用程式。Vertex AI Agent Engine 會將基礎架構抽象化，讓您專注於代理邏輯，而非作業。

以下是 Vertex AI Agent Engine 的功能和注意事項：

Vertex AI Agent Engine 提供專屬的代管環境，可處理許多複雜的代理作業 (例如生命週期和情境管理)，因此能加快正式環境的部署速度。如果用途需要大量自訂運算環境，或需要使用 Python 以外的程式設計語言，則不適合使用 Vertex AI Agent Engine。如果工作負載對私有依附元件管理有嚴格的安全防護需求，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 提供的功能和注意事項：

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

後續步驟

貢獻者

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

其他貢獻者：