Wann Task Flow verwendet werden sollte
Synchronisierungsmodi
Verwalteter Modus
Ein verwalteter Flow verfügt über 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 Anfordernden werden an untergeordnete Aufgaben weitergegeben.
- Der Controller überführt den Flow zwischen
running,waitingund Endzuständen und speichert einen beliebigen JSON-Schrittzustand im Flow-Datensatz. - Bei jeder Änderung wird die erwartete Revision des Flows übergeben. Ein Schreibvorgang mit veralteter Revision wird als Revisionskonflikt abgelehnt, statt einen neueren Zustand zu überschreiben.
- Sobald eine Abbrechung angefordert wurde, werden neue untergeordnete Aufgaben abgelehnt, und der Flow wird als
cancelledabgeschlossen, wenn keine untergeordnete Aufgabe mehr aktiv ist.
Gespiegelter Modus
OpenClaw erstellt automatisch einen gespiegelten Flow mit einer Aufgabe, wenn ein entkoppelter ACP- oder Subagent-Lauf beginnt (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 Synchronisierungsmodustask_mirrored an.
Flow-Status
Dauerhafter Zustand und Revisionsverfolgung
Flow-Datensätze werden gemeinsam mit Aufgabendatensätzen in der gemeinsam genutzten SQLite-Zustandsdatenbank (~/.openclaw/state/openclaw.sqlite, Tabelle flow_runs) gespeichert, sodass der Fortschritt Gateway-Neustarts übersteht. Jeder Schreibvorgang erhöht revision des Flows; gleichzeitige Schreibende, die eine veraltete erwartete Revision übergeben, erhalten einen Konflikt und müssen die Daten erneut lesen. Das WAL-Wachstum wird durch automatische SQLite-Checkpoints sowie regelmäßige passive Checkpoints begrenzt; beim Herunterfahren werden Truncate-Checkpoints ausgeführt. Die veraltete flows/registry.sqlite-Begleitdatei aus älteren Installationen wird durch 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 – entweder sofort oder durch den Wartungsdurchlauf, falls die Beendigung der untergeordneten Aufgaben länger dauert. Die Absicht wird gespeichert, sodass ein abgebrochener Flow auch dann abgebrochen bleibt, wenn das Gateway neu startet, bevor alle untergeordneten Aufgaben beendet wurden.
CLI-Befehle
Flows werden außerdem von
openclaw tasks audit (Feststellungen zu veralteten oder beschädigten Flows) und openclaw tasks maintenance (schließt festhängende Abbrüche ab und entfernt Endzustands-Flows nach 7 Tagen) berücksichtigt.
Muster für zuverlässige geplante Workflows
Behandeln Sie bei wiederkehrenden Workflows wie Marktanalyse-Briefings die Planung, Orchestrierung und Zuverlässigkeitsprüfungen als getrennte Schichten:- Verwenden Sie Geplante Aufgaben für die zeitliche Planung.
- Verwenden Sie eine persistente Cron-Sitzung, wenn der Workflow auf vorherigem Kontext aufbauen soll.
- Verwenden Sie Lobster für deterministische Schritte, Genehmigungsschranken und Fortsetzungstoken.
- Verwenden Sie Task Flow, um den mehrstufigen Lauf über untergeordnete Aufgaben, Wartezeiten, Wiederholungen und Gateway-Neustarts hinweg zu verfolgen.
--session session:<id> anstelle von isolated, wenn der wiederkehrende Workflow einen gezielt aufgebauten Verlauf, Zusammenfassungen vorheriger 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 Zuverlässigkeitsprüfungen innerhalb des Workflows vor dem LLM-Zusammenfassungsschritt:
- Browser-Verfügbarkeit und Profilauswahl, beispielsweise
openclawfür einen verwalteten Zustand oderuser, 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, etwa
lobster,browserundllm-task. - Für Cron konfiguriertes Fehlerziel, damit Fehler bei Vorabprüfungen sichtbar sind. Siehe Geplante Aufgaben.
sourceUrl, retrievedAt und asOf in seiner Ausgabe beizubehalten. Verwenden Sie LLM-Aufgabe, wenn Sie innerhalb des Workflows einen schemavalidierten Modellschritt benötigen.
Verpacken Sie bei wiederverwendbaren Team- oder Community-Workflows die CLI, die .lobster-Dateien und sämtliche Einrichtungshinweise als Skill oder Plugin und veröffentlichen Sie das Paket über ClawHub. Behalten Sie Workflow-spezifische Schutzmechanismen in diesem Paket, sofern der Plugin-API keine benötigte generische Funktion fehlt.
Beziehung zwischen Flows und Aufgaben
Flows koordinieren Aufgaben, sie ersetzen sie nicht. Ein einzelner Flow kann während seiner Lebensdauer mehrere Hintergrundaufgaben steuern. Verwenden Sieopenclaw tasks, um einzelne Aufgabendatensätze zu prüfen, und openclaw tasks flow, um den orchestrierenden Flow zu prüfen.
Verwandte Themen
- Hintergrundaufgaben – das Verzeichnis entkoppelter Arbeiten, die von Flows koordiniert werden
- 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