AX Code holen · KostenlosDokumentation

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

  1. Installieren und prüfen Sie die ausführbare Datei ax-code als derselbe Benutzer, der den Dienst ausführen wird.
  2. Wählen Sie einen absoluten Projektpfad. Setzen Sie ihn als AX_CODE_PROJECT, damit der Serverstart dieses Projekt vorwärmt und seinen Planer startet.
  3. Belassen Sie den Server auf 127.0.0.1; der Server von AX Code ist nur lokal.
  4. Legen Sie die Zugangsdaten des Anbieters in die geschützte Umgebung des Supervisors, nicht in eine committete Dienstdatei.
  5. 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 /schedule listet 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 Sie ctrl+d zweimal zur Bestätigung) und zu der Sitzung springen, die ein Lauf erzeugt hat. Die Werkzeuge list_scheduled_tasks und list_scheduled_task_runs des 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; /attention listet 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 SIGTERM erhä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.

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.