Desvendando a Interação com Agentes de Análise Conversacional do Looker
Se a sua empresa já tem suas próprias ferramentas, mas o acesso à camada semântica do Looker ainda é um gargalo, temos uma boa notícia! Agora é possível se conectar diretamente aos Agentes de Análise Conversacional (CA Agents) já existentes no seu Looker, sem a necessidade de criar wrappers customizados do zero.
A nova integração permite que esses agentes funcionem diretamente via A2A (Agent-to-Agent) protocol, apontando para um endpoint nativo da API do Looker. Isso significa que você pode conversar com seus agentes de qualquer cliente, usando o protocolo A2A e o Google Python ADK.
Entendendo a Arquitetura por Trás dos Agentes
Para facilitar essa conexão, foi desenvolvido um exemplo de cliente A2A, que funciona como uma interface de linha de comando (CLI) para desenvolvimento local. Vamos dar uma olhada na estrutura por baixo dos panos e como colocá-la para rodar.
1. A Estrutura do "Agent Card"
O SDK Python do ADK é a chave para se conectar a um agente A2A remoto. Ele se baseia em um arquivo de configuração estruturado, o "Agent Card". Pense nele como um perfil detalhado do agente remoto, que define sua localização, suas funcionalidades e os requisitos de segurança.
Como o endpoint A2A do Looker não disponibiliza nativamente o "Agent Card" em um local padrão, você precisa defini-lo no seu cliente A2A. Um "Agent Card" típico é composto por:
- Identidade & Endpoint: Define o nome do agente e o caminho exato na API do Looker que contém seu UUID específico.
- Capacidades & Modos: Declara explicitamente funcionalidades, como streaming, e especifica os tipos de dados aceitos para entrada e saída (ex:
text/plain). - Skills: Um resumo descritivo do que o agente é capaz de fazer (ex:
conversational_analytics), fornecendo contexto para camadas de orquestração. - Esquemas de Segurança: Detalha como o cliente deve provar sua identidade. Para prototipagem rápida, geralmente se configura para aceitar um token Bearer HTTP padrão.
2. Desacoplando a Lógica do Cliente ADK
O fluxo de execução no código da aplicação utiliza os elementos do ADK para traduzir texto bruto do usuário em respostas do Looker. Em vez de lidar com os detalhes do protocolo JSON-RPC, a aplicação cria um pipeline claro em várias etapas:
- Camada de Transporte Escopada: Um cliente HTTPX assíncrono é inicializado com os cabeçalhos de autorização necessários do Looker, garantindo que todas as chamadas de rede sejam assinadas com segurança.
- Inicialização do Agente: A classe
RemoteA2aAgentdo ADK utiliza o perfil do "Agent Card" para padronizar as interfaces de comunicação. - Isolamento de Sessão & Contexto: Um gerenciador de sessão em memória do ADK cria "invocations" únicas (
InvocationContext) para isolar conversas de diferentes usuários e manter o histórico. Para produção, é altamente recomendável usar o serviço gerenciado da plataforma. - Execução em Stream: O cliente aciona o motor de execução remota, retornando um gerador assíncrono que entrega os eventos em tempo real enquanto o Looker processa a consulta.
3. Testando a Integração Localmente
A maneira mais rápida de validar sua configuração A2A é usando a ferramenta CLI fornecida. Isso permite verificar a autorização do token e garantir que o Looker consiga interpretar suas solicitações em linguagem natural corretamente.
Preparando o Ambiente
Antes de executar o cliente, duplique o arquivo .env_example para um .env local e insira um token de acesso válido e de curta duração para a API do Looker. Certifique-se também de editar seu arquivo agent_card.json, substituindo os placeholders ( e ) pelos detalhes da sua instância Looker.
Executando Testes
Com as variáveis de ambiente configuradas, você pode interagir diretamente com a CLI. O projeto suporta nativamente o uv para uma execução simplificada, mas ambientes virtuais Python padrão também funcionam.
# Opção A: Execute instantaneamente usando uv (Recomendado)
uv run a2a-client chat -- prompt "Mostre minhas vendas totais da semana passada, divididas por geografia"
# Opção B: Execute via ambiente virtual Python padrão
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
a2a-client chat -- prompt "Mostre minhas vendas totais da semana passada, divididas por geografia"
Ao ser acionado, o cliente estabelece a conexão segura, envia o comando e exibe os resultados em tempo real no seu terminal.
Atenção para Segurança em Produção
Embora o uso de um token estático em um arquivo .env seja ótimo para testes locais, ambientes de produção exigem um fluxo OAuth 2.0 com PKCE para passar as credenciais do usuário final.
Ao implantar em produção, o arquivo agent_card_oauth.json é usado para descoberta de metadados OAuth, permitindo que o ADK encontre os endpoints de autorização corretos e os escopos necessários. No entanto, a autenticação em si é responsabilidade da sua aplicação cliente, que gerenciará o fluxo OAuth 2.0, incluindo redirecionamentos de navegador e troca de tokens.
Uma vez que sua aplicação obtenha o token dinâmico do usuário, ele é injetado no ADK. Essa arquitetura garante que as credenciais do usuário sejam tratadas com segurança e que o Looker aplique rigorosamente os controles de acesso e segurança em nível de linha para cada consulta conversacional.
chat_bubble Comentários (0)
Nenhum comentário ainda. Seja o primeiro a comentar!
Deixe seu comentário