¿Por qué los agentes de IA necesitan una identidad en cadena? Comprender ERC-8004, MCP y A2A

La identidad onchain para agentes de IA se refiere al uso de registros de blockchain consultables para establecer identificadores digitales que permitan reconocer, vincular y gestionar agentes de inteligencia artificial en distintas aplicaciones. A medida que los agentes de IA evolucionan de simples asistentes conversacionales a sistemas autónomos capaces de usar herramientas, acceder a datos, ejecutar tareas y participar en actividades económicas, la identidad de los agentes se está convirtiendo en una infraestructura esencial para las redes de colaboración abiertas. ERC-8004 es un estándar de Ethereum propuesto para abordar esta necesidad. Busca establecer interfaces comunes para la identidad, la reputación y la información de validación de los agentes mediante registros onchain.

En los sistemas de software tradicionales, las identidades de los servicios suelen basarse en cuentas de plataforma, claves API y gestión interna de permisos empresariales. Estos enfoques pueden cubrir la mayoría de las necesidades de los agentes que operan dentro de la misma organización o plataforma. Sin embargo, cuando varios agentes de IA proceden de distintos desarrolladores, se ejecutan en infraestructuras diferentes y necesitan delegarse tareas entre sí, descubrir servicios, confirmar relaciones de control, evaluar el rendimiento histórico y validar los resultados de ejecución se convierten en nuevos retos técnicos.

ERC-8004, MCP (Model Context Protocol) y A2A (Agent2Agent) abordan estos problemas desde perspectivas diferentes. MCP permite que los agentes se conecten a herramientas y datos, A2A permite la comunicación y colaboración entre agentes, y ERC-8004 proporciona descubrimiento de identidad y señales de confianza entre plataformas. Comprender sus límites técnicos y cómo funcionan conjuntamente ayuda a explicar cómo las redes abiertas de agentes de IA pueden evolucionar de llamadas a herramientas individuales a sistemas multiagente componibles.

Puntos clave:

• La principal utilidad de la identidad onchain para agentes de IA reside en la capacidad de descubrimiento, verificabilidad y colaboración entre plataformas. Ayuda a los agentes creados por distintos desarrolladores y plataformas a establecer vínculos de identidad consultables sin depender por completo de un único directorio de servicios centralizado.

• ERC-8004 proporciona infraestructura de identidad y confianza mediante el Registro de identidad, el Registro de reputación y el Registro de validación, y admite el registro de agentes, los comentarios de reputación y la validación de tareas.

• MCP aborda principalmente cómo los agentes utilizan herramientas y conecta bases de datos, servicios de búsqueda, sistemas de archivos y API externas mediante interfaces estandarizadas.

• A2A aborda principalmente cómo los agentes colaboran con otros agentes y admite el descubrimiento de capacidades, la delegación de tareas, el intercambio de mensajes y la gestión del estado de las tareas.

• ERC-8004, MCP y A2A no son soluciones competidoras. Pueden gestionar, respectivamente, la identidad y la confianza, el acceso a herramientas y la comunicación entre agentes. Sin embargo, el registro onchain por sí solo no constituye una verificación de identidad en el mundo real ni garantiza resultados fiables en la ejecución de tareas.

¿Por qué los agentes de IA necesitan identidad onchain? ¿Cuáles son las limitaciones de las cuentas de plataforma tradicionales?

El reto de identidad de los agentes de IA no consiste simplemente en asignar un nombre a un programa. Requiere establecer vínculos de identidad que otros sistemas puedan reconocer y verificar.

En las plataformas centralizadas, los agentes se identifican normalmente mediante cuentas de plataforma, claves API o direcciones de servicio proporcionadas por los desarrolladores. Las plataformas pueden gestionar los permisos de los usuarios, mantener directorios de servicios y restringir infracciones. Este modelo funciona bien para las operaciones dentro de una sola plataforma. Sin embargo, cuando los agentes necesitan colaborar entre organizaciones, es posible que la información de identidad no pueda compartirse, que las evaluaciones históricas sean difíciles de transferir y que la fiabilidad de los servicios dependa de una plataforma concreta.

Por ejemplo, un agente de análisis de mercado desarrollado por una empresa puede haber acumulado amplios registros de servicio en una plataforma. Cuando se incorpora a otra red de agentes, es posible que la nueva plataforma no pueda verificar directamente esos registros, lo que requiere que el desarrollador restablezca la identidad y la reputación del agente.

La identidad onchain busca reducir esta fragmentación. Al registrar identificadores, derechos de control y determinadas señales de confianza en una blockchain pública, diferentes aplicaciones pueden consultar la misma información de registro y crear sobre ella sus propios sistemas de descubrimiento de servicios y evaluación de riesgos.

Sin embargo, la identidad onchain no requiere que el propio modelo de IA se ejecute en una blockchain. La inferencia, el acceso a bases de datos y las llamadas a herramientas pueden seguir realizándose offchain. La blockchain gestiona principalmente el registro compartido, los registros verificables y la coordinación de confianza.

Esto también significa que la identidad onchain no puede sustituir la verificación de identidad tradicional. Una dirección puede demostrar que una clave concreta tiene permiso para realizar determinadas operaciones, pero no demuestra necesariamente que el desarrollador detrás de esa dirección tenga cualificaciones legítimas. Los casos de uso de alto riesgo, como las finanzas y la atención sanitaria, siguen requiriendo una verificación adicional de la identidad legal y autorización para realizar actividades comerciales.

¿Qué es ERC-8004? ¿Cómo establece una identidad portátil para los agentes de IA?

ERC-8004, denominado formalmente Trustless Agents, es un estándar propuesto dentro del ecosistema Ethereum para redes abiertas de agentes. Su objetivo es proporcionar infraestructura de descubrimiento y confianza entre organizaciones para los agentes, sin requerir relaciones de confianza preexistentes.

El mecanismo de registro de identidad de ERC-8004 se basa en ERC-721. Tras registrar un agente, un desarrollador puede obtener un agentId y utilizar la información de registro correspondiente para asociar el nombre del agente, la descripción funcional, los puntos de conexión del servicio y los protocolos de comunicación compatibles.

Este diseño separa la identidad de un agente de su dirección de servicio específica. Por ejemplo, un agente puede cambiar de servidores o actualizar su interfaz A2A mientras conserva su identidad registrada. Otras aplicaciones solo necesitan consultar la información de registro pertinente para obtener el punto de conexión de servicio actualizado.

ERC-8004 también permite que la información de registro enlace distintos tipos de puntos de conexión, incluidos MCP, A2A, ENS, DID y direcciones de billetera, conectando la identidad onchain con la infraestructura existente de Web3 e IA.

Su núcleo consta de tres registros:

El Registro de reputación no determina automáticamente qué evaluaciones son auténticas o fiables. En su lugar, proporciona registros de comentarios consultables. Las distintas aplicaciones pueden diseñar sus propios algoritmos de puntuación, filtrado y evaluación de riesgos.

El Registro de validación permite a validadores externos comprobar resultados de tareas específicas. Los métodos de validación pueden incluir la reejecución, los entornos de ejecución confiables (TEE) o el aprendizaje automático de conocimiento cero (zkML).

Es importante destacar que ERC-8004 sigue teniendo el estado de borrador en la página EIP de Ethereum. Esto no impide que los desarrolladores lo implementen y experimenten con él, pero debe distinguirse el estado de su especificación de su adopción real.

¿Qué es MCP? ¿Cómo conecta a los agentes de IA con herramientas y datos externos?

MCP (Model Context Protocol) es un protocolo abierto para conectar aplicaciones de IA con herramientas externas, datos y recursos de contexto.

Sin una interfaz unificada, los desarrolladores podrían tener que escribir una lógica de integración independiente para cada base de datos, sistema de archivos o API. A medida que los agentes utilizan más herramientas, este enfoque puede generar trabajo de desarrollo duplicado y mayores costes de mantenimiento.

MCP reduce la complejidad de conectar distintas aplicaciones de IA con capacidades externas mediante una comunicación estandarizada entre clientes y servidores.

En la arquitectura de MCP, los servidores pueden proporcionar a los clientes tres tipos principales de capacidades:

• Herramientas: funciones ejecutables, como consultar bases de datos, buscar información o llamar a API empresariales.

• Recursos: datos de contexto legibles, como documentos, registros de bases de datos y contenidos de archivos.

• Prompts: plantillas de prompts reutilizables para estructurar interacciones destinadas a tareas específicas.

Por ejemplo, un agente de investigación sobre criptomonedas puede usar MCP para conectarse a una base de datos de información de mercado, interfaces de datos onchain y un repositorio de investigación. Cuando un usuario solicita un análisis, el agente puede llamar a las herramientas pertinentes, recuperar datos y generar después los resultados de la investigación.

MCP se centra en estandarizar el acceso a herramientas, no en establecer una identidad onchain pública.

MCP también puede funcionar con mecanismos de autorización tradicionales para proteger servicios restringidos. Para el transporte HTTP, las especificaciones pertinentes admiten flujos de autorización basados en OAuth. Por tanto, MCP no debe entenderse como un protocolo que carece por completo de capacidades de identidad o control de acceso.

La diferencia respecto a ERC-8004 es que la autorización de MCP admite principalmente conexiones a herramientas específicas y acceso a recursos, mientras que ERC-8004 se centra en identidades de agentes y registros de confianza que pueden compartirse entre plataformas.

¿Qué es A2A? ¿Cómo admite la colaboración en tareas entre agentes de IA?

A2A (Agent2Agent) es un protocolo abierto de comunicación para distintos sistemas de agentes. Google lideró inicialmente su desarrollo y posteriormente pasó a formar parte del ecosistema de la Linux Foundation.

A diferencia de MCP, que conecta principalmente herramientas, A2A busca permitir que agentes de IA creados por distintos desarrolladores y utilizando marcos diferentes descubran las capacidades de los demás e intercambien mensajes, deleguen tareas y gestionen el estado de ejecución de forma estandarizada.

Un mecanismo importante de A2A es la Agent Card. Se trata de un documento de metadatos legible por máquinas que describe el nombre, las capacidades, las habilidades, la dirección de servicio y los requisitos de autenticación de un agente.

Cuando un agente necesita delegar una tarea, puede leer primero la Agent Card del otro agente, determinar si tiene las capacidades necesarias e iniciar después una solicitud de acuerdo con el protocolo.

A2A también admite la gestión del ciclo de vida de las tareas. Por ejemplo, una tarea de investigación compleja puede requerir bastante tiempo para completarse. El agente iniciador puede consultar su estado, recibir actualizaciones de progreso y recuperar los resultados al finalizar la ejecución.

Esto difiere de las solicitudes de API convencionales. Las API tradicionales suelen diseñarse para operaciones individuales, mientras que A2A pone mayor énfasis en las interacciones continuas entre agentes durante una tarea.

Sin embargo, A2A también incluye mecanismos para el descubrimiento de capacidades y la autenticación. Por tanto, ERC-8004 no cubre una ausencia total de funcionalidades de identidad en A2A. En cambio, añade información de identidad onchain, reputación y validación que puede compartirse entre plataformas.

A2A gestiona la comunicación y la colaboración en tareas, mientras que ERC-8004 puede ayudar a quienes realizan llamadas a evaluar el rendimiento histórico de un proveedor de servicios y las señales de confianza pertinentes antes de establecer una relación de trabajo.

¿En qué se diferencian ERC-8004, MCP y A2A?

ERC-8004, MCP y A2A abordan problemas diferentes en los sistemas de agentes. Los tres pueden aparecer en el mismo flujo de trabajo, pero no todos los agentes de IA necesitan utilizar todos ellos.

Los tres pueden entenderse como tres capas de una red abierta de agentes.

ERC-8004 proporciona identidades y señales de confianza que pueden consultarse entre plataformas, MCP conecta a los agentes con las herramientas necesarias para ejecutar tareas y A2A ayuda a múltiples agentes a intercambiar tareas y resultados.

Esta división también significa que ERC-8004 no sustituye las capacidades de llamada a herramientas de MCP, MCP no sustituye los mecanismos de colaboración en tareas de A2A y A2A no requiere una blockchain para comunicarse.

Su valor reside en que pueden combinarse según las necesidades empresariales, en lugar de requerir un conjunto fijo de dependencias técnicas.

¿Cómo completan ERC-8004, MCP y A2A un flujo de trabajo multiagente?

Supongamos que una institución quiere utilizar agentes de IA para generar automáticamente un informe de investigación sobre un activo cripto. La tarea general puede implicar datos de mercado, datos onchain, noticias y análisis de riesgos, lo que requiere la colaboración de varios agentes.

En primer lugar, el agente principal de investigación necesita encontrar un agente especializado que proporcione servicios de análisis onchain. Puede consultar la información de registro pertinente mediante el Registro de identidad de ERC-8004 para obtener descripciones de servicios y puntos de conexión A2A.

A continuación, el agente principal de investigación puede leer los comentarios históricos del Registro de reputación para evaluar si los posibles proveedores de servicios tienen experiencia de servicio relevante. Para tareas de análisis más exigentes, también puede consultar registros de validación independientes.

Tras seleccionar a los candidatos, el agente principal de investigación inicia una tarea con el agente elegido a través de A2A y solicita un análisis de los flujos recientes de fondos onchain de un activo concreto.

Después de recibir la tarea, el agente delegado utiliza MCP para llamar a herramientas de datos de blockchain, bases de datos o API externas, recuperar la información necesaria y realizar el análisis.

Una vez completada la tarea, el agente delegado devuelve los resultados de la investigación a través de A2A. El agente principal de investigación puede integrar entonces otra información y generar el informe final.

Si la aplicación ha integrado el mecanismo de comentarios de ERC-8004, también puede registrar una evaluación de la calidad del servicio al finalizar la tarea para que futuros colaboradores la consulten.

Ejemplo de colaboración entre agentes de IA mediante varios protocolos

La clave de este escenario no es escribir todos los datos en la blockchain, sino asignar distintas funciones a la infraestructura adecuada.

Las señales de identidad y confianza pueden compartirse mediante registros onchain, A2A gestiona la comunicación para tareas complejas y MCP gestiona el acceso a datos y la ejecución de herramientas.

Este diseño por capas conserva la eficiencia de ejecución de los sistemas tradicionales de internet y, al mismo tiempo, permite que la colaboración entre organizaciones utilice infraestructura pública de confianza.

¿Cómo aborda ERC-8004 la reputación y la validación de agentes entre plataformas?

Un reto importante en las redes abiertas de agentes es permitir que los agentes reutilicen registros de rendimiento de servicio acumulados en distintas plataformas.

Si la reputación se gestiona íntegramente en una plataforma centralizada, es posible que un agente no pueda conservar el acceso a los registros de evaluaciones existentes después de abandonar esa plataforma. Una plataforma nueva también puede tener dificultades para comprobar de forma independiente el origen de los datos históricos.

El Registro de reputación de ERC-8004 proporciona una interfaz estandarizada para este problema y permite vincular los comentarios de los clientes con la identidad onchain correspondiente.

Sin embargo, los registros públicos no convierten automáticamente las evaluaciones en fiables. Los desarrolladores maliciosos pueden crear un gran número de cuentas vinculadas para proporcionar comentarios falsos sobre los agentes que controlan. Los competidores también pueden intentar manipular las calificaciones.

Por tanto, las aplicaciones siguen necesitando filtrar y ponderar las señales de reputación según las fuentes de las evaluaciones, el comportamiento histórico y los patrones anómalos.

Para tareas más importantes, la reputación por sí sola puede no ser suficiente para establecer confianza. Por ejemplo, cuando un agente proporciona análisis de riesgos de contratos inteligentes, los clientes pueden querer no solo conocer sus evaluaciones anteriores, sino también confirmar si sus métodos de detección y resultados de análisis se han comprobado de forma independiente.

El Registro de validación permite que los sistemas pertinentes registren solicitudes y resultados de validación y los vinculen a identidades de agentes específicas.

Sin embargo, la calidad de la validación depende de los métodos utilizados y de los propios validadores. Un TEE demuestra propiedades de un entorno de ejecución específico, mientras que zkML demuestra que un proceso computacional determinado cumple las condiciones especificadas. Ninguno de los dos implica que el juicio empresarial final sea necesariamente correcto.

Por tanto, la fortaleza de ERC-8004 reside en admitir combinaciones de mecanismos de confianza, en lugar de proporcionar una única puntuación que determine automáticamente la seguridad de cada agente.

¿Por qué ERC-8004 utiliza blockchain en lugar de un directorio centralizado de agentes?

Los directorios centralizados de agentes tienen valor. Para los sistemas empresariales internos, una plataforma de gestión unificada suele facilitar el control de acceso, la revisión de servicios y el mantenimiento de la seguridad.

Sin embargo, entre organizaciones, distintas plataformas pueden utilizar diferentes estándares de registro y sistemas de evaluación. Es posible que la información de identidad y los datos de reputación que posee una plataforma no puedan ser consultados o reutilizados directamente por otra.

La blockchain proporciona un enfoque de mantenimiento de registros compartido que permite a distintas aplicaciones crear servicios en torno a la misma información de registro pública.

ERC-8004 utiliza ERC-721 como base para el registro de identidad y vincula las identidades de los agentes con las relaciones de propiedad y control onchain. La información de registro también puede apuntar a metadatos offchain, evitando la necesidad de almacenar directamente en la blockchain todas las descripciones y datos de servicio.

Este enfoque ofrece cierto grado de composabilidad. Por ejemplo, los desarrolladores externos pueden crear motores de búsqueda de agentes, plataformas de análisis de reputación o servicios de validación de tareas sin depender por completo de la plataforma de registro original.

Sin embargo, la blockchain también introduce nuevos costes y complejidad, incluidas comisiones de transacción, coordinación de identidad entre redes y problemas de privacidad derivados de los registros públicos.

Además, aunque las identidades onchain pueden consultarse, los puntos de conexión de servicio asociados pueden seguir fallando y los metadatos pueden contener errores o contenido engañoso. Un registro público no puede sustituir la supervisión continua del servicio.

Por tanto, la blockchain es más adecuada para el intercambio entre organizaciones y la coordinación de confianza, pero no necesariamente para gestionar todos los aspectos de la operación y gestión de los agentes.

¿En qué se diferencia ERC-8004 de ENS y DID?

ENS (Ethereum Name Service) y DID (Decentralized Identifier) también están relacionados con la identidad digital, por lo que es fácil confundirlos con ERC-8004.

ENS proporciona principalmente nombres legibles por humanos y resolución de registros asociados. Por ejemplo, una dirección de Ethereum puede vincularse a un nombre ENS fácilmente reconocible, lo que reduce la dificultad de utilizar direcciones complejas.

DID es una categoría de especificaciones de identificadores descentralizados que puede combinarse con distintos métodos DID y mecanismos de verificación para establecer sistemas de identidad digital.

ERC-8004 se centra más específicamente en las necesidades de aplicación de los agentes de IA. Además de identificadores, necesita vincular capacidades de servicio, puntos de conexión de comunicación, comentarios históricos e información de validación de tareas.

Estos mecanismos no son mutuamente excluyentes.

Un agente puede tener simultáneamente una identidad ERC-8004, un nombre ENS y un identificador DID, con los datos pertinentes vinculados en su información de registro.

La diferencia es que ENS y DID no proporcionan específicamente los registros de reputación de agentes y validación de tareas definidos por ERC-8004.

¿Qué retos de seguridad y privacidad plantea la identidad onchain para los agentes de IA?

La identidad onchain puede facilitar la consulta de registros, pero no resuelve de forma inherente los problemas de seguridad en redes abiertas.

El primer riesgo es el abuso de identidad. Crear una identidad onchain no requiere necesariamente comprobaciones rigurosas de identidad en el mundo real, por lo que los participantes maliciosos pueden registrar un gran número de agentes para fabricar redes de servicios o registros de reputación.

El segundo riesgo se refiere al control sobre la identidad. Si se roba la clave de control de un agente, un atacante puede modificar su información de registro o realizar operaciones no autorizadas. Los desarrolladores de agentes de alto valor necesitan una gestión de claves más estricta y una separación de permisos.

El tercer riesgo es la seguridad de los metadatos. La información de registro de ERC-8004 puede vincular puntos de conexión de servicios externos, pero esos puntos de conexión pueden ser atacados, reemplazados o cerrados. Los clientes no deben confiar en el contenido devuelto únicamente porque una dirección aparezca en un registro.

El cuarto aspecto es la privacidad. Los comentarios onchain y los registros de validación pueden permanecer públicos a largo plazo. Si los desarrolladores escriben directamente en la blockchain las identidades de los clientes, detalles sensibles de las tareas o datos empresariales, pueden generar una exposición irreversible de información.

Por tanto, un diseño más adecuado consiste en registrar onchain los identificadores, resúmenes criptográficos y señales de confianza necesarios, mientras se mantienen los datos empresariales sensibles en sistemas offchain con controles de acceso adecuados.

Por último, el propio modelo de confianza tiene limitaciones. Un agente que funciona bien en consultas de datos sencillas puede no ser capaz de ejecutar operaciones financieras complejas de forma segura. Las aplicaciones deben elegir distintos niveles de validación en función del valor de la tarea, las consecuencias de los errores y la sensibilidad de los datos.

Los agentes implicados en transferencias de activos o ejecución de operaciones también deben tener permisos de billetera separados, límites de fondos y condiciones de aprobación humana. La identidad onchain no debe considerarse una autorización para mover fondos.

¿Cómo afectarán ERC-8004, MCP y A2A a Web3 y a la economía de los agentes de IA?

El desarrollo de ERC-8004, MCP y A2A refleja la expansión gradual de la infraestructura de agentes de IA, desde llamadas a herramientas dentro de aplicaciones individuales hasta redes de colaboración que abarcan plataformas y organizaciones.

MCP reduce la complejidad de conectar agentes con datos y herramientas externos, A2A proporciona un enfoque común para las interacciones de tareas entre agentes y ERC-8004 busca reducir la dependencia total de una única plataforma para la información de identidad y confianza.

Para el ecosistema Web3, esta arquitectura puede permitir nuevas aplicaciones, incluidos directorios descentralizados de agentes, análisis de reputación onchain, validación de tareas de agentes y sistemas de pago y liquidación para servicios de máquinas.

Cuando se combinan con protocolos de pago como x402, los agentes también pueden pagar por datos, computación y otros servicios digitales después de recibir autorización, creando un flujo de trabajo más completo desde el descubrimiento del servicio hasta la ejecución de tareas, el pago y los comentarios.

Sin embargo, adoptar estos estándares no significa que cada agente de IA deba emitir un token ni que toda actividad de los agentes deba ejecutarse en una blockchain.

Las aplicaciones que ofrecen valor real todavía deben demostrar ventajas sobre las soluciones existentes en términos de coste, eficiencia, seguridad e interoperabilidad entre plataformas.

A largo plazo, el desarrollo de redes abiertas de agentes puede ampliar el papel de la blockchain más allá del registro de activos y la infraestructura de liquidación, hacia la identidad de las máquinas y la coordinación de confianza.

Resumen

Los agentes de IA necesitan identidad onchain principalmente porque las redes abiertas de agentes se enfrentan a retos relacionados con el descubrimiento de identidad entre plataformas, la portabilidad de la reputación y la validación de tareas.

Las cuentas de plataforma tradicionales y las claves API pueden cubrir las necesidades de identidad y autorización dentro de sistemas específicos, pero la información asociada suele ser difícil de compartir entre organizaciones. Mediante registros de identidad, reputación y validación onchain, ERC-8004 establece una infraestructura de confianza componible para distintas plataformas.

MCP y A2A abordan, respectivamente, la conectividad de los agentes con herramientas y la colaboración entre sistemas. MCP permite a los agentes acceder a datos y ejecutar operaciones con herramientas, mientras que A2A permite que distintos agentes descubran capacidades, deleguen tareas e intercambien resultados.

Los tres no son sustitutos entre sí. Pueden combinarse según las necesidades prácticas.

A medida que los agentes de IA participan cada vez más en la adquisición de datos, la investigación financiera, las operaciones empresariales y los servicios automatizados, la identidad, la confianza, la comunicación y los pagos pueden formar un sistema técnico más completo. Sin embargo, la identidad onchain no establece la fiabilidad en el mundo real y la reputación pública no garantiza la calidad del servicio. Las aplicaciones prácticas siguen requiriendo una validación de seguridad sólida, gestión de permisos y controles de riesgos.

ERC-8004 aborda la coordinación de identidad y confianza en redes abiertas, MCP conecta herramientas y datos, y A2A conecta distintos agentes. Juntos, proporcionan una base para la colaboración entre plataformas de agentes de IA.

Preguntas frecuentes

¿Por qué los agentes de IA necesitan identidad onchain?

La identidad onchain proporciona a los agentes identificadores que pueden consultarse entre plataformas y vincularse con información de servicio, comentarios históricos y registros de validación, lo que reduce la dependencia de un único directorio centralizado.

¿Qué es ERC-8004?

ERC-8004 es una propuesta de estándar de Ethereum para agentes de IA que admite el descubrimiento de agentes y la evaluación de confianza mediante registros de identidad, reputación y validación.

¿Cuál es la principal diferencia entre ERC-8004 y MCP?

ERC-8004 gestiona principalmente la identidad y la información de confianza entre plataformas, mientras que MCP aborda principalmente cómo las aplicaciones de IA se conectan con herramientas externas, datos y recursos de contexto.

¿Cuál es la diferencia entre MCP y A2A?

MCP se centra en las interacciones entre agentes y herramientas, mientras que A2A se centra en la comunicación, la delegación de tareas y la colaboración entre distintos agentes.

¿Por qué se necesita ERC-8004 si A2A ya admite Agent Card?

Agent Card puede describir las capacidades y los puntos de conexión de servicio de un agente, mientras que ERC-8004 proporciona adicionalmente interfaces para compartir entre plataformas la identidad onchain, los comentarios de reputación y la validación de tareas.

¿ERC-8004 requiere que los agentes de IA se ejecuten en una blockchain?

No. La inferencia de modelos de IA y la ejecución de herramientas pueden seguir realizándose offchain. La blockchain se utiliza principalmente para el registro de identidad y los registros de confianza relacionados.

¿Tener una identidad ERC-8004 significa que un agente de IA es seguro y fiable?

No. El registro onchain solo demuestra el vínculo entre una identidad concreta y sus registros de registro. La evaluación de riesgos sigue requiriendo validación del servicio, análisis de reputación y controles de seguridad.

¿Pueden utilizarse ERC-8004, MCP y A2A con x402?

Sí. ERC-8004 proporciona señales de identidad y confianza, MCP y A2A gestionan el acceso a herramientas y la colaboración en tareas, y x402 puede proporcionar capacidades de pago para servicios de pago.