Standing Orders in OpenClaw: Daueraufträge mit klaren Grenzen einrichten

Standing Orders in OpenClaw: Daueraufträge mit klaren Grenzen einrichten

Manche Aufgaben kommen jede Woche wieder: der Statusbericht, das Sortieren des Posteingangs oder ein Überblick über neue Daten. Du kannst deinen Agenten jedes Mal neu darum bitten. Mit Standing Orders hinterlegst du stattdessen einen dauerhaften Auftrag, der festlegt, was der Agent tun soll, wodurch er ausgelöst wird und wann er stoppen muss.

Standing Orders sind Anweisungen in den geladenen Workspace-Dateien. Sie erteilen keine Connector-, Datei- oder Systemrechte und sind keine technisch erzwungene Zugriffskontrolle. Ein textliches Verbot verhindert allein weder einen Tool-Aufruf noch eine externe Sendung. Begrenze riskante Programme zusätzlich durch eingeschränkte Konten, Tool-Policies, Ziel-Allowlisting und technisch erzwungene Approval Gates.

In diesem Tutorial formulierst du einen Auftrag zur täglichen Postfachsichtung, löst ihn zeitgesteuert aus und prüfst das Ergebnis. Grundlagen zu Workspace-Dateien findest du im Tutorial zum OpenClaw-Workspace.

Was ein Dauerauftrag regelt

Die OpenClaw-Dokumentation beschreibt Standing Orders als dauerhafte Betriebsanweisungen für klar umrissene Programme. Darin hältst du fest, welche Daten der Agent lesen darf, welche Ergebnisse er erzeugen soll und bei welchen Abweichungen er den Lauf abbricht.

Diese Autorisierung gilt auf Anweisungsebene und nur innerhalb der bereits verfügbaren Tools und Berechtigungen. Ein Eintrag wie „Bericht an den Owner senden“ schaltet keinen Nachrichtenkanal frei. Ebenso ersetzt „vor externem Versand nachfragen“ kein echtes Approval Gate. Die technische Absicherung wird separat konfiguriert; das Zusammenspiel erklärt der Artikel zu Sandboxing und Exec Approvals.

Der Nutzen liegt in der Überprüfbarkeit. Der Auftrag nennt ein konkretes Artefakt, ein zulässiges Ziel und messbare Abbruchbedingungen. So kannst du nach einem Lauf kontrollieren, ob der Agent die erwartete Datei erzeugt und der Scheduler die Ausgabe ausschließlich an das vorgesehene Ziel zugestellt hat.

Den Auftrag in AGENTS.md anlegen

OpenClaw empfiehlt, Standing Orders direkt in AGENTS.md abzulegen. Diese Datei wird automatisch in Agentensitzungen eingebunden. Eine umfangreiche Sammlung kann in einer Datei wie standing-orders.md liegen, sofern AGENTS.md ausdrücklich darauf verweist. Beliebige Dateien in Unterverzeichnissen werden nicht automatisch geladen.

Das folgende Programm ist auf eine tägliche Postfachsichtung begrenzt. Es nennt den erlaubten Mailzugriff, den zeitgesteuerten Auslöser, den zulässigen Empfänger und die Datei, anhand derer du den Lauf später kontrollierst:

## Program: Daily Inbox Triage

**Authority:** Read new messages from the configured mail account, categorize
alerts, and write a summary. Produce only the final summary intended for the
configured owner.

**Trigger:** Weekdays at 08:00 in the automation's configured timezone.

**Approval gate:** Ask before contacting any recipient other than the configured
owner, changing mail state, changing credentials, or expanding the data scope.
These instructions do not replace technical tool approvals or destination rules.

**Escalation:** Stop and report a diagnosis if mail access fails, the sender or
recipient is ambiguous, an attachment looks unsafe, or the requested action
exceeds this program's authority.

### Execution steps

1. Read new alerts from the configured mail account.
2. Categorize each item without modifying or deleting mail.
3. Write the report to Reports/inbox/YYYY-MM-DD.md.
4. Verify that the report exists, is non-empty, and contains the item counts.
5. Return one final summary for the scheduler to deliver to the configured owner.

### What NOT to do

- Do not delete, move, reply to, or mark messages as read.
- Do not address content to a recipient outside the configured owner destination.
- Do not expose credentials or full message bodies in the final summary.
- Do not continue after an approval or escalation condition is reached.
- Do not claim or record successful external delivery. With `--announce`, the
  scheduler attempts delivery only after this agent turn has finished.

### Execution rules

- Follow Execute-Verify-Report for the work performed during the agent turn.
- A confirmation is not execution; perform the work before reporting completion.
- Verify the report artifact, but leave delivery verification to the operator
  after the scheduler has processed the completed turn.
- Make at most three total attempts, including the initial attempt.
- After the third failed attempt, stop and report the diagnosis and attempted fixes.

Die Verbote begrenzen das erwartete Verhalten des Agenten, bilden aber keine Sicherheitsgrenze. Konfiguriere den Mailzugang möglichst als eingeschränkten Leser. Begrenze den Nachrichtenkanal technisch auf das erlaubte Ziel und verlange eine echte Freigabe, wenn das Programm später weitere Empfänger oder schreibende Mailaktionen erhalten soll.

Zeitplan, Ereignis oder Bedingung wählen

Das Beispiel verwendet eine zeitgesteuerte Automation. Der Gateway-Scheduler startet den Agenten werktags um 08:00 Uhr; der Agent lädt AGENTS.md und führt das dort beschriebene Programm aus. Eine ausführlichere Einführung bietet das Tutorial zu Cron-Jobs, Heartbeats und Automationen.

Andere Standing Orders können durch ein Ereignis oder eine Bedingung starten. Für Aufrufe durch externe Dienste stellt OpenClaw authentifizierte Inbound Webhooks bereit. Wiederholt geprüfte Bedingungen werden über Condition Watchers abgebildet. Der Trigger im Auftrag sollte den tatsächlich eingesetzten Mechanismus benennen.

Voraussetzungen für den Beispieljob

Prüfe vor dem Anlegen des Jobs diese Umgebung:

• Der OpenClaw Gateway läuft dauerhaft, da Zeitpläne im Gateway-Prozess ausgeführt werden.
• Der gewünschte Workspace-Agent ist eingerichtet und über seine Agent-ID erreichbar.
• Der Agent besitzt lesenden Zugriff auf das vorgesehene Mailkonto.
• Der iMessage-Kanal ist eingerichtet und darf an das vorgesehene Ziel zustellen.
• Das Ziel ist für diesen Auftrag zulässig und nach Möglichkeit technisch allowgelistet.
• Du führst die spätere Dateiprüfung im Workspace des gewählten Agenten aus.

Im folgenden Befehl sind main, America/New_York und +1XXXXXXXXXX Beispiele. Ersetze main durch deine Agent-ID, die Zeitzone durch eine passende IANA-Zeitzone wie Europe/Berlin und die Nummer durch das erlaubte iMessage-Ziel. Nutzt dein Setup einen anderen Kanal, ersetze auch imessage samt Zielformat.

Automation anlegen und Job-ID erfassen

Der Automation-Prompt verweist auf den Auftrag, statt dessen Regeln zu duplizieren. Dadurch bleibt AGENTS.md die zentrale Stelle für Scope und Eskalation:

openclaw automations add \
  --name "daily-inbox-triage" \
  --agent "main" \
  --cron "0 8 * * 1-5" \
  --tz "America/New_York" \
  --session isolated \
  --timeout-seconds 300 \
  --announce \
  --channel "imessage" \
  --to "+1XXXXXXXXXX" \
  --message "Execute Daily Inbox Triage per the standing orders in AGENTS.md. Verify the report artifact and return exactly one final summary for scheduler delivery. Do not claim or record delivery success; with --announce, delivery occurs after this agent turn. Escalate unknowns."

--announce bedeutet in diesem Ablauf: Der Agent erzeugt während seines Turns die finale Zusammenfassung. Erst nachdem der Turn abgeschlossen ist, übernimmt der Scheduler den Zustellversuch an den konfigurierten Kanal. Der laufende Agent kann den tatsächlichen Erfolg dieser externen Zustellung deshalb weder prüfen noch zuverlässig protokollieren.

openclaw cron bleibt ein Alias für openclaw automations. Nach erfolgreichem Anlegen gibt die CLI die Jobdefinition mit einer Job-ID aus. Kopiere genau diese ID in eine Shellvariable:

JOB_ID="<job-id-from-add-output>"

Bleibt die Ausgabe aus oder meldet die CLI einen Verbindungsfehler, prüfe den Gateway, bevor du den Befehl wiederholst. Lege den Job nicht mehrfach an; kontrolliere zuvor mit openclaw automations list, ob bereits ein Eintrag namens daily-inbox-triage vorhanden ist.

Definition und manuellen Test prüfen

Zeige den gespeicherten Job an:

openclaw automations show "$JOB_ID"

Die Ausgabe soll den aktivierten Job, den Cron-Ausdruck 0 8 * * 1-5, deine Zeitzone, die gewählte Agent-ID sowie Kanal und Ziel enthalten. Stimmen Werte nicht mit deiner Umgebung überein, starte noch keinen Testlauf.

Führe den Job anschließend manuell aus:

openclaw automations run "$JOB_ID"

Kontrolliere danach die Run-Historie:

openclaw automations runs "$JOB_ID" --limit 20

Warte bei einem noch laufenden Eintrag, bis der Scheduler einen abschließenden Status aufgezeichnet hat, und rufe die Historie dann erneut auf. Ein abgeschlossener erfolgreicher Lauf erscheint dort mit Status ok. Prüfe außerdem Warnungen und Diagnosen in der Run-Historie sowie erneut in der Jobansicht. Ein Agent kann einen Toolfehler in seiner Antwort melden, obwohl der Turn selbst abgeschlossen wurde.

Die Run-Historie wird vom Scheduler nach dem Agenten-Turn aktualisiert. Sie ist daher die richtige Stelle für den technischen Lauf- und Zustellstatus. Sie ersetzt bei einem Ende-zu-Ende-Test jedoch nicht die Kontrolle des tatsächlichen Zielkanals.

Artefakt und Zustellung verifizieren

Wechsle in den Workspace des Agenten. Wenn du America/New_York im Job beibehalten hast, prüfst du den erwarteten Tagesbericht so:

REPORT="Reports/inbox/$(TZ=America/New_York date +%F).md"
test -s "$REPORT" && sed -n '1,80p' "$REPORT"

Bei einer anderen Job-Zeitzone ersetzt du America/New_York auch in dieser Prüfung. test -s ist nur dann erfolgreich, wenn die Datei vorhanden und nicht leer ist. Kontrolliere im ausgegebenen Inhalt zusätzlich Datum, Kategorien und Anzahl der verarbeiteten Meldungen. Der Bericht darf keine vollständigen Nachrichtentexte oder Zugangsdaten enthalten.

Prüfe nach Abschluss des Agenten-Turns zunächst die Run-Historie auf den vom Scheduler aufgezeichneten Zustellstatus. Kontrolliere anschließend selbst am konfigurierten iMessage-Ziel, ob genau eine Zusammenfassung angekommen ist. Vergleiche Empfänger und Inhalt mit dem Auftrag. Diese Ende-zu-Ende-Prüfung liegt beim Operator, weil die --announce-Zustellung erst nach dem Turn stattfindet und vom Agenten nicht rückwirkend bestätigt werden kann.

Der Test gilt nur dann als erfolgreich, wenn Run-Historie, Berichtsdatei und tatsächlich empfangene Nachricht übereinstimmen. Ein ok ohne Datei oder ohne erwartete Nachricht ist kein fachlicher Erfolg. Fehlt die Zustellung, darf auch eine anderslautende Formulierung in der Agentenausgabe nicht als Zustellnachweis gewertet werden.

Diagnose und sicherer Rückweg

Wenn der Job nicht startet oder nichts zustellt, arbeite die Diagnose in dieser Reihenfolge ab:

openclaw status
openclaw gateway status
openclaw automations status
openclaw automations list --all
openclaw automations runs "$JOB_ID" --limit 20
openclaw doctor

Nutze bei Bedarf vorübergehend openclaw logs --follow, während du einen kontrollierten Testlauf startest. Prüfe bei ausbleibenden Zeitplanläufen besonders, ob der Gateway dauerhaft läuft, der Job aktiviert ist und seine Zeitzone stimmt. Bei Zustellproblemen kontrollierst du Kanal, Konto, Ziel-Allowlist und die Diagnosefelder des Laufs.

Halte einen falsch konfigurierten Job vor weiteren Versuchen an:

openclaw automations disable "$JOB_ID"
openclaw automations show "$JOB_ID"

Die Jobansicht soll nun den deaktivierten Zustand zeigen. Korrigiere danach gezielt den fehlerhaften Wert. Dieses Beispiel ersetzt die Zeitzone:

openclaw automations edit "$JOB_ID" --tz "Europe/Berlin"
openclaw automations show "$JOB_ID"

Aktiviere den korrigierten Job und teste ihn kontrolliert:

openclaw automations enable "$JOB_ID"
openclaw automations run "$JOB_ID"
openclaw automations runs "$JOB_ID" --limit 20

Wird der Job nicht mehr benötigt, entfernst du ihn statt ihn unbemerkt aktiviert zu lassen:

openclaw automations rm "$JOB_ID"
openclaw automations list --all

Nach dem Entfernen darf die Job-ID nicht mehr in der Liste erscheinen. Wiederhole einen Test erst, nachdem die konkrete Ursache behoben wurde. Nach höchstens drei Gesamtversuchen beendet der Agent das Programm und eskaliert mit Diagnose.

Sonderfall openclaw agent exec

Für abgeschottete Einmalläufe in CI oder Skripten bietet OpenClaw openclaw agent exec. Dieser Einstiegspunkt überspringt die Workspace-Bootstrap-Dateien. Ein solcher Lauf lädt die Standing Orders aus AGENTS.md daher nicht automatisch und muss alle benötigten Anweisungen selbst enthalten.

Wenn ein Skriptlauf vom beschriebenen Programm abweicht, prüfe seinen Einstiegspunkt. Für einen wiederkehrenden Auftrag, der die Workspace-Anweisungen verwenden soll, eignet sich die gezeigte Agent-Automation. Für einen selbstständigen, reproduzierbaren CI-Lauf ist openclaw agent exec vorgesehen.

Mehrere Programme sauber trennen

Betreut ein Agent mehrere Bereiche, erhält jeder Bereich einen eigenen Programmblock. Ein Wochenbericht kann Quelldaten lesen und einen internen Bericht schreiben. Ein Finanzprogramm darf dagegen ausschließlich vorbereiten und muss vor jeder Empfehlung oder externen Aktion stoppen.

Gemeinsame Eskalationsregeln können unter einer eigenen Überschrift stehen, sofern sie die konkreten Regeln der einzelnen Programme nicht aufweichen. Prüfe die Agent-Logs regelmäßig und passe Scope, Ziele und Freigaben an beobachtete Fehler an. Zusätzliche Befugnisse sollten erst nach nachvollziehbaren, erfolgreich verifizierten Läufen freigeschaltet werden.

Kernpunkte

Standing Orders machen wiederkehrende Agentenarbeit schriftlich und überprüfbar. Sie beschreiben Scope, Trigger, erwartete Artefakte, Freigabepunkte und Eskalation, schaffen aber keine technischen Rechte oder Zugriffssperren.

Für den produktiven Betrieb kombinierst du den Auftrag mit eingeschränkten Konten, Tool-Policies, Ziel-Allowlisting und echten Approval Gates. Ein zeitgesteuerter Job ist erst einsatzbereit, wenn seine Definition geprüft, ein manueller Lauf kontrolliert sowie Datei und Zustellung fachlich verifiziert wurden. Der Agent prüft dabei nur die Arbeit innerhalb seines Turns; den nachgelagerten --announce-Zustellversuch bewerten Scheduler-Historie und Operator. Bei einer Fehlkonfiguration hältst du den Job mit disable an, korrigierst ihn mit edit oder entfernst ihn mit rm.