Hintergrundaufgaben & dauerhafte Workflows

OpenClaw gibt dir mehrere Wege, Arbeit außerhalb des aktuellen Chat-Turns laufen zu lassen. Das ist nützlich, erzeugt aber auch einen typischen Anfängerfehler: Viele werfen Shell-Ausführung, Hintergrund-Überwachung und dauerhafte Nachverfolgung in einen Topf, als wäre das alles dasselbe.

Ist es nicht. Ein hilfreiches Denkmodell ist dieses: exec startet den Motor, process ist das Armaturenbrett und Tasks sind der Flugschreiber. Wenn du diese Ebenen verwechselst, wird lang laufende Arbeit sehr schnell fragil.

Laut aktueller offizieller OpenClaw-Doku sind Tasks Datensätze, keine Scheduler. Sie verfolgen losgelöste Arbeit wie Cron-Ausführungen, Subagenten-Spawns, ACP-Runs und CLI-Operationen. Eine separate Doku zu Background Exec erklärt außerdem, dass exec Shell-Befehle ausführt und process live Hintergrund-Sessions verwaltet, die im Speicher bleiben, nicht auf der Festplatte.

Was dauerhafte Arbeit eigentlich bedeutet

Dauerhafte Arbeit ist Arbeit, die auch dann noch verständlich bleibt, wenn Zeit vergeht, Output aus dem Blick rutscht oder das Gateway neu startet. Das bedeutet nicht immer einfach nur: "Der Befehl lief weiter." Manchmal heißt Dauerhaftigkeit, dass der Datensatz bleibt. Manchmal, dass der Workflow fortgesetzt werden kann. Manchmal, dass die richtige Person eine Benachrichtigung bekommt, wenn der Job endet.

Die saubere Trennung sieht so aus:

• exec: startet jetzt einen Shell-Befehl
• process: beobachtet oder steuert diese live Hintergrund-Session
• Tasks: protokollieren losgelöste Arbeit als auditierbares Aktivitäts-Ledger
• TaskFlow: koordiniert dauerhafte mehrstufige Flows über einzelnen Tasks

Dieser Stack ist weniger ein einzelnes Tool als ein Staffellauf. Eine Person startet das Rennen, eine andere behält die Bahn im Blick und eine dritte hält das offizielle Ergebnis fest.

exec vs. process vs. Tasks

Das ist der Vergleich, den die meisten zuerst brauchen.

Die offizielle Background-Process-Seite macht eine Grenze sehr deutlich: Hintergrund-Sessions von process liegen im Speicher und gehen bei einem Neustart verloren. Genau dieses Detail überspringen viele, bis sie es später mühsam wiederfinden.

Wann warten, wann pollen und wann ankündigen

Die meisten Fehler bei dauerhafter Arbeit sind Timing-Fehler. Leute warten zu lange im Vordergrund, pollen zu aggressiv oder bauen falsche Erinnerungs-Loops, die eigentlich Cron-Jobs sein sollten.

Im Vordergrund warten

Bleib im Vordergrund, wenn der Befehl kurz ist, das Ergebnis sofort gebraucht wird und der Nutzer aktiv darauf wartet. Ein schneller Testlauf oder ein kleiner Datei-Check gehört hierhin.

Mit process bei Bedarf pollen

Nutze process, wenn der Job schon läuft und du Logs sehen, eine interaktive Session retten, einen stillen Erfolg bestätigen oder in einen laufenden Befehl eingreifen musst. Polling ist für Sichtbarkeit da, nicht für Scheduling.

Über Task-Abschluss oder Session-Wake ankündigen

Die Tasks-Doku beschreibt ein push-basiertes Modell. Losgelöste Arbeit kann die anfragende Session wecken oder beim Abschluss eine Benachrichtigung zustellen. Das gesunde Standardmuster lautet also meist: einmal starten und dann die Laufzeitumgebung das Ergebnis nach vorn bringen lassen. Wiederholtes manuelles Polling ist meist nur fürs Debugging nötig.

Die Dauerhaftigkeits-Leiter

Hier ist die praktische Leiter von wenig dauerhaft bis stark strukturiert:

1. ein Vordergrund-Befehl, der sofort zurückkommt
2. eine Hintergrund-Session von exec, die du noch mit process prüfen kannst
3. ein losgelöster Task-Datensatz, den du später listen, auditieren, abbrechen und prüfen kannst
4. ein TaskFlow-Lauf, wenn mehrere Tasks über Zeit koordiniert bleiben müssen

Wenn dein ganzer Plan nur lautet: "Ich hoffe, ich merke mir später, welcher Terminal-Output wichtig war", dann stehst du immer noch auf Sprosse eins.

Typische Fehlermuster

Tasks mit Schedulern verwechseln

Tasks sagen dir, was passiert ist. Sie entscheiden nicht, wann etwas starten soll. Wenn die Arbeit exaktes Timing braucht, nimm Cron. Wenn sie ungefähre laufende Aufmerksamkeit braucht, nimm Heartbeat. Wenn sie nach dem Start einen Audit-Trail braucht, werden Tasks wichtig.

In Loops pollen, weil sich sonst nichts sicher anfühlt

Die offizielle Doku ist hier ziemlich klar. Pollen bei Bedarf. Verwandelt Polling nicht in einen Ersatz für echtes Scheduling. Wenn du Arbeit später brauchst, nimm Cron. Wenn du das Abschluss-Ereignis brauchst, verlass dich auf Wake oder Benachrichtigung.

Blindheit bei Neustarts

Eine Hintergrund-Shell-Session kann in einem Moment noch da sein und nach einem Neustart aus dem Speicher verschwinden. Wenn du process-Logs wie dauerhaftes Beweismaterial behandelst, vertraust du der falschen Ebene. Dauerhafte Nachverfolgung lebt in Tasks, nicht in einem zufällig überlebenden Buffer.

Einen Befehl neu starten, statt den bestehenden zu prüfen

Das ist ein leiser Kostenfresser. Jemand startet einen Build, wird ungeduldig, startet ihn erneut und plötzlich konkurrieren zwei lange Jobs um dieselben Ressourcen. Einmal starten. Die vorhandene Session prüfen. Keine neue Verwirrung erzeugen, nur um beschäftigt zu wirken.

Sleep-Loops als falsche Erinnerungen nutzen

Wenn die Arbeit später passieren soll, halte keinen Shell-Prozess mit einer Delay-Schleife künstlich offen. Das ist fragil, laut und schwerer wiederherzustellen. OpenClaw hat für spätere Arbeit bereits Cron.

Beispielaufbau: langer Build mit sauberem Follow-up

Die offizielle Background-Process-Doku zeigt die gewünschte Form ziemlich klar: Starte den langen Job einmal und prüfe ihn später bei Bedarf über process.

// jetzt starten, nach kurzer Wartezeit in den Hintergrund schicken
{ "tool": "exec", "command": "npm run build", "yieldMs": 1000 }

// später neuen Output oder Abschluss prüfen
{ "tool": "process", "action": "poll", "sessionId": "<id>" }

Dieses Muster ist auf gute Weise langweilig. Es vermeidet Doppelstarts, hält einen klaren Session-Handle fest und hält den Hauptchat trotzdem responsiv.

Wo Tasks zur Quelle der Wahrheit werden

Wenn die Arbeit so losgelöst ist, dass du dich für Historie, Status oder Operator-Inspektion interessierst, werden Tasks zur besseren Wahrheitsebene. Die aktuelle Tasks-Doku listet klare Lebenszyklus-Status wie queued, running, succeeded, failed, timed_out, cancelled und lost.

Das zählt, weil dauerhafte Operationen selten nur von rohem Output leben. Es geht darum zu wissen, ob der Job fertig ist, wer ihn besitzt, ob er ein Timeout hatte und ob die Wiederherstellung automatisch oder manuell passieren sollte.

Wie du über Dauerhaftigkeit nachdenkst, ohne zu überbauen

Nicht jede lange Aufgabe braucht TaskFlow. Nicht jeder Shell-Befehl braucht ein Task-Audit. Der Trick ist, den Mechanismus auf das Risiko abzustimmen.

• Du brauchst nur einen direkten Befehl? Nimm exec.
• Du musst eine laufende Shell-Session beobachten? Nimm process.
• Du brauchst einen auditierbaren losgelösten Lauf? Stütze dich auf Tasks.
• Du brauchst mehrere abhängige Hintergrund-Stufen? Dann geh hoch zu TaskFlow.

Denk daran wie an Kleidung fürs Wetter. Du ziehst keinen Wintermantel an, nur um den Briefkasten zu prüfen. Aber du gehst auch nicht im T-Shirt auf den Berg, nur weil die Einfahrt gestern warm war.

Operative Gewohnheiten, die losgelöste Arbeit sauber halten

• Lange Arbeit einmal starten, nicht wiederholt
• yieldMs oder Background Mode bewusst einsetzen
• Nur pollen, wenn du Status, Logs oder Eingriffe brauchst
• Push-basierten Abschluss nervösen Refresh-Loops vorziehen
• Cron für spätere Arbeit nutzen, nicht Delay-Hacks in der Shell
• Zu TaskFlow wechseln, wenn mehrere Schritte dauerhaft koordiniert werden müssen

Die praktische Faustregel

Wenn die Frage lautet: "Kann ich diesen Befehl starten, ohne den Chat zu blockieren?", denk an exec. Wenn die Frage lautet: "Wie prüfe oder steuere ich den live laufenden Hintergrundbefehl?", denk an process. Wenn die Frage lautet: "Was lief, in welchem Status ist es und kann ich es später auditieren?", denk an Tasks.

Diese Aufteilung klingt simpel, weil sie simpel ist. Komplex wird es erst, wenn Leute eine Ebene zwingen, die Rolle einer anderen zu spielen.