Zum Inhalt
alles was bewegtvon Oliver Münk
← Alle Geschichten
technik

OpenClaw Gateway: Vault, Skills, Scheduling – Teil 2 der Hybrid-Architektur-Serie

6. Mai 2026 · von Oliver Muenk

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:

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:

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:

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

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:

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:

  1. Nutzereingabe per Telegram: „Schreibe einen Blogartikel über die Hybrid-Architektur“
  2. Briefing-Phase: OpenClaw erstellt ein Redaktionsbriefing (Zielgruppe, Stil, Kernaussagen)
  3. Chefredakteur-Review: Ein Sub-Agent prüft das Briefing auf Vollständigkeit
  4. Recherche: Der Vault wird nach Architektur-Dokumenten durchsucht, der Workspace nach aktuellen Betriebsdaten
  5. Struktur-Phase: Gliederung wird erstellt und erneut durch den Chefredakteur geprüft
  6. Schreibphase: Abschnitt für Abschnitt wird der Text erstellt
  7. Gesamt-Review: Der Chefredakteur prüft den kompletten Text auf Stilbrüche, Wiederholungen und Logikfehler
  8. SEO-Optimierung: Titel, Meta-Beschreibung, Zwischenüberschriften
  9. 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:

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.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden.