OpenClaw Tutorial Teil 1: Was ist OpenClaw?

📚 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 und sich je nach Plugin und Konfiguration in Kommunikationskanäle wie WhatsApp, Telegram, Slack oder Discord integrieren kann. Das Framework verbindet KI-Modelle mit Werkzeugen wie Shell-Zugriff, lokalen Dateien, Browser-/Web-Funktionen und pluginbasierten Erweiterungen.

Wichtig ist dabei die Architektur: Die zentrale Steuerung läuft lokal über einen Gateway-Prozess. Externe KI-Modelle können weiterhin über Provider-APIs angebunden werden, aber Routing, Sessions, lokale Werkzeuge und Konfigurationen bleiben unter eigener Kontrolle. Dadurch eignet sich OpenClaw besonders für Nutzer, die einen KI-Assistenten selbst hosten und nicht vollständig an eine einzelne 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 immer mit dem aktuellen GitHub-Repository und der offiziellen Website abgeglichen werden.

Dieser erste Teil der Serie gibt einen Überblick über Architektur, Begriffe und typische Einsatzmöglichkeiten. Das schafft die Grundlage, um im zweiten Teil mit der praktischen Installation zu starten.

Was ist OpenClaw?

OpenClaw agiert als lokaler KI-Agent bzw. als Agenten-Runtime auf dem eigenen System. Das Projekt positioniert sich plattformübergreifend; die konkrete Installation kann sich aber je nach Betriebssystem und Version unterscheiden. Diese Serie konzentriert sich in den praktischen Teilen zunächst auf macOS, Linux und Raspberry Pi. Windows-Setups sollten anhand der jeweils aktuellen Projekt-Dokumentation gesondert geprüft werden.

Statt ausschließlich über eine eigene Chat-App bedient zu werden, kann OpenClaw in bestehende Kanäle eingebunden werden. Eingehende Nachrichten werden über Channel-Plugins an den lokalen Gateway weitergereicht; der Agent verarbeitet sie mit einem konfigurierten Modell und kann anschließend freigegebene Tools nutzen.

Typische Werkzeuge sind zum Beispiel:

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

Zusätzlich lassen sich wiederkehrende Aufgaben über OpenClaw-eigene Automations- bzw. Cron-Funktionen abbilden. Mehrere Sessions, Workspaces oder Agentenrollen können je nach Setup getrennt betrieben werden. Im Gegensatz zu reinen Cloud-Diensten liegt die Orchestrierung dabei auf dem eigenen Rechner. Die eigentlichen Sprachmodelle werden separat konfiguriert, typischerweise über Provider-APIs oder, falls in der verwendeten Version und Umgebung unterstützt, über lokale Modell-Backends.

Die Philosophie hinter dem System

Das Projekt beschreibt sich mit dem „Lobster Way“: OpenClaw soll flexibel, robust und möglichst unabhängig von einer einzelnen Plattform funktionieren. Im Zentrum steht die lokale Kontrolle über den Steuerungs-Layer. Anwender entscheiden selbst, welche Provider, Tools, Plugins und Datenquellen genutzt werden.

Diese Architektur macht das System anpassbar. Wenn ein bestimmter Modellanbieter nicht verfügbar ist oder für eine Aufgabe ungeeignet erscheint, kann ein anderer Provider oder ein anderes Modell konfiguriert werden, sofern die aktuelle OpenClaw-Version diesen Pfad unterstützt. Skills und Plugins erweitern den Funktionsumfang, ohne dass der Gateway grundsätzlich neu gedacht werden muss.

Das bedeutet aber nicht, dass niemals Daten den Rechner verlassen. Sobald ein externer LLM-Provider, ein Messenger-Dienst oder ein Web-Tool genutzt wird, fließen Daten zu diesem Dienst. Der Vorteil von OpenClaw liegt darin, dass diese Verbindungen bewusst konfiguriert und lokal orchestriert werden, statt vollständig in einer geschlossenen Cloud-App verborgen zu sein.

Architektur und Funktionsweise

OpenClaw basiert auf einer modularen Architektur. Der wichtigste 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 OpenClaw-Dokumentation ist das Standardziel für die Gateway-WebSocket-Verbindung ws://127.0.0.1:18789. Dieses Loopback-first-Verhalten ist wichtig: Auf dem lokalen Rechner ist die Nutzung möglichst bequem, während Zugriffe von außerhalb bewusst abgesichert werden müssen.

Wenn der Gateway nicht nur an 127.0.0.1, sondern an LAN-, Tailnet- oder andere Nicht-Loopback-Adressen gebunden wird, braucht er einen gültigen Authentifizierungspfad, etwa Token-/Passwort-Authentifizierung oder eine korrekt konfigurierte Trusted-Proxy-Variante. Für Remote-Zugriff werden typischerweise SSH-Tunnel oder ein VPN/Tailnet wie Tailscale genutzt. Pro Host wird in der Dokumentation ein Gateway empfohlen; mehrere Gateways sollten nur mit getrennten Profilen und Ports betrieben werden.

Die Web- bzw. Canvas-Oberflächen werden nach der Dokumentation auf demselben Gateway-Port bereitgestellt, unter anderem unter /__openclaw__/canvas/ und /__openclaw__/a2ui/. Sobald der Gateway über Loopback hinaus erreichbar ist, müssen auch diese Oberflächen durch die Gateway-Authentifizierung geschützt sein.

Channels sind pluginbasierte Anbindungen an Kommunikationsdienste. In der Code- und Dokumentationsstruktur finden sich unter anderem Channel-Aktionsruntimes für Discord, Slack, Telegram und WhatsApp. Diese Plugins leiten Nachrichten an den Gateway weiter und ermöglichen je nach Channel auch Antworten oder channel-spezifische Aktionen.

Die eigentliche Verarbeitung findet in Agents bzw. Sessions statt. Eine Session arbeitet mit einem Prompt, einem Modell, einem Workspace und einem Satz verfügbarer Tools. In eingebetteten Läufen werden dafür unter anderem eine sessionId, ein sessionKey, eine Session-Datei und ein workspaceDir übergeben. Praktisch heißt das: OpenClaw trennt Konversation, Arbeitsverzeichnis und Werkzeugkontext, damit Agenten kontrolliert arbeiten können.

Skills und Plugins liefern zusätzliche Anleitungen, Fähigkeiten oder Befehle. Ein Beispiel ist OpenProse: Dieses gebündelte Plugin ist laut Dokumentation standardmäßig nicht aktiv, kann aber einen /prose-Slash-Command bereitstellen und .prose-Workflows ausführen, etwa für mehrstufige Recherche- oder Schreibaufgaben. Solche Erweiterungen sind kein Ersatz für Sicherheitskonfiguration, sondern erhöhen den Funktionsumfang innerhalb der OpenClaw-Runtime.

Anbindung der KI-Modelle

OpenClaw bringt nach der hier geprüften Dokumentationslage kein eigenes großes Sprachmodell als zwingenden Kernbestandteil mit. Stattdessen wird ein Modellanbieter konfiguriert. In der Dokumentation finden sich beispielsweise Provider- und Modellparameter wie ein Provider-Feld mit Anthropic als Beispielanbieter und ein konkreter Modellname. Welche Provider, Modellnamen und Konfigurationsfelder gültig sind, hängt von der verwendeten OpenClaw-Version ab.

Für die Praxis ist wichtig:

• API-Schlüssel und Provider-Konfiguration gehören nicht in öffentliche Repositories.
• Externe Provider erhalten die an sie gesendeten Prompts, Kontextdaten und Tool-Ergebnisse.
• Lokale Modelle können Abhängigkeiten reduzieren, benötigen aber passende Hardware und eine unterstützte Backend-Konfiguration.
• Unterschiedliche Agenten oder Sessions können je nach Setup unterschiedliche Modelle nutzen.

Die konkrete Provider-Konfiguration behandelt diese Serie in Teil 3. Dort muss gegen die aktuelle OpenClaw-Dokumentation geprüft werden, welche Provider, Modellnamen und Konfigurationsfelder gültig sind.

Zielgruppe und Einsatzszenarien

OpenClaw richtet sich an technikaffine Anwender, Entwickler, Maker und Teams, die einen KI-Assistenten selbst betreiben möchten. Grundkenntnisse auf der Kommandozeile sind sinnvoll. Je nach Installationsweg kommen außerdem Node.js, Paketmanager, Docker oder systemnahe Dienste ins Spiel.

Typische Einsatzszenarien sind:

• persönliche Assistenz über Messenger-Nachrichten,
• Recherche, Zusammenfassung und Vergleich von Web-Inhalten,
• lokale Datei- und Workspace-Aufgaben,
• Automationen über geplante Aufgaben oder Cron-ähnliche Funktionen,
• wiederverwendbare Workflows mit Skills oder Plugins,
• Team- oder Labor-Setups mit kontrollierter Gateway-Konfiguration.

Smart-Home-, Kalender- oder Spezialintegrationen sind möglich, wenn passende Tools, Plugins oder externe Schnittstellen eingerichtet sind. Sie sollten aber nicht als automatisch vorhandene Grundfunktion verstanden werden.

Wichtige Begriffe im Überblick

Begriff	Kurzerklärung
Gateway	Der zentrale lokale Daemon, der Channel-Verbindungen, WebSocket-Steuerung, Sessions und Tools koordiniert. Standardmäßig arbeitet er loopback-first über 127.0.0.1.
Agent / Session	Eine laufende KI-Verarbeitung mit Prompt, Modell, Kontext, Werkzeugen und Session-Datei.
Channel	Plugin-Anbindung an einen Kommunikationsdienst wie Telegram, WhatsApp, Slack oder Discord.
Skill	Eine zusätzliche Fähigkeit oder Anleitung, die dem Agenten strukturiertes Verhalten oder Befehle bereitstellt.
Plugin	Erweiterungspaket, das neue Channels, Skills, Commands oder Tool-Integrationen hinzufügen kann.
Tool	Ein konkretes Werkzeug, das ein Agent nutzen darf, zum Beispiel Shell, Browser, Nachrichten- oder Dateiwerkzeuge.
Workspace	Das Arbeitsverzeichnis einer Session bzw. eines Agenten, in dem Dateien, Zustände oder projektspezifische Daten liegen können.
Canvas/Web-Oberfläche	Weboberflächen des Gateways, die auf demselben Gateway-Port bereitgestellt und bei Nicht-Loopback-Bindings durch Gateway-Auth geschützt werden müssen.

Sicherheit: Was man von Anfang an beachten sollte

Auch wenn dieser Teil noch keine Installation durchführt, ist ein Punkt zentral: OpenClaw kann mächtige lokale Werkzeuge bereitstellen. Ein Agent mit Shell-, Datei- oder Browser-Zugriff ist kein harmloser Chatbot.

Für spätere Teile der Serie gelten deshalb diese Grundregeln:

• Gateway zunächst lokal auf 127.0.0.1 betreiben.
• Nicht-Loopback-Zugriffe nur mit sauberer Authentifizierung aktivieren.
• Remote-Zugriff lieber über SSH-Tunnel oder Tailscale/VPN absichern als ungeschützt ins LAN oder Internet zu binden.
• API-Keys und Tokens nicht in Chatverläufen, Screenshots oder öffentlichen Repositories teilen.
• Tools nur aktivieren, wenn klar ist, wofür sie gebraucht werden.
• Bei Shell- und Dateizugriff mit Test-Workspaces beginnen, nicht direkt mit produktiven Daten.
• Messenger-Integrationen nur mit bewusst gewählten Accounts, Gruppen und Berechtigungen testen.

Diese Punkte sind besonders wichtig, weil OpenClaw gerade durch seine lokale Werkzeugfähigkeit mächtig wird.

Aufbau dieser Serie

Diese Tutorial-Serie führt Schritt für Schritt 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 ersten Teil sind keine besonderen Voraussetzungen nötig. Ein grundlegendes Interesse an KI-Agenten und ein Rechner mit Internetzugang genügen. Ein GitHub-Account ist hilfreich, um bei Bedarf den Quellcode des Projekts einzusehen.

Weiter mit Teil 2

Im nächsten Schritt folgt die praktische Umsetzung. Teil 2 zeigt die Installation von OpenClaw auf macOS, Linux oder einem Raspberry Pi. Dort wird der Gateway-Daemon gestartet, die lokale Oberfläche geprüft und die erste Grundkonfiguration vorbereitet. Die konkreten Installationsbefehle sollten dabei immer mit dem aktuellen Stand des OpenClaw-Repositories abgeglichen werden.

Zu Teil 2 →