Patrones de integración para agentes de datos

En esta página, se describen los patrones de integración para incorporar experiencias de agentes de datos en tus aplicaciones. Estos patrones varían en complejidad, desde un componente de chat integrado hasta un sistema multiagente organizado.

Esta guía está dirigida a arquitectos de la nube y a ingenieros de datos que diseñan aplicaciones de IA generativa. Debes tener conocimientos básicos sobre los conceptos de Google Cloud , Identity and Access Management y las APIs de REST. También debes conocer la arquitectura de la fuente de datos que usa tu aplicación.

Descripción general de los patrones de integración

Esta guía se organiza en los siguientes segmentos principales según tu punto de partida:

  • Pista de Looker: Selecciona esta pista si deseas proporcionar funcionalidad de chat a través de la incorporación de Looker, la API de Looker o la API de Conversational Analytics.
  • Pista de BigQuery y bases de datos: Selecciona esta pista si compilas una aplicación personalizada que usa BigQuery, Data Studio o una base de datos operativa compatible.

En la siguiente tabla, se resumen los patrones de integración disponibles:

Patrón de integración Descripción Fuente de datos
Incorporación de iframe de Looker Agrega la interfaz de chat estándar a una aplicación que requiere una cantidad mínima de código. Looker
API de Looker y SDKs Compila una interfaz de chat personalizada que usa la API de Looker para la autenticación. Looker
API de Conversational Analytics (fuente de Looker) Administra los agentes de datos de Looker como recursos de Google Cloud que funcionan en múltiples plataformas y sistemas multiagente. Looker
API directa (de un solo agente) Utiliza una integración directa de la API para los flujos de texto a respuesta. BigQuery, bases de datos y Looker
API directa (orquestador) Enruta las consultas entre la API y otras herramientas con la llamada a funciones. BigQuery, bases de datos y Looker
ADK (basado en el esquema) con BigQueryToolset Genera estadísticas rápidas a partir de referencias de tablas con la herramienta ask_data_insights. BigQuery
ADK (regido) con DataAgentToolset Consulta a los agentes de datos preconfigurados que usan la herramienta ask_data_agent para garantizar un comportamiento coherente. BigQuery, bases de datos y Looker
ADK (transmisión personalizada) Admite la transmisión en tiempo real de gráficos y SQL con una clase de agente personalizada. BigQuery, bases de datos y Looker
MCP con McpToolset o ToolboxToolset Conecta aplicaciones a herramientas de datos que usan el Protocolo de contexto del modelo (MCP). BigQuery Looker
Protocolo A2A Permite la colaboración segura entre agentes especializados que operan en diferentes sistemas. Dependiente del framework

Opciones de integración para Looker

Si usas Looker, puedes proporcionar Looker Conversational Analytics a tus usuarios a través de los siguientes patrones:

Resumen de los patrones de integración de Looker

En la siguiente tabla, se resumen los principales patrones de integración de Looker:

Patrón Ideal para Ventajas Consideraciones
Incorporación con elementos iframe: Es un método de poco código para agregar rápidamente la experiencia de chat estándar de Looker a una aplicación. Equipos que requieren una experiencia de análisis de conversaciones lista para producción con un desarrollo personalizado mínimo.
  • Requiere una cantidad mínima de código para implementarse.
  • Aplica automáticamente el modelo de seguridad existente de Looker.
  • No requiere Google Cloud autenticación independiente.
  • Es compatible con el SDK de Embed de Looker, que acelera el desarrollo administrando los ciclos de vida de los iframe y el paso de eventos.
  • Ofrece una personalización limitada de la IU y depende de la interfaz de usuario estándar del chat de Looker.
  • Tu instancia de Looker debe estar alojada en Looker.
Compila con la API y los SDKs de Looker: Un enfoque flexible para compilar una interfaz de chat personalizada y mantener la autenticación y la administración de agentes dentro de Looker. Equipos que requieren una experiencia de usuario de chat personalizada, pero desean mantener la autenticación de usuarios y la administración de agentes dentro del ecosistema de Looker Este patrón es ideal para las aplicaciones que ya usan la incorporación de Looker o la API.
  • Proporciona una sola capa de autenticación y control total sobre la interfaz de usuario.
  • Simplifica la arquitectura para los clientes existentes de Looker.
  • Utiliza la capa semántica de Looker para mejorar la precisión de las consultas.
  • No requiere Google Cloud autenticación independiente.
  • Requiere experiencia en el desarrollo de la API de Looker.
  • Solo se pueden usar fuentes de datos de Looker.
  • Los agentes se administran en Looker y no se pueden transferir a otros servicios de Google Cloud .
Usa la API de Conversational Analytics: Integración directa con la API para administrar agentes como recursos a nivel de la nube. Clientes de Looker que requieren portabilidad multiplataforma para sus agentes de datos
  • Garantiza que el agente de datos sea portátil en todas las Google Cloud plataformas.
  • Se administra de forma centralizada a través de Identity and Access Management.
  • Te permite integrar agentes de datos en flujos de trabajo de ADK o MCP.
  • Requiere que administres la pila de integración completa, incluida la autenticación de Google Cloud y Looker.
  • Los agentes de datos se administran de forma independiente de la interfaz de usuario de Looker.

Incorpora contenido con iframes

Puedes incorporar Conversational Analytics como un iframe para ofrecer la experiencia de chat fuera de la IU de Looker. Este patrón es una forma directa de proporcionar Conversational Analytics que no requiere desarrollo de IU personalizada, orquestación de backend ni administración del estado de la API. Para usar este patrón, agrega una URL con formato previo a tu aplicación.

El SDK de Embed de Looker proporciona herramientas que administran tareas como la generación de URLs seguras, la administración del ciclo de vida de iframe y el paso de eventos de JavaScript entre la aplicación host y el iframe. Puedes incorporar la página Agentes, la página Conversaciones o una conversación específica agregando una URL con formato previo a tu aplicación.

Puedes usar los siguientes métodos de autenticación para el contenido integrado:

  • Incorporación privada: Autentica a los usuarios con sus credenciales existentes de Looker. Cuando configuras la URL de incorporación como la fuente del iframe, los usuarios acceden con sus cuentas de Looker. Este método aplica automáticamente los roles, el acceso al contenido y los permisos a nivel de los datos existentes, como los filtros de acceso o las otorgaciones de acceso, sin necesidad de configuración adicional de Identity and Access Management ni asignación de tokens.
  • Incorporación firmada: Autentica a los usuarios a través de tu aplicación con el inicio de sesión único (SSO). Construyes una URL firmada que incluye la ruta de contenido de Conversational Analytics, lo que te permite especificar de forma dinámica exactamente qué permisos otorgar.

Crea soluciones con la API y los SDKs de Looker

Para obtener más flexibilidad en la experiencia de chat, puedes usar los métodos ConversationalAnalytics en la API de Looker o un SDK de Looker para compilar una aplicación personalizada. Este enfoque te permite compilar un frontend personalizado que se comunica directamente con los extremos de Looker.

La integración con la API de Looker proporciona los siguientes beneficios:

  • Solo administras la autenticación con Looker. No es necesario autenticarse por separado con la API de Conversational Analytics.
  • En el caso de las aplicaciones que ya usan la API o la incorporación de Looker, este patrón simplifica la arquitectura del proyecto, ya que evita los mecanismos de autenticación secundarios y elimina la necesidad de administrar agentes de datos externos.
  • Tienes el control total sobre la interfaz de chat, el flujo de conversación y la forma en que la aplicación renderiza los resultados (como gráficos y tablas).

Para ver una implementación de referencia, consulta la guía de la API de Conversational Analytics de Looker en GitHub.

Usa la API de Conversational Analytics con datos de Looker

Puedes realizar la integración directamente con la API de Conversational Analytics en geminidataanalytics.googleapis.com si necesitas realizar alguna de las siguientes tareas:

  • Compartir el mismo agente de datos en varias Google Cloud plataformas, como aplicaciones web personalizadas, Google Chat y Gemini Enterprise
  • Combina fuentes de datos de Looker con fuentes de BigQuery o bases de datos operativas en un solo sistema multiagente
  • Administra tu agente de datos como un recurso a nivel de la nube que se rige por Identity and Access Management en lugar del modelo de permisos de Looker.

Para obtener más información sobre los patrones de arquitectura comunes para la API de Conversational Analytics, consulta Opciones de integración para BigQuery y bases de datos.

Opciones de integración para BigQuery y bases de datos

En esta sección, se describen los patrones de arquitectura para las aplicaciones que usan BigQuery, Data Studio o bases de datos operativas compatibles Google Cloud para crear experiencias personalizadas con la API de Conversational Analytics.

Si usas la API de Conversational Analytics con una fuente de datos de Looker, los patrones que se describen en esta sección también se aplican a tu integración.

La API de Conversational Analytics proporciona los siguientes métodos principales para interactuar con los datos:

  • Método chat: Admite BigQuery, Looker, Data Studio y bases de datos operativas.
  • Método queryData: Admite bases de datos operativas, como AlloyDB, GoogleSQL para Spanner, Cloud SQL para MySQL y Cloud SQL para PostgreSQL.

Cuando compilas una aplicación personalizada, puedes usar uno o más de los siguientes patrones de integración:

  • Integración directa de la API: Es un enfoque personalizado que proporciona la mayor flexibilidad, pero requiere que compiles la infraestructura para la autenticación, la administración de conversaciones y el análisis de respuestas.
  • Organización basada en frameworks (ADK): Es un enfoque que usa el Kit de desarrollo de agentes (ADK) para el enrutamiento de múltiples agentes, la ejecución de herramientas y la administración de estados.
  • Integración vertical (MCP): Es un enfoque que usa el Protocolo de contexto del modelo (MCP) para proporcionar una forma uniforme de conectar aplicaciones de IA a herramientas y fuentes de datos en diferentes entornos.
  • Organización horizontal (A2A): Es un enfoque que usa el protocolo Agent2Agent (A2A) para permitir que los agentes especializados en diferentes sistemas colaboren de forma segura sin necesidad de código de integración personalizado.

Resumen de los patrones de integración de bases de datos y BigQuery

En la siguiente tabla, se resumen los patrones de implementación específicos para BigQuery y las bases de datos operativas:

Patrón Ideal para Ventajas Consideraciones
Integración de un solo agente (API directa): Es un patrón en el que tu aplicación llama a la API directamente para devolver estadísticas a partir de tus fuentes de datos. Aplicaciones, prototipos o microservicios de un solo agente que requieren control directo sobre cada llamada a la API
  • Proporciona un control detallado sin dependencias de frameworks.
  • Proporciona la arquitectura más simple para los casos de uso de un solo agente.
  • Admite modos con y sin estado.
  • Requiere que compiles toda la infraestructura para la autenticación, la administración de estados, el análisis de respuestas, el manejo de errores, la transmisión y la implementación.
  • No se adapta bien a situaciones con varios agentes.
Orquestador personalizado (API directa): Es un patrón que usa un agente raíz y llamadas a funciones para enrutar consultas entre la API de Conversational Analytics y otras herramientas o servicios. Aplicaciones que combinan consultas de datos con otras tareas, como correos electrónicos o documentos, en un solo flujo de conversación.
  • Proporciona el máximo control de la organización sin dependencias del framework.
  • Te permite definir exactamente cómo el modelo realiza el enrutamiento entre las herramientas.
  • Funciona con cualquier modelo de Gemini.
  • Requiere que administres manualmente las definiciones de herramientas, los bucles de conversación, el estado de varios turnos, el manejo de errores y la implementación.
  • La sobrecarga de desarrollo podría volverse engorrosa en comparación con el uso de un framework como el ADK.
Integración basada en esquemas con BigQueryToolset (ADK): Es un patrón que usa referencias de tablas para devolver estadísticas de datos rápidamente. Prototipos rápidos, herramientas internas en las que la administración de datos es menos crítica o situaciones en las que las estadísticas de datos son una de las varias capacidades de un agente del ADK
  • Proporciona la ruta de integración más rápida dentro del framework del ADK.
  • No requiere la configuración previa de un agente de datos.
  • Funciona directamente con los nombres de las tablas de la base de datos.
  • No tiene gobernanza semántica y solo genera SQL a partir de la inferencia del esquema.
  • Funciona en modo sin estado a nivel de API.
  • Proporciona respuestas solo de texto y no admite gráficos.
Integración controlada con DataAgentToolset (ADK): Es un patrón que consulta un agente de datos preconfigurado haciendo referencia al ID del agente. Aplicaciones de producción que requieren acceso a los datos coherente o sistemas multiagente en los que el agente de datos es un componente reutilizable y confiable
  • Proporciona una administración semántica y un comportamiento coherente en todos los consumidores.
  • Mejora la precisión con consultas verificadas y un glosario empresarial.
  • Garantiza que los agentes de datos se puedan reutilizar en las integraciones directas de ADK, MCP y la API.
  • Requiere que configures previamente los recursos del agente de datos.
  • Funciona en modo sin estado a nivel de API.
  • Devuelve respuestas solo de texto y no admite gráficos.
Agentes secundarios personalizados (ADK): Es un patrón que usa una clase de agente personalizada para conectarse directamente a la API y transmitir fragmentos de datos al usuario. Aplicaciones orientadas al usuario en las que la baja latencia de respuesta es una prioridad o canalizaciones de varios agentes en las que la recuperación de datos alimenta a los agentes posteriores.
  • Proporciona comentarios de transmisión en tiempo real.
  • Accede a todos los tipos de respuestas, como gráficos, tablas y SQL.
  • Se puede componer con otros agentes del ADK a través del estado de la sesión.
  • Se requiere más esfuerzo de desarrollo para compilar una clase de agente de ADK personalizada.
  • Requiere que administres la conexión de transmisión y el análisis de respuestas directamente.
Protocolo de contexto del modelo (MCP): Es un patrón que usa un estándar abierto para conectar aplicaciones de IA a fuentes de datos y herramientas en diferentes entornos. Organizaciones que requieren interoperabilidad de herramientas en múltiples clientes de IA y IDE, o equipos que necesitan que las mismas herramientas de datos sean accesibles desde el framework del ADK, los IDE y las aplicaciones personalizadas.
  • Usa un estándar de herramientas universal que funciona con cualquier cliente compatible con MCP.
  • Desacopla la implementación de la herramienta de las aplicaciones de consumidores.
  • Ofrece opciones de servidores administrados, como el Google Cloud servidor de MCP.
  • Requiere una capa de infraestructura adicional para el servidor de la caja de herramientas.
  • Proporciona una integración menos ajustada que los conjuntos de herramientas del Kit de desarrollo de agentes (ADK).
  • Depende del ecosistema en evolución de la Caja de herramientas de MCP.
  • Opera en un modo sin estado que requiere que administres el estado de varios turnos de forma externa.
Agente a agente (A2A): Es un patrón que usa el protocolo A2A, un estándar abierto que permite que los agentes especializados en diferentes sistemas colaboren de forma segura sin necesidad de código de integración personalizado. Entornos empresariales altamente distribuidos en los que un agente de enrutamiento central debe delegar tareas en agentes de datos que operan en diferentes sistemas o redes.
  • Reduce la necesidad de código de integración personalizado entre marcos dispares.
  • Garantiza una interoperabilidad multiplataforma sin interrupciones.
  • Proporciona un descubrimiento de capacidades seguro y estandarizado.
  • Introduce una latencia de red menor en comparación con los subagentes internos.
  • Requiere que configures los parámetros del servidor de A2A.

Integración directa con la API

La integración directa de la API proporciona un control detallado sobre la lógica y la arquitectura de tu aplicación, pero requiere que compiles la infraestructura de asistencia. Con este enfoque, eres responsable de tareas como la autenticación, la administración de conversaciones, el análisis de respuestas y la implementación.

En esta sección, se abordan los siguientes temas:

  • Integración de un solo agente: Es un patrón en el que tu aplicación llama directamente a la API de Conversational Analytics para devolver estadísticas a partir de tus fuentes de datos.
  • Integración personalizada del orquestador: Es un patrón avanzado que usa un agente raíz y llamadas a funciones para enrutar consultas entre la API de Conversational Analytics.

Integración de un solo agente

Con una integración de un solo agente, tu backend llama directamente a la API de Conversational Analytics con REST o una biblioteca cliente y pasa la búsqueda y el contexto del usuario. Este patrón es adecuado para aplicaciones de baja complejidad, como apps web, herramientas de chat internas o microservicios, que usan un flujo de texto a respuesta directo. También puedes usar este enfoque para crear prototipos y pruebas de concepto.

Este patrón admite el chat con estado, en el que Google administra el historial de conversaciones, y el chat sin estado, en el que tu aplicación administra el historial.

Para ver las implementaciones de referencia, consulta el inicio rápido de la API de Conversational Analytics o la demostración de oro de la API de Conversational Analytics en GitHub.

Integración de un organizador personalizado

Con este enfoque, compilas un agente raíz que actúa como el punto de entrada y coordinador principal de tu aplicación. El agente raíz usa un modelo estándar de Gemini que está equipado con herramientas a través de la llamada a función. Cuando un usuario hace una pregunta relacionada con los datos, el agente raíz emite una llamada a la herramienta de la API de Conversational Analytics, recibe el resultado y, luego, puede seguir razonando o llamar a otras herramientas más adelante.

La llamada a función implica las siguientes etapas:

  1. Declarar: Define esquemas de herramientas como objetos FunctionDeclaration que incluyen definiciones de parámetros.
  2. Invocar: El modelo devuelve un mensaje functionCall estructurado que contiene el nombre y los argumentos de la función.
  3. Ejecutar: Tu aplicación realiza la llamada a la API y devuelve el resultado en un mensaje FunctionResponse.
  4. Sintetizar: El modelo de Gemini usa el resultado para generar una respuesta final o determinar la siguiente acción.

Este enfoque es adecuado para aplicaciones en las que los usuarios pueden solicitar estadísticas de datos junto con otras tareas. Por ejemplo, un usuario podría pedirle al agente que le muestre las ventas y, luego, redacte un correo electrónico para el equipo de ventas. El agente raíz puede enrutar la pregunta de datos a la API de Conversational Analytics y usar otras herramientas para tareas que no sean de datos.

Para ver una implementación de referencia, consulta las páginas orchestrate o multimodal en la demostración dorada de la API de Conversational Analytics en GitHub.

Organización basada en frameworks (ADK)

El Kit de desarrollo de agentes (ADK) es un framework centrado en el código para crear agentes de IA que administra la complejidad del enrutamiento de varios agentes, la ejecución de herramientas y la administración de estados. El framework de ADK es el mismo que impulsa Gemini Enterprise.

Con el ADK, puedes encadenar la API de Conversational Analytics con otras herramientas y agentes para realizar acciones complejas.

En esta sección, se abordan los siguientes temas:

Integración basada en el esquema con BigQueryToolset

El conjunto de herramientas BigQueryToolset en el framework del ADK incluye una herramienta ask_data_insights compilada previamente. Para usar esta herramienta, debes pasar los nombres de las tablas y la pregunta del usuario a la herramienta, que luego llama a la API de Conversational Analytics con el contexto intercalado.

Cuando llamas a la herramienta, se envía una solicitud sin estado que incluye las referencias de la tabla de BigQuery especificadas a la API de Conversational Analytics. La API infiere el esquema de la base de datos, genera y ejecuta la consulta en SQL, y devuelve una respuesta de texto. Luego, el resultado se devuelve al agente del ADK como respuesta de la herramienta.

Este patrón es una forma eficaz de agregar rápidamente análisis conversacionales a un agente. Sin embargo, debido a que la llamada a la API no tiene estado y carece de gobernanza, la API genera SQL basado completamente en el esquema de la tabla sin medidas de seguridad semánticas. Esto hace que el patrón sea más rápido de implementar, pero más riesgoso para la lógica empresarial de producción en la que se aplican convenciones de nomenclatura, lógica empresarial o controles de acceso.

Integración controlada con DataAgentToolset

El conjunto de herramientas DataAgentToolset en el framework del ADK proporciona una integración prediseñada que hace referencia a un agente de datos preconfigurado por su ID. El agente del ADK pasa la pregunta del usuario a la herramienta ask_data_agent, que llama a la API de Conversational Analytics con el contexto del agente de datos especificado.

Puedes crear un agente de datos de forma programática con la API de Conversational Analytics o a través del Catálogo de agentes en la consola de Google Cloud . Un agente de datos viene equipado con los siguientes componentes:

  • Fuentes de conocimiento: Son tablas, vistas o funciones definidas por el usuario (UDF) que el agente puede consultar.
  • Contexto estructurado: Son las descripciones de las tablas y las columnas que ayudan al agente a comprender los datos subyacentes.
  • Instrucciones: Orientación adicional para que el agente interprete y consulte las fuentes de datos
  • Consultas verificadas: Consultas en SQL validadas previamente que sirven como ejemplos para preguntas comunes
  • Glosario: Definiciones de términos comerciales que ayudan al agente a comprender el lenguaje específico del dominio

Si deseas obtener una guía detallada para crear agentes a través del Catálogo de agentes, consulta el codelab sobre análisis conversacional en BigQuery.

Dado que el agente se define como una unidad gobernada, usa la misma lógica, el mismo contexto y las mismas barreras de protección confiables, independientemente de la aplicación o el agente secundario que lo llame.

Integración avanzada de la UX con subagentes personalizados

Los conjuntos de herramientas BigQueryToolset y DataAgentToolset no muestran resultados al usuario hasta que finaliza el procesamiento de la solicitud a la API. Dado que el framework del ADK trata la API como una herramienta que bloquea las respuestas hasta que se completan, las consultas de mayor duración podrían dejar a los usuarios sin comentarios.

Como alternativa para las aplicaciones en las que la baja latencia de respuesta es una prioridad o en las que la recuperación de datos alimenta a los agentes posteriores, puedes compilar una clase de agente del ADK personalizada que se conecte directamente a la API de Conversational Analytics y transmita datos en fragmentos al usuario de forma asíncrona. Este patrón admite los siguientes tipos de respuestas a medida que se producen:

  • Mensajes de pensamiento: Proceso de razonamiento del agente de datos a medida que interpreta la pregunta.
  • Mensajes de progreso: Son actualizaciones de estado durante la recuperación de datos para las fuentes de datos.
  • Generación de consultas: Es la consulta de SQL o de Looker generada, que se transmite a medida que se produce.
  • Data: Son los resultados de los datos en formato JSON.
  • Visualización: Especificaciones del gráfico de Vega-Lite.
  • Resumen: Es la respuesta final basada en texto.

Para obtener una lista completa de los tipos de datos que se devuelven, consulta el tipo SystemMessage en la documentación de referencia de la API.

Este enfoque asíncrono garantiza que los usuarios no tengan que esperar a que finalice por completo un proceso complejo de recuperación de datos. A medida que el agente de datos avanza en el proceso de consulta, comparte de forma continua actualizaciones incrementales (como resúmenes de texto, datos sin procesar o configuraciones de gráficos) en un espacio de trabajo compartido temporal. Luego, estos datos se pueden renderizar para el usuario en tiempo real y compartirse con subagentes especializados para realizar tareas adicionales.

Para ver una implementación de referencia que incluya un agente raíz, un agente secundario de datos y un agente de visualización, consulta la demostración de transmisión del ADK en GitHub.

Integración vertical (MCP)

El Protocolo de contexto del modelo (MCP) es un estándar abierto que proporciona una forma uniforme para que las aplicaciones de IA se conecten a herramientas y fuentes de datos externas. El MCP estandariza la interfaz entre los modelos de IA y las herramientas que usan.

En esta sección, se abordan los siguientes temas:

MCP Toolbox para bases de datos

Si bien no hay un servidor de MCP de la API de Conversational Analytics dedicado, puedes acceder a la API a través del servidor de MCP Toolbox for Databases. Este servidor de código abierto proporciona herramientas prediseñadas y compatibles con MCP que exponen el método chat en la API de Conversational Analytics:

El MCP es una capa de interoperabilidad que expone las capacidades de Analytics como herramientas para los clientes compatibles con el MCP, en lugar de un modelo de ejecución independiente de la API de Conversational Analytics.

Patrones de implementación de MCP para arquitecturas independientes y de ADK

Puedes implementar el MCP con los siguientes patrones:

Patrón Detalles
MCP independiente (sin ADK)

Usar el servidor de MCP Toolbox for Databases como un servidor independiente para conectarse a cualquier cliente compatible con MCP Este patrón es de uso frecuente para las siguientes tareas:

  • Integración en el IDE: Conecta un IDE, como Antigravity, Cursor o VS Code, al servidor para consultar datos de forma conversacional desde un editor.
  • Cliente de MCP personalizado: Crea una aplicación que use el servidor para proporcionar una interfaz de herramientas uniforme en varios proveedores de IA.
  • Gemini CLI: Usa la CLI como cliente de MCP para conversaciones de datos basadas en la terminal.
MCP en el ADK

El framework del ADK proporciona los siguientes mecanismos para integrar servidores de MCP en los flujos de trabajo de los agentes:

  • ToolboxToolset: Es una variante especializada para el servidor de MCP Toolbox para bases de datos que admite varios métodos de autenticación.
  • McpToolset: Conecta un agente del ADK a cualquier servidor de MCP a través de conexiones locales o remotas. Descubre automáticamente las herramientas del servidor y las expone al agente.

También puedes compilar servidores MCP con el framework de FastMCP para exponer herramientas creadas con el framework del ADK a cualquier cliente compatible con MCP. Este enfoque hace que tus agentes del ADK estén disponibles como herramientas en otros ecosistemas.

Elige un patrón de integración según los requisitos arquitectónicos específicos de tu aplicación:

  • El uso de conjuntos de herramientas integrados del Kit de desarrollo de agentes (ADK), como BigQueryToolset o DataAgentToolset, proporciona una integración más estrecha sin dependencias de servidores externos. Este enfoque es ideal para los sistemas que existen completamente dentro del framework del ADK.
  • El uso de las herramientas en MCP Toolbox proporciona interoperabilidad entre los clientes compatibles con MCP. Este enfoque es ideal para las herramientas de datos que deben atender varias aplicaciones para el consumidor o IDE de terceros.

Organización horizontal (A2A)

El protocolo de agente a agente (A2A) es un estándar abierto que permite que los agentes especializados en diferentes sistemas se comuniquen y colaboren de forma segura sin necesidad de código de integración personalizado.

A medida que los sistemas se expanden, las organizaciones suelen implementar varios agentes especializados que se basan en diferentes frameworks o infraestructuras de nube. La A2A establece un nivel de mensajería universal para estos agentes autónomos. En lugar de usar APIs personalizadas, cada agente publica una tarjeta de agente, que es un perfil detectable que detalla las capacidades del agente, los formatos de datos admitidos y los requisitos de seguridad.

Cuando un agente central o un agente par requieren datos analíticos, delegan la tarea de forma segura a un agente de datos a través de mensajes estructurados de A2A. El agente de datos procesa la solicitud de forma autónoma y devuelve los resultados, lo que desacopla la lógica de ejecución del solicitante.

Elige un patrón de integración

Usa la siguiente tabla para comparar la complejidad, la administración y las capacidades de cada patrón de integración.

Los niveles de complejidad se definen de la siguiente manera:

  • Bajo: Patrones que requieren un mínimo de código personalizado y se basan en interfaces de usuario o herramientas prediseñadas
  • Medio: Patrones que requieren desarrollo personalizado de frontend y la integración de APIs o SDKs, pero evitan una infraestructura de orquestación de backend compleja.
  • Alta: Patrones que requieren desarrollo de aplicaciones de pila completa, administración del estado de la conversación, varias capas de autenticación o infraestructura de orquestador intermedia
  • Varía: Patrones en los que la complejidad depende del método de integración subyacente que elijas.
Patrón de integración Complejidad Personalización Administración de agentes Control de acceso Multiagente Transmisión Portabilidad
Incorporación de iframe de Looker Bajo Bajo Administración a través de Looker Looker No Integrado Solo Looker
API de Looker y SDKs Media Alta Administración a través de Looker Looker No Integrado Solo Looker
API de Conversational Analytics con fuente de Looker Varía Alta Se administra a través de la API Looker y IAM Sí Sí Cualquier superficie Google Cloud
Un solo agente (API directa) Media Alta Se administra a través de la API IAM No Sí (admite) Cualquier superficie Google Cloud
Organizador personalizado Alta Muy alta Se administra a través de la API IAM Manual Manual Cualquier superficie Google Cloud
Impulsado por el esquema con BigQueryToolset (ADK) Bajo Media Ninguno (inferencia de esquema) IAM Sí (ADK) No (bloqueo) Ecosistema del ADK
Regido por DataAgentToolset (ADK) Bajo Media Se administra a través de la API IAM Sí (ADK) No (bloqueo) Ecosistema del ADK
Agente secundario de transmisión personalizado (ADK) Alta Muy alta Se administra a través de la API IAM Sí (ADK) Sí (personalizado) Ecosistema del ADK
MCP independiente Media Media Ninguno (inferencia de esquema) IAM No No Cualquier cliente de MCP
MCP en el ADK Media Alta Ninguno (inferencia de esquema) IAM Sí (ADK) No Clientes de ADK y MCP
Protocolo A2A Alta Alta Dependiente del framework IAM Sí Sí Multiplataforma

¿Qué sigue?