A medida que los Agentes de IA evolucionan desde propiedades de herramientas hacia sujetos económicos autónomos, el Agente de IA se convierte en un participante económico capaz de tomar decisiones autónomas, ejecutar operaciones y realizar intercambios de valor. Sin embargo, la infraestructura de pagos tradicional no puede satisfacer una serie de necesidades clave como las transacciones autónomas de los Agentes, la interacción entre ecosistemas y la verificación de identidad.
Estas limitaciones han dado lugar a la creación de una nueva generación de protocolos: x 402, Protocolo de Pagos para Agentes ( AP 2) y ERC- 8004, que establecen una base confiable para el intercambio de valor en la próxima economía de máquinas. Este artículo analizará en profundidad los principios técnicos, los escenarios de aplicación y el estado actual del ecosistema de estos tres principales protocolos, revelando cómo juntos configuran el panorama de pagos de la futura economía de Agentes de IA.
![] ( https://img-cdn.gateio.im/social/moments-f 8 a 84661 da 3 b 3223 c 824 ab 2 c 2 cadc 3 f 7)
x 402 ：Protocolo de pagos en la cadena nativo HTTP
x 402 fue lanzado por Coinbase, y su innovación principal consiste en activar el código de estado HTTP 402 (“PaymentRequired”), que no se aprovecha plenamente en Internet, integrando la lógica de pago de forma nativa en el flujo de solicitudes y respuestas web, logrando “API call es pago”, y realizando la liquidación mediante Stablecoins u otras criptomonedas para resolver los altos fricciones de los pagos tradicionales.
# Detalle del protocolo
Dado que x 402 está construido sobre el código de estado HTTP 402, su arquitectura es cliente/servidor. El cliente es el comprador del servicio o producto, y el servidor es el proveedor. Basándose en esta arquitectura, Coinbase ofrece a los vendedores servicios de facilitadores ( Facilitators ) para simplificar la verificación y liquidación de pagos entre comprador y vendedor.
Tomemos como ejemplo el servidor Canza, que ocupa el primer lugar en el escaneo de x 402 (proporciona información de transacciones mediante IA). Primero, el usuario inicia una solicitud en el cliente para acceder a los servicios de pago de Canza.
![] ( https://img-cdn.gateio.im/social/moments- 4 f 562918407 b 8 c 6 d 44 d 85 aaf 72 de 30 b 6)
Luego, el servidor Canza define la solicitud de pago mediante una respuesta HTTP 402: el cliente debe proporcionar el encabezado X-PAYMENT y pagar con USDC en la cadena Base. Como se muestra a continuación:
![] ( https://img-cdn.gateio.im/social/moments- 72 db 5 ed 3693 dcad 8223 f 342 f 1 be 14558)
Tras analizar el contenido JSON de la respuesta 402, la billetera mostrará un mensaje que requiere firmar una transferencia con autorización (TransferWithAuthorization) mediante firma (ERC- 3009). Este mensaje permite al firmante transferir USDC desde su dirección a la dirección receptora de Canza, delegando a un tercero (EOA o contrato) sin coste de gas. En este ejemplo, delegamos a Canza la dirección de recepción 0 x 4 e 9 bCe 2547 A 9491 b 09 ed 092 c 433 B 19888 e 665 edB para transferir USDC desde nuestra billetera.
![] ( https://img-cdn.gateio.im/social/moments-ced 25702 a 668725 f 0 d 611 e 908 bfaebb 0)
Luego, el usuario firma el mensaje, y el cliente envía el Payload codificado en base 64 en el encabezado X-PAYMENT. Cuando el servidor Canza recibe el Payload, será validado por el facilitador ( Facilitators ) y se realiza el pago en la cadena por parte del servidor. Tras confirmar el pago, Canza proporciona el servicio solicitado al usuario.
Resumiendo el proceso de funcionamiento del protocolo x 402:
![] ( https://img-cdn.gateio.im/social/moments-aa 24950 f 66 af 54874 bd 099 ad 64 a 9 dbe 8)
Es importante destacar que el protocolo x 402 soporta múltiples cadenas de bloques (Base, Avalanche y otras cadenas EVM, Solana) y diversos activos encriptados (que soporten ERC- 3009, por defecto USDC), solo requiere configuración en el servidor:
![] ( https://img-cdn.gateio.im/social/moments- 9 bef 6355 fe 7269 cc 5 ac 08 f 119377 c 363)
Protocolo de Pagos para Agentes (AP 2): Sistema de pagos confiable para ecosistema de Agentes
AP 2 es un marco de pago abierto basado en el protocolo de comunicación AgenttoAgent (A 2 A) y la extensión del Modelo de Contexto (MCP). Su objetivo principal es resolver tres problemas centrales en los negocios de Agentes: verificación de autorización (demostrar que el Agente tiene permiso del usuario), autenticidad (garantizar que la transacción refleja las necesidades reales del usuario) y responsabilidad en las transacciones (definir claramente las responsabilidades en caso de disputas), permitiendo que Agentes de IA puedan realizar transacciones seguras con cualquier comerciante que cumpla con las normativas.
El flujo de trabajo del protocolo AP 2 se basa en la idea de los Mandatos ( Mandates ), que son contratos digitales firmados criptográficamente e inalterables, que sirven como evidencia verificable de las instrucciones del usuario. Existen tres tipos principales de mandatos:
** 1. Mandato de intención ( Intent Mandate ) **
Para transacciones automatizadas en las que el usuario no está presente. El usuario proporciona instrucciones predefinidas a un Agente de IA, con condiciones específicas, como “Comprar entradas para un concierto, con un presupuesto máximo de 500 yuanes”.
![] ( https://img-cdn.gateio.im/social/moments-a 370234 d 3 d 86 da 6913 cc 5 e 3338930569)
** 2. Mandato de carrito ( Cart Mandate ) **
Para transacciones en las que el usuario está presente y confirma. Cuando el agente prepara productos y precios específicos para que el usuario los apruebe, se genera un mandato de carrito. La aprobación del usuario crea un registro seguro e inalterable del producto y precio exactos, asegurando que lo que se ve es lo que se paga.
![] ( https://img-cdn.gateio.im/social/moments- 720852 d 4 fe 6 f 0636 e 2 d 64271993973 ab )
** 3. Mandato de pago ( Payment Mandate ) **
Es un certificado independiente compartido con la red de pagos y la entidad emisora, que transmite información sobre la participación del Agente de IA y la presencia del usuario, ayudando a resolver disputas, realizar evaluaciones de riesgo y cumplir con regulaciones.
![] ( https://img-cdn.gateio.im/social/moments- 810 a 9480851 e 7 e 4 ef 2 a 7 ae 46 e 7 eb 4 e 24)
ERC- 8004 ：Sistema descentralizado de identificación y reputación de Agentes de IA
ERC- 8004 es una solución de identificación descentralizada para Agentes de IA en Ethereum, diseñada para resolver problemas relacionados con la verificación de la autenticidad de la identidad, la fiabilidad de los registros de comportamiento y la verificabilidad. A diferencia de AP 2, ERC- 8004 se centra en construir confianza entre Agentes de IA, en lugar de la confianza en las transacciones entre usuario, AIAgent y comerciante.
El diseño de ERC- 8004 se basa en tres registros ligeros que gestionan diferentes aspectos del modelo de confianza:
** 1. Registro de Identidad (Identity Registry)**
Implementado con el estándar ERC- 721 y extendido con la función URIStorage, permitiendo que la identidad del Agente de IA sea compatible con el ecosistema NFT existente.
![] ( https://img-cdn.gateio.im/social/moments- 7251 bc 0031726 b 9 d 8 d 1 acee 3 c 5257 ff 6)
Cada Agente de IA se registra mediante la función register, obteniendo un agentId único (tokenId de ERC- 721). Durante el registro, el agente debe proporcionar un tokenURI que apunte a su archivo de registro (Archivo de Registro del Agente), en formato JSON estandarizado, que incluya el nombre, descripción, endpoints y modelos de confianza soportados.
** 2. Registro de Reputación (Reputation Registry)**
Proporciona una interfaz estándar para publicar y obtener retroalimentación sobre los servicios del Agente de IA, soportando un sistema de puntuación de 0 a 100, clasificación por etiquetas y asociación con pruebas de pago. Este registro combina datos en cadena y fuera de cadena, garantizando la componibilidad en cadena de los datos clave, mientras que las cálculos complejos se realizan fuera de la cadena para mayor eficiencia.
![] ( https://img-cdn.gateio.im/social/moments- 3 f 55 c 5102 f 78 dd 664 faf 90 fceff 7 f 016)
La estructura del contrato del registro de reputación está estrechamente vinculada con la del registro de identidad; al desplegarse, se debe pasar la dirección del registro de identidad, asegurando que solo los Agentes de IA registrados puedan obtener registros de reputación.
** 3. Registro de Validación (Validation Registry)**
Proporciona hooks universales para solicitar y registrar resultados de validación independientes, soportando múltiples mecanismos de validación, incluyendo depósitos económicos (validadores que vuelven a ejecutar tareas) y pruebas criptográficas (pruebas TEE, zkML, etc.). Este diseño permite que diferentes mecanismos de validación con distintos requisitos de seguridad coexistan en un mismo ecosistema.
El contrato del registro de validación es sencillo, principalmente con dos funciones: ValidationRequest para enviar solicitudes de validación y ValidationResponse para registrar los resultados.
ERC- 8004 es la capa de identificación del ecosistema de Agentes de IA. Proporciona identidades verificables, sistemas de reputación y mecanismos de registro en la cadena, siendo clave para construir la confianza en la economía de máquinas.
La integración de x 402, AP 2 y ERC- 8004 conforma un sistema completo de pagos para Agentes de IA: ERC- 8004 resuelve el problema de identidad, x 402 aborda “cómo usar criptomonedas para micropagos de alta frecuencia”, y AP 2 proporciona un marco seguro y estandarizado para el protocolo de pagos, estableciendo límites económicos independientes para los Agentes de IA. Esto les permite gestionar información, poseer y controlar activos, y participar realmente en el intercambio de valor comercial, impulsando así una nueva economía autónoma basada en máquinas.
