Stell dir OpenClaw-Automation wie eine Werkstatt vor. Eine Wanduhr sagt, wann etwas startet. Ein Schichtleiter merkt, wenn etwas Aufmerksamkeit braucht. Ein Türsensor reagiert, wenn jemand hereinkommt. Ein Klemmbrett hält fest, was erledigt wurde. Ein Produktionsboard koordiniert mehrstufige Jobs. Das Betriebshandbuch legt fest, wer was darf.
Genau so ist hier die Aufteilung. Cron ist die Wanduhr. Heartbeat ist der Schichtleiter. Hooks sind die Türsensoren. Tasks sind das Klemmbrett. Task Flow ist das Produktionsboard. Standing Orders sind das Handbuch.
Die offiziellen Automation-Dokumente und die Scheduled-Tasks-Dokumente laufen auf dieselbe praktische Lektion hinaus: Wähle die Oberfläche, die zum echten Trigger und zum echten Zuverlässigkeitsbedarf passt. Lass Cron nicht alles imitieren, nur weil es das erste Werkzeug war, das du gelernt hast.
Erst die Kurzfassung als Router
| Wenn du brauchst... | Nutze | Warum |
|---|---|---|
| Exaktes Timing | cron | Es plant bewusst und erzeugt immer Task-Records. |
| Ungefähre periodische Aufmerksamkeit | heartbeat | Es führt periodische Main-Session-Turns aus, ohne Task-Records zu erzeugen. |
| Event-getriebene Reaktionen im Gateway | hooks | Sie feuern bei Lifecycle-, Command- und Message-Events. |
| Ein Protokoll für entkoppelte Arbeit | tasks | Tasks verfolgen, was passiert ist. Sie entscheiden nicht, wann etwas läuft. |
| Dauerhafte mehrstufige Orchestrierung | Task Flow | Er koordiniert mehrstufige Abläufe oberhalb einzelner Tasks. |
| Persistente Befugnisse und Regeln | standing orders | Sie definieren, was der Agent über Sessions hinweg tun darf. |
Nutze Cron, wenn Timing wichtiger ist als Stimmung
Cron ist für Präzision da. Eine Erinnerung in 20 Minuten, ein Report jeden Werktag um 7 Uhr, ein Weekly Review jeden Montag, ein webhook-getriggerter isolierter Lauf. Das ist Cron-Gebiet.
Das wichtige Detail, das viele übersehen: Cron beantwortet die Wann-Frage, nicht die ganze Workflow-Frage. Es weckt den Agenten zum richtigen Zeitpunkt, kann Output in Chat oder Webhook liefern, und jede Cron-Ausführung erzeugt einen Background-Task-Record.
Genau das ist operativ wertvoll. Wenn dir Auditierbarkeit, entkoppelte Delivery oder Laufhistorie wichtig sind, bringt Cron diese Spur standardmäßig mit.
Der Cron Execution Style verändert den Charakter des Jobs
| Style | Session-Wert | Gut für |
|---|---|---|
| Main Session | main | Erinnerungen und System-Events, die über die Main Session auftauchen sollen. |
| Isolated | isolated | Hintergrundarbeit, Reports und frische Läufe ohne geerbten Chat-Kontext. |
| Current Session | current | Wiederkehrende Arbeit, die an das Gespräch gebunden bleiben soll, in dem sie erstellt wurde. |
| Custom Session | session:<id> | Workflows, die absichtlich auf früheren Zusammenfassungen oder strukturierter Historie aufbauen sollen. |
Genau hier entsteht viel unnötiger Operator-Schmerz. Menschen sagen: "Cron hat meinen Kontext verloren", meinen aber eigentlich: "Ich habe isolated für einen Workflow gewählt, der eine benannte Session gebraucht hätte." Ein kleiner Unterschied in der Formulierung, ein deutlich nützlicherer Fix.
# exaktes Timing, jeden Morgen frischer Lauf
openclaw cron add --name "Morning brief" --cron "0 7 * * 1-5" --tz "Europe/Berlin" --session isolated --message "Summarize overnight updates." --announce
# exaktes Timing, aber mit absichtlich geteilter Historie
openclaw cron add --name "Weekly project review" --cron "0 9 * * 1" --session session:weekly-review --message "Continue the standing weekly review process."Nutze Heartbeat, wenn sich die Arbeit wie periodische Aufmerksamkeit anfühlen soll
Heartbeat ist kein zweitklassiges Cron. Es ist eine andere Idee.
Heartbeat führt periodische Turns in der Main Session aus, standardmäßig meist alle 30 Minuten. Das Timing ist ungefähr. Der Wert liegt nicht in Präzision. Der Wert liegt darin, dass der Agent Checks bündeln, Background-Abschlüsse bemerken und Relevantes hervorheben kann, ohne für jeden kleinen Blick einen entkoppelten Job zu erzeugen.
- Guter Fit: Inbox-Checks, Kalender-Bewusstsein, Erinnerungen, ruhige Follow-up-Schleifen
- Schlechter Fit: "Starte exakt um 08:00" oder alles, was starke Scheduling-Garantien braucht
Eine kleine, aber wichtige Regel: Heartbeat-Turns erzeugen keine Task-Records. Wenn du ein Protokoll für entkoppelte Arbeit willst, ist Heartbeat die falsche Spur.
Ein guter Merksatz ist: Wenn die Aufgabe wie "behalte das im Blick" klingt, ist Heartbeat oft der richtige erste Gedanke. Wenn sie wie "feuere genau zu diesem Zeitpunkt" klingt, ist es wahrscheinlich Cron.
Tasks sind das Protokoll, nicht der Scheduler
Das ist das Konzept, das am häufigsten plattgebügelt wird. Tasks wirken operativ, also nehmen Anfänger schnell an, Tasks müssten der Ort sein, an dem Arbeit geplant wird. Die Doku ist klar: Tasks sind Records, keine Scheduler.
Sie verfolgen entkoppelte Arbeit wie ACP-Runs, Subagent-Spawns, Cron-Ausführungen und CLI-Operationen. Sie sagen dir, was lief, wann es begann und ob es erfolgreich war, scheiterte, ein Timeout hatte oder abgebrochen wurde.
Diese Trennung ist gesund. Scheduling und Tracking gehören zusammen, sind aber nicht dieselbe Sorge. Das eine entscheidet, wann etwas läuft. Das andere erzählt dir, was danach passiert ist.
- Cron entscheidet, wann ein entkoppelter geplanter Lauf startet
- Tasks protokollieren den Laufzyklus
- Heartbeat kann auf abgeschlossene Arbeit reagieren, wird aber selbst nicht zum Task
Wenn du dir einen Satz aus diesem Abschnitt merken willst, dann diesen: Tasks erklären die Folgen.
Task Flow nutzt du dann, wenn ein Task nicht die ganze Geschichte ist
Ein einzelner Task reicht für eine einzelne Hintergrundoperation. Daten holen. Datei rendern. Entkoppelte Analyse laufen lassen. Fertig.
Task Flow ist für Arbeit mit Struktur da: Schritt A, dann B, dann C, vielleicht mit Wartezeiten, Retries, Freigaben oder gespiegelt beobachtetem Fortschritt. Er sitzt oberhalb von Tasks und hält dauerhaften Flow-Status über Gateway-Restarts hinweg.
Der praktische Unterschied ist einfach. Wenn du fragst: "Ist der Background-Run fertig?", bist du im Tasks-Land. Wenn du fragst: "In welcher Phase steckt der Workflow, und was passiert als Nächstes?", bist du im Task-Flow-Land.
Stell dir Tasks wie Sendungsverfolgung für ein Paket vor. Task Flow ist das Lagerboard für eine ganze Lieferung, die durch mehrere Stationen geht.
Hooks sind für Events da, nicht für Zeitpläne
Hooks sind die richtige Antwort, wenn etwas innerhalb von OpenClaw die Automation auslösen soll. Ein /new-Command, ein /reset, ein Startup-Event, ein Shutdown-Event, Message-Receipt, Message-Send, Session-Compaction und so weiter.
Das ist wichtig, weil event-getriebene Automation sauberer bleibt, wenn sie event-getrieben bleibt. Wenn du nach message:sent eine kleine Aktion ausführen musst, wäre Polling alle paar Minuten ein ziemlich absurder Weg, das herauszufinden. Das Event ist ja schon passiert. Nutze die Event-Oberfläche.
Und noch etwas: Verwechsle interne Hooks nicht mit eingehenden HTTP-Webhooks. Die Namen klingen verwandt, was etwas lästig ist. In der OpenClaw-Doku meint Hooks hier interne Gateway-Events. Webhooks sind externe HTTP-Trigger-Endpunkte.
Standing Orders beantworten "Was darf ich überhaupt tun?"
Standing Orders sind die dauerhaften Betriebsregeln. Sie liegen meistens in AGENTS.md, damit sie automatisch in jede Session injiziert werden.
Cron ist meistens der Timer. Standing Orders sind das Playbook.
Das ist besser, als alles in einen Cron-Prompt zu stopfen. Warum? Weil der Zeitplan nicht die ganze Policy-Logik des Workflows mitschleppen sollte. Wenn Befugnisse, Eskalationsregeln und Grenzen in Standing Orders leben, können einzelne geplante Prompts kurz und klar bleiben.
- Standing Order: übernimm die tägliche Inbox-Triage, eskaliere Unbekanntes, sende keine externen Antworten ohne Freigabe
- Cron-Prompt: führe die Inbox-Triage gemäß Standing Orders aus
Sauberer. Leichter prüfbar. Viel weniger anfällig dafür, später auseinanderzudriften.
Ein praktischer Entscheidungsbaum
- Brauchst du exaktes Timing? Nutze Cron.
- Brauchst du nur periodische Aufmerksamkeit? Nutze Heartbeat.
- Hat ein internes Event die Aktion ausgelöst? Nutze Hooks.
- Brauchst du ein Protokoll für entkoppelte Arbeit? Tasks verfolgen das.
- Hat der Job mehrere dauerhafte Phasen? Ergänze Task Flow.
- Braucht der Agent dauerhafte Befugnisse oder Leitplanken? Definiere Standing Orders.
Auffällig ist: Diese Antworten stapeln sich oft, statt miteinander zu konkurrieren. Eine reife Automation nutzt häufig mehrere dieser Oberflächen gleichzeitig.
- Standing Orders definieren Befugnisse
- Cron definiert das Timing
- Tasks protokollieren den entkoppelten Lauf
- Task Flow koordiniert die mehrstufigen Phasen
Das ist keine Doppelarbeit. Das ist Trennung der Verantwortlichkeiten, die ihren Job macht.
Typische Fehlgriffe
- Cron für ambient checking nutzen: du erzeugst zu viele entkoppelte Runs und zu wenig gemeinsamen Kontext
- Heartbeat für exakte Erinnerungen nutzen: das Timing wird weich, weil Heartbeat absichtlich nur ungefähr ist
- Tasks wie einen Scheduler behandeln: du bekommst ein schönes Protokoll und keine Timing-Logik
- Hooks für lange Workflow-Orchestrierung nutzen: Event-Trigger sind nicht dasselbe wie dauerhafter mehrstufiger Status
- Alle Regeln in Cron-Prompts stopfen: der Workflow wird schwerer prüfbar und leichter widersprüchlich
Die Kurzfassung
Wenn Timing das Problem ist, beginne mit Cron. Wenn Aufmerksamkeit das Problem ist, beginne mit Heartbeat. Wenn ein Event die Aktion auslösen soll, nutze Hooks. Wenn du Tracking brauchst, sind Tasks das Protokoll. Wenn der Workflow Phasen hat, ergänze Task Flow. Wenn der Agent dauerhafte Befugnisse braucht, definiere Standing Orders.
OpenClaw hat mehrere Automatisierungsoberflächen, weil echte operative Probleme unterschiedlich sind. Das ist kein Ballast. Das ist die Plattform, die sich weigert so zu tun, als würde ein Hammer auch jede Schraube sauber lösen.
Need help from people who already use this stuff?
Du bist unsicher, welche Automations-Spur zu deinem Workflow passt?
Bring Trigger, Timing-Bedarf und Kontextfrage in die Community. Eine saubere Routing-Entscheidung jetzt schlägt Wochen voller cron-förmiger Überkonstruktion.
FAQ
Wann reicht Cron, und wann sollte ich stattdessen Heartbeat nutzen?
Nutze Cron, wenn das Timing exakt sein muss oder der Lauf für sich stehen soll. Nutze Heartbeat, wenn ungefähres Timing reicht und der Agent vom vollen Main-Session-Kontext profitiert, etwa bei Inbox-Checks, Kalender-Bewusstsein oder leichten Follow-ups.
Was ist der Unterschied zwischen Tasks und Task Flow?
Tasks sind das Protokoll für entkoppelte Arbeit. Sie zeichnen auf, was lief und wie es endete. Task Flow sitzt darüber und koordiniert mehrstufige Arbeit mit dauerhaftem Status, Reihenfolge und restart-sicherem Fortschritt.
Wann sollte ich Hooks statt eines geplanten Jobs verwenden?
Nutze Hooks, wenn etwas innerhalb von OpenClaw die Aktion auslösen soll, zum Beispiel /new, /reset, Startup, Shutdown oder Message-Lifecycle-Events. Nutze Cron, wenn der Trigger zeitbasiert ist oder aus einem Scheduler kommen soll.
Warum Regeln in Standing Orders statt direkt in einen Cron-Prompt schreiben?
Standing Orders definieren dauerhafte Befugnisse und Eskalationsregeln, die in jede Session geladen werden. Der Cron-Job sollte meist nur sagen, wann gehandelt wird, während die Standing Orders festlegen, was der Agent tun darf und wann er Hilfe holen muss.
Welcher Automatisierungsmodus behält Kontext, und welcher startet frisch?
Heartbeat nutzt die Main Session. Cron kann main, isolated, current oder eine benannte session ansteuern. Isolated startet frisch. Current und session:<id> behalten absichtlich Kontext. Tasks und Task Flow verfolgen Arbeit, sind aber nicht selbst der Gesprächskontext.