Padrões de integração para agentes de dados

Nesta página, descrevemos padrões de integração para incorporar experiências de agente de dados aos seus aplicativos. Esses padrões variam em complexidade, desde um componente de chat incorporado até um sistema multiagente orquestrado.

Este guia é destinado a arquitetos de nuvem e engenheiros de dados que projetam aplicativos de IA generativa. Você precisa ter um conhecimento básico dos conceitos do Google Cloud , do Identity and Access Management e das APIs REST. Também é preciso conhecer a arquitetura da fonte de dados usada pelo aplicativo.

Visão geral dos padrões de integração

Este guia está organizado nas seguintes faixas principais com base no seu ponto de partida:

  • Programa do Looker: selecione esse programa se quiser oferecer funcionalidade de chat usando a incorporação do Looker, a API Looker ou a API Análises de conversação.
  • Programa BigQuery e banco de dados: selecione esse programa se você estiver criando um aplicativo personalizado que usa o BigQuery, o Data Studio ou um banco de dados operacional compatível.

A tabela a seguir resume os padrões de integração disponíveis:

Padrão de integração Descrição Fonte de dados
Incorporação de iframe do Looker Adiciona a interface de chat padrão a um aplicativo que exige um código mínimo. Looker
API Looker e SDKs Cria uma interface de chat personalizada que usa a API Looker para autenticação. Looker
API Análises de conversação (fonte do Looker) Gerencia agentes de dados do Looker como recursos Google Cloud que funcionam em várias plataformas e sistemas multiagentes. Looker
API direta (agente único) Usa uma integração direta de API para fluxos de texto para resposta. BigQuery, bancos de dados, Looker
API direta (orquestrador) Encaminha consultas entre a API e outras ferramentas usando a chamada de função. BigQuery, bancos de dados, Looker
ADK (baseado em esquema) com BigQueryToolset Gera insights rápidos de referências de tabela usando a ferramenta ask_data_insights. BigQuery
ADK (controlado) com DataAgentToolset Consultas a agentes de dados pré-configurados que usam a ferramenta ask_data_agent para garantir um comportamento consistente. BigQuery, bancos de dados, Looker
ADK (streaming personalizado) Oferece suporte a streaming em tempo real de gráficos e SQL usando uma classe de agente personalizada. BigQuery, bancos de dados, Looker
MCP com McpToolset ou ToolboxToolset Conecta aplicativos a ferramentas de dados que usam o Protocolo de Contexto de Modelo (MCP). Looker do BigQuery
Protocolo A2A Permite a colaboração segura entre agentes especializados que operam em sistemas diferentes. Dependente do framework

Opções de integração do Looker

Se você usa o Looker, pode oferecer a Análise de conversação do Looker aos usuários com os seguintes padrões:

Resumo dos padrões de integração do Looker

A tabela a seguir resume os principais padrões de integração do Looker:

Padrão Ideal para Vantagens Considerações
Incorporação com iframes: um método de pouco código para adicionar rapidamente a experiência padrão de chat do Looker a um aplicativo. Equipes que precisam de uma experiência de análise de conversação pronta para produção com desenvolvimento personalizado mínimo.
  • Requer pouco código para implementação.
  • Aplica automaticamente o modelo de segurança do Looker.
  • Não exige autenticação Google Cloud separada.
  • Compatível com o SDK Embed do Looker, que acelera o desenvolvimento gerenciando ciclos de vida de iframe e transmissão de eventos.
  • Oferece personalização limitada da UI e depende da interface padrão do chat do Looker.
  • Sua instância do Looker precisa ser hospedada pelo Looker.
Crie com a API do Looker e os SDKs: uma abordagem flexível para criar uma interface de chat personalizada, mantendo a autenticação e o gerenciamento de agentes no Looker. Equipes que precisam de uma experiência de usuário de chat personalizada, mas querem manter a autenticação de usuários e o gerenciamento de agentes no ecossistema do Looker. Esse padrão é ideal para aplicativos que já usam a incorporação do Looker ou a API.
  • Fornece uma única camada de autenticação e controle total sobre a interface do usuário.
  • Simplifica a arquitetura para clientes atuais do Looker.
  • Usa a camada semântica do Looker para melhorar a precisão das consultas.
  • Não exige autenticação Google Cloud separada.
  • Requer experiência em desenvolvimento de API Looker.
  • Limitado a fontes de dados do Looker.
  • Os agentes são gerenciados no Looker e não podem ser transferidos para outros serviços do Google Cloud .
Usar a API Análises de conversação: integração direta com a API para gerenciar agentes como recursos no nível da nuvem. Clientes do Looker que precisam de portabilidade multiplataforma para os agentes de dados.
  • Garante que o agente de dados seja portátil em todas as plataformas do Google Cloud .
  • Governado centralmente pelo Identity and Access Management.
  • Permite integrar agentes de dados aos fluxos de trabalho do ADK ou do MCP.
  • Exige que você gerencie a pilha de integração completa, incluindo a autenticação do Google Cloud e do Looker.
  • Os agentes de dados são gerenciados de forma independente da interface do usuário do Looker.

Incorporar com iframes

É possível incorporar as Análises de conversação como um iframe para oferecer a experiência de chat fora da interface do Looker. Esse padrão é uma maneira direta de fornecer a análise de conversas que não exige desenvolvimento UI personalizada, orquestração de back-end ou gerenciamento de estado da API. Para usar esse padrão, adicione um URL pré-formatado ao aplicativo.

O SDK de incorporação do Looker oferece ferramentas que gerenciam tarefas como geração de URL seguro, gerenciamento do ciclo de vida do iframe e transmissão de eventos JavaScript entre o aplicativo host e o iframe. Você pode incorporar a página Agentes, a página Conversas ou uma conversa específica adicionando um URL pré-formatado ao seu aplicativo.

Você pode usar os seguintes métodos de autenticação para conteúdo incorporado:

  • Incorporação particular: autentica usuários com as credenciais do Looker. Quando você define o URL de incorporação como a origem do iframe, os usuários fazem login com as contas do Looker. Esse método aplica automaticamente os papéis, o acesso ao conteúdo e as permissões no nível dos dados atuais, como filtros de acesso ou concessões de acesso, sem exigir configuração adicional do Identity and Access Management ou mapeamento de tokens.
  • Incorporação assinada: autentica usuários no seu aplicativo usando o Logon único (SSO). Você cria um URL assinado que inclui o caminho de conteúdo das Análises de conversação, permitindo especificar dinamicamente quais permissões conceder.

Criar com a API Looker e os SDKs

Para mais flexibilidade na experiência de chat, use os métodos ConversationalAnalytics na API Looker ou um SDK do Looker para criar um aplicativo personalizado. Essa abordagem permite criar um front-end personalizado que se comunica diretamente com os endpoints do Looker.

A integração com a API Looker oferece os seguintes benefícios:

  • Você só gerencia a autenticação com o Looker. Não é necessário fazer a autenticação separadamente com a API Análises de conversação.
  • Para aplicativos que já usam a incorporação do Looker ou a API, esse padrão simplifica a arquitetura do projeto, evitando mecanismos de autenticação secundários e eliminando a necessidade de gerenciar agentes de dados externos.
  • Você tem controle total sobre a interface de chat, o fluxo de conversa e como o aplicativo renderiza os resultados (como gráficos e tabelas).

Para uma implementação de referência, consulte o guia da API Looker Análises de conversação no GitHub.

Usar a API Análises de conversação com dados do Looker

Você pode fazer a integração diretamente com a API Análises de conversação em geminidataanalytics.googleapis.com se precisar realizar alguma das seguintes tarefas:

  • Compartilhe o mesmo agente de dados em várias Google Cloud plataformas, como aplicativos da Web personalizados, Google Chat e Gemini Enterprise.
  • Combinar fontes de dados do Looker com fontes do BigQuery ou de banco de dados operacional em um único sistema multiagente
  • Gerenciar seu agente de dados como um recurso no nível da nuvem governado pelo Identity and Access Management em vez do modelo de permissões do Looker

Para mais informações sobre padrões de arquitetura comuns para a API Análises de conversação, consulte Opções de integração para BigQuery e bancos de dados.

Opções de integração para o BigQuery e bancos de dados

Nesta seção, descrevemos padrões de arquitetura para aplicativos que usam o BigQuery, o Data Studio ou bancos de dados operacionais Google Cloud compatíveis para criar experiências personalizadas com a API Análises de conversação.

Se você usar a API Análises de conversação com uma fonte de dados do Looker, os padrões descritos nesta seção também se aplicam à sua integração.

A API Análises de conversação oferece os seguintes métodos principais para interagir com dados:

  • Método chat: compatível com BigQuery, Looker, Data Studio e bancos de dados operacionais.
  • Método queryData: compatível com bancos de dados operacionais, como AlloyDB, GoogleSQL para Spanner, Cloud SQL para MySQL e Cloud SQL para PostgreSQL.

Ao criar um aplicativo personalizado, você pode usar um ou mais dos seguintes padrões de integração:

  • Integração direta da API: uma abordagem personalizada que oferece mais flexibilidade, mas exige que você crie a infraestrutura para autenticação, gerenciamento de conversas e análise de respostas.
  • Orquestração orientada por framework (ADK): uma abordagem que usa o Kit de Desenvolvimento de Agente (ADK) para roteamento multiagente, execução de ferramentas e gerenciamento de estado.
  • Integração vertical (MCP): uma abordagem que usa o Protocolo de Contexto de Modelo (MCP) para fornecer uma maneira uniforme de conectar aplicativos de IA a ferramentas e fontes de dados em diferentes ambientes.
  • Orquestração horizontal (A2A): uma abordagem que usa o protocolo Agent-to-Agent (A2A) para permitir que agentes especializados em diferentes sistemas colaborem com segurança sem exigir um código de integração personalizado.

Resumo dos padrões de integração do BigQuery e de bancos de dados

A tabela a seguir resume os padrões de implementação específicos para o BigQuery e bancos de dados operacionais:

Padrão Ideal para Vantagens Considerações
Integração de agente único (API direta): um padrão em que seu aplicativo chama a API diretamente para retornar insights das suas fontes de dados. Aplicativos de agente único, protótipos ou microsserviços que exigem controle direto sobre cada chamada de API.
  • Fornece controle granular sem dependências de framework.
  • Fornece a arquitetura mais simples para casos de uso de agente único.
  • Compatível com os modos com e sem estado.
  • Exige que você crie toda a infraestrutura para autenticação, gerenciamento de estado, análise de respostas, tratamento de erros, streaming e implantação.
  • Não é adequado para cenários com vários agentes.
Orquestrador personalizado (API direta): um padrão que usa um agente raiz e chamadas de função para encaminhar consultas entre a API Análises de conversação e outras ferramentas ou serviços. Aplicativos que combinam consultas de dados com outras tarefas, como e-mail ou documentos, em um único fluxo de conversa.
  • Oferece controle máximo de orquestração sem dependências de framework.
  • Permite definir exatamente como o modelo faz o roteamento entre as ferramentas.
  • Funciona com qualquer modelo do Gemini.
  • Exige que você gerencie manualmente definições de ferramentas, loops de conversa, estado multiturno, tratamento de erros e implantação.
  • A sobrecarga de desenvolvimento pode se tornar pesada em comparação com o uso de uma estrutura como o ADK.
Integração orientada a esquema com o BigQueryToolset (ADK): um padrão que usa referências de tabela para retornar insights de dados rapidamente. Prototipagem rápida, ferramentas internas em que a governança de dados é menos crítica ou cenários em que os insights de dados são uma das várias funcionalidades de um agente do ADK.
  • Oferece o caminho de integração mais rápido no framework do ADK.
  • Não requer pré-configuração do agente de dados.
  • Funciona diretamente com nomes de tabelas de banco de dados.
  • Não tem governança semântica e gera SQL apenas com base na inferência de esquema.
  • Opera em um modo sem estado no nível da API.
  • Fornece respostas somente de texto e não é compatível com gráficos.
Integração controlada com DataAgentToolset (ADK): um padrão que consulta um agente de dados pré-configurado referenciando o ID dele. Aplicativos Production que exigem acesso aos dados consistente ou sistemas multiagentes em que o agente de dados é um componente confiável e reutilizável.
  • Oferece governança semântica e comportamento consistente em todos os consumidores.
  • Melhora a precisão usando consultas verificadas e um glossário empresarial.
  • Garante que os agentes de dados possam ser reutilizados em integrações diretas de ADK, MCP e API.
  • Exige que você pré-configure recursos do agente de dados.
  • Opera em um modo sem estado no nível da API.
  • Retorna respostas somente de texto e não aceita gráficos.
Subagentes personalizados (ADK): um padrão que usa uma classe de agente personalizada para se conectar diretamente à API e transmitir blocos de dados de volta ao usuário. Aplicativos voltados ao usuário em que a baixa latência de resposta é uma prioridade ou pipelines multiagente em que a recuperação de dados alimenta agentes downstream.
  • Oferece feedback de streaming em tempo real.
  • Acessa todos os tipos de respostas, como gráficos, tabelas e SQL.
  • Componível com outros agentes do ADK usando o estado da sessão.
  • Exige mais esforço de desenvolvimento para criar uma classe de agente ADK personalizada.
  • Exige que você gerencie diretamente a conexão de streaming e a análise da resposta.
Protocolo de Contexto de Modelo (MCP): um padrão que usa um padrão aberto para conectar aplicativos de IA a fontes de dados e ferramentas em diferentes ambientes. Organizações que exigem interoperabilidade de ferramentas em vários clientes de IA e IDEs ou equipes que precisam que as mesmas ferramentas de dados sejam acessíveis na estrutura do ADK, em IDEs e em aplicativos personalizados.
  • Usa um padrão de ferramenta universal que funciona com qualquer cliente compatível com o MCP.
  • Desvincula a implementação da ferramenta dos aplicativos consumidores.
  • Oferece opções de servidor gerenciado, como o servidor Google Cloud MCP.
  • Requer uma camada de infraestrutura adicional para o servidor da caixa de ferramentas.
  • Oferece uma integração menos completa do que os conjuntos de ferramentas do Kit de Desenvolvimento de Agente (ADK).
  • Depende do ecossistema em evolução da MCP Toolbox.
  • Opera em um modo sem estado que exige o gerenciamento externo do estado multiturno.
Agente para agente (A2A): um padrão que usa o protocolo A2A, um padrão aberto que permite que agentes especializados em diferentes sistemas colaborem com segurança sem exigir um código de integração personalizado. Ambientes empresariais altamente distribuídos em que um agente de roteamento central precisa delegar tarefas a agentes de dados que operam em diferentes sistemas ou redes.
  • Reduz a necessidade de código de integração personalizado entre frameworks diferentes.
  • Garante a interoperabilidade multiplataforma perfeita.
  • Oferece descoberta de recursos segura e padronizada.
  • Introduz uma pequena latência de rede em comparação com subagentes internos.
  • Exige que você configure as definições do servidor A2A.

Integração direta de API

A integração direta da API oferece controle granular sobre a lógica e a arquitetura do aplicativo, mas exige que você crie a infraestrutura de suporte. Com essa abordagem, você é responsável por tarefas como autenticação, gerenciamento de conversas, análise de respostas e implantação.

Esta seção abrange os seguintes tópicos:

Integração de um único agente

Com uma integração de agente único, seu back-end chama diretamente a API Análises de conversação usando REST ou uma biblioteca de cliente e transmite a consulta e o contexto do usuário. Esse padrão é adequado para aplicativos de baixa complexidade, como apps da Web, ferramentas de chat internas ou microsserviços, que usam um fluxo simples de texto para resposta. Você também pode usar essa abordagem para prototipagem e prova de conceito.

Esse padrão é compatível com conversas com estado, em que o Google gerencia o histórico, e sem estado, em que o aplicativo gerencia o histórico.

Para implementações de referência, consulte o guia de início rápido da API Análises de conversação ou a demonstração principal da API Análises de conversação no GitHub.

Integração de orquestrador personalizado

Com essa abordagem, você cria um agente raiz que atua como o ponto de entrada e coordenador principal do seu aplicativo. O agente raiz usa um modelo padrão do Gemini equipado com ferramentas por chamada de função. Quando um usuário faz uma pergunta relacionada a dados, o agente raiz emite uma chamada de função para a API Análises de conversação, recebe o resultado e pode continuar raciocinando ou chamar outras ferramentas downstream.

A chamada de função envolve as seguintes etapas:

  1. Declarar: defina esquemas de ferramentas como objetos FunctionDeclaration que incluem definições de parâmetros.
  2. Invocar: o modelo retorna uma mensagem functionCall estruturada que contém o nome e os argumentos da função.
  3. Executar: seu aplicativo faz a chamada de API e retorna o resultado em uma mensagem FunctionResponse.
  4. Síntese: o modelo do Gemini usa o resultado para gerar uma resposta final ou determinar a próxima ação.

Essa abordagem é adequada para aplicativos em que os usuários podem pedir insights de dados junto com outras tarefas. Por exemplo, um usuário pode pedir ao agente para "Mostrar minhas vendas e escrever um e-mail para a equipe de vendas". O agente raiz pode encaminhar a pergunta sobre dados para a API Análises de conversação e usar outras ferramentas para tarefas que não envolvem dados.

Para uma implementação de referência, consulte as páginas orchestrate ou multimodal na demonstração principal da API Análises de conversação no GitHub.

Orquestração orientada por framework (ADK)

O Kit de Desenvolvimento de Agente (ADK) é um framework que prioriza o código para criar agentes de IA que gerenciam a complexidade do roteamento multiagente, da execução de ferramentas e do gerenciamento de estado. O framework do ADK é o mesmo que alimenta o Gemini Enterprise.

Ao usar o ADK, você pode encadear a API Análises de conversação com outras ferramentas e agentes para realizar ações complexas.

Esta seção abrange os seguintes tópicos:

Integração orientada a esquema com BigQueryToolset

O conjunto de ferramentas BigQueryToolset no framework do ADK inclui uma ferramenta ask_data_insights pré-criada. Para usar essa ferramenta, transmita os nomes das tabelas e a pergunta do usuário para ela, que vai chamar a API Análises de conversação usando o contexto inline.

Quando você chama a ferramenta, ela envia uma solicitação sem estado que inclui as referências de tabela do BigQuery especificadas à API Análises de conversação. A API deduz o esquema do banco de dados, gera e executa a consulta SQL e retorna uma resposta em texto. O resultado é transmitido de volta ao agente do ADK como uma resposta da ferramenta.

Esse padrão é uma maneira eficaz de adicionar análises de conversação a um agente rapidamente. No entanto, como a chamada para a API não tem estado e não tem governança, ela gera SQL com base inteiramente no esquema da tabela, sem restrições semânticas. Isso torna o padrão mais rápido de implantar, mas mais arriscado para a lógica de negócios de produção, em que convenções de nomenclatura, lógica de negócios ou controles de acesso são aplicados.

Integração controlada com o DataAgentToolset

O conjunto de ferramentas DataAgentToolset no framework do ADK oferece uma integração pré-criada que faz referência a um agente de dados pré-configurado pelo ID. O agente do ADK transmite a pergunta do usuário para a ferramenta ask_data_agent, que chama a API Análises de conversação com o contexto especificado do agente de dados.

É possível criar um agente de dados de maneira programática usando a API Análises de conversação ou pelo Catálogo de agentes no console do Google Cloud . Um agente de dados vem equipado com os seguintes componentes:

  • Fontes de conhecimento: tabelas, visualizações ou funções definidas pelo usuário (UDFs) que o agente pode consultar
  • Contexto estruturado: descrições de tabelas e colunas que ajudam o agente a entender os dados subjacentes.
  • Instruções: orientações adicionais para o agente interpretar e consultar as fontes de dados
  • Consultas verificadas: consultas SQL pré-validadas que servem como exemplos para perguntas comuns
  • Glossário: definições de termos comerciais que ajudam o agente a entender a linguagem específica do domínio.

Para um guia detalhado sobre como criar agentes no catálogo, consulte o codelab Análise de conversas no BigQuery.

Como o agente é definido como uma unidade governada, ele usa a mesma lógica, contexto e proteções confiáveis, seja qual for o aplicativo ou subagente que o chama.

Integração avançada da UX com subagentes personalizados

Os conjuntos de ferramentas BigQueryToolset e DataAgentToolset não retornam resultados para o usuário até que a solicitação de API termine o processamento. Como o framework ADK trata a API como uma ferramenta que bloqueia respostas até a conclusão, consultas mais longas podem deixar os usuários sem feedback.

Como alternativa para aplicativos em que a baixa latência de resposta é uma prioridade ou em que a recuperação de dados alimenta agentes downstream, é possível criar uma classe de agente ADK personalizada que se conecta diretamente à API Análises de conversação e transmite dados em partes de volta ao usuário de forma assíncrona. Esse padrão é compatível com os seguintes tipos de resposta à medida que são produzidos:

  • Mensagens de pensamento: o processo de raciocínio do agente de dados ao interpretar a pergunta.
  • Mensagens de progresso: atualizações de status durante a recuperação de dados para fontes de dados.
  • Geração de consultas: a consulta SQL ou do Looker gerada, que é transmitida conforme é produzida.
  • Dados: os resultados dos dados no formato JSON.
  • Visualização: especificações de gráficos do Vega-Lite.
  • Resumo: a resposta final baseada em texto.

Para conferir uma lista completa dos tipos de dados retornados, consulte o tipo SystemMessage na documentação de referência da API.

Essa abordagem assíncrona garante que os usuários não precisem esperar que um processo complexo de recuperação de dados seja concluído. À medida que o agente de dados passa pelo processo de consulta, ele compartilha continuamente atualizações incrementais, como resumos de texto, dados brutos ou configurações de gráficos, em um espaço de trabalho temporário e compartilhado. Esses dados podem ser renderizados para o usuário em tempo real e compartilhados com subagentes especializados para realizar outras tarefas.

Para uma implementação de referência que inclui um agente raiz, um subagente de dados e um agente de visualização, consulte a demonstração de streaming do ADK no GitHub.

Integração vertical (MCP)

O Protocolo de Contexto de Modelo (MCP) é um padrão aberto que oferece uma maneira uniforme para os aplicativos de IA se conectarem a ferramentas e fontes de dados externas. O MCP padroniza a interface entre os modelos de IA e as ferramentas que eles usam.

Esta seção abrange os seguintes tópicos:

MCP Toolbox para bancos de dados

Embora não haja um servidor MCP dedicado da API Análises de conversação, é possível acessar a API pelo servidor MCP Toolbox para bancos de dados. Esse servidor de código aberto oferece ferramentas pré-criadas e compatíveis com o MCP que expõem o método chat na API Análises de conversação:

O MCP é uma camada de interoperabilidade que expõe recursos de análise como ferramentas para clientes compatíveis com o MCP, em vez de um modelo de execução separado da API Análises de conversação.

Padrões de implementação do MCP para arquiteturas autônomas e do ADK

É possível implementar o MCP usando os seguintes padrões:

Padrão Detalhes
MCP independente (sem ADK)

Use o servidor da MCP Toolbox for Databases como um servidor independente para se conectar a qualquer cliente compatível com o MCP. Esse padrão é usado com frequência para as seguintes tarefas:

  • Integração com IDE: conecte um IDE, como Antigravity, Cursor ou VS Code, ao servidor para consultar dados de forma conversacional em um editor.
  • Cliente MCP personalizado: crie um aplicativo que usa o servidor para fornecer uma interface de ferramenta uniforme em vários provedores de IA.
  • CLI do Gemini: use a CLI como um cliente MCP para conversas de dados baseadas em terminal.
MCP no ADK

O framework do ADK oferece os seguintes mecanismos para integrar servidores MCP aos fluxos de trabalho de agentes:

  • ToolboxToolset: uma variante especializada para o servidor da MCP Toolbox for Databases que oferece suporte a vários métodos de autenticação.
  • McpToolset: conecta um agente do ADK a qualquer servidor MCP usando conexões de servidor MCP local ou remoto. Descobre automaticamente as ferramentas do servidor e as expõe ao agente.

Também é possível criar servidores do MCP usando a estrutura FastMCP para expor ferramentas criadas com a estrutura do ADK a qualquer cliente compatível com o MCP. Essa abordagem disponibiliza seus agentes do ADK como ferramentas em outros ecossistemas.

Escolha um padrão de integração com base nos requisitos arquitetônicos específicos do seu aplicativo:

  • Usar conjuntos de ferramentas integrados do Kit de Desenvolvimento de Agente (ADK), como BigQueryToolset ou DataAgentToolset, oferece uma integração mais estreita sem dependências de servidores externos. Essa abordagem é ideal para sistemas que existem totalmente na estrutura do ADK.
  • Usar as ferramentas na MCP Toolbox oferece interoperabilidade entre clientes compatíveis com o MCP. Essa abordagem é ideal para ferramentas de dados que precisam atender a vários aplicativos de consumidores ou IDEs de terceiros.

Orquestração horizontal (A2A)

O protocolo Agent-to-Agent (A2A) é um padrão aberto que permite que agentes especializados em diferentes sistemas se comuniquem e colaborem com segurança sem exigir código de integração personalizado.

À medida que os sistemas são escalonados, as organizações costumam implantar vários agentes especializados criados em diferentes frameworks ou infraestruturas de nuvem. O A2A estabelece um nível de mensagens universal para esses agentes autônomos. Em vez de usar APIs personalizadas, cada agente publica um card de agente, que é um perfil detectável que detalha os recursos do agente, os formatos de dados compatíveis e os requisitos de segurança.

Quando um orquestrador central ou um agente de mesmo nível exige dados analíticos, ele delega a tarefa com segurança a um agente de dados por mensagens A2A estruturadas. O agente de dados processa a solicitação de forma autônoma e retorna as descobertas, o que separa a lógica de execução do solicitante.

Escolher um padrão de integração

Use a tabela a seguir para comparar a complexidade, a governança e os recursos de cada padrão de integração.

Os níveis de complexidade são definidos da seguinte maneira:

  • Baixo: padrões que exigem o mínimo de código personalizado e dependem de interfaces ou ferramentas de usuário pré-criadas.
  • Médio: padrões que exigem desenvolvimento de front-end personalizado e integração de API ou SDK, mas evitam infraestrutura complexa de orquestração de back-end.
  • Alto: padrões que exigem desenvolvimento de aplicativos full-stack, gerenciamento de estado de conversa, várias camadas de autenticação ou infraestrutura de orquestrador intermediário.
  • Varia: padrões em que a complexidade depende do método de integração escolhido.
Padrão de integração Complexidade Personalização Governança de agentes Controle de acesso Multiagente Streaming Portabilidade
Incorporação de iframe do Looker Baixo Baixo Gerenciado pelo Looker Looker Não Integrado Somente Looker
API Looker e SDKs Médio Alta Gerenciado pelo Looker Looker Não Integrado Somente Looker
API Análises de conversação com fonte do Looker Varia Alta Gerenciadas pela API Looker e IAM Sim Sim Qualquer Google Cloud plataforma
Agente único (API direta) Médio Alta Gerenciadas pela API IAM Não Sim (compatível) Qualquer Google Cloud superfície
Orquestrador personalizado Alta Muito alto Gerenciadas pela API IAM Manual Manual Qualquer Google Cloud plataforma
Orientado a esquema com BigQueryToolset (ADK) Baixo Médio Nenhum (inferência de esquema) IAM Sim (ADK) Não (bloqueio) Ecossistema do ADK
Regido por DataAgentToolset (ADK) Baixo Médio Gerenciadas pela API IAM Sim (ADK) Não (bloqueio) Ecossistema do ADK
Subagente de streaming personalizado (ADK) Alta Muito alto Gerenciadas pela API IAM Sim (ADK) Sim (personalizado) Ecossistema do ADK
MCP independente Médio Médio Nenhum (inferência de esquema) IAM Não Não Qualquer cliente MCP
MCP no ADK Médio Alta Nenhum (inferência de esquema) IAM Sim (ADK) Não Clientes do ADK e do MCP
Protocolo A2A Alta Alta Dependente do framework IAM Sim Sim Multiplataforma

A seguir