Porque é que os agentes de IA precisam de uma identidade on-chain? Compreender o ERC-8004, o MCP e o A2A

A identidade onchain para agentes de IA refere-se à utilização de registos de blockchain consultáveis para estabelecer identificadores digitais que permitem reconhecer, associar e gerir agentes de inteligência artificial entre aplicações. À medida que os agentes de IA evoluem de simples assistentes conversacionais para sistemas autónomos capazes de chamar ferramentas, aceder a dados, executar tarefas e participar em atividades económicas, a identidade dos agentes está a tornar-se uma infraestrutura essencial para redes de colaboração abertas. O ERC-8004 é uma norma Ethereum proposta para responder a esta necessidade, procurando estabelecer interfaces comuns para informações de identidade, reputação e validação dos agentes através de registos onchain.

Nos sistemas de software tradicionais, as identidades dos serviços baseiam-se normalmente em contas de plataforma, chaves API e gestão interna de permissões empresariais. Estas abordagens podem satisfazer a maioria das necessidades dos agentes que operam na mesma organização ou plataforma. No entanto, quando vários agentes de IA provêm de diferentes programadores, funcionam em infraestruturas distintas e precisam de delegar tarefas entre si, a descoberta de serviços, a confirmação de relações de controlo, a avaliação do desempenho histórico e a validação dos resultados de execução tornam-se novos desafios técnicos.

O ERC-8004, o MCP (Model Context Protocol) e o A2A (Agent2Agent) abordam estas questões sob perspetivas diferentes. O MCP permite que os agentes se liguem a ferramentas e dados, o A2A permite a comunicação e colaboração entre agentes, e o ERC-8004 disponibiliza descoberta de identidade e sinais de confiança entre plataformas. Compreender os seus limites técnicos e a forma como funcionam em conjunto ajuda a explicar como as redes abertas de agentes de IA podem evoluir de chamadas individuais de ferramentas para sistemas multiagente combináveis.

Principais conclusões

• O valor central da identidade onchain para agentes de IA reside na capacidade de descoberta, verificabilidade e colaboração entre plataformas. Ajuda agentes criados por diferentes programadores e plataformas a estabelecer ligações de identidade consultáveis sem depender inteiramente de um único diretório de serviços centralizado.

• O ERC-8004 fornece infraestrutura de identidade e confiança através do Registo de Identidade, do Registo de Reputação e do Registo de Validação, suportando o registo de agentes, o feedback de reputação e a validação de tarefas.

• O MCP aborda sobretudo a forma como os agentes utilizam ferramentas, ligando bases de dados, serviços de pesquisa, sistemas de ficheiros e API externos através de interfaces normalizadas.

• O A2A aborda sobretudo a forma como os agentes colaboram com outros agentes, suportando a descoberta de capacidades, a delegação de tarefas, a troca de mensagens e a gestão do estado das tarefas.

• O ERC-8004, o MCP e o A2A não são soluções concorrentes. Podem tratar, respetivamente, da identidade e confiança, do acesso a ferramentas e da comunicação entre agentes. Contudo, o registo onchain, por si só, não constitui uma verificação de identidade no mundo real nem garante resultados fiáveis de execução de tarefas.

Porque precisam os agentes de IA de identidade onchain? Quais são as limitações das contas de plataformas tradicionais?

O desafio da identidade para os agentes de IA não consiste simplesmente em atribuir um nome a um programa. Exige o estabelecimento de ligações de identidade que outros sistemas possam reconhecer e verificar.

Em plataformas centralizadas, os agentes são normalmente identificados através de contas de plataforma, chaves API ou endereços de serviço fornecidos pelos programadores. As plataformas podem gerir permissões de utilizadores, manter diretórios de serviços e restringir infrações. Este modelo funciona bem para operações dentro de uma única plataforma. No entanto, quando os agentes precisam de colaborar entre organizações, as informações de identidade podem não ser partilháveis, as avaliações históricas podem ser difíceis de transferir e a fiabilidade do serviço pode depender de uma determinada plataforma.

Por exemplo, um agente de análise de mercado desenvolvido por uma empresa pode ter acumulado um extenso histórico de serviços numa plataforma. Quando entra noutra rede de agentes, a nova plataforma pode não conseguir verificar diretamente esses registos, exigindo que o programador restabeleça a identidade e a reputação do agente.

A identidade onchain procura reduzir esta fragmentação. Ao registar identificadores, direitos de controlo e determinados sinais de confiança numa blockchain pública, diferentes aplicações podem consultar as mesmas informações de registo e desenvolver, com base nelas, os seus próprios sistemas de descoberta de serviços e avaliação de riscos.

No entanto, a identidade onchain não exige que o próprio modelo de IA seja executado numa blockchain. A inferência, o acesso a bases de dados e as chamadas de ferramentas podem continuar a ocorrer offchain. A blockchain trata sobretudo do registo partilhado, de registos verificáveis e da coordenação de confiança.

Isto também significa que a identidade onchain não pode substituir a verificação de identidade tradicional. Um endereço pode provar que uma determinada chave tem permissão para executar certas operações, mas não prova necessariamente que o programador por trás do endereço possui qualificações legítimas. Casos de utilização de elevado risco, como finanças e cuidados de saúde, continuam a exigir verificação adicional de identidade legal e autorização para atividades empresariais.

O que é o ERC-8004? Como estabelece uma identidade portátil para agentes de IA?

O ERC-8004, formalmente denominado Trustless Agents, é uma norma proposta no ecossistema Ethereum para redes abertas de agentes. O seu objetivo é fornecer infraestrutura de descoberta e confiança entre organizações para agentes, sem exigir relações de confiança preexistentes.

O mecanismo de registo de identidade do ERC-8004 baseia-se no ERC-721. Após registar um agente, um programador pode obter um agentId e utilizar as informações de registo correspondentes para associar o nome do agente, a descrição funcional, os pontos finais de serviço e os protocolos de comunicação suportados.

Esta conceção separa a identidade de um agente do seu endereço de serviço específico. Por exemplo, um agente pode mudar de servidores ou atualizar a sua interface A2A, mantendo a sua identidade registada. Outras aplicações apenas precisam de consultar as informações de registo relevantes para obter o ponto final de serviço atualizado.

O ERC-8004 também permite que as informações de registo estabeleçam ligações a diferentes tipos de pontos finais, incluindo MCP, A2A, ENS, DID e endereços de carteira, ligando a identidade onchain à infraestrutura Web3 e de IA existente.

O seu núcleo é composto por três registos:

O Registo de Reputação não determina automaticamente quais as avaliações autênticas ou fiáveis. Em vez disso, fornece registos de feedback consultáveis. Diferentes aplicações podem conceber os seus próprios algoritmos de pontuação, filtragem e avaliação de riscos.

O Registo de Validação permite que validadores terceiros verifiquem resultados de tarefas específicas. Os métodos de validação podem incluir reexecução, ambientes de execução fidedignos (TEE) ou aprendizagem automática de conhecimento zero (zkML).

Importa referir que o ERC-8004 mantém o estado de Draft na página EIP da Ethereum. Isto não impede os programadores de o implementar e experimentar, mas o estado da sua especificação deve ser distinguido da sua adoção efetiva.

O que é o MCP? Como liga agentes de IA a ferramentas e dados externos?

O MCP (Model Context Protocol) é um protocolo aberto para ligar aplicações de IA a ferramentas externas, dados e recursos de contexto.

Sem uma interface unificada, os programadores podem necessitar de escrever lógica de integração separada para cada base de dados, sistema de ficheiros ou API. À medida que os agentes utilizam mais ferramentas, esta abordagem pode resultar em trabalho de desenvolvimento duplicado e custos de manutenção mais elevados.

O MCP reduz a complexidade de ligar diferentes aplicações de IA a capacidades externas através de comunicação normalizada entre clientes e servidores.

Na arquitetura MCP, os servidores podem fornecer aos clientes três tipos principais de capacidades:

• Ferramentas: funções executáveis, como consultar bases de dados, pesquisar informações ou chamar API empresariais.

• Recursos: dados de contexto legíveis, como documentos, registos de bases de dados e conteúdos de ficheiros.

• Prompts: modelos de prompt reutilizáveis para estruturar interações em tarefas específicas.

Por exemplo, um agente de investigação sobre cripto pode utilizar o MCP para se ligar a uma base de dados de dados de mercado, a interfaces de dados onchain e a um repositório de investigação. Quando um utilizador solicita uma análise, o agente pode chamar as ferramentas relevantes, obter dados e gerar resultados de investigação.

O MCP centra-se na normalização do acesso a ferramentas, não no estabelecimento de uma identidade onchain pública.

O MCP também pode funcionar com mecanismos de autorização tradicionais para proteger serviços restritos. Para o transporte HTTP, as especificações relevantes suportam fluxos de autorização baseados em OAuth. Por conseguinte, o MCP não deve ser entendido como totalmente desprovido de capacidades de identidade ou controlo de acesso.

A diferença face ao ERC-8004 é que a autorização do MCP suporta sobretudo ligações a ferramentas específicas e acesso a recursos, enquanto o ERC-8004 se centra em identidades de agentes partilháveis e registos de confiança entre plataformas.

O que é o A2A? Como suporta a colaboração em tarefas entre agentes de IA?

O A2A (Agent2Agent) é um protocolo de comunicação aberto para diferentes sistemas de agentes. A Google liderou inicialmente o seu desenvolvimento, tendo posteriormente passado a integrar o ecossistema da Linux Foundation.

Ao contrário do MCP, que liga sobretudo ferramentas, o A2A visa permitir que agentes de IA desenvolvidos por diferentes programadores e com diferentes frameworks descubram as capacidades uns dos outros e troquem mensagens, deleguem tarefas e façam a gestão do estado de execução de uma forma normalizada.

Um mecanismo importante do A2A é o Agent Card. Trata-se de um documento de metadados legível por máquina que descreve o nome, as capacidades, as competências, o endereço de serviço e os requisitos de autenticação de um agente.

Quando um agente precisa de delegar uma tarefa, pode primeiro ler o Agent Card do outro agente, determinar se este possui as capacidades necessárias e, em seguida, iniciar um pedido de acordo com o protocolo.

O A2A também suporta a gestão do ciclo de vida das tarefas. Por exemplo, uma tarefa de investigação complexa pode demorar bastante tempo a concluir. O agente iniciador pode consultar o respetivo estado, receber atualizações de progresso e obter os resultados após a conclusão da execução.

Isto difere dos pedidos API comuns. As API tradicionais são frequentemente concebidas para operações individuais, enquanto o A2A dá maior ênfase a interações contínuas entre agentes durante as tarefas.

No entanto, o próprio A2A também inclui mecanismos para descoberta de capacidades e autenticação. Assim, o ERC-8004 não preenche uma ausência total de funcionalidade de identidade no A2A. Em vez disso, acrescenta informações de identidade, reputação e validação onchain que podem ser partilhadas entre plataformas.

O A2A trata da comunicação e colaboração em tarefas, enquanto o ERC-8004 pode ajudar os solicitantes a avaliar o desempenho histórico de um prestador de serviços e os sinais de confiança relevantes antes de estabelecer uma relação de trabalho.

Em que diferem o ERC-8004, o MCP e o A2A?

O ERC-8004, o MCP e o A2A abordam questões diferentes nos sistemas de agentes. Os três podem surgir no mesmo fluxo de trabalho, mas nem todos os agentes de IA precisam de utilizar todos.

Os três podem ser entendidos como três camadas de uma rede aberta de agentes.

O ERC-8004 fornece identidades e sinais de confiança que podem ser consultados entre plataformas, o MCP liga os agentes às ferramentas necessárias para executar tarefas e o A2A ajuda vários agentes a trocar tarefas e resultados.

Esta divisão também significa que o ERC-8004 não substitui as capacidades de chamada de ferramentas do MCP, o MCP não substitui os mecanismos de colaboração em tarefas do A2A e o A2A não exige uma blockchain para comunicar.

O seu valor reside na possibilidade de serem combinados de acordo com as necessidades empresariais, em vez de exigirem um conjunto fixo de dependências técnicas.

Como concluem o ERC-8004, o MCP e o A2A um fluxo de trabalho multiagente?

Suponha-se que uma instituição pretende utilizar agentes de IA para gerar automaticamente um relatório de investigação sobre um criptoativo. A tarefa global pode envolver dados de mercado, dados onchain, notícias e análise de riscos, exigindo colaboração entre vários agentes.

Primeiro, o agente principal de investigação precisa de encontrar um agente especializado que preste serviços de análise onchain. Pode consultar as informações de registo relevantes através do Registo de Identidade do ERC-8004 para obter descrições de serviços e pontos finais A2A.

Em seguida, o agente principal de investigação pode ler o feedback histórico no Registo de Reputação para avaliar se os potenciais prestadores de serviços têm experiência de serviço relevante. Para tarefas de análise mais exigentes, também pode consultar registos de validação independentes.

Após selecionar os candidatos, o agente principal de investigação inicia uma tarefa com o agente escolhido através do A2A, solicitando uma análise dos fluxos recentes de fundos onchain de um determinado ativo.

Depois de receber a tarefa, o agente delegado utiliza o MCP para chamar ferramentas de dados de blockchain, bases de dados ou API externos, obter as informações necessárias e realizar a análise.

Quando a tarefa estiver concluída, o agente delegado devolve os resultados da investigação através do A2A. O agente principal de investigação pode então integrar outras informações e gerar o relatório final.

Se a aplicação tiver integrado o mecanismo de feedback do ERC-8004, também pode registar uma avaliação da qualidade do serviço após o fim da tarefa para referência de futuros colaboradores.

Exemplo de colaboração entre agentes de IA com diferentes protocolos

O essencial neste cenário não é escrever todos os dados na blockchain, mas atribuir diferentes funções à infraestrutura adequada.

Os sinais de identidade e confiança podem ser partilhados através de registos onchain, o A2A trata da comunicação para tarefas complexas e o MCP trata do acesso a dados e da execução de ferramentas.

Esta conceção em camadas preserva a eficiência de execução dos sistemas de internet tradicionais, permitindo simultaneamente que a colaboração entre organizações utilize infraestrutura pública de confiança.

Como aborda o ERC-8004 a reputação e a validação de agentes entre plataformas?

Um desafio importante nas redes abertas de agentes é permitir que estes reutilizem registos de desempenho de serviços acumulados em diferentes plataformas.

Se a reputação for gerida inteiramente por uma plataforma centralizada, um agente poderá não conseguir manter o acesso aos registos de avaliações existentes depois de sair dessa plataforma. Uma nova plataforma também poderá ter dificuldade em verificar de forma independente a origem dos dados históricos.

O Registo de Reputação do ERC-8004 fornece uma interface normalizada para esta questão, permitindo associar o feedback dos clientes à identidade onchain correspondente.

No entanto, os registos públicos não tornam automaticamente as avaliações fiáveis. Programadores maliciosos podem criar um grande número de contas associadas para fornecer feedback falso sobre agentes que controlam. Os concorrentes também podem tentar manipular classificações.

Por conseguinte, as aplicações continuam a precisar de filtrar e ponderar os sinais de reputação com base nas fontes das avaliações, no comportamento histórico e em padrões anómalos.

Para tarefas mais importantes, a reputação por si só pode não ser suficiente para estabelecer confiança. Por exemplo, quando um agente fornece análise de risco de contratos inteligentes, os clientes podem querer não apenas conhecer as suas avaliações anteriores, mas também confirmar se os seus métodos de deteção e resultados de análise foram verificados de forma independente.

O Registo de Validação permite que os sistemas relevantes registem pedidos e resultados de validação e os associem a identidades de agentes específicas.

Contudo, a qualidade da validação depende dos métodos utilizados e dos próprios validadores. Um TEE prova propriedades de um ambiente de execução específico, enquanto a zkML prova que um determinado processo computacional cumpre condições especificadas. Nenhum deles significa que a avaliação empresarial final esteja necessariamente correta.

Assim, a força do ERC-8004 reside em suportar combinações de mecanismos de confiança, e não em fornecer uma única pontuação que determine automaticamente a segurança de todos os agentes.

Porque utiliza o ERC-8004 uma blockchain em vez de um diretório centralizado de agentes?

Os diretórios centralizados de agentes têm valor. Para sistemas empresariais internos, uma plataforma de gestão unificada normalmente facilita o controlo de acesso, a revisão de serviços e a manutenção da segurança.

No entanto, entre organizações, diferentes plataformas podem utilizar normas de registo e sistemas de avaliação distintos. As informações de identidade e os dados de reputação detidos por uma plataforma podem não ser diretamente consultáveis ou reutilizáveis por outra.

A blockchain disponibiliza uma abordagem de manutenção de registos partilhada que permite a diferentes aplicações desenvolver serviços em torno das mesmas informações de registo públicas.

O ERC-8004 utiliza o ERC-721 como base para o registo de identidade, associando as identidades dos agentes às relações de propriedade e controlo onchain. As informações de registo também podem apontar para metadados offchain, evitando a necessidade de armazenar diretamente na blockchain todas as descrições e dados de serviço.

Esta abordagem oferece um certo grau de combinabilidade. Por exemplo, programadores terceiros podem desenvolver motores de pesquisa de agentes, plataformas de análise de reputação ou serviços de validação de tarefas sem depender inteiramente da plataforma de registo original.

Contudo, a blockchain também introduz novos custos e complexidade, incluindo taxas de transação, coordenação de identidade entre redes e questões de privacidade resultantes de registos públicos.

Além disso, embora as identidades onchain possam ser consultadas, os pontos finais de serviço associados podem continuar a falhar, e os metadados podem conter erros ou conteúdos enganosos. Um registo público não pode substituir a monitorização contínua do serviço.

Assim, a blockchain é mais adequada para a partilha entre organizações e a coordenação de confiança, mas não necessariamente para gerir todos os aspetos da operação e gestão dos agentes.

Em que difere o ERC-8004 do ENS e do DID?

O ENS (Ethereum Name Service) e o DID (Decentralized Identifier) também envolvem identidade digital, o que facilita a confusão com o ERC-8004.

O ENS fornece sobretudo nomes legíveis por humanos e resolução de registos associados. Por exemplo, um endereço Ethereum pode ser associado a um nome ENS facilmente reconhecível, reduzindo a dificuldade de utilização de endereços complexos.

O DID é uma categoria de especificações de identificadores descentralizados que pode ser combinada com diferentes métodos DID e mecanismos de verificação para estabelecer sistemas de identidade digital.

O ERC-8004 centra-se mais especificamente nas necessidades de aplicação dos agentes de IA. Para além de identificadores, precisa de associar capacidades de serviço, pontos finais de comunicação, feedback histórico e informações de validação de tarefas.

Estes mecanismos não são mutuamente exclusivos.

Um agente pode ter simultaneamente uma identidade ERC-8004, um nome ENS e um identificador DID, com os dados relevantes associados nas respetivas informações de registo.

A diferença é que o ENS e o DID não fornecem especificamente os registos de reputação de agentes e validação de tarefas definidos pelo ERC-8004.

Que desafios de segurança e privacidade apresenta a identidade onchain para os agentes de IA?

A identidade onchain pode tornar os registos mais fáceis de consultar, mas não resolve inerentemente os problemas de segurança em redes abertas.

O primeiro risco é o abuso de identidade. A criação de uma identidade onchain não exige necessariamente verificações rigorosas de identidade no mundo real, pelo que participantes maliciosos podem registar um grande número de agentes para fabricar redes de serviços ou registos de reputação.

O segundo risco diz respeito ao controlo da identidade. Se a chave de controlo de um agente for roubada, um atacante pode modificar as respetivas informações de registo ou executar operações não autorizadas. Os programadores de agentes de elevado valor precisam de uma gestão de chaves mais rigorosa e de separação de permissões.

O terceiro risco é a segurança dos metadados. As informações de registo do ERC-8004 podem associar pontos finais de serviços externos, mas esses pontos finais podem ser atacados, substituídos ou encerrados. Os clientes não devem confiar no conteúdo devolvido apenas porque um endereço aparece num registo.

A quarta questão é a privacidade. Os registos de feedback e validação onchain podem permanecer públicos a longo prazo. Se os programadores escreverem diretamente onchain identidades de clientes, detalhes sensíveis de tarefas ou dados empresariais, podem criar uma exposição irreversível de informações.

Por conseguinte, uma conceção mais adequada consiste em registar onchain os identificadores, resumos criptográficos e sinais de confiança necessários, mantendo os dados empresariais sensíveis em sistemas offchain com controlos de acesso adequados.

Por fim, o próprio modelo de confiança tem limitações. Um agente com bom desempenho em consultas de dados simples pode não conseguir executar operações financeiras complexas em segurança. As aplicações precisam de escolher diferentes níveis de validação com base no valor da tarefa, nas consequências dos erros e na sensibilidade dos dados.

Os agentes envolvidos em transferências de ativos ou execução de operações também devem ter permissões de carteira separadas, limites de fundos e condições de aprovação humana. A identidade onchain não deve ser considerada uma autorização para movimentar fundos.

Como afetarão o ERC-8004, o MCP e o A2A a Web3 e a economia de agentes de IA?

O desenvolvimento do ERC-8004, do MCP e do A2A reflete a expansão gradual da infraestrutura de agentes de IA, desde chamadas de ferramentas dentro de aplicações individuais até redes de colaboração que abrangem plataformas e organizações.

O MCP reduz a complexidade de ligar agentes a dados e ferramentas externos, o A2A fornece uma abordagem comum para interações em tarefas entre agentes e o ERC-8004 procura reduzir a dependência total de uma única plataforma para informações de identidade e confiança.

Para o ecossistema Web3, esta arquitetura pode permitir novas aplicações, incluindo diretórios descentralizados de agentes, análise de reputação onchain, validação de tarefas de agentes e sistemas de pagamento e liquidação para serviços automatizados.

Quando combinados com protocolos de pagamento como o x402, os agentes também podem pagar por dados, computação e outros serviços digitais após receberem autorização, criando um fluxo de trabalho mais completo desde a descoberta de serviços até à execução de tarefas, pagamento e feedback.

Contudo, a adoção destas normas não significa que todos os agentes de IA precisem de emitir um token ou que todas as atividades dos agentes tenham de funcionar numa blockchain.

As aplicações que proporcionam valor genuíno continuam a precisar de demonstrar vantagens face às soluções existentes em termos de custo, eficiência, segurança e interoperabilidade entre plataformas.

A longo prazo, o desenvolvimento de redes abertas de agentes pode alargar o papel da blockchain para além da manutenção de registos de ativos e da infraestrutura de liquidação, abrangendo a identidade de máquinas e a coordenação de confiança.

Resumo

Os agentes de IA precisam de identidade onchain sobretudo porque as redes abertas de agentes enfrentam desafios relacionados com a descoberta de identidade entre plataformas, a portabilidade de reputação e a validação de tarefas.

As contas de plataformas tradicionais e as chaves API podem satisfazer necessidades de identidade e autorização em sistemas específicos, mas as informações associadas são frequentemente difíceis de partilhar entre organizações. Através de registos de identidade, reputação e validação onchain, o ERC-8004 estabelece infraestrutura de confiança combinável para diferentes plataformas.

O MCP e o A2A abordam, respetivamente, a conectividade de ferramentas dos agentes e a colaboração entre sistemas. O MCP permite que os agentes acedam a dados e executem operações de ferramentas, enquanto o A2A permite que diferentes agentes descubram capacidades, deleguem tarefas e troquem resultados.

Os três não são substitutos uns dos outros. Podem ser combinados de acordo com necessidades práticas.

À medida que os agentes de IA participam cada vez mais na aquisição de dados, investigação financeira, operações empresariais e serviços automatizados, a identidade, a confiança, a comunicação e os pagamentos podem formar um sistema técnico mais completo. Contudo, a identidade onchain não estabelece fiabilidade no mundo real e a reputação pública não garante a qualidade do serviço. As aplicações práticas continuam a exigir validação de segurança robusta, gestão de permissões e controlos de risco.

O ERC-8004 aborda a coordenação de identidade e confiança em redes abertas, o MCP liga ferramentas e dados, e o A2A liga diferentes agentes. Em conjunto, fornecem uma base para a colaboração entre agentes de IA em várias plataformas.

Perguntas frequentes

Porque precisam os agentes de IA de identidade onchain?

A identidade onchain fornece aos agentes identificadores que podem ser consultados entre plataformas e associados a informações de serviço, feedback histórico e registos de validação, reduzindo a dependência de um único diretório centralizado.

O que é o ERC-8004?

O ERC-8004 é uma proposta de norma Ethereum para agentes de IA que suporta a descoberta de agentes e a avaliação de confiança através de registos de identidade, reputação e validação.

Qual é a principal diferença entre o ERC-8004 e o MCP?

O ERC-8004 trata sobretudo das informações de identidade e confiança entre plataformas, enquanto o MCP aborda sobretudo a forma como as aplicações de IA se ligam a ferramentas externas, dados e recursos de contexto.

Qual é a diferença entre o MCP e o A2A?

O MCP centra-se nas interações entre agentes e ferramentas, enquanto o A2A se centra na comunicação, delegação de tarefas e colaboração entre diferentes agentes.

Porque é necessário o ERC-8004 se o A2A já suporta Agent Card?

O Agent Card pode descrever as capacidades e os pontos finais de serviço de um agente, enquanto o ERC-8004 fornece adicionalmente interfaces para a partilha entre plataformas de identidade onchain, feedback de reputação e validação de tarefas.

O ERC-8004 exige que os agentes de IA sejam executados numa blockchain?

Não. A inferência de modelos de IA e a execução de ferramentas podem continuar offchain. A blockchain é utilizada sobretudo para o registo de identidade e os registos de confiança relacionados.

Ter uma identidade ERC-8004 significa que um agente de IA é seguro e fiável?

Não. O registo onchain apenas prova a ligação entre uma determinada identidade e os seus registos de registo. A avaliação de riscos continua a exigir validação do serviço, análise de reputação e controlos de segurança.

O ERC-8004, o MCP e o A2A podem ser utilizados com o x402?

Sim. O ERC-8004 fornece sinais de identidade e confiança, o MCP e o A2A tratam do acesso a ferramentas e da colaboração em tarefas, e o x402 pode fornecer capacidades de pagamento para serviços pagos.