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
AX Code für lang laufende Arbeit betreiben
Status: Aktiv Geltungsbereich: aktueller Stand Zuletzt geprüft: 2026-09-13 Verantwortlich: Betreuende von AX Code
AX Code begrenzt einen interaktiven Super-Long-Lauf auf 72 Stunden. Für den Betrieb über
Tage oder Wochen führen Sie einen beaufsichtigten Prozess ax-code serve aus und teilen die Arbeit
in dauerhafte geplante Vorkommen. Der Supervisor startet den Server neu; die
Projektdatenbank bewahrt Zeitpläne und den Zustand der Warteschlange.
Dauerhafter interaktiver Arbeitsbereich
Für lokale Arbeit, die nach dem Schließen des Terminals weiterlaufen soll, stimmen Sie einer Projektlaufzeit zu:
ax-code runtime start --dir /absolute/path/project
ax-code runtime attach --dir /absolute/path/project --continue
ax-code runtime status --dir /absolute/path/project
ax-code runtime list # every managed runtime on this machine
ax-code runtime stop --dir /absolute/path/project
runtime attach startet die Laufzeit ebenfalls, wenn keine vorhanden ist. Die Laufzeit ist dem
kanonischen Projektverzeichnis zugeordnet; gleichzeitige Starts verwenden einen Prozess.
Die TUI zeigt den Ausführungshost und eine Aktion Trennen. Das Trennen
schließt den Client und lässt angenommene Arbeit weiterlaufen. runtime stop fährt
die Laufzeit dieses Projekts herunter und unterbricht deren aktive Arbeit. Gewöhnliches ax-code
behält seinen bestehenden Lebenszyklus im Vordergrund.
Angenommene Folgeaufgaben, die abgesendet werden, während eine Sitzung beschäftigt ist, werden auf dem Server gespeichert.
Standardmäßig starten sie, nachdem der laufende Zug endet, sodass eine unabhängige Anfrage
laufende Arbeit nie aus der Bahn wirft. Um stattdessen den laufenden Zug zu korrigieren, drücken Sie
ctrl+s (input_submit_steer in keybinds) mit einem Entwurf nur aus Text: Der Text
wird in die aktive Erzeugung aufgenommen und an der nächsten Schrittgrenze der
Schleife als Benutzernachricht geschrieben, nachdem die laufenden Werkzeugaufrufe zur Ruhe kommen und bevor die
nächste Modellanfrage erfolgt. Eine Korrektur, die zugelassen wird, während der Zug endet, verlängert
den Lauf um eine Iteration, statt verworfen zu werden. Das Lenken geschieht nach bestem Bemühen: Wenn
keine Erzeugung mehr aktiv ist, geht der Entwurf den gewöhnlichen Weg;
weist ein Hook ihn ab, bleibt der Entwurf mit dem Grund im Eingabebereich. Entwürfe
mit Anhängen und Slash-Befehle verwenden immer die Warteschlange der Folgeaufgaben. Dieselbe
Zustellung steht anderen Clients über die Lenk-API zur Verfügung, beschrieben unter
Harness-Steuerung.
Gespeicherte Folgeaufgaben lassen sich auch nachträglich lenken: ctrl+s mit
leerem Eingabebereich zu drücken hebt das lenkbare Präfix der Warteschlange der Reihe nach an und stoppt
bei der ersten nicht lenkbaren Zeile. Der Abschnitt Folgeaufgaben in der Seitenleiste und der
Dialog /queue bieten dieselbe Aktion zum sofortigen Lenken je Zeile. Pausierte Zeilen sind
an Ort und Stelle lenkbar — einen Zug zu unterbrechen pausiert wartende Folgeaufgaben, und
eine davon zu lenken liefert ihren Text, ohne den Rest der Warteschlange fortzusetzen. Nur
Zeilen, die keine Folgeaufgaben sind (eingereihte Slash-Befehle, Shell-Befehle), Zeilen mit
Anhängen, leerer oder zu großer Text und Zeilen, die bereits laufen oder fertig sind, sind
Schranken. Gelenkte Zeilen werden mit einer Prüfspur steeredInto abgebrochen und bleiben
in der Historie /queue sichtbar. Wenn keine Erzeugung aktiv ist, fällt sofortiges Lenken
darauf zurück, die Zeile an den Anfang der Warteschlange zu setzen — sie startet weiterhin erst,
nachdem der Zug endet.
Der Eingabebereich leert sich erst nach der Bestätigung. Verbinden Sie sich erneut mit derselben Sitzung
und verwenden Sie /queue, um sie zu prüfen, zu pausieren, zu bearbeiten, fortzusetzen oder abzubrechen. Das Bearbeiten
pausiert den Eintrag zuerst und bewahrt Anhänge und die Modellauswahl; das Speichern setzt
ihn nicht fort. Gleichzeitige veraltete Bearbeitungen werden abgelehnt. In /queue enthält Ctrl+R
abgeschlossene und abgebrochene Historie. Schmale Terminals zeigen außerdem eine anklickbare
Überschrift Follow-ups. Eine getrennte Ansicht ist zwischengespeichert und kann Einträge nicht ändern.
Den aktiven Zug zu unterbrechen pausiert ausstehende Folgeaufgaben, damit sie nicht sofort
einen weiteren Zug starten. Setzen Sie sie ausdrücklich fort, wenn Sie bereit sind.
Nach einem Neustart des Backends können angenommene wartende Folgeaufgaben fortgesetzt werden. Ein gewöhnlicher laufender Prompt, den dieser Neustart unterbricht, wird als fehlgeschlagen gekennzeichnet und verlangt eine Prüfung vor einem erneuten Versuch; Warteschlangeneinträge wiederherzustellen stellt einen ausführenden Shell-Prozess nicht wieder her. Eine verlorene Bestätigung kann aus dem unveränderten Eingabebereich mit derselben Anfrageidentität während dieser Clientsitzung erneut versucht werden. Nicht gespeicherte Entwürfe sind keine angenommenen Aufträge, und das garantiert keine genau einmaligen externen Wirkungen.
Dieser Modus installiert keinen Anmeldedienst, startet einen abgestürzten Server nicht automatisch neu und führt nichts aus, während der Host schläft oder ausgeschaltet ist. Starten Sie nach einem Absturz erneut oder verbinden Sie sich wieder; verwenden Sie die Beispiele für beaufsichtigte Dienste unten für unbeaufsichtigte Neustarts des Servers. Benutzer von SSH sollten die Laufzeit auf einem wachen entfernten Host ausführen und sich dort verbinden. Legen Sie den HTTP-Port nicht öffentlich offen.
Die Ermittlung der Laufzeit speichert eine private Fähigkeit und ein Protokoll im Ordner runtime/ des Zustandsverzeichnisses von AX Code. Die Statusausgabe lässt die Fähigkeit weg. Das Herunterfahren
verlangt eine authentifizierte passende Laufzeitidentität, nicht nur eine gespeicherte PID.
Ein nicht verfügbarer laufender Prozess, eine beschädigte Aufzeichnung oder eine abweichende Version verlangt
eine Prüfung; die CLI weigert sich, einen ungeprüften Prozess zu beenden. Stoppen Sie eine gesunde
Laufzeit vor dem Aktualisieren und starten Sie sie mit der neuen ausführbaren Datei neu.
Zuverlässigkeitsmodell
| Ereignis | Verhalten |
|---|---|
| Das Backend endet, bevor ein fälliges Vorkommen festgeschrieben ist | Das Vorkommen bleibt fällig |
| Das Backend endet, nachdem die Transaktion vom Zeitplan in die Warteschlange festgeschrieben wurde | Derselbe Eintrag der Warteschlange wird beim Start fortgesetzt |
| Das Backend endet, nachdem ein Prompt gestartet ist | Der unterbrochene Eintrag wird als fehlgeschlagen gekennzeichnet, statt automatisch erneut abgespielt zu werden |
| Der Host verpasst mehrere Vorkommen | run_once fasst sie zu einem Lauf zusammen; skip rückt vor, ohne zu laufen |
| Ein Lauf der Warteschlange überschreitet seine Frist | Der Ausführer bricht die Sitzung ab und zeichnet einen fehlgeschlagenen Eintrag der Warteschlange auf |
| Der Supervisor sieht, dass der Server endet | Die Beispiele unten starten ihn nach einer kurzen Verzögerung neu |
Das ist eine wiederholungssichere Wiederherstellung, keine genau einmalige Zustellung für beliebige externe Wirkungen. Integrationen, die in externe Systeme schreiben, sollten weiterhin eigene Idempotenzschlüssel verwenden.
Vor der Installation eines Dienstes
- Installieren und prüfen Sie die ausführbare Datei
ax-codeals derselbe Benutzer, der den Dienst ausführen wird. - Wählen Sie einen absoluten Projektpfad. Setzen Sie ihn als
AX_CODE_PROJECT, damit der Serverstart dieses Projekt vorwärmt und seinen Planer startet. - Belassen Sie den Server auf
127.0.0.1; der Server von AX Code ist nur lokal. - Legen Sie die Zugangsdaten des Anbieters in die geschützte Umgebung des Supervisors, nicht in eine committete Dienstdatei.
- Ersetzen Sie jeden Platzhalter
/absolute/path/...im gewählten Beispiel.
Die Beispiele verwenden einen festen Port, damit sich Clients von Desktop oder SDK erneut verbinden können:
ax-code serve --hostname=127.0.0.1 --port=4096
Benutzerdienst mit systemd
Kopieren Sie das systemd-Beispiel nach
~/.config/systemd/user/ax-code.service, ersetzen Sie die absoluten Pfade und
legen Sie Zugangsdaten bei Bedarf in ~/.config/ax-code/server.env ab.
chmod 600 ~/.config/ax-code/server.env
systemctl --user daemon-reload
systemctl --user enable --now ax-code.service
systemctl --user status ax-code.service
journalctl --user -u ax-code.service -f
Verwenden Sie loginctl enable-linger "$USER" nur, wenn Ihre Betriebsrichtlinie erlaubt, dass der
Benutzerdienst läuft, während der Benutzer abgemeldet ist.
launchd-Agent
Kopieren Sie das launchd-Beispiel nach
~/Library/LaunchAgents/com.axcode.server.plist, ersetzen Sie die absoluten Pfade
und prüfen und laden Sie es dann:
plutil -lint ~/Library/LaunchAgents/com.axcode.server.plist
launchctl bootstrap "gui/$(id -u)" ~/Library/LaunchAgents/com.axcode.server.plist
launchctl kickstart -k "gui/$(id -u)/com.axcode.server"
launchd expandiert Shell-Variablen in ProgramArguments nicht. Verwenden Sie absolute
Pfade und stellen Sie nötige Zugangsdaten über einen von der Betriebsseite verwalteten Weg bereit.
PM2
Kopieren Sie das PM2-Beispiel, ersetzen Sie die Pfade und starten Sie es:
pm2 start docs/examples/ax-code-ecosystem.config.cjs
pm2 save
pm2 logs ax-code-server
Folgen Sie den plattformspezifischen Startanweisungen von PM2, wenn der Prozess nach einem Neustart des Hosts zurückkehren muss.
Fristen, Nachholen und Wiederherstellung
Geplante Aufgaben verwenden standardmäßig catchUpPolicy: "run_once". Nach einer Ausfallzeit führt AX Code
ein zusammengefasstes Vorkommen aus, statt einen unbegrenzten Rückstand zu erzeugen.
Wählen Sie "skip", wenn verspätete Arbeit irreführend oder unsicher wäre.
Jede geplante Aufgabe kann maxRunDurationMs von 1 Sekunde bis 72 Stunden setzen.
Die Ausführung der Aufgabenwarteschlange verwendet sonst die Obergrenze von 72 Stunden. Aktive Einträge aktualisieren alle
30 Sekunden einen Zeitstempel als Lebenszeichen, und der Endstatus sowie Fehlerdetails
bleiben in der Projektdatenbank.
Asynchrone Endpunkte für Prompt, Befehl und Shell geben den dauerhaften Warteschlangeneintrag in
ihrer Antwort HTTP 202 zurück. Clients sollten dessen id behalten und
GET /task-queue/:id abfragen, bis completed, failed oder cancelled erreicht ist; die Annahme
allein ist kein Abschluss.
Beim Start setzt ein dauerhaftes Backend von AX Code geplante Warteschlangeneinträge und ausdrücklich gekennzeichnete asynchrone Einträge fort, die festgeschrieben waren, aber noch nicht gestartet hatten. Einmalige CLI-Befehle übernehmen diese Einträge nicht. Bereits gestartete Prompt-Arbeit wird mit einer Erklärung zum Neustart als fehlgeschlagen gekennzeichnet, damit die Betriebsseite Nebenwirkungen prüfen kann, bevor sie es erneut versucht.
Sehen, was geplante Aufgaben tun
Jedes Vorkommen einer geplanten Aufgabe ist sichtbar, während es geschieht, und danach prüfbar:
- Start, Abschluss, Fehlschlag, Überspringen und automatische Pausen bei dauerhaftem Fehlschlag erzeugen jeweils eine Meldung in der Anwendung, die die Aufgabe nennt.
- Der TUI-Befehl
/schedulelistet jede Aufgabe mit Status, Zeitplan, nächster Laufzeit und letztem Fehler und öffnet die jüngere Laufhistorie. Von dort können Sie pausieren, fortsetzen, jetzt ausführen, löschen (drücken Siectrl+dzweimal zur Bestätigung) und zu der Sitzung springen, die ein Lauf erzeugt hat. Die Werkzeugelist_scheduled_tasksundlist_scheduled_task_runsdes Agenten beantworten dieselben Fragen im Gespräch. - Jeder Lauf führt in einer neuen Sitzung aus, die mit dem Aufgabentitel benannt ist, sodass Ergebnisse nur einen Eintrag in der Sitzungsliste entfernt sind, auch wenn eine Meldung übersehen wurde.
- Wenn ein Lauf nach einer Berechtigung oder einer Antwort auf eine Frage verlangt, während Sie ein
anderes Gespräch sehen, nennt ein Warnhinweis die Sitzung, die Sie braucht;
/attentionlistet bekannte ausstehende Anfragen und öffnet die anfragende Sitzung. Anfragen lassen sich in dieser Sitzung oder in der Ansicht eines geladenen Vorfahren beantworten, einschließlich Kind- und Enkelsitzungen. Eine Anfrage zu öffnen genehmigt sie nie automatisch. - Eine einmalige Aufgabe wird erst nach einem erfolgreichen Lauf deaktiviert. Ein fehlgeschlagenes Vorkommen wird mit begrenztem Backoff erneut versucht, und wiederholte Fehlschläge pausieren die Aufgabe mit einer Meldung — eine Erinnerung kann nicht mehr still verschwinden.
Betriebliche Prüfungen
- Beobachten Sie die Neustartzahl des Supervisors und die Serverprotokolle.
- Prüfen Sie fehlgeschlagene Einträge der Aufgabenwarteschlange und Fehler geplanter Aufgaben, bevor Sie es erneut versuchen.
- Stellen Sie genug Speicherplatz für die SQLite-Datenbank des Projekts und die Protokolle sicher.
- Führen Sie nach Änderungen an Zugangsdaten, Modellen oder Dienstpfaden ein manuelles Jetzt ausführen aus.
- Stoppen Sie über den Supervisor, damit AX Code
SIGTERMerhält; die Beispiele erlauben bis zu 90 Sekunden für ein geordnetes Herunterfahren.
/loop ist absichtlich auf den Prozess beschränkt und übersteht einen Neustart nicht. Verwenden Sie
geplante Aufgaben für dauerhafte unbeaufsichtigte Arbeit.
Parallele Sitzungen steuern
Ab 146 Terminalspalten zeigt eine linke Navigationsleiste die Sitzungen im
aktuellen Arbeitsbereich und ihre geladenen Kindagenten. Klappen Sie eine Zeile mit ihrem
Steuerelement + auf und klicken Sie auf einen Titel, um sie zu öffnen. Angeheftete Sitzungen behalten ihre Reihenfolge und
Kürzelnummern. Vollständige Aktivitätsbeschriftungen unterscheiden Arbeit, Wiederholung, Genehmigungen
und Fragen; übergeordnete Einträge spiegeln auch Anfragen von Nachkommen. Diese Beschriftungen bedeuten nicht,
dass eine Aufgabe die Prüfung bestanden hat. Die bestehende rechte Seitenleiste behält den Kontext und die Steuerung der aktuellen
Sitzung.
Die Überschrift Projekt kennzeichnet das aktuelle Verzeichnis. Klicken Sie darauf oder verwenden Sie
/navigation-info, um den vollständigen Projektpfad und den Titel der aktuellen Sitzung zu sehen.
Jüngere zeigt geladene Sitzungen; Aktiv behält arbeitende oder wartende Sitzungsbäume
und den Baum der aktuellen Sitzung. Der Filter wird mit der Navigationsauswahl geteilt
und gemerkt. Verwenden Sie /navigation-filter, um ihn über die Tastatur umzuschalten. Während
einer Trennung zeigt er zwischengespeicherte Sitzungen, statt zu vermuten, welche Sitzungen
aktiv sind. Leeren (oder /navigation-clear) fragt nach Bestätigung und blendet dann
historische Zeilen nur aus der linken Leiste und der Navigationsauswahl aus. Es löscht
keine Sitzungen; /sessions listet sie weiterhin. Der Baum der aktuellen Sitzung, angeheftete Sitzungen und beobachtete
arbeitende oder wartende Bäume bleiben auf der Leiste. Eine Sitzung aus /sessions zu öffnen
holt sie in die Liste zurück.
Verwenden Sie /navigation-width oder die Aktion Breite der Navigation, um 20, 24, 28, 30, 32, 36 oder 40
Spalten zu wählen (Voreinstellung 28). Die rechte Sitzungsleiste hat dieselbe Aktion Breite und
/sidebar-width (Voreinstellung 32). Beide Einstellungen werden gemerkt und schrumpfen bei Bedarf automatisch,
damit der Hauptinhalt erhalten bleibt. Verwenden Sie /navigation, um die linke
Navigationsleiste auf breiten Terminals auszublenden oder wiederherzustellen. /sidebar blendet die rechte
Sitzungsleiste auf dieselbe Weise aus oder wieder ein. Auf schmaleren Terminals öffnet /navigation stattdessen eine Auswahl für Sitzung und Agent.
Eine sichtbare Leiste Sitzungen bietet dieselbe Aktion, wann immer die
Navigationsleiste fehlt. Ihre Aktion Ausstehend erscheint, wenn bekannte Anfragen eine Eingabe brauchen;
ein Sternchen kennzeichnet eine zwischengespeicherte Zahl während der Trennung. /sessions
öffnet weiterhin die normale Sitzungsauswahl. /attention ist bei jeder
Breite verfügbar. Während der Trennung ist ihre Liste als zwischengespeichert gekennzeichnet; zwischengespeicherte
Einträge lassen sich weiterhin öffnen, aber Anfragen können bereits anderswo beantwortet worden sein.
Die Aktion Bekannte Anfragen der Seitenleiste öffnet ausstehende Anfragen über bekannte
Arbeitsbereiche, während ihr Sitzungsbaum auf das aktuelle Projekt begrenzt bleibt.
Alle diese Ansichten sind durch die verbundene Instanz und geladene Sitzungsdaten begrenzt;
diese Zahl ist kein vollständiges Inventar anderer Server oder nicht geladener Arbeitsbereiche.
Nicht gesendete Entwürfe sind innerhalb der laufenden TUI nach Projekt und Sitzung isoliert. Der Wechsel der Sitzung bewahrt Text, Anhänge, Cursorposition und Shell-Modus; die Rückkehr stellt den passenden Entwurf wieder her. Diese Entwürfe liegen nur im Speicher und überstehen das Schließen der TUI nicht.
Die optionale Abschlussmeldung lautet nun Session idle. Sie folgt
beobachteter Arbeit im Teilbaum der angesehenen Sitzung und wartet, bis beobachtete aktive
Nachkommen ausdrücklich im Leerlauf sind, ohne ausstehende Anfragen. Trennungen,
erneute Synchronisation, fehlender Zustand, Fehler und Abbruch können den Hinweis unterdrücken. Es ist
eine Meldung zum Lebenszyklus, kein Nachweis, dass Tests bestanden haben oder ein Ziel abgeschlossen wurde.
Neue Aufgaben und Einrichtung
Der normale Start öffnet die Arbeitsfläche Neue Aufgabe mit einem Eingabebereich unten und
Sitzungsnavigation. Sie zu öffnen oder einen Entwurf zu tippen erzeugt keine gespeicherte
Sitzung; eine Sitzung entsteht, wenn Sie absenden. Verwenden Sie /sessions oder die linke
Navigation, um bestehende Arbeit fortzusetzen. Das ausdrückliche Verhalten von --session, --continue und
--prompt bleibt verfügbar; der Start aktiviert die automatische Fortsetzung nicht.
Die Anbietereinrichtung öffnet sich nicht automatisch. Verwenden Sie die sichtbare Aktion /connect
im Arbeitsbereich, wenn kein Anbieter konfiguriert ist. Ist ein Anbieter konfiguriert,
aber kein gültiges Modell gewählt,
wechselt die Aktion zu /models. Eine fehlgeschlagene Anbieterermittlung verweist auf /status;
/connect und /providers bleiben verfügbar, um die Konfiguration zu reparieren. Ein gewähltes
Modell ist eine Konfigurationsentscheidung, keine Prüfung der Zugangsdaten oder der Laufzeitbereitschaft.
Die Hinweise erscheinen auch für wiederkehrende Benutzer, deren Konfiguration Aufmerksamkeit braucht.