Português (Portugal)

A2A vs MCP: Dois protocolos complementares para o emergente ecossistema de agentes

Este artigo apresenta o A2A e o MCP — dois protocolos emergentes que estão a moldar o futuro dos sistemas de agentes de IA. Explica como funcionam, como diferem e porque compreender esta arquitetura importa para desenvolvedores, designers e construtores de produtos de IA.

Guamian

Product & Design

4/11/2025

Pare de perder semanas com autenticação de utilizadores

Lance aplicações seguras mais rapidamente com o Logto. Integre a autenticação de utilizadores em minutos e concentre-se no seu produto principal.

Começar

A crescente adoção de agentes de IA — entidades de software autónomas ou semi-autónomas que realizam raciocínios e ações em nome dos utilizadores — está a dar origem a uma nova camada na arquitetura de aplicações.

No início de 2025, dois protocolos distintos surgiram para enfrentar este desafio — A2A (Agente-para-Agente) e MCP (Protocolo de Contexto de Modelo). Uma maneira simples de entender os seus papéis é:

A2A: Como os agentes interagem uns com os outros

MCP: Como os agentes interagem com ferramentas ou contexto externo

referência: https://google.github.io/A2A/#/topics/a2a_and_mcp

Eles abordam o desafio central de construir sistemas com múltiplos agentes, múltiplas MLLs, e múltiplas fontes de contexto — todos precisando colaborar.

Uma maneira de enquadrá-lo é: “O MCP fornece integração vertical (aplicação-para-modelo), enquanto o A2A fornece integração horizontal (agente-para-agente).

Quer seja um desenvolvedor ou não, qualquer pessoa que construa produtos de IA ou sistemas agentivos deve entender a arquitetura fundamental — porque ela molda como projetamos produtos, interações com utilizadores, ecossistemas, e crescimento a longo prazo.

Este artigo apresenta ambos os protocolos de forma simples e fácil de entender e destaca pontos chave para desenvolvedores e construtores de produtos de IA.

O que é o A2A (Agente-para-Agente)?

A2A (Agente-para-Agente) é um protocolo aberto desenvolvido pela Google e mais de 50 parceiros da indústria. Seu propósito é permitir a interoperabilidade entre agentes — independentemente de quem os construiu, onde estão hospedados, ou que framework usam.

Mecanismo do protocolo A2A

O A2A utiliza JSON-RPC 2.0 sobre HTTP(S) como mecanismo de comunicação, com suporte para Eventos Enviados pelo Servidor (SSE) para transmitir atualizações.

Modelos de comunicação A2A

O A2A define um modelo estruturado de como dois agentes interagem. Um agente assume o papel de “agente cliente”, que inicia uma solicitação ou tarefa, e outro age como “agente remoto”, que recebe a solicitação e tenta realizá-la. O agente cliente pode primeiro realizar uma descoberta de capacidades para determinar qual agente é mais adequado para um dado trabalho.

Aqui surge uma questão, como os agentes se descobrem. Cada agente pode publicar um Cartão de Agente (um documento de metadados JSON, frequentemente hospedado em um URL padrão como /.well-known/agent.json) descrevendo suas capacidades, habilidades, pontos finais de API, e requisitos de autenticação.

Ao ler um Cartão de Agente, um agente cliente pode identificar um agente parceiro adequado para a tarefa em questão — essencialmente um diretório do que esse agente sabe ou pode fazer. Uma vez escolhido o agente alvo, o agente cliente formula um objeto Tarefa para enviar.

referência: https://google.github.io/A2A/#/

Gestão de Tarefas

Toda a interação no A2A é orientada para a realização de tarefas. Uma tarefa é um objeto estruturado (definido pelo esquema do protocolo) que inclui detalhes da solicitação e acompanha seu estado.

No A2A, cada agente desempenha um de dois papéis:

Agente Cliente: inicia uma tarefa
Agente Remoto: recebe e processa a tarefa

As tarefas podem incluir qualquer forma de trabalho: gerar um relatório, recuperar dados, iniciar um fluxo de trabalho. Os resultados são retornados como artefactos, e os agentes podem enviar mensagens estruturadas durante a execução para coordenar ou esclarecer.

Colaboração e negociação de conteúdo

O A2A suporta mais do que simples solicitações de tarefas — os agentes podem trocar mensagens ricas e multi-partes que incluem texto, JSON, imagens, vídeo, ou conteúdo interativo. Isso permite a negociação de formato com base no que cada agente pode manipular ou exibir.

Por exemplo, um agente remoto poderia retornar um gráfico como dados brutos ou uma imagem, ou solicitar a abertura de um formulário interativo. Este design suporta uma comunicação flexível, agnóstica em relação à modalidade, sem exigir que os agentes compartilhem ferramentas internas ou memória.

Exemplo de caso de uso

Aqui está um exemplo do mundo real de como o A2A poderia ser usado em um cenário empresarial:

Um novo funcionário é contratado em uma grande empresa. Múltiplos sistemas e departamentos estão envolvidos no processo de integração:

O RH precisa criar um registo e enviar um e-mail de boas-vindas
A equipe de TI precisa fornecer um portátil e contas da empresa
As instalações precisam preparar uma mesa e crachá de acesso

Tradicionalmente, esses passos são realizados manualmente ou através de integrações fortemente acopladas entre sistemas internos.

Em vez de APIs personalizadas entre cada sistema, cada departamento expõe seu próprio agente usando o protocolo A2A:

Agente	Responsabilidade
hr-agent.empresa.com	Criar registo de funcionário, enviar documentos
it-agent.empresa.com	Criar conta de e-mail, encomendar portátil
facilities-agent.empresa.com	Atribuir mesa, imprimir crachá de acesso

Um sistema multi-agente — chamemos de OnboardingPro (e.g. onboarding-agent.empresa.com) — coordena todo o fluxo de trabalho de integração.

Descoberta: Ele lê o.well-known/agent.json de cada agente para entender capacidades e autenticações.
Delegação de Tarefas:
- Envia uma tarefa createEmployee para o agente de RH.
- Envia as tarefas setupEmailAccount e orderHardware para o agente de TI.
- Envia assignDesk e generateBadge para o agente de Instalações.
Atualizações em fluxo: Os agentes transmitem progresso de volta usando Eventos Enviados pelo Servidor (e.g. “portátil enviado”, “mesa atribuída”).
Coleção de artefactos: Os resultados finais (e.g. crachá em PDF, e-mails de confirmação, credenciais de conta) são retornados como artefactos do A2A.
Conclusão: O OnboardingPro notifica o gerente de contratação quando a integração está completa.

O que é MCP (Protocolo de Contexto de Modelo)?

MCP (Protocolo de Contexto de Modelo), desenvolvido pela Anthropic, aborda outro problema: como as aplicações externas podem fornecer contexto estruturado e ferramentas a um agente baseado em modelo de linguagem durante a execução.

Em vez de permitir a comunicação entre agentes, o MCP foca na janela de contexto — a memória de trabalho de um MLL. Seu objetivo é:

Injetar dinamicamente ferramentas relevantes, documentos, funções de API, ou estado do utilizador na sessão de inferência de um modelo
Permitir que modelos chamem funções ou busquem documentos sem precisar codificar o prompt ou a lógica

Arquitetura chave do MCP

Para entender o MCP, primeiro é necessário entender a arquitetura geral — como todas as partes trabalham juntas.

Host MCP: “A IA com quem você está a falar”

Pense no Host MCP como a própria aplicação de IA — como o Claude Desktop ou o seu assistente de codificação.

É a interface que você está a usar — o local onde você digita ou conversa.

Ele deseja atrair ferramentas e dados que ajudem o modelo a dar melhores respostas.

Cliente MCP: “O conector”

O Cliente MCP é a peça de software que conecta o seu host de IA (como o Claude) ao mundo exterior. É como uma central de comunicação — gerencia conexões seguras individualizadas com diferentes Servidores MCP. Quando a IA quer acesso a algo, ela vai através do cliente.

É útil pensar em ferramentas como ChatGPT, Claude chat, ou Cursor IDE como hosts MCP — elas fornecem a interface com a qual você interage. Nos bastidores, elas usam um cliente MCP para se conectar a diferentes fontes de ferramentas e dados através de servidores MCP.

referência: https://modelcontextprotocol.io/introduction

Servidor MCP: “O fornecedor de ferramentas”

Um Servidor MCP é um pequeno programa focado que expõe uma ferramenta ou capacidade específica — como:

Pesquisar arquivos no seu computador
Consultar dados em uma base de dados local
Chamar uma API externa (como tempo, finanças, calendário)

Cada servidor segue o protocolo MCP, de modo que a IA pode entender o que ele pode fazer e como chamá-lo.

Fontes de dados locais: “Os seus próprios arquivos e serviços”

Alguns Servidores MCP conectam-se a coisas na sua própria máquina — como:

Documentos e pastas
Projetos de código
Bases de dados ou aplicações locais

Isso permite que a IA pesquise, recupere, ou calcule coisas sem carregar os seus dados para a nuvem.

Serviços remotos: “APIs e ferramentas online”

Outros Servidores MCP estão conectados à internet — eles conversam com:

APIs (e.g. Stripe, Notion, GitHub)
Ferramentas SaaS
Bases de dados de empresas na nuvem

Assim, a IA pode dizer, por exemplo: “Chame o servidor GitHub e busque a lista de PRs abertos.”

Agora o MCP suporta conexão com servidores MCP remotos. Isso significa que um cliente MCP pode obter capacidades mais poderosas. Em teoria,

Com o conjunto certo de servidores MCP, os utilizadores podem transformar cada cliente MCP em uma “aplicação para tudo”.

referência: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

Colocando tudo junto

Agora vamos usar um diagrama para ver como tudo funciona junto.

Você pede algo complexo à IA
A IA (o host) pede ajuda ao cliente
O cliente chama o servidor MCP correto — talvez um que verifique arquivos ou acesse uma API
O servidor envia de volta dados ou executa uma função
O resultado flui de volta para o modelo para ajudá-lo a completar a tarefa

A2A vs MCP — Comparação

Categoria	A2A (Agente-para-Agente)	MCP (Protocolo de Contexto de Modelo)
Objetivo Primário	Habilitar a troca de tarefas entre agentes	Permitir que MLLs acessem ferramentas externas ou contexto
Desenhado Para	Comunicação entre agentes autónomos	Melhorar capacidades de agentes durante a inferência
Foco	Fluxos de trabalho multi-agentes, coordenação, delegação	Uso dinâmico de ferramentas, aumento de contexto
Modelo de execução	Agentes enviam/recebem tarefas e artefactos	MLL seleciona e executa ferramentas durante o raciocínio
Segurança	OAuth 2.0, chaves de API, escopos declarativos	Tratado na camada de integração da aplicação
Papel do Desenvolvedor	Construir agentes que expõem tarefas e artefactos via endpoints	Definir ferramentas estruturadas e contexto que o modelo pode usar
Parceiros no Ecossistema	Google, Salesforce, SAP, LangChain, etc.	Anthropic, com adoção emergente em UIs de MLL baseadas em ferramentas

Como eles trabalham juntos

Em vez de serem alternativas, A2A e MCP são complementares. Em muitos sistemas, ambos serão usados juntos.

Exemplo de fluxo de trabalho

Um utilizador submete uma solicitação complexa em uma interface de agente empresarial.
O agente coordenador usa A2A para delegar subtarefas a agentes especializados (e.g., análise, RH, finanças).
Um desses agentes usa MCP internamente para invocar uma função de busca, buscar um documento, ou calcular algo usando um modelo.
O resultado é retornado como um artefacto via A2A, permitindo colaboração de agentes de ponta a ponta com acesso modular a ferramentas.

Esta arquitetura separa a comunicação entre-agentes (A2A) da invocação de capacidade intra-agente (MCP) — tornando o sistema mais fácil de compor, escalar, e proteger.

Conclusão

O A2A trata de agentes conversando com outros agentes através de uma rede — de forma segura, assíncrona, e centrada em tarefas.

O MCP é sobre injetar capacidades estruturadas em uma sessão de modelo, permitindo que MLLs raciocinem sobre ferramentas e dados contextualmente.

Usados juntos, eles suportam sistemas multi-agentes compostáveis que são extensíveis e interoperáveis.

Como a infraestrutura base MCP + A2A poderia moldar o futuro dos marketplaces de produtos agentivos

Por fim, quero falar sobre como essa base técnica poderia moldar o futuro do marketplace de IA — e o que isso significa para pessoas que constroem produtos de IA.

A mudança na interação humano-computador

Um exemplo claro desta mudança pode ser visto em fluxos de trabalho de desenvolvedores e serviços. Com servidores MCP agora integrados em IDEs e agentes de codificação, a forma como os desenvolvedores interagem com ferramentas está a mudar fundamentalmente.

Antigamente, um fluxo de trabalho típico envolvia procurar o serviço correto, configurar hospedagem, ler documentação, integrar APIs manualmente, codificar no IDE, e configurar recursos através de um painel de código baixo. Era uma experiência fragmentada, exigindo mudança de contexto e sobrecarga técnica em cada etapa.

Agora, com agentes de codificação conectados ao MCP, muita dessa complexidade pode ser abstraída. Os desenvolvedores podem descobrir e usar ferramentas de forma mais natural através de prompts de conversação. A integração de APIs está a tornar-se parte do fluxo de codificação — muitas vezes sem necessidade de uma UI separada ou configuração manual. (Basta pensar em como os painéis da AWS ou da Microsoft podem ser complexos.). A interação torna-se mais suave — mais sobre guiar comportamentos do que montar recursos.

Neste modelo, a interação do utilizador ou desenvolvedor muda de configurar recursos para orquestrar comportamentos. Isso muda também o papel do design de produto.

Em vez de usar UIs para “tampar” desafios técnicos (e.g. “isso é muito difícil de codificar, vamos fazer um painel de configuração”), agora precisamos de:

Pensar sobre a experiência de ponta a ponta
Projetar como e quando interações IA + utilizador devem se unir
Deixar que a IA lide com a lógica, e guiar os utilizadores através de intenção e fluxo

O desafio torna-se decidir quando e como a IA e a entrada do utilizador devem unir-se, deixar que a IA lide com a lógica, e guiar os utilizadores através de intenção e fluxo e como inserir as interações certas no momento certo.

Usei um serviço de desenvolvimento e produto de API como exemplo para mostrar como a interação do utilizador poderia mudar — mas o mesmo se aplica ao software empresarial. Por muito tempo, as ferramentas empresariais foram complexas e difíceis de usar. A interação em linguagem natural tem o potencial de simplificar muitos desses fluxos de trabalho.

Paradigmas de produtos agentivos e seu impacto no SaaS

Estamos a começar a ver um número crescente de servidores MCP surgir. Imagine o Airbnb oferecendo um servidor MCP de reservas, ou o Google Maps expondo um servidor MCP de mapas. Um agente (como cliente MCP) poderia conectar-se a muitos destes servidores ao mesmo tempo — desbloqueando fluxos de trabalho que antes exigiam integrações personalizadas ou aplicações rigidamente vinculadas.

Comparado à era SaaS, onde as integrações eram frequentemente manuais e rígidas, este modelo permite fluxos de trabalho mais autónomos e conexões fluidas entre serviços. Aqui estão dois exemplos:

Projeto a partir de documentos

Você escreve um PRD no Notion. Um agente Figma lê o documento e cria automaticamente um wireframe que define os conceitos principais — sem necessidade de entrega manual.
Pesquisa de concorrentes, de ponta a ponta

Você pede uma análise de concorrentes. Um grupo de agentes pesquisa na web, inscreve-se em serviços relevantes em seu nome (com autenticação segura), coleta os resultados, e entrega os artefactos de volta — já organizados no seu espaço de trabalho do Notion.

Desafios com limites de autenticação e autorização

Com o aumento das conexões de agente para agente, cliente MCP para servidor MCP, há muitas necessidades subjacentes sobre autenticação e autorização porque o agente atuará em nome de humanos e utilizadores e as credenciais devem ser seguras ao longo desta jornada.

Até agora, há vários cenários específicos para o novo aumento de agente para agente e MCP.

Agente vs SaaS & Application de Website
Cliente MCP (Agente) vs Servidor MCP
Utilizador vs Agente
Agente vs Agente

Outro caso de uso interessante é a federação de múltiplas identidades Google mencionou:

Por exemplo, o Utilizador U está a trabalhar com o Agente A exigindo o identificador do sistema A. Se o Agente A então depender da Ferramenta B ou do Agente B que requer o identificador do sistema B, o utilizador pode precisar fornecer identidades para ambos A-sistema e B-sistema em uma única solicitação. (Assuma que o sistema A é uma identidade LDAP empresarial e o sistema B é uma identidade de fornecedor SaaS).

Logto é um provedor OIDC e OAuth, bem adequado para o futuro das integrações de IA.

Com a sua infraestrutura flexível, estamos a expandir ativamente as suas capacidades e publicámos uma série de tutoriais para ajudar os desenvolvedores a começar rapidamente.

Tem perguntas?

Entre em contato conosco — ou mergulhe e explore o que você pode construir com o Logto hoje.

Experimente o Logto Cloud gratuitamente

O que é o A2A (Agente-para-Agente)?#

Mecanismo do protocolo A2A#

Modelos de comunicação A2A#

Gestão de Tarefas#

Colaboração e negociação de conteúdo#

Exemplo de caso de uso#

O que é MCP (Protocolo de Contexto de Modelo)?#

Arquitetura chave do MCP#

Host MCP: “A IA com quem você está a falar”#

Cliente MCP: “O conector”#

Servidor MCP: “O fornecedor de ferramentas”#

Fontes de dados locais: “Os seus próprios arquivos e serviços”#

Serviços remotos: “APIs e ferramentas online”#

Colocando tudo junto#

A2A vs MCP — Comparação#

Como eles trabalham juntos#

Exemplo de fluxo de trabalho#

Conclusão#

Como a infraestrutura base MCP + A2A poderia moldar o futuro dos marketplaces de produtos agentivos#

A mudança na interação humano-computador#

Paradigmas de produtos agentivos e seu impacto no SaaS#

Desafios com limites de autenticação e autorização#