Integrationsmuster für Daten-Agents

Auf dieser Seite werden Integrationsmuster zum Einbetten von Data-Agent-Funktionen in Ihre Anwendungen beschrieben. Diese Muster reichen von einer eingebetteten Chatkomponente bis hin zu einem orchestrierten Multi-Agenten-System.

Dieser Leitfaden richtet sich an Cloud-Architekten und Data Engineers, die generative KI-Anwendungen entwickeln. Sie sollten ein grundlegendes Verständnis von Google Cloud Konzepten, Identity and Access Management und REST APIs haben. Außerdem sollten Sie mit der Architektur der Datenquelle vertraut sein, die von Ihrer Anwendung verwendet wird.

Übersicht über Integrationsmuster

Dieser Leitfaden ist je nach Ausgangspunkt in die folgenden Hauptbereiche unterteilt:

  • Looker-Track: Wählen Sie diesen Track aus, wenn Sie Chatfunktionen über die Looker-Einbettung, die Looker API oder die konversationelle Analyse API bereitstellen möchten.
  • BigQuery- und Datenbank-Track: Wählen Sie diesen Track aus, wenn Sie eine benutzerdefinierte Anwendung erstellen, die BigQuery, Data Studio oder eine unterstützte operative Datenbank verwendet.

In der folgenden Tabelle sind die verfügbaren Integrationsmuster zusammengefasst:

Integrationsmuster Beschreibung Datenquelle
Looker-iFrame-Einbettung Fügt einer Anwendung die Standard-Chatoberfläche hinzu. Dazu ist nur minimaler Code erforderlich. Looker
Looker API und SDKs Erstellt eine benutzerdefinierte Chatoberfläche, die die Looker API zur Authentifizierung verwendet. Looker
Konversationelle Analyse API (Looker-Quelle) Verwaltet Looker-Daten-Agents als Google Cloud Ressourcen, die auf mehreren Oberflächen und in Multi-Agent-Systemen funktionieren. Looker
Direct API (single-agent) Verwendet eine direkte API-Integration für Text-to-Answer-Abläufe. BigQuery, Datenbanken, Looker
Direct API (Orchestrator) Leitet Anfragen zwischen der API und anderen Tools mithilfe von Funktionsaufrufen weiter. BigQuery, Datenbanken, Looker
ADK (schemabasiert) mit BigQueryToolset Mit dem Tool ask_data_insights lassen sich schnell Erkenntnisse aus Tabellenbezügen gewinnen. BigQuery
ADK (governed) mit DataAgentToolset Fragt vorkonfigurierte Daten-Agents ab, die das ask_data_agent-Tool verwenden, um einheitliches Verhalten zu gewährleisten. BigQuery, Datenbanken, Looker
ADK (benutzerdefiniertes Streaming) Unterstützt das Echtzeit-Streaming von Diagrammen und SQL mithilfe einer benutzerdefinierten Agent-Klasse. BigQuery, Datenbanken, Looker
MCP mit McpToolset oder ToolboxToolset Verbindet Anwendungen mit Datentools, die das Model Context Protocol (MCP) verwenden. BigQuery Looker
A2A-Protokoll Ermöglicht die sichere Zusammenarbeit zwischen spezialisierten Agenten, die auf verschiedenen Systemen ausgeführt werden. Framework-abhängig

Einbindungsoptionen für Looker

Wenn Sie Looker verwenden, können Sie Ihren Nutzern Looker Conversational Analytics über die folgenden Muster zur Verfügung stellen:

Zusammenfassung der Looker-Integrationsmuster

In der folgenden Tabelle sind die primären Integrationsmuster für Looker zusammengefasst:

Muster Optimal für Vorteile Hinweise
Mit iFrames einbetten: Eine Low-Code-Methode, mit der Sie einer Anwendung schnell die standardmäßige Looker-Chatfunktion hinzufügen können. Teams, die eine produktionsreife Lösung für die Analyse von Unterhaltungen mit minimalem benutzerdefinierten Entwicklungsaufwand benötigen.
  • Die Implementierung erfordert nur minimalen Code.
  • Das vorhandene Looker-Sicherheitsmodell wird automatisch erzwungen.
  • Es ist keine separate Google Cloud Authentifizierung erforderlich.
  • Unterstützt das Looker Embed SDK, das die Entwicklung beschleunigt, indem es den Lebenszyklus von iFrames und die Übergabe von Ereignissen verwaltet.
  • Bietet nur begrenzte Anpassungsmöglichkeiten für die Benutzeroberfläche und basiert auf der Standard-Chat-Benutzeroberfläche von Looker.
  • Ihre Looker-Instanz muss von Looker gehostet werden.
Mit der Looker API und den SDKs entwickeln: Ein flexibler Ansatz zum Erstellen einer benutzerdefinierten Chatoberfläche, bei dem die Authentifizierung und die Agent-Verwaltung in Looker erfolgen. Teams, die eine benutzerdefinierte Chat-Benutzeroberfläche benötigen, aber die Nutzerauthentifizierung und die Agent-Verwaltung im Looker-Ökosystem beibehalten möchten. Dieses Muster eignet sich ideal für Anwendungen, in denen bereits Looker-Einbettungen oder die API verwendet werden.
  • Bietet eine einzelne Authentifizierungsebene und vollständige Kontrolle über die Benutzeroberfläche.
  • Vereinfacht die Architektur für bestehende Looker-Kunden.
  • Verwendet den semantischen Layer von Looker, um die Genauigkeit von Abfragen zu verbessern.
  • Es ist keine separate Google Cloud Authentifizierung erforderlich.
  • Erfordert Fachwissen in der Looker API-Entwicklung.
  • Auf Looker-Datenquellen beschränkt.
  • Agents werden in Looker verwaltet und können nicht auf andere Google Cloud Dienste übertragen werden.
Konversationelle Analyse API verwenden: Direkte Integration mit der API, um Agenten als Ressourcen auf Cloud-Ebene zu verwalten. Looker-Kunden, die eine plattformübergreifende Portabilität für ihre Daten-Agents benötigen.
  • Sorgt dafür, dass der Daten-Agent auf allen Google Cloud Plattformen portierbar ist.
  • Zentral über Identity and Access Management verwaltet.
  • Ermöglicht die Integration von Daten-Agents in ADK- oder MCP-Workflows.
  • Erfordert, dass Sie den gesamten Integrationsstack verwalten, einschließlich der Google Cloud - und Looker-Authentifizierung.
  • Daten-Agents werden unabhängig von der Looker-Benutzeroberfläche verwaltet.

Mit iFrames einbetten

Sie können konversationelle Analysen als iFrame einbetten, um die Chatfunktion außerhalb der Looker-Benutzeroberfläche bereitzustellen. Dieses Muster ist eine direkte Möglichkeit, konversationelle Analyse bereitzustellen, ohne dass eine benutzerdefinierte UI-Entwicklung, Backend-Orchestrierung oder API-Statusverwaltung erforderlich ist. Wenn Sie dieses Muster verwenden möchten, fügen Sie eine vorformatierte URL in Ihre Anwendung ein.

Das Looker Embed SDK bietet Tools zum Verwalten von Aufgaben wie der sicheren URL-Generierung, der iframe-Lebenszyklusverwaltung und der Übergabe von JavaScript-Ereignissen zwischen der Hostanwendung und dem iframe. Sie können die Seite Agents, die Seite Conversations oder eine bestimmte Unterhaltung einbetten, indem Sie eine vorformatierte URL in Ihre Anwendung einfügen.

Sie können die folgenden Authentifizierungsmethoden für eingebettete Inhalte verwenden:

  • Privates Einbetten: Nutzer werden mit ihren vorhandenen Looker-Anmeldedaten authentifiziert. Wenn Sie die Einbettungs-URL als iFrame-Quelle festlegen, melden sich Nutzer mit ihren Looker-Konten an. Bei dieser Methode werden vorhandene Rollen, der Zugriff auf Inhalte und Berechtigungen auf Datenebene wie Zugriffsfilter oder Zugriffsberechtigungen automatisch erzwungen, ohne dass eine zusätzliche Identity and Access Management-Konfiguration oder Tokenzuordnung erforderlich ist.
  • Signierte Einbettung: Nutzer werden über Ihre Anwendung mithilfe der Einmalanmeldung (SSO) authentifiziert. Sie erstellen eine signierte URL, die den Inhaltspfad für die konversationelle Analyse enthält. So können Sie dynamisch festlegen, welche Berechtigungen gewährt werden sollen.

Mit der Looker API und den SDKs entwickeln

Wenn Sie mehr Flexibilität beim Chat wünschen, können Sie die ConversationalAnalytics-Methoden in der Looker API verwenden oder mit einem Looker SDK eine benutzerdefinierte Anwendung erstellen. Mit diesem Ansatz können Sie ein benutzerdefiniertes Frontend erstellen, das direkt mit Looker-Endpunkten kommuniziert.

Die Integration in die Looker API bietet folgende Vorteile:

  • Sie verwalten die Authentifizierung nur mit Looker. Sie müssen sich nicht separat bei der API für konversationelle Analyse authentifizieren.
  • Für Anwendungen, die bereits Looker-Einbettung oder die API verwenden, wird durch dieses Muster die Projektarchitektur vereinfacht, da keine sekundären Authentifizierungsmechanismen erforderlich sind und keine externen Daten-Agents verwaltet werden müssen.
  • Sie haben die volle Kontrolle über die Chatoberfläche, den Konversationsablauf und die Art und Weise, wie die Anwendung Ergebnisse (z. B. Diagramme und Tabellen) rendert.

Eine Referenzimplementierung finden Sie im Leitfaden zur konversationellen Analyse-Looker-API auf GitHub.

Konversationelle Analyse API mit Looker-Daten verwenden

Wenn Sie eine der folgenden Aufgaben ausführen müssen, können Sie die konversationelle Analyse API unter geminidataanalytics.googleapis.com direkt einbinden:

  • Denselben Daten-Agent auf mehreren Google Cloud Oberflächen wie benutzerdefinierten Webanwendungen, Google Chat und Gemini Enterprise verwenden
  • Looker-Datenquellen mit BigQuery- oder operativen Datenbankquellen in einem einzigen Multi-Agent-System kombinieren
  • Daten-Agent als Ressource auf Cloud-Ebene verwalten, die Identity and Access Management und nicht dem Looker-Berechtigungsmodell unterliegt

Weitere Informationen zu gängigen Architekturmustern für die konversationelle Analyse-API finden Sie unter Integrationsoptionen für BigQuery und Datenbanken.

Integrationsoptionen für BigQuery und Datenbanken

In diesem Abschnitt werden Architekturmuster für Anwendungen beschrieben, die BigQuery, Data Studio oder unterstützte Google Cloud operative Datenbanken verwenden, um benutzerdefinierte Funktionen mit der konversationellen Analyse API zu erstellen.

Wenn Sie die konversationelle Analyse API mit einer Looker-Datenquelle verwenden, gelten die in diesem Abschnitt beschriebenen Muster auch für Ihre Integration.

Die Conversational Analytics API bietet die folgenden primären Methoden für die Interaktion mit Daten:

  • chat-Methode: Unterstützt BigQuery, Looker, Data Studio und operative Datenbanken.
  • queryData-Methode: Unterstützt operative Datenbanken wie AlloyDB, GoogleSQL for Spanner, Cloud SQL for MySQL und Cloud SQL for PostgreSQL.

Wenn Sie eine benutzerdefinierte Anwendung erstellen, können Sie eines oder mehrere der folgenden Integrationsmuster verwenden:

  • Direkte API-Integration: Ein benutzerdefinierter Ansatz, der die größte Flexibilität bietet, aber die Entwicklung der Infrastruktur für Authentifizierung, Konversationsverwaltung und Antwortparsing erfordert.
  • Framework-basierte Orchestrierung (ADK): Ein Ansatz, bei dem das Agent Development Kit (ADK) für das Multi-Agent-Routing, die Tool-Ausführung und die Zustandsverwaltung verwendet wird.
  • Vertikale Integration (MCP): Ein Ansatz, bei dem das Model Context Protocol (MCP) verwendet wird, um eine einheitliche Möglichkeit zu bieten, KI-Anwendungen in verschiedenen Umgebungen mit Tools und Datenquellen zu verbinden.
  • Horizontale Orchestrierung (A2A): Ein Ansatz, bei dem das Agent-to-Agent-Protokoll (A2A) verwendet wird, damit spezialisierte Agenten auf verschiedenen Systemen sicher zusammenarbeiten können, ohne dass benutzerdefinierter Integrationscode erforderlich ist.

Zusammenfassung der BigQuery- und Datenbankintegrationsmuster

In der folgenden Tabelle sind die spezifischen Implementierungsmuster für BigQuery und operative Datenbanken zusammengefasst:

Muster Optimal für Vorteile Hinweise
Integration mit einem einzelnen Agenten (direkte API): Ein Muster, bei dem Ihre Anwendung die API direkt aufruft, um Statistiken aus Ihren Datenquellen zurückzugeben. Anwendungen mit einem einzelnen Agent, Prototypen oder Mikrodienste, die eine direkte Kontrolle über jeden API-Aufruf erfordern.
  • Bietet eine detaillierte Steuerung ohne Framework-Abhängigkeiten.
  • Bietet die einfachste Architektur für Anwendungsfälle mit einem einzelnen Agent.
  • Unterstützt sowohl zustandsorientierte als auch zustandslose Modi.
  • Sie müssen die gesamte Infrastruktur für Authentifizierung, Statusverwaltung, Parsing von Antworten, Fehlerbehandlung, Streaming und Bereitstellung selbst entwickeln.
  • Nicht gut für Multi-Agent-Szenarien geeignet.
Benutzerdefinierter Orchestrator (direkte API): Ein Muster, bei dem ein Stamm-Agent und Funktionsaufrufe verwendet werden, um Anfragen zwischen der konversationellen Analyse-API und anderen Tools oder Diensten weiterzuleiten. Anwendungen, die Datenabfragen mit anderen Aufgaben wie E-Mails oder Dokumenten in einem einzigen Konversationsablauf kombinieren.
  • Bietet maximale Orchestrierungssteuerung ohne Framework-Abhängigkeiten.
  • Damit können Sie genau festlegen, wie das Modell zwischen Tools wechselt.
  • Funktioniert mit jedem Gemini-Modell.
  • Erfordert, dass Sie Tooldefinitionen, Konversationsschleifen, Multi-Turn-Status, Fehlerbehandlung und Bereitstellung manuell verwalten.
  • Der Entwicklungsaufwand kann im Vergleich zur Verwendung eines Frameworks wie dem ADK sehr hoch sein.
Schemaorientierte Integration mit BigQueryToolset (ADK): Ein Muster, bei dem Tabellenreferenzen verwendet werden, um schnell Datenstatistiken zu erhalten. Schnelles Prototyping, interne Tools, bei denen Data Governance weniger kritisch ist, oder Szenarien, in denen Daten-Insights eine von mehreren Funktionen in einem ADK-Agenten sind.
  • Bietet den schnellsten Integrationspfad im ADK-Framework.
  • Es ist keine Vorabkonfiguration des Daten-Agents erforderlich.
  • Funktioniert direkt mit Datenbanktabellennamen.
  • Es fehlt die semantische Steuerung und SQL wird nur aus der Schemaableitung generiert.
  • Funktioniert auf API-Ebene im zustandslosen Modus.
  • Es werden nur Textantworten generiert und Diagramme werden nicht unterstützt.
Gesteuerte Integration mit DataAgentToolset (ADK): Ein Muster, bei dem ein vorkonfigurierter KI-Datenagent durch Verweisen auf die ID des Agenten abgefragt wird. Produktionsanwendungen, die einen konsistenten Datenzugriff erfordern, oder Multi-Agent-Systeme, in denen der Daten-Agent eine vertrauenswürdige, wiederverwendbare Komponente ist.
  • Bietet semantische Governance und einheitliches Verhalten für alle Nutzer.
  • Die Genauigkeit wird durch die Verwendung von bestätigten Abfragen und einem Unternehmensglossar verbessert.
  • Sorgt dafür, dass Daten-Agents in ADK-, MCP- und direkten API-Integrationen wiederverwendet werden können.
  • Dazu müssen Sie Daten-Agent-Ressourcen vorab konfigurieren.
  • Funktioniert auf API-Ebene im zustandslosen Modus.
  • Gibt nur Textantworten zurück und unterstützt keine Diagramme.
Benutzerdefinierte untergeordnete Agents (ADK): Ein Muster, bei dem eine benutzerdefinierte Agent-Klasse verwendet wird, um eine direkte Verbindung zur API herzustellen und Datenblöcke an den Nutzer zu streamen. Nutzerorientierte Anwendungen, bei denen eine niedrige Antwortlatenz Priorität hat, oder Multi-Agent-Pipelines, bei denen der Datenabruf nachgelagerte Agents speist.
  • Feedback in Echtzeit
  • Greift auf alle Antworttypen zu, z. B. Diagramme, Tabellen und SQL.
  • Über den Sitzungsstatus kann er mit anderen ADK-Agents kombiniert werden.
  • Für die Entwicklung einer benutzerdefinierten ADK-Agentenklasse ist mehr Entwicklungsaufwand erforderlich.
  • Sie müssen die Streamingverbindung und das Parsen der Antwort direkt verwalten.
Model Context Protocol (MCP): Ein Muster, das einen offenen Standard verwendet, um KI-Anwendungen mit Datenquellen und Tools in verschiedenen Umgebungen zu verbinden. Organisationen, die eine Tool-Interoperabilität über mehrere KI-Clients und IDEs hinweg benötigen, oder Teams, die auf dieselben Datentools über das ADK-Framework, IDEs und benutzerdefinierte Anwendungen zugreifen müssen.
  • Es wird ein universeller Tool-Standard verwendet, der mit jedem MCP-kompatiblen Client funktioniert.
  • Entkoppelt die Tool-Implementierung von Verbraucheranwendungen.
  • Bietet Optionen für verwaltete Server, z. B. den Google Cloud MCP-Server.
  • Erfordert eine zusätzliche Infrastrukturschicht für den Toolbox-Server.
  • Bietet eine weniger enge Integration als die Toolsets des Agent Development Kit (ADK).
  • Hängt von der sich entwickelnden Umgebung der MCP Toolbox ab.
  • Der Modus ist zustandslos. Sie müssen den Status von Unterhaltungen mit mehreren Runden extern verwalten.
Agent-to-Agent (A2A): Ein Muster, das das A2A-Protokoll verwendet, einen offenen Standard, mit dem spezialisierte Agents auf verschiedenen Systemen sicher zusammenarbeiten können, ohne dass benutzerdefinierter Integrationscode erforderlich ist. Stark verteilte Unternehmensumgebungen, in denen ein zentraler Routing-Agent Aufgaben an Daten-Agents delegieren muss, die auf verschiedenen Systemen oder in verschiedenen Netzwerken ausgeführt werden.
  • Es ist weniger benutzerdefinierter Integrationscode zwischen verschiedenen Frameworks erforderlich.
  • Sorgt für nahtlose plattformübergreifende Interoperabilität.
  • Bietet eine sichere und standardisierte Erkennung von Funktionen.
  • Im Vergleich zu internen Sub-Agents wird eine geringe Netzwerklatenz eingeführt.
  • Dazu müssen Sie A2A-Servereinstellungen konfigurieren.

Direkte API-Verknüpfung

Die direkte API-Integration bietet eine detaillierte Steuerung der Logik und Architektur Ihrer Anwendung, erfordert jedoch, dass Sie die unterstützende Infrastruktur selbst erstellen. Bei diesem Ansatz sind Sie für Aufgaben wie Authentifizierung, Konversationsverwaltung, Parsing von Antworten und Bereitstellung verantwortlich.

In diesem Abschnitt werden die folgenden Themen behandelt:

Integration eines einzelnen Agents

Bei einer Integration mit einem einzelnen Agent ruft Ihr Backend die konversationelle Analyse API direkt über REST oder eine Clientbibliothek auf und übergibt die Anfrage und den Kontext des Nutzers. Dieses Muster eignet sich für Anwendungen mit geringer Komplexität, z. B. Web-Apps, interne Chat-Tools oder Mikrodienste, die einen einfachen Text-zu-Antwort-Ablauf verwenden. Sie können diesen Ansatz auch für Prototypen und Proof-of-Concept-Arbeiten verwenden.

Dieses Muster unterstützt sowohl zustandsorientierte Chats, bei denen Google den Unterhaltungsverlauf verwaltet, als auch zustandslose Chats, bei denen Ihre Anwendung den Verlauf verwaltet.

Referenzimplementierungen finden Sie in der Kurzanleitung zur konversationellen Analyse-API oder in der Golden Demo zur konversationellen Analyse-API auf GitHub.

Benutzerdefinierte Orchestrator-Integration

Bei diesem Ansatz erstellen Sie einen Stamm-Agenten, der als primärer Einstiegspunkt und Koordinator für Ihre Anwendung fungiert. Der Stamm-Agent verwendet ein Standard-Gemini-Modell, das über Funktionsaufrufe mit Tools ausgestattet ist. Wenn ein Nutzer eine datenbezogene Frage stellt, gibt der Stamm-Agent einen Tool-Aufruf an die konversationelle Analyse API aus, empfängt das Ergebnis und kann dann mit der Schlussfolgerung fortfahren oder andere Tools aufrufen.

Funktionsaufrufe umfassen die folgenden Phasen:

  1. Deklarieren: Definieren Sie Tool-Schemas als FunctionDeclaration-Objekte, die Parameterdefinitionen enthalten.
  2. Aufrufen: Das Modell gibt eine strukturierte functionCall-Nachricht mit dem Funktionsnamen und den Argumenten zurück.
  3. Ausführen: Ihre Anwendung führt den API-Aufruf aus und gibt das Ergebnis in einer FunctionResponse-Nachricht zurück.
  4. Synthetisieren: Das Gemini-Modell verwendet das Ergebnis, um eine endgültige Antwort zu generieren oder die nächste Aktion zu bestimmen.

Dieser Ansatz eignet sich für Anwendungen, in denen Nutzer neben anderen Aufgaben auch Datenstatistiken anfordern können. Ein Nutzer könnte den Agenten beispielsweise bitten, „Zeige mir die Verkaufszahlen und verfasse dann eine E-Mail an das Vertriebsteam.“ Der Stamm-Agent kann die Datenfrage an die konversationelle Analyse API weiterleiten und andere Tools für Aufgaben verwenden, die nicht mit Daten zusammenhängen.

Eine Referenzimplementierung finden Sie auf den Seiten orchestrate oder multimodal in der Golden Demo der konversationellen Analyse-API auf GitHub.

Framework-basierte Orchestrierung (ADK)

Das Agent Development Kit (ADK) ist ein Code-First-Framework zum Erstellen von KI-Agenten, das die Komplexität von Multi-Agent-Routing, Tool-Ausführung und Statusverwaltung bewältigt. Das ADK-Framework ist dasselbe Framework, das auch Gemini Enterprise zugrunde liegt.

Mit dem ADK können Sie die konversationelle Analyse mit anderen Tools und Agenten verknüpfen, um komplexe Aktionen auszuführen.

In diesem Abschnitt werden die folgenden Themen behandelt:

Schemaorientierte Integration mit BigQueryToolset

Das BigQueryToolset-Toolset im ADK-Framework enthält ein vorgefertigtes ask_data_insights-Tool. Um dieses Tool zu verwenden, übergeben Sie Tabellennamen und die Frage des Nutzers an das Tool, das dann die konversationelle Analyse-API mit Inline-Kontext aufruft.

Wenn Sie das Tool aufrufen, wird eine statuslose Anfrage mit den angegebenen BigQuery-Tabellenreferenzen an die Conversational Analytics API gesendet. Die API leitet das Datenbankschema ab, generiert und führt die SQL-Abfrage aus und gibt eine Textantwort zurück. Das Ergebnis wird dann als Tool-Antwort an den ADK-Agenten zurückgegeben.

Dieses Muster ist eine effektive Möglichkeit, einem Agenten schnell konversationelle Analysen hinzuzufügen. Da der Aufruf der API jedoch zustandslos ist und keine Governance-Funktionen bietet, wird SQL ausschließlich auf Grundlage des Tabellenschemas ohne semantische Einschränkungen generiert. Dadurch lässt sich das Muster schneller bereitstellen, es ist aber riskanter für die Produktionsgeschäftslogik, in der Namenskonventionen, Geschäftslogik oder Zugriffssteuerungen gelten.

Geregelte Integration in DataAgentToolset

Das DataAgentToolset-Toolset im ADK-Framework bietet eine vorgefertigte Integration, die anhand ihrer ID auf einen vorkonfigurierten KI-Datenagenten verweist. Der ADK-Agent übergibt die Frage des Nutzers an das Tool ask_data_agent, das die Conversational Analytics API mit dem angegebenen Kontext des Daten-KI-Agenten aufruft.

Sie können einen Datenagenten programmatisch über die konversationelle Analyse-API oder über den Agent Catalog in der Google Cloud Console erstellen. Ein Daten-Agent enthält die folgenden Komponenten:

  • Wissensquellen: Tabellen, Ansichten oder benutzerdefinierte Funktionen (User-Defined Functions, UDFs), die der Agent abfragen kann
  • Strukturierter Kontext: Beschreibungen für Tabellen und Spalten, die dem KI-Agenten helfen, die zugrunde liegenden Daten zu verstehen
  • Anweisungen: Zusätzliche Anleitung für den Agenten zum Interpretieren und Abfragen der Datenquellen
  • Bestätigte Abfragen: Vorab validierte SQL-Abfragen, die als Beispiele für häufige Fragen dienen
  • Glossar: Definitionen von Geschäftsbegriffen, die dem KI-Agenten helfen, fachspezifische Sprache zu verstehen

Eine ausführliche Anleitung zum Erstellen von Agenten über den Agent-Katalog finden Sie im Codelab Konversationsanalysen in BigQuery.

Da der Agent als verwaltete Einheit definiert ist, verwendet er dieselbe vertrauenswürdige Logik, denselben Kontext und dieselben Schutzmaßnahmen, unabhängig davon, welche Anwendung oder welcher Sub-Agent ihn aufruft.

Erweiterte UX-Integration mit benutzerdefinierten untergeordneten Agenten

Die Toolsets BigQueryToolset und DataAgentToolset geben erst dann Ergebnisse an den Nutzer zurück, wenn die API-Anfrage verarbeitet wurde. Da das ADK-Framework die API als Tool behandelt, das Antworten bis zum Abschluss blockiert, erhalten Nutzer bei länger laufenden Anfragen möglicherweise kein Feedback.

Als Alternative für Anwendungen, bei denen eine niedrige Antwortlatenz Priorität hat oder bei denen der Datenabruf nachgelagerte Agents speist, können Sie eine benutzerdefinierte ADK-Agent-Klasse erstellen, die direkt mit der konversationellen Analyse API verbunden ist und Daten asynchron in Blöcken an den Nutzer streamt. Dieses Muster unterstützt die folgenden Antworttypen, sobald sie erstellt werden:

  • Gedankennachrichten: Der Reasoning-Prozess des Data-Agents bei der Interpretation der Frage.
  • Fortschrittsmeldungen: Statusaktualisierungen während des Datenabrufs für Datenquellen.
  • Abfragegenerierung: Die generierte SQL- oder Looker-Abfrage, die gestreamt wird, sobald sie erstellt ist.
  • Daten: Die Datenergebnisse im JSON-Format.
  • Visualisierung: Vega-Lite-Diagrammspezifikationen.
  • Zusammenfassung: Die endgültige textbasierte Antwort.

Eine vollständige Liste der zurückgegebenen Datentypen finden Sie in der API-Referenzdokumentation unter dem Typ SystemMessage.

Dieser asynchrone Ansatz sorgt dafür, dass Nutzer nicht warten müssen, bis ein komplexer Datenabrufprozess vollständig abgeschlossen ist. Während der Daten-Agent die Abfrage durchläuft, werden kontinuierlich inkrementelle Updates wie Textzusammenfassungen, Rohdaten oder Diagrammkonfigurationen in einem temporären, freigegebenen Arbeitsbereich geteilt. Diese Daten können dann in Echtzeit für den Nutzer gerendert und mit spezialisierten untergeordneten Agents geteilt werden, um zusätzliche Aufgaben auszuführen.

Eine Referenzimplementierung mit einem Root-Agent, einem Daten-Sub-Agent und einem Visualisierungs-Agent finden Sie in der ADK-Streamingdemo auf GitHub.

Vertikale Integration (MCP)

Das Model Context Protocol (MCP) ist ein offener Standard, der eine einheitliche Möglichkeit für KI-Anwendungen bietet, sich mit externen Tools und Datenquellen zu verbinden. MCP standardisiert die Schnittstelle zwischen KI-Modellen und den Tools, die sie verwenden.

In diesem Abschnitt werden die folgenden Themen behandelt:

MCP Toolbox for Databases

Es gibt zwar keinen dedizierten MCP-Server für die konversationelle Analyse-API, Sie können aber über den Server MCP Toolbox for Databases auf die API zugreifen. Dieser Open-Source-Server bietet vorgefertigte, MCP-kompatible Tools, die die Methode chat in der konversationellen Analyse API bereitstellen:

MCP ist eine Interoperabilitätsebene, die Analysefunktionen als Tools für MCP-kompatible Clients bereitstellt und kein separates Ausführungsmodell der konversationellen Analyse-API ist.

MCP-Implementierungsmuster für Standalone- und ADK-Architekturen

Sie können MCP mit den folgenden Mustern implementieren:

Muster Details
Eigenständiges MCP (ohne ADK)

Den MCP Toolbox for Databases-Server als eigenständigen Server verwenden, um eine Verbindung zu einem beliebigen MCP-kompatiblen Client herzustellen Dieses Muster wird häufig für die folgenden Aufgaben verwendet:

  • IDE-Integration: Verbinden Sie eine IDE wie Antigravity, Cursor oder VS Code mit dem Server, um Daten über einen Editor abzufragen.
  • Benutzerdefinierter MCP-Client: Erstellen Sie eine Anwendung, die den Server verwendet, um eine einheitliche Tool-Schnittstelle für mehrere KI-Anbieter bereitzustellen.
  • Gemini CLI: Verwenden Sie die CLI als MCP-Client für datenbezogene Unterhaltungen im Terminal.
MCP im ADK

Das ADK-Framework bietet die folgenden Mechanismen zum Einbinden von MCP-Servern in Agent-Workflows:

  • ToolboxToolset: Eine spezielle Variante für den MCP Toolbox for Databases-Server, die mehrere Authentifizierungsmethoden unterstützt.
  • McpToolset: Stellt eine Verbindung zwischen einem ADK-Agenten und einem beliebigen MCP-Server her, indem entweder lokale oder Remote-MCP-Serververbindungen verwendet werden. Erkennt automatisch die Tools des Servers und stellt sie dem Agenten zur Verfügung.

Sie können auch MCP-Server mit dem FastMCP-Framework erstellen, um Tools, die mit dem ADK-Framework erstellt wurden, für jeden MCP-kompatiblen Client verfügbar zu machen. So können Ihre ADK-Agents als Tools in anderen Ökosystemen verwendet werden.

Wählen Sie ein Integrationsmuster basierend auf den spezifischen Architekturanforderungen Ihrer Anwendung aus:

  • Die Verwendung integrierter Toolsets des Agent Development Kit (ADK) wie BigQueryToolset oder DataAgentToolset ermöglicht eine engere Integration ohne externe Serverabhängigkeiten. Dieser Ansatz ist ideal für Systeme, die vollständig im ADK-Framework enthalten sind.
  • Die Verwendung der Tools in der MCP Toolbox ermöglicht die Interoperabilität zwischen MCP-kompatiblen Clients. Dieser Ansatz ist ideal für Datentools, die mehrere Verbraucheranwendungen oder IDEs von Drittanbietern unterstützen müssen.

Horizontale Orchestrierung (A2A)

Das Agent-to-Agent-Protokoll (A2A) ist ein offener Standard, der es spezialisierten Agenten auf verschiedenen Systemen ermöglicht, sicher zu kommunizieren und zusammenzuarbeiten, ohne dass benutzerdefinierter Integrationscode erforderlich ist.

Wenn Systeme skaliert werden, stellen Unternehmen häufig mehrere spezialisierte Agents bereit, die auf verschiedenen Frameworks oder Cloud-Infrastrukturen basieren. A2A richtet eine universelle Messaging-Ebene für diese autonomen Agenten ein. Statt benutzerdefinierte APIs zu verwenden, veröffentlicht jeder Agent eine Agent-Karte. Das ist ein auffindbares Profil, in dem die Funktionen, unterstützten Datenformate und Sicherheitsanforderungen des Agents beschrieben werden.

Wenn ein zentraler Orchestrator oder Peer-Agent Analysedaten benötigt, wird die Aufgabe über strukturierte A2A-Nachrichten sicher an einen Datenagenten delegiert. Der Daten-Agent verarbeitet die Anfrage autonom und gibt die Ergebnisse zurück. Dadurch wird die Ausführungslogik vom Anfragenden entkoppelt.

Integrationsmuster auswählen

In der folgenden Tabelle können Sie die Komplexität, Governance und Funktionen der einzelnen Integrationsmuster vergleichen.

Die Komplexitätsstufen sind so definiert:

  • Niedrig: Muster, die nur minimalen benutzerdefinierten Code erfordern und auf vorgefertigten Benutzeroberflächen oder Tools basieren.
  • Mittel: Muster, die eine benutzerdefinierte Frontend-Entwicklung und API- oder SDK-Integration erfordern, aber eine komplexe Backend-Orchestrierungs-Infrastruktur vermeiden.
  • Hoch: Muster, die die Entwicklung von Full-Stack-Anwendungen, die Verwaltung des Konversationsstatus, mehrere Authentifizierungsebenen oder eine Orchestrator-Infrastruktur erfordern.
  • Variiert: Muster, bei denen die Komplexität von der zugrunde liegenden Integrationsmethode abhängt, die Sie auswählen.
Integrationsmuster Komplexität Anpassung KI-Agenten-Governance Zugriffssteuerung Mehrere Agents Streaming Portabilität
Looker-iFrame-Einbettung Niedrig Niedrig Über Looker verwaltet Looker Nein Integriert Nur Looker
Looker API und SDKs Mittel Hoch Über Looker verwaltet Looker Nein Integriert Nur Looker
Konversationelle Analyse API mit Looker-Quelle Variabel Hoch Über die API verwaltet Looker und IAM Ja Ja Beliebige Google Cloud Oberfläche
Einzelner Kundenservicemitarbeiter (direkte API) Mittel Hoch Über die API verwaltet IAM Nein Ja (unterstützt) Beliebige Google Cloud Oberfläche
Benutzerdefinierter Orchestrator Hoch Sehr hoch Über die API verwaltet IAM Manuell Manuell Beliebige Google Cloud Oberfläche
Schemaorientiert mit BigQueryToolset (ADK) Niedrig Mittel Keine (Schema-Inferenz) IAM Ja (ADK) Nein (blockierend) ADK-Ökosystem
Geregelt durch DataAgentToolset (ADK) Niedrig Mittel Über die API verwaltet IAM Ja (ADK) Nein (blockierend) ADK-Ökosystem
Benutzerdefinierter Streaming-Sub-Agent (ADK) Hoch Sehr hoch Über die API verwaltet IAM Ja (ADK) Ja (benutzerdefiniert) ADK-Ökosystem
Eigenständiges MCP Mittel Mittel Keine (Schema-Inferenz) IAM Nein Nein Beliebiger MCP-Client
MCP im ADK Mittel Hoch Keine (Schema-Inferenz) IAM Ja (ADK) Nein ADK- und MCP-Clients
A2A-Protokoll Hoch Hoch Framework-abhängig IAM Ja Ja Plattformübergreifend

Nächste Schritte