Cómo funcionan los agentes de IA en crypto: herramientas y…

Los agentes de IA en crypto funcionan ejecutando un bucle de agente que convierte indicaciones en consultas de datos estructurados en la cadena, luego enruta cualquier acción propuesta a través de reglas de billetera programables antes de que se pueda ejecutar una transacción. La parte útil no es “el bot comercia”, es el límite de permisos entre la inteligencia de solo lectura y la ejecución en la cadena.

Puntos clave

• Los agentes de crypto se vuelven utilizables cuando la “inteligencia” se separa de la “ejecución”: llamadas a herramientas de análisis estructurado por un lado, autorización de cuentas inteligentes por el otro.
• El servidor MCP de Dune expone 12 herramientas a través de un único punto de acceso para que un agente pueda descubrir tablas, generar DuneSQL, ejecutar consultas y devolver resultados consumibles por máquinas en más de 100 blockchains.
• Las Cuentas Inteligentes Seguras reemplazan las EOAs de clave única con propietarios más un umbral, y pueden ser ampliadas con módulos críticos de seguridad y guardias que también pueden fallar de maneras desagradables.
• El soporte de cadenas no es uniforme, por lo que una pila de agentes que asume un módulo o característica específica de Safe puede funcionar en una red y no estar disponible en otra.

Cómo encajan los agentes de IA en crypto

En una pantalla, “agentes en crypto” generalmente se ven como un cuadro de chat que puede mostrar un gráfico, resumir flujos y, a veces, poner en cola una transacción. Bajo el capó, el modelo mental limpio es un pipeline de dos claves: un cerebro de solo lectura que puede llamar a herramientas de análisis estructurado, y un conjunto de “manos” que solo pueden moverse cuando las reglas de una cuenta inteligente lo permiten.

Ese marco responde a la pregunta de qué son los agentes de IA en crypto sin pretender que el agente es una billetera mágica con opiniones.

El mecanismo en el que la mayoría de los equipos convergen es el bucle de agente percibir decidir actuar, porque se ajusta perfectamente a la división de crypto entre datos y ejecución. La percepción no es “observar la cadena” en el sentido humano. Son llamadas a herramientas que devuelven salidas estructuradas. La decisión es el paso de inferencia del modelo sobre esas salidas más cualquier política que codifiques.

La acción es una propuesta de transacción o una ejecución real en la cadena, dependiendo de cómo esté diseñado el límite de autorización.

Ese límite es donde crypto difiere de la automatización genérica. Un agente SaaS normal puede recibir un clave API y límites de tasa. Un agente de IA cripto que puede firmar está a un mal aviso de convertirse en un evento de pérdida.

Así que la arquitectura que se sostiene es: (1) dar al agente lecturas confiables y llamables por máquina, y (2) darle una ejecución restringida a través de una cuenta inteligente que fuerza aprobaciones explícitas, límites, o ambos.

Aquí es donde el 'flujo de trabajo agente' deja de ser una palabra de moda. El flujo de trabajo es una cadena reproducible de llamadas a herramientas, salidas e intenciones de transacción, con un punto claro donde un umbral seguro o guardia puede decir 'no'.

Acceso de herramientas a datos onchain

El servidor MCP de Dune es un ejemplo concreto de cómo funcionan los agentes de IA cuando no están raspando paneles de control. Expone 12 herramientas a través de un único punto final para que un agente compatible con MCP pueda descubrir tablas, escribir DuneSQL, ejecutar consultas, recuperar resultados y generar visualizaciones contra el almacén de Dune a través de más de 100 blockchains indexados.

Eso importa porque el agente ya no está adivinando nombres de tablas o confiando en capturas de pantalla. Está llamando funciones que devuelven resultados estructurados.

La secuencia es sencilla, y es la parte que la mayoría de los explicadores de 'los agentes leen datos y comercian' omiten:

1. El agente busca en el catálogo de Dune conjuntos de datos relevantes y tablas de contratos decodificados. 2. Genera DuneSQL a partir del aviso, luego ejecuta la consulta a través de la interfaz de la herramienta. 3. Recupera resultados en un formato consumible por máquina y puede renderizar una visualización si es necesario.

La CLI de Dune lleva la misma idea a la automatización nativa de terminal. La CLI está construida para flujos de trabajo de agentes y cubre el descubrimiento de conjuntos de datos, la escritura y ejecución de DuneSQL, la gestión de consultas, la búsqueda de documentos y el seguimiento del uso.

Cada comando produce JSON para consumo por máquina, y se envía con un archivo Skills.md que sigue un estándar de habilidades de agentes para que un agente pueda aprender capacidades y manejo de errores sin integración a medida.

Esta es la realidad de la 'arquitectura de agente de IA cripto': el marco del agente es tan bueno como las herramientas que puede llamar. Si la capa de herramientas devuelve SQL y salidas JSON reproducibles, el agente puede ser auditado y vuelto a ejecutar. Si la capa de herramientas es un panel de control y una vibra, el agente solo está improvisando.

Cuentas inteligentes como capa de ejecución de agentes

La ejecución es donde los agentes de criptomonedas se vuelven lo suficientemente seguros para usar o lo suficientemente peligrosos para evitar. El error común es otorgar a la automatización una EOA. Las EOAs son controladas por un soloclave privada, y si alguien obtiene esa clave, obtiene el control completo. Ese es un modelo de seguridad limpio para un humano con unbilletera de hardwareEs un modelo frágil para software que opera sin supervisión.

Las Cuentas Inteligentes cambian el modelo de autorización. Pueden recibir fondos y realizar transacciones como las EOA, pero no pueden iniciarlas. Su lógica de verificación y ejecución está definida porcontrato inteligentecódigo en lugar de una única clave privada. Ese detalle es la razón por la cual las cuentas inteligentes son la capa natural de "billetera agente". La cuenta en sí se convierte en un motor de políticas.

Safe Smart Account es la implementación más conocida de esa idea. Es una Cuenta Inteligente con multisignatura en su núcleo: un conjunto de propietarios y un umbral de confirmaciones requeridas antes de la ejecución. Los propietarios pueden ser EOAs, otras cuentas de contratos inteligentes o incluso una clave de acceso.

Para un agente, eso significa que la postura predeterminada puede ser “el agente prepara, un humano co-firma”, y el sistema aún utiliza la misma onchain.direccióny contabilidad.

La arquitectura de Safe también importa para el despliegue y las operaciones. Las Cuentas Inteligentes de Safe se despliegan utilizando un patrón de proxy donde un Proxy de Safe delega llamadas a un contrato Safe singleton, lo que reduce el costo de despliegue. La Fábrica de Proxies de Safe puede crear un proxy y ejecutar la configuración en una transacción. Nada de esto es 'IA', pero es la infraestructura que hace posible la automatización controlada.

Controles programables para una automatización más segura

Las superficies de control que realmente hacen que la automatización funcione están dentro de Safe, no dentro del modelo. El umbral multi-sig de Safe es el instrumento contundente. Los módulos y guardias son los escalpelos, y Safe los marca como críticos para la seguridad por una razón.

Los módulos extienden lo que un Safe puede hacer al habilitar patrones de acceso alternativos y permisos granulares. La documentación de Safe menciona ejemplos como límites de asignación y flujos de recuperación, y es explícita en que un Safe básico no requiere módulos.

Agregar o eliminar un módulo requiere confirmación por parte del umbral del propietario, y los módulos deben ser tan seguros como el resto de los contratos de Safe porque pueden expandir lo que es ejecutable.

Los guardias son una palanca diferente. Un guardia puede aceptar o rechazar transacciones basadas en la lógica del guardia. Safe también advierte que los guardias son críticos para la seguridad y que un guardia malicioso podría evitar que se ejecuten transacciones y bloquear el acceso a los fondos almacenados en el Safe. Ese es el modo de falla que la gente pasa por alto cuando trata a los guardias como 'una seguridad adicional'. Un guardia es un contrato de control de acceso. Si es incorrecto o hostil, el Safe puede quedar inoperativo.

Safe también admite transacciones patrocinadas y pago basado en tokens de gas a través de un servicio de retransmisión que acepta tokens ERC20 compatibles y envía transacciones mientras paga el gas en ETH. El mismo camino de relé se puede utilizar para flujos sin ether donde un tercero paga las tarifas en nombre de un Safe. Para los sistemas de agentes, esto se trata menos de conveniencia y más de diseño operativo.

Si se espera que el agente envíe transacciones, las suposiciones sobre el gas y el relé son parte del límite de permisos.

Aquí es donde el “crypto de bucle de agente” se vuelve concreto: la percepción y la inferencia pueden ser rápidas y baratas, pero la acción es una transacción que debe pasar verificaciones de umbral, permisos de módulo y lógica de guardia antes de que llegue a la cadena.

Consideraciones sobre el despliegue y el soporte de la red

Muchos diseños de agentes fallan por una razón aburrida: se asume que la pila es uniforme a través de las cadenas. Safe publica una lista de redes soportadas que muestra las versiones de Smart Account y la disponibilidad de características o módulos por cadena, incluidos módulos como Safe 4337, Safe Passkey y Safe Recovery.

La página es efectivamente una matriz de compatibilidad, y es importante porque “simplemente usaremos el módulo X” no es un plan si la cadena objetivo no lo soporta.

Incluso dentro del ecosistema de Safe, las versiones difieren según la red. La lista de redes soportadas muestra múltiples versiones de Smart Account (por ejemplo, v1.5.0, v1.4.1, v1.3.0 y versiones anteriores) y luego indica qué servicios y módulos están disponibles en cada cadena. Ese es el tipo de detalle que decide si un flujo de trabajo agente puede implementarse como se diseñó o necesita una postura de ejecución diferente.

Aquí es también donde las dos mitades de la tubería deben ser verificadas por separado. La publicación de MCP de Dune describe el acceso a más de 100 blockchains, mientras que la publicación de CLI nativa de agente de Dune describe el acceso a más de 130 cadenas. Esa discrepancia no es un problema en sí misma, pero es un recordatorio para tratar la “cobertura de cadena” como un ítem de verificación, no como un texto publicitario.

Surge una lista de verificación operativa mínima:

1. Confirmar que la capa de datos cubre la cadena objetivo y las tablas de protocolo específicas necesarias para el paso de percepción del agente. 2. Confirmar que la capa de ejecución soporta la versión de Safe y los módulos o características específicas de las que depende la política. 3. Solo entonces diseñar el puente entre ellos, porque el puente es donde viven los permisos y los modos de fallo.

Límites y riesgos abiertos a tener en cuenta

Las fuentes describen bloques de construcción poderosos, pero no proporcionan una única arquitectura de referencia de extremo a extremo para un agente autónomo que tanto analiza como ejecuta. Esa brecha es importante porque la autonomía no es un interruptor. Es un espectro, y el punto seguro en ese espectro depende de cuánta autoridad otorga la capa de ejecución.

Dos límites aparecen de inmediato. Primero, el acceso a las herramientas es tan bueno como su estructura. El MCP y el CLI de Dune están diseñados para devolver salidas consumibles por máquinas, lo cual es la dirección correcta, pero las fuentes no cuantifican la fiabilidad, las tasas de error, o con qué frecuencia los agentes generan consultas incorrectas que aún devuelven resultados que parecen plausibles.

Segundo, los puntos de extensión de Safe son explícitamente críticos para la seguridad. Los módulos pueden ampliar los permisos de ejecución, y los guardias pueden bloquear la ejecución por completo. Esos no son riesgos abstractos. Son restricciones de diseño.

También hay un límite de gobernanza y operaciones que se ignora en los ciclos de hype. Si un agente depende de un módulo, guardia o ruta de retransmisión particular, entonces los cambios de política, actualizaciones o brechas de soporte específicas de la cadena se convierten en parte de la superficie de riesgo del agente. La matriz de redes soportadas de Safe existe porque la disponibilidad de características no es uniforme.

Finalmente, la conversación sobre el 'TEE' tiende a ser presentada como una solución mágica. Un tee puede ayudar a aislar secretos y atestiguar la ejecución de código, pero no reemplaza la necesidad de un límite de permisos de cuenta inteligente. Incluso con una custodia de claves más fuerte, el error costoso sigue siendo dar al software un único punto de fallo y autoridad ilimitada.

Los agentes de criptomonedas se están volviendo reales porque la infraestructura se está volviendo real. La parte difícil sigue siendo la misma: separar la inteligencia de la ejecución, y luego restringir el puente para que el sistema pueda ser confiable con capital.

La Conclusión

He visto a equipos obsesionarse con la elección del modelo e ignorar la parte que realmente decide si un agente es utilizable: el límite de autorización. En el momento en que un agente puede proponer y ejecutar desde un EOA de clave única, todo el sistema hereda el peor modelo de seguridad posible para la automatización. Una clave filtrada, un host comprometido, una mala integración, y se acabó.

Lo que he visto que se mantiene es tratar las herramientas estructuradas al estilo Dune como el cerebro de solo lectura, y luego forzar la ejecución a través de un umbral de Safe hasta que el flujo de trabajo se demuestre a sí mismo. Los módulos y los guardias son donde la automatización se vuelve real, y Safe es explícito en que son críticos para la seguridad. Esa es la postura que evita que 'los agentes en cripto' se conviertan en una interfaz elegante para firmar errores.

Fuentes

• Dune
• Dune
• Documentos Seguros
• Documentos Seguros