Quicknode

22 de junho de 2026 — 8 minutos de leitura

Os agentes de IA podem gerar código, executar fluxos de trabalho e interagir com serviços externos.

Encontrar novas ferramentas continua a ser muito mais difícil.

A maioria dos agentes recorre a integrações que foram configuradas previamente, seja através de instruções, frameworks, APIs ou mercados de aplicações. À medida que o número de serviços acessíveis aos agentes aumenta, essa abordagem torna-se difícil de escalar.

A norma ERC-8257 promete uma forma sem autorização prévia de descobrir e verificar ferramentas e serviços com capacidade de ação autónoma.

Este blogue explica o que é o ERC-8257, como funciona um registo de ferramentas de agentes, como este se enquadra na pilha global de infraestrutura de agentes e quais as capacidades que este registo permite.

O que é o ERC-8257?

O ERC-8257 (Registo de Ferramentas e Agentes) é um projeto de norma da Ethereum que define um registo na cadeia de blocos, sem necessidade de autorização, para agentes e ferramentas de IA. Este padrão estabelece um registo mínimo e verificável sobre o que é uma ferramenta, quem a publicou e quem está autorizado a utilizá-la.

Em abril de 2026, Cody Sears e Ryan Ghods, da OpenSea, propuseram esta norma para permitir que os agentes de IA descobrissem, adquirissem acesso e utilizassem ferramentas de forma autónoma.

Como funciona a norma ERC-8257

Cada ferramenta registada ou agente compatível com a norma ERC-8257 terá um registo na cadeia de blocos composto por 3 componentes:

1. Endereço do criador: a editora, indicado de forma permanente no registo

2. URI de metadados: um ponteiro para o manifesto fora da cadeia da ferramenta

3. Hash do manifesto: verifica se a descrição não sofreu alterações

E um quarto componente opcional no predicado de acesso, que é um endereço de contrato que determina quem pode aceder à ferramenta.

Em conjunto, estes elementos criam uma fonte única de verdade para os metadados da ferramenta, com uma garantia: o manifesto que obteve é aquele que o criador submeteu, a partir da origem que controla, sob o endereço com o qual assinou.

Agora que já compreendemos o objetivo e os componentes que fazem parte do registo de ferramentas do agente, vamos aprender como funcionam em conjunto e como é o fluxo.

Existem dois fluxos de trabalho no âmbito da norma ERC-8257, nomeadamente:

1. Fluxo do registo: Interação entre o editor e o registo.

2. Fluxo de descoberta e verificação: interação entre agentes, registo e ferramentas.

Vamos analisar cada um deles individualmente.

ERC-8257: Como funciona o fluxo do registo

O fluxo de registo determina a forma como uma ferramenta é publicada e torna-se detetável. Um editor regista o endereço do criador da ferramenta, o URI dos metadados e o hash do manifesto (além de um predicado de acesso opcional), criando o registo na cadeia de blocos que os agentes podem posteriormente resolver e verificar.

ERC-8257: Como funciona o processo de descoberta e verificação

Quando um agente encontra uma ferramenta ou um serviço, este processo de descoberta e verificação cria confiança nos metadados que o agente está a ler.

A função do registo termina assim que o agente verificar que o manifesto, o editor e os requisitos de acesso correspondem ao registo registado.

Até agora, o ERC-8257 parece ser um registo genérico, mas é na secção opcional de predicados que o ERC-8257 se torna mais do que um simples registo.

Controlo de acesso ERC-8257: Explicação do padrão de predicado

O registo de ferramentas dos agentes resolve as questões da deteção e verificação. No entanto, nem todas as ferramentas devem poder ser acedidas por todos os agentes nem ser totalmente públicas.

Alguns serviços podem exigir uma subscrição. Outros podem estar restritos a detentores de NFT, clientes empresariais ou agentes que cumpram requisitos específicos de reputação.

A norma ERC-8257 resolve a questão do acesso através de um componente opcional denominado «predicado de acesso»: um contrato externo que determina se um utilizador pode utilizar uma ferramenta.

O que é o controlo de acesso baseado em predicados

Um predicado de acesso é um endereço de contrato associado ao registo de uma ferramenta.

Quando um agente tenta utilizar uma ferramenta, pode invocar o contrato de predicado e fazer uma pergunta simples: este utilizador tem permissão para aceder a esta ferramenta?

Agora, o contrato de predicado pode verificar se um agente é proprietário de um NFT, detém um token de subscrição, pagou pelo acesso, faz parte de uma lista de autorizados ou cumpre um requisito de reputação.

Diferentes ferramentas podem implementar políticas diferentes sem que seja necessário alterar o próprio registo. Eis alguns exemplos:

Mais importante ainda, a norma ERC-8257 não codifica nenhuma dessas regras de forma rígida; permite que o contrato de predicado seja um complemento opcional, mantendo o padrão leve e, ao mesmo tempo, extensível a uma grande variedade de casos de utilização.

Já sabemos o que é o registo de ferramentas do agente, como é registado, como os agentes o detetam e como o acesso é controlado. A seguir, o que se pode criar com isto?

O que a norma ERC-8257 possibilita

Um registo, por si só, não é particularmente interessante.

O DNS tornou-se importante porque permitia descobrir sítios Web. Os registos de pacotes tornaram-se importantes porque o software podia depender deles. As lojas de aplicações tornaram-se importantes porque ligavam os utilizadores às aplicações.

A norma ERC-8257 cria uma camada de descoberta para ferramentas acessíveis aos agentes. Vamos explorar uma série de funcionalidades que ficam disponíveis graças a isso:

1. Mercados de agentes

Cada ferramenta tem uma proveniência verificável, acesso programável e indicações de preços na cadeia. Isso é suficiente para criar um mercado onde as ferramentas são descobertas, acedidas e negociadas sem que o operador da plataforma intervenha em nenhum desses processos.

2. Mercados de acesso programável

Um fornecedor de ferramentas pode definir preços, subscrições, requisitos de posse de tokens, limiares de reputação ou permissões empresariais através do contrato predicado. Esta flexibilidade permite que diferentes modelos de acesso concorram entre si, mantendo-se interoperáveis na camada de descoberta.

3. Fluxos de trabalho de agentes modulares

Com a norma ERC-8257, é agora possível criar pipelines de agentes com várias etapas, em que cada ferramenta é verificada e submetida a controlos de forma independente.

Por exemplo, um agente de negociação pode estar associado a uma ferramenta de recolha de notícias disponível 24 horas por dia, 7 dias por semana, ou um agente de mercado de previsões pode estar ligado a um agente do Twitter (X).

A norma ERC-8257 proporciona uma forma padronizada de identificar e verificar essas dependências, facilitando a composição de fluxos de trabalho com múltiplos agentes entre fornecedores independentes.

4. Ecossistemas de agentes abertos

Todas as plataformas acabam por enfrentar o mesmo desafio: manter o seu próprio diretório de serviços.

A norma ERC-8257 transfere essa responsabilidade para uma infraestrutura partilhada. Os fornecedores de ferramentas publicam os dados uma única vez. As estruturas de agentes, as carteiras, as plataformas de comércio e as aplicações utilizam os mesmos registos.

5. Fluxos de trabalho de agentes interorganizacionais

Atualmente, a maioria dos fluxos de trabalho dos agentes opera no âmbito de uma única organização ou plataforma.

A norma ERC-8257 abre caminho para fluxos de trabalho entre organizações, como fornecedor-cliente, cliente-mercado e outros.

Por exemplo, um agente de investigação poderia adquirir acesso a fontes de dados exclusivas disponibilizadas através de ferramentas registadas.

Já se compreende o funcionamento e as capacidades do ERC-8257. O próximo passo é compreender a pilha de agentes mais abrangente necessária para que os agentes funcionem efetivamente.

O lugar do ERC-8257 na pilha de infraestrutura da Agentic

A norma ERC-8257 resolve um problema específico no âmbito mais vasto da pilha de agentes: a descoberta de capacidades e a interação verificável.

No entanto, os agentes continuam a necessitar de identidade, ambientes de execução, canais de pagamento e coordenação para interagirem.

Vamos montar a pilha agora.

Nesta perspetiva, o ERC-8257 parece menos uma norma de IA e mais uma infraestrutura.

• Uma ferramenta registada pode expor um servidor MCP.

• Um predicado pode exigir o pagamento antes de o acesso ser concedido.

• Pode ser utilizada uma norma de identificação do agente para comprovar quem está a efetuar o pedido.

Nenhuma dessas responsabilidades incumbe ao próprio ERC-8257.

O papel da norma é responder a uma pergunta mais simples: «Que funcionalidades estão disponíveis e onde podem ser encontradas?»

Ora, a arquitetura é sólida, tal como a escolha de design. As questões em aberto dizem respeito à adoção.

O que se segue para o ERC-8257

Atualmente, a maioria dos programas de software é concebida com base em integrações diretas.

Um programador escolhe um serviço, lê a respetiva documentação, escreve código com base na sua API e mantém essa relação ao longo do tempo.

A norma ERC-8257 não contribui para isso, mas impulsiona a infraestrutura de agentes numa direção diferente.

• As funcionalidades tornam-se detetáveis em tempo de execução.

• As políticas de acesso passam a ser programáveis.

• Os serviços podem ser utilizados sem aprovação humana.

O ERC-8257 é uma camada de descoberta comum. Isso pode parecer uma pequena parte da infraestrutura.

O DNS era uma pequena parte da infraestrutura. Os registos de pacotes eram uma pequena parte da infraestrutura. As lojas de aplicações começaram por ser diretórios.

O desafio mais difícil ainda está por vir.

Como devem os agentes avaliar a reputação? Como devem as plataformas de mercado classificar as ferramentas? Que normas devem reger os pagamentos, as subscrições ou a partilha de receitas entre sistemas autónomos? Como devem as organizações divulgar as suas capacidades internas sem comprometer a segurança?

A norma ERC-8257 não responde às perguntas. Inicia o diálogo e o caminho para a solução.

Perguntas Frequentes (FAQ)

1. Como funciona o ERC-8257?

Um fornecedor regista uma ferramenta através da publicação de um endereço do criador, de um URI de metadados, de um hash do manifesto e de um predicado de acesso opcional. Os agentes recuperam o manifesto, verificam-no em relação ao registo na cadeia de blocos, avaliam quaisquer requisitos de acesso e, em seguida, invocam a ferramenta.

2. O que é um manifesto ERC-8257?

Um manifesto é uma descrição legível por máquina de uma ferramenta. Contém metadados, tais como capacidades, pontos finais, requisitos de utilização e outras informações de que os agentes necessitam para compreender e interagir com o serviço.

3. O ERC-8257 destina-se apenas a agentes de IA?

Não. Qualquer serviço acessível por máquinas pode ser registado através da norma ERC-8257. Embora a norma tenha sido concebida a pensar nos agentes de IA, as APIs, os serviços de software, os sistemas de automação e outras aplicações programáveis podem utilizar o mesmo modelo de descoberta.

4. Em que é que a norma ERC-8257 difere da MCP?

O MCP padroniza a forma como as ferramentas são expostas e invocadas. O ERC-8257 padroniza a forma como as ferramentas são detetadas e verificadas. Ambos são complementares e podem ser utilizados em conjunto na mesma arquitetura de agente.

5. O que podem os programadores criar com o ERC-8257?

Os programadores podem criar mercados de agentes, sistemas de acesso programáveis, fluxos de trabalho de agentes interorganizacionais, camadas de descoberta de serviços e ecossistemas multiagentes com base num padrão de registo partilhado.

6. O ERC-8257 já está ativo na mainnet?

Sim. O contrato ToolRegistry está implementado em 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 na rede principal da Ethereum e na Base. Em meados de 2026, estavam indexadas 76 ferramentas. A EIP mantém-se no estado de «Rascunho», o que significa que a interface ainda pode sofrer alterações antes da sua finalização.

7. O ERC-8257 armazena metadados das ferramentas na cadeia de blocos?

Não. O registo armazena referências aos metadados, em vez dos próprios metadados. As descrições das ferramentas permanecem fora da cadeia, enquanto os hashes armazenados na cadeia permitem que os agentes verifiquem a sua integridade.