Aufgabenablauf

Task Flow ist die Orchestrierungsschicht oberhalb von Hintergrundaufgaben. Ein Flow ist ein dauerhafter Datensatz für mehrstufige Arbeit mit eigenem Status, JSON-Zustand, Revisionszähler und verknüpften Aufgabendatensätzen. Flows überstehen Gateway-Neustarts; einzelne Aufgaben bleiben die Einheit für entkoppelte Arbeit.

Wann Task Flow verwendet werden sollte

Synchronisierungsmodi

Verwalteter Modus

Ein verwalteter Flow besitzt einen Controller: Plugin-Code, der den Flow über die Task-Flow-API der Plugin-Laufzeit mit einem Ziel und einer erforderlichen Controller-ID erstellt und ihn anschließend explizit steuert.

• Jeder Schritt wird als Hintergrundaufgabe ausgeführt, die unter dem Flow erstellt wird; der Eigentümerschlüssel und der Ursprung des Anforderers werden an untergeordnete Aufgaben weitergegeben.
• Der Controller überführt den Flow zwischen running, waiting und Endzuständen und speichert einen beliebigen JSON-Schrittzustand im Flow-Datensatz.
• Jede Änderung übergibt die erwartete Revision des Flows. Ein veralteter Schreibvorgang wird als Revisionskonflikt abgelehnt, anstatt einen neueren Zustand zu überschreiben.
• Sobald ein Abbruch angefordert wurde, werden neue untergeordnete Aufgaben abgelehnt, und der Flow wird als cancelled abgeschlossen, wenn keine untergeordnete Aufgabe mehr aktiv ist.

Beispiel: ein wöchentlicher Berichts-Flow, der (1) Daten erfasst, (2) den Bericht erstellt und (3) ihn zustellt, mit einer Hintergrundaufgabe pro Schritt:

Flow: weekly-report  Schritt 1: gather-data     → Aufgabe erstellt → erfolgreich  Schritt 2: generate-report → Aufgabe erstellt → erfolgreich  Schritt 3: deliver         → Aufgabe erstellt → wird ausgeführt

Gespiegelter Modus

OpenClaw erstellt automatisch einen gespiegelten Flow mit einer Aufgabe, wenn ein entkoppelter ACP- oder Subagent-Lauf gestartet wird (sitzungsbezogene Aufgaben mit zustellbarem Abschluss). Der Flow-Datensatz spiegelt seine einzige zugrunde liegende Aufgabe – Status, Ziel und Zeitangaben –, sodass entkoppelte Starts ohne Controller eine stabile Flow-Kennung für Status- und Wiederholungsoberflächen erhalten. Gespiegelte Flows zeigen in der CLI den Synchronisierungsmodus task_mirrored an.

Flow-Status

Dauerhafter Zustand und Revisionsverfolgung

Flow-Datensätze werden zusammen mit Aufgabendatensätzen in der gemeinsamen SQLite-Zustandsdatenbank (~/.openclaw/state/openclaw.sqlite, Tabelle flow_runs) gespeichert, sodass der Fortschritt Gateway-Neustarts übersteht. Jeder Schreibvorgang erhöht die revision des Flows; gleichzeitige Schreibende, die eine veraltete erwartete Revision übergeben, erhalten einen Konflikt und müssen erneut lesen. Das WAL-Wachstum wird durch automatische SQLite-Checkpoints sowie regelmäßige passive Checkpoints begrenzt; beim Herunterfahren werden Truncate-Checkpoints ausgeführt. Die ältere Sidecar-Datenbank flows/registry.sqlite aus früheren Installationen wird von openclaw doctor importiert.

Abbruchverhalten

openclaw tasks flow cancel setzt eine dauerhafte Abbruchabsicht für den Flow, bricht seine aktiven untergeordneten Aufgaben ab und lehnt neue verwaltete untergeordnete Aufgaben ab. Sobald keine untergeordnete Aufgabe mehr aktiv ist, wird der Flow als cancelled abgeschlossen – sofort oder durch den Wartungsdurchlauf, wenn untergeordnete Aufgaben länger zum Beenden benötigen. Die Absicht wird dauerhaft gespeichert, sodass ein abgebrochener Flow auch dann abgebrochen bleibt, wenn das Gateway neu startet, bevor alle untergeordneten Aufgaben beendet wurden.

CLI-Befehle

# Aktive und kürzlich ausgeführte Flows auflistenopenclaw tasks flow list [--status <status>] [--json] # Details zu einem bestimmten Flow anzeigenopenclaw tasks flow show <lookup> [--json] # Einen laufenden Flow und seine aktiven Aufgaben abbrechenopenclaw tasks flow cancel <lookup>

Flows werden außerdem von openclaw tasks audit (Befunde zu veralteten oder beschädigten Flows) und openclaw tasks maintenance (schließt festhängende Abbrüche ab und entfernt beendete Flows nach 7 Tagen) erfasst.

Muster für zuverlässige geplante Workflows

Behandeln Sie bei wiederkehrenden Workflows wie Marktinformationsbriefings die Zeitplanung, Orchestrierung und Zuverlässigkeitsprüfungen als getrennte Schichten:

1. Verwenden Sie Geplante Aufgaben für die Zeitplanung.
2. Verwenden Sie eine persistente Cron-Sitzung, wenn der Workflow auf vorherigem Kontext aufbauen soll.
3. Verwenden Sie Lobster für deterministische Schritte, Genehmigungssperren und Fortsetzungstoken.
4. Verwenden Sie Task Flow, um den mehrstufigen Lauf über untergeordnete Aufgaben, Wartezeiten, Wiederholungen und Gateway-Neustarts hinweg zu verfolgen.

Beispiel für eine Cron-Struktur:

openclaw cron add \  --name "Marktinformationsbriefing" \  --cron "0 7 * * 1-5" \  --tz "America/New_York" \  --session session:market-intel \  --message "Führen Sie den Lobster-Workflow market-intel aus. Prüfen Sie vor der Zusammenfassung die Aktualität der Quellen." \  --announce \  --channel slack \  --to "channel:C1234567890"

Verwenden Sie --session session:<id> anstelle von isolated, wenn der wiederkehrende Workflow einen bewusst beibehaltenen Verlauf, Zusammenfassungen früherer Läufe oder dauerhaften Kontext benötigt. Verwenden Sie isolated, wenn jeder Lauf ohne vorherigen Kontext beginnen soll und der gesamte erforderliche Zustand explizit im Workflow angegeben ist.

Platzieren Sie im Workflow die Zuverlässigkeitsprüfungen vor dem LLM-Zusammenfassungsschritt:

name: market-intel-briefsteps:  - id: preflight    command: market-intel check --json  - id: collect    command: market-intel collect --json    stdin: $preflight.json  - id: summarize    command: market-intel summarize --json    stdin: $collect.json  - id: approve    command: market-intel deliver --preview    stdin: $summarize.json    approval: required  - id: deliver    command: market-intel deliver --execute    stdin: $summarize.json    condition: $approve.approved

Empfohlene Vorabprüfungen:

• Browser-Verfügbarkeit und Profilauswahl, beispielsweise openclaw für verwalteten Zustand oder user, wenn eine angemeldete Chrome-Sitzung erforderlich ist. Siehe Browser.
• API-Anmeldedaten und Kontingent für jede Quelle.
• Netzwerkerreichbarkeit der erforderlichen Endpunkte.
• Für den Agenten aktivierte erforderliche Werkzeuge wie lobster, browser und llm-task.
• Für Cron konfiguriertes Fehlerziel, damit Fehler bei der Vorabprüfung sichtbar sind. Siehe Geplante Aufgaben.

Empfohlene Datenherkunftsfelder für jedes erfasste Element:

{  "sourceUrl": "https://example.com/report",  "retrievedAt": "2026-04-24T12:00:00Z",  "asOf": "2026-04-24",  "title": "Beispielbericht",  "content": "..."}

Lassen Sie den Workflow veraltete Elemente vor der Zusammenfassung ablehnen oder als veraltet markieren. Der LLM-Schritt sollte ausschließlich strukturiertes JSON erhalten und angewiesen werden, sourceUrl, retrievedAt und asOf in seiner Ausgabe beizubehalten. Verwenden Sie LLM-Aufgabe, wenn Sie innerhalb des Workflows einen schemavalidierten Modellschritt benötigen.

Paketieren Sie für wiederverwendbare Team- oder Community-Workflows die CLI, .lobster-Dateien und alle Einrichtungshinweise als Skill oder Plugin und veröffentlichen Sie das Paket über ClawHub. Belassen Sie Workflow-spezifische Schutzmechanismen in diesem Paket, sofern der Plugin-API keine benötigte generische Fähigkeit fehlt.

Beziehung zwischen Flows und Aufgaben

Flows koordinieren Aufgaben, ersetzen sie jedoch nicht. Ein einzelner Flow kann im Laufe seiner Lebensdauer mehrere Hintergrundaufgaben steuern. Verwenden Sie openclaw tasks, um einzelne Aufgabendatensätze zu untersuchen, und openclaw tasks flow, um den orchestrierenden Flow zu untersuchen.

Verwandte Themen

• Hintergrundaufgaben – das Verzeichnis entkoppelter Arbeit, die von Flows koordiniert wird
• CLI: Aufgaben – CLI-Befehlsreferenz für openclaw tasks flow
• Automatisierungsübersicht – alle Automatisierungsmechanismen auf einen Blick
• Cron-Aufträge – geplante Aufträge, die Flows speisen können