A maioria dos sistemas de IA hoje são agentes únicos. Um modelo, um loop de prompt, um conjunto de ferramentas. Isso funciona até que o trabalho seja grande demais para um único agente, ou até que você precise de um agente construído por outra equipe para lidar com uma etapa que seu agente não consegue. Então você encontra um obstáculo: não há uma maneira padrão para dois agentes independentes se encontrarem, trocarem trabalho e relatarem resultados. Agent2Agent (A2A) é o protocolo construído para remover esse obstáculo.
Este guia explica o que é o A2A, o problema que ele resolve, como funciona nos bastidores e como difere do MCP. Se você quiser testar um agente A2A depois de ler isto, o guia do Apidog A2A Debugger continua de onde esta postagem termina.
button
O que é Agent2Agent (A2A)?
Agent2Agent (A2A) é um protocolo aberto para comunicação entre agentes de IA. Ele define como um agente anuncia suas capacidades, como outro agente se conecta a ele, como os dois trocam mensagens e arquivos, e como o status da tarefa retorna ao solicitante.
A palavra-chave é entre. O A2A não se trata de dar mais ferramentas a um agente. Trata-se de permitir que agentes separados, muitas vezes construídos em diferentes frameworks por diferentes equipes, trabalhem juntos sem que nenhum dos lados conheça os detalhes internos do outro.
Pense nisso como o HTTP para o tráfego de agentes. O HTTP permite que um navegador converse com qualquer servidor web sem se importar com a linguagem em que o servidor está executando. O A2A permite que um agente LangGraph converse com um agente CrewAI sem se importar como esse agente foi construído. Ambos os lados concordam com o "envelope"; nenhum lado revela sua implementação.
O Google introduziu o A2A em 2025 e, posteriormente, o transferiu para a Linux Foundation como um projeto neutro em relação a fornecedores. A especificação está disponível publicamente no repositório A2A do GitHub, e as implementações de referência são publicadas no site do projeto A2A.
O problema que o A2A resolve
Antes do A2A, conectar dois agentes significava escrever código "cola". Cada emparelhamento era personalizado. Se seu agente precisasse chamar o agente de pesquisa de uma equipe parceira, alguém escrevia um cliente sob medida, escolhia um formato de payload, inventava um esquema de autenticação e mantinha tudo isso manualmente. O próximo emparelhamento começava do zero novamente.
Essa abordagem falha rapidamente:
- Nenhuma descoberta. Não havia uma maneira padrão para um agente perguntar "o que você pode fazer?" antes de enviar o trabalho.
- Nenhum modelo de tarefa compartilhado. Um agente retornava uma string simples, outro retornava um blob JSON personalizado, um terceiro transmitia tokens. O solicitante tinha que tratar cada um de forma especial.
- Nenhuma autenticação comum. Toda integração reinventava credenciais e cabeçalhos.
- Nenhuma interoperabilidade. Um agente construído no AutoGen não poderia substituir um construído no LangGraph, mesmo quando ambos faziam o mesmo trabalho.
O A2A corrige isso da mesma forma que o OpenAPI corrigiu as integrações REST: um contrato acordado, para que qualquer agente compatível possa conversar com qualquer outro agente compatível.
Como o A2A funciona
O A2A possui quatro conceitos centrais. Depois de conhecê-los, todo o protocolo cabe na sua cabeça.
O Cartão de Agente
O Cartão de Agente é um documento JSON que um agente publica para se descrever. É o ponto de entrada para a descoberta. Ele lista o nome do agente, descrição, capacidades, habilidades declaradas, tipos de entrada e saída suportados, requisitos de autenticação e versão do protocolo.
Por convenção, o cartão reside em um caminho conhecido, frequentemente `https://your-agent.example.com/.well-known/agent.json`. Um agente solicitante busca essa URL primeiro, lê o cartão e aprende exatamente o que pode pedir antes de enviar uma única mensagem.
Tarefas
Uma tarefa é a unidade de trabalho no A2A. Quando um agente pede a outro para fazer algo, essa solicitação se torna uma tarefa com seu próprio ID e um status que transita por estados como `submitted` (enviado), `working` (em andamento), `input-required` (entrada necessária) e `completed` (concluído). O solicitante pode consultar a tarefa ou se inscrever para atualizações. Este modelo de tarefa compartilhada é o que torna os agentes A2A intercambiáveis; o solicitante lida com o status da mesma forma, independentemente de quem esteja realizando o trabalho.
Mensagens e artefatos
Uma mensagem transporta o conteúdo real entre os agentes. Uma mensagem é composta de partes: uma parte de texto, uma parte de arquivo, dados estruturados ou uma mistura. O agente receptor lê as partes que sua habilidade precisa.
Quando o agente termina, ele retorna artefatos; as saídas estruturadas da tarefa. Um artefato pode ser um documento gerado, uma tabela de dados, um resumo ou uma referência a um arquivo. Os artefatos também são construídos a partir de partes, para que o formato permaneça consistente em ambas as direções.
Streaming e atualizações
Tarefas de longa duração não precisam bloquear. O A2A suporta eventos enviados pelo servidor (server-sent events), para que um agente possa transmitir resultados parciais e mudanças de status à medida que o trabalho avança. Um agente de pesquisa pode emitir "encontrou 3 fontes" antes de emitir o relatório final. O solicitante exibe o progresso em vez de ficar olhando para um "spinner".
Juntando tudo, uma troca A2A típica se parece com isto:
- O Agente A busca o Cartão de Agente do Agente B e lê suas habilidades.
- O Agente A envia uma mensagem que cria uma tarefa.
- O Agente B executa a tarefa e transmite atualizações de status.
- O Agente B retorna artefatos quando a tarefa atinge o status `completed` (concluído).
- O Agente A consome os artefatos e segue em frente.
Toda a conversa é JSON sobre HTTP. Nada exótico.
A2A vs MCP
A2A e o Protocolo de Contexto do Modelo (MCP) são constantemente confundidos porque ambos envolvem agentes e ambos são protocolos abertos. Eles resolvem problemas diferentes.
| A2A | MCP | |
|---|---|---|
| Conecta | Agente a agente | Agente a ferramentas e dados |
| Pergunta que responde | "Outro agente pode fazer esta etapa por mim?" | "Quais ferramentas e recursos este agente pode alcançar?" |
| Uso típico | Fluxos de trabalho multiagente entre equipes | Um único agente chamando um banco de dados, sistema de arquivos ou API |
| Unidade de troca | Tarefas, mensagens, artefatos | Chamadas de ferramentas, recursos, prompts |
O MCP é como um agente alcança *sistemas externos*. O A2A é como um agente se conecta *a outro agente*. Um sistema de produção real frequentemente usa ambos: um agente usa o MCP para consultar um banco de dados e o A2A para entregar uma subtarefa a um agente especialista. A comparação entre servidor MCP e A2A aborda a decisão em profundidade, e o debugger de cliente MCP da Apidog mostra o lado do MCP na prática.
Colaboração multiagente na prática
O A2A é uma maneira de fazer os agentes colaborarem, mas não a única. Alguns sistemas usam orquestração direta, onde um agente planeja o trabalho e delega explicitamente a outro.
Um exemplo claro de código aberto é o Codex-Claude-Collab, uma habilidade que coordena um fluxo de trabalho em tempo real entre o OpenAI Codex e o Claude Code. O Codex planeja a tarefa, delega a implementação ao Claude Code e, em seguida, revisa a diferença e verifica o resultado antes de responder ao usuário. É um ciclo estreito de planejamento e construção entre dois agentes de codificação diferentes.
Esse padrão é uma orquestração "hard-wired"; um lado sabe exatamente quem é o outro. O A2A generaliza a mesma ideia: em vez de o Codex saber que está chamando especificamente o Claude Code, um solicitante A2A lê um Cartão de Agente e trabalha com qualquer agente compatível que responda. A orquestração é ótima quando você controla ambas as extremidades. O A2A é o que você deseja quando os agentes são independentes, pertencem a equipes diferentes ou precisam ser intercambiáveis. A maioria dos sistemas maduros acaba com ambos: orquestração dentro de uma equipe, A2A através das fronteiras das equipes.
Como testar um agente A2A
Depois de construir ou consumir um agente A2A, você precisa ver o tráfego. Os logs do console ocultam os campos estruturados, e scripts de teste personalizados se tornam obsoletos. É aqui que um depurador visual A2A ganha seu lugar.
O Apidog inclui um A2A Debugger em seu cliente padrão. Você cola a URL de um Cartão de Agente, clica em Conectar, e o Apidog lê o cartão e exibe o nome, as capacidades e as habilidades do agente. Você envia uma mensagem de teste, anexa arquivos, adiciona metadados e lê a resposta em três visualizações: uma prévia legível, o conteúdo bruto e o payload JSON-RPC completo. Ele lida com Bearer Token, Basic Auth e cabeçalhos de chave de API sem usar curl.
O objetivo é o isolamento. Quando um agente se comporta mal, você quer saber se o transporte está errado ou se a lógica do agente está errada. Ver o payload exato na rede responde a isso em segundos. O guia do Apidog A2A Debugger demonstra um ciclo completo de conexão-envio-leitura, e o princípio mais amplo de testar agentes de IA que chamam suas APIs aplica a mesma disciplina de "confirmar primeiro a comunicação".
Começando com A2A
Se você deseja construir ou conectar um agente A2A, um caminho rápido:
- Leia a especificação A2A para conhecer os campos obrigatórios do Cartão de Agente e o ciclo de vida da tarefa.
- Execute um dos agentes de exemplo de referência localmente. A maioria inicia em poucos minutos e expõe um Cartão de Agente funcional.
- Aponte um depurador A2A para a URL do Cartão de Agente da amostra e envie uma mensagem de "olá". Confirme que você consegue ver a comunicação de ida e volta.
- Crie seu próprio agente, exponha um Cartão de Agente válido e teste-o da mesma forma antes de integrá-lo a um fluxo de trabalho.
- Adicione autenticação, anexos de arquivo e streaming assim que o caminho de texto simples funcionar.
O A2A é jovem, mas é apoiado por uma fundação neutra em relação a fornecedores e uma lista crescente de integrações de frameworks. Tratar o tráfego de agentes como um protocolo de primeira classe agora evita a necessidade de reescrever "código cola" personalizado mais tarde. A postagem Agentes de IA são os novos consumidores de API apresenta o argumento mais longo, e projetar APIs para agentes de IA aborda o que muda quando seu consumidor é um agente em vez de um humano.
Perguntas frequentes
O A2A foi criado pelo Google?
O Google introduziu o A2A em 2025 e depois o doou para a Linux Foundation como um projeto aberto e neutro em relação a fornecedores. A especificação é desenvolvida abertamente, e qualquer fornecedor pode implementá-la.
Preciso do A2A se tiver apenas um agente?
Não. O A2A resolve a comunicação entre agentes. Um único agente com um conjunto de ferramentas precisa de MCP, não de A2A. Você recorre ao A2A quando um segundo agente entra em cena.
Quais frameworks suportam A2A?
O A2A é agnóstico em relação a frameworks por design. Qualquer agente que publique um Cartão de Agente válido e "fale" o protocolo pode participar, então LangGraph, CrewAI, AutoGen e agentes personalizados funcionam. O framework interno do agente é invisível para os solicitantes.
A2A é o mesmo que MCP?
Não. O MCP conecta um agente a ferramentas e fontes de dados. O A2A conecta agentes uns aos outros. Eles são complementares, e muitos sistemas executam ambos simultaneamente.
Como depurar uma integração A2A?
Use um depurador visual A2A, como o Apidog A2A Debugger. Cole a URL do Cartão de Agente, envie mensagens de teste e inspecione a solicitação e a resposta brutas para poder distinguir erros de transporte de erros de lógica do agente.
O A2A suporta tarefas de longa duração?
Sim. O modelo de tarefa possui estados de status explícitos, e o protocolo suporta eventos enviados pelo servidor (server-sent events) para transmissão de resultados parciais e atualizações de progresso, para que tarefas longas não bloqueiem o solicitante.
button