Esta página es una traducción de la documentación en inglés. Los comandos, identificadores y ejemplos no cambian. Runtime 7.24.4 · SDK 2.6.7. Original en inglés

Modo de bucle y tareas programadas

Estado: Activo Alcance: estado actual Última revisión: 2026-08-27 Responsable: runtime de ax-code

AX Code tiene tres primitivas de automatización que se pueden componer:

/loop: prompts recurrentes

/loop <interval> <prompt>   start (interval like 30s, 5m, 1h)
/loop status                show runs, busy-skips, and the prompt
/loop stop                  stop the loop

Ejemplos:

/loop 5m check CI for new failures and fix any you find
/loop 30m drain the review queue

Reglas:

• Límites del intervalo: de 30 segundos a 24 horas. Un bucle por sesión: iniciar uno nuevo sustituye al anterior.
• Un tic que se dispara mientras la sesión está ocupada se omite y se cuenta, y nunca se encola: los bucles no pueden acumular turnos.
• Cada tic es un turno de prompt ordinario: se aplican permisos, preguntas, topes autónomos y compuertas de finalización. Con la autonomía desactivada, un tic simplemente se detiene en el primer aviso de permiso.
• Techo duro de 500 ejecuciones por bucle; después el bucle se detiene solo con un aviso.
• Los bucles viven solo en el proceso de backend: no sobreviven a un reinicio. Para programaciones duraderas, usa las tareas programadas de abajo.

Combinar /goal con /loop

/goal es dueño del objetivo («todas las pruebas en verde, sin hallazgos de revisión abiertos»); /loop aporta el latido que sigue comprobando. Crear un objetivo primero ejecuta un redactor de plan dedicado que guarda un contrato revisable bajo .ax-code/goals/ (o el directorio de datos de AX cuando el proyecto no es un worktree de Git). Si la planificación falla, el objetivo permanece en pausa: /goal resume lo reintenta. Las comprobaciones de rango de Git que miden el diff de este objetivo usan el HEAD del momento del plan ({BASELINE}), no origin/main, salvo que el objetivo nombre ese remoto. La finalización del objetivo sigue condicionada a la verificación: el agente no puede marcar un objetivo como completo después de editar sin una ejecución de verificación superada, y cuando existe un plan también debe aportar evidencia de cada criterio de aceptación.

/goal keep main green: fix any CI failure the loop finds
/loop 10m check CI status and act on failures

El aseguramiento de objetivos es optativo

/goal <objective> empieza de inmediato: no adjunta un contrato de aceptación congelado, así que la finalización se juzga por el plan de trabajo que mantiene el agente (tareas pendientes) más una verificación superada después de su último cambio. /goal view (y «Ver detalles del objetivo» del diálogo del objetivo) lo dice de forma explícita — «Sin contrato de aseguramiento» — para que el estado nunca sea algo que tengas que inferir.

/goal --assure <objective> ejecuta primero el redactor del plan, que congela los criterios de aceptación, las referencias de fuente y las comprobaciones ejecutables; la finalización exige entonces también un recibo correcto y vigente de cada comprobación requerida (verify_project con su id goalCheck). Úsalo cuando el «hecho» del objetivo deba ser demostrable y no solo descrito.

--assure se combina con los indicadores de presupuesto en cualquier orden (/goal --assure --budget 500000 <objective>). /goal replace <objective> conserva el aseguramiento cuando el objetivo que se sustituye tiene un contrato válido, de modo que sustituir nunca puede debilitar en silencio un objetivo que ya estaba asegurado.

Presupuestos y techos del objetivo

Un objetivo activo eleva el tope de continuación automática por ejecución (session.max_continuations): la ejecución sigue hasta que el objetivo está completo, bloqueado, en pausa o limitado por el presupuesto. Lo que lo acota en su lugar:

• Presupuesto de tokens (/goal --budget N …): cuando se agota, el agente obtiene un turno de cierre y luego el objetivo pasa a budget_limited.
• Presupuesto de tiempo (/goal --time-budget 30m …): un límite de reloj en segundos, minutos (m) u horas (h), combinable con el presupuesto de tokens en cualquier orden. Acota el trabajo transcurrido que el presupuesto de tokens no ve: trabajos de entrenamiento remotos, llamadas largas a herramientas, atascos del proveedor. Se aplican el mismo turno de cierre y la transición budget_limited cuando se alcanza.
• Techo acumulado de pasos: las ejecuciones de un objetivo activo comparten el respaldo Super-Long de max_steps × 40 pasos en total (20,000 de forma predeterminada) en lugar del techo autónomo ordinario de max_steps × (max_continuations + 1). Anúlalo con session.max_total_steps.
• La detección de bucle destructivo, los topes de radio de impacto y el cortacircuitos de turnos solo de herramientas siguen aplicándose en todo momento.

CLI de objetivos (sin interfaz)

El mismo control de objetivos está disponible fuera de la TUI bajo ax-code goal:

• ax-code goal status [--json]: muestra el objetivo actual (-s/--session para elegir una sesión; de forma predeterminada usa el único objetivo reanudable del proyecto y da error cuando la elección sería ambigua).
• ax-code goal pause / ax-code goal clear: lo pausa o lo borra.
• ax-code goal resume: reanuda el objetivo y lo conduce sin interfaz hasta que se asienta. Sin --attach arranca el proyecto en el proceso; con --attach http://localhost:4111 conduce un servidor en ejecución. Los códigos de salida siguen el contrato de objetivo sin interfaz: 0 completo, 3 bloqueado, 4 limitado por presupuesto, 6 en pausa o no terminal, 1 error de sesión, 124 tiempo de espera inactivo (--idle-timeout-ms, 10 minutos de forma predeterminada). Los eventos se transmiten a stdout como JSONL (--event-log PATH también los registra), y una línea final Goal <status>: <objective> va a stderr.

Cuando una ejecución de objetivo se acerca al techo de pasos, el agente recibe un aviso único de convergencia que le indica verificar y completar el objetivo o dejar un relevo limpio. Si aun así se alcanza el techo, el objetivo queda en pausa — no fallido — y se puede retomar con /goal resume (sube session.max_total_steps antes si necesita más margen).

Tareas programadas: duraderas y conversacionales

Pídeselo directamente al agente; usa las herramientas schedule_task, list_scheduled_tasks y manage_scheduled_task:

• «Recuérdame a las 14:30 que revise el despliegue.»
• «Cada día laborable a las 9:00, resume los fallos nuevos de CI.»
• «Enumera mis tareas programadas.» / «Pausa la tarea de resumen de CI.»

Los cambios de programación creados y gestionados por el agente piden el permiso schedule. Una ejecución de solo lectura no puede cambiar ni disparar una programación. Para la creación sin interfaz y sin supervisión, usa el comando explícito ax-code schedule o configura una concesión explícita del permiso schedule para el agente; las concesiones amplias con comodín no autorizan cambios de programación.

Las mismas tareas se pueden gestionar desde el shell sin abrir la TUI:

ax-code schedule list                 # status, next run, schedule, id, title
ax-code schedule show <id>            # details plus the five most recent runs
ax-code schedule runs <id>            # run history: fired, failed, skipped and why
ax-code schedule pause|resume <id>
ax-code schedule delete <id>
ax-code schedule run <id>             # trigger now; requires a live runtime

pause/resume/delete pasan por el entorno de ejecución gestionado del proyecto cuando hay uno en marcha (efecto inmediato, actualizaciones en vivo de la TUI) y, si no, escriben la base de datos del proyecto directamente. run necesita un backend en vivo — inicia uno con ax-code runtime start — porque un proceso de CLI de un solo uso no debe reclamar trabajo que no pueda terminar. Todos los subcomandos de lectura aceptan --json.

Las programaciones admiten ejecuciones de una vez, horas diarias o semanales y expresiones cron de 5 campos, cada una con una zona horaria IANA opcional. Las tareas persisten en la base de datos del proyecto y se disparan mientras un backend de AX Code del proyecto está en ejecución (barrido del programador de 60 s, reclamación atómica: una tarea se dispara una vez aunque haya varios backends abiertos). El avance de la programación y la inserción en la cola duradera comparten una transacción de base de datos, así que un fallo no puede avanzar una ocurrencia sin dejar trabajo que recuperar. Los comandos de un solo uso como ax-code run y ax-code stats no reclaman las tareas vencidas. Inicia un backend persistente con ax-code runtime start para despacharlas.

Las ocurrencias perdidas usan de forma predeterminada catchUpPolicy: "run_once": después de una interrupción, AX Code fusiona cualquier cola pendiente en una ejecución. Usa "skip" cuando el trabajo obsoleto deba avanzar sin ejecutarse. Una tarea también puede definir maxRunDurationMs desde un segundo hasta 72 horas; una ejecución que agota el tiempo se cancela y se registra como fallida.

Para operar a través de reinicios del proceso y del host, ejecuta el backend bajo un supervisor. Consulta Operaciones de larga duración para ejemplos de systemd, launchd y PM2, más la semántica exacta de recuperación.

Ejecuciones largas sin supervisión

Para sesiones autónomas de varias horas, el modo Super-Long añade plazos de ejecución (hasta 72 h), ritmo de solicitudes y ajuste de la compactación. Se activa solo para los modelos cuyas capacidades declaradas admiten trabajo de agente largo (modelos de razonamiento de contexto 1M, como Qwen 3.7+ Max/Plus en rutas de Alibaba y GLM 5.x en rutas de z.ai) y se puede forzar por sesión, por proyecto o mediante AX_CODE_SUPER_LONG. La participación de la ejecución se registra (super-long run engaged), y el ritmo del proveedor solo empieza después de una ventana de gracia desde el inicio de la ejecución (2 horas de forma predeterminada, super_long.pacing_grace_minutes) para que la fase productiva inicial de una ejecución agéntica conserve el rendimiento completo de llamadas a herramientas; la cola de maratón se ritma según el nivel de límite de tasa declarado del modelo.