En este artículo
Google AX Agent Executor: presupuesto y autoalojamiento
Una sandbox puede contener al agente sin contener su factura. Esa es la distinción fundamental antes de adoptar AX de Google, el Agent Executor. Dar al agente un espacio de trabajo y restringir la red resulta útil. Demostrar que no puede exceder el presupuesto, repetir una acción perjudicial o dejar su estado inaccesible es otro problema de ingeniería.
AX es un proyecto de orquestación con licencia Apache 2.0 alojado en la organización de Google en GitHub. Su interfaz actual utiliza cuatro tipos de recursos: Task, Workspace, Gateway y Model. El repositorio advierte expresamente que puede introducir cambios importantes e incompatibles antes de una versión estable. Consulta el repositorio de AX y su estado de desarrollo.
Fuentes revisadas el , con AX en el commit d8ed0fe38bce. Este artículo es una revisión de fuentes y arquitectura, no una prueba de despliegue ni de rendimiento. La pregunta es concreta: ¿qué debes verificar para ejecutar agentes con AX bajo tu propio control operativo?
¿Qué controlan realmente las cuatro primitivas declarativas de AX?
AX separa el entorno de ejecución del razonamiento del agente. Una tarea puede ejecutar un agente, una operación delegada u otro programa. Un workspace describe el entorno inicial; un gateway define el acceso a la red; un recurso model centraliza la configuración del proveedor.
| Primitiva | Responsabilidad declarada | No equivale a |
|---|---|---|
| Task | Imagen, comando, recursos de CPU y memoria, referencias al workspace y al gateway. | Un presupuesto acumulado de tokens o una prueba del éxito de la tarea de negocio. |
| Workspace | Repositorios Git, configuración MCP, skills y preparación opcional basada en un objetivo. | Persistencia automática de todos los archivos de sesión, secretos y efectos externos. |
| Gateway | Listeners y lista de destinos de salida permitidos por host y puerto. | Autorización por herramienta, cliente o documento. |
| Model | Proveedor, identificador del modelo, parámetros de generación y referencia a un secreto de Kubernetes. | Pesos de un modelo, inferencia local o configuración universal de cualquier SDK de agentes. |
Esas son las funciones descritas en la documentación de conceptos de AX. En particular, Model es una configuración con nombre, no un nuevo modelo de lenguaje. Los componentes de AX pueden consumirla; un programa arbitrario dentro de la tarea sigue necesitando una integración compatible.
¿AX es un framework de agentes, una sandbox o un sustituto de Kubernetes?
AX es la capa de orquestación sobre Agent Substrate, no un sustituto del ciclo de decisiones del agente. Su API y sus controladores gestionan recursos; Agent Substrate proporciona el ciclo de ejecución subyacente. Kubernetes sigue formando parte de la infraestructura.
El YAML parecido al de Kubernetes puede confundir: el diseño de AX guarda el estado de los recursos en Redis y distribuye el trabajo de reconciliación mediante Redis Streams. No almacena cada tarea efímera como un recurso personalizado de Kubernetes. Los controladores pueden escalar añadiendo réplicas. Revisa la arquitectura del plano de control.
Es una estrategia arquitectónica para gestionar muchas tareas, no una demostración de que tu clúster ejecutará miles de millones de agentes activos. La capacidad depende del trabajo, los recursos de los workers, el almacenamiento, la latencia del modelo y los límites operativos. Considera las afirmaciones de escala del proyecto como un objetivo de diseño hasta medir tu propio entorno con una carga representativa.
Nuestra guía de ingeniería del harness de agentes explica el ciclo de razonamiento, las herramientas y la retroalimentación alrededor del modelo. Aquí nos centramos en los límites de ejecución y control de AX.
¿Cómo restringir las conexiones salientes de Google AX?
Vincula la tarea a un Gateway con destinos explícitos y comprueba después la restricción efectiva. El ejemplo documentado incluye host: "*" en el puerto 443. Eso permite acceso HTTPS amplio; no es una configuración de producción limitada a tus servidores de modelos y Git. Consulta los ejemplos actuales de manifiestos.
Este Gateway es ilustrativo, no un despliegue completo. Sustituye el hostname de ejemplo por un endpoint controlado por el operador que la sandbox pueda resolver y alcanzar. La infraestructura se aprovisiona por separado.
apiVersion: ax.io/v1alpha1
kind: Gateway
metadata:
name: research-egress
spec:
egress:
allowlist:
hosts:
- host: llm-gateway.internal.example
port: 443Añade la siguiente referencia al spec de la tarea existente. Un recurso Gateway que nadie utiliza en el plano de control no restringe esa tarea.
gateway:
name: research-egress
debug: falseRecomendamos exigir GatewayReady, comprobar destinos denegados y mantener debug: false salvo durante una sesión de diagnóstico controlada. Prueba redirecciones, acceso directo al proveedor, endpoints internos de metadatos y rutas de red alternativas. Son pruebas de aceptación, no vulnerabilidades que hayamos reproducido en AX.
Un hostname permitido sigue representando un límite de confianza amplio. Un servidor de herramientas autorizado puede atender a varios clientes o realizar sus propias conexiones salientes. Mantén la autorización por solicitud en ese servidor y verifica también los destinos posteriores. Utiliza nuestra checklist de seguridad para sandboxes de agentes para la revisión general de aislamiento.
¿Google AX detiene automáticamente el gasto descontrolado de tokens?
No presupongas que la API Task actual impone un límite acumulado de tokens o dinero. En el esquema revisado, el campo 9 de TaskSpec, antes denominado policies para configurar presupuestos y aprobaciones, está reservado y descrito expresamente como retirado por ahora. Permanecen los contadores de UsageStats y el tipo de estado PendingApproval, pero un tipo o un contador no demuestra que exista un mecanismo de bloqueo. Examina el esquema de AX fijado al commit revisado.
Los límites de CPU y memoria restringen el cómputo local. No limitan cuántas solicitudes de pago puede enviar un bucle que consume poca CPU. Del mismo modo, el máximo de salida por respuesta no limita el coste agregado de reintentos, subtareas paralelas y llamadas repetidas. Tampoco debes asumir que existe una aprobación de negocio obligatoria solo porque aparece un campo de estado relacionado con aprobaciones.
Google Cloud también distingue los presupuestos de solo alertas de los controles de gasto: un presupuesto de solo alertas no interrumpe automáticamente el uso ni los cargos. Su documentación señala por separado presupuestos con límites de gasto en versión preliminar para servicios compatibles. Ninguno de estos hechos demuestra un límite por trabajo para todos los modelos externos a los que puede llamar tu agente. Lee la distinción en la documentación de Cloud Billing.
Coloca el presupuesto donde el agente no pueda modificarlo
Recomendamos un proxy de modelos controlado por el operador y un registro de presupuesto compartido por el trabajo principal y todos sus descendientes. Antes de admitir una solicitud, reserva atómicamente su coste máximo acotado. Concilia el consumo real después, contabiliza reintentos y llamadas paralelas, y rechaza nuevas solicitudes cuando el saldo sea insuficiente. Las credenciales de control y el registro deben quedar fuera del entorno que el agente puede escribir.
Añade un tiempo máximo de ejecución, límites de reintentos, pasos y subtareas paralelas, además de detección de acciones repetidas. Al alcanzar el umbral, bloquea nuevas llamadas y activa cancelación o suspensión. Las solicitudes ya admitidas pueden seguir generando cargos: define y prueba el exceso máximo en lugar de prometer una parada instantánea sin coste. Incluye el agente que prepara el workspace, no solo el comando final.
Para analizar la economía general, además del control específico de AX, consulta el coste por acción de un agente de IA.
¿Qué se conserva al suspender y reanudar una tarea de AX?
El contrato del runner de AX revisado describe un workspace restaurado y un árbol de procesos nuevo. Identifica /workspace como directorio persistente y explica que la reanudación lo restaura en un contenedor nuevo. No interpretes esto como una garantía de conservar intactos los objetos de Python, las conexiones o la memoria todavía no guardada. Consulta el ciclo de vida y el contrato de sustitución del runner.
La afirmación se refiere a la integración documentada del runner de AX, no a la capacidad máxima de snapshots de todos los backends de Agent Substrate. La aceptación debe comprobar la capa que realmente utiliza tu aplicación.
Guarda la conversación o el punto de control de la sesión, los identificadores de operaciones completadas y las instrucciones de reinicio en la ruta persistente. Reanuda mediante el mecanismo de sesiones que admita el agente. Un snapshot del sistema de archivos no deshace un correo enviado o un pago solicitado: las escrituras externas necesitan claves de idempotencia y un registro duradero de finalización.
Una sandbox lista no implica un trabajo de negocio terminado
El mismo contrato indica que el runner sigue vivo cuando termina el comando y que el plano de control no recupera actualmente su código de salida. Supervisa un evento explícito de finalización o un artefacto de resultado, no únicamente Running, Ready o un endpoint de salud que responde. Prueba tanto un comando exitoso como uno fallido.
¿Se puede autoalojar Google AX sin GCP?
Las rutas disponibles no son exclusivamente GCP, pero portabilidad no significa instalación inmediata. El inicio rápido de AX requiere Kubernetes, un registro de contenedores, Redis y una API de control de Agent Substrate accesible. Agent Substrate documenta una instalación local de desarrollo con kind y otra sobre GKE que utiliza recursos de Google Cloud. También advierte que está en desarrollo temprano, no preparado para producción y que no es un producto con soporte oficial de Google. Compara las instrucciones locales y de GKE de Agent Substrate.
El inicio rápido local de Substrate demuestra una ruta de desarrollo sin GCP para la ejecución subyacente. No prueba un despliegue integral en tus instalaciones que incluya AX, tu almacenamiento y tu configuración de seguridad. Además, ejecutar localmente el agente no convierte en local la inferencia de un proveedor remoto.
| Capa | Qué verificar | Evidencia de control |
|---|---|---|
| Ejecución | ¿Quién administra Kubernetes, AX, Substrate y las imágenes? | Puedes reconstruir, desplegar, aislar y detener una tarea sin su colaboración. |
| Inferencia | ¿Qué proveedor recibe los prompts durante la preparación y la ejecución? | Destinos registrados y una alternativa de proveedor o modelo local probada. |
| Estado | ¿Dónde se guardan workspaces, sesiones, snapshots y registros? | Exportación y restauración satisfactorias bajo tu política de conservación. |
| Autoridad | ¿Quién controla los secretos, la admisión de gasto y los permisos de herramientas? | Pruebas de revocación y denegación fuera del entorno modificable por el agente. |
Esa es nuestra definición operativa de «ser dueño de tu IA». Un despliegue en la nube puede conservar un control significativo; el autoalojamiento puede seguir dependiendo de un modelo, registro o servicio de credenciales externo. Elige conscientemente el equilibrio, sin sustituir el análisis de amenazas por la ubicación del servidor.
¿Hasta qué punto depende AX de Antigravity?
La dependencia concreta está en la preparación del workspace basada en un objetivo. El runner predeterminado entrega ese objetivo a un agente Antigravity, necesita GEMINI_API_KEY para ese paso y documenta un plazo de preparación de diez minutos, configurable mediante AX_BOOTSTRAP_TIMEOUT. Ese plazo no es un presupuesto para toda la vida del trabajo. Revisa la secuencia documentada de arranque de la sandbox.
Esto aporta más que afirmar que todo el proyecto fue «programado con Antigravity». La documentación de ejecución demuestra cómo se utiliza durante la preparación, no cómo se escribió cada archivo del repositorio.
Para un entorno más controlado, evalúa una imagen preparada de antemano y omite el bootstrap basado en objetivos, o implementa un runner propio compatible. AX exige un ejecutable en /usr/local/bin/ax-task-runner; indicar cualquier imagen de agente no basta. Antes de sustituirlo, comprueba endpoints de disponibilidad, propagación de señales y gestión del estado persistente conforme al contrato del runner.
¿Puede un agente de programación Pi utilizar el modelo de ejecución de AX?
Pi documenta modos interactivo, print/JSON, RPC y SDK. Son posibles superficies de integración, pero no demuestran que exista un adaptador AX listo para usar. Consulta la documentación del harness de programación Pi.
Un experimento razonable sería empaquetar Pi detrás de un runner compatible con AX, iniciarlo mediante spec.command, dirigir las llamadas al modelo a través del control externo de presupuesto y conservar sesiones reanudables en /workspace. Es un diseño de integración propuesto, no una configuración desplegada por nosotros ni una integración oficial verificada aquí.
También puedes adoptar esta separación sin incorporar AX: declarar el workspace, aislar la ejecución, imponer las restricciones de red fuera del proceso y mantener credenciales y reglas presupuestarias bajo control del operador. El valor está en el límite de control, no en copiar una implementación ligada a una nube.
¿Qué debe demostrar un piloto de AX antes de recibir credenciales reales?
Empieza con un repositorio prescindible, datos sintéticos y una credencial de modelo con privilegios mínimos. Los siguientes son nuestros criterios de aceptación, no afirmaciones de que el proyecto ya los cumpla.
| Prueba | Condición de éxito |
|---|---|
| Denegación de red | La tarea alcanza el proxy declarado; fallan un destino no autorizado y la conexión directa al proveedor. |
| Presupuesto agotado | Un trabajo deliberadamente repetitivo deja de admitir llamadas al alcanzar el límite compartido; el exceso por concurrencia queda acotado. |
| Suspensión y reanudación | La sesión continúa desde el estado persistente sin repetir una acción externa ya completada. |
| Finalización y fallo | Ambos resultados llegan al supervisor del trabajo, aunque el runner continúe respondiendo correctamente. |
| Revocación de credenciales | Retirar la autoridad de la tarea bloquea nuevas operaciones privilegiadas sin pedir colaboración al agente. |
| Portabilidad | El workspace y la sesión exportados se restauran en el despliegue alternativo que realmente piensas utilizar. |
Registra las revisiones de AX y Substrate, el digest de la imagen del runner, la ruta activa del modelo, la política del gateway y los resultados observados. Conserva una vía de reversión mientras cambian las API. Un experimento pequeño que supera las pruebas vale más que una promesa no verificada sobre una flota completa.
Los servicios de ingeniería de IA de Wavect abarcan implementación y preparación para producción. El caso de Twinsoft AI muestra experiencia de implementación independiente, no un despliegue de referencia de AX. Utiliza nuestra checklist de QA antes del lanzamiento para convertir el piloto en evidencias de aceptación, o coméntanos tus requisitos de ejecución y control de agentes.
Google AX: preguntas prácticas antes del despliegue
¿Qué es Google AX Agent Executor?
AX es un proyecto abierto de orquestación para ejecutar agentes en entornos aislados. Utiliza recursos Task, Workspace, Gateway y Model sobre Agent Substrate. No es un nuevo modelo de lenguaje ni sustituye el ciclo de razonamiento del agente.
¿AX impone un presupuesto acumulado de tokens?
No lo presupongas a partir de la API actual. En el commit revisado se retiró el campo policies de Task para presupuestos y aprobaciones. Los contadores de uso no imponen un límite. Una capa independiente debe controlar el trabajo completo, incluidas preparación y subtareas.
¿El Gateway de ejemplo de AX está restringido?
El ejemplo documentado permite todos los hostnames en el puerto 443. Sustitúyelos por destinos explícitos, vincula el Gateway a la tarea y verifica rutas denegadas. Permitir un host no sustituye la autorización por solicitud en un servidor de herramientas.
¿AX reanuda exactamente el estado en memoria del agente?
El contrato del runner revisado describe la restauración del workspace persistente en un contenedor nuevo con un árbol de procesos nuevo. Guarda sesiones reanudables y operaciones completadas de forma explícita. Esto no describe todas las capacidades de snapshots de los backends Substrate.
¿Puede funcionar AX sin Google Cloud?
Agent Substrate documenta un entorno local de desarrollo con kind además del despliegue GKE. AX sigue necesitando su plano de control y una API Substrate accesible. Es una opción de desarrollo sin GCP, no una instalación de producción verificada en cualquier infraestructura.
¿Antigravity es obligatorio para todas las tareas de AX?
El runner predeterminado documentado utiliza Antigravity para preparar workspaces a partir de objetivos. Puedes evaluar un entorno preconstruido sin ese paso o un runner compatible propio. El reemplazo debe cumplir el contrato de AX, no limitarse a incluir un agente ejecutable.
¿Puede ejecutarse un agente Pi dentro de AX?
Pi ofrece modos de integración print/JSON, RPC y SDK. Empaquetarlo detrás de un runner compatible es una propuesta, no un adaptador oficial listo para usar verificado aquí. Comprueba sesiones, rutas de modelos, presupuestos y señales antes de utilizar credenciales reales.
¿El código abierto implica ser dueño de todo el sistema de IA?
No. Verifica ejecución, inferencia, estado y autoridad por separado. Controlar significa poder inspeccionar, exportar, revocar y detener. Un runtime autoalojado puede seguir usando modelos remotos o servicios de credenciales controlados por terceros.
Reflexiones finales
Controla los mecanismos, no solo una copia del repositorio. AX ofrece límites de ejecución útiles; la admisión de gasto, el estado recuperable, la finalización fiable y una vía de salida necesitan evidencias propias. Empieza con un piloto pequeño que pueda demostrar esas propiedades.