Voltar ao blog

SDKs de agentes atingem 1.0 com suporte nativo a MCP e A2A: o que muda na construção de sistemas multi-agente

AI Engineering Agent Development MCP A2A Multi-Agent Systems Google ADK Microsoft Agent Framework

Em abril de 2026, dois SDKs de construção de agentes atingiram a versão 1.0 com suporte nativo aos mesmos protocolos abertos. O Google lançou o ADK para Java 1.0.0 com integração direta ao Agent2Agent (A2A) e ao Model Context Protocol (MCP). A Microsoft publicou o Agent Framework 1.0 para .NET e Python, unificando Semantic Kernel e AutoGen num único SDK com suporte a MCP e A2A. Os dois lançamentos aconteceram com menos de três semanas de diferença.

Essa coincidência não é acidental — e o que ela revela sobre a estabilização da infraestrutura de agentes é mais relevante do que qualquer um dos lançamentos individualmente.

Protocolos abertos como interface comum

MCP e A2A migraram para a Agentic AI Foundation (AAIF) sob a Linux Foundation em dezembro de 2025, com Anthropic, Google, OpenAI, Microsoft, AWS e Block como cofundadores. Em quatro meses, a fundação acumulou mais de 170 membros. O MCP ultrapassou 97 milhões de downloads mensais combinados dos SDKs Python e TypeScript. O A2A absorveu o Agent Communication Protocol (ACP) da IBM em agosto de 2025 e se consolidou como protocolo de comunicação entre agentes de frameworks diferentes.

Os dois protocolos resolvem camadas distintas do problema. O MCP padroniza como um agente acessa ferramentas, fontes de dados e serviços externos — é o adaptador universal entre agente e mundo exterior. O A2A padroniza como agentes se comunicam entre si, mesmo quando construídos em linguagens, frameworks ou runtimes diferentes. Com governança neutra e adoção ampla, os protocolos viraram a interface comum que os SDKs agora implementam como funcionalidade nativa, não como extensão opcional.

ADK para Java 1.0: protocolo como abstração de composição

O ADK para Java ilustra bem o que significa internalizar um protocolo no nível do SDK. Um agente remoto exposto via A2A é encapsulado num RemoteA2AAgent que resolve o AgentCard do endpoint, constrói o cliente e se insere na hierarquia de agentes local. Para o Runner que orquestra a execução, esse agente remoto se comporta exatamente como um agente local — transmite eventos no mesmo fluxo, responde às mesmas chamadas. A abstração não esconde que o agente é remoto; ela padroniza a interface de comunicação para que a orquestração não precise distinguir entre local e remoto.

O módulo google-adk-a2a implementa conversores bidirecionais entre o sistema de tipos do ADK e o do A2A, incluindo streaming e agregação parcial de eventos. Na prática, isso significa que um agente Java pode delegar uma subtarefa a um agente Python ou TypeScript rodando em outro servidor, desde que ambos exponham um endpoint A2A com um AgentCard que descreva suas capacidades.

O ADK Java 1.0 também introduz uma arquitetura de plugins com duas novas APIs: a classe App, que funciona como contêiner da aplicação agentic (hospeda o agente raiz, mantém configurações globais e gerencia plugins), e a classe base Plugin para extensões. Três plugins vêm incluídos: LoggingPlugin para logging estruturado de execuções e chamadas de ferramenta, ContextFilterPlugin para gerenciar a janela de contexto filtrando turnos antigos, e GlobalInstructionPlugin para aplicar instruções consistentes a todos os agentes da hierarquia.

O ADK não é exclusivo do Java. O framework está disponível em Python, Java, Go e TypeScript, com o ADK Go também tendo atingido 1.0 com suporte a A2A.

Microsoft Agent Framework 1.0: unificação e descoberta dinâmica

Do lado da Microsoft, o Agent Framework 1.0 resolve um problema organizacional antes de resolver um problema técnico. Semantic Kernel era o SDK de integração empresarial — kernel, modelo de plugins, conectores, telemetria, middleware. AutoGen era o framework de orquestração multi-agente com abstrações simples de conversação e padrões de coordenação entre agentes. Dois projetos open-source da mesma empresa, com sobreposição crescente e sem ponto claro de convergência.

A versão 1.0 funde os dois. Semantic Kernel vira a camada de fundação — seu kernel, modelo de plugins e sistema de conectores sobrevivem intactos. Os conceitos de orquestração do AutoGen são reconstruídos sobre essa fundação como motor de workflows baseados em grafos, permitindo orquestração explícita de múltiplos agentes com controle de fluxo definido em código.

O suporte a MCP permite que agentes descubram ferramentas dinamicamente. Quando um servidor MCP é configurado para um agente, o framework consulta o servidor na inicialização, popula a lista de ferramentas automaticamente sem definições manuais, e roteia chamadas para o servidor MCP apropriado durante a execução. A lista de ferramentas disponíveis passa a ser uma propriedade do runtime em vez de uma constante do código.

O suporte a A2A (anunciado como “A2A 1.0 coming soon” na versão GA) segue a mesma lógica: agentes em frameworks diferentes se comunicam via mensagens estruturadas baseadas no protocolo, sem precisar compartilhar código ou dependências.

Capacidades convergentes: do desenvolvedor para o framework

Os dois SDKs convergem em capacidades que seguem o mesmo padrão: responsabilidades que antes ficavam inteiramente com o desenvolvedor migram para o framework como primitivas configuráveis.

Gestão de ciclo de vida do contexto

O ADK Java introduz compactação de eventos: uma janela deslizante retém os eventos mais recentes enquanto um sumarizador condensa os anteriores. A API expõe controles para intervalo de compactação, limiar de tokens, tamanho de sobreposição, limite de retenção de eventos e escolha do sumarizador. As interfaces BaseEventSummarizer e EventCompactor permitem customização completa da estratégia.

O Agent Framework da Microsoft traz gestão de estado baseada em sessão, com middleware e persistência entre turnos. A abordagem é diferente na implementação — sessão persistida vs. compactação in-flight — mas o efeito é o mesmo: o SDK assume responsabilidade por manter o contexto operável à medida que a conversa cresce, em vez de deixar cada aplicação implementar sua própria estratégia.

Controle humano integrado ao fluxo de execução

O ADK Java implementa ToolConfirmation: uma ferramenta registrada acessa seu ToolContext e chama requestConfirmation(), o que intercepta automaticamente o fluxo do modelo e pausa a execução até receber aprovação externa. Depois da confirmação, o framework limpa eventos intermediários e injeta a chamada de ferramenta aprovada explicitamente no contexto da próxima requisição ao modelo, garantindo que o modelo entenda que a ação foi aprovada sem entrar em loop.

O Agent Framework da Microsoft implementa padrão análogo via middleware de confirmação na pipeline de execução. A pausa para aprovação humana deixou de ser lógica ad hoc implementada por cada aplicação e virou primitiva do SDK — um sinal de que human-in-the-loop é considerado requisito de produção, não funcionalidade opcional.

Instrumentação do runtime

O Agent Framework 1.0 inclui DevUI, um depurador local no navegador que visualiza fluxo de mensagens, chamadas de ferramenta e decisões de orquestração em tempo real. O ADK Java oferece o LoggingPlugin como plugin nativo, registrando execuções de agentes e chamadas de ferramentas de forma estruturada. Em ambos, observabilidade vem embutida no SDK em vez de ser adicionada como camada posterior — o que reduz a distância entre desenvolvimento e diagnóstico em produção.

Trade-offs que só aparecem em produção

A consolidação de responsabilidades no SDK não elimina complexidade; ela a redistribui.

Compactação de contexto com sumarização introduz perda de informação que precisa ser calibrada por domínio. Um sumarizador genérico pode descartar detalhes que são irrelevantes para conversação casual mas críticos para um agente que rastreia estado de uma pipeline de dados. A escolha do limiar de tokens, da estratégia de sobreposição e do modelo usado para sumarizar afeta diretamente o comportamento do agente em conversas longas — e o efeito só é observável em sessões reais, não em testes unitários.

A interoperabilidade A2A depende de que os AgentCards dos agentes remotos descrevam capacidades com precisão suficiente para roteamento automático. Se o card de um agente diz que ele “processa documentos” sem especificar formatos, limites de tamanho ou latência esperada, a orquestração pode rotear requisições para um agente inadequado. A qualidade da descrição no AgentCard funciona como contrato de serviço — e contratos vagos geram falhas silenciosas.

A descoberta dinâmica de ferramentas via MCP transfere para o runtime uma decisão que antes era estática e revisável em código. Quando a lista de ferramentas é populada automaticamente a partir de um servidor MCP, o conjunto de ações disponíveis para o agente pode mudar entre uma execução e outra. Isso é poderoso para cenários onde ferramentas são adicionadas ou removidas frequentemente, mas introduz uma superfície de variabilidade que precisa ser monitorada — especialmente em ambientes onde auditoria de capacidades é requisito.

A superfície que se estabiliza

O fato de Google e Microsoft terem convergido para a mesma combinação de protocolos, com abstrações estruturalmente similares, na mesma janela de tempo, indica que a camada de SDK para agentes está se estabilizando ao redor de um contrato técnico compartilhado. MCP para acesso a ferramentas, A2A para comunicação entre agentes, gestão de ciclo de vida e confirmação humana como primitivas — essa é a superfície que os SDKs 1.0 definem. A engenharia de sistemas multi-agente passa a operar sobre essa superfície em vez de reconstruí-la a cada projeto.

Referências