Automation
Hintergrundaufgaben
Hintergrundaufgaben verfolgen Arbeit, die außerhalb Ihrer Haupt-Konversationssitzung läuft: ACP-Ausführungen, Subagent-Starts, isolierte Cron-Job-Ausführungen und CLI-initiierte Vorgänge.
Aufgaben ersetzen keine Sitzungen, Cron-Jobs oder Heartbeats - sie sind das Aktivitätsprotokoll, das aufzeichnet, welche losgelöste Arbeit stattgefunden hat, wann sie stattfand und ob sie erfolgreich war.
TL;DR
- Aufgaben sind Einträge, keine Scheduler - Cron und Heartbeat entscheiden, wann Arbeit ausgeführt wird, Aufgaben verfolgen, was passiert ist.
- ACP, Subagents, alle Cron-Jobs und CLI-Vorgänge erstellen Aufgaben. Heartbeat-Turns tun dies nicht.
- Jede Aufgabe durchläuft
queued → running → terminal(succeeded, failed, timed_out, cancelled oder lost). - Cron-Aufgaben bleiben aktiv, solange die Cron-Laufzeit den Job noch besitzt; wenn der In-Memory-Laufzeitstatus weg ist, prüft die Aufgabenwartung zuerst die persistente Cron- Ausführungshistorie, bevor eine Aufgabe als verloren markiert wird.
- Der Abschluss ist push-gesteuert: Losgelöste Arbeit kann direkt benachrichtigen oder die anfragende Sitzung/den Heartbeat wecken, wenn sie fertig ist, daher sind Status-Polling-Schleifen normalerweise die falsche Form.
- Isolierte Cron-Ausführungen und Subagent-Abschlüsse bereinigen nach bestem Aufwand nachverfolgte Browser-Tabs/Prozesse für ihre untergeordnete Sitzung vor der abschließenden Bereinigungsbuchhaltung.
- Isolierte Cron-Zustellung unterdrückt veraltete Zwischenantworten des übergeordneten Agenten, während nachgelagerte Subagent-Arbeit noch ausläuft, und bevorzugt die finale Ausgabe von Nachkommen, wenn diese vor der Zustellung eintrifft.
- Abschlussbenachrichtigungen werden direkt an einen Kanal zugestellt oder für den nächsten Heartbeat in die Warteschlange gestellt.
openclaw tasks listzeigt alle Aufgaben;openclaw tasks auditdeckt Probleme auf.- Terminale Einträge werden 7 Tage lang aufbewahrt und dann automatisch bereinigt.
Schnellstart
Auflisten und filtern
# List all tasks (newest first)openclaw tasks list # Filter by runtime or statusopenclaw tasks list --runtime acpopenclaw tasks list --status runningPrüfen
# Show details for a specific task (by ID, run ID, or session key)openclaw tasks show <lookup>Abbrechen und benachrichtigen
# Cancel a running task (kills the child session)openclaw tasks cancel <lookup> # Change notification policy for a taskopenclaw tasks notify <lookup> state_changesAudit und Wartung
# Run a health auditopenclaw tasks audit # Preview or apply maintenanceopenclaw tasks maintenanceopenclaw tasks maintenance --applyAufgabenfluss
# Inspect TaskFlow stateopenclaw tasks flow listopenclaw tasks flow show <lookup>openclaw tasks flow cancel <lookup>Was eine Aufgabe erstellt
| Quelle | Laufzeittyp | Wann ein Aufgabeneintrag erstellt wird | Standard-Benachrichtigungsrichtlinie |
|---|---|---|---|
| ACP-Hintergrundläufe | acp |
Starten einer untergeordneten ACP-Sitzung | done_only |
| Subagent-Orchestrierung | subagent |
Starten eines Subagents über sessions_spawn |
done_only |
| Cron-Jobs (alle Typen) | cron |
Jede Cron-Ausführung (Hauptsitzung und isoliert) | silent |
| CLI-Vorgänge | cli |
openclaw agent-Befehle, die über den Gateway laufen |
silent |
| Agent-Medienjobs | cli |
Sitzungsbasierte music_generate/video_generate-Läufe |
silent |
Benachrichtigungsstandards für Cron und Medien
Cron-Aufgaben in der Hauptsitzung verwenden standardmäßig die Benachrichtigungsrichtlinie silent - sie erstellen Einträge zur Nachverfolgung, erzeugen aber keine Benachrichtigungen. Isolierte Cron-Aufgaben verwenden ebenfalls standardmäßig silent, sind aber sichtbarer, weil sie in ihrer eigenen Sitzung laufen.
Sitzungsbasierte music_generate- und video_generate-Läufe verwenden ebenfalls die Benachrichtigungsrichtlinie silent. Sie erstellen weiterhin Aufgabeneinträge, aber der Abschluss wird als interner Wake an die ursprüngliche Agent-Sitzung zurückgegeben, damit der Agent die Folgenachricht schreiben und die fertigen Medien selbst anhängen kann. Abschlüsse in Gruppen/Kanälen folgen der normalen Richtlinie für sichtbare Antworten, daher verwendet der Agent das Nachrichten-Tool, wenn die Quellzustellung dies erfordert. Wenn der Abschluss-Agent in einer reinen Tool-Route keinen Zustellnachweis über das Nachrichten-Tool erzeugt, sendet OpenClaw den Abschluss-Fallback direkt an den ursprünglichen Kanal, statt die Medien privat zu lassen.
Schutzregel für gleichzeitige video_generate-Läufe
Während eine sitzungsbasierte video_generate-Aufgabe noch aktiv ist, fungiert das Tool auch als Schutzregel: Wiederholte video_generate-Aufrufe in derselben Sitzung geben den Status der aktiven Aufgabe zurück, statt eine zweite gleichzeitige Generierung zu starten. Verwenden Sie action: "status", wenn Sie von Agent-Seite eine explizite Fortschritts-/Statusabfrage wünschen.
Was keine Aufgaben erstellt
- Heartbeat-Turns - Hauptsitzung; siehe Heartbeat
- Normale interaktive Chat-Turns
- Direkte
/command-Antworten
Aufgabenlebenszyklus
stateDiagram-v2
[*] --> queued
queued --> running : agent starts
running --> succeeded : completes ok
running --> failed : error
running --> timed_out : timeout exceeded
running --> cancelled : operator cancels
queued --> lost : session gone > 5 min
running --> lost : session gone > 5 min| Status | Bedeutung |
|---|---|
queued |
Erstellt, wartet darauf, dass der Agent startet |
running |
Agent-Turn wird aktiv ausgeführt |
succeeded |
Erfolgreich abgeschlossen |
failed |
Mit einem Fehler abgeschlossen |
timed_out |
Konfiguriertes Timeout überschritten |
cancelled |
Vom Operator über openclaw tasks cancel gestoppt |
lost |
Die Laufzeit hat nach einer Nachfrist von 5 Minuten den autoritativen Hintergrundstatus verloren |
Übergänge erfolgen automatisch - wenn der zugehörige Agent-Lauf endet, wird der Aufgabenstatus entsprechend aktualisiert.
Der Abschluss des Agent-Laufs ist für aktive Aufgabeneinträge maßgeblich. Ein erfolgreicher losgelöster Lauf wird als succeeded finalisiert, gewöhnliche Laufzeitfehler werden als failed finalisiert, und Timeout- oder Abbruchergebnisse werden als timed_out finalisiert. Wenn ein Operator die Aufgabe bereits abgebrochen hat oder die Laufzeit bereits einen stärkeren terminalen Status wie failed, timed_out oder lost aufgezeichnet hat, stuft ein späteres Erfolgssignal diesen terminalen Status nicht herab.
lost ist laufzeitbewusst:
- ACP-Aufgaben: Metadaten der zugrunde liegenden untergeordneten ACP-Sitzung sind verschwunden.
- Subagent-Aufgaben: Die zugrunde liegende untergeordnete Sitzung ist aus dem Ziel-Agent-Speicher verschwunden.
- Cron-Aufgaben: Die Cron-Laufzeit verfolgt den Job nicht mehr als aktiv und die persistente Cron-Ausführungshistorie zeigt kein terminales Ergebnis für diesen Lauf. Der Offline-CLI- Audit behandelt seinen eigenen leeren prozessinternen Cron-Laufzeitstatus nicht als autoritativ.
- CLI-Aufgaben: Aufgaben mit einer Lauf-ID/Quell-ID verwenden den Live-Laufkontext, sodass
verbleibende Zeilen für untergeordnete Sitzungen oder Chat-Sitzungen sie nicht aktiv halten, nachdem der
vom Gateway besessene Lauf verschwunden ist. Legacy-CLI-Aufgaben ohne Laufidentität fallen weiterhin
auf die untergeordnete Sitzung zurück. Gateway-gestützte
openclaw agent-Läufe finalisieren ebenfalls aus ihrem Laufergebnis, sodass abgeschlossene Läufe nicht aktiv bleiben, bis der Sweeper sie alslostmarkiert.
Zustellung und Benachrichtigungen
Wenn eine Aufgabe einen terminalen Status erreicht, benachrichtigt OpenClaw Sie. Es gibt zwei Zustellwege:
Direkte Zustellung - wenn die Aufgabe ein Kanalziel hat (den requesterOrigin), geht die Abschlussnachricht direkt an diesen Kanal (Telegram, Discord, Slack usw.). Aufgabenabschlüsse in Gruppen und Kanälen werden stattdessen über die anfragende Sitzung geleitet, damit der übergeordnete Agent die sichtbare Antwort schreiben kann. Bei Subagent-Abschlüssen bewahrt OpenClaw außerdem gebundenes Thread-/Topic-Routing, wenn verfügbar, und kann ein fehlendes to / Konto aus der gespeicherten Route der anfragenden Sitzung (lastChannel / lastTo / lastAccountId) ergänzen, bevor die direkte Zustellung aufgegeben wird.
Sitzungs-Warteschlangenzustellung - wenn die direkte Zustellung fehlschlägt oder kein Ursprung gesetzt ist, wird die Aktualisierung als Systemereignis in die Sitzung des Anfragenden gestellt und erscheint beim nächsten Heartbeat.
Das bedeutet, der übliche Workflow ist push-basiert: Starten Sie losgelöste Arbeit einmal und lassen Sie dann die Laufzeit Sie beim Abschluss wecken oder benachrichtigen. Fragen Sie den Aufgabenstatus nur ab, wenn Sie Debugging, Eingriff oder einen expliziten Audit benötigen.
Benachrichtigungsrichtlinien
Steuern Sie, wie viel Sie zu jeder Aufgabe hören:
| Richtlinie | Was zugestellt wird |
|---|---|
done_only (Standard) |
Nur terminaler Status (succeeded, failed usw.) - dies ist der Standard |
state_changes |
Jeder Statusübergang und jede Fortschrittsaktualisierung |
silent |
Gar nichts |
Ändern Sie die Richtlinie, während eine Aufgabe läuft:
openclaw tasks notify <lookup> state_changesCLI-Referenz
tasks list
openclaw tasks list [--runtime <acp|subagent|cron|cli>] [--status <status>] [--json]Ausgabespalten: Aufgaben-ID, Art, Status, Zustellung, Lauf-ID, untergeordnete Sitzung, Zusammenfassung.
tasks show
openclaw tasks show <lookup>Das Lookup-Token akzeptiert eine Aufgaben-ID, Lauf-ID oder einen Sitzungsschlüssel. Zeigt den vollständigen Eintrag einschließlich Timing, Zustellstatus, Fehler und terminaler Zusammenfassung.
tasks cancel
openclaw tasks cancel <lookup>Bei ACP- und Subagent-Aufgaben beendet dies die untergeordnete Sitzung. Bei CLI-verfolgten Aufgaben wird der Abbruch in der Aufgabenregistrierung aufgezeichnet (es gibt keinen separaten untergeordneten Laufzeit-Handle). Der Status wechselt zu cancelled und eine Zustellbenachrichtigung wird gesendet, sofern zutreffend.
tasks notify
openclaw tasks notify <lookup> <done_only|state_changes|silent>tasks audit
openclaw tasks audit [--json]Deckt betriebliche Probleme auf. Befunde erscheinen auch in openclaw status, wenn Probleme erkannt werden.
| Ergebnis | Schweregrad | Auslöser |
|---|---|---|
stale_queued |
warn | Seit mehr als 10 Minuten in der Warteschlange |
stale_running |
error | Läuft seit mehr als 30 Minuten |
lost |
warn/error | Runtime-gestützte Aufgabenverantwortung ist verschwunden; beibehaltene verlorene Aufgaben warnen bis cleanupAfter und werden dann zu Fehlern |
delivery_failed |
warn | Zustellung fehlgeschlagen und Benachrichtigungsrichtlinie ist nicht silent |
missing_cleanup |
warn | Terminale Aufgabe ohne Cleanup-Zeitstempel |
inconsistent_timestamps |
warn | Zeitachsenverletzung (zum Beispiel vor dem Start beendet) |
tasks maintenance
openclaw tasks maintenance [--json]openclaw tasks maintenance --apply [--json]Verwenden Sie dies, um Abgleich, Cleanup-Stempelung und Bereinigung für Aufgaben, Task Flow-Status und veraltete Registry-Zeilen für Cron-Ausführungssitzungen vorab anzuzeigen oder anzuwenden.
Der Abgleich ist runtime-bewusst:
- ACP-/Subagent-Aufgaben prüfen ihre zugrunde liegende untergeordnete Sitzung.
- Subagent-Aufgaben, deren untergeordnete Sitzung einen Tombstone für Neustart-Wiederherstellung hat, werden als verloren markiert, statt als wiederherstellbare zugrunde liegende Sitzungen behandelt zu werden.
- Cron-Aufgaben prüfen, ob die Cron-Runtime den Job weiterhin besitzt, und stellen dann den terminalen Status aus persistierten Cron-Ausführungsprotokollen/dem Job-Status wieder her, bevor sie auf
lostzurückfallen. Nur der Gateway-Prozess ist für die aktive In-Memory-Job-Menge von Cron maßgeblich; ein Offline-CLI-Audit verwendet dauerhafte Historie, markiert eine Cron-Aufgabe aber nicht allein deshalb als verloren, weil dieses lokale Set leer ist. - CLI-Aufgaben mit Ausführungsidentität prüfen den besitzenden Live-Ausführungskontext, nicht nur Zeilen von untergeordneten Sitzungen oder Chat-Sitzungen.
Auch der Abschluss-Cleanup ist runtime-bewusst:
- Subagent-Abschluss schließt nach bestem Bemühen nachverfolgte Browser-Tabs/Prozesse für die untergeordnete Sitzung, bevor der Ankündigungs-Cleanup fortgesetzt wird.
- Isolierter Cron-Abschluss schließt nach bestem Bemühen nachverfolgte Browser-Tabs/Prozesse für die Cron-Sitzung, bevor die Ausführung vollständig heruntergefahren wird.
- Isolierte Cron-Zustellung wartet bei Bedarf auf nachgelagerte Subagent-Folgeaktionen und unterdrückt veralteten Bestätigungstext des übergeordneten Elements, statt ihn anzukündigen.
- Die Zustellung bei Subagent-Abschluss bevorzugt den neuesten sichtbaren Assistententext; wenn dieser leer ist, fällt sie auf bereinigten neuesten Tool-/toolResult-Text zurück, und reine Timeout-Tool-Call-Ausführungen können zu einer kurzen Teilfortschrittszusammenfassung zusammengefasst werden. Terminal fehlgeschlagene Ausführungen kündigen den Fehlerstatus an, ohne erfassten Antworttext erneut wiederzugeben.
- Cleanup-Fehler verdecken nicht das tatsächliche Aufgabenergebnis.
Beim Anwenden der Wartung entfernt OpenClaw außerdem veraltete Registry-Zeilen für Sitzungen vom Typ cron:<jobId>:run:<uuid>, die älter als 7 Tage sind, bewahrt dabei Zeilen für aktuell laufende Cron-Jobs und lässt Nicht-Cron-Sitzungszeilen unverändert.
tasks flow list | show | cancel
openclaw tasks flow list [--status <status>] [--json]openclaw tasks flow show <lookup> [--json]openclaw tasks flow cancel <lookup>Verwenden Sie diese Befehle, wenn der orchestrierende Task Flow für Sie relevant ist und nicht ein einzelner Hintergrundaufgabeneintrag.
Chat-Aufgabenboard (/tasks)
Verwenden Sie /tasks in einer beliebigen Chat-Sitzung, um Hintergrundaufgaben zu sehen, die mit dieser Sitzung verknüpft sind. Das Board zeigt aktive und kürzlich abgeschlossene Aufgaben mit Runtime, Status, Zeitangaben sowie Fortschritts- oder Fehlerdetails.
Wenn die aktuelle Sitzung keine sichtbaren verknüpften Aufgaben hat, fällt /tasks auf agent-lokale Aufgabenzählungen zurück, sodass Sie weiterhin einen Überblick erhalten, ohne Details anderer Sitzungen offenzulegen.
Für das vollständige Operator-Ledger verwenden Sie die CLI: openclaw tasks list.
Statusintegration (Aufgabendruck)
openclaw status enthält eine Aufgabenübersicht auf einen Blick:
Tasks: 3 queued · 2 running · 1 issuesDie Zusammenfassung meldet:
- active - Anzahl von
queued+running - failures - Anzahl von
failed+timed_out+lost - byRuntime - Aufschlüsselung nach
acp,subagent,cron,cli
Sowohl /status als auch das Tool session_status verwenden einen Cleanup-bewussten Aufgaben-Snapshot: Aktive Aufgaben werden bevorzugt, veraltete abgeschlossene Zeilen werden ausgeblendet, und aktuelle Fehler werden nur angezeigt, wenn keine aktive Arbeit verbleibt. Dadurch bleibt die Statuskarte auf das fokussiert, was gerade wichtig ist.
Speicherung und Wartung
Wo Aufgaben gespeichert werden
Aufgabeneinträge bleiben in SQLite bestehen unter:
$OPENCLAW_STATE_DIR/tasks/runs.sqliteDie Registry wird beim Gateway-Start in den Arbeitsspeicher geladen und synchronisiert Schreibvorgänge mit SQLite, um Dauerhaftigkeit über Neustarts hinweg zu gewährleisten.
Der Gateway hält das SQLite-Write-Ahead-Log begrenzt, indem er den standardmäßigen Autocheckpoint-Schwellenwert von SQLite sowie regelmäßige und Shutdown-TRUNCATE-Checkpoints verwendet.
Automatische Wartung
Ein Sweeper läuft alle 60 Sekunden und erledigt vier Dinge:
Abgleich
Prüft, ob aktive Aufgaben weiterhin eine maßgebliche Runtime-Grundlage haben. ACP-/Subagent-Aufgaben verwenden den Status untergeordneter Sitzungen, Cron-Aufgaben verwenden Active-Job-Eigentum, und CLI-Aufgaben mit Ausführungsidentität verwenden den besitzenden Ausführungskontext. Wenn dieser zugrunde liegende Status länger als 5 Minuten verschwunden ist, wird die Aufgabe als lost markiert.
ACP-Sitzungsreparatur
Schließt terminale oder verwaiste parent-owned One-Shot-ACP-Sitzungen und schließt veraltete terminale oder verwaiste persistente ACP-Sitzungen nur, wenn keine aktive Gesprächsbindung verbleibt.
Cleanup-Stempelung
Setzt einen cleanupAfter-Zeitstempel auf terminale Aufgaben (endedAt + 7 Tage). Während der Aufbewahrung erscheinen verlorene Aufgaben im Audit weiterhin als Warnungen; nachdem cleanupAfter abläuft oder wenn Cleanup-Metadaten fehlen, sind sie Fehler.
Bereinigung
Löscht Einträge nach ihrem cleanupAfter-Datum.
Wie Aufgaben mit anderen Systemen zusammenhängen
Aufgaben und Task Flow
Task Flow ist die Flow-Orchestrierungsschicht oberhalb von Hintergrundaufgaben. Ein einzelner Flow kann über seine Lebensdauer hinweg mehrere Aufgaben mithilfe verwalteter oder gespiegelter Synchronisierungsmodi koordinieren. Verwenden Sie openclaw tasks, um einzelne Aufgabeneinträge zu prüfen, und openclaw tasks flow, um den orchestrierenden Flow zu prüfen.
Siehe Task Flow für Details.
Aufgaben und Cron
Eine Cron-Job-Definition befindet sich in ~/.openclaw/cron/jobs.json; der Runtime-Ausführungsstatus befindet sich daneben in ~/.openclaw/cron/jobs-state.json. Jede Cron-Ausführung erstellt einen Aufgabeneintrag - sowohl Hauptsitzung als auch isoliert. Cron-Aufgaben in Hauptsitzungen verwenden standardmäßig die Benachrichtigungsrichtlinie silent, sodass sie nachverfolgen, ohne Benachrichtigungen zu erzeugen.
Siehe Cron Jobs.
Aufgaben und Heartbeat
Heartbeat-Ausführungen sind Hauptsitzungs-Turns - sie erstellen keine Aufgabeneinträge. Wenn eine Aufgabe abgeschlossen wird, kann sie ein Heartbeat-Wecken auslösen, damit Sie das Ergebnis zeitnah sehen.
Siehe Heartbeat.
Aufgaben und Sitzungen
Eine Aufgabe kann auf einen childSessionKey (wo die Arbeit läuft) und einen requesterSessionKey (wer sie gestartet hat) verweisen. Sitzungen sind Gesprächskontext; Aufgaben sind Aktivitätsnachverfolgung darauf.
Aufgaben und Agent-Ausführungen
Die runId einer Aufgabe verweist auf die Agent-Ausführung, die die Arbeit erledigt. Agent-Lebenszyklusereignisse (Start, Ende, Fehler) aktualisieren automatisch den Aufgabenstatus - Sie müssen den Lebenszyklus nicht manuell verwalten.
Verwandte Themen
- Automatisierung - alle Automatisierungsmechanismen auf einen Blick
- CLI: Aufgaben - CLI-Befehlsreferenz
- Heartbeat - regelmäßige Hauptsitzungs-Turns
- Geplante Aufgaben - Hintergrundarbeit planen
- Task Flow - Flow-Orchestrierung oberhalb von Aufgaben