Atualmente, estamos vendo a “pilha de protocolos da rede” da inteligência artificial descentralizada (deAI) sendo gradualmente construída. Assim como a internet opera em uma série de padrões interoperáveis - a camada de transporte usa TCP/IP, a camada de descoberta de serviços usa DNS, e a lógica de aplicação usa HTTP - também podemos decompor a pilha de protocolos de deAI em esses três módulos: a camada de aplicação usa x402, a camada de descoberta de serviços usa ERC 8004, e a camada de transporte usa A2A - todos funcionando sobre a pilha de protocolos HTTP tradicional.
Em suma, a pilha de protocolos de deAI define como os agentes pagam taxas, descobrem recursos e se comunicam entre si. Agora, vamos analisar cada parte uma a uma:
Camada de aplicação - x402
O topo da pilha de protocolos de Inteligência Artificial Descentralizada (deAI) é o x402, que representa o protocolo de camada de aplicação para pagamentos entre agentes por vários serviços (como armazenamento de arquivos, e-commerce, captura de páginas da web, etc.). O x402 foi construído pela Coinbase e pela Cloudflare, e expande fundamentalmente o código de estado original “HTTP 402: Pagamento Necessário”, tornando-o parte do fluxo de trabalho, permitindo que os agentes paguem as taxas de serviço com stablecoins.
Eu já escrevi detalhadamente sobre o x402 antes, com o título “A Modernização do HTTP 402”, que abrange sua visão, arquitetura, oportunidades e desafios.
Fundamentalmente, o x402 opera através de um acordo tripartido, que consiste em três partes: o cliente solicita recursos → o servidor retorna o código de status 402 → o coordenador de pagamento (facilitator) verifica a autorização de pagamento do cliente e efetua a transferência de fundos (por exemplo, submetendo uma transação assinada na blockchain). Após a conclusão destes passos, o servidor desbloqueará o conteúdo premium.
Hoje, o x402scan pode ser um dos melhores recursos para observar o desempenho do servidor x402 em operação real. Embora a longo prazo, o x402 beneficie muito os micropagamentos de conteúdo de qualidade (como rastreamento de páginas, artigos pagos, recursos computacionais), sua ascensão recente (que pode ser claramente vista através do x402scan) deve-se em grande parte a uma série de moedas meme, como… $PING - essas moedas exigem pagamento através do x402 para serem cunhadas ao longo da curva de dívida.
Apesar disso, o x402 continua a ser um bom exemplo de um padrão de camada de aplicação no emergente stack de protocolos de inteligência artificial descentralizada (deAI). Assim como a “camada de aplicação” no stack de protocolos de rede tradicional contém vários protocolos (HTTP, FTP, SMTP, VoIP, etc.), também podemos esperar que mais padrões de camada de aplicação surjam no futuro.
Camada de Descoberta - ERC 8004
Ao usar o x402, uma pergunta comum que surge é: como as pessoas descobrem quais serviços estão disponíveis? É aqui que o ERC 8004, desenvolvido sob a liderança da Ethereum Foundation, desempenha um papel na “camada de descoberta”.
Assim como o DNS mapeia nomes de domínio para endereços IP (google.com → 8.8.8.8), o ERC 8004 resolve o problema da descoberta de agentes de IA criando um registro em cadeia que mapeia ID de agente para vários links e funcionalidades do agente. O ERC 8004 utiliza “cartão de agente” como identificação do agente e oferece funcionalidades adicionais como pontuação de reputação e verificação.
ERC 8004 utiliza ERC721 (NFT) e URIStorage na camada base. Ele contém parâmetros como Nome, A2A, MCP, OASF, ENS, DID e tipos de confiança suportados (como reputação, economia criptográfica, prova TEE). Todos esses diferentes parâmetros apontam para vários padrões de ID de agente, proporcionando uma visão mais abrangente das funcionalidades do agente.
Eu acredito que o ERC 8004, como a trajetória de desenvolvimento da camada de descoberta de deAI, será semelhante ao DNS na pilha de protocolos da Internet – haverá um protocolo geral que todos irão consultar, mas redirecionará os usuários para vários nós pares (aqui referindo-se a diferentes links de cartões de proxy) para obter informações mais específicas sobre qualquer consulta dada.
Camada de Transporte - Protocolo A2A
Até aqui, já apresentamos a camada de aplicação e a camada de descoberta. A última etapa da pilha de protocolos é a camada de transporte - ela é responsável por lidar com a maneira como os aplicativos se comunicam entre si após completar a descoberta através de protocolos como o ERC 8004. Para a pilha de protocolos da internet convencional, o protocolo TCP/IP é responsável por transferir pacotes de dados da rede do cliente para o servidor. No entanto, para a pilha de protocolos de inteligência artificial descentralizada (deAI), o Google lançou recentemente o protocolo A2A, que é especificamente projetado para permitir a comunicação entre agentes.
A comunicação entre o cliente proxy (cliente A2A) e o servidor proxy (servidor A2A) é feita através de HTTPS utilizando JSON-RPC 2.0. Essencialmente, os dois proxies “dialogam” acessando seus respectivos endpoints HTTP e solicitando cálculos ou várias funcionalidades. A A2A também estabelece que cada proxy possui um cartão proxy, utilizado para publicar suas funcionalidades, estrutura, anexos MCP, entre outras informações.
No protocolo A2A, após a confirmação mútua entre o cliente e o proxy remoto, o cliente visualizará o cartão do proxy para obter o endpoint HTTP e solicitará o serviço correspondente. O proxy remoto utilizará suas ferramentas MCP e recursos computacionais, entre outros, e durante o processamento da tarefa enviará atualizações assíncronas (semelhante ao “processo de pensamento” em um modelo de inferência). Por fim, enviará a resposta final e os artefatos.
Eu recomendo aqui um excelente artigo introdutório que é o da IBM “What is A2A protocol (Agent2Agent)?”.
Juntando todos os fatores…
Considerando fatores como x402, 8004 e A2A, podemos nos referir ao exemplo de demonstração fornecido pela Coinbase - comprar um novo frigorífico na Lowe's. Suponha que o usuário converse com o chatbot, perguntando como comprar um frigorífico na Lowe's:
Vamos usar o ERC 8004 (camada de descoberta) para encontrar o agente de vendas de refrigeradores da Lowe's e solicitar que ele liste as funções do agente.
Iremos usar A2A (camada de transporte) para comunicar com o agente da Lowe's através do ponto de extremidade HTTP.
Usaremos o x402 (camada de aplicação) para processar a autorização de pagamento e transferir stablecoins na blockchain.
Claro, tudo isso acontecerá sobre a pilha de protocolos de rede tradicional HTTP-DNS-TCP/IP!
Em suma, esta pilha constitui a espinha dorsal do protocolo da Internet Agentic (, permitindo que os agentes não apenas transmitam dados, mas também realizem transações, verifiquem e coordenem com recursos na cadeia.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Desconstrução da pilha de protocolos DeAI - X402 / ERC 8004 / A2A
null Autor do artigo: Jay Yu
Artigo traduzido: Block unicorn
Introdução
Atualmente, estamos vendo a “pilha de protocolos da rede” da inteligência artificial descentralizada (deAI) sendo gradualmente construída. Assim como a internet opera em uma série de padrões interoperáveis - a camada de transporte usa TCP/IP, a camada de descoberta de serviços usa DNS, e a lógica de aplicação usa HTTP - também podemos decompor a pilha de protocolos de deAI em esses três módulos: a camada de aplicação usa x402, a camada de descoberta de serviços usa ERC 8004, e a camada de transporte usa A2A - todos funcionando sobre a pilha de protocolos HTTP tradicional.
Em suma, a pilha de protocolos de deAI define como os agentes pagam taxas, descobrem recursos e se comunicam entre si. Agora, vamos analisar cada parte uma a uma:
O topo da pilha de protocolos de Inteligência Artificial Descentralizada (deAI) é o x402, que representa o protocolo de camada de aplicação para pagamentos entre agentes por vários serviços (como armazenamento de arquivos, e-commerce, captura de páginas da web, etc.). O x402 foi construído pela Coinbase e pela Cloudflare, e expande fundamentalmente o código de estado original “HTTP 402: Pagamento Necessário”, tornando-o parte do fluxo de trabalho, permitindo que os agentes paguem as taxas de serviço com stablecoins.
Eu já escrevi detalhadamente sobre o x402 antes, com o título “A Modernização do HTTP 402”, que abrange sua visão, arquitetura, oportunidades e desafios.
Fundamentalmente, o x402 opera através de um acordo tripartido, que consiste em três partes: o cliente solicita recursos → o servidor retorna o código de status 402 → o coordenador de pagamento (facilitator) verifica a autorização de pagamento do cliente e efetua a transferência de fundos (por exemplo, submetendo uma transação assinada na blockchain). Após a conclusão destes passos, o servidor desbloqueará o conteúdo premium.
Hoje, o x402scan pode ser um dos melhores recursos para observar o desempenho do servidor x402 em operação real. Embora a longo prazo, o x402 beneficie muito os micropagamentos de conteúdo de qualidade (como rastreamento de páginas, artigos pagos, recursos computacionais), sua ascensão recente (que pode ser claramente vista através do x402scan) deve-se em grande parte a uma série de moedas meme, como… $PING - essas moedas exigem pagamento através do x402 para serem cunhadas ao longo da curva de dívida.
Apesar disso, o x402 continua a ser um bom exemplo de um padrão de camada de aplicação no emergente stack de protocolos de inteligência artificial descentralizada (deAI). Assim como a “camada de aplicação” no stack de protocolos de rede tradicional contém vários protocolos (HTTP, FTP, SMTP, VoIP, etc.), também podemos esperar que mais padrões de camada de aplicação surjam no futuro.
Ao usar o x402, uma pergunta comum que surge é: como as pessoas descobrem quais serviços estão disponíveis? É aqui que o ERC 8004, desenvolvido sob a liderança da Ethereum Foundation, desempenha um papel na “camada de descoberta”.
Assim como o DNS mapeia nomes de domínio para endereços IP (google.com → 8.8.8.8), o ERC 8004 resolve o problema da descoberta de agentes de IA criando um registro em cadeia que mapeia ID de agente para vários links e funcionalidades do agente. O ERC 8004 utiliza “cartão de agente” como identificação do agente e oferece funcionalidades adicionais como pontuação de reputação e verificação.
ERC 8004 utiliza ERC721 (NFT) e URIStorage na camada base. Ele contém parâmetros como Nome, A2A, MCP, OASF, ENS, DID e tipos de confiança suportados (como reputação, economia criptográfica, prova TEE). Todos esses diferentes parâmetros apontam para vários padrões de ID de agente, proporcionando uma visão mais abrangente das funcionalidades do agente.
Eu acredito que o ERC 8004, como a trajetória de desenvolvimento da camada de descoberta de deAI, será semelhante ao DNS na pilha de protocolos da Internet – haverá um protocolo geral que todos irão consultar, mas redirecionará os usuários para vários nós pares (aqui referindo-se a diferentes links de cartões de proxy) para obter informações mais específicas sobre qualquer consulta dada.
Até aqui, já apresentamos a camada de aplicação e a camada de descoberta. A última etapa da pilha de protocolos é a camada de transporte - ela é responsável por lidar com a maneira como os aplicativos se comunicam entre si após completar a descoberta através de protocolos como o ERC 8004. Para a pilha de protocolos da internet convencional, o protocolo TCP/IP é responsável por transferir pacotes de dados da rede do cliente para o servidor. No entanto, para a pilha de protocolos de inteligência artificial descentralizada (deAI), o Google lançou recentemente o protocolo A2A, que é especificamente projetado para permitir a comunicação entre agentes.
A comunicação entre o cliente proxy (cliente A2A) e o servidor proxy (servidor A2A) é feita através de HTTPS utilizando JSON-RPC 2.0. Essencialmente, os dois proxies “dialogam” acessando seus respectivos endpoints HTTP e solicitando cálculos ou várias funcionalidades. A A2A também estabelece que cada proxy possui um cartão proxy, utilizado para publicar suas funcionalidades, estrutura, anexos MCP, entre outras informações.
No protocolo A2A, após a confirmação mútua entre o cliente e o proxy remoto, o cliente visualizará o cartão do proxy para obter o endpoint HTTP e solicitará o serviço correspondente. O proxy remoto utilizará suas ferramentas MCP e recursos computacionais, entre outros, e durante o processamento da tarefa enviará atualizações assíncronas (semelhante ao “processo de pensamento” em um modelo de inferência). Por fim, enviará a resposta final e os artefatos.
Eu recomendo aqui um excelente artigo introdutório que é o da IBM “What is A2A protocol (Agent2Agent)?”.
Juntando todos os fatores…
Considerando fatores como x402, 8004 e A2A, podemos nos referir ao exemplo de demonstração fornecido pela Coinbase - comprar um novo frigorífico na Lowe's. Suponha que o usuário converse com o chatbot, perguntando como comprar um frigorífico na Lowe's:
Vamos usar o ERC 8004 (camada de descoberta) para encontrar o agente de vendas de refrigeradores da Lowe's e solicitar que ele liste as funções do agente.
Iremos usar A2A (camada de transporte) para comunicar com o agente da Lowe's através do ponto de extremidade HTTP.
Usaremos o x402 (camada de aplicação) para processar a autorização de pagamento e transferir stablecoins na blockchain.
Claro, tudo isso acontecerá sobre a pilha de protocolos de rede tradicional HTTP-DNS-TCP/IP!
Em suma, esta pilha constitui a espinha dorsal do protocolo da Internet Agentic (, permitindo que os agentes não apenas transmitam dados, mas também realizem transações, verifiquem e coordenem com recursos na cadeia.