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-Projekt für einen selbst gehosteten KI-Assistenten. In deiner Umgebung läuft ein Gateway-Prozess. Er nimmt Nachrichten aus angebundenen Chat-Kanälen entgegen, ordnet sie einem Agenten zu und verbindet diesen mit Modellen, Werkzeugen und Automationen.

Die OpenClaw-Dokumentation nennt unter anderem Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp und Zalo als mögliche Channels. Welche Anbindungen in deinem Setup verfügbar sind, hängt von der installierten Version, der Konfiguration und teilweise von Plugins ab.

OpenClaw dient als selbst gehostete Vermittlungsschicht zwischen Kommunikationsdiensten und einem handlungsfähigen KI-Agenten. Ein Agent kann je nach Freigabe Text erzeugen, Dateien lesen, Prozesse starten, Webseiten aufrufen oder Nachrichten versenden.

Dieser Auftakt bleibt konzeptionell. Du installierst noch nichts. Stattdessen klärst du, wie das System aufgebaut ist, welche Datenflüsse entstehen und ob OpenClaw zu deinem Vorhaben passt.

Für wen ist dieser Einstieg gedacht?

OpenClaw passt zu dir, wenn du einen KI-Assistenten über eigene Infrastruktur betreiben und selbst über Channels, Modellprovider, Werkzeuge und Erweiterungen entscheiden möchtest. Grundkenntnisse im Umgang mit einem Terminal, Konfigurationsdateien und Zugangsdaten helfen bei den späteren Teilen der Serie.

Für diesen Einstieg brauchst du einen internetfähigen Rechner und etwas Zeit, um dein geplantes Setup einzuordnen. Ein GitHub-Account ist optional. Die öffentliche Dokumentation und das Repository lassen sich ohne Anmeldung lesen.

Nach diesem Teil solltest du die Aufgabe des Gateways erklären und Agent sowie Session auseinanderhalten können. Außerdem kannst du einschätzen, wann Daten trotz Self-Hosting an externe Dienste fließen und welche Entscheidungen vor der Installation anstehen.

Was OpenClaw im Alltag macht

Nehmen wir ein konkretes Beispiel: Du schickst deinem Assistenten über Telegram die Nachricht, eine Datei im Projektordner zusammenzufassen.

Der Telegram-Channel liefert die Nachricht an den OpenClaw Gateway. Das Routing ordnet sie dem vorgesehenen Agenten und einer Session zu. Der Agent arbeitet innerhalb seines konfigurierten Workspace, verwendet ein freigegebenes Datei-Tool und sendet den benötigten Kontext an das ausgewählte Sprachmodell. Die Antwort läuft anschließend über den Gateway zurück in denselben Chat.

Telegram transportiert die Nachricht. Der Gateway vermittelt und routet. Der Agent bringt Konfiguration, Workspace und Werkzeugregeln mit. Die Session hält den Zustand dieser konkreten Unterhaltung. Das Modell erzeugt die Antwort; Channel-Routing und lokale Dateiberechtigungen bleiben Aufgaben anderer Komponenten.

Diese Trennung macht OpenClaw anpassbar. Ein funktionierendes Setup verlangt dadurch mehrere Entscheidungen zu Datenwegen, Zugängen und Werkzeugrechten.

Architektur: die Komponenten im Zusammenhang

Nachricht aus einem Channel
           │
           ▼
┌──────────────────────────┐
│     OpenClaw Gateway     │
│  Routing und Verbindung  │
└────────────┬─────────────┘
             │
             ▼
┌──────────────────────────┐
│          Agent           │
│ Workspace, Modellregeln, │
│ Tools und Erweiterungen  │
└───────┬──────────┬───────┘
        │          │
        ▼          ▼
   Modellprovider  freigegebene Tools
        │
        ▼
 Antwort über den Channel

Session: Zustand der konkreten Unterhaltung

Der geführte Konfigurationsweg openclaw configure enthält die Bereiche workspace, model, web, gateway, daemon, channels, plugins, skills und health. Die Gliederung verdeutlicht die verschiedenen Konfigurationsebenen des Systems.

Gateway

Der Gateway ist der laufende Vermittlungsprozess. Er verbindet Channels mit Agenten und stellt die gemeinsame Laufzeit für Routing, Konfiguration und weitere Funktionen bereit.

Channels

Channels sind Anbindungen an Kommunikationsdienste. Einrichtung und Funktionsumfang unterscheiden sich je nach Plattform. Ein Channel kann etwa ein Bot-Token, einen Login, eine Freigabe eingehender Kontakte oder besondere Regeln für Gruppenchats verlangen.

Agent

Ein Agent ist eine konfigurierte Arbeitseinheit. Zu seiner Umgebung können ein Workspace, Modellvorgaben, Werkzeugregeln, Skills und weitere Ressourcen gehören. Seine möglichen Aktionen ergeben sich aus dieser Konfiguration und den eingeräumten Berechtigungen.

Session

Eine Session ist der Gesprächs- und Laufzeitzustand einer konkreten Unterhaltung. Sie enthält den zugehörigen Verlauf und Kontext. Je nach Oberfläche kann sie auch eine temporäre Modellauswahl tragen. Die dauerhaftere Agentenkonfiguration bleibt davon getrennt.

Workspace

Der Workspace ist der einem Agenten zugeordnete Arbeitsbereich für Dateien und projektspezifischen Kontext. Diese Zuordnung gewährt für sich genommen keine unbegrenzten Dateirechte. Die aktivierten Tools, ihre Regeln und die Laufzeitumgebung bestimmen die konkreten Zugriffe.

Plugins, Skills und Tools

Plugins können zusätzliche Channels, Tools, Commands oder Integrationen bereitstellen. Skills geben einem Agenten strukturierte Anleitungen und Arbeitsabläufe. Ein Tool ist eine ausführbare Fähigkeit, etwa ein Datei-, Browser-, Shell- oder Nachrichtenwerkzeug.

Prüfe vor der Aktivierung die Herkunft einer Erweiterung, ihre benötigten Zugangsdaten und mögliche Nebenwirkungen. Plugins und andere ausführbare Komponenten können den Handlungsspielraum eines Agenten verändern.

Automationen

OpenClaw unterstützt Abläufe, die über unmittelbare Chat-Antworten hinausgehen. Der Dokumentationsindex ordnet wiederkehrende und ereignisgesteuerte Arbeit den Bereichen Tasks, Automations, Hooks, Standing Orders und Task Flow zu.

Die praktische Einrichtung folgt in Teil 7 zu Cron-Jobs, Heartbeats und Automationen. Dieser Überblick verwendet keine versionsabhängigen Automationsbefehle.

Wie OpenClaw Modelle auswählt

OpenClaw bindet Sprachmodelle über Modellprovider an. Modellreferenzen folgen dem Format provider/model. Enthält eine Modell-ID weitere Schrägstriche, bleibt das Providerpräfix am Anfang erhalten. Eine OpenRouter-Referenz kann daher beispielsweise openrouter/moonshotai/kimi-k2 lauten.

Zwei Konfigurationsebenen erfüllen dabei unterschiedliche Aufgaben:

Konfiguration	Aufgabe
agents.defaults.model	Enthält primary für das Standardmodell und fallbacks für Ersatzmodelle.
agents.defaults.models	Konfigurierter Modellkatalog und zugleich Allowlist. Schlüssel sind vollständige provider/model-IDs oder ein literales provider/* für einen dynamischen Providerkatalog.

Ist agents.defaults.models gesetzt, bestimmt diese Allowlist die auswählbaren Modelle — etwa im Modell-Picker der Control-UI und beim Chat-Kommando /model. Ohne diesen Eintrag zeigen die Oberflächen die explizit konfigurierten Provider-Modelle sowie Provider mit nutzbarer Authentifizierung.

Ein eingerichteter Provider wird dadurch nicht automatisch zum Standardmodell. Das Primärmodell steht in agents.defaults.model.primary und wird ausdrücklich gesetzt, beispielsweise so:

openclaw config set agents.defaults.model.primary openai/gpt-5.6-sol

Fallbacks können die Verfügbarkeit verbessern und zugleich den Datenweg verändern. Läuft ein Ersatzmodell bei einem anderen Anbieter, können Prompt, Kontext und relevante Tool-Ergebnisse an diesen Anbieter übertragen werden. Diese Folge gehört in die Auswahlentscheidung.

Die konkrete Einrichtung behandelt Teil 3 zu Modellprovidern, API-Keys und lokalen Optionen. Vergleiche dort die verwendeten Modellnamen und Authentifizierungswege mit der Dokumentation deiner installierten OpenClaw-Version.

Was Self-Hosting für den Datenweg bedeutet

Bei einem selbst gehosteten OpenClaw-Setup laufen Gateway und Orchestrierung in deiner Umgebung. Du legst fest, welche Channels, Provider, Tools und Erweiterungen angeschlossen werden.

Externe Dienste bleiben Teil des Datenwegs, sobald du sie einbindest. Ein Modellprovider erhält die Inhalte einer Modellanfrage. Messenger transportieren die dort gesendeten Nachrichten. Web-Suchen und andere APIs erhalten die jeweiligen Anfragen.

Für eine lokale Verarbeitung brauchst du neben dem selbst gehosteten Gateway passende lokale Modelle. Externe Integrationen müssen ebenfalls lokal betrieben oder abgeschaltet werden. Ob dein Setup dieses Ziel erreicht, ergibt sich aus dem gesamten Datenweg.

Passt OpenClaw zu deinem Vorhaben?

Beginne mit dem geplanten Channel. Für eine lokale Oberfläche brauchst du keine Messenger-Anbindung. Telegram, WhatsApp und andere Plattformen bringen eigene Konten, Tokens und Zugriffsregeln mit.

Lege danach fest, wo Inhalte verarbeitet werden dürfen. Berücksichtige dabei das primäre Modell, mögliche Fallbacks, Webdienste und Messenger. Sensible Daten brauchen klare Grenzen, bevor du einen Provider verbindest.

Definiere anschließend die Aktionen des Agenten. Eine Textassistenz kann ohne Shell- oder Nachrichtenwerkzeuge auskommen. Für Dateioperationen bietet sich ein begrenzter Test-Workspace ohne wichtige Originaldaten an.

Bestimme außerdem, wer den Agenten ansprechen darf. Externe Channels benötigen passende Zugriffskontrollen, besonders wenn der Agent Werkzeuge mit Nebenwirkungen verwenden kann.

Sind einzelne Antworten noch offen, starte mit einem kleinen Test-Setup ohne sensible Daten und weitreichende Tools. Du kannst den Umfang später kontrolliert erweitern.

Sicherheit vor der Installation

Ein OpenClaw-Agent kann abhängig von seinen Freigaben reale Änderungen auslösen. Behandle seine Werkzeuge deshalb wie ausführbare Funktionen mit möglichen Nebenwirkungen.

Halte Gateway und Verwaltungsoberflächen aus öffentlichen Netzen heraus, solange Authentifizierung und Netzwerkzugriff ungeklärt sind. Verwende für entfernten Zugriff einen abgesicherten Netzwerkpfad.

Speichere API-Keys, OAuth-Tokens und Messenger-Credentials weder in öffentlichen Repositories noch in Screenshots oder geteilten Chatverläufen. Prüfe Logs und Setup-Ausgaben vor dem Teilen auf Zugangsdaten.

Erprobe Shell- und Dateiwerkzeuge in einem begrenzten Test-Workspace ohne wichtige Originaldaten. Prüfe bei Plugins und Skills die Quelle sowie benötigte Berechtigungen vor der Aktivierung.

Teste ausgehende Nachrichten mit einem bewusst gewählten Konto oder Kanal, bevor Automationen reale Empfänger erreichen.

Ein geeigneter Testzustand sieht so aus: Der Gateway ist nur über den vorgesehenen Netzwerkpfad erreichbar. Ein kontrollierter Nutzer kann den Agenten ansprechen. Die freigegebenen Werkzeuge decken genau den Testfall ab.

Begriffe im Überblick

Begriff	Bedeutung
Gateway	Verbindet Channels, Agenten und Laufzeitfunktionen.
Agent	Arbeitseinheit mit Workspace, Modell- und Werkzeugregeln.
Session	Zustand einer konkreten Unterhaltung.
Channel	Anbindung an einen Kommunikationsdienst.
Model Provider	Anbieter oder Backend eines Modells.
Fallback-Modell	Ersatz für das primäre Modell.
Workspace	Dem Agenten zugeordneter Arbeitsbereich.
Skill	Strukturierte Anleitung für einen Agenten.
Plugin	Paket für zusätzliche Funktionen.
Tool	Ausführbare Fähigkeit eines Agenten.
Automation	Wiederkehrender oder ereignisgesteuerter Ablauf.

Die Begriffe beschreiben unterschiedliche Ebenen. Besonders wichtig: Ein Workspace bestimmt den Arbeitsbereich, während Tools und Laufzeitregeln über konkrete Zugriffe entscheiden.

Aufbau dieser Serie

Die weiteren Teile führen von der Installation bis zum Betrieb eines umfangreicheren Setups:

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

Weiter mit Teil 2

Teil 2 führt durch die Installation auf macOS, Linux oder Raspberry Pi. Dort prüfst du die Voraussetzungen für dein System. Danach folgen CLI-Installation, geführte Konfiguration, Modellzugang, Channel-Anbindung und Gateway-Betrieb.

Hast du OpenClaw bereits installiert, kannst du den eigenen Stand vor Teil 2 kurz gegenprüfen. openclaw --version zeigt die installierte Version, openclaw config get agents.defaults.model.primary das gesetzte Primärmodell. Kommt dabei kein Wert zurück, ist noch kein Standardmodell konfiguriert — das gehört zu Teil 3 und ist an dieser Stelle kein Fehler.

Falls Optionen oder Oberflächen von der Serie abweichen, vergleiche deine installierte OpenClaw-Version mit der zugehörigen Dokumentation. Folge neuen Sicherheitsabfragen, auch wenn ältere Abbildungen sie noch nicht zeigen.

Zusammenfassung

OpenClaw verbindet Chat-Kanäle über einen selbst gehosteten Gateway mit Agenten, Modellen und freigegebenen Werkzeugen. Der Agent trägt die dauerhaftere Konfiguration; die Session hält den Zustand einer konkreten Unterhaltung. Ein Workspace gehört zur Agentenkonfiguration und erteilt allein keine Dateiberechtigungen.

Bei der Modellauswahl trennen sich zwei Ebenen: agents.defaults.model bestimmt Primär- und Fallback-Modell. agents.defaults.models beschreibt den konfigurierten Katalog und begrenzt als Allowlist die auswählbaren Modelle. Self-Hosting gibt dir Kontrolle über die Orchestrierung, während angebundene Provider, Messenger und APIs weiterhin Daten erhalten können.

Du bist für Teil 2 vorbereitet, wenn du den Weg einer Nachricht durch Channel, Gateway, Agent, Session, Modell und Tools beschreiben kannst. Vor der Installation sollten außerdem der erlaubte Datenweg, die benötigten Werkzeuge und der zugelassene Nutzerkreis feststehen.