Diese Seite ist eine Übersetzung der englischen Dokumentation. Befehle, Bezeichner und Beispiele bleiben unverändert. Runtime 7.24.4 · SDK 2.6.7. Englische Fassung

Loop-Modus und geplante Aufgaben

Status: Aktiv Geltungsbereich: aktueller Stand Zuletzt geprüft: 2026-08-27 Verantwortlich: ax-code runtime

AX Code hat drei kombinierbare Grundbausteine der Automatisierung:

/loop — wiederkehrende Prompts

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

Beispiele:

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

Regeln:

• Grenzen des Intervalls: 30 Sekunden bis 24 Stunden. Eine Schleife je Sitzung — eine neue ersetzt die bisherige.
• Ein Tick, der auslöst, während die Sitzung beschäftigt ist, wird übersprungen und gezählt, nie eingereiht. Schleifen können keine Runden anhäufen.
• Jeder Tick ist eine gewöhnliche Prompt-Runde: Berechtigungen, Fragen, autonome Obergrenzen und Abschlussprüfungen gelten sämtlich. Bei ausgeschaltetem autonomen Modus bleibt ein Tick an der ersten Berechtigungsabfrage stehen.
• Harte Obergrenze von 500 Läufen je Schleife; danach beendet die Schleife sich selbst mit einem Hinweis.
• Schleifen leben nur im Backend-Prozess: einen Neustart überstehen sie nicht. Für dauerhafte Zeitpläne verwenden Sie die geplanten Aufgaben weiter unten.

/goal mit /loop koppeln

/goal trägt das Ziel („alle Tests grün, keine offenen Review-Befunde“); /loop liefert den Herzschlag, der weiter prüft. Wird zuerst ein Ziel angelegt, läuft ein eigener Planverfasser, der einen prüfbaren Vertrag unter .ax-code/goals/ ablegt, oder im AX-Datenverzeichnis, wenn das Projekt kein Git-Worktree ist. Scheitert die Planung, bleibt das Ziel pausiert — /goal resume versucht es erneut. Git-Bereichsprüfungen, die den Diff dieses Ziels messen, verwenden den HEAD zum Zeitpunkt der Planung ({BASELINE}), nicht origin/main, außer das Ziel nennt genau dieses Remote. Der Abschluss des Ziels bleibt an die Verifikation gebunden: nach Änderungen kann der Agent ein Ziel ohne bestandenen Verifikationslauf nicht als abgeschlossen markieren, und liegt ein Plan vor, muss er außerdem für jedes Annahmekriterium einen Beleg liefern.

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

Zusicherung von Zielen nur bei ausdrücklicher Aktivierung

/goal <objective> startet sofort: es hängt keinen eingefrorenen Annahmevertrag an. Den Abschluss beurteilen daher der Arbeitsplan, den der Agent führt (ausstehende Todos), und eine bestandene Verifikation nach der letzten Änderung. /goal view und „Zieldetails anzeigen“ im Zieldialog sagen das ausdrücklich — „Kein Zusicherungsvertrag“ —, damit Sie den Zustand nie erschließen müssen.

/goal --assure <objective> führt zuerst den Planverfasser aus. Der friert Annahmekriterien, Quellverweise und ausführbare Prüfungen ein; der Abschluss verlangt dann zusätzlich einen aktuellen erfolgreichen Beleg für jede erforderliche Prüfung (verify_project mit der Kennung goalCheck). Verwenden Sie das, wenn das „fertig“ des Ziels belegbar sein muss und nicht bloß beschrieben.

--assure lässt sich mit den Budget-Optionen in beliebiger Reihenfolge kombinieren (/goal --assure --budget 500000 <objective>). /goal replace <objective> behält die Zusicherung, wenn das ersetzte Ziel einen gültigen Vertrag hat, sodass ein Ersetzen ein bereits zugesichertes Ziel nie stillschweigend abschwächen kann.

Budgets und Obergrenzen für Ziele

Ein aktives Ziel hebt die Obergrenze der automatischen Fortsetzung je Lauf (session.max_continuations). Der Lauf geht weiter, bis das Ziel abgeschlossen, blockiert, pausiert oder durch das Budget begrenzt ist. Was es stattdessen begrenzt:

• Token-Budget (/goal --budget N …): ist es erschöpft, erhält der Agent eine Abschlussrunde, danach wird das Ziel zu budget_limited.
• Zeitbudget (/goal --time-budget 30m …): eine Grenze der Wanduhr in Sekunden, Minuten (m) oder Stunden (h), in beliebiger Reihenfolge mit dem Token-Budget kombinierbar. Es begrenzt verstrichene Arbeit, die das Token-Budget nicht sieht: entfernte Trainingsjobs, lange Werkzeugaufrufe, Stockungen beim Anbieter. Dieselbe Abschlussrunde und der Übergang budget_limited gelten, wenn es auslöst.
• Kumulative Schritt-Obergrenze: Läufe mit aktivem Ziel teilen die Super-Long-Absicherung von insgesamt max_steps × 40 Schritten (20,000 als Voreinstellung) statt der gewöhnlichen autonomen Obergrenze von max_steps × (max_continuations + 1). Überschreiben Sie das mit session.max_total_steps.
• Die Erkennung von Doom-Loops, die Obergrenzen des Wirkungsradius und der Unterbrecher für Runden nur mit Werkzeugen gelten durchgehend weiter.

Ziel-CLI (headless)

Dieselbe Steuerung für Ziele steht außerhalb der TUI unter ax-code goal bereit:

• ax-code goal status [--json] — zeigt das aktuelle Ziel (-s/--session, um eine Sitzung zu wählen; Voreinstellung ist das einzige fortsetzbare Ziel des Projekts, und es kommt zu einem Fehler, wenn die Wahl mehrdeutig wäre).
• ax-code goal pause / ax-code goal clear — pausiert oder entfernt es.
• ax-code goal resume — setzt das Ziel fort und steuert es headless, bis es zur Ruhe kommt. Ohne --attach richtet es das Projekt im selben Prozess ein; mit --attach http://localhost:4111 steuert es stattdessen einen laufenden Server. Die Exit-Codes folgen dem Headless-Vertrag für Ziele: 0 abgeschlossen, 3 blockiert, 4 durch das Budget begrenzt, 6 pausiert oder nicht terminal, 1 Sitzungsfehler, 124 Leerlauf-Timeout (--idle-timeout-ms, Voreinstellung 10 Minuten). Ereignisse strömen als JSONL nach stdout (--event-log PATH zeichnet sie ebenfalls auf), und eine abschließende Zeile Goal <status>: <objective> geht nach stderr.

Nähert sich ein Ziellauf der Schritt-Obergrenze, erhält der Agent eine einmalige Konvergenzwarnung. Sie fordert ihn auf, das Ziel zu prüfen und abzuschließen oder eine saubere Übergabe zu hinterlassen. Wird die Obergrenze trotzdem erreicht, ist das Ziel pausiert und gilt nicht als fehlgeschlagen. Es lässt sich mit /goal resume wieder aufnehmen (erhöhen Sie zuvor session.max_total_steps, wenn mehr Spielraum nötig ist).

Geplante Aufgaben — dauerhaft und im Dialog

Fragen Sie den Agenten direkt; er nutzt die Werkzeuge schedule_task, list_scheduled_tasks und manage_scheduled_task:

• „Erinnern Sie mich um 14:30 daran, das Deployment zu prüfen.“
• „Fassen Sie an jedem Werktag um 9 Uhr neue CI-Fehler zusammen.“
• „Listen Sie meine geplanten Aufgaben.“ / „Pausieren Sie die Aufgabe mit der CI-Zusammenfassung.“

Vom Agenten angelegte und verwaltete Änderungen am Zeitplan fordern die Berechtigung schedule an. Ein nur lesender Lauf kann einen Zeitplan weder ändern noch auslösen. Für die unbeaufsichtigte Erstellung ohne TUI verwenden Sie den ausdrücklichen Befehl ax-code schedule oder richten Sie für den Agenten eine ausdrückliche Berechtigung schedule ein. Breite Wildcard-Freigaben berechtigen nicht zu Änderungen am Zeitplan.

Dieselben Aufgaben lassen sich in der Shell verwalten, ohne die TUI zu öffnen:

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 laufen über die verwaltete Laufzeit des Projekts, wenn eine aktiv ist (sofortige Wirkung, Live-Aktualisierung der TUI), und schreiben sonst direkt in die Projektdatenbank. run braucht ein lebendes Backend — starten Sie eines mit ax-code runtime start —, weil ein einmaliger CLI-Prozess keine Arbeit beanspruchen darf, die er nicht zu Ende führen kann. Alle lesenden Unterbefehle akzeptieren --json.

Zeitpläne unterstützen einmalige Läufe, tägliche und wöchentliche Uhrzeiten sowie Cron-Ausdrücke mit 5 Feldern, jeweils mit optionaler IANA-Zeitzone. Aufgaben bleiben in der Projektdatenbank und lösen aus, solange ein Backend von AX Code für das Projekt läuft (Scheduler-Durchlauf alle 60s, atomares Beanspruchen: eine Aufgabe löst einmal aus, auch wenn mehrere Backends offen sind). Das Fortschreiben des Zeitplans und das Einfügen in die dauerhafte Warteschlange teilen sich eine Datenbanktransaktion, sodass ein Absturz ein Vorkommen nicht fortschreiben kann, ohne wiederherstellbare Arbeit zu hinterlassen. Einmalbefehle wie ax-code run und ax-code stats beanspruchen keine fälligen Aufgaben. Starten Sie mit ax-code runtime start ein dauerhaftes Backend, damit sie zugestellt werden.

Verpasste Vorkommen verwenden standardmäßig catchUpPolicy: "run_once": nach einer Ausfallzeit fasst AX Code jeden Rückstand zu einem Lauf zusammen. Verwenden Sie "skip", wenn veraltete Arbeit ohne Ausführung fortgeschrieben werden soll. Eine Aufgabe kann außerdem maxRunDurationMs von einer Sekunde bis 72 Stunden setzen; ein Lauf mit Zeitüberschreitung wird abgebrochen und als fehlgeschlagen aufgezeichnet.

Für den Betrieb über Neustarts von Prozess und Host hinweg führen Sie das Backend unter einem Supervisor. Siehe Lang laufende Vorgänge für die Beispiele mit systemd, launchd und PM2 sowie die genaue Semantik der Wiederherstellung.

Lange unbeaufsichtigte Läufe

Für mehrstündige autonome Sitzungen ergänzt der Modus Super-Long Lauf-Fristen (bis 72h), eine Taktung der Anfragen und eine Abstimmung der Verdichtung. Er schaltet sich für Modelle automatisch ein, deren erklärte Fähigkeiten lange Agentenarbeit unterstützen (Reasoning-Modelle mit 1M-Kontext wie Qwen 3.7+ Max/Plus auf Routen von Alibaba und GLM 5.x auf Routen von z.ai). Er lässt sich je Sitzung, je Projekt oder über AX_CODE_SUPER_LONG erzwingen. Die Beteiligung am Lauf wird protokolliert (super-long run engaged), und die Taktung des Anbieters beginnt erst nach einem Schonfenster ab Laufstart (Voreinstellung 2 Stunden, super_long.pacing_grace_minutes), damit die produktive frühe Phase eines agentischen Laufs den vollen Durchsatz der Werkzeugaufrufe behält. Der Marathon-Ausläufer wird gemäß der erklärten Rate-Limit-Stufe des Modells getaktet.