2026-08-01T10:18:29.386Z
Protocolos de Agentes AI: Escolha-se com base nas provas que apresentam
Comparar MCP, A2A, ACP, UCP e AP2 pelo seu limite operacional, evidência do ciclo de vida, recibos de efeitos e prova de resultado que cada um ainda deixa faltando.
Escolha os protocolos de agente AI pelo limite que eles padronizam, não pelo qual o acrônimo aparece com mais frequência. Usar MCP quando um host precisar de ferramentas ou contexto. Use A2A quando um agente opaco delega uma tarefa com estado a outro. Tratar os ACP como uma entrada migratória, porque o projecto ACP agora diz que faz parte do A2A. Adicionar protocolos mais restritos apenas para obrigações mais restritos, como a autorização de pagamento ou de caixa. Depois, adicione um verificador de resultados acima de cada protocolo: um aperto de mão bem sucedido, resultado de ferramenta, tarefa terminal ou recibo de pagamento são evidências, mas nenhuma prova necessariamente que o trabalho pretendido do usuário é correto. Essa regra evita dois erros caros. O primeiro é pedir um protocolo para resolver a descoberta, execução, monitoramento, autorização e verificação de negócios. O segundo é a empilhamento de protocolos que atravessam a mesma fronteira, criando mais adaptadores sem criar mais evidências. Comece com o limite, depois inspecione os recibos. Os protocolos atuais são mais fáceis de raciocinar como camadas. MCP atravessa o limite de hospedeiro a ferramenta. O Especificação do MCP datada de 2025 11 25 define hospedeiros, clientes e servidores; negociação de capacidade; recursos, instruções e ferramentas; além de utilitários para progresso, cancelamento, erros e registro. Isso é um forte ajuste quando um agente hospedeiro precisa descobrir uma ferramenta de banco de dados, ler um recurso ou invocar uma função externa através de um contrato comum. O MCP não torna o servidor um agente remoto com um ciclo de vida das tarefas portátil e duradouro. Um pedido JSON RPC pode ser correlacionado e uma ferramenta pode devolver conteúdo estruturado, mas um aplicativo ainda tem que preservar a identidade operacional que importa para a empresa. Se uma ferramenta de correio eletrônico estiver desligada, um erro de transporte não lhe diz se o destino aceitou a mensagem. A repetição do resultado do protocolo pode duplicar o efeito. A2A atravessa o limite de agente a agente. O Especificação A2A 1.0 atual define Cartões de Agente para descoberta de capacidade, tarefas com IDs e estado estáveis, Mensagens, Artefatos, atualizações de streaming, notificações push, recuperação e cancelamento. Apoia explicitamente o trabalho humano de longa duração entre agentes que podem manter a memória interna e as ferramentas opacas. Esse ciclo de vida extra é uma evidência significativa de saúde. Um cliente pode distinguir uma tarefa que ainda está trabalhando de uma que está esperando entrada, concluída, falhada, cancelada ou rejeitada. Pode recuperar a tarefa após uma desconexão do fluxo e inspecionar artefatos em vez de tratar o fechamento da conexão como conclusão. No entanto, uma tarefa A2A COMPLETED ainda relata o que o agente remoto acredita ter acontecido. O requerente deve verificar que o artefacto satisfaz o contrato original. ACP é agora uma questão de migração. O Repositório ACP ainda documenta manifestos de agente, corridas, sessões, streaming, solicitações de espera, saídas e erros. A sua nota atual de destaque diz também: ACP faz agora parte da A2A sob a Linux Foundation. Para um serviço ACP existente, inventar a semântica em que se baseia e mapeá la para A2A. Para um limite de agente remoto de campo verde, tratar ACP e A2A como apostas concorrentes independentes ignoraria o próprio aviso de convergência do projeto. Domain protocolos adicionam recibos de domínio. guia de desenvolvedores para protocolos de agentes atual do Google separa acesso à ferramenta MCP e colaboração A2A do checkout UCP e autorização de pagamento AP2. Essa composição é defendível porque as camadas respondem a perguntas diferentes. A UCP pode estruturar uma operação comercial. AP2 pode ligar a autorização a uma intenção e produzir um recibo de pagamento. Nenhum dos dois recibos prova que a mercadoria chegou ou resolveu o problema do utilizador. O incumprimento razoável é, por conseguinte: Escolher o MCP para as ferramentas e o contexto; Selecionar A2A para tarefas de agente remoto; Migrar ACP em vez de iniciar um segundo padrão agente a agente; Adicionar um protocolo de domínio somente quando os seus recibos digitados correspondem a uma obrigação de domínio real; Nunca permita que o sucesso do protocolo substitua a verificação dos resultados. Pontuação de seis campos de evidência, não conteúdo Uma comparação de protocolo torna se operacional quando cada linha responde a seis perguntas: 1. Pode o telefonista descobrir a capacidade e o contrato atual? 2. Existe uma identidade que sobrevive a retemptamentos, reconectas e trabalhos assíncronos? 3. O telefonista consegue distinguir os estados de trabalho, espera, falha e terminal? 4. A cancelamento é representada e o seu efeito pode ser verificado? 5. Há provas de que o efeito colateral externo aconteceu exatamente como pretendido? 6. Existe prova de que o resultado prometido pelo utilizador está presente e válido? Os primeiros quatro são em forma de protocolo. Os dois últimos normalmente se cruzam em aplicação e estado de negócios. Fronteira Melhor ajuste de corrente Forte evidência nativa Prova ainda devida Anfitrião de ferramentas ou contexto MCP Negociação de capacidades, solicitações, progresso, cancelamento, erros, resultados das ferramentas Identidade de operação comercial duradoura, reconciliação de efeitos externos, resultado final Agente opaco a agente opaco A2A 1.0 Cartão de Agente, ID da tarefa, ciclo de vida, história, artefatos, streaming, cancelamento Validação semântica de artefatos e prova de resultados do utilizador Serviço de agentes ACP existente migrar em direcção a A2A Manifestação, execução, sessão, espera, saída, erro no contrato anterior Paridade de migração, testes de execução, resultado final Autorização de comércio e pagamento UCP mais AP2 O pagamento deve ser efectuado em conformidade com o disposto no n.o 1 do presente regulamento. Entrega, aceitação, utilidade e qualquer trabalho não comercial Native não significa que todas as implementações permitam ou implementam um recurso corretamente. Um cartão de agente pode ficar ultrapassado. Um servidor pode anunciar o streaming e não se conectar. Um resultado da ferramenta pode ser sintaticamente válido, mas se referir ao cliente errado. Trate a capacidade anunciada, o comportamento de transporte observado, o efeito registrado e o resultado verificado como recibos separados. Esta separação também continua a esperar para não parecer um fracasso. A A2A tem vocabulário de protocolo para trabalho de longa duração e entrada humana. O MCP dispõe de instalações de obtenção e progresso. A sua camada de saúde ainda precisa de um proprietário, um prazo, um caminho de retomada e uma regra de frescura. Uma espera válida sem um proprietário é abandonada operacionalmente mesmo que o estado do protocolo seja legal. Execução da auditoria da dívida de prova antes de escolher um adaptador O artefacto que acompanha codifica quatro cenários e os seis campos de evidência no protocol health matrix.json . A sua auditoria não concede um único vencedor. Ele seleciona o protocolo que corresponda ao limite e relata receitas parciais ou faltantes. Faça isso com: A fixação fixa retorna: Cada linha requer um verificador de resultados. Esse é o resultado importante, não um protocolo de classificação. Para a ferramenta de banco de dados, a embalagem pode gravar um ID de operação estável, conjunto de filas esperado, escopo de autorização e uma consulta de pós condição. Para a pesquisa delegada, pode validar que cada pergunta requerida tem uma resposta citada e que o artefato foi gerado após o pedido. Para uma migração ACP, deve reproduzir os casos de espera, transmissão, cancelamento e erro contra ambas as implementações antes de o tráfego se mover. Para uma compra, deve conciliar a autorização assinada e o recibo de pagamento, verificando separadamente a aceitação e a entrega do pedido. A auditoria marca deliberadamente algumas provas como parciais. O cancelamento do MCP pode parar o trabalho do protocolo sem reverter uma escrita externa. A cancelamento A2A pode produzir uma tarefa cancelada enquanto um sistema a jusante permanece ativo. A AP2 pode emitir um recibo de pagamento sem comprovar o cumprimento. Estes não são defeitos de protocolo. São fatos de fronteira que a aplicação deve tornar visíveis. Mantenha a conclusão do protocolo e a conclusão do resultado separados Modela os dois veredictos explicitamente: Este registo recusa um falso verde. O agente remoto completou a sua tarefa de protocolo e forneceu um artefato. O trabalho do utilizador não está completo porque faltam uma resposta necessária e as verificações de origem. A próxima ação mais segura é não reiniciar automaticamente toda a tarefa. É solicitar as provas limitadas faltantes, preservar a tarefa original e as identidades do artefato, e verificar o delta. Use a mesma divisão para as chamadas de ferramentas. Registo de pedido de transporte separado da reconciliação de efeitos. Se a ferramenta tiver expirado após o envio de uma escrita, consulte o destino com a chave de operação estável antes de tentar novamente. Se o protocolo não puder expor uma chave duradoura, crie uma no limite da aplicação. A conclusão do comando é atividade; um estado de destino verificado é prova. A frescura pertence a ambos os veredictos. Uma capacidade descoberta ontem pode ter desaparecido hoje. Uma tarefa concluída pode apontar para um artefato que foi substituído mais tarde. Um recibo de pagamento pode ser válido enquanto a entrega estiver atrasada. Armazenar a fonte, o tempo de observação, o intervalo de atualização esperado e a confiança para cada sinal decisivo. Uma regra de seleção compacta Use esta ordem durante a revisão de arquitetura: 1. Nomeie a fronteira em uma frase. 2. Lista dos estados de falha que o operador deve distinguir. 3. Selecione o protocolo de corrente mais estreito que expõe esses estados. 4. Marque todos os recibos necessários como nativos, parciais ou desaparecidos. 5. Adicionar provas de aplicação apenas para os campos parciais e faltantes. 6. Test reconnectar, esperar, cancelar, entrega dupla, descoberta obsoleta e casos falsos. 7. Limpar o trabalho só depois que o resultado prometido passar o seu próprio contrato. Não compor MCP e A2A simplesmente porque ambos são populares. Compõe as quando um agente A2A remoto precisa de ferramentas MCP: A2A possui o estado de delegação e tarefa, enquanto o MCP possui o limite de ferramentas desse agente. Mantenha os documentos ligados, mas distintos. Não adicionar UCP ou AP2 a menos que o fluxo de trabalho contenha obrigações de pagamento ou de pagamento. A matriz é uma auditoria de nível de especificação, não prova de que um determinado SDK ou servidor interopera corretamente. Os recursos opcionais, extensões, autenticação, autorização, comportamento de reconexão e retenção de telemetria precisam de testes de implementação. Os protocolos também evoluem; fixa a versão das especificações utilizada por cada adaptador e repita a auditoria antes da atualização. A Sidewisp está atualmente em prévia privada. A sua direcção pretendida é tornar mais clara a saúde dos agentes, a evidência, os estados de espera e a verificação segura nos tempos de execução existentes; os adaptadores de monitorização da produção e os sistemas de recuperação não são geralmente enviados. O princípio útil hoje é independente de qualquer produto: escolher o protocolo para a fronteira, reter os recibos que pode fornecer, e tornar impossível ignorar a prova de resultado faltante.