Pattern di integrazione per gli agenti di dati

Questa pagina descrive i pattern di integrazione per incorporare le esperienze degli agenti di dati nelle tue applicazioni. Questi pattern variano in complessità da un componente di chat incorporato a un sistema multi-agente orchestrato.

Questa guida è destinata agli architetti cloud e ai data engineer che progettano applicazioni di AI generativa. Devi avere una conoscenza di base dei concetti di Google Cloud , di Identity and Access Management e delle API REST. Devi anche conoscere l'architettura dell'origine dati utilizzata dalla tua applicazione.

Panoramica dei pattern di integrazione

Questa guida è organizzata nei seguenti percorsi principali in base al punto di partenza:

  • Traccia Looker: seleziona questa traccia se vuoi fornire funzionalità di chat tramite l'incorporamento di Looker, l'API Looker o l'API Analisi conversazionale.
  • BigQuery e traccia del database: seleziona questa traccia se stai creando un'applicazione personalizzata che utilizza BigQuery, Data Studio o un database operativo supportato.

La seguente tabella riepiloga i pattern di integrazione disponibili:

Pattern di integrazione Descrizione Origine dati
Incorporamento di iframe di Looker Aggiunge l'interfaccia di chat standard a un'applicazione che richiede un codice minimo. Looker
API Looker e SDK Crea un'interfaccia di chat personalizzata che utilizza l'API Looker per l'autenticazione. Looker
API Analisi conversazionale (origine Looker) Gestisce gli agenti dati di Looker come Google Cloud risorse che funzionano su più piattaforme e sistemi multi-agente. Looker
API diretta (single-agent) Utilizza un'integrazione API diretta per i flussi di testo in risposta. BigQuery, database, Looker
API diretta (orchestratore) Instrada le query tra l'API e altri strumenti utilizzando la chiamata di funzione. BigQuery, database, Looker
ADK (basato su schema) con BigQueryToolset Genera rapidamente approfondimenti dai riferimenti tabella utilizzando lo strumento ask_data_insights. BigQuery
ADK (governato) con DataAgentToolset Esegue query sugli agenti di dati preconfigurati che utilizzano lo strumento ask_data_agent per garantire un comportamento coerente. BigQuery, database, Looker
ADK (streaming personalizzato) Supporta lo streaming in tempo reale di grafici e SQL utilizzando una classe di agenti personalizzata. BigQuery, database, Looker
MCP con McpToolset o ToolboxToolset Collega le applicazioni agli strumenti di dati che utilizzano il Model Context Protocol (MCP). BigQuery Looker
Protocollo A2A Consente la collaborazione sicura tra agenti specializzati che operano su sistemi diversi. Dipendente dal framework

Opzioni di integrazione per Looker

Se utilizzi Looker, puoi fornire Analisi conversazionale di Looker ai tuoi utenti tramite i seguenti pattern:

Riepilogo dei pattern di integrazione di Looker

La tabella seguente riassume i principali pattern di integrazione per Looker:

Pattern Ideale per Vantaggi Considerazioni
Incorporamento con iframe: un metodo low-code per aggiungere rapidamente l'esperienza di chat standard di Looker a un'applicazione. Team che richiedono un'esperienza di analisi conversazionale pronta per la produzione con uno sviluppo personalizzato minimo.
  • Richiede un codice minimo per l'implementazione.
  • Applica automaticamente il modello di sicurezza Looker esistente.
  • Non richiede l'autenticazione Google Cloud separata.
  • Supporta l'SDK Embed di Looker, che accelera lo sviluppo gestendo i cicli di vita degli iframe e il passaggio degli eventi.
  • Offre una personalizzazione limitata della UI e dipende dalla UI utente standard della chat di Looker.
  • La tua istanza di Looker deve essere ospitata da Looker.
Crea con l'API Looker e gli SDK: un approccio flessibile per creare un'interfaccia di chat personalizzata mantenendo l'autenticazione e la gestione degli agenti in Looker. Team che richiedono un'esperienza utente di chat personalizzata, ma vogliono mantenere l'autenticazione utente e la gestione degli agenti all'interno dell'ecosistema Looker. Questo pattern è ideale per le applicazioni che utilizzano già l'incorporamento di Looker o l'API.
  • Fornisce un unico livello di autenticazione e il pieno controllo dell'interfaccia utente.
  • Semplifica l'architettura per i clienti Looker esistenti.
  • Utilizza il livello semantico di Looker per migliorare l'accuratezza delle query.
  • Non richiede l'autenticazione Google Cloud separata.
  • Richiede competenze di sviluppo dell'API Looker.
  • Limitato alle origini dati di Looker.
  • Gli agenti vengono gestiti in Looker e non sono trasferibili ad altri servizi Google Cloud .
Utilizza l'API Analisi conversazionale: integrazione diretta con l'API per gestire gli agenti come risorse a livello di cloud. Clienti Looker che richiedono la portabilità multipiattaforma per i propri agenti di dati.
  • Garantisce che l'agente di dati sia portatile su tutte le Google Cloud piattaforme.
  • Gestito centralmente da Identity and Access Management.
  • Consente di integrare gli agenti di dati nei workflow ADK o MCP.
  • Richiede la gestione dell'intero stack di integrazione, inclusa l'autenticazione Google Cloud e Looker.
  • Gli agenti di dati vengono gestiti indipendentemente dall'interfaccia utente di Looker.

Incorporare con gli iframe

Puoi incorporare Analisi conversazionale come iframe per offrire l'esperienza di chat al di fuori della UI di Looker. Questo pattern è un modo diretto per fornire Analisi conversazionale che non richiede lo sviluppo di UI personalizzate, l'orchestrazione del backend o la gestione dello stato dell'API. Per utilizzare questo pattern, aggiungi un URL preformattato alla tua applicazione.

L'SDK Embed di Looker fornisce strumenti che gestiscono attività come la generazione di URL sicuri, la gestione del ciclo di vita degli iframe e il passaggio di eventi JavaScript tra l'applicazione host e l'iframe. Puoi incorporare la pagina Agenti, la pagina Conversazioni o una conversazione specifica aggiungendo un URL preformattato all'applicazione.

Puoi utilizzare i seguenti metodi di autenticazione per i contenuti incorporati:

  • Incorporamento privato: autentica gli utenti con le loro credenziali Looker esistenti. Quando imposti l'URL di incorporamento come origine iframe, gli utenti accedono con i propri account Looker. Questo metodo applica automaticamente i ruoli, l'accesso ai contenuti e le autorizzazioni a livello di dati esistenti, come i filtri di accesso o le concessioni di accesso, senza richiedere ulteriori configurazioni di Identity and Access Management o mappatura dei token.
  • Incorporamento firmato: autentica gli utenti tramite la tua applicazione utilizzando Single Sign-On (SSO). Crea un URL firmato che includa il percorso dei contenuti di Analisi conversazionale, che ti consente di specificare in modo dinamico le autorizzazioni da concedere.

Creare con l'API Looker e gli SDK

Per una maggiore flessibilità nell'esperienza di chat, puoi utilizzare i metodi ConversationalAnalytics nell'API Looker o un SDK Looker per creare un'applicazione personalizzata. Questo approccio ti consente di creare un frontend personalizzato che comunica direttamente con gli endpoint di Looker.

L'integrazione con l'API Looker offre i seguenti vantaggi:

  • Gestisci solo l'autenticazione con Looker. Non è necessario eseguire l'autenticazione separatamente con l'API Analisi conversazionale.
  • Per le applicazioni che utilizzano già l'incorporamento di Looker o l'API, questo pattern semplifica l'architettura del progetto evitando meccanismi di autenticazione secondari ed eliminando la necessità di gestire agenti di dati esterni.
  • Hai il pieno controllo dell'interfaccia di chat, del flusso della conversazione e del modo in cui l'applicazione esegue il rendering dei risultati (ad esempio grafici e tabelle).

Per un'implementazione di riferimento, consulta la guida all'API Looker per l'analisi conversazionale su GitHub.

Utilizzare l'API Analisi conversazionale con i dati di Looker

Puoi eseguire l'integrazione direttamente con l'API Analisi conversazionale all'indirizzo geminidataanalytics.googleapis.com se devi eseguire una delle seguenti attività:

  • Condividere lo stesso agente di dati su più Google Cloud piattaforme, come applicazioni web personalizzate, Google Chat e Gemini Enterprise
  • Combinare le origini dati di Looker con le origini BigQuery o di database operativi in un unico sistema multiagente
  • Gestisci l'agente dati come risorsa a livello di cloud regolata da Identity and Access Management anziché dal modello di autorizzazioni di Looker

Per ulteriori informazioni sui pattern di architettura comuni per l'API Analisi conversazionale, consulta Opzioni di integrazione per BigQuery e database.

Opzioni di integrazione per BigQuery e database

Questa sezione descrive i pattern architetturali per le applicazioni che utilizzano BigQuery, Data Studio o database operativi Google Cloud supportati per creare esperienze personalizzate con l'API Analisi conversazionale.

Se utilizzi l'API Analisi conversazionale con un'origine dati di Looker, i pattern descritti in questa sezione si applicano anche alla tua integrazione.

L'API Analisi conversazionale fornisce i seguenti metodi principali per interagire con i dati:

  • Metodo chat: supporta BigQuery, Looker, Data Studio e i database operativi.
  • Metodo queryData: supporta database operativi come AlloyDB, GoogleSQL per Spanner, Cloud SQL per MySQL e Cloud SQL per PostgreSQL.

Quando crei un'applicazione personalizzata, puoi utilizzare uno o più dei seguenti pattern di integrazione:

  • Integrazione API diretta: un approccio personalizzato che offre la massima flessibilità, ma richiede di creare l'infrastruttura per l'autenticazione, la gestione delle conversazioni e l'analisi delle risposte.
  • Orchestrazione basata sul framework (ADK): un approccio che utilizza l'Agent Development Kit (ADK) per il routing multi-agente, l'esecuzione di strumenti e la gestione dello stato.
  • Integrazione verticale (MCP): un approccio che utilizza il Model Context Protocol (MCP) per fornire un modo uniforme per connettere le applicazioni AI a strumenti e origini dati in diversi ambienti.
  • Orchestrazione orizzontale (A2A): un approccio che utilizza il protocollo Agent-to-Agent (A2A) per consentire ad agenti specializzati su sistemi diversi di collaborare in modo sicuro senza richiedere codice di integrazione personalizzato.

Riepilogo dei pattern di integrazione di BigQuery e dei database

La tabella seguente riepiloga i pattern di implementazione specifici per BigQuery e i database operativi:

Pattern Ideale per Vantaggi Considerazioni
Integrazione di un singolo agente (API diretta): un pattern in cui l'applicazione chiama direttamente l'API per restituire approfondimenti dalle origini dati. Applicazioni, prototipi o microservizi con un singolo agente che richiedono il controllo diretto di ogni chiamata API.
  • Fornisce un controllo granulare senza dipendenze dal framework.
  • Fornisce l'architettura più semplice per i casi d'uso con un singolo agente.
  • Supporta le modalità stateful e stateless.
  • Richiede la creazione di tutta l'infrastruttura per l'autenticazione, la gestione dello stato, l'analisi della risposta, la gestione degli errori, lo streaming e il deployment.
  • Non è scalabile per scenari multi-agente.
Orchestratore personalizzato (API diretta): un pattern che utilizza un agente radice e la chiamata di funzioni per indirizzare le query tra l'API Analisi conversazionale e altri strumenti o servizi. Applicazioni che combinano query sui dati con altre attività, come email o documenti, in un unico flusso conversazionale.
  • Offre il massimo controllo dell'orchestrazione senza dipendenze dal framework.
  • Consente di definire esattamente il modo in cui il modello esegue il routing tra gli strumenti.
  • Funziona con qualsiasi modello Gemini.
  • Richiede la gestione manuale delle definizioni degli strumenti, dei loop di conversazione, dello stato multi-turn, della gestione degli errori e del deployment.
  • L'overhead di sviluppo potrebbe diventare oneroso rispetto all'utilizzo di un framework come ADK.
Integrazione basata sullo schema con BigQueryToolset (ADK): un pattern che utilizza i riferimenti alle tabelle per restituire rapidamente approfondimenti sui dati. Prototipazione rapida, strumenti interni in cui la governance dei dati è meno critica o scenari in cui gli approfondimenti sui dati sono una delle diverse funzionalità di un agente ADK.
  • Fornisce il percorso di integrazione più rapido all'interno del framework ADK.
  • Non richiede la preconfigurazione dell'agente dati.
  • Funziona direttamente con i nomi delle tabelle del database.
  • Non dispone di governance semantica e genera SQL solo dall'inferenza dello schema.
  • Funziona in modalità stateless a livello di API.
  • Fornisce risposte solo di testo e non supporta i grafici.
Integrazione controllata con DataAgentToolset (ADK): un pattern che esegue query su un agente di dati preconfigurato facendo riferimento al suo ID. Applicazioni di produzione che richiedono un accesso ai dati coerente o sistemi multi-agente in cui l'agente di dati è un componente riutilizzabile e attendibile.
  • Fornisce una governance semantica e un comportamento coerente per tutti i consumatori.
  • Migliora l'accuratezza utilizzando query verificate e un glossario aziendale.
  • Garantisce che gli agenti di dati siano riutilizzabili nelle integrazioni ADK, MCP e API dirette.
  • Richiede la preconfigurazione delle risorse dell'agente di dati.
  • Funziona in modalità stateless a livello di API.
  • Restituisce risposte di solo testo e non supporta i grafici.
Subagenti personalizzati (ADK): un pattern che utilizza una classe di agenti personalizzata per connettersi direttamente all'API e trasmettere i blocchi di dati all'utente. Applicazioni rivolte agli utenti in cui la bassa latenza di risposta è una priorità o pipeline multi-agente in cui il recupero dei dati alimenta gli agenti downstream.
  • Fornisce feedback in tempo reale sullo streaming.
  • Accede a tutti i tipi di risposta, come grafici, tabelle e SQL.
  • Componibile con altri agenti ADK tramite lo stato della sessione.
  • Richiede un maggiore impegno di sviluppo per creare una classe di agenti ADK personalizzata.
  • Richiede la gestione diretta dell'analisi della connessione di streaming e della risposta.
Model Context Protocol (MCP): un pattern che utilizza uno standard aperto per connettere le applicazioni AI a origini dati e strumenti in diversi ambienti. Organizzazioni che richiedono l'interoperabilità degli strumenti in più client AI e IDE o team che hanno bisogno che gli stessi strumenti per i dati siano accessibili dal framework ADK, dagli IDE e dalle applicazioni personalizzate.
  • Utilizza uno standard di strumenti universale che funziona con qualsiasi client conforme a MCP.
  • Disaccoppia l'implementazione dello strumento dalle applicazioni consumer.
  • Offre opzioni di server gestito, come il Google Cloud server MCP.
  • Richiede un livello di infrastruttura aggiuntivo per il server della casella degli strumenti.
  • Fornisce un'integrazione meno stretta rispetto ai toolset di Agent Development Kit (ADK).
  • Dipende dall'ecosistema in evoluzione di MCP Toolbox.
  • Funziona in modalità stateless, il che richiede di gestire esternamente lo stato multi-turn.
Da agente ad agente (A2A): un pattern che utilizza il protocollo A2A, uno standard aperto che consente ad agenti specializzati su sistemi diversi di collaborare in modo sicuro senza richiedere codice di integrazione personalizzato. Ambienti aziendali altamente distribuiti in cui un agente di routing centrale deve delegare le attività agli agenti di dati che operano su sistemi o reti diversi.
  • Riduce la necessità di codice di integrazione personalizzato tra framework diversi.
  • Garantisce un'interoperabilità multipiattaforma senza interruzioni.
  • Fornisce un rilevamento sicuro e standardizzato delle funzionalità.
  • Introduce una latenza di rete minima rispetto ai subagenti interni.
  • Richiede la configurazione delle impostazioni del server A2A.

Integrazione API diretta

L'integrazione diretta dell'API fornisce un controllo granulare sulla logica e sull'architettura dell'applicazione, ma richiede la creazione dell'infrastruttura di supporto. Con questo approccio, sei responsabile di attività come l'autenticazione, la gestione delle conversazioni, l'analisi delle risposte e il deployment.

Questa sezione tratta i seguenti argomenti:

Integrazione di un singolo agente

Con un'integrazione con un singolo agente, il backend chiama direttamente l'API Analisi conversazionale utilizzando REST o una libreria client e trasmette la query e il contesto dell'utente. Questo pattern è adatto ad applicazioni a bassa complessità, come app web, strumenti di chat interni o microservizi, che utilizzano un flusso di testo in risposta semplice. Puoi utilizzare questo approccio anche per la prototipazione e la prova di concetto.

Questo pattern supporta sia la chat stateful, in cui Google gestisce la cronologia della conversazione, sia la chat stateless, in cui la cronologia viene gestita dalla tua applicazione.

Per le implementazioni di riferimento, consulta l'guida rapida dell'Analisi conversazionale API o la demo golden dell'Analisi conversazionale API su GitHub.

Integrazione dell'orchestratore personalizzato

Con questo approccio, crei un agente principale che funge da punto di ingresso e coordinatore principale per la tua applicazione. L'agente principale utilizza un modello Gemini standard dotato di strumenti tramite la chiamata di funzione. Quando un utente pone una domanda relativa ai dati, l'agente principale emette una chiamata allo strumento all'API Analisi conversazionale, riceve il risultato e può quindi continuare il ragionamento o chiamare altri strumenti a valle.

La chiamata di funzione prevede le seguenti fasi:

  1. Dichiarare: definisci gli schemi degli strumenti come oggetti FunctionDeclaration che includono definizioni dei parametri.
  2. Invoke: il modello restituisce un messaggio functionCall strutturato che contiene il nome e gli argomenti della funzione.
  3. Esegui: la tua applicazione esegue la chiamata API e restituisce il risultato in un messaggio FunctionResponse.
  4. Sintetizza: il modello Gemini utilizza il risultato per generare una risposta finale o per determinare l'azione successiva.

Questo approccio è adatto alle applicazioni in cui gli utenti potrebbero richiedere approfondimenti sui dati insieme ad altre attività. Ad esempio, un utente potrebbe chiedere all'agente di "Mostrami le vendite, poi scrivi una bozza di email per il team di vendita". L'agente principale può indirizzare la domanda sui dati all'API Analisi conversazionale e utilizzare altri strumenti per le attività non correlate ai dati.

Per un'implementazione di riferimento, consulta le pagine orchestrate o multimodal nella demo golden dell'API Analisi conversazionale su GitHub.

Orchestrazione basata su framework (ADK)

Agent Development Kit (ADK) è un framework code-first per la creazione di agenti AI che gestisce la complessità del routing multi-agente, dell'esecuzione degli strumenti e della gestione dello stato. Il framework ADK è lo stesso che alimenta Gemini Enterprise.

Utilizzando l'ADK, puoi concatenare l'API Analisi conversazionale con altri strumenti e agenti per eseguire azioni complesse.

Questa sezione tratta i seguenti argomenti:

Integrazione basata su schema con BigQueryToolset

Il set di strumenti BigQueryToolset nel framework ADK include uno strumento ask_data_insights predefinito. Per utilizzare questo strumento, devi trasmettere i nomi delle tabelle e la domanda dell'utente allo strumento, che poi chiama l'API Analisi conversazionale utilizzando il contesto incorporato.

Quando chiami lo strumento, questo invia una richiesta stateless che include i riferimenti alla tabella BigQuery specificati all'API Analisi conversazionale. L'API deduce lo schema del database, genera ed esegue la query SQL e restituisce una risposta di testo. Il risultato viene quindi restituito all'agente ADK come risposta dello strumento.

Questo pattern è un modo efficace per aggiungere rapidamente l'analisi conversazionale a un agente. Tuttavia, poiché la chiamata all'API è stateless e priva di governance, l'API genera SQL basato interamente sullo schema della tabella senza guardrail semantici. Questo rende il pattern più veloce da implementare, ma più rischioso per la logica di business di produzione in cui si applicano convenzioni di denominazione, logica di business o controlli dell'accesso.

Integrazione controllata con DataAgentToolset

Il set di strumenti DataAgentToolset nel framework ADK fornisce un'integrazione predefinita che fa riferimento a un agente dati preconfigurato tramite il suo ID. L'agente ADK trasmette la domanda dell'utente allo strumento ask_data_agent, che chiama l'API Analisi conversazionale con il contesto dell'agente dati specificato.

Puoi creare un agente dati in modo programmatico utilizzando l'API Analisi conversazionale o tramite il catalogo degli agenti nella console Google Cloud . Un agente dati è dotato dei seguenti componenti:

  • Origini della conoscenza: tabelle, viste o funzioni definite dall'utente che l'agente può interrogare
  • Contesto strutturato: descrizioni per tabelle e colonne che aiutano l'agente a comprendere i dati sottostanti
  • Istruzioni: indicazioni aggiuntive per l'agente per interpretare ed eseguire query sulle origini dati
  • Query verificate: query SQL pre-validate che fungono da esempi per domande comuni
  • Glossario: definizioni dei termini aziendali che aiutano l'agente a comprendere il linguaggio specifico del dominio

Per una guida dettagliata alla creazione di agenti tramite il catalogo degli agenti, consulta il codelab Analisi conversazionale in BigQuery.

Poiché l'agente è definito come unità controllata, utilizza la stessa logica, lo stesso contesto e le stesse misure di protezione attendibili, indipendentemente dall'applicazione o dal sub-agente che lo chiama.

Integrazione avanzata dell'esperienza utente con subagenti personalizzati

I set di strumenti BigQueryToolset e DataAgentToolset non restituiscono risultati all'utente finché la richiesta API non viene elaborata. Poiché il framework ADK considera l'API come uno strumento che blocca le risposte fino al completamento, le query di lunga durata potrebbero lasciare gli utenti senza feedback.

In alternativa, per le applicazioni in cui la bassa latenza di risposta è una priorità o in cui il recupero dei dati alimenta gli agenti downstream, puoi creare una classe di agenti ADK personalizzata che si connette direttamente all'API Analisi conversazionale e trasmette i dati in blocchi all'utente in modo asincrono. Questo pattern supporta i seguenti tipi di risposta man mano che vengono prodotti:

  • Messaggi di pensiero: il processo di ragionamento del data agent mentre interpreta la domanda.
  • Messaggi di avanzamento: aggiornamenti di stato durante il recupero dei dati per le origini dati.
  • Generazione di query: la query SQL o Looker generata, che viene trasmessa in streaming man mano che viene prodotta.
  • Dati: i risultati dei dati in formato JSON.
  • Visualizzazione: specifiche del grafico Vega-Lite.
  • Riepilogo: la risposta finale basata sul testo.

Per un elenco completo dei tipi di dati restituiti, consulta il tipo SystemMessage nella documentazione di riferimento dell'API.

Questo approccio asincrono garantisce che gli utenti non debbano attendere il completamento di una complessa procedura di recupero dei dati. Man mano che l'agente dei dati scorre il processo di query, condivide continuamente aggiornamenti incrementali, come riepiloghi di testo, dati non elaborati o configurazioni di grafici, in uno spazio di lavoro temporaneo condiviso. Questi dati possono quindi essere visualizzati per l'utente in tempo reale e condivisi con subagenti specializzati per eseguire attività aggiuntive.

Per un'implementazione di riferimento che include un agente principale, un sub-agente di dati e un agente di visualizzazione, consulta la demo di streaming ADK su GitHub.

Integrazione verticale (MCP)

Il Model Context Protocol (MCP) è uno standard aperto che fornisce un modo uniforme per le applicazioni AI di connettersi a strumenti esterni e origini dati. MCP standardizza l'interfaccia tra i modelli di AI e gli strumenti che utilizzano.

Questa sezione tratta i seguenti argomenti:

MCP Toolbox per database

Sebbene non esista un server MCP API Analisi conversazionale dedicato, puoi accedere all'API tramite il server MCP Toolbox for Databases. Questo server open source fornisce strumenti predefiniti compatibili con MCP che espongono il metodo chat nell'API Analisi conversazionale:

MCP è un livello di interoperabilità che espone le funzionalità di analisi come strumenti per i client compatibili con MCP anziché un modello di esecuzione separato dell'API Analisi conversazionale.

Pattern di implementazione MCP per architetture autonome e ADK

Puoi implementare MCP tramite i seguenti pattern:

Pattern Dettagli
MCP autonomo (senza ADK)

Utilizza il server MCP Toolbox per database come server autonomo per connetterti a qualsiasi client conforme a MCP. Questo pattern è di uso comune per le seguenti attività:

  • Integrazione IDE: collega un IDE, ad esempio Antigravity, Cursor o VS Code, al server per eseguire query sui dati in modo conversazionale da un editor.
  • Client MCP personalizzato: crea un'applicazione che utilizza il server per fornire un'interfaccia di strumenti uniforme per più provider di AI.
  • Gemini CLI: utilizza la CLI come client MCP per conversazioni basate sui dati nel terminale.
MCP in ADK

Il framework ADK fornisce i seguenti meccanismi per l'integrazione dei server MCP nei flussi di lavoro degli agenti:

  • ToolboxToolset: una variante specializzata per il server MCP Toolbox for Databases che supporta più metodi di autenticazione.
  • McpToolset: connette un agente ADK a qualsiasi server MCP utilizzando connessioni al server MCP locali o remote. Rileva automaticamente gli strumenti del server e li espone all'agente.

Puoi anche creare server MCP utilizzando il framework FastMCP per esporre gli strumenti creati con il framework ADK a qualsiasi client conforme a MCP. Questo approccio rende gli agenti ADK disponibili come strumenti in altri ecosistemi.

Scegli un pattern di integrazione in base ai requisiti architetturali specifici della tua applicazione:

  • L'utilizzo di set di strumenti integrati di Agent Development Kit (ADK), come BigQueryToolset o DataAgentToolset, offre un'integrazione più stretta senza dipendenze da server esterni. Questo approccio è ideale per i sistemi che esistono interamente all'interno del framework ADK.
  • L'utilizzo degli strumenti in MCP Toolbox garantisce l'interoperabilità tra i client conformi a MCP. Questo approccio è ideale per gli strumenti di dati che devono servire più applicazioni consumer o IDE di terze parti.

Orchestrazione orizzontale (A2A)

Il protocollo Agent-to-Agent (A2A) è uno standard aperto che consente ad agenti specializzati su sistemi diversi di comunicare e collaborare in modo sicuro senza richiedere codice di integrazione personalizzato.

Man mano che i sistemi vengono scalati, le organizzazioni spesso eseguono il deployment di più agenti specializzati basati su framework o infrastrutture cloud diversi. A2A stabilisce un livello di messaggistica universale per questi agenti autonomi. Anziché utilizzare API personalizzate, ogni agente pubblica una scheda dell'agente, ovvero un profilo rilevabile che descrive in dettaglio le funzionalità dell'agente, i formati di dati supportati e i requisiti di sicurezza.

Quando un orchestratore centrale o un agente peer richiede dati analitici, delega in modo sicuro l'attività a un agente di dati tramite messaggistica A2A strutturata. L'agente dati elabora la richiesta in modo autonomo e restituisce i risultati, separando la logica di esecuzione dal richiedente.

Scegliere un pattern di integrazione

Utilizza la seguente tabella per confrontare la complessità, la governance e le funzionalità di ciascun pattern di integrazione.

I livelli di complessità sono definiti come segue:

  • Basso: pattern che richiedono un codice personalizzato minimo e si basano su interfacce utente o strumenti predefiniti.
  • Medio: pattern che richiedono lo sviluppo personalizzato del frontend e l'integrazione di API o SDK, ma evitano un'infrastruttura di orchestrazione del backend complessa.
  • Alto: pattern che richiedono lo sviluppo di applicazioni full-stack, la gestione dello stato della conversazione, più livelli di autenticazione o un'infrastruttura di orchestratore intermedia.
  • Varia: pattern in cui la complessità dipende dal metodo di integrazione sottostante scelto.
Pattern di integrazione complessità Personalizzazione Governance degli agenti Controllo degli accessi Multi-agente Streaming Portabilità
Incorporamento di iframe di Looker Bassa Bassa Gestito tramite Looker Looker No Integrato Solo Looker
API Looker e SDK Media Alta Gestito tramite Looker Looker No Integrato Solo Looker
API Analisi conversazionale con origine Looker Variabile Alta Gestito tramite l'API Looker e IAM Sì Sì Qualsiasi Google Cloud piattaforma
Singolo agente (API diretta) Media Alta Gestito tramite l'API IAM No Sì (supportato) Qualsiasi Google Cloud piattaforma
Orchestratore personalizzato Alta Molto alta Gestito tramite l'API IAM Manuale Manuale Qualsiasi Google Cloud piattaforma
Basato su schema con BigQueryToolset (ADK) Bassa Media Nessuno (inferenza dello schema) IAM Sì (ADK) No (blocco) Ecosistema ADK
Governato con DataAgentToolset (ADK) Bassa Media Gestito tramite l'API IAM Sì (ADK) No (blocco) Ecosistema ADK
Subagente di streaming personalizzato (ADK) Alta Molto alta Gestito tramite l'API IAM Sì (ADK) Sì (personalizzato) Ecosistema ADK
MCP autonomo Media Media Nessuno (inferenza dello schema) IAM No No Qualsiasi client MCP
MCP in ADK Media Alta Nessuno (inferenza dello schema) IAM Sì (ADK) No Client ADK e MCP
Protocollo A2A Alta Alta Dipendente dal framework IAM Sì Sì Multipiattaforma

Passaggi successivi