A2A
Quando dois agentes pertencem a equipes ou aplicações diferentes, importar código ou compartilhar memória pode ser inviável. Agent2Agent, ou A2A, oferece uma interface para descobrir capacidades, enviar mensagens e acompanhar trabalho remoto. Nosso caso será um agente de compras que pede a um agente de logística uma análise de rota. O agente remoto pode levar tempo, precisar de informação adicional e produzir um artefato, em vez de responder tudo em uma única chamada síncrona.
A referência conferida é A2A 1.0.1, cujo contrato anuncia interfaces com protocolVersion 1.0 e pode usar bindings como JSON-RPC, gRPC e HTTP+JSON. Não vamos copiar Agent Cards0.3 como se fossem atuais. O exemplo local representa descoberta de interface e estados da tarefa sem abrir rede, permitindo compreender identificação, continuidade e saída. Depois, o laboratório exige a mesma semântica em uma integração real compatível com os dois runtimes.
JavaScriptJSONMCPAPIsAgentesAo terminar esta aula
- Agent Card descreve capacidades e interfaces, sem conceder autorização.
- Mensagens, tarefas e artefatos têm papéis distintos.
- Compatibilidade depende de protocolo, binding e contrato, além da linguagem.
Antes de continuar: Laboratório: MCP Security
Agent Card descreve uma interface pública
AgentesUma Agent Card apresenta identidade informativa, capacidades, skills, formatos e interfaces suportadas. A descoberta pode usar uma localização conhecida, um catálogo ou configuração direta. O consumidor deve escolher um binding e uma versão que realmente suporta e verificar o endpoint conforme sua política. A Card não é uma credencial nem prova de que o serviço entregará uma boa resposta. Quando houver informação protegida ou Card estendida, autenticação e controles de acesso continuam necessários. Não coloque segredos no documento público para facilitar a conexão.
Na versão atual, supportedInterfaces separa URL, protocolBinding e protocolVersion. A versão do software do agente é outra informação: um agente na versão2.0 pode oferecer protocolo1.0. Essa separação permite descobrir compatibilidade sem inferir pelo nome ou pela linguagem de implementação. Um cliente em JavaScript pode falar com um agente em Python porque ambos seguem o contrato de rede. Interoperabilidade entre linguagens não elimina diferenças de schema, autenticação, conteúdo ou limites operacionais; essas condições precisam ser verificadas antes de enviar dados reais.
Mensagens comunicam; tarefas acompanham trabalho; artefatos entregam saída
FundamentosUma mensagem representa comunicação com conteúdo e identidade própria. Uma task representa uma unidade de trabalho com identificador e estado, e um artifact representa a saída produzida. Essa separação permite perguntar pelo andamento sem reenviar o pedido inteiro, além de distinguir necessidade de informação adicional de conclusão. No caso de logística, a mensagem pede uma rota; a tarefa passa por trabalho e pode solicitar destino; o artefato final reúne a análise. Um texto dizendo “concluído” não substitui um estado verificável nem um artefato acessível.
Conserve identificadores de mensagem, tarefa e contexto para correlacionar os eventos. Eles possuem finalidades diferentes: mensagem identifica comunicação, tarefa identifica trabalho e contexto agrupa interações relacionadas. Não suponha que repetir uma mensagem com identificador novo será reconhecido como a mesma operação. O protocolo não remove a necessidade de política de deduplicação e idempotência no serviço. Depois de um timeout, consulte a tarefa conhecida quando possível antes de criar outra. Se não recebeu seu identificador, trate a incerteza conforme o contrato do servidor.
Binding não muda a responsabilidade pela tarefa
FundamentosJSON-RPC expressa operação, parâmetros, identificador e resposta ou erro. No binding atual de A2A, nomes de métodos seguem o contrato da versão, como SendMessage e GetTask. gRPC e HTTP+JSON mapeiam as operações a outras formas de comunicação. A escolha depende de compatibilidade e ambiente, não de qual linguagem parece mais próxima. Não misture nomes antigos de métodos com estruturas atuais. O simulador usa somente seleção de interface e estado local; ele não afirma construir todos os campos de um envelope A2A válido.
Streaming permite observar progresso quando anunciado e suportado, mas não transforma um evento parcial em resultado final. Uma conexão pode cair enquanto a tarefa continua no servidor. Polling ou retomada do acompanhamento, quando disponível, precisa usar a identidade correta e respeitar timeout. Cancelar também não garante desfazer um efeito já concluído. Defina a política do consumidor para tarefas pendentes, falhas e pedidos de informação, preservando o limite total do trabalho. Uma tarefa remota não deve esperar indefinidamente porque o endpoint ainda responde a consultas de status.
const card={name:'LogisticaLocal',version:'1.0.0',supportedInterfaces:[{url:'https://exemplo.invalid/a2a',protocolBinding:'JSONRPC',protocolVersion:'1.0'}]};
function selecionar(c) { const i=c.supportedInterfaces.find(x=>x.protocolBinding==='JSONRPC'&&x.protocolVersion==='1.0'); if(!i)throw new Error('interface incompativel'); return i; }
let tarefa={id:'T7',status:{state:'TASK_STATE_INPUT_REQUIRED'}};
function completar(destino) {
if(!destino)throw new Error('destino necessario');
tarefa={...tarefa,status:{state:'TASK_STATE_COMPLETED'},artifacts:[{artifactId:'A7',name:'rota',parts:[{text:'Rota simulada para '+destino}]}]};
return tarefa;
}
console.log(selecionar(card),tarefa,completar('Cuiaba'));
try { selecionar({...card,supportedInterfaces:[]}); } catch(e) { console.log(e.message); }MCP e A2A podem coexistir
MCPAPIsMCP expõe operações e contexto a uma aplicação de modelos; A2A organiza interação com trabalho de outro agente por um contrato público. A diferença é de semântica e fronteira, não uma disputa de protocolo melhor. Um agente de logística A2A pode usar ferramentas MCP internamente, e um controlador pode consultar catálogo MCP antes de delegar análise A2A. O consumidor não precisa conhecer o raciocínio ou a implementação interna do agente remoto, mas precisa de contrato suficiente para validar a saída e decidir se pode usá-la.
↗ Agent2Agent Protocol Specification v1.0.1↗ Architecture — MCP 2026-07-28
Avalie interface incompatível, tarefa pedindo dados, falha terminal, artefato ausente e acesso a tarefa de outro usuário. O controlador deve tratar artefatos como dados externos e verificar origem, tamanho e correspondência com a solicitação. Um agente remoto que pede para enviar credenciais não ganha essa permissão por ser descoberto via Card. Para integração ADK ou outro framework, confirme a versão A2A suportada pelo adaptador. O fato de existir um guia de integração não prova compatibilidade automática com a versão atual da especificação.
↗ A2A Quickstart: Consuming↗ Agent2Agent Protocol Specification v1.0.1
Exercício aplicado
Um agente de compras solicita análise de rota a um agente remoto. Descubra uma interface compatível, forneça destino quando solicitado e valide o artefato sem criar tarefas duplicadas após desconexão.
- Execute seleção de interface e uma versão incompatível.
- Observe informação necessária e conclua a tarefa com destino.
- Implemente a troca em um binding A2A compatível e capture identificadores.
- Teste artefato ausente, consulta por outra identidade e desconexão.
Abrir resolução comentada
A seleção procura uma interface JSONRPC com protocolVersion 1.0 e bloqueia quando só há outra versão. A tarefa local começa exigindo informação e passa a concluída quando recebe um destino. Seu artefato identifica a saída da análise. Esse percurso mostra a diferença entre descoberta, comunicação adicional e conclusão, sem enviar pedidos reais.
Na implementação integrada, use os campos e envelopes definidos pelo binding da versão confirmada. Capture o identificador de tarefa e consulte o estado sem criar trabalho novo. Valide o artefato contra a solicitação e documente autenticação, timeout e comportamento após desconexão.
const card={name:'LogisticaLocal',version:'1.0.0',supportedInterfaces:[{url:'https://exemplo.invalid/a2a',protocolBinding:'JSONRPC',protocolVersion:'1.0'}]};
function selecionar(c) { const i=c.supportedInterfaces.find(x=>x.protocolBinding==='JSONRPC'&&x.protocolVersion==='1.0'); if(!i)throw new Error('interface incompativel'); return i; }
let tarefa={id:'T7',status:{state:'TASK_STATE_INPUT_REQUIRED'}};
function completar(destino) {
if(!destino)throw new Error('destino necessario');
tarefa={...tarefa,status:{state:'TASK_STATE_COMPLETED'},artifacts:[{artifactId:'A7',name:'rota',parts:[{text:'Rota simulada para '+destino}]}]};
return tarefa;
}
console.log(selecionar(card),tarefa,completar('Cuiaba'));
try { selecionar({...card,supportedInterfaces:[]}); } catch(e) { console.log(e.message); }Como conferir seu resultado
- O consumidor rejeita binding ou versão não suportados.
- A informação adicional continua o trabalho identificado.
- Artefatos e status privados não são entregues a outra identidade.
Aplique em um problema novo
Primeiro resolva sem consultar a resposta. Explique suas decisões e guarde a evidência. A conclusão de leitura é independente desta autoavaliação.
Confira seus pré-requisitos
- Ler Card/binding/tarefa/artefato.
- Separar desconexão e cancelamento.
Rota remota retorna taskId mas conexão fecha antes do artefato. Outro usuário conhece id. O que fazer?
Conferir raciocínio e critérios de domínio
Identificador não é autorização; consulta de outro usuário é recusada.
Retomar GetTask na mesma tarefa, sem recriar por desconexão; verificar binding/revisão da Card.
Estado concluído sem artefato esperado é resultado incompleto.
Evidências para autoavaliação ou revisão por pares
- Identidade: Identificador não é autorização; consulta de outro usuário é recusada.
- Continuidade: Retomar GetTask na mesma tarefa, sem recriar por desconexão; verificar binding/revisão da Card.
- Resultado: Estado concluído sem artefato esperado é resultado incompleto.
Um erro frequente
Conexão fechada prova que tarefa não começou.
Desconexão não prova ausência de trabalho; consultar a tarefa conhecida.
Teste sua compreensão
Responda com suas palavras antes de abrir o comentário. Saber explicar uma decisão é parte do domínio.
1. A2A 1.0.1 exige somente JSON-RPC?
Não. A especificação define múltiplos bindings.
A Card informa interfaces e o consumidor escolhe uma compatível.
2. Mensagem e artefato são equivalentes?
Não. Mensagem comunica; artefato representa saída do trabalho.
Separar ambos facilita acompanhar e validar a tarefa.
3. MCP e A2A são substitutos obrigatórios?
Não. Podem compor fronteiras diferentes no mesmo sistema.
Um agente remoto pode usar MCP internamente e expor trabalho via A2A.
↗ Agent2Agent Protocol Specification v1.0.1↗ Architecture — MCP 2026-07-28
Seu progresso fica salvo neste navegador. Concluir a leitura não substitui demonstrar o domínio nos exercícios.
Referências e aprofundamento
Documentação oficial e trabalhos originais. As referências registram o escopo e as limitações para você conferir o que sustentam.
- Agent2Agent Protocol Specification v1.0.1
A2A Project / Linux Foundation • consulta: 2026-10-06
APIsAgent Cards, discovery, tarefas, mensagens, artefatos, interoperabilidade, segurança, comparação MCP e bindings JSON-RPC/gRPC/HTTP+JSON.
Limites: Fixar versão do protocolo/SDK no laboratório; JSON-RPC é um binding, não a única opção.
- Base protocol — MCP 2026-07-28
Model Context Protocol • consulta: 2026-10-06
MCPJSON-RPC, schema, versão/capabilities em _meta e JSON Schema2020-12.
Limites: Fonte aberta contém versão por requisição; compatibilidade com revisões antigas exige implementação explícita.
- Architecture — MCP 2026-07-28
Model Context Protocol • consulta: 2026-10-06
MCPInfraestruturaHost, clients e servers, fronteiras de segurança e requisições stateless com versão/capabilities.
Limites: Difere das revisões baseadas em initialize; SDKs e clientes antigos podem usar a arquitetura legada.
- A2A Quickstart: Consuming
Google ADK • consulta: 2026-10-06
Google ADKAPIsConsumir agente remoto A2A e uso de Agent Card; integração ADK.
Limites: A interoperabilidade depende da versão A2A e das capacidades concretas do SDK e servidor.