Google AX: suspensión, reinicios y autoalojamiento

Volver

Kevin Riedl

15 min de lectura · 20 sep 2026
Última revisión 15 de octubre de 2026

Siguiente

Un agente gasta 30 dólares. Su proceso desaparece. Pagas otra vez por trabajo que ya había hecho. Ese es un problema de recuperación. Pagar por agentes que pasan casi todo el tiempo esperando es un problema de capacidad ociosa. Google AX puede ayudar a abordar ambos, pero una misma función no resuelve automáticamente los dos.

AX, también llamado Agent Executor, es el orquestador de Google con licencia Apache 2.0 para tareas de agentes en entornos aislados. Funciona sobre Agent Substrate y utiliza YAML y comandos parecidos a los de Kubernetes. La idea útil es gestionar la ejecución como infraestructura, no crear otro framework para el razonamiento del agente. Consulta el proyecto AX y su advertencia sobre el estado de desarrollo.

Revisión del 15 de octubre de 2026: AX 22954f64bb29 y Agent Substrate 6edd1fccfc9d. Es un análisis de fuentes y arquitectura, no una prueba de despliegue ni un benchmark de rendimiento. El caso de los 30 dólares es ilustrativo, no un resultado de AX medido por nosotros.

¿Qué orquesta Google AX actualmente?

La API actual tiene tres recursos principales: Task, Workspace y Model. Las explicaciones anteriores con cuatro recursos incluyen un Gateway que ya no forma parte del esquema de AX revisado aquí. Un recurso declara configuración, no todas las garantías operativas que la rodean.

Una tarea puede representar un trabajo completo o una operación delegada. Puedes enlazar varios espacios bajo spec.workspaces; el primero será el directorio de trabajo del comando. Conceptos actuales de recursos y ciclo de vida en AX.

¿Qué cambió respecto a los ejemplos de AX de septiembre?

No despliegues sin cambios un manifiesto antiguo de cuatro recursos. Esta versión sustituye el ejemplo anterior de Gateway y revisa el contrato de ejecución. Fija versiones compatibles de CLI, plano de control y runner antes de migrar.

El esquema es una referencia de configuración más fiable que la frase residual sobre «cuatro tipos» de la guía de manifiestos. Tampoco conserva la explicación del antiguo campo reservado para políticas de Task que aparecía en nuestro análisis de septiembre. Revisa el esquema actual de la API de AX.

¿AX es realmente Kubernetes para agentes de IA?

Es una analogía útil, no un sustituto de Kubernetes. El harness gestiona razonamiento y decisiones sobre herramientas. AX gestiona declaraciones y ciclos de vida de tareas. Agent Substrate ejecuta los entornos aislados, mientras Kubernetes administra la infraestructura de workers.

El servidor actual de AX reconcilia directamente con Substrate mediante bloqueos distribuidos y guarda el estado de los recursos en Redis. No crea un recurso personalizado de Kubernetes por cada tarea breve. Su diseño también define expresamente las tareas como inmutables. Diseño actualizado del plano de control de AX.

La referencia del README a miles de millones de tareas es un objetivo de diseño. No demuestra que tu clúster ejecute miles de millones de agentes activos a la vez. Dimensiona por concurrencia activa, tamaño del estado, latencia del modelo y picos de carga. Para bucles de razonamiento, herramientas y feedback, consulta la guía de ingeniería de agent harness.

¿Qué sobrevive a la suspensión y reanudación de AX?

Según el runner documentado de AX, sobreviven los archivos del workspace; el comando vuelve en un proceso nuevo. Tanto detener como suspender envía SIGTERM al PID 1. El runner propaga la señal para que el comando guarde su estado. Ese cierre ordenado no equivale a perder una máquina en mitad de una llamada. El contrato fijado del runner explica persistencia y cierre.

Haz que los reintentos sean idempotentes: asigna una identidad persistente a cada operación para que repetir la solicitud no repita silenciosamente su efecto. Registra además un resultado explícito de éxito o error. Ready, WorkspaceReady y un runner sano no sustituyen un entregable aceptado.

Hay que distinguir las capas. Agent Substrate describe instantáneas completas que conservan RAM y sistema de archivos, y muestra unos 250 actores compartiendo ocho pods. Eso no sustituye el contrato específico del runner de AX. Prueba exactamente la pareja de runner y backend prevista. Capacidades de instantáneas, demostración y despliegue de Substrate.

¿Reanudar en menos de un segundo significa cero arranque en frío y cero coste ocioso?

No. Activarse rápido es una afirmación de latencia, no una garantía sobre toda la factura. El README de Substrate informa de reanudaciones por debajo de 500 ms y más de 500 activaciones de suspensión/reanudación por segundo. Son capacidades comunicadas por el proyecto, no un benchmark de Wavect ni una promesa para cualquier carga de AX.

El primer arranque, la falta de workers, una instantánea grande, la instalación de dependencias o una respuesta lenta del modelo todavía pueden retrasar el trabajo útil. Mide tanto el tiempo hasta estar listo como el tiempo hasta el primer resultado útil, incluida la latencia p95.

Liberar CPU y RAM de un actor suspendido puede mejorar el uso de la flota. No hace gratuitos los pools de workers, Redis, el almacenamiento de instantáneas, la red o la operación. Una solicitud de modelo ya admitida puede seguir generando cargos mientras el agente local espera. Capacidad ociosa y tokens son partidas distintas.

También hay que separar comandos de automatización. AX documenta ax suspend y ax resume. La detección de inactividad y suspensión automáticas siguen en la hoja de ruta, junto con presupuestos de tokens, tiempos máximos y políticas de aprobación. Un comando existente no demuestra una política automática activa. Comprueba qué capacidades de AX siguen en la hoja de ruta.

¿Cuánto puede ahorrar una recuperación mejor?

Mide el trabajo repetido tras la interrupción, no todo el trabajo original. Un checkpoint útil puede reducir repeticiones. No devuelve el dinero de la inferencia consumida, y una función de suspensión no demuestra recuperación ante fallos abruptos.

Supongamos un mes con 1.000 trabajos. El 10 % sufre exactamente una interrupción. Si cada trabajo afectado repite 30 dólares de llamadas a modelos y herramientas, la repetición cuesta 3.000 dólares. Si la recuperación probada reduce ese trabajo a 3 dólares, el coste baja a 300 dólares. Son 2.700 dólares de repetición evitada, no un ahorro garantizado por instalar AX.

Si la ejecución adicional, las instantáneas y la operación suman 600 dólares, el escenario deja 2.100 dólares antes de otros costes que hayan cambiado. Son supuestos ilustrativos en USD, no tarifas de proveedores ni resultados de clientes. La mejora debe probarse con fallos abruptos, no deducirse de una pausa correcta.

La metodología completa, incluida la revisión humana y los resultados aceptados, está en nuestra guía de coste por acción de agentes de IA. Este artículo se centra en repeticiones y recuperación relacionadas con el ciclo de vida de AX.

¿Cómo probar la recuperación de archivos en AX sin gastar tokens?

Empieza con un workspace desechable y un proceso inocuo que espera. El ejemplo usa los campos actuales del manifiesto. No incluye llamadas al modelo, credenciales de repositorios ni preparación basada en objetivos. Sí consume infraestructura. Contrasta el ejemplo con la referencia actual de manifiestos.

Necesitas una instalación compatible de AX/Substrate, la CLI y acceso autorizado al clúster. Guarda el ejemplo como task.yaml. debug: true es deliberado para esta tarea aislada de diagnóstico: SSH permite ejecutar comandos y acceder a archivos. No es una configuración predeterminada para producción ni exposición pública.

apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: recovery-lab
spec:
  files:
    - path: README.txt
      content: "Disposable recovery test. No model calls."
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: recovery-lab-001
spec:
  workspaces:
    - name: recovery-lab
      path: /workspace/recovery-lab
  command: ["python3", "-c", "import time; time.sleep(3600)"]
  debug: true

Aplica el manifiesto y espera a que Ready sea verdadero. Detén la observación continua con Ctrl+C. Eso cierra el watch, no la tarea.

ax apply -f task.yaml
ax watch task recovery-lab-001

Escribe el marcador después del arranque y luego suspende y reanuda. El comando de la tarea no vuelve a crear el archivo. Leerlo después comprueba persistencia, no una inicialización repetida.

ax ssh recovery-lab-001 -- sh -c 'printf "%s\n" "checkpoint-before-suspend" > /workspace/recovery-lab/recovery-marker.txt'
ax suspend task recovery-lab-001
ax resume task recovery-lab-001
ax watch task recovery-lab-001

Espera de nuevo a Ready, detén el watch con Ctrl+C y lee el marcador:

ax ssh recovery-lab-001 -- cat /workspace/recovery-lab/recovery-marker.txt

El resultado esperado es checkpoint-before-suspend. Superar esta prueba demuestra que ese archivo sobrevivió a una suspensión y reanudación ordenadas. No demuestra restauración de RAM, durabilidad ante fallos abruptos ni reintentos seguros de acciones externas. No hemos ejecutado aquí esta prueba de clúster.

Copia las evidencias que necesites y borra únicamente los recursos desechables creados arriba. Estos comandos eliminan la tarea de prueba y su definición de workspace:

ax delete task recovery-lab-001
ax delete workspace recovery-lab

¿Dónde se controla la red tras retirar AX Gateway?

No sigas aplicando el ejemplo antiguo de AX Gateway. El esquema revisado de Task no tiene un enlace gateway. Diseña restricciones de salida en la capa real de ejecución o red y comprueba que se aplican al actor de la tarea.

La documentación actual de Substrate describe HTTP(S) controlado por políticas, restricciones DNS y bloqueo de WebSocket, CONNECT de proxy directo y otro tráfico TCP. Es un contrato de protocolos que debes contrastar con tu versión instalada, no un atajo de YAML de AX. Importa cuando un SDK o transporte MCP presupone conexiones que el runtime no permite. Revisa las reglas de tráfico de salida de Substrate.

Prueba endpoints permitidos, destinos bloqueados, redirecciones, acceso directo al proveedor y revocación de credenciales. Mantén autorización por solicitud en los servidores permitidos: un hostname autorizado no concede acceso a todos sus clientes o documentos. Son comprobaciones propuestas, no vulnerabilidades reproducidas por nosotros. La lista de seguridad para entornos aislados de agentes cubre el perímetro más amplio.

¿AX detiene automáticamente una factura de tokens descontrolada?

El esquema revisado de Task no declara un límite acumulado de dinero o tokens. UsageStats y PendingApproval no demuestran control efectivo de presupuesto. Los límites de CPU tampoco limitan la factura de un modelo remoto.

Utiliza una capa independiente que autorice las llamadas al modelo. Vincula preparación, subtareas y reintentos a un identificador persistente del trabajo. Reserva presupuesto antes de admitir llamadas concurrentes, concilia el consumo después y bloquea nuevas admisiones al llegar al límite. Las solicitudes ya admitidas aún pueden generar cargos. Define un exceso acotado en lugar de prometer una parada instantánea sin sobrecoste.

El componente que revoca credenciales o bloquea solicitudes debe estar fuera del workspace modificable por el agente. Un prompt que le pide respetar un presupuesto no es un control de gasto.

¿Puedes alojar AX sin Google Cloud?

Existe una ruta de desarrollo sin GCP, pero la portabilidad en producción necesita su propia prueba. Substrate documenta quickstarts locales con kind y también en GKE. AX requiere una API de control de Substrate accesible, su propio plano de control con Redis e imágenes de runner adecuadas. Ejecutar localmente no implica inferencia local.

El README actual de Substrate describe un proyecto anterior a la versión 1.0 sin garantías de compatibilidad hacia atrás. AX avisa de cambios importantes incompatibles y su hoja de ruta aún incluye migración a la API de actores de Substrate. Selecciona versiones probadas juntas, no simplemente la revisión más reciente de cada proyecto.

¿Antigravity es obligatorio en todas las tareas?

No. El runner predeterminado documentado llama a Antigravity cuando un workspace enlazado tiene un goal. Esa ruta requiere GEMINI_API_KEY y un tiempo de preparación máximo de diez minutos por defecto, configurable con AX_BOOTSTRAP_TIMEOUT. Un entorno preparado sin goal evita esa ruta concreta. La misma documentación coloca los metadatos en loopback e indica usar AX_METADATA_URL. Contrato actual de arranque y metadatos dentro de la sandbox.

¿Y Pi u otro harness personalizado?

Trátalo como una integración pendiente de validar, no como un adaptador listo confirmado por este análisis. La imagen debe incluir /usr/local/bin/ax-task-runner, leer AX_TASK_YAML y AX_WORKSPACES_YAML, preparar workspaces persistentes, informar de disponibilidad y supervisar el cierre. Verifica por separado dónde guarda la sesión el harness y cómo la recupera.

Tener el repositorio es solo una parte de controlar tu IA. Debes poder inspeccionar la ejecución, exportar el estado, elegir proveedores de inferencia, revocar permisos y abandonar el despliegue. La ubicación en una nube no resuelve por sí sola esas preguntas.

¿Qué debe demostrar un piloto de AX antes de producción?

Empieza con tareas sintéticas y sistemas desechables. Son criterios de aceptación propuestos por nosotros, no pruebas que AX haya superado en nuestro entorno.

Registra revisiones AX/Substrate, digest del runner, ruta del modelo, políticas y resultados de cada ejecución. Elige AX cuando las mejoras medidas de capacidad y recuperación justifiquen operar la plataforma. Una flota pequeña con trabajos breves y baratos quizá todavía no necesite esta infraestructura adicional.

Los servicios de ingeniería de IA de Wavect cubren integración y preparación para producción. El caso Twinsoft AI demuestra experiencia de entrega independiente, no un despliegue de referencia de AX. Utiliza la lista de QA antes del lanzamiento para organizar las evidencias o hablemos de los costes de reinicio y requisitos de tu runtime de agentes.