資料代理程式的整合模式

本頁面說明將資料代理體驗嵌入應用程式的整合模式。這些模式的複雜度不一，從嵌入式聊天元件到協調的多代理系統都有。

本指南適用於設計生成式 AI 應用程式的雲端架構師和資料工程師。您應對 Google Cloud 概念、Identity and Access Management (IAM) 和 REST API 有基本瞭解。此外，您也應熟悉應用程式使用的資料來源架構。

整合模式總覽

本指南分為下列主要路徑，每個路徑都根據您的起點而定：

  • Looker 方案：如要透過 Looker 嵌入、Looker API 或對話式數據分析 API 提供對話功能，請選取這個方案。
  • BigQuery 和資料庫追蹤：如果您要建構使用 BigQuery、數據分析或支援的作業資料庫的自訂應用程式，請選取這個追蹤。

下表列出可用的整合模式：

整合模式 說明 資料來源
Looker iframe 嵌入 在應用程式中加入標準對話介面，只需編寫少量程式碼。 Looker
Looker API 和 SDK 建構自訂對話介面，並使用 Looker API 進行驗證。 Looker
對話式數據分析 API (Looker 來源) 將 Looker 資料代理視為 Google Cloud 資源管理，可在多個介面和多代理系統中運作。 Looker
Direct API (單一代理) 使用直接 API 整合，進行文字轉答案流程。 BigQuery、資料庫、Looker
Direct API (orchestrator) 使用呼叫函式，在 API 和其他工具之間轉送查詢。 BigQuery、資料庫、Looker
ADK (結構定義導向) 搭配 BigQueryToolset 使用 ask_data_insights 工具，快速從表格參照生成洞察資料。 BigQuery
ADK (受控管) 搭配 DataAgentToolset 查詢預先設定的資料代理，這些代理會使用 ask_data_agent 工具，確保行為一致。 BigQuery、資料庫、Looker
ADK (自訂串流) 使用自訂代理類別，支援圖表和 SQL 的即時串流。 BigQuery、資料庫、Looker
MCP 搭配 McpToolset 或 ToolboxToolset 將應用程式連結至使用 Model Context Protocol (MCP) 的資料工具。 BigQuery、Looker
對話式數據分析 API 遠端 MCP 伺服器 提供統一的安全閘道，讓第三方 AI 平台和 Google 代管平台 (例如 Gemini Enterprise) 中的根代理，探索 Google Cloud中的專門資料代理並與其通訊。 BigQuery、資料庫、Looker
A2A 通訊協定 讓在不同系統上運作的專業代理安全協作。 依賴架構

Looker 整合選項

如果您使用 Looker，可以透過下列模式向使用者提供 Looker 對話式數據分析：

Looker 整合模式摘要

下表總結 Looker 的主要整合模式：

模式 適用情境 優點 注意事項
使用 iframe 嵌入：低程式碼方法，可快速將標準 Looker 對話體驗新增至應用程式。 團隊需要可用於正式環境的對話式數據分析體驗，且只需進行少量自訂開發。
  • 只需少量程式碼即可導入。
  • 自動強制執行現有的 Looker 安全性模型。
  • 不需要另外 Google Cloud 驗證。
  • 支援 Looker Embed SDK，可管理 iframe 生命週期和事件傳遞，加快開發速度。
  • 提供有限的 UI 自訂功能，並仰賴標準 Looker 對話使用者介面。
  • Looker 執行個體必須由 Looker 代管。
使用 Looker API 和 SDK 建構：這種方法可彈性建構自訂對話介面，同時在 Looker 中管理驗證和代理。 團隊需要自訂即時通訊使用者體驗，但想在 Looker 生態系統中保留使用者驗證和代理管理功能。如果應用程式已使用 Looker 嵌入功能或 API，這個模式就很適合。
  • 提供單一驗證層，並可完整控管使用者介面。
  • 簡化現有 Looker 客戶的架構。
  • 使用 Looker 語意層提高查詢準確度。
  • 不需要另外 Google Cloud 驗證。
  • 需要具備 Looker API 開發專業知識。
  • 僅限 Looker 資料來源。
  • 代理是在 Looker 中管理，無法轉移至其他 Google Cloud 服務。
使用對話式數據分析 API：直接與 API 整合，將代理當做雲端層級資源管理。 Looker 客戶需要跨平台可攜性，才能使用資料代理。
  • 確保資料代理可在所有 Google Cloud 介面之間轉移。
  • 由 IAM 集中管理。
  • 可將資料代理整合至 ADK 或 MCP 工作流程。
  • 您必須管理完整的整合堆疊，包括 Google Cloud 和 Looker 驗證。
  • 資料代理程式的管理與 Looker 使用者介面無關。

使用 iframe 嵌入

您可以嵌入對話式數據分析做為 iframe，在 Looker UI 以外提供對話體驗。這個模式可直接提供對話式數據分析，不需要自訂 UI 開發、後端自動化調度管理或 API 狀態管理。如要使用這個模式，請在應用程式中加入預先格式化的網址。

Looker 嵌入 SDK 提供多項工具，可管理安全網址產生、iframe 生命週期管理，以及主機應用程式與 iframe 之間的 JavaScript 事件傳遞等工作。只要在應用程式中加入預先格式化的網址，即可嵌入「代理」頁面、「對話」頁面或特定對話。

您可以對內嵌內容使用下列驗證方式：

  • 私人嵌入：使用現有的 Looker 憑證驗證使用者。將嵌入網址設為 iframe 來源時，使用者會以 Looker 帳戶登入。這個方法會自動強制執行現有角色、內容存取權和資料層級權限，例如存取權篩選器或存取權授予，不需額外設定 IAM 或對應權杖。
  • 簽署嵌入：使用單一登入 (SSO) 服務，透過應用程式驗證使用者。您建構的經簽署的網址包含對話式數據分析內容路徑，可讓您動態指定要授予的確切權限。

使用 Looker API 和 SDK 建構

如要享有更靈活的對話體驗，可以使用 Looker API 中的 ConversationalAnalytics 方法，或使用 Looker SDK 建構自訂應用程式。這種做法可讓您建構自訂前端，直接與 Looker 端點通訊。

整合 Looker API 有下列優點：

  • 您只需透過 Looker 管理驗證。您不需要另外透過對話式數據分析 API 進行驗證。
  • 對於已使用 Looker 嵌入或 API 的應用程式，這種模式可避免次要驗證機制，且不需管理外部資料代理，進而簡化專案架構。
  • 您可以完全掌控對話介面、對話流程，以及應用程式呈現結果的方式 (例如圖表和表格)。

如需參考實作，請參閱 GitHub 上的 Looker API 指南，其中使用 ConversationalAnalytics 方法。

搭配使用對話式數據分析 API 和 Looker 資料

如需執行下列任一工作，可以直接在 geminidataanalytics.googleapis.com 整合對話式數據分析 API：

  • 在多個 Google Cloud 介面 (例如自訂網頁應用程式、Google Chat 和 Gemini Enterprise) 共用同一個資料代理。
  • 在單一多代理系統中，結合 Looker 資料來源與 BigQuery 或作業資料庫來源。
  • 將資料代理視為雲端層級資源管理，由 IAM 控管，而非 Looker 權限模型。

如要進一步瞭解 Conversational Analytics API 的常見架構模式，請參閱「BigQuery 和資料庫的整合選項」。

BigQuery、數據分析和資料庫的整合選項

本節說明應用程式的架構模式，這些應用程式使用 BigQuery、數據分析或支援的 Google Cloud 作業資料庫，透過 Conversational Analytics API 建構自訂體驗。

如果您搭配使用對話式數據分析 API 和 Looker 資料來源，本節所述的模式也適用於您的整合。

對話式數據分析 API 提供下列主要方法，可與資料互動：

  • chat 方法：支援 BigQuery、Looker、數據分析和作業資料庫。
  • queryData 方法：支援 AlloyDB、GoogleSQL for Spanner、MySQL 適用的 Cloud SQL 和 PostgreSQL 適用的 Cloud SQL 等作業資料庫。

建構自訂應用程式時，您可以使用下列一或多種整合模式：

  • 直接整合 API：自訂方法，提供最大彈性，但您必須建構驗證、對話管理和回覆剖析的基礎架構。
  • 框架導向自動調度管理 (ADK)：使用 Agent Development Kit (ADK) 進行多代理路由、工具執行和狀態管理。
  • 垂直整合 (MCP)：這種方法使用 Model Context Protocol (MCP)，提供統一的方式，將 AI 應用程式連結至不同環境中的工具和資料來源。
  • 橫向自動化調度管理 (A2A)：這種方法使用 Agent-to-Agent (A2A) 通訊協定，讓不同系統上的專門代理安全協作，不需自訂整合代碼。

BigQuery 和資料庫整合模式摘要

下表匯總 BigQuery 和作業資料庫的特定實作模式：

模式 適用情境 優點 注意事項
單一代理整合 (直接 API)：應用程式直接呼叫 API，從資料來源傳回洞察資訊。 需要直接控管每個 API 呼叫的單一代理應用程式、原型或微服務。
  • 提供精細的控制功能，不依賴任何架構。
  • 提供最簡單的架構，適用於單一代理用途。
  • 支援有狀態和無狀態模式。
  • 您必須建構所有基礎架構，才能進行驗證、狀態管理、回應剖析、錯誤處理、串流和部署。
  • 不適合用於多重代理情境。
自訂自動化調度管理工具 (直接 API)：這種模式會使用根代理和函式呼叫，在對話式數據分析 API 與其他工具或服務之間轉送查詢。 在單一對話流程中，結合資料查詢與其他工作 (例如電子郵件或文件) 的應用程式。
  • 提供最大程度的自動化調度管理控制，不依賴任何架構。
  • 可讓您精確定義模型在工具之間的路由方式。
  • 適用於任何 Gemini 模型。
  • 需要手動管理工具定義、對話迴圈、多輪對話狀態、錯誤處理和部署作業。
  • 與使用 ADK 等框架相比，開發負擔可能會加重。
使用 BigQueryToolset (ADK) 進行結構定義導向整合：使用資料表參照快速傳回資料洞察的模式。 快速原型設計、資料治理較不重要的內部工具，或資料洞察是 ADK 代理中多項功能之一的情境。
  • 在 ADK 架構中提供最快的整合路徑。
  • 不需預先設定資料代理程式。
  • 直接使用資料庫資料表名稱。
  • 缺乏語意管理，僅根據結構定義推論生成 SQL。
  • 在 API 級別以無狀態模式運作。
  • 僅提供文字答案，不支援圖表。
與 DataAgentToolset (ADK) 整合並控管：參照代理 ID 查詢預先設定的資料代理。 需要一致資料存取權的正式版應用程式，或資料代理為可信賴、可重複使用元件的多代理系統。
  • 提供語意管理機制，並在所有消費者之間保持一致的行為。
  • 使用通過驗證的查詢和組織詞彙，提高準確度。
  • 確保資料代理可在 ADK、MCP 和直接 API 整合中重複使用。
  • 必須預先設定資料代理程式資源。
  • 在 API 級別以無狀態模式運作。
  • 只會傳回文字答案，不支援圖表。
自訂子代理 (ADK)：使用自訂代理類別直接連線至 API，並將資料區塊串流回傳給使用者的模式。 優先考量低回應延遲時間的面向使用者應用程式，或資料檢索會提供下游代理程式的多代理管道。
  • 即時提供串流意見回饋。
  • 可存取所有回覆類型，例如圖表、表格和 SQL。
  • 可透過工作階段狀態與其他 ADK 代理組合。
  • 需要投入更多開發心力，才能建構自訂 ADK 代理類別。
  • 您必須直接管理串流連線和回應剖析。
Model Context Protocol (MCP)：使用開放標準，將 AI 應用程式連結至不同環境中的資料來源和工具。 機構需要跨多個 AI 用戶端和 IDE 的工具互通性，或團隊需要從 ADK 架構、IDE 和自訂應用程式存取相同的資料工具。
  • 採用通用工具標準，可與任何符合 MCP 規範的用戶端搭配使用。
  • 將工具實作與消費者應用程式分離。
  • 提供代管伺服器選項，例如 Google Cloud MCP 伺服器。
  • 需要為工具箱伺服器建立額外的基礎架構層。
  • 與 ADK 工具組相比，整合程度較低。
  • 視 MCP Toolbox 的生態系統發展而定。
  • 以無狀態模式運作，您必須從外部管理多輪對話狀態。
Agent-to-Agent (A2A)：這個模式採用 A2A 通訊協定，這項開放標準可讓不同系統上的專用代理安全協作，不需自訂整合代碼。 高度分散的企業環境，其中中央路由器代理必須將工作委派給在不同系統或網路上運作的資料代理。
  • 減少在不同框架之間使用自訂整合代碼的需求。
  • 確保跨平台互通性順暢。
  • 提供安全且標準化的功能探索。
  • 與內部子代理相比，網路延遲時間較短。
  • 必須設定 A2A 伺服器設定。

直接整合 API

直接整合 API 可讓您精細控管應用程式的邏輯和架構，但您必須建構支援的基礎架構。採用這種做法時，您必須負責驗證、對話管理、回覆剖析和部署等工作。

本節涵蓋下列主題：

單一代理整合

如果採用單一代理整合，後端會使用 REST 或用戶端程式庫直接呼叫 Conversational Analytics API，並傳遞使用者的查詢和情境。這個模式適用於複雜度低的應用程式，例如網頁應用程式、內部即時通訊工具或微服務，這些應用程式會使用簡單的文字轉答案流程。您也可以將這個方法用於原型設計和概念驗證工作。

這個模式支援有狀態對話 (由 Google 管理對話記錄) 和無狀態對話 (由應用程式管理記錄)。

如需參考實作，請參閱 GitHub 上的 Conversational Analytics API 快速入門導覽課程或 Conversational Analytics API 黃金示範。

自訂自動調度管理工具整合

這種做法是建構根層級代理，做為應用程式的主要進入點和協調器。根代理使用標準 Gemini 模型，並透過函式呼叫功能配備工具。當使用者提出與資料相關的問題時，根代理會向對話式數據分析 API 發出工具呼叫、接收結果，然後繼續推論或呼叫其他下游工具。

呼叫函式包含下列階段：

  1. 宣告：將工具結構定義定義為 FunctionDeclaration 物件，其中包含參數定義。
  2. 叫用：模型會傳回結構化 functionCall 訊息，其中包含函式名稱和引數。
  3. 執行：應用程式執行 API 呼叫，並在 FunctionResponse 訊息中傳回結果。
  4. 合成：Gemini 模型會根據結果生成最終答案，或決定下一個動作。

如果使用者在執行其他工作時，可能會要求取得資料洞察，就適合採用這種做法。舉例來說，使用者可能會要求代理「顯示銷售資料，然後撰寫電子郵件草稿給銷售團隊」。根代理可將資料問題轉送至對話式數據分析 API，並使用其他工具處理非資料工作。

如需參考實作，請前往 GitHub 上的 Conversational Analytics API 黃金示範，查看 orchestrate 或 multimodal 頁面。

框架導向的自動化調度管理 (ADK)

Agent Development Kit (ADK) 是以程式碼為優先的框架，可用於建構 AI 代理，管理複雜的多代理轉送、工具執行和狀態管理。ADK 框架與 Gemini Enterprise 採用的框架相同。

使用 ADK 時，您可以將對話式數據分析 API 與其他工具和代理鏈結，執行複雜動作。

本節涵蓋下列主題：

與 BigQueryToolset 整合，由結構定義驅動

ADK 架構中的 BigQueryToolset 工具組包含預先建構的 ask_data_insights 工具。如要使用這項工具，請將資料表名稱和使用者問題傳遞給工具，工具就會使用內嵌內容呼叫對話式數據分析 API。

呼叫工具時，工具會傳送無狀態要求至對話式數據分析 API，其中包含指定的 BigQuery 資料表參照。API 會推論資料庫結構定義、生成並執行 SQL 查詢，然後傳回文字答案。接著，結果會以工具回覆的形式傳回 ADK 代理。

這個模式可有效快速地為代理新增對話式數據分析功能。不過，由於 API 呼叫是無狀態且缺乏管理，因此 API 生成的 SQL 完全以資料表結構定義為基礎，沒有語意護欄。這個模式的部署速度較快，但如果正式環境的商業邏輯會套用命名慣例、商業邏輯或存取控管機制，則風險較高。

與 DataAgentToolset 整合並受控管

ADK 架構中的 DataAgentToolset 工具組提供預先建構的整合功能，可依 ID 參照預先設定的資料代理。ADK 代理會將使用者的問題傳遞至 ask_data_agent 工具，該工具會使用指定的資料代理情境呼叫對話式數據分析 API。

您可以透過程式輔助方式，使用對話式數據分析 API 建立資料代理，或透過 Google Cloud 控制台中的「Agent Catalog」(代理目錄) 建立。資料代理程式配備下列元件：

  • 知識來源：代理可查詢的資料表、檢視表或 user-defined function (UDF)
  • 結構化背景資訊：資料表和資料欄的說明，可協助代理瞭解基礎資料
  • 指令：提供給代理的額外指引，說明如何解讀及查詢資料來源
  • 經驗證的查詢：預先驗證的 SQL 查詢，可做為常見問題的範例
  • 詞彙表：業務術語定義，協助代理理解特定領域的語言

如需透過代理目錄建立代理的詳細指南，請參閱 BigQuery 對話式數據分析程式碼實驗室。

由於代理是受控管的單元，因此無論由哪個應用程式或子代理呼叫，都會使用相同的可信任邏輯、情境和護欄。

進階使用者體驗整合與自訂子代理

BigQueryToolset 和 DataAgentToolset 工具組會等到 API 要求處理完畢，才向使用者傳回結果。由於 ADK 架構會將 API 視為工具，在完成前會封鎖回應，因此查詢時間較長時，使用者可能不會收到任何回饋。

如果應用程式優先考量低回應延遲時間，或資料擷取會提供給下游代理程式，您可以建構自訂 ADK 代理程式類別，直接連結至對話式數據分析 API，並以非同步方式將資料分塊串流回使用者。這個模式支援下列回應類型 (在產生時)：

  • 思考訊息：資料代理在解讀問題時的推論過程。
  • 進度訊息：擷取資料來源資料時的狀態更新。
  • 查詢生成：生成的 SQL 或 Looker 查詢，會以串流方式呈現。
  • Data：JSON 格式的資料結果。
  • 視覺化：Vega-Lite 圖表規格。
  • 摘要：最終的文字答案。

如需傳回資料類型的完整清單，請參閱 API 參考文件中的 SystemMessage 類型。

這種非同步方法可確保使用者不必等待複雜的資料擷取程序完全完成。資料代理在查詢過程中，會持續將增量更新 (例如文字摘要、原始資料或圖表設定) 分享到臨時共用工作區。接著，系統會即時向使用者顯示這項資料，並與專門的子代理共用，以便執行其他工作。

如需包含根代理、資料子代理和視覺化代理的參考實作，請參閱 GitHub 上的 ADK 串流示範。

垂直整合 (MCP)

Model Context Protocol (MCP) 是一項開放標準，可讓 AI 應用程式以統一的方式連結外部工具和資料來源。MCP 規範 AI 模型與所用工具之間的介面。

本節涵蓋下列主題：

對話式數據分析 API 遠端 MCP 伺服器

對話式數據分析 API 透過 Google 的代管 MCP 伺服器，在 https://geminidataanalytics.googleapis.com/mcp 提供遠端 MCP 伺服器。這個閘道提供統一、安全的 HTTP 和伺服器傳送事件 (SSE) 介面，讓第三方 AI 平台和 Google 代管平台 (例如 Gemini Enterprise) 中的根代理，能探索 Google Cloud中的專門資料代理並與其通訊。

根層級代理通訊總覽

外部或 Google 代管的根代理與對話式數據分析 API 之間的通訊涉及三個不同的角色：

  1. 資料操作員會在對話式數據分析介面中，建立及設定範圍資料代理，並清楚說明各代理可存取的資料來源和可回答的問題，然後與業務使用者共用這些代理。
  2. 平台管理員在代理平台中註冊自訂 MCP 連線，指向 https://geminidataanalytics.googleapis.com/mcp 端點。管理員會使用 Google 授權端點 (https://accounts.google.com/o/oauth2/v2/auth)、權杖端點 (https://oauth2.googleapis.com/token) 和必要的授權範圍 (https://www.googleapis.com/auth/geminidataanalytics 和 https://www.googleapis.com/auth/bigquery.readonly)，設定 OAuth 2.0 用戶端憑證 (用戶端 ID 和用戶端密鑰)。
  3. 業務使用者在代理平台中以自然語言提問。平台的根代理 (自動調度管理 LLM) 不會直接查詢原始資料庫，而是與對話式數據分析 API 遠端 MCP 伺服器通訊，找出相關的資料代理，將使用者的問題轉送至適當範圍的資料代理，並傳回綜合答案。
身分傳播

如果要求來自第三方或外部根代理，為維護企業資料治理，遠端 MCP 伺服器會強制執行端對端身分傳播：

  • 使用者委派驗證：企業使用者與根代理互動時，代理平台會透過 3-legged OAuth 2.0 流程驗證使用者，並在傳送至 MCP 閘道的要求 HTTP 標頭中，加入使用者委派的 OAuth 存取權杖。
  • 轉送使用者憑證 (EUC)：遠端 MCP 伺服器會驗證權杖，並透過 Conversational Analytics API 層，將使用者憑證傳播至基礎資料引擎，例如 BigQuery、Spanner、AlloyDB 和 Cloud SQL。
  • 受控管的資料存取權：由於查詢是使用已驗證使用者的身分執行，而非共用服務帳戶，因此基礎資料來源會自動強制執行現有的 IAM 權限、資料列層級和資料欄層級安全性政策，以及受控管的資料存取權邊界。使用者只能探索資料代理，以及查詢有權存取的資料集。
  • Looker 雙重身分模型：針對 BigQuery 和作業資料庫，系統會使用個別使用者轉送的 Google OAuth 憑證執行查詢。如果是 Looker 支援的資料代理，驗證程序會採用雙重身分模型：使用者的 Google OAuth 權杖會授權 Google IAM 中的資料代理存取權，但查詢會在 Looker 中執行，並使用 Looker API 使用者提供的憑證 (在對話工具的憑證區塊中傳遞)。Looker 模型存取權、權限和資料列層級規則會反映設定的 API 使用者，而非個別使用者的 Looker 身分。
根代理存取 API 方法的方式

MCP 用戶端連線至 https://geminidataanalytics.googleapis.com/mcp 時，會呼叫標準 MCP tools/list 方法，動態匯入對話式數據分析 API 公開的工具結構定義。接著，根代理會叫用這些 MCP 工具和資源，與對話式數據分析 API 互動。這些工具和資源會直接對應至基礎 REST API 方法：

MCP 工具或資源 對應的對話式數據分析 API 方法 根代理的使用方式
list_data_agents projects.locations.dataAgents.list

探索可用的資料代理。根代理會傳遞目標 PROJECT_ID (和 LOCATION)，並接收使用者有權存取的有效資料代理清單，包括每個代理的 ID 和說明。根代理會評估這些說明，判斷哪個資料代理能回答使用者的問題。

提示：在根代理的自訂系統指令中加入目標 PROJECT_ID，這樣根代理就不會提示企業使用者提供專案 ID。

get_data_agent

(或 gda://agents/AGENT_ID MCP 資源)

 projects.locations.dataAgents.get

檢查特定資料代理的中繼資料和背景資訊。如果僅憑代理說明無法轉送複雜的提示，根代理會傳遞目標 AGENT_ID，擷取設定詳細資料，例如連結的 BigQuery 資料表、系統指示、詞彙或經驗證的查詢。
chat projects.locations.chat

做為對話式查詢的執行 Proxy。如要查詢探索到的資料代理，根代理會傳遞 data_agent_context，其中包含代理的完整資源名稱 (projects/PROJECT_ID/locations/LOCATION/dataAgents/AGENT_ID) 和使用者的自然語言訊息 (messages)。如果是無狀態的臨時查詢，根代理可以改為傳遞 inline_context。這項工具會傳回自然語言答案、生成的 SQL 查詢、結果列、Vega-Lite 圖表規格和代理推論。

MCP Toolbox for Databases

您也可以透過開放原始碼 MCP Toolbox for Databases 伺服器，存取對話式數據分析 API。這個伺服器提供預先建構、與 MCP 相容的工具，可公開「對話式數據分析」API 中的 chat 方法：

MCP 是互通性層，可將數據分析功能做為工具提供給 MCP 相容用戶端，而非對話式數據分析 API 的獨立執行模型。

獨立和 ADK 架構的 MCP 實作模式

您可以透過下列模式導入 MCP：

模式 詳細資料
獨立 MCP (不含 ADK)

將 MCP Toolbox for Databases 伺服器做為獨立伺服器，連線至任何符合 MCP 規範的用戶端。這個模式通常用於下列工作：

  • IDE 整合：將 IDE (例如 Antigravity、Cursor 或 VS Code) 連結至伺服器，即可透過編輯器以對話方式查詢資料。
  • 自訂 MCP 用戶端：建構應用程式，使用伺服器在多個 AI 供應商之間提供統一的工具介面。
  • Gemini CLI：將 CLI 做為 MCP 用戶端，在終端機中進行資料對話。
ADK 中的 MCP

ADK 架構提供下列機制，可將 MCP 伺服器整合至 Agentic Workflows：

  • ToolboxToolset：MCP Toolbox for Databases 伺服器的特殊變體，支援多種驗證方式。
  • McpToolset：使用本機或遠端 MCP 伺服器連線，將 ADK 代理連至任何 MCP 伺服器。自動探索伺服器的工具，並提供給代理。

您也可以使用 FastMCP 架構建構 MCP 伺服器，將以 ADK 架構建構的工具，公開給任何符合 MCP 規範的用戶端。這樣一來，ADK 代理就能在其他生態系統中做為工具使用。

請根據應用程式的特定架構需求，選擇合適的整合模式：

  • 使用內建的 Agent Development Kit (ADK) 工具組 (例如 BigQueryToolset 或 DataAgentToolset)，可更緊密整合，且不依賴外部伺服器。如果系統完全位於 ADK 架構內，這個方法最合適。
  • 使用 MCP Toolbox 中的工具，可確保與符合 MCP 規範的用戶端互通。如果資料工具必須為多個消費者應用程式或第三方 IDE 提供服務，這個方法就很合適。

水平自動化調度管理 (A2A)

Agent-to-Agent (A2A) 通訊協定是一項開放標準，可讓不同系統上的專門代理安全地通訊及協作，不需自訂整合代碼。

隨著系統規模擴大，組織通常會部署多個專用代理，這些代理是以不同的框架或雲端基礎架構建構而成。A2A 為這些自主代理建立通用訊息層，每個代理不使用自訂 API，而是發布代理資訊卡，這是一種可供探索的設定檔，詳細說明代理的功能、支援的資料格式和安全需求。

當中央自動調度管理工具或對等代理需要分析資料時，會透過結構化 A2A 訊息，安全地將任務委派給資料代理。資料代理會自主處理要求並傳回結果，將執行邏輯與要求者分離。

如要瞭解如何使用 A2A 通訊協定探索代理資訊卡、傳送訊息及串流結構化構件，請參閱「使用 A2A 自動調度管理資料代理」。

選擇整合模式

請參閱下表，比較各項整合模式的複雜度、管理方式和功能。

複雜度等級定義如下：

  • 低：需要最少自訂程式碼，並依賴預先建構的使用者介面或工具。
  • 中：需要自訂前端開發和 API 或 SDK 整合，但避免複雜的後端自動化調度管理基礎架構。
  • 高：需要全端應用程式開發、對話狀態管理、多個驗證層或中繼自動化調度管理基礎架構的模式。
  • 不一：複雜度取決於所選基礎整合方法的模式。
整合模式 複雜度 自訂 Agent Governance 存取控管 多代理 串流 可攜性
Looker iframe 嵌入 低 低 透過 Looker 管理 Looker 否 內建 僅限 Looker
Looker API 和 SDK 中 高 透過 Looker 管理 Looker 否 內建 僅限 Looker
對話式數據分析 API (Looker 來源) 因解決方案而異 高 透過 API 管理 Looker 和 IAM 是 是 任何 Google Cloud 平台
單一代理 (直接 API) 中 高 透過 API 管理 IAM 否 是 (支援) 任何 Google Cloud 平台
自訂自動調度管理工具 高 極高 透過 API 管理 IAM 手動 手動 任何 Google Cloud 平台
使用 BigQueryToolset (ADK) 建立結構定義導向的代理 低 中 無 (結構定義推論) IAM 是 (ADK) 否 (阻斷) ADK 生態系統
使用 DataAgentToolset (ADK) 控管 低 中 透過 API 管理 IAM 是 (ADK) 否 (阻斷) ADK 生態系統
自訂串流子代理 (ADK) 高 極高 透過 API 管理 IAM 是 (ADK) 是 (自訂) ADK 生態系統
獨立 MCP 中 中 無 (結構定義推論) IAM 否 否 任何 MCP 用戶端
ADK 中的 MCP 中 高 無 (結構定義推論) IAM 是 (ADK) 否 ADK 和 MCP 用戶端
A2A 通訊協定 高 高 依賴架構 IAM 是 是 跨平台

後續步驟