OpenClaw Background Tasks: Ein Aktivitätsbuch für Arbeit im Hintergrund

Ein Cronjob springt an, ein Subagent läuft weiter, ein ACP-Run arbeitet längst außerhalb des sichtbaren Chats. Genau dann wird Betrieb unerquicklich, weil niemand mehr sauber sieht, wo ein Auftrag gerade steckt. OpenClaw bündelt diese entkoppelte Arbeit deshalb in einem gemeinsamen Aktivitätsbuch für Tasks.

Das Aktivitätsbuch schafft eine gemeinsame Sicht auf Arbeit, die ohnehin schon läuft. Wenn ein Auftrag hängt oder scheinbar verschwunden ist, liefert es Betreibern einen Ausgangspunkt; die Detailspuren des jeweiligen Runners bleiben für die weitere Diagnose erhalten.

Tasks protokollieren, sie ersetzen keine Runner

In diesem Aktivitätsbuch landen ACP-Runs, gestartete Subagents, Cron-Ausführungen und über das Gateway ausgelöste CLI-Agentenjobs. Normale interaktive Chats und Heartbeat-Turns erzeugen keinen Task. Erfasst wird also abgekoppelte Ausführung; sichtbare Unterhaltung hat ihre eigenen Spuren.

Das ist für die Praxis wichtiger, als es zunächst klingt. Ein Task plant nichts, stößt nichts eigenständig an und ersetzt weder Session noch Cronjob noch Heartbeat. Er hält fest, was lief, wann es lief und wie es endete.

Damit verschwindet auch ein typischer Bedienfehler nicht völlig, wird aber seltener: Wenn ein Zeitplan nicht feuert, musst du weiter den Cron prüfen. Wenn du wissen willst, ob der letzte Lauf gestartet ist, noch arbeitet oder schon gescheitert ist, schaust du auf den Task. Diese Trennung ist sinnvoll, weil sie zwei verschiedene Fragen auseinanderhält.

Ein gemeinsamer Lebenszyklus macht Unterschiede sichtbar

Jeder erfasste Task beginnt in queued, wechselt zu running und endet anschließend in einem terminalen Zustand. Genannt werden dafür succeeded, failed, timed_out, cancelled und lost. Der praktische Gewinn liegt auf der Hand: Sehr unterschiedliche Runner lassen sich damit auf derselben Oberfläche lesen, ohne ihre Unterschiede zu verwischen.

Besonders relevant ist lost. Gemeint ist damit nicht einfach ein Lauf, der länger dauert als gedacht. Bei Cron-Tasks prüft OpenClaw zunächst die dauerhafte Cron-Historie, wenn die Runtime im flüchtigen Speicher keinen laufenden Job mehr kennt. Erst wenn auch dort nichts mehr sauber zugeordnet werden kann, gilt der Task als verloren.

Betrieblich relevant wird das Feature an dieser Stelle. Ein Runtime-Neustart, leerer Prozessspeicher oder eine unterbrochene Session soll nicht sofort dieselbe Diagnose auslösen wie ein wirklich verwaister Lauf. Ohne diese Trennung würde ein Activity-Log nach jedem Prozesswechsel unnötig Alarm machen.

Abschlüsse sollen zurückkommen, nicht abgefragt werden

OpenClaw beschreibt die Fertigmeldung als ereignisgetrieben. Entkoppelte Arbeit kann ihren Abschluss direkt melden oder die anfragende Session beziehungsweise den Heartbeat wieder wecken. Das klingt unspektakulär, verändert aber kleine Agenten-Workflows spürbar.

Wer eigene Orchestrierung um Agents baut, kennt das Muster: Arbeit wird ausgelagert, danach beginnt eine Polling-Schleife, die im Sekundentakt auf einen neuen Status starrt. Hier ist meist etwas anderes vorgesehen. Der übergeordnete Agent kann Arbeit abgeben, auf das Abschlussereignis warten und erst dann weitermachen.

Das spart nicht nur Rechenzeit. Es senkt auch das Risiko, dass ungeduldige Statusabfragen Folgeaktionen zu früh auslösen. Gerade bei längeren Subagent-Läufen oder isolierten Cron-Ausführungen ist das operativ wertvoller als jede hübsche Oberfläche.

Dazu kommt Aufräumlogik rund um abgeschlossene Subagents und isolierte Cron-Läufe. Vor dem endgültigen Abschluss versucht das System, zugehörige Browser-Tabs und Prozesse der Child-Session zu bereinigen. Bei isolierter Cron-Auslieferung sollen veraltete Zwischenantworten des Parent-Laufs unterdrückt werden, solange nachgelagerte Subagent-Arbeit noch läuft. Trifft rechtzeitig ein finales Ergebnis des Nachfahren ein, bekommt dieses den Vorrang.

Für Monitoring zählt die Art des Fehlers

Aus Betreibersicht folgt daraus eine einfache Regel: Der Task-Zustand liefert die Einordnung, anschließend führt die Diagnose zum verantwortlichen Runner. failed steht für einen regulär beendeten Fehler, timed_out für eine überschrittene Laufzeit und lost für eine Ausführung, die auch nach dem Abgleich mit belastbarer Historie nicht mehr sauber auffindbar ist.

Diese Zustände in ein einziges rotes „kaputt“ zu pressen, wäre der falsche Reflex. Ein Timeout spricht eher für grobe Laufzeitgrenzen oder zu große Arbeitspakete. Ein verlorener Task deutet eher auf einen Bruch zwischen Runtime-Zustand und Ausführungshistorie. cancelled kann dagegen schlicht eine bewusste Entscheidung gewesen sein. Die gemeinsame Oberfläche macht das Lesen leichter, nimmt dir die Diagnose aber nicht ab.

Ebenso wichtig ist die Grenze des Modells. Heartbeats erscheinen nicht als Tasks. Ein Dashboard, das nur dieses Aktivitätsbuch auswertet, sieht also bewusst nur die entkoppelte Arbeit. Wenn du zusätzlich prüfen willst, ob Heartbeats regelmäßig laufen, brauchst du weiterhin deren eigene Status- und Laufzeitspuren.

Damit ist der Wert von Background Tasks ziemlich klar umrissen. OpenClaw erfindet hier keinen neuen Runner, sondern schafft eine gemeinsame Betriebssicht auf Cron, ACP, Subagents und CLI-Jobs. Für produktive Setups ist genau das nützlich: weniger Rätselraten darüber, wo ein Auftrag verschwunden ist, und eine sauberere Diagnose, bevor du tiefer in den jeweiligen Runner steigst.