OpenClaw-Hintergrund-Exec und das process-Tool
Wie sich ein Befehl nach der Yield-Verzögerung selbst in den Hintergrund verlagert, das Sitzungsregister mit seinen Ausgabelimits und Lebensdauern, Worker-Umgebungen, die einen Turn überdauern, und die neun Prozessaktionen von poll bis paste
Bei lang laufender Arbeit wird ein Shell-Tool entweder nützlich oder zur Belastung. Die Antwort von OpenClaw lautet: den Befehl in den Hintergrund verlagern, eine Sitzungs-ID zurückgeben und dem Agenten ein separates Tool geben, um ihn abzufragen, mit Eingaben zu versorgen und zu beenden. Wissenswert sind die Details, die entscheiden, ob die Ausgabe überlebt, ob der Prozess überlebt und was der Agent tun sollte, statt zu schlafen.
Hintergrundbetrieb und Aufbewahrung
- Ein Lauf im Vordergrund gibt die aufbewahrte Ausgabe direkt zurück und weist darauf hin, wenn frühere Ausgabe das Gesamtlimit überschritten hat; wird der Befehl in den Hintergrund verlagert, explizit oder durch Überschreiten der Yield-Verzögerung, gibt das Tool einen laufenden Status, eine Sitzungs-ID und ein kurzes Ausgabeende zurück, und Hintergrundläufe erben weiterhin das konfigurierte Exec-Timeout, sofern der Aufruf kein eigenes übergibt.
- Die Rückgabe einer Sitzungs-ID hält das Prozess-Timeout nicht an: Für einen dauerhaften Dienst auf dem Gateway oder in einer Sandbox verlagern Sie den Befehl mit deaktiviertem Timeout in den Hintergrund und stoppen ihn später mit der Aktion kill, wobei die Lebenszyklus-Limits von Host und Worker weiterhin gelten.
- Die Ausgabe bleibt bis zum Gesamtlimit pro Sitzung im Arbeitsspeicher, bis die Sitzung abgefragt oder geleert wird; beendete Sitzungen verfallen nach einer ab dem Abschluss gemessenen Lebensdauer, wobei jeder Exec-Aufruf bei seiner Zulassung die Aufbewahrungseinstellung seines Agenten übernimmt, und das Register hält höchstens 50 beendete Sitzungen und zwei Millionen aufbewahrte Zeichen vor und verdrängt die ältesten zuerst, während die neueste abgeschlossene Sitzung ihre gedeckelte Gesamtausgabe behält.
- Die Stellschrauben existieren als Konfigurationsschlüssel statt als Umgebungsvariablen: Die Hintergrundverzögerung beträgt standardmäßig zehn Sekunden, das Timeout pro Aufruf 1800 Sekunden, die Lebensdauer bis zur Bereinigung 30 Minuten, die Benachrichtigung beim Beenden ist standardmäßig aktiv und reiht ein Systemereignis plus eine Heartbeat-Anfrage ein, und eine zusätzliche Einstellung kann auch bei erfolgreichen Läufen ohne Ausgabe benachrichtigen.
Abfragen dient dem Status auf Abruf, nicht der Planung von Warteschleifen. Soll die Arbeit später stattfinden, verwenden Sie cron.
Worker, Bereinigung und das process-Tool
Auf einem gekoppelten Node oder einem Node-gestützten Cloud-Worker gehören Hintergrundprozesse zur Umgebung der Sitzung: Das Beenden oder Abbrechen eines Turns lässt bereits in den Hintergrund verlagerte Befehle weiterlaufen, ein späterer Turn in derselben Umgebung kann sie abfragen, mit Eingaben versorgen oder stoppen, und Vordergrundbefehle stoppen weiterhin, wenn ihr Turn abgebrochen wird. Der beibehaltene Worker belegt einen Node-Worker-Slot, seine Wiederverwendung braucht keinen zusätzlichen Slot, und sobald ein Turn ohne laufende Hintergrundbefehle endet, beendet sich der Worker. Das Verschieben oder Stilllegen der Umgebung, das Ersetzen ihres Eigentümers oder das Stoppen des Nodes stoppt auch ihre Prozesse, und Handles überleben keinen Neustart des Workers oder Nodes. Auch anderswo ist die Bereinigung bewusst vorsichtig: Bei eigenen Prozessgruppen wartet sie, bis das Betriebssystem bestätigt, dass die Gruppe verschwunden ist, ein abgeschlossener Befehl oder eine geschlossene Ausgabe-Pipe allein beweist nicht, dass die Nachfahrenprozesse gestoppt sind, und eine erzwungene Beendigung ohne bestätigte Bereinigung bleibt ungewiss, statt als sauberes Herunterfahren gemeldet zu werden.
Die neun Aktionen
- Die Aktion list zeigt laufende und beendete Sitzungen mit einem abgeleiteten Namen, poll holt neue Ausgabe ab und meldet den Exit-Status, log liest die gesammelte Ausgabe mit zeilenbasierter Paginierung und Hinweisen zur Wiederherstellung von Eingaben, und alle drei markieren eine Sitzung nur dann als auf Eingabe wartend, wenn stdin noch beschreibbar ist und sie länger als der Schwellenwert untätig war.
- Die Aktion write sendet stdin mit optionaler Endmarkierung, send-keys sendet explizite Tasten-Token oder Bytes an eine terminalgestützte Sitzung, submit sendet einen Wagenrücklauf, und paste sendet wörtlichen Text, standardmäßig in Bracketed Paste eingeschlossen; kill beendet eine laufende Sitzung, clear entfernt eine beendete, und remove tut das jeweils Zutreffende.
- Nur in den Hintergrund verlagerte Sitzungen werden gelistet und gespeichert, im Arbeitsspeicher und nie auf der Festplatte, sodass sie bei einem Neustart verloren gehen; das Tool ist pro Agent begrenzt und sieht nur die Sitzungen dieses Agenten, eine laufende Hintergrundsitzung blockiert kooperatives Suspendieren und einen sicheren Gateway-Neustart, bis das Beenden bestätigt ist, und ein Poll-Timeout über 30 Sekunden wird gekappt.
Das exec-Tool von OpenClaw ist das Tool, das diese Sitzungen startet, und die Übersicht der Hintergrundaufgaben in OpenClaw das Verzeichnis, das sie anzeigt, während sie laufen.
Was statt Schlafen zu tun ist
Die Dokumentation benennt das Antipattern unverblümt: Bilden Sie Erinnerungen oder verzögerte Nachfassaktionen nicht mit Sleep-Schleifen oder wiederholtem Abfragen nach. Arbeit, die jetzt beginnt, starten Sie einmal und verlassen sich auf das automatische Aufwecken bei Abschluss, wenn es aktiviert ist und der Befehl Ausgabe erzeugt oder fehlschlägt; danach nutzen Sie das process-Tool für Logs, Status, Eingabe oder Eingriff. Für Arbeit, die später oder nach Zeitplan stattfinden soll, ist der Scheduler die richtige Oberfläche. Das Log zu lesen, bevor man einen interaktiven Befehl wiederherstellt, ist die andere Gewohnheit, die sich lohnt, denn Transkript, stdin-Zustand und der Hinweis auf wartende Eingabe sind nur dort gemeinsam sichtbar. OpenClaw-Automatisierungen behandelt den Scheduler, und der Artikel zum OpenClaw-Sandboxing erklärt, wo diese Befehle tatsächlich laufen.
Bei Diali
Bei Diali läuft der Assistent in seiner eigenen Laufzeitumgebung mit dem Zustand auf einem persistenten Volume, sodass ein Hintergrundbefehl allein zu dieser Kundenumgebung gehört; tägliche Snapshots und Wiederherstellung per Klick sind über das Backups-Add-on (in Max enthalten) verfügbar. Gehostetes OpenClaw bei Diali beschreibt den gehosteten Assistenten und die Diali-Sicherheitsseite die Grenze um das, was er ausführen darf.
- Nach der Yield-Verzögerung liefert ein Befehl eine Sitzungs-ID statt einer Wand aus Ausgabe.
- Nur im Arbeitsspeicher: Sitzungen gehen bei einem Neustart verloren, sind gedeckelt und verfallen.
- Aufwecken bei Abschluss schlägt Abfragen; der Scheduler schlägt Schlafen.
Genug gelesen, bauen Sie selbst einen
Richten Sie einen Agenten ein, wählen Sie einen Kanal und lassen Sie ihn in der App arbeiten, die Sie ohnehin geöffnet haben.
