Quicknode

22 de junho de 2026 — 8 minutos de leitura

IA Agentes pode 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 Agentes dependem de integrações configuradas previamente, seja através de prompts, frameworks, APIs ou marketplaces. À medida que o número de Agenteserviços acessíveis 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 autônomos.

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

O que é o ERC-8257

ERC-8257 (Agente Registo de Ferramentas) é um projeto de norma da Ethereum que define um registo onchain sem autorização para ferramentas de IA Agentes e ferramentas. Normaliza 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 a IA Agentes descobrir, adquirir acesso e utilizar ferramentas de forma autónoma.

Como funciona a norma ERC-8257

Cada ferramenta registada ou compatível com a norma ERC-8257 Agente terá um registo « onchain » com 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.

Depois de compreendermos o objetivo e os componentes que fazem parte do Agente registo de ferramentas, vamos aprender como funcionam em conjunto e como é o « flow ».

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

1. Registo Flow: Interação entre a editora e o registo.

2. Descoberta e verificação Flow: Interação entre Agentes, registo e ferramentas.

Vamos analisar cada um deles individualmente.

ERC-8257: Como funciona o registo Flow

O registo flow define 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 onchain que Agentes pode posteriormente ser resolvido e verificado.

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

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

A função do registo termina assim que o Agente tiver verificado que o manifesto, o editor e os requisitos de acesso correspondem ao registo.

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 Agente registo de ferramentas resolve a questão da descoberta e verificação. No entanto, nem todas as ferramentas devem poder ser chamadas por todas as Agente nem ser totalmente pública.

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 a um registo de ferramenta.

Quando um Agente tenta utilizar uma ferramenta, pode invocar o contrato de predicado e fazer uma pergunta simples: este utilizador está autorizado a aceder a esta ferramenta?

Agora, o contrato de predicado pode verificar se alguém 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 predicativo 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 Agente é o registo de ferramentas, como é que se regista, como Agentes o descobrir 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 usuários às aplicações.

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

1. Mercados de agentes

Cada ferramenta tem uma proveniência verificável, acesso programável e indicações de preços « onchain ». Isso é suficiente para criar um mercado onde as ferramentas são descobertas, acedidas e comercializadas 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, ao mesmo tempo, interoperáveis na camada de descoberta.

3. Composable Agente Fluxos de trabalho

Com o ERC-8257, é agora possível criar Agente em que cada ferramenta é verificada e submetida a controlo de forma independente são agora possíveis com o ERC-8257.

Por exemplo, um trading Agente pode ser associado a uma ferramenta de recolha de notícias 24 horas por dia, 7 dias por semana, ou a um mercado de previsões Agente pode ser associado a um Twitter (X) Agente.

A norma ERC-8257 proporciona uma forma padronizada de identificar e verificar essas dependências, facilitando aAgente fluxos de trabalho mais fáceis de compor entre fornecedores independentes.

4. Abrir Agente Ecossistemas

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

O padrão ERC-8257 transfere essa responsabilidade para uma infraestrutura compartilhada. Os provedores de ferramentas publicam uma única vez. Frameworks de agentes, carteiras, mercados e aplicativos consomem os mesmos registros.

5. Interorganizacionais Agente Fluxos de trabalho

Atualmente, a maioria Agente fluxos de trabalho atuais operam 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 investigador Agente poderia adquirir acesso a fontes de dados proprietárias disponibilizadas através de ferramentas registadas.

Já se compreende o funcionamento e as capacidades do ERC-8257. O próximo passo é compreender a Agente necessária para ajudar a Agentes que funcione 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 Agente : a descoberta de capacidades e a interação verificável.

Mas, Agentes ainda são necessárias identidades, ambientes de execução, canais de pagamento e coordenação para que haja interação.

Vamos montar a pilha agora.

Com isto lens, o ERC-8257 parece menos um padrão 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.

• Um Agente padrão de identificação pode ser utilizado para comprovar quem está a efetuar o pedido.

Nenhuma dessas responsabilidades recai sobre o 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?»

Agora, 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 se deve Agentes avaliar a reputação? Como é que as plataformas devem classificar as ferramentas? Que normas devem reger os pagamentos, as subscrições ou a partilha de receitas entre sistemas autónomos? Como é que as organizações devem divulgar as suas capacidades internas sem comprometer a segurança?

O ERC-8257 não responde às perguntas. Ele inicia o diálogo e o caminho para a solução.

Perguntas Frequentes (FAQ)

1. Como funciona o padrã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. Agentes Recuperar o manifesto, verificá-lo em relação ao registo onchain , avaliar quaisquer requisitos de acesso e, em seguida, invocar a ferramenta.

2. O que é um manifesto ERC-8257?

Um manifesto é uma descrição legível por máquina de uma ferramenta. Ele contém metadados como funcionalidades, endpoints, requisitos de uso e outras informações que os agentes precisam para entender e interagir com o serviço.

3. O padrão ERC-8257 é exclusivo para agentes de IA?

Não. Qualquer serviço acessível por máquina pode ser registrado através do ERC-8257. Embora o padrão tenha sido projetado pensando em agentes de IA, APIs, serviços de software, sistemas de automação e outros aplicativos programáveis ​​podem usar o mesmo modelo de descoberta.

4. Qual a diferença entre ERC-8257 e 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 descobertas e verificadas. Os dois são complementares e podem ser usados ​​em conjunto na mesma arquitetura de agente.

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

Desenvolvedores pode criar Agente mercados, sistemas de acesso programáveis, Agente , camadas de descoberta de serviços e ecossistemas multi-Agente ecossistemas com base num padrão de registo partilhado.

6. O ERC-8257 está ativo na rede principal?

Sim. O contrato ToolRegistry está implantado em 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 na rede principal Ethereum e na Base. Em meados de 2026, 76 ferramentas estavam indexadas. A EIP permanece em status de rascunho, o que significa que a interface ainda pode sofrer alterações antes da finalização.

7. O ERC-8257 armazena metadados de ferramentas na blockchain?

Não. O registro armazena referências a metadados, e não os metadados em si. As descrições das ferramentas permanecem fora da blockchain, enquanto os hashes armazenados na blockchain permitem que os agentes verifiquem sua integridade.