Zum Inhalt springen
tutorials · 8 min Lesezeit

OpenClaw Tutorial Teil 1: Was ist OpenClaw?

OpenClaw ist ein lokal orchestrierter KI-Assistent für Kanäle wie WhatsApp, Telegram, Slack oder Discord – abhängig von Plugin und Konfiguration.

Tutorial OpenClaw KI-Agenten Self-Hosting

📚 Serie: OpenClaw installieren & einrichten — Teil 1 von 8
Teil 2: Installation auf macOS, Linux & Raspberry Pi →

OpenClaw ist ein Open-Source-KI-Assistent, der lokal auf dem eigenen Rechner orchestriert wird. Je nach Plugin und Konfiguration lässt er sich in Kommunikationskanäle wie WhatsApp, Telegram, Slack oder Discord einbinden. Das Framework koppelt KI-Modelle mit Werkzeugen wie Shell-Zugriff, lokalen Dateien, Browser-Funktionen und erweiterbaren Plugins.

Die Architektur setzt auf lokale Kontrolle: Ein zentraler Gateway-Prozess steuert Routing, Sessions und Werkzeuge. Externe KI-Modelle können weiterhin über Provider-APIs angebunden werden, bleiben aber in der eigenen Infrastruktur verankert. Damit eignet sich OpenClaw für Nutzer, die einen KI-Assistenten selbst hosten und nicht an eine geschlossene Cloud-App binden möchten.

Stand dieser Einordnung: 2026-05-03. OpenClaw entwickelt sich aktiv weiter. Vor der praktischen Installation in Teil 2 sollten Installationsbefehle, Provider-Felder und Plugin-Namen stets mit dem aktuellen GitHub-Repository und der offiziellen Dokumentation abgeglichen werden.

Dieser Auftakt der Serie vermittelt Architektur, zentrale Begriffe und typische Einsatzmöglichkeiten. Er legt das Fundament für die praktische Installation im zweiten Teil.

Was ist OpenClaw?

OpenClaw agiert als lokaler KI-Agent bzw. als Agenten-Runtime auf dem eigenen System. Das Projekt ist plattformübergreifend ausgelegt. Die konkrete Installation variiert jedoch je nach Betriebssystem und Version. Diese Serie behandelt in den praktischen Kapiteln primär macOS, Linux und Raspberry Pi. Windows-Setups sollten anhand der aktuellen Projekt-Dokumentation gesondert geprüft werden.

Statt über eine isolierte Chat-App bedient zu werden, integriert sich OpenClaw in bestehende Kanäle. Eingehende Nachrichten werden über Channel-Plugins an den lokalen Gateway geleitet. Der Agent verarbeitet sie mit einem konfigurierten Modell und kann anschließend freigegebene Tools nutzen.

Typische Werkzeuge umfassen:

  • Shell- und Prozesssteuerung,
  • Datei- und Workspace-Zugriff,
  • Browser- und Web-Funktionen,
  • Nachrichten-Tools für angebundene Channels,
  • pluginbasierte Erweiterungen wie Skills oder Workflows.

Wiederkehrende Aufgaben lassen sich über integrierte Automations- bzw. Cron-Funktionen abbilden. Mehrere Sessions, Workspaces oder Agentenrollen können je nach Setup isoliert betrieben werden. Im Gegensatz zu reinen Cloud-Diensten liegt die Orchestrierung lokal. Die Sprachmodelle werden separat angebunden, typischerweise über Provider-APIs oder unterstützte lokale Backends.

Die Philosophie hinter dem System

Das Projekt folgt dem „Lobster Way“: OpenClaw soll flexibel, robust und unabhängig von einzelnen Plattformen funktionieren. Im Zentrum steht die lokale Kontrolle über den Steuerungs-Layer. Anwender wählen selbst Provider, Tools, Plugins und Datenquellen.

Diese Architektur ermöglicht hohe Anpassbarkeit. Falls ein Modellanbieter ausfällt oder ungeeignet ist, lässt sich ein anderer konfigurieren, sofern die aktuelle Version den Pfad unterstützt. Skills und Plugins erweitern den Funktionsumfang, ohne die Gateway-Grundstruktur zu verändern.

Daten verlassen den Rechner jedoch nicht automatisch nur, weil OpenClaw lokal läuft. Sobald externe LLM-Provider, Messenger-Dienste oder Web-Tools genutzt werden, werden entsprechende Anfragen weitergeleitet. Der Vorteil liegt in der bewussten Konfiguration und lokalen Orchestrierung dieser Verbindungen.

Architektur und Funktionsweise

OpenClaw basiert auf einer modularen Struktur. Der zentrale Baustein ist der Gateway: ein lokal laufender Prozess, der Channel-Verbindungen, Sessions, Tools und die WebSocket-Steuerung koordiniert.

┌─────────────────────────────────────────────────────────┐
│                    Gateway (Kern)                       │
│  ┌─────────────┐   ┌─────────────┐   ┌─────────────┐    │
│  │   Channel   │◀─▶│  Messages / │◀─▶│   Agent /   │    │
│  │ (Telegram)  │   │   Router    │   │   Session   │    │
│  └─────────────┘   └─────────────┘   └─────────────┘    │
│                    ▲           ▲                        │
└────────────────────┼───────────┼────────────────────────┘
                     │           │
            ┌────────┴─────┐ ┌───┴──────────┐
            │              │ │              │
      ┌─────▼─────┐  ┌────▼─▼─────┐  ┌─────▼─────┐
      │ Web/Canvas│  │   Skills / │  │   Tools   │
      │ Gateway UI│  │  Plugins   │  │           │
      └───────────┘  └────────────┘  └───────────┘

Der Gateway ist der zentrale Daemon. Laut Dokumentation ist das Standardziel für die WebSocket-Verbindung ws://127.0.0.1:18789. Dieses Loopback-first-Design ist entscheidend: Lokal ist die Nutzung unkompliziert, externe Zugriffe erfordern jedoch explizite Absicherung.

Wird der Gateway an LAN-, Tailnet- oder andere Nicht-Loopback-Adressen gebunden, ist ein gültiger Authentifizierungspfad zwingend. Dies umfasst Token- oder Passwort-Authentifizierung sowie korrekt konfigurierte Trusted-Proxy-Setups. Für Remote-Zugriff empfehlen sich SSH-Tunnel oder VPN-Lösungen wie Tailscale. Pro Host wird ein Gateway empfohlen; parallele Instanzen benötigen getrennte Profile und Ports.

Die Web- bzw. Canvas-Oberflächen laufen auf demselben Gateway-Port. Sie sind unter anderem unter /__openclaw__/canvas/ und /__openclaw__/a2ui/ erreichbar. Sobald der Gateway über Loopback hinaus zugänglich ist, müssen diese Oberflächen durch die Gateway-Authentifizierung geschützt werden.

Channels sind pluginbasierte Schnittstellen zu Kommunikationsdiensten. Die Dokumentation listet unter anderem Runtimes für Discord, Slack, Telegram und WhatsApp. Diese Plugins leiten Nachrichten an den Gateway weiter und ermöglichen je nach Kanal auch Antworten oder spezifische Aktionen.

Die Verarbeitung erfolgt in Agents bzw. Sessions. Eine Session kombiniert Prompt, Modell, Workspace und verfügbare Tools. Technisch werden dabei Parameter wie sessionId, sessionKey, eine Session-Datei und ein workspaceDir übergeben. OpenClaw trennt damit Konversation, Arbeitsverzeichnis und Werkzeugkontext strikt.

Skills und Plugins erweitern die Fähigkeiten des Systems. Ein Beispiel ist OpenProse: Dieses Plugin ist standardmäßig deaktiviert, kann aber einen /prose-Befehl bereitstellen und .prose-Workflows ausführen. Solche Erweiterungen erhöhen den Funktionsumfang, ersetzen jedoch keine Sicherheitskonfiguration.

Anbindung der KI-Modelle

OpenClaw liefert kein eigenes Sprachmodell als festen Kernbestandteil. Stattdessen wird ein externer Modellanbieter konfiguriert. Die Dokumentation nennt beispielsweise Provider-Felder mit Anthropic als Referenz sowie konkrete Modellparameter. Gültige Provider und Konfigurationsfelder hängen von der eingesetzten OpenClaw-Version ab.

Für den Betrieb sind folgende Punkte essenziell:

  • API-Schlüssel und Provider-Konfigurationen gehören nicht in öffentliche Repositories.
  • Externe Provider erhalten die gesendeten Prompts, Kontextdaten und Tool-Ergebnisse.
  • Lokale Modelle reduzieren Cloud-Abhängigkeiten, erfordern jedoch passende Hardware und unterstützte Backends.
  • Unterschiedliche Sessions können je nach Setup verschiedene Modelle parallel nutzen.

Die detaillierte Provider-Konfiguration wird in Teil 3 behandelt. Vor der Einrichtung sollte stets die aktuelle OpenClaw-Dokumentation konsultiert werden.

Zielgruppe und Einsatzszenarien

OpenClaw adressiert technikaffine Anwender, Entwickler und Teams, die einen KI-Assistenten selbst hosten möchten. Grundkenntnisse im Umgang mit der Kommandozeile sind empfehlenswert. Je nach Installationsweg kommen Node.js, Paketmanager, Docker oder systemd-Dienste hinzu.

Typische Anwendungsfälle umfassen:

  • persönliche Assistenz über Messenger,
  • Recherche, Zusammenfassung und Web-Analysen,
  • lokale Datei- und Workspace-Verwaltung,
  • geplante Aufgaben über Cron-ähnliche Funktionen,
  • wiederverwendbare Workflows mit Skills,
  • kontrollierte Labor- oder Team-Setups.

Smart-Home-, Kalender- oder Fachintegrationen sind möglich, sofern passende Tools oder externe Schnittstellen bereitstehen. Sie sind jedoch keine automatische Grundfunktion, sondern erfordern gezielte Konfiguration.

Wichtige Begriffe im Überblick

BegriffKurzerklärung
GatewayZentraler lokaler Daemon für Channel-Verbindungen, WebSocket-Steuerung, Sessions und Tools. Standardmäßig loopback-first über 127.0.0.1.
Agent / SessionLaufende KI-Verarbeitung mit Prompt, Modell, Kontext, Werkzeugen und Session-Datei.
ChannelPlugin-Anbindung an Dienste wie Telegram, WhatsApp, Slack oder Discord.
SkillZusätzliche Fähigkeit oder Anleitung für strukturiertes Agentenverhalten.
PluginErweiterungspaket für neue Channels, Skills, Commands oder Tool-Integrationen.
ToolKonkretes Werkzeug (z. B. Shell, Browser, Datei-Zugriff), das ein Agent nutzen darf.
WorkspaceArbeitsverzeichnis einer Session für Dateien, Zustände und projektspezifische Daten.
Canvas/Web-OberflächeGateway-Weboberflächen, die bei Nicht-Loopback-Bindings durch Authentifizierung geschützt werden müssen.

Sicherheit: Was man von Anfang an beachten sollte

OpenClaw stellt mächtige lokale Werkzeuge bereit. Ein Agent mit Shell-, Datei- oder Browser-Zugriff ist kein harmloser Chatbot.

Für die folgenden Serienteile gelten diese Grundregeln:

  • Gateway initial ausschließlich auf 127.0.0.1 betreiben.
  • Nicht-Loopback-Zugriffe nur mit sauberer Authentifizierung aktivieren.
  • Remote-Zugriff über SSH-Tunnel oder Tailscale/VPN absichern.
  • API-Keys und Tokens niemals in Chatverläufen, Screenshots oder öffentlichen Repositories teilen.
  • Tools nur aktivieren, wenn der Einsatzzweck klar definiert ist.
  • Bei Shell- und Dateizugriff zunächst mit isolierten Test-Workspaces arbeiten.
  • Messenger-Integrationen nur mit bewusst gewählten Accounts und Berechtigungen testen.

Diese Maßnahmen sind entscheidend, da die lokale Werkzeugfähigkeit OpenClaw erst seine volle Stärke verleiht.

Aufbau dieser Serie

Die Tutorial-Serie führt schrittweise von der Installation bis zum produktiven Einsatz:

  1. Teil 1 – Überblick & Architektur ✓
  2. Teil 2 – Installation auf macOS, Linux & Raspberry Pi
  3. Teil 3 – Modelle konfigurieren (Provider, API-Keys und lokale Modelle)
  4. Teil 4 – Telegram & WhatsApp verbinden
  5. Teil 5 – Skills & Tools erweitern
  6. Teil 6 – Workspace einrichten (System-Prompts & Gedächtnis)
  7. Teil 7 – Cron-Funktionen, Heartbeats & Automationen
  8. Teil 8 – Multi-Agent-Setup & Sub-Agenten

Für diesen Auftakt sind keine speziellen Voraussetzungen nötig. Ein grundlegendes Interesse an KI-Agenten und ein internetfähiger Rechner genügen. Ein GitHub-Account ist hilfreich, um bei Bedarf den Quellcode zu prüfen.

Weiter mit Teil 2

Im nächsten Schritt folgt die praktische Umsetzung. Teil 2 zeigt die Installation auf macOS, Linux oder Raspberry Pi. Der Gateway-Daemon wird gestartet, die lokale Oberfläche geprüft und die Grundkonfiguration vorbereitet. Alle Installationsbefehle sollten vor der Ausführung mit dem aktuellen Stand des OpenClaw-Repositories abgeglichen werden.

Zu Teil 2 →

Was daraus folgt

OpenClaw bietet eine modulare, lokal kontrollierte Architektur für KI-Agenten. Durch die Trennung von Gateway, Channels und Modellanbindung bleibt die Datenhoheit weitgehend in der eigenen Hand. Die Flexibilität erfordert jedoch ein bewusstes Sicherheitskonzept, insbesondere bei der Freigabe von Werkzeugen und externen Zugriffen. Mit diesem Überblick sind die Grundlagen gelegt, um im nächsten Teil die Grundkonfiguration sicher umzusetzen.

Transparenz

Agentenlog nutzt KI-Assistenz für Recherche, Struktur und Entwurf. Inhaltliche Auswahl, Einordnung und Veröffentlichung liegen redaktionell bei nexus; Quellen und Fakten werden vor Veröffentlichung geprüft.

Serie: OpenClaw installieren & einrichten

Teil 1 von 8