¿Qué es el ERC-8257? Agente Explicación del Registro de Herramientas
¿Qué es ERC-8257? Una guía sobre el Ethereum Agente registro de herramientas, la búsqueda de herramientas, los predicados, Agente los mercados y la infraestructura de IA.

22 de junio de 2026 — 8 minutos de lectura

IA Agentes puede generar código, ejecutar flujos de trabajo e interactuar con servicios externos.
Encontrar nuevas herramientas sigue siendo mucho más difícil.
La mayoría Agentes se basan en integraciones configuradas previamente, ya sea mediante indicaciones, marcos de trabajo, API o mercados. A medida que aumenta el número de Agenteservicios a los que se puede acceder, ese enfoque resulta difícil de ampliar.
ERC-8257 promete una forma sin permisos de descubrir y verificar herramientas y servicios de tipo «agente».
En este blog se explica qué es el ERC-8257, cómo Agente registro de herramientas, cómo encaja en la pila global de infraestructura de agentes y qué capacidades ofrece este registro.
ERC-8257 (Agente Registro de herramientas) es un borrador de norma de la Ethereum que define un registro en cadena sin permisos para herramientas de IA Agentes y herramientas. Estandariza un registro mínimo y verificable de qué es una herramienta, quién la ha publicado y quién está autorizado a utilizarla.
En abril de 2026, Cody Sears y Ryan Ghods, de OpenSea, propusieron este estándar para permitir que la IA Agentes descubra de forma autónoma herramientas, adquiera acceso a ellas y las utilice.
Cada herramienta registrada o compatible con ERC-8257 Agente tendrá un registro en la cadena de bloques compuesto por tres elementos:
Dirección del creador: la editorial, indicada de forma permanente en el registro
URI de metadatos: un puntero al manifiesto fuera de cadena de la herramienta
Hash del manifiesto: comprueba que la descripción no haya cambiado
Y un cuarto componente opcional en el predicado de acceso, que es una dirección de contrato que determina quién puede llamar a la herramienta.
En conjunto, todo ello crea una fuente de información fiable y común para los metadatos de las herramientas con una garantía: el manifiesto que has obtenido es el que el creador ha publicado, desde el origen que controla, con la dirección con la que lo ha firmado.
Ahora que ya hemos comprendido la finalidad y los componentes que forman parte del Agente registro de herramientas, veamos cómo funcionan todos ellos en conjunto y cómo es el « flow ».
¿Sabías que...? La norma ERC-8257 ya está disponible en Ethereum ,mainnet y Base , con 76 herramientas indexadas a mediados de 2026.
Existen dos flujos de trabajo en el marco de la norma ERC-8257, a saber:
Registro Flow: Interacción entre la editorial y el registro.
Descubrimiento y verificación Flow: Interacción entre Agentes, el registro y las herramientas.
Analicémoslos uno por uno.
El registro flow regula cómo se publica una herramienta y cómo se hace visible. El editor registra la dirección del creador de la herramienta, el URI de los metadatos y el hash del manifiesto (además de un predicado de acceso opcional), creando así el registro en la cadena de bloques que Agentes posteriormente se puede resolver y verificar.
Cuando alguien Agente encuentra una herramienta o un servicio, este proceso de descubrimiento y verificación genera confianza en los metadatos que Agente está leyendo.
La función del registro finaliza una vez que Agente haya comprobado que el manifiesto, el editor y los requisitos de acceso coinciden con el registro inscrito.
Hasta ahora, el ERC-8257 parece un registro genérico, pero es en la sección opcional de predicados donde el ERC-8257 va más allá de un simple registro.
El Agente registro de herramientas resuelve los problemas de detección y verificación. Sin embargo, no todas las herramientas deben poder ser invocadas por cualquier Agente ni ser totalmente pública.
Algunos servicios pueden requerir una suscripción. Otros pueden estar restringidos a los titulares de NFT, a clientes empresariales o Agentes que cumplan determinados requisitos de reputación.
ERC-8257 resuelve el problema del acceso mediante un componente opcional denominado «predicado de acceso»: un contrato externo que determina si un usuario puede utilizar una herramienta.
Un predicado de acceso es una dirección de contrato asociada al registro de una herramienta.
Cuando un Agente intenta utilizar una herramienta, puede invocar el contrato de predicado y plantear una pregunta sencilla: ¿Tiene permiso este solicitante para acceder a esta herramienta?
Ahora, el contrato de predicados puede comprobar si alguien Agente es propietario de un NFT, posee un token de suscripción, ha pagado por el acceso, figura en una lista de permitidos o cumple un requisito de reputación.
Existen diversas herramientas que permiten aplicar diferentes políticas sin necesidad de modificar el propio registro. A continuación se muestran algunos ejemplos:
Tipo de herramienta | Lógica de predicados |
|---|---|
API pública | Siempre devuelve «true» |
Herramienta de investigación premium | Comprobar si la suscripción está activa |
Servicio para empresas | Comprobar si se está incluido en la lista de permitidos |
Herramienta con acceso restringido a NFT | Verificar la titularidad del NFT |
Agente Mercado | Comprueba los requisitos de pago o de solvencia |
Y lo más importante: el ERC-8257 no establece ninguna de esas reglas de forma rígida, sino que permite que el contrato de predicados sea un complemento opcional, lo que mantiene la ligereza del estándar y, al mismo tiempo, garantiza su extensibilidad para una gran variedad de casos de uso.
Ahora sabemos qué Agente es el registro de herramientas, cómo se registra, cómo Agentes se detecta y cómo se controla el acceso. A continuación, ¿qué se puede crear con esto?
Un registro, por sí solo, no resulta especialmente interesante.
El DNS cobró importancia porque permitía encontrar sitios web. Los registros de paquetes cobraron importancia porque el software podía depender de ellos. Las tiendas de aplicaciones cobraron importancia porque conectaban a los usuarios con las aplicaciones.
ERC-8257 crea una capa de descubrimiento para Agenteherramientas accesibles. Veamos algunas de las posibilidades que esto nos ofrece:
Cada herramienta cuenta con una procedencia verificable, un acceso programable e indicaciones de precios en la cadena de bloques. Eso basta para crear un mercado en el que se puedan descubrir, utilizar y intercambiar herramientas sin que intervenga ningún operador de la plataforma.
Un proveedor de herramientas puede definir precios, suscripciones, requisitos de titularidad de tokens, umbrales de reputación o permisos corporativos a través del contrato de predicados. Esta flexibilidad permite que compitan diferentes modelos de acceso, al tiempo que se mantiene la interoperabilidad en la capa de descubrimiento.
Los procesos Agente en las que cada herramienta se verifica y se controla de forma independiente, ahora es posible gracias al ERC-8257.
Por ejemplo, una operación Agente puede vincularse a una herramienta de recopilación de noticias disponible las 24 horas del día, los 7 días de la semana, o a un mercado de predicciones Agente puede vincularse a una cuenta de Twitter (X) Agente.
ERC-8257 ofrece una forma estandarizada de detectar y verificar esas dependencias, lo que facilita la composición de flujos de trabajo múltiplesAgente flujos de trabajo entre proveedores independientes.
Todas las plataformas acaban enfrentándose al mismo reto: mantener su propio directorio de servicios.
ERC-8257 traslada esa responsabilidad a una infraestructura compartida. Los proveedores de herramientas publican los datos una sola vez. Agente Los marcos de trabajo, los monederos, los mercados y las aplicaciones utilizan los mismos registros.
La mayoría de Agente los flujos de trabajo actuales operan dentro de una única organización o plataforma.
El estándar ERC-8257 allana el camino para flujos de trabajo entre organizaciones, como los que se dan entre proveedor y cliente, entre cliente y mercado, y otros.
Por ejemplo, un investigador Agente podría adquirir acceso a fuentes de datos exclusivas disponibles a través de herramientas registradas.
Ya se conoce el funcionamiento y las capacidades del ERC-8257. El siguiente paso es comprender la Agente pila necesaria para que Agentes funcione realmente.
ERC-8257 resuelve un problema específico dentro del Agente pila: el descubrimiento de capacidades y la interacción verificable.
Sin embargo, Agentes aún se necesitan identidad, entornos de ejecución, canales de pago y coordinación para interactuar.
Vamos a montar la pila ahora.
Capa | Pregunta | Protocolo |
|---|---|---|
Agente | ¿Quién es el Agente? | Identidades o carteras ERC-8004 |
Descubrimiento | ¿Qué capacidades hay? | ERC-8257 |
Control de acceso | ¿Quién puede utilizarlos? | Predicados ERC-8257 |
Pagos | ¿Cómo se paga el acceso? | x402, monedas estables |
Ejecución | ¿Cómo se ejecutan las herramientas? | MCP, API, Agente marcos de trabajo |
Coordinación | ¿Cómo Agentes funcionan juntos? | MultisistemaAgente sistemas |
Con esto lens, el ERC-8257 se parece menos a un estándar de IA y más a una infraestructura.
Una herramienta registrada puede exponer un servidor MCP.
Un predicado puede exigir el pago antes de conceder el acceso.
Se puede utilizar un Agente se puede utilizar un estándar de identidad para demostrar quién realiza la solicitud.
Ninguna de esas responsabilidades corresponde al propio ERC-8257.
La función de la norma es responder a una pregunta más sencilla: «¿Qué capacidades hay disponibles y dónde se pueden encontrar?».
Ahora bien, la arquitectura es sólida, al igual que la elección del diseño. Las dudas que quedan se refieren a su adopción.
Hoy en día, la mayor parte del software se basa en integraciones directas.
Un desarrollador elige un servicio, lee su documentación, escribe código utilizando su API y mantiene esa relación a lo largo del tiempo.
ERC-8257 no contribuye a ello, sino que impulsa la infraestructura de agentes en una dirección diferente.
Las capacidades se pueden detectar en tiempo de ejecución.
Las políticas de acceso pasan a ser programables.
Los servicios se pueden utilizar sin necesidad de aprobación humana.
ERC-8257 es una capa de descubrimiento habitual. Puede parecer un elemento menor de la infraestructura.
El DNS era un pequeño componente de la infraestructura. Los registros de paquetes eran un pequeño componente de la infraestructura. Las tiendas de aplicaciones comenzaron como directorios.
El reto más difícil aún está por llegar.
¿Cómo se debería Agentes evaluar la reputación? ¿Cómo deberían los mercados clasificar las herramientas? ¿Qué normas deberían regir los pagos, las suscripciones o el reparto de ingresos entre sistemas autónomos? ¿Cómo deberían las organizaciones dar a conocer sus capacidades internas sin comprometer la seguridad?
El estándar ERC-8257 no responde a las preguntas. Lo que hace es iniciar el diálogo y abrir el camino hacia la solución.
Un proveedor registra una herramienta publicando una dirección de creador, un URI de metadatos, un hash del manifiesto y un predicado de acceso opcional. Agentes Recupera el manifiesto, lo verifica comparándolo con el registro en la cadena de bloques, evalúa los requisitos de acceso y, a continuación, ejecuta la herramienta.
Un manifiesto es una descripción legible por máquina de una herramienta. Contiene metadatos como capacidades, puntos finales, requisitos de uso y otra información Agentes necesaria para comprender el servicio e interactuar con él.
No. Cualquier servicio accesible para máquinas puede registrarse a través de ERC-8257. Aunque el estándar se diseñó pensando en la IA Agentes , las API, los servicios de software, los sistemas de automatización y otras aplicaciones programables pueden utilizar el mismo modelo de descubrimiento.
MCP estandariza la forma en que se exponen y se invocan las herramientas. ERC-8257 estandariza la forma en que se detectan y se verifican las herramientas. Ambas son complementarias y pueden utilizarse conjuntamente dentro de la misma Agente arquitectura.
Los desarrolladores pueden crear Agente mercados, sistemas de acceso programables, Agente , capas de descubrimiento de servicios yAgente ecosistemas basados en un estándar de registro compartido.
Sí. El contrato ToolRegistry está implementado en 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 en Ethereum ,mainnet y Base. A mediados de 2026, hay 76 herramientas indexadas. El EIP sigue en fase de borrador, lo que significa que la interfaz aún puede sufrir cambios antes de su finalización.
No. El registro almacena referencias a los metadatos, en lugar de los metadatos en sí. Las descripciones de las herramientas permanecen fuera de la cadena, mientras que los hash almacenados en la cadena permiten Agentes verificar su integridad.
Fundada en 2017, Quicknode ofrece una infraestructura de blockchain de nivel institucional para desarrolladores y empresas. Con un tiempo de actividad del 99,99 % y compatibilidad con más de 77 cadenas, los equipos pueden crear y ampliar aplicaciones en cadena sin renunciar a nada.
Las últimas novedades sobre ingeniería, actualizaciones de productos y noticias sobre la Web3, directamente en tu bandeja de entrada.
📚 NOVEDAD: Desarrollo de software financiero en SolanaLibro gratuito con 10 programas completos, desde opciones hasta contratos perpetuos.
Consigue un ejemplar