TaskFlow ist das Werkzeug für den Moment, in dem aus einem einzelnen Background Job ein echter Workflow wird. Wenn ein einfacher Task ein einzelner Lieferwagen mit einer Lieferung ist, dann ist TaskFlow die Disposition, die die ganze Route, Übergaben, Verzögerungen und die Frage verfolgt, ob der nächste Wagen überhaupt losfahren sollte.
Genau dort liegt der Unterschied. OpenClaw hat bereits Cron für Timing und Tasks als Datensätze für losgelöste Arbeit. TaskFlow sitzt darüber, wenn deine Automatisierung mehrere abhängige Schritte hat und du nicht willst, dass Fortschritt verschwindet, nur weil das Gateway im falschen Moment neu startet.
Laut offizieller OpenClaw-Dokumentation ist TaskFlow die Flow-Orchestrierungsschicht über Background Tasks. Sie verwaltet dauerhafte mehrstufige Flows, verfolgt eigenen State und Revisionen und hält die Sync-Semantik sauber, während einzelne Tasks weiter die eigentliche Einheit losgelöster Arbeit bleiben.
Wofür TaskFlow eigentlich gedacht ist
Die meiste Verwirrung beginnt genau hier. Menschen hören "Workflow" und denken, jede Automatisierung brauche das. Das wäre ungefähr so, als würdest du ein komplettes Lagerverwaltungssystem nutzen, um einen einzigen Brief zu verschicken.
TaskFlow ist für Arbeit wie diese gedacht:
- Schritt A muss fertig sein, bevor Schritt B startet
- einige Schritte brauchen Waits, Freigaben oder Retries
- Child Tasks laufen im Hintergrund und melden sich später zurück
- du brauchst dauerhaften Fortschritt über Gateway-Neustarts hinweg
- du willst einen Ort, an dem du den ganzen Lauf prüfen oder abbrechen kannst
Wenn das nach deiner Automatisierung klingt, gehört TaskFlow wahrscheinlich ins Design.
Wo es in echten Automatisierungen hineinpasst
Das saubere Denkmodell ist simpel:
- Cron: entscheidet, wann die Arbeit startet
- TaskFlow: entscheidet, wie der mehrstufige Lauf voranschreitet
- Tasks: protokollieren jede losgelöste Arbeitseinheit
Denk an einen Flughafen. Cron ist der Flugplan. Ein einfacher Task ist eine einzelne Flugbewegung. TaskFlow ist der Tower, der dafür sorgt, dass Starts, Landungen, Gates und Übergaben in der richtigen Reihenfolge laufen und sich nicht gegenseitig in die Quere kommen.
Ein gutes Beispiel ist ein tägliches Marktbriefing. Der Zeitplan gehört in Cron. Der eigentliche Lauf braucht vielleicht einen Preflight-Check, Datensammlung, Zusammenfassung, Freigabe und Auslieferung. Das ist TaskFlow-Gelände, weil jede Stufe von der vorherigen abhängt und die ganze Kette dauerhaft sichtbar bleiben muss.
Was State, Waits und Child Tasks dir bringen
Hier hört TaskFlow auf, abstrakt zu klingen, und beginnt seinen Job zu machen.
Dauerhafter State
TaskFlow speichert den Fortschritt des Workflows getrennt vom live laufenden Chat-Turn. Wenn das Gateway mitten in einer langen Sequenz neu startet, weiß der Flow trotzdem noch, was schon erledigt ist und was noch fehlt. Das zählt bei jedem Workflow, den du ungern von vorn starten würdest.
Waits
Manche Arbeit pausiert ganz natürlich. Vielleicht wartest du auf einen Subagenten, einen Browser-Schritt, menschliche Freigabe oder ein externes System. Mit TaskFlow ist diese Pause ein offizieller Teil des Workflows statt einer fragilen Improvisation im Prompt.
Child Tasks
Flows koordinieren Tasks, sie ersetzen sie nicht. Ein Flow kann über seine Laufzeit mehrere losgelöste Tasks starten, verfolgen, welcher zu welchem Schritt gehört, und den größeren Lauf verständlich halten. Das ist deutlich sauberer, als hinterher mehrere unabhängige Background Jobs im Kopf zusammenzusetzen.
Managed Mode vs. Mirrored Mode
Die OpenClaw-Dokumentation beschreibt zwei Sync-Modi und der Unterschied ist wichtig.
Managed Mode
TaskFlow besitzt den gesamten Lebenszyklus. Es erstellt die Child Tasks, schiebt den Flow automatisch weiter und entscheidet, wann der nächste Schritt beginnen darf. Nutze das, wenn TaskFlow der eigentliche Dirigent des Workflows ist.
Mirrored Mode
TaskFlow beobachtet extern erstellte Tasks und hält den Flow-State synchron, ohne die Erstellung selbst zu besitzen. Das ist nützlich, wenn Jobs bereits aus einer anderen Quelle kommen, etwa Cron oder CLI-Operationen, du aber trotzdem einen gemeinsamen Flow-Blick willst.
Die kurze Merkhilfe lautet: Managed Mode spielt das Stück, Mirrored Mode beobachtet die Anzeigetafel.
Warum Revision Tracking nützlicher ist, als es klingt
Revision Tracking klingt nach langweiliger Infrastruktur, bis zwei verschiedene Dinge gleichzeitig denselben Flow weiterschieben wollen. Dann ist es plötzlich der Grund, warum dein Workflow nicht in Unsinn abdriftet.
OpenClaw nutzt Revision Tracking zur Konflikterkennung. Das heißt, gleichzeitige Updates an einem Flow werden absichtlich behandelt, statt sich stillschweigend gegenseitig zu überschreiben. Wenn du mehrere Background-Akteure koordinierst, ist diese Leitplanke Gold wert.
Wann TaskFlow besser ist als einfache Cron-Jobs oder stehende Anweisungen
Stehende Anweisungen definieren Befugnisse. Cron definiert Timing. Keines von beidem gibt dir allein dauerhafte mehrstufige Orchestrierung.
- Nutze stehende Anweisungen, wenn das Hauptproblem ist, was der Agent wiederholt tun darf.
- Nutze Cron, wenn das Hauptproblem ist, wann etwas passieren soll.
- Nutze TaskFlow, wenn das Hauptproblem ist, mehrere abhängige Schritte nach dem Start zu koordinieren.
In der Praxis nutzen die stärksten Automatisierungen oft alle drei zusammen. Stehende Anweisungen geben die Regeln. Cron weckt den Lauf. TaskFlow hält die beweglichen Teile in einer Spur.
Beispielaufbau: geplanter Workflow mit Preflight und Freigabe
Die offizielle Doku empfiehlt, Zeitplan, Orchestrierung und Reliability Checks in Schichten zu trennen. Das ist vernünftig. Timing sollte nicht der Ort sein, an dem deine komplette Workflow-Logik lebt.
openclaw cron add --name "market-intel-brief" --cron "0 7 * * 1-5" --tz "Europe/Berlin" --session session:market-intel --message "Run the market-intel workflow. Verify source freshness before summarizing."Dieser Cron-Job sollte den Workflow nur starten. Innerhalb des Flows könnten die Schritte eher so aussehen:
1. preflight: Browser, Credentials, Quota und Netzwerk prüfen
2. collect: Quelldaten als strukturiertes JSON einsammeln
3. summarize: Briefing aus sauberen Inputs erzeugen
4. approve: Auslieferung prüfen und bei Bedarf Freigabe verlangen
5. deliver: nur veröffentlichen, wenn die Freigabe vorliegtGenau darin liegt der Wert von TaskFlow. Jeder Schritt hat einen klaren Job. Jede Übergabe ist explizit. Jeder Fehler hat einen vernünftigen Ort.
Wann TaskFlow übertrieben ist
Das ist der Teil, den viele hören müssen. Nicht jede Automatisierung verdient Orchestrierungs-Maschinerie.
- Eine einmalige Erinnerung braucht kein TaskFlow.
- Ein einzelner Background-Analyse-Lauf braucht meist kein TaskFlow.
- Ein Cron-Job, der nur einen Bericht sendet und endet, braucht oft kein TaskFlow.
- Ein einfacher Heartbeat-Check braucht ganz sicher kein TaskFlow.
Wenn es keine sinnvollen Verzweigungen, Waits, Retries oder abhängigen Stufen gibt, ist ein einfacher Task leichter zu lesen und leichter zu debuggen. Das beste Workflow-Tool ist oft das, das du nicht überstrapazierst.
Operative Gewohnheiten, die TaskFlow lohnend machen
- Halte Schrittgrenzen offensichtlich
- Führe Preflight-Checks vor teurer Modellarbeit aus
- Übergib nach Möglichkeit strukturierte Daten zwischen den Schritten
- Nutze Freigaben für riskante externe Auslieferung
- Prüfe beim Debugging Flows und Tasks getrennt
- Brich den ganzen Flow ab, wenn das übergeordnete Ziel nicht mehr gilt
Gerade der letzte Punkt zählt. OpenClaw kann einen laufenden Flow samt aktiver Tasks abbrechen. Wenn das Geschäftsziel tot ist, stoppe die ganze Kette. Lass veraltete Automatisierung nicht aus Gewohnheit weiterlaufen.
Die praktische Faustregel
Wenn deine Automatisierung als ein einzelner losgelöster Job beschrieben werden kann, nutze einen Task. Wenn sie eher nach "zuerst das, dann das, dann warten, dann vielleicht freigeben, dann ausliefern" klingt, nimm TaskFlow.
Das ist im Kern schon alles. TaskFlow ist nicht da, damit OpenClaw mehr nach Enterprise klingt. Es ist da, damit mehrstufige Arbeit dauerhaft, prüfbar und weniger fragil bleibt, wenn der Alltag den Lauf unterbricht.
Need help from people who already use this stuff?
Du willst einen Workflow bauen, der nächste Woche nicht auseinanderfällt?
Komm in My AI Agent Profit Lab, wenn du Hilfe dabei willst, zwischen Cron, stehenden Anweisungen, Tasks und TaskFlow sauber zu wählen, ohne dein Setup in ein fragiles Automatisierungsmuseum zu verwandeln.
FAQ
Was ist TaskFlow in OpenClaw?
TaskFlow ist die dauerhafte Workflow-Schicht von OpenClaw für mehrstufige Hintergrundarbeit. Sie sitzt über einfachen Background Tasks und verfolgt Flow-State, Revisionen, Abbruchsignale, Waits und Fortschritt zwischen einzelnen Schritten auch über Gateway-Neustarts hinweg.
Wann sollte ich TaskFlow statt eines einfachen Tasks nutzen?
Nutze einen einfachen Task für einen einzelnen losgelösten Job. Nutze TaskFlow, wenn der Job mehrere abhängige Schritte, Wartepunkte, Freigaben, Retries oder Child Tasks hat, die über Zeit koordiniert bleiben müssen.
Ist TaskFlow dasselbe wie Cron?
Nein. Cron beantwortet, wann Arbeit starten soll. TaskFlow beantwortet, wie ein mehrstufiger Lauf nach dem Start voranschreitet. Ein typisches Muster ist: Cron für das Timing, TaskFlow für die Orchestrierung und Tasks als Datensätze für die einzelnen losgelösten Schritte.
Was sind Managed und Mirrored Mode?
Im Managed Mode erstellt und steuert TaskFlow die Child Tasks selbst. Im Mirrored Mode beobachtet TaskFlow Tasks, die anderswo erstellt wurden, und hält nur den gemeinsamen Flow-Blick synchron, ohne die Task-Erstellung zu besitzen.
Wann ist TaskFlow übertrieben?
Es ist übertrieben, wenn du nur einen einzelnen Background Run, eine exakte Erinnerung oder einen simplen wiederkehrenden Cron-Prompt brauchst. Wenn es keine sinnvollen Handoffs, Waits, Verzweigungen oder Retries gibt, sind einfache Tasks oder Cron leichter wartbar.