Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Mode boucle et tâches planifiées

Statut : actif Portée : état actuel Dernière revue : 2026-08-27 Responsable : runtime AX Code

AX Code dispose de trois primitives d’automatisation composables :

/loop — invites récurrentes

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

Exemples :

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

Règles :

• Bornes d’intervalle : 30 secondes à 24 heures. Une boucle par session — en démarrer une nouvelle remplace l’ancienne.
• Un tic qui se déclenche pendant que la session est occupée est ignoré et compté, jamais mis en file — les boucles ne peuvent pas empiler des tours.
• Chaque tic est un tour d’invite ordinaire : permissions, questions, plafonds du mode autonome et barrières d’achèvement s’appliquent tous. Mode autonome désactivé, un tic s’arrête simplement à la première demande de permission.
• Plafond dur de 500 exécutions par boucle, puis la boucle s’arrête d’elle-même avec un avis.
• Les boucles ne vivent que dans le processus de backend : elles ne survivent pas à un redémarrage. Pour des planifications durables, utilisez les tâches planifiées ci-dessous.

Associer /goal et /loop

/goal porte l’objectif (« tous les tests au vert, aucun constat de revue encore ouvert ») ; /loop fournit le battement qui continue de vérifier. Créer un objectif lance d’abord un rédacteur de plan dédié, qui enregistre un contrat révisable sous .ax-code/goals/ (ou dans le répertoire de données AX lorsque le projet n’est pas un worktree Git). Si la planification échoue, l’objectif reste en pause — /goal resume la relance. Les contrôles de plage Git qui mesurent le diff de cet objectif utilisent le HEAD du moment du plan ({BASELINE}), et non origin/main, sauf si l’objectif nomme ce remote. L’achèvement de l’objectif reste soumis à la vérification : l’agent ne peut pas marquer un objectif comme terminé après des modifications sans une exécution de vérification réussie, et lorsqu’un plan existe il doit aussi fournir une preuve pour chaque critère d’acceptation.

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

L'assurance d'objectif est sur activation

/goal <objective> démarre tout de suite : il n’attache aucun contrat d’acceptation figé, donc l’achèvement se juge d’après le plan de travail que l’agent maintient (tâches en attente) plus une vérification réussie après son dernier changement. /goal view (et « Voir le détail de l’objectif » dans le dialogue d’objectif) le dit explicitement — « Aucun contrat d’assurance » — afin que cet état ne soit jamais à déduire.

/goal --assure <objective> exécute d’abord le rédacteur de plan, qui fige les critères d’acceptation, les références de source et les contrôles exécutables ; l’achèvement exige alors aussi un reçu réussi et à jour pour chaque contrôle requis (verify_project avec son identifiant goalCheck). Utilisez-le lorsque le « terminé » de l’objectif doit être prouvable plutôt que seulement décrit.

--assure se combine avec les indicateurs de budget dans un ordre ou dans l’autre (/goal --assure --budget 500000 <objective>). /goal replace <objective> conserve l’assurance lorsque l’objectif remplacé possède un contrat valide, de sorte qu’un remplacement ne peut jamais affaiblir en silence un objectif déjà assuré.

Budgets et plafonds d'objectif

Un objectif actif lève le plafond de continuation automatique par exécution (session.max_continuations) — l’exécution continue jusqu’à ce que l’objectif soit terminé, bloqué, en pause ou limité par le budget. Ce qui le borne à la place :

• Budget de jetons (/goal --budget N …) : une fois épuisé, l’agent obtient un tour de clôture, puis l’objectif passe à budget_limited.
• Budget de temps (/goal --time-budget 30m …) : une limite de temps horloge en secondes, en minutes (m) ou en heures (h), combinable avec le budget de jetons dans un ordre ou dans l’autre. Il borne le travail écoulé que le budget de jetons ne voit pas — tâches d’entraînement distantes, appels d’outils longs, blocages de fournisseur. Le même tour de clôture et la transition budget_limited s’appliquent lorsqu’il se déclenche.
• Plafond cumulé d’étapes : les exécutions d’un objectif actif partagent le filet Super-Long de max_steps × 40 étapes au total (20,000 par défaut) au lieu du plafond autonome ordinaire de max_steps × (max_continuations + 1). Remplacez-le avec session.max_total_steps.
• La détection de boucle fatale, les plafonds de rayon d’impact et le coupe-circuit des tours seulement-outils s’appliquent toujours jusqu’au bout.

CLI d'objectif (sans interface)

Le même pilotage d’objectif est disponible hors du TUI, sous ax-code goal :

• ax-code goal status [--json] — affiche l’objectif courant (-s/--session pour choisir une session ; par défaut, l’unique objectif reprenable du projet, avec une erreur si le choix serait ambigu).
• ax-code goal pause / ax-code goal clear — le met en pause ou l’efface.
• ax-code goal resume — reprend l’objectif et le pilote sans interface jusqu’à ce qu’il se stabilise. Sans --attach, il amorce le projet dans le processus ; avec --attach http://localhost:4111, il pilote plutôt un serveur déjà lancé. Les codes de sortie suivent le contrat d’objectif sans interface : 0 terminé, 3 bloqué, 4 limité par le budget, 6 en pause ou non terminal, 1 erreur de session, 124 délai d’inactivité (--idle-timeout-ms, 10 minutes par défaut). Les événements sont diffusés sur stdout en JSONL (--event-log PATH les enregistre aussi), et une ligne finale Goal <status>: <objective> part sur stderr.

Lorsqu’une exécution d’objectif approche du plafond d’étapes, l’agent reçoit un avertissement de convergence unique : vérifier et terminer l’objectif, ou laisser une passation propre. Si le plafond est tout de même atteint, l’objectif est en pause — pas en échec — et peut être repris avec /goal resume (augmentez session.max_total_steps d’abord s’il faut davantage de marge).

Tâches planifiées — durables et conversationnelles

Demandez directement à l’agent ; il utilise les outils schedule_task, list_scheduled_tasks et manage_scheduled_task :

• « Rappelle-moi à 14:30 de vérifier le déploiement. »
• « Chaque jour ouvré à 9 h, résume les nouveaux échecs de CI. »
• « Liste mes tâches planifiées. » / « Mets en pause la tâche de résumé CI. »

Les changements de planification créés ou gérés par l’agent demandent la permission schedule. Une exécution en lecture seule ne peut ni modifier ni déclencher une planification. Pour une création sans surveillance et sans interface, utilisez la commande explicite ax-code schedule ou configurez un octroi de permission explicite schedule pour l’agent ; les octrois génériques à joker n’autorisent pas les changements de planification.

Les mêmes tâches se gèrent depuis le shell sans ouvrir le 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 passent par le runtime géré du projet lorsqu’il tourne (effet immédiat, mises à jour du TUI en direct) et, sinon, écrivent directement la base du projet. run a besoin d’un backend vivant — démarrez-en un avec ax-code runtime start — car un processus CLI ponctuel ne doit pas revendiquer un travail qu’il ne peut pas finir. Toutes les sous-commandes de lecture acceptent --json.

Les planifications acceptent les exécutions ponctuelles, les heures quotidiennes ou hebdomadaires, et les expressions cron à 5 champs, chacune avec un fuseau IANA facultatif. Les tâches restent dans la base du projet et se déclenchent tant qu’un backend AX Code du projet tourne (balayage du planificateur toutes les 60 s, revendication atomique — une tâche ne part qu’une fois, même si plusieurs backends sont ouverts). L’avancement de la planification et l’insertion dans la file durable partagent une seule transaction de base, de sorte qu’un plantage ne peut pas avancer une occurrence sans laisser du travail à reprendre. Les commandes ponctuelles telles que ax-code run et ax-code stats ne revendiquent pas les tâches échues. Démarrez un backend persistant avec ax-code runtime start pour les répartir.

Les occurrences manquées prennent par défaut catchUpPolicy: "run_once" : après un arrêt, AX Code rassemble tout l’arriéré en une seule exécution. Utilisez "skip" lorsque le travail périmé doit avancer sans être exécuté. Une tâche peut aussi fixer maxRunDurationMs d’une seconde jusqu’à 72 heures ; une exécution expirée est annulée et enregistrée comme échouée.

Pour tenir à travers les redémarrages de processus et d’hôte, exécutez le backend sous un superviseur. Voir Opérations de longue durée pour les exemples systemd, launchd et PM2, ainsi que la sémantique exacte de reprise.

Exécutions longues sans surveillance

Pour les sessions autonomes de plusieurs heures, le mode Super-Long ajoute des échéances d’exécution (jusqu’à 72 h), un cadencement des requêtes et un réglage du compactage. Il s’active tout seul pour les modèles dont les capacités déclarées prennent en charge le travail d’agent long (modèles de raisonnement à contexte de 1M, tels que Qwen 3.7+ Max/Plus sur les routes Alibaba et GLM 5.x sur les routes z.ai) et peut être forcé par session, par projet, ou via AX_CODE_SUPER_LONG. L’engagement de l’exécution est journalisé (super-long run engaged), et le cadencement fournisseur ne commence qu’après une fenêtre de grâce depuis le début de l’exécution (2 heures par défaut, super_long.pacing_grace_minutes), afin que la phase initiale productive d’une exécution agentique garde le plein débit d’appels d’outils ; la fin de marathon est cadencée selon le palier de limite de débit déclaré par le modèle.