Inhaltsverzeichnis
Recap Teil 1
Im ersten Teil dieser Serie habe ich die Hybrid-Architektur beschrieben: Ein Raspberry Pi 5 als lokale Basis mit Docker-Container, ein günstiger VPS als Ollama-Endpunkt für Cloud-Modelle, und die klare Trennung von lokalen Embeddings und externer Sprachmodell-Inferenz. Die Kosten liegen bei etwa 5 €/Monat für den VPS – keine GPU-Investition, kein Abonnement.
In diesem Teil geht es um die Software-Schicht, die alles zusammenhält: OpenClaw Gateway. Es ist die Steuerzentrale, die entscheidet, welches Modell wann läuft, wo Informationen gespeichert werden und wie der Betrieb automatisiert abläuft.
1. Das Gateway-Prinzip
OpenClaw ist kein Chat-Interface im klassischen Sinne. Es ist ein Gateway – eine Orchestrierungsschicht, die zwischen Nutzer, Modellen, Speichern und externen Diensten vermittelt. Der Betrieb läuft in einem Docker-Container mit strikter Trennung von Code und State.
Das Prinzip ist einfach:
- Der Container-Code ist austauschbar – Updates ersetzen den Container, ohne Daten zu verlieren
- Der State ist persistent – Konfiguration, Workspace und Memory liegen auf gemounteten Volumes
- Das System ist dokumentationsgetrieben – Verhalten wird über Dokumente gesteuert, nicht über Code-Patches
Das bedeutet: Ein Update von OpenClaw ist ein docker compose pull && docker compose up -d. Fertig. Keine Datenmigration, keine manuelle Konfigurationsübertragung.
2. Vault und Workspace: Zwei Welten
OpenClaw arbeitet mit zwei getrennten Wissensbereichen, die unterschiedliche Aufgaben haben:
Vault – Das fachliche Gedächtnis
Der Vault ist eine Obsidian-kompatible Markdown-Struktur, die als fachliche Wissensbasis dient. Hier liegen:
- Architektur-Dokumentation
- Betriebshandbücher
- Sicherheitskonzepte
- Prozessbeschreibungen
Der Vault ist die Quelle für fachliche Fragen. Wenn OpenClaw wissen muss, wie eine bestimmte Komponente funktioniert oder warum eine Entscheidung getroffen wurde, sucht es im Vault.
Workspace – Die operative Steuerung
Der Workspace enthält die Steuerlogik des Systems:
- Verhaltensregeln (AGENTS.md)
- Globale Kernregeln (MEMORY.md)
- Technische Referenz (TOOLS.md)
- Tägliche Arbeitsnotizen
Der Workspace steuert, wie OpenClaw arbeitet. Er enthält keine fachliche Dokumentation – nur die operative Logik.
Warum die Trennung?
Weil sie deterministisches Verhalten erzwingt. Wenn OpenClaw vor einer Entscheidung erst den Vault (fachlich) und dann den Workspace (operativ) konsultieren muss, entsteht ein reproduzierbarer Ablauf. Es gibt keine impliziten Annahmen, keine versteckten Konfigurationen, keine Abhängigkeit von Chat-Verläufen.
Praktisches Beispiel: Bei der Erstellung eines Blogartikels konsultiert OpenClaw den Vault für die fachlichen Inhalte (Architektur, Prozesse), den Workspace für die Arbeitsregeln (SEO-Vorgaben, Stilregeln) und die Skill-Dokumentation für den spezifischen Workflow (10-Phasen-Prozess). Jede Quelle hat ihre Aufgabe, keine überschreibt die andere.
3. Skills: Erweiterbare Fähigkeiten
OpenClaw-Funktionalität wird über Skills erweitert. Ein Skill ist ein strukturiertes Paket aus einer Steuerdatei (SKILL.md) mit Zweck, Triggern, Eingaben und Ausgaben, optional ergänzt durch Skripte, Referenzdokumente und Konfigurationen.
Beispiele aktiver Skills
- Blog-Schreiber: Erstellt SEO-optimierte Blogartikel in einem 10-Phasen-Workflow mit Chefredakteur-Review über Sub-Agenten
- Depot-Monitor: Verwaltet Wertpapierdepots auf Transaktionsbasis, inklusive Kursabfragen und Report-Generierung
- Web-Suche: Sucht über mehrere Provider (Google, Tavily, Perplexity, SearXNG) mit automatischer Provider-Wahl. Der Trigger ist das Erkennen einer suchähnlichen Frage – woraufhin der Skill den passenden Anbieter auswählt: Google für aktuelle Nachrichten, SearXNG für private Abfragen, Perplexity für komplexe Recherche.
- Sonos-Steuerung: Steuert Sonos-Lautsprecher über eine lokale HTTP-Bridge
Jeder Skill hat eine eigene SKILL.md, die genau definiert, bei welchem Trigger er aktiv wird und wie er arbeitet. Das macht das System erweiterbar, ohne den Kern-Code zu ändern.
Sub-Agenten als Redaktionsinstanz
Ein besonderes Merkmal ist der Einsatz ephemerer Sub-Agenten als Qualitätsinstanz. Beim Blog-Schreiber-Skill durchläuft jeder Artikel einen Chefredakteur-Review: Ein separater Sub-Agent mit eigenem Modell (standardmäßig Nemotron 3 Super – ein leistungsstärkeres Modell als das Standard-Modell) prüft Gliederung und Text auf Lücken und bestätigt die SEO-Konformität, bevor der Artikel veröffentlicht wird.
Dieses Prinzip – getrennte Instanzen für Produktion und Prüfung – reduziert systematische Fehler, die entstehen, wenn dieselbe Instanz ihren eigenen Output bewertet.
4. Scheduling: Der Gateway entscheidet
OpenClaw hat ein eigenes Scheduling-System, das unabhängig vom System-Cron des Hosts arbeitet. Die Cron-Jobs werden im Gateway selbst definiert und ausgeführt:
- Heartbeat: Tägliche Statusprüfung von Gateway und angeschlossenen Systemen
- Depot-Kurse: Kursaktualisierungen an Börsentagen
- Hardware-Monitoring: Temperatur- und Lastüberwachung des Raspberry Pi
- Tägliche Zusammenfassung: Wetter, Termine, Relevantes per Telegram
Der Vorteil: Die Jobs laufen im selben Kontext wie der Bot selbst – sie haben Zugriff auf denselben Workspace, dieselben Secrets und dieselben Skills. Kein externes Skript muss SSH-Keys oder API-Tokens verwalten. Das vereinfacht Wartung und Sicherheit gleichermaßen.
5. Ein konkreter Workflow: So entsteht ein Blogartikel
Um das Zusammenspiel zu zeigen, hier der Ablauf bei der Erstellung genau dieses Artikels:
- Nutzereingabe per Telegram: „Schreibe einen Blogartikel über die Hybrid-Architektur“
- Briefing-Phase: OpenClaw erstellt ein Redaktionsbriefing (Zielgruppe, Stil, Kernaussagen)
- Chefredakteur-Review: Ein Sub-Agent prüft das Briefing auf Vollständigkeit
- Recherche: Der Vault wird nach Architektur-Dokumenten durchsucht, der Workspace nach aktuellen Betriebsdaten
- Struktur-Phase: Gliederung wird erstellt und erneut durch den Chefredakteur geprüft
- Schreibphase: Abschnitt für Abschnitt wird der Text erstellt
- Gesamt-Review: Der Chefredakteur prüft den kompletten Text auf Stilbrüche, Wiederholungen und Logikfehler
- SEO-Optimierung: Titel, Meta-Beschreibung, Zwischenüberschriften
- Veröffentlichung: WordPress-Draft per REST API
Jeder Schritt ist dokumentiert, jede Entscheidung nachvollziehbar. Das Ergebnis ist ein Artikel, der nicht vom Zufall des gewählten Modells abhängt, sondern von einem reproduzierbaren Prozess.
6. Grenzen des Gateways
OpenClaw Gateway ist kein Allheilmittel. Die Architektur hat klare Grenzen:
- Kein Host-Zugriff: Der Container kann keine Host-Dienste steuern, die nicht explizit freigegeben sind
- Kein Echtzeit-Betrieb: Antwortzeiten hängen von der Cloud-Modell-Latenz ab (2–15 Sekunden typisch)
- Kein Multimedia: Reine Text- und API-Steuerung, keine Bilderkennung im Gateway selbst
- Lernkurve: Die dokumentationsgetriebene Arbeitsweise erfordert Disziplin – wer schnell hackt, statt zu dokumentieren, verliert den Überblick
Diese Grenzen sind bewusst gewählt. Sie schaffen eine Architektur, die kontrolliert, auditierbar und wartbar bleibt – auch wenn der Funktionsumfang wächst.
Teil 3 dieser Serie behandelt Betriebserfahrung, Update-Strategie und ein ehrliches Fazit: Was in der Praxis funktioniert, was nicht, und für wen sich diese Architektur wirklich lohnt.