OpenClaw 24/7 betreiben: Praktische Architektur für persistente autonome Agenten

Das Kernproblem: Kontextwachstum ohne Persistenz

Wenn OpenClaw als ständig laufender autonomer Agent für Geschäftsworkflows wie Auftragsabwicklung, E-Mail-Kampagnen, Inhaltserstellung über 25 Websites und Sendungsverfolgung mit etwa 30 Cron-Jobs betrieben wird, verhält sich das System eher wie ein Server als wie ein Chatbot. Das Grundproblem ist unbegrenztes Kontextwachstum ohne echte Persistenzschicht.

Cron-Jobs, die alle 30 Minuten ausgeführt werden, halten Sitzungen aktiv, verhindern Leerlauf-Timeouts, während der Kontext auf Tausende von Zeilen anwächst. Wenn Komprimierung Gespräche zusammenfasst, gehen kritische Details wie Zugangsdaten, Workflow-Status und laufende Aufgaben verloren. Der Agent erwacht mit "Amnesie", während Benutzer für Kontextfenster zahlen, die zu 80 % aus veralteten Tool-Ausgaben von vor Stunden bestehen.

Funktionierende Architektur: Speicher als Grundlage

Die Lösung besteht darin, Speicher als Grundlage zu behandeln und nicht als nachträglichen Einfall:

• Themengetrennte Speicherdateien anstelle eines Monolithen:
  workspace/ ├── MEMORY.md (schlank, nur Identität + Zeiger) ├── AGENTS.md (Startsequenz + Wiederherstellungsprotokoll) ├── memory/ │ ├── INDEX.md (Navigationskarte, Agent liest diese zuerst) │ ├── SETUP.md (Zugangsdaten, Token, API-Schlüssel, Pfade) │ ├── OUTREACH.md (E-Mail-Workflows, Preise, Angebote) │ ├── SHIPMENT.md (Überwachung, Cron-Regeln, Kanäle) │ └── log/ │ └── YYYY-MM-DD.md (tägliches Aktivitätsprotokoll, kompakt gehalten)
• Wesentliche Erkenntnis: Währenddessen speichern, nicht am Ende speichern. Der Agent schreibt während Gesprächen in Speicherdateien, um sicherzustellen, dass kritische Informationen vor der Komprimierung erhalten bleiben.

Sitzungs- und Kontextmanagement

• Aggressiver Sitzungslebenszyklus: "session": { "idleMinutes": 10, "reset": { "mode": "daily", "atHour": 4 } } - Täglicher erzwungener Reset um 4 Uhr morgens mit kurzen Leerlauf-Timeouts.
• Kontextbereinigung, die tatsächlich bereinigt: "contextPruning": { "mode": "cache-ttl", "ttl": "5m", "softTrimRatio": 0.2, "hardClearRatio": 0.35, "hardClear": { "enabled": true, "placeholder": "[Gelöscht — Speicherdateien lesen, um Kontext wiederherzustellen]" } } - Der Platzhalter teilt dem Agenten mit, wie er sich erholen kann, anstatt Kontext stillschweigend zu löschen.
• Günstigere Komprimierung: Verwenden Sie ein kleineres Modell für die Zusammenfassung anstelle des teuren Modells, da Sie Gespräche zusammenfassen und keinen Code schreiben.

Wrapper-Tools für erweiterte Funktionalität

Vier Python-Skripte, die neben dem Agenten entwickelt wurden, bieten wichtige Funktionen:

• Strukturierter Speicher: JSON-basiert mit TTL, Tags, Wichtigkeitsbewertungen und Abfragen nach Typ. query --type credential ist sofort verfügbar.
• Sitzungs-Checkpoints: Agent speichert Zustand an natürlichen Unterbrechungspunkten für Absturzwiederherstellung.
• Cron-Digest: Alle Cron-Jobs protokollieren in eine tägliche Datei anstatt 15 separate Ausgaben, die den Kontext aufblähen.
• Kostenverfolgung: Token-Verbrauch pro Agent pro Tag mit täglichen Budgetwarnungen bei 80 % und 100 %.

Diese Tools sind reines Python ohne OpenClaw-Abhängigkeiten und überleben Versionsupgrades durch Lesen und Schreiben eigener JSON-Dateien.

Zusätzliche Optimierungen

• Prompt-Cache-Management: Verlängerte Cache-Aufbewahrung plus häufige Heartbeats halten den Prompt-Cache warm, reduzieren Cache-Fehler für schnellere Antworten und niedrigere Kosten.

Fehlende native Funktionen

Der Entwickler wünscht sich, dass OpenClaw nativ hätte: strukturierten Speicher mit TTL und automatischem Verfall (keine flachen Dateien), echte Absturzwiederherstellung und Sitzungs-Checkpoints, Planmodus (vorher nachdenken, dann handeln), Artefakte, die Komprimierung überleben, Kostenbudgets pro Agent mit harten Grenzen und Multi-Agent-Routing (z.B. Sendungsfragen gehen an den Erfüllungsagenten statt an den Inhaltsautor).