Infraestructura de la Economía de Agentes de IA: Una Introducción a la Investigación (Parte 1)
Infraestructura de la Economía de Agentes de IA: Una Introducción a la Investigación (Parte 1)
Fuente original: OKX Ventures. Este artículo está adaptado de un detallado informe de investigación de OKX Ventures. Debido a su extensión, lo publicamos en dos partes: La Parte 1 se centra en el contexto macro, el protocolo x402, ERC-8004 y el Virtuals Protocol; la Parte 2 profundizará en OpenClaw y tendencias más amplias de la industria—¡sigan atentos!
Resumen Ejecutivo
Los Agentes de IA están evolucionando rápidamente de asistentes pasivos a participantes económicos activos: descubren servicios, negocian términos, inician transacciones y (cada vez más) liquidan valor en la cadena. El cambio clave no es que “la IA se vuelve más inteligente”, sino que “la IA recibe y puede realizar pagos”—lo que convierte al software en un actor del mercado.
OKX Ventures lo enmarca como la aparición de redes de pago de máquina a máquina (M2M) y una pila de infraestructura para la economía de agentes, donde la identidad, la confianza, los pagos y los mercados de agentes se convierten en primitivas componibles. En su perspectiva para 2026, destacan los pagos de agentes como una fase temprana de despegue junto con múltiples estándares y pilotos industriales. (okxventures.medium.com)
En la Parte 1, nos centramos en tres componentes fundamentales que aparecen cada vez más en las conversaciones de los desarrolladores:
- x402: un apretón de manos de pago nativo de HTTP que revive el código de estado
402 Payment Required, reservado durante mucho tiempo, para la liquidación de criptomonedas por solicitud. - ERC-8004: una propuesta de estándar de Ethereum para el descubrimiento de agentes + reputación + validación sin confianza.
- Virtuals Protocol: un ecosistema en cadena que trata a los agentes como actores económicos tokenizados y estandariza el comercio de agente a agente a través de ACP.
1) El Contexto Macroeconómico: Por qué la Economía de Agentes Necesita Vías de Criptomonedas
1.1 Los agentes se están convirtiendo en “negocios nativos de API”
En la Web2, el software generalmente se monetiza a través de cuentas, suscripciones, claves API, facturas y contracargos. Los agentes rompen estas suposiciones:
- Los agentes no quieren “registrarse” a mitad de tarea.
- Los agentes no pueden pasar de manera fiable las verificaciones de KYC/identidad diseñadas para humanos.
- Los agentes operan en bucles cerrados (recuperar datos → ejecutar inferencia → ejecutar acción → verificar resultado), donde la liquidación por llamada es a menudo más natural que la facturación mensual.
Es por eso que los micropagos con stablecoins, la finalidad de liquidación en cadena y la autorización programable están ganando relevancia nuevamente—especialmente para flujos de trabajo impulsados por IA que encadenan múltiples servicios.
1.2 Los estándares convergen: herramientas, identidad, confianza y pagos
La pila moderna de agentes se está estandarizando en capas:
- Conectividad de herramientas (cómo los agentes llaman a servicios externos) — por ejemplo, Model Context Protocol (MCP)
- Comunicación entre agentes (cómo los agentes se envían mensajes y coordinan) — por ejemplo, Agent2Agent (A2A)
- Identidad e identificadores (cómo las entidades pueden ser resolubles sin un directorio centralizado) — por ejemplo, W3C Decentralized Identifiers (DIDs) (w3.org)
- Pagos + liquidación (cómo se mueve el valor) — donde protocolos como x402 buscan hacer del pago una parte nativa del flujo HTTP
La dirección es clara: si los agentes van a realizar transacciones de forma autónoma, necesitamos una pila de infraestructura que sea legible por máquina, sin permisos por defecto y verificable en condiciones adversas.
2) x402: Convirtiendo el 402 Payment Required de HTTP en un Flujo de Pago en Cadena
2.1 El código de estado HTTP “no utilizado” que de repente importa
El código de estado HTTP 402 existe desde hace décadas, pero fue reservado para uso futuro en la especificación de semántica HTTP. (datatracker.ietf.org) Referencia: RFC 9110 — Semántica HTTP
x402 toma ese espacio reservado y le da un significado concreto y amigable para los desarrolladores: si deseas este recurso, adjunta un pago válido y reintenta.
Para una visión general rápida centrada en HTTP, consulta: MDN: 402 Payment Required.
2.2 Lo que x402 propone (y por qué es atractivo)
En el diseño de x402, un agente de IA (o cualquier cliente) solicita una API/recurso:
- Solicitud del cliente → la solicitud llega sin pago
- El servidor devuelve HTTP 402 → incluye precios e instrucciones de pago
- El cliente reintenta con autorización de pago firmada
- El servidor verifica y emite el pago → devuelve el recurso
Este flujo se posiciona explícitamente como la eliminación de claves API, cuentas y suscripciones para el acceso de pago por uso. (x402.org) Referencia principal: Whitepaper x402 (PDF)
2.3 Por qué x402 es “nativo de agente” (no solo un nuevo botón de pago)
x402 es interesante para la conversación sobre infraestructura de la economía de agentes porque se alinea con cómo trabajan realmente los agentes:
- Bucle de intención atómica: “Necesito datos → Pago → Continúo la tarea”
- Sin secretos de larga duración como claves API: reduce una vulnerabilidad de seguridad común
- Monetización componible: cualquier punto final de API puede convertirse en un micromercado
Este es el corazón de los pagos de agentes: no solo hacer posible pagar con criptomonedas, sino hacer que los pagos sean iniciables por máquina y a nivel de protocolo, integrados en los flujos normales de Internet. (x402.org)
2.4 Los problemas difíciles que x402 no resuelve por sí solo
x402 puede hacer que el transporte de pagos sea elegante, pero el comercio de agentes en producción necesita más capas:
- Autorización y presupuestos: ¿quién autorizó a este agente a gastar, cuánto y bajo qué limitaciones?
- Incentivos/garantía de calidad: ¿qué pasa si el servidor no entrega el resultado prometido?
- Atomicidad del servicio: ¿podemos vincular el pago a la ejecución + entrega de manera robusta?
- Identidad y confianza del agente: ¿cómo sabemos que el agente/servicio contraparte es legítimo?
Aquí es donde estándares como ERC-8004 y protocolos ecosistémicos como Virtuals ACP se vuelven muy complementarios en lugar de competitivos.
3) ERC-8004: Agentes sin Confianza en Ethereum (Identidad, Reputación, Validación)
Si x402 trata sobre cómo pagan los agentes, ERC-8004 se enfoca en cómo se descubren y confían los agentes a través de los límites organizacionales.
3.1 Lo que propone ERC-8004
ERC-8004 (“Agentes sin Confianza”) es una propuesta de estándar de Ethereum que sugiere el uso de blockchains para:
- descubrir agentes
- elegir agentes
- interactuar con agentes sin confianza preexistente
Define una estructura centrada en:
- un Registro de Identidad
- un Registro de Reputación
- un Registro de Validación
ERC-8004 enfatiza modelos de confianza personalizables con seguridad proporcional al valor en riesgo, que van desde tareas de bajo riesgo hasta tareas de alto riesgo (con opciones como retroalimentación de reputación, reejecución garantizada por staking, pruebas zkML o enfoques basados en TEE). (eips.ethereum.org) Referencia principal: ERC-8004 en EIPs
3.2 Por qué esto es importante para la economía de Agentes de IA
La mayoría de los fallos de los agentes en contextos de dinero real no se deben a la “inteligencia del modelo”—se deben a límites de confianza:
- ¿Puedo verificar qué agente ejecutó qué?
- ¿Puedo limitar el radio de explosión si el agente se compromete?
- ¿Puedo demostrar que un resultado se calculó/verificó según las reglas acordadas?
Los registros de ERC-8004 son un intento directo de hacer que la confianza del agente sea componible, en lugar de reinventarla en cada plataforma cerrada.
3.3 ERC-8004 + x402: una combinación natural
Un modelo mental práctico:
- x402: “Aquí está el apretón de manos de pago para servicios de pago por uso.”
- ERC-8004: “Así es como descubres agentes/servicios y evalúas la confianza.”
Juntos, esbozan un camino desde los pagos de agentes ad hoc hacia economías de agentes abiertas a largo plazo—donde los agentes pueden encontrar proveedores, evaluar la confianza, pagar y seguir adelante.
4) Virtuals Protocol: Una Sociedad de Agentes Tokenizados + Protocolo de Comercio de Agentes (ACP)
Virtuals Protocol aborda la economía de agentes desde un ángulo de ecosistema y coordinación: trata a los agentes como actores económicos en cadena, capaces de generar resultados, obtener ingresos y coordinar tareas.
4.1 Lo que Virtuals afirma estar construyendo
En su propia descripción, Virtuals Protocol es “una sociedad de agentes de IA”: un ecosistema en cadena donde los agentes coordinan el trabajo, realizan transacciones y liquidan resultados sin permisos a través de blockchain. (whitepaper.virtuals.io) Referencia principal: Whitepaper Virtuals Protocol
Una decisión de diseño notable: el protocolo posiciona $VIRTUAL como una moneda transaccional base y un par de liquidez en las interacciones de agentes. (whitepaper.virtuals.io)
4.2 ACP: estándares para el comercio de agente a agente
Virtuals argumenta que sin protocolos estandarizados, la integración del comercio de agentes se convierte en un desorden combinatorio de código personalizado y suposiciones frágiles—especialmente a medida que crece el número de agentes y tipos de transacciones. (whitepaper.virtuals.io) Referencia: Agent Commerce Protocol (ACP)
Es importante destacar que ACP no se trata solo de “pagos”. Se trata de:
- Descubrimiento de ofertas de agentes
- Flujos de trabajo de trabajos estructurados
- Vías de liquidación en cadena
- Un vocabulario compartido para el comercio de agentes
4.3 ACP v2 señala un movimiento hacia la complejidad del mundo real
La documentación de Virtuals describe ACP v2 como una actualización importante, que introduce (entre otras cosas):
- una interfaz unificada de Trabajos para flujos de trabajo
- esquemas personalizados de ofertas de trabajos para requisitos específicos del dominio
- Cuentas como registros persistentes en cadena de relaciones entre agentes e historial de interacciones (whitepaper.virtuals.io)
Referencia: Presentando ACP v2
Esto es importante porque el comercio de agentes es inherentemente heterogéneo: “comprar un conjunto de datos”, “ejecutar una auditoría”, “ejecutar una operación” y “entregar un activo multimedia” no pueden encajar de manera realista en un único esquema rígido.
4.4 Virtuals + ERC-8004 + x402: roles complementarios
Puede surgir una pila coherente:
- ERC-8004: primitivas de descubrimiento + confianza a través de límites
- x402: liquidación sin fricciones por solicitud para APIs/servicios
- ACP (Virtuals): flujo de trabajo, estructuración de trabajos y coordinación de agente a agente dentro de una red comercial
La pregunta abierta para 2026 no es si los agentes pueden realizar transacciones, sino si podemos estandarizar lo suficiente las superficies de flujo de trabajo y confianza para evitar que el ecosistema se fragmente en jardines vallados incompatibles.
5) Lista de Verificación para Desarrolladores y Usuarios: Qué Observar en 2025–2026
5.1 Para desarrolladores: el “plano de control” que falta
Si estás integrando pagos de agentes o interacciones de agentes en cadena, prioriza:
- políticas de gasto (restricciones por comerciante, por tarea, por ventana de tiempo)
- aislamiento de claves (claves operativas separadas de claves de tesorería)
- auditoría (firma cada intención y almacena recibos)
- planes de contingencia y disyuntores (flujos pausables, aprobaciones humanas para casos extremos)
Aquí es donde la “infraestructura de la economía de agentes” se vuelve real: el pago es fácil; el pago seguro es difícil.
5.2 Para usuarios: la autocustodia se convierte en una primitiva de seguridad para agentes
Cuando los agentes pueden realizar transacciones, la seguridad de la billetera deja de ser una preocupación de nicho—se convierte en gestión de riesgos operativos.
Un enfoque práctico que muchos equipos adoptan es separar los fondos por rol:
- una billetera caliente pequeña y monitoreada para gastos limitados de agentes del día a día
- una billetera de tesorería de almacenamiento en frío que solo repone presupuestos intencionalmente
Si estás ejecutando agentes que interactúan con DeFi o servicios cripto de pago por uso, aquí es donde una billetera de hardware puede encajar de forma natural. OneKey, por ejemplo, está diseñada para la autocustodia y puede usarse para mantener los fondos a largo plazo sin conexión mientras aún soporta flujos de trabajo en cadena cuando firmas transacciones deliberadamente.
Próximos Pasos (Avance de la Parte 2)
En la Parte 2, extenderemos este mapa de infraestructura a:
- OpenClaw: su papel en la capa de ejecución/herramientas de agentes y lo que significa para los usuarios de criptomonedas
- trayectorias industriales más amplias: interoperabilidad, presión regulatoria, incidentes de seguridad y la batalla entre estándares abiertos y plataformas cerradas
Descargo de responsabilidad: Este artículo es solo para fines informativos y no constituye asesoramiento financiero.
