Schémas d'intégration pour les agents de données

Cette page décrit les schémas d'intégration permettant d'intégrer des expériences d'agent de données dans vos applications. Ces modèles varient en complexité, d'un composant de chat intégré à un système multi-agents orchestré.

Ce guide s'adresse aux architectes cloud et aux ingénieurs de données qui conçoivent des applications d'IA générative. Vous devez avoir des connaissances de base sur les concepts Google Cloud , Identity and Access Management et les API REST. Vous devez également connaître l'architecture de la source de données utilisée par votre application.

Présentation des modèles d'intégration

Ce guide est organisé en fonction de votre point de départ :

  • Parcours Looker : sélectionnez ce parcours si vous souhaitez fournir une fonctionnalité de chat via l'intégration Looker, l'API Looker ou l'API Conversational Analytics.
  • Parcours BigQuery et base de données : sélectionnez ce parcours si vous créez une application personnalisée qui utilise BigQuery, Data Studio ou une base de données opérationnelle compatible.

Le tableau suivant récapitule les modèles d'intégration disponibles :

Modèle d'intégration Description Source de données
Intégration d'iFrame Looker Ajoute l'interface de chat standard à une application qui nécessite un minimum de code. Looker
API et SDK Looker Crée une interface de chat personnalisée qui utilise l'API Looker pour l'authentification. Looker
API Conversational Analytics (source Looker) Gère les agents de données Looker en tant que ressources Google Cloud qui fonctionnent sur plusieurs surfaces et systèmes multi-agents. Looker
API directe (agent unique) Utilise une intégration directe de l'API pour les flux de questions/réponses. BigQuery, bases de données, Looker
API directe (orchestrateur) Route les requêtes entre l'API et d'autres outils à l'aide de l'appel de fonction. BigQuery, bases de données, Looker
ADK (piloté par un schéma) avec BigQueryToolset Générez rapidement des insights à partir de références de tableaux à l'aide de l'outil ask_data_insights. BigQuery
ADK (réglementé) avec DataAgentToolset Interroge les agents de données préconfigurés qui utilisent l'outil ask_data_agent pour garantir un comportement cohérent. BigQuery, bases de données, Looker
ADK (streaming personnalisé) Permet le streaming en temps réel des graphiques et du code SQL à l'aide d'une classe d'agent personnalisée. BigQuery, bases de données, Looker
MCP avec McpToolset ou ToolboxToolset Connecte les applications aux outils de données qui utilisent le protocole MCP (Model Context Protocol). BigQuery Looker
Protocole A2A Permet une collaboration sécurisée entre des agents spécialisés fonctionnant sur différents systèmes. Dépend du framework

Options d'intégration pour Looker

Si vous utilisez Looker, vous pouvez fournir Looker Conversational Analytics à vos utilisateurs en suivant les modèles suivants :

Récapitulatif des modèles d'intégration Looker

Le tableau suivant récapitule les principaux modèles d'intégration pour Looker :

Modèle Application idéale Avantages Remarques
Intégrer avec des iFrames : méthode low-code permettant d'ajouter rapidement l'expérience de chat Looker standard à une application. Équipes qui ont besoin d'une expérience d'analyse conversationnelle prête pour la production avec un développement personnalisé minimal.
  • L'implémentation nécessite un minimum de code.
  • Applique automatiquement le modèle de sécurité Looker existant.
  • Ne nécessite pas d'authentification Google Cloud distincte.
  • Compatible avec le SDK d'intégration Looker, qui accélère le développement en gérant les cycles de vie des iFrames et la transmission des événements.
  • Offre une personnalisation limitée de l'UI et dépend de l'interface utilisateur standard de chat Looker.
  • Votre instance Looker doit être hébergée par Looker.
Développer avec l'API et les SDK Looker : une approche flexible pour créer une interface de chat personnalisée tout en conservant l'authentification et la gestion des agents dans Looker. Les équipes qui ont besoin d'une expérience utilisateur de chat personnalisée, mais qui souhaitent conserver l'authentification des utilisateurs et la gestion des agents dans l'écosystème Looker. Ce modèle est idéal pour les applications qui utilisent déjà l'intégration Looker ou l'API.
  • Fournit une couche d'authentification unique et un contrôle total sur l'interface utilisateur.
  • Simplifie l'architecture pour les clients Looker existants.
  • Utilise la couche sémantique Looker pour améliorer la précision des requêtes.
  • Ne nécessite pas d'authentification Google Cloud distincte.
  • Nécessite une expertise en développement d'API Looker.
  • Limité aux sources de données Looker.
  • Les agents sont gérés dans Looker et ne peuvent pas être transférés vers d'autres services Google Cloud .
Utiliser l'API Conversational Analytics : intégration directe à l'API pour gérer les agents en tant que ressources au niveau du cloud. Clients Looker qui ont besoin d'une portabilité multiplate-forme pour leurs agents de données.
  • Garantit que l'agent de données est portable sur toutes les surfaces Google Cloud .
  • Gouverné de manière centralisée par Identity and Access Management.
  • Vous permet d'intégrer des agents de données dans les workflows ADK ou MCP.
  • Vous devez gérer l'intégralité de la pile d'intégration, y compris l'authentification Google Cloud et Looker.
  • Les agents de données sont gérés indépendamment de l'interface utilisateur Looker.

Intégrer des rapports avec des iFrames

Vous pouvez intégrer Conversational Analytics en tant qu'iframe pour proposer l'expérience de chat en dehors de l'UI Looker. Ce modèle est un moyen direct de fournir des données Conversational Analytics qui ne nécessitent aucun développement d'UI personnalisée, ni orchestration de backend, ni gestion de l'état de l'API. Pour utiliser ce modèle, vous devez ajouter une URL préformatée à votre application.

Le SDK d'intégration Looker fournit des outils qui gèrent des tâches telles que la génération d'URL sécurisées, la gestion du cycle de vie des iFrames et la transmission d'événements JavaScript entre l'application hôte et l'iFrame. Vous pouvez intégrer la page Agents, la page Conversations ou une conversation spécifique en ajoutant une URL préformatée dans votre application.

Vous pouvez utiliser les méthodes d'authentification suivantes pour le contenu intégré :

  • Intégration privée : authentifie les utilisateurs avec leurs identifiants Looker existants. Lorsque vous définissez l'URL d'intégration comme source de l'iFrame, les utilisateurs se connectent avec leur compte Looker. Cette méthode applique automatiquement les rôles, l'accès au contenu et les autorisations au niveau des données existants, tels que les filtres d'accès ou les autorisations d'accès, sans nécessiter de configuration Identity and Access Management ni de mappage de jetons supplémentaires.
  • Intégration signée : authentifie les utilisateurs via votre application à l'aide de l'authentification unique (SSO). Vous créez une URL signée qui inclut le chemin d'accès au contenu Conversational Analytics, ce qui vous permet de spécifier de manière dynamique les autorisations à accorder.

Créer avec l'API et les SDK Looker

Pour une expérience de chat plus flexible, vous pouvez utiliser les méthodes ConversationalAnalytics dans l'API Looker ou un SDK Looker pour créer une application personnalisée. Cette approche vous permet de créer une interface utilisateur personnalisée qui communique directement avec les points de terminaison Looker.

L'intégration à l'API Looker offre les avantages suivants :

  • Vous ne gérez l'authentification qu'avec Looker. Il n'est pas nécessaire de s'authentifier séparément auprès de l'API Conversational Analytics.
  • Pour les applications qui utilisent déjà l'intégration Looker ou l'API, ce modèle simplifie l'architecture du projet en évitant les mécanismes d'authentification secondaires et en éliminant la nécessité de gérer des agents de données externes.
  • Vous contrôlez entièrement l'interface de chat, le flux de conversation et la façon dont l'application affiche les résultats (graphiques et tableaux, par exemple).

Pour obtenir une implémentation de référence, consultez le guide de l'API Looker Conversational Analytics sur GitHub.

Utiliser l'API Conversational Analytics avec les données Looker

Vous pouvez effectuer une intégration directe à l'API Conversational Analytics sur geminidataanalytics.googleapis.com si vous devez effectuer l'une des tâches suivantes :

  • Partager le même agent de données sur plusieurs surfaces Google Cloud , comme les applications Web personnalisées, Google Chat et Gemini Enterprise
  • Combiner des sources de données Looker avec des sources BigQuery ou de bases de données opérationnelles dans un seul système multi-agents
  • Gérez votre agent de données en tant que ressource au niveau du cloud régie par Identity and Access Management plutôt que par le modèle d'autorisations Looker.

Pour en savoir plus sur les modèles d'architecture courants pour l'API Conversational Analytics, consultez Options d'intégration pour BigQuery et les bases de données.

Options d'intégration pour BigQuery et les bases de données

Cette section décrit les modèles architecturaux pour les applications qui utilisent BigQuery, Data Studio ou des bases de données opérationnelles Google Cloud compatibles pour créer des expériences personnalisées avec l'API Conversational Analytics.

Si vous utilisez l'API Conversational Analytics avec une source de données Looker, les modèles décrits dans cette section s'appliquent également à votre intégration.

L'API Conversational Analytics fournit les principales méthodes suivantes pour interagir avec les données :

  • Méthode chat : compatible avec BigQuery, Looker, Data Studio et les bases de données opérationnelles.
  • Méthode queryData : compatible avec les bases de données opérationnelles telles qu'AlloyDB, GoogleSQL pour Spanner, Cloud SQL pour MySQL et Cloud SQL pour PostgreSQL.

Lorsque vous créez une application personnalisée, vous pouvez utiliser un ou plusieurs des modèles d'intégration suivants :

  • Intégration directe de l'API : approche personnalisée qui offre le plus de flexibilité, mais qui vous oblige à créer l'infrastructure pour l'authentification, la gestion des conversations et l'analyse des réponses.
  • Orchestration basée sur un framework (ADK) : approche qui utilise l'Agent Development Kit (ADK) pour le routage multi-agents, l'exécution d'outils et la gestion de l'état.
  • Intégration verticale (MCP) : approche qui utilise le protocole MCP (Model Context Protocol) pour fournir un moyen uniforme de connecter les applications d'IA à des outils et des sources de données dans différents environnements.
  • Orchestration horizontale (A2A) : approche qui utilise le protocole Agent-to-Agent (A2A) pour permettre à des agents spécialisés sur différents systèmes de collaborer de manière sécurisée sans nécessiter de code d'intégration personnalisé.

Récapitulatif des schémas d'intégration de BigQuery et des bases de données

Le tableau suivant récapitule les modèles d'implémentation spécifiques à BigQuery et aux bases de données opérationnelles :

Modèle Application idéale Avantages Remarques
Intégration à agent unique (API directe) : modèle dans lequel votre application appelle directement l'API pour renvoyer des insights à partir de vos sources de données. Applications, prototypes ou microservices mono-agent nécessitant un contrôle direct sur chaque appel d'API.
  • Fournit un contrôle précis sans dépendances de framework.
  • Fournit l'architecture la plus simple pour les cas d'utilisation à agent unique.
  • Compatible avec les modes avec état et sans état.
  • Vous devez créer toute l'infrastructure pour l'authentification, la gestion de l'état, l'analyse des réponses, la gestion des exceptions, le streaming et le déploiement.
  • Ne s'adapte pas bien aux scénarios multi-agents.
Orchestrateur personnalisé (API directe) : modèle qui utilise un agent racine et l'appel de fonction pour acheminer les requêtes entre l'API Conversational Analytics et d'autres outils ou services. Applications qui combinent des requêtes de données avec d'autres tâches, comme l'envoi d'e-mails ou la création de documents, dans un seul flux conversationnel.
  • Offre un contrôle maximal de l'orchestration sans dépendance de framework.
  • Vous permet de définir précisément comment le modèle effectue le routage entre les outils.
  • Fonctionne avec n'importe quel modèle Gemini.
  • Vous devez gérer manuellement les définitions d'outils, les boucles de conversation, l'état multitours, la gestion des exceptions et le déploiement.
  • Les frais généraux de développement peuvent devenir lourds par rapport à l'utilisation d'un framework tel que l'ADK.
Intégration basée sur le schéma avec BigQueryToolset (ADK) : modèle qui utilise des références de tables pour renvoyer rapidement des insights sur les données. Prototypage rapide, outils internes où la gouvernance des données est moins critique ou scénarios où les insights sur les données ne sont qu'une des nombreuses fonctionnalités d'un agent ADK.
  • Fournit le chemin d'intégration le plus rapide dans le framework ADK.
  • Aucune préconfiguration de l'agent de données n'est requise.
  • Fonctionne directement avec les noms de tables de base de données.
  • Ne dispose pas de gouvernance sémantique et génère du code SQL à partir de l'inférence de schéma uniquement.
  • Fonctionne en mode sans état au niveau de l'API.
  • Fournit des réponses textuelles uniquement et n'accepte pas les graphiques.
Intégration régie avec DataAgentToolset (ADK) : modèle qui interroge un agent de données préconfiguré en référençant l'ID de l'agent. Applications de production nécessitant un accès cohérent aux données ou systèmes multi-agents où l'agent de données est un composant réutilisable et fiable.
  • Fournit une gouvernance sémantique et un comportement cohérent pour tous les consommateurs.
  • Améliore la précision en utilisant des requêtes validées et un glossaire d'entreprise.
  • Garantit que les agents de données sont réutilisables dans les intégrations ADK, MCP et API directes.
  • Vous devez préconfigurer les ressources de l'agent de données.
  • Fonctionne en mode sans état au niveau de l'API.
  • Renvoie des réponses textuelles uniquement et n'accepte pas les graphiques.
Sous-agents personnalisés (ADK) : modèle qui utilise une classe d'agent personnalisée pour se connecter directement à l'API et renvoyer des blocs de données à l'utilisateur. Applications destinées aux utilisateurs pour lesquelles une faible latence de réponse est une priorité ou pipelines multi-agents dans lesquels la récupération de données alimente les agents en aval.
  • Elle fournit des commentaires en temps réel sur le streaming.
  • Accès à tous les types de réponses, tels que les graphiques, les tableaux et le code SQL.
  • Composable avec d'autres agents ADK via l'état de la session.
  • Nécessite plus d'efforts de développement pour créer une classe d'agent ADK personnalisée.
  • Vous devez gérer directement la connexion de flux et l'analyse de la réponse.
Model Context Protocol (MCP) : modèle qui utilise une norme ouverte pour connecter des applications d'IA à des sources de données et à des outils dans différents environnements. Les organisations qui ont besoin d'une interopérabilité des outils sur plusieurs clients d'IA et IDE, ou les équipes qui ont besoin que les mêmes outils de données soient accessibles à partir du framework ADK, des IDE et des applications personnalisées.
  • Utilise une norme d'outil universelle qui fonctionne avec n'importe quel client conforme à MCP.
  • Dissocie l'implémentation de l'outil des applications consommateur.
  • Propose des options de serveur géré, comme le serveur Google Cloud MCP.
  • Nécessite une couche d'infrastructure supplémentaire pour le serveur de la boîte à outils.
  • L'intégration est moins étroite qu'avec les ensembles d'outils Agent Development Kit (ADK).
  • Dépend de l'évolution de l'écosystème de la boîte à outils MCP.
  • Fonctionne en mode sans état, ce qui vous oblige à gérer l'état multitour en externe.
Agent2Agent (A2A) : modèle qui utilise le protocole A2A, une norme ouverte qui permet aux agents spécialisés de différents systèmes de collaborer de manière sécurisée sans nécessiter de code d'intégration personnalisé. Environnements d'entreprise hautement distribués dans lesquels un agent de routage central doit déléguer des tâches à des agents de données fonctionnant sur différents systèmes ou réseaux.
  • Réduit le besoin de code d'intégration personnalisé entre différents frameworks.
  • Assure une interopérabilité multiplate-forme fluide.
  • Permet de découvrir les fonctionnalités de manière sécurisée et standardisée.
  • Entraîne une latence réseau mineure par rapport aux sous-agents internes.
  • Vous devez configurer les paramètres du serveur A2A.

Intégration directe à l'aide de l'API

L'intégration directe de l'API offre un contrôle précis sur la logique et l'architecture de votre application, mais vous oblige à créer l'infrastructure sous-jacente. Avec cette approche, vous êtes responsable de tâches telles que l'authentification, la gestion des conversations, l'analyse des réponses et le déploiement.

Cette section aborde les points suivants :

  • Intégration à un seul agent : modèle dans lequel votre application appelle directement l'API Conversational Analytics pour renvoyer des insights à partir de vos sources de données.
  • Intégration d'un orchestrateur personnalisé : modèle avancé qui utilise un agent racine et l'appel de fonction pour acheminer les requêtes entre l'API Conversational Analytics.

Intégration d'un seul agent

Avec une intégration mono-agent, votre backend appelle directement l'API Conversational Analytics à l'aide de REST ou d'une bibliothèque cliente, et transmet la requête et le contexte de l'utilisateur. Ce modèle convient aux applications peu complexes, telles que les applications Web, les outils de chat internes ou les microservices, qui utilisent un flux de conversion de texte en réponse simple. Vous pouvez également utiliser cette approche pour le prototypage et les démonstrations de faisabilité.

Ce modèle est compatible avec le chat avec état, où Google gère l'historique des conversations, et le chat sans état, où votre application gère l'historique.

Pour obtenir des exemples d'implémentation, consultez le guide de démarrage rapide de l'API Conversational Analytics ou la démo Golden de l'API Conversational Analytics sur GitHub.

Intégration d'un orchestrateur personnalisé

Avec cette approche, vous créez un agent racine qui sert de point d'entrée et de coordinateur principal pour votre application. L'agent racine utilise un modèle Gemini standard équipé d'outils via l'appel de fonction. Lorsqu'un utilisateur pose une question liée aux données, l'agent racine émet un appel d'outil à l'API Conversational Analytics, reçoit le résultat, puis peut continuer à raisonner ou appeler d'autres outils en aval.

L'appel de fonction comporte les étapes suivantes :

  1. Déclarer : définissez les schémas d'outils en tant qu'objets FunctionDeclaration incluant des définitions de paramètres.
  2. Appeler : le modèle renvoie un message functionCall structuré contenant le nom et les arguments de la fonction.
  3. Exécuter : votre application effectue l'appel d'API et renvoie le résultat dans un message FunctionResponse.
  4. Synthétiser : le modèle Gemini utilise le résultat pour générer une réponse finale ou déterminer la prochaine action.

Cette approche convient aux applications dans lesquelles les utilisateurs peuvent demander des insights sur les données en plus d'autres tâches. Par exemple, un utilisateur peut demander à l'agent de "m'afficher les ventes, puis de rédiger un e-mail à l'équipe commerciale". L'agent racine peut acheminer la question sur les données vers l'API Conversational Analytics et utiliser d'autres outils pour les tâches non liées aux données.

Pour obtenir une implémentation de référence, consultez les pages orchestrate ou multimodal dans la démo Golden de l'API Conversational Analytics sur GitHub.

Orchestration basée sur un framework (ADK)

L'Agent Development Kit (ADK) est un framework axé sur le code permettant de créer des agents d'IA qui gèrent la complexité du routage multi-agents, de l'exécution des outils et de la gestion de l'état. Le framework ADK est le même que celui qui alimente Gemini Enterprise.

En utilisant l'ADK, vous pouvez enchaîner l'API Conversational Analytics avec d'autres outils et agents pour effectuer des actions complexes.

Cette section aborde les points suivants :

Intégration basée sur le schéma avec BigQueryToolset

L'ensemble d'outils BigQueryToolset du framework ADK inclut un outil ask_data_insights prédéfini. Pour utiliser cet outil, vous transmettez les noms de tables et la question de l'utilisateur à l'outil, qui appelle ensuite l'API Conversational Analytics en utilisant le contexte intégré.

Lorsque vous appelez l'outil, il envoie une requête sans état qui inclut les références de table BigQuery spécifiées à l'API Conversational Analytics. L'API déduit le schéma de la base de données, génère et exécute la requête SQL, puis renvoie une réponse textuelle. Le résultat est ensuite renvoyé à l'agent ADK en tant que réponse de l'outil.

Ce modèle est un moyen efficace d'ajouter rapidement des analyses conversationnelles à un agent. Toutefois, comme l'appel à l'API est sans état et sans gouvernance, l'API génère du code SQL basé entièrement sur le schéma de table, sans garde-fous sémantiques. Ce modèle permet un déploiement plus rapide, mais il est plus risqué pour la logique métier de production où des conventions de dénomination, une logique métier ou des contrôles d'accès s'appliquent.

Intégration régie avec DataAgentToolset

L'ensemble d'outils DataAgentToolset du framework ADK fournit une intégration prédéfinie qui fait référence à un agent de données préconfiguré par son ID. L'agent ADK transmet la question de l'utilisateur à l'outil ask_data_agent, qui appelle l'API Conversational Analytics avec le contexte de l'agent de données spécifié.

Vous pouvez créer un agent de données de manière programmatique à l'aide de l'API Conversational Analytics ou du catalogue d'agents dans la console Google Cloud . Un agent de données est équipé des composants suivants :

  • Sources de connaissances : tables, vues ou fonctions définies par l'utilisateur (UDF) que l'agent peut interroger
  • Contexte structuré : descriptions des tableaux et des colonnes qui aident l'agent à comprendre les données sous-jacentes
  • Instructions : conseils supplémentaires pour l'agent afin d'interpréter les sources de données et d'y effectuer des requêtes
  • Requêtes validées : requêtes SQL prévalidées qui servent d'exemples pour les questions courantes
  • Glossaire : définitions de termes commerciaux qui aident l'agent à comprendre le langage spécifique à un domaine

Pour obtenir un guide détaillé sur la création d'agents à l'aide du catalogue d'agents, consultez l'atelier de programmation Analyse conversationnelle dans BigQuery.

Étant donné que l'agent est défini comme une unité régie, il utilise la même logique, le même contexte et les mêmes garde-fous de confiance, quelle que soit l'application ou le sous-agent qui l'appelle.

Intégration UX avancée avec des sous-agents personnalisés

Les ensembles d'outils BigQueryToolset et DataAgentToolset ne renvoient pas de résultats à l'utilisateur tant que la requête API n'a pas été traitée. Étant donné que le framework ADK traite l'API comme un outil qui bloque les réponses jusqu'à ce qu'elles soient terminées, les requêtes de longue durée peuvent laisser les utilisateurs sans réponse.

Pour les applications où une faible latence de réponse est une priorité ou où la récupération de données alimente les agents en aval, vous pouvez créer une classe d'agent ADK personnalisée qui se connecte directement à l'API Conversational Analytics et transmet les données par blocs à l'utilisateur de manière asynchrone. Ce modèle est compatible avec les types de réponses suivants :

  • Messages de réflexion : processus de raisonnement de l'agent de données lorsqu'il interprète la question.
  • Messages de progression : mises à jour de l'état lors de la récupération des données pour les sources de données.
  • Génération de requêtes : la requête SQL ou Looker générée, qui est diffusée en streaming au fur et à mesure de sa production.
  • Data : résultats des données au format JSON.
  • Visualisation : spécifications du graphique Vega-Lite.
  • Récapitulatif : réponse finale au format texte.

Pour obtenir la liste complète des types de données renvoyés, consultez le type SystemMessage dans la documentation de référence de l'API.

Cette approche asynchrone permet aux utilisateurs de ne pas avoir à attendre la fin d'un processus complexe de récupération de données. Au fur et à mesure que l'agent de données parcourt le processus de requête, il partage en continu des mises à jour incrémentielles (telles que des résumés de texte, des données brutes ou des configurations de graphiques) dans un espace de travail temporaire et partagé. Ces données peuvent ensuite être affichées à l'utilisateur en temps réel et partagées avec des sous-agents spécialisés pour effectuer des tâches supplémentaires.

Pour obtenir une implémentation de référence incluant un agent racine, un sous-agent de données et un agent de visualisation, consultez la démonstration de streaming ADK sur GitHub.

Intégration verticale (MCP)

Le Model Context Protocol (MCP) est une norme ouverte qui permet aux applications d'IA de se connecter de manière uniforme à des outils et des sources de données externes. MCP standardise l'interface entre les modèles d'IA et les outils qu'ils utilisent.

Cette section aborde les points suivants :

MCP Toolbox for Databases

Bien qu'il n'existe pas de serveur MCP dédié à l'API Conversational Analytics, vous pouvez accéder à l'API via le serveur MCP Toolbox for Databases. Ce serveur Open Source fournit des outils prédéfinis et compatibles avec MCP qui exposent la méthode chat dans l'API Conversational Analytics :

MCP est une couche d'interopérabilité qui expose les capacités d'analyse en tant qu'outils aux clients compatibles avec MCP, plutôt qu'un modèle d'exécution distinct de l'API Conversational Analytics.

Modèles d'implémentation MCP pour les architectures autonomes et ADK

Vous pouvez implémenter MCP à l'aide des modèles suivants :

Modèle Détails
MCP autonome (sans ADK)

Utilisez le serveur MCP Toolbox for Databases comme serveur autonome pour vous connecter à n'importe quel client compatible avec MCP. Ce modèle est couramment utilisé pour les tâches suivantes :

  • Intégration de l'IDE : connectez un IDE (Antigravity, Cursor ou VS Code, par exemple) au serveur pour interroger les données de manière conversationnelle depuis un éditeur.
  • Client MCP personnalisé : créez une application qui utilise le serveur pour fournir une interface d'outil uniforme à plusieurs fournisseurs d'IA.
  • Gemini CLI : utilisez la CLI comme client MCP pour les conversations de données basées sur le terminal.
MCP dans ADK

Le framework ADK fournit les mécanismes suivants pour intégrer les serveurs MCP dans les workflows d'agent :

  • ToolboxToolset : variante spécialisée du serveur MCP Toolbox for Databases qui accepte plusieurs méthodes d'authentification.
  • McpToolset : connecte un agent ADK à n'importe quel serveur MCP à l'aide de connexions au serveur MCP local ou distant. Détecte automatiquement les outils du serveur et les expose à l'agent.

Vous pouvez également créer des serveurs MCP à l'aide du framework FastMCP pour exposer les outils créés avec le framework ADK à n'importe quel client conforme à MCP. Cette approche permet de rendre vos agents ADK disponibles en tant qu'outils dans d'autres écosystèmes.

Choisissez un modèle d'intégration en fonction des exigences architecturales spécifiques de votre application :

  • L'utilisation d'ensembles d'outils Agent Development Kit (ADK) intégrés, tels que BigQueryToolset ou DataAgentToolset, permet une intégration plus étroite sans dépendance à un serveur externe. Cette approche est idéale pour les systèmes qui existent entièrement dans le framework ADK.
  • L'utilisation des outils de la boîte à outils MCP permet l'interopérabilité entre les clients conformes à MCP. Cette approche est idéale pour les outils de données qui doivent desservir plusieurs applications grand public ou IDE tiers.

Orchestration horizontale (A2A)

Le protocole Agent2Agent (A2A) est une norme ouverte qui permet aux agents spécialisés de différents systèmes de communiquer et de collaborer de manière sécurisée sans nécessiter de code d'intégration personnalisé.

À mesure que les systèmes évoluent, les entreprises déploient souvent plusieurs agents spécialisés conçus sur différents frameworks ou infrastructures cloud. A2A établit un niveau de messagerie universel pour ces agents autonomes. Au lieu d'utiliser des API personnalisées, chaque agent publie une fiche d'agent, qui est un profil détectable détaillant les capacités de l'agent, les formats de données compatibles et les exigences de sécurité.

Lorsqu'un orchestrateur central ou un agent pair a besoin de données analytiques, il délègue la tâche de manière sécurisée à un agent de données via une messagerie A2A structurée. L'agent de données traite la requête de manière autonome et renvoie les résultats, ce qui découple la logique d'exécution du demandeur.

Choisir un modèle d'intégration

Utilisez le tableau suivant pour comparer la complexité, la gouvernance et les capacités de chaque modèle d'intégration.

Les niveaux de complexité sont définis comme suit :

  • Faible : modèles qui nécessitent un minimum de code personnalisé et qui s'appuient sur des outils ou des interfaces utilisateur prédéfinis.
  • Moyen : modèles qui nécessitent un développement frontend personnalisé et une intégration d'API ou de SDK, mais qui évitent une infrastructure d'orchestration backend complexe.
  • Élevé : modèles nécessitant le développement d'applications full stack, la gestion de l'état de la conversation, plusieurs couches d'authentification ou une infrastructure d'orchestrateur intermédiaire.
  • Variable : modèles dont la complexité dépend de la méthode d'intégration sous-jacente que vous choisissez.
Modèle d'intégration Complexité Personnalisation Gouvernance des agents Contrôle des accès Multi-agent Streaming Portabilité
Intégration d'iFrame Looker Faible Faible Géré avec Looker Looker Non Intégré Looker uniquement
API et SDK Looker Moyenne Élevée Géré avec Looker Looker Non Intégré Looker uniquement
API Conversational Analytics avec source Looker Variable Élevée Géré via l'API Looker et IAM Oui Oui N'importe quelle surface Google Cloud
Agent unique (API directe) Moyenne Élevée Géré via l'API IAM Non Oui (compatible) Toute surface Google Cloud
Orchestrateur personnalisé Élevée Très élevée Géré via l'API IAM Manuel Manuel N'importe quelle surface Google Cloud
Piloté par un schéma avec BigQueryToolset (ADK) Faible Moyenne Aucune (inférence de schéma) IAM Oui (ADK) Non (bloquant) Écosystème ADK
Régie par DataAgentToolset (ADK) Faible Moyenne Géré via l'API IAM Oui (ADK) Non (bloquant) Écosystème ADK
Sous-agent de streaming personnalisé (ADK) Élevée Très élevée Géré via l'API IAM Oui (ADK) Oui (personnalisé) Écosystème ADK
MCP autonome Moyenne Moyenne Aucune (inférence de schéma) IAM Non Non Tout client MCP
MCP dans ADK Moyenne Élevée Aucune (inférence de schéma) IAM Oui (ADK) Non Clients ADK et MCP
Protocole A2A Élevée Élevée Dépend du framework IAM Oui Oui Multiplate-forme

Étapes suivantes