OpenClaw Grundlagen - Was ist OpenClaw, und für wen?

OpenClaw ist ein Open-Source-Framework für KI-Agenten, das den Schritt vom isolierten Chat-Prompt zum tatsächlich handelnden System praktikabel macht. Es bündelt LLM-Aufruf, Tool-Nutzung, Gedächtnis und externe Datenquellen über das Model Context Protocol (MCP) in einer kleinen, gut nachvollziehbaren Codebasis. Diese erste Lektion liefert dir eine saubere Definition, erklärt die Architektur, zeigt typische Einsatzszenarien und ordnet OpenClaw gegen LangChain, Crew und AutoGen ein. Am Ende weißt du, ob OpenClaw zu deinem Stack passt und welche Voraussetzungen du für die folgenden Lektionen mitbringen solltest.

Was ist OpenClaw?

OpenClaw ist ein modulares Framework, mit dem du autonome und teilautonome KI-Agenten aufbaust. Im Kern stellt es einen Agent-Loop bereit, der Eingaben entgegennimmt, ein Sprachmodell befragt, Tool-Aufrufe orchestriert, Zwischenergebnisse speichert und so lange iteriert, bis eine Aufgabe gelöst ist. Der Quellcode liegt auf github.com/openclaw/openclaw.

Architektonisch bringt OpenClaw vier klar getrennte Bausteine mit: einen Agent-Kern (Loop und Policy), ein Tool-Interface (lokale Funktionen oder externe MCP-Server), eine Memory-Schicht (Buffer, Summary oder Retrieval) und Prompt-Templates für rollen- und aufgabenspezifische Anweisungen. Dieser strikte Schnitt sorgt dafür, dass du jede Komponente einzeln testen, austauschen oder durch ein eigenes Implementat ersetzen kannst. Wer schon einmal mit überfrachteten Agent-Frameworks gerungen hat, erkennt sofort den Mehrwert: keine versteckten Magie-Layer, kein „Cloud-Lock-in”, sondern Python- und Node-Code, den du in zwei Stunden gelesen hast.

OpenClaw ist als Reaktion auf eine sehr konkrete Beobachtung entstanden: Viele DACH-Teams wollen Agenten produktiv betreiben, scheitern aber an überdimensionierten Ökosystemen. Das Projekt wurde 2025 als Konsolidierung mehrerer interner Agent-Stacks veröffentlicht und in den Folgemonaten konsequent verschlankt. Statt jedes Feature-Request zu integrieren, betont das Maintainer-Team die orthogonale Trennung von Verantwortlichkeiten und die Lesbarkeit des Loops. Wer den Source liest, versteht in einer Sitzung, was passiert.

Der aktuelle Maintainer-Status ist gesund: regelmäßige Releases, verlässliche Issue-Reaktion und ein wachsender Pool an MCP-kompatiblen Tools, die ohne Forking funktionieren. Die Community ist kleiner als bei LangChain, aber dafür technisch ernsthaft. Es gibt einen schlanken Core, der semantisch versioniert wird, plus optionale Pakete für Memory-Backends, Provider-Adapter und Observability. Dieser Aufbau macht das Framework attraktiv für Teams, die Wert auf Wartbarkeit legen.

OpenClaw steht unter der Apache-2.0-Lizenz. Das bedeutet: kommerzielle Nutzung erlaubt, Modifikationen erlaubt, Weitergabe erlaubt, sofern Lizenz- und Copyright-Hinweise erhalten bleiben. Ein Patentfrieden ist mitgedacht, was vor allem für DACH-Unternehmen mit vorsichtigen Rechtsabteilungen relevant ist. Du kannst das Framework also bedenkenlos in interne SaaS-Produkte einbetten, ohne unter eine Copyleft-Pflicht zu fallen oder spätere Lizenzgebühren befürchten zu müssen.

Die Roadmap zielt auf drei Bereiche: bessere Multi-Agent-Orchestrierung als optionales Add-on, vereinfachte Distributed-Tracing-Integration über OpenTelemetry und ein erweitertes Plugin-Verzeichnis für MCP-Server. Damit positioniert sich OpenClaw als Framework, das nicht alles selbst macht, sondern sauber mit dem wachsenden MCP-Ökosystem zusammenarbeitet. Wenn du heute einsteigst, baust du auf einem Fundament, das in den nächsten Quartalen primär Stabilität und Werkzeug-Kompatibilität bringt, statt mit Breaking Changes zu überraschen.

Konkret bedeutet die Apache-2.0-Lizenz für DACH-Teams: Dein interner Fork darf eigene Anpassungen enthalten, ohne dass du sie zurück an die Community geben musst. Du kannst OpenClaw also in geschlossener Form weiterentwickeln, etwa um Authentifizierung gegen ein internes IAM oder um proprietäre Tool-Integrationen für deine ERP-Landschaft. Trotzdem wird empfohlen, generische Verbesserungen zurückzuspielen, weil das die langfristige Wartbarkeit deines Forks reduziert. Jeder Patch, den der Upstream akzeptiert, ist ein Patch, den du nicht mehr selbst gegen neue Major-Versionen rebasen musst.

Wie ist OpenClaw aufgebaut?

Der Agent-Loop ist das Herzstück von OpenClaw. Er nimmt eine Nutzeranfrage entgegen, baut den Prompt aus System-Anweisungen, Memory-Auszug und aktueller Frage, ruft das LLM auf und prüft die Antwort: Ist es ein Tool-Call, wird das Tool ausgeführt und das Ergebnis zurückgespielt. Ist es eine finale Antwort, wird die Schleife beendet. Diese explizite Schrittstruktur ist der wichtigste Unterschied zu Frameworks, die Iteration in einer einzigen agent.run()-Black-Box verstecken.

Das Tool-Interface ist bewusst minimal: Eine Funktion bekommt einen Namen, eine JSON-Schema-Beschreibung der Parameter und einen Handler. Tools können lokal als Python- oder TypeScript-Funktion existieren oder als externer MCP-Server über stdio bzw. HTTP angebunden werden. Letzteres ist der entscheidende Hebel, denn das gleiche Tool funktioniert dann auch in Claude Desktop, Cursor oder anderen MCP-Hosts. Du schreibst es einmal und nutzt es überall.

Die Memory-Schicht bietet drei Strategien, die du je nach Anwendungsfall mischst. Buffer-Memory hält die letzten N Turns wörtlich vor und ist ideal für kurze, transaktionale Sessions. Summary-Memory komprimiert ältere Turns durch ein zweites LLM-Passing in eine Zusammenfassung, was den Token-Verbrauch in langen Gesprächen begrenzt. Retrieval-Memory legt Vektor-Embeddings in einer Datenbank ab und holt nur thematisch passende Fragmente in den aktuellen Kontext, was sich für Wissensbasen und Customer-Support-Bots eignet.

Die MCP-Bridge ist mehr als ein Adapter: Sie übersetzt zwischen dem internen Tool-Format von OpenClaw und dem öffentlichen MCP-Protokoll. Konkret bedeutet das, dass du externe MCP-Server (Filesystem-Zugriff, GitHub, Slack, eine SQL-Datenbank) per Konfiguration einhängst und sofort Tools bekommst, ohne Adapter-Code zu schreiben. Umgekehrt kannst du eigene Tools als MCP-Server exponieren, sodass andere Hosts sie wiederverwenden können. Diese Bidirektionalität ist im aktuellen Markt selten und einer der stärksten Hebel von OpenClaw.

Über die Policy-Schicht steuerst du, wie der Agent zwischen Tool-Calls und LLM-Antworten entscheidet. Die Default-Policy ist eine ReAct-Variante mit harter Iterations-Obergrenze und Tool-Whitelist. Für anspruchsvollere Szenarien definierst du eigene Policies, etwa eine Plan-and-Execute-Strategie, die zuerst einen Plan generiert und dann jeden Schritt als Sub-Agent ausführt. Wichtig: Policies sind regulärer Python-Code, kein YAML, keine externe DSL. Du debuggst sie mit pdb, wie jeden anderen Code auch.

Ein konkretes Praxisbeispiel: Ein DACH-Online-Shop nutzt OpenClaw für die Vorqualifikation eingehender Support-Tickets. Die Policy ist hart begrenzt auf maximal vier Iterationen, drei zugelassene Tools (CRM-Lookup, Bestellstatus, Wissensdatenbank) und eine Eskalations-Funktion, die ab einer bestimmten Eskalationsstufe einen Slack-Thread im Support-Channel öffnet. Diese Konstruktion ist mit unter 200 Zeilen Python umgesetzt, läuft seit Monaten stabil und erspart dem Team etwa 40 Prozent der Erstkontakt-Aufwände. Der Schlüssel war nicht ein cleveres Modell, sondern eine kontrollierte Policy mit klaren Abbruchbedingungen.

Observability ist erste Klasse. Jeder Schritt im Loop emittiert ein strukturiertes Event mit Timestamp, Token-Verbrauch, gewähltem Tool und Zwischenergebnis. Diese Events kannst du an stdout, an OpenTelemetry-Backends wie Tempo oder direkt an Langfuse weitergeben. Für die Praxis heißt das: Wenn dein Agent in Produktion eine merkwürdige Entscheidung trifft, hast du im Trace genau den Prompt, das LLM-Output und den Tool-Response, die zur Entscheidung geführt haben. Kein Reverse-Engineering, kein Raten.

┌────────────┐    ┌────────────┐    ┌────────────┐
│   User     │───▶│   Agent    │───▶│    LLM     │
└────────────┘    │   Loop     │    └────────────┘
                  │            │           │
                  │            │◀──────────┘
                  │            │
                  │            │───▶ Tools (MCP)
                  │            │───▶ Memory
                  └────────────┘

Wann ist OpenClaw die richtige Wahl?

OpenClaw passt überall dort, wo ein Team einen Agent in produktiver Umgebung kontrollieren, beobachten und schrittweise erweitern will. Die typischen Sweet-Spot-Szenarien sind interne Automatisierung, Customer-Support-Bots mit Eskalationspfad und domänenspezifische Research-Assistenten. In all diesen Fällen ist nicht „möglichst smart” das Ziel, sondern „möglichst zuverlässig, nachvollziehbar und debugbar”.

Interne Automatisierung ist der häufigste Einstieg: Ein Agent, der Tickets klassifiziert, Mails priorisiert, Reports aus Datenbanken zusammenstellt oder Build-Pipelines triggert. Hier sind die Anforderungen klar: definierte Tools (typischerweise drei bis sieben), eine begrenzte Anzahl von Aufgabentypen und ein Audit-Log, das die Compliance-Abteilung beruhigt. Genau dafür ist OpenClaw gebaut. Du startest mit einem Prompt, drei Tools und einem Buffer-Memory und hast in einem Tag einen lauffähigen Prototyp, den du danach iterativ härtest.

Customer-Support-Bots sind ein zweites starkes Feld, vor allem wenn sie nicht „Kundenkontakt zu jedem Preis” leisten sollen, sondern strukturierte Vorqualifikation: Kontext aus dem CRM ziehen, FAQ-Eintrag finden, im Zweifel an einen Menschen eskalieren. OpenClaws explizite Policies erlauben dir, Eskalation als harten Schritt zu definieren, statt sie dem LLM allein zu überlassen. Das ist in regulierten Bereichen (Finanz, Gesundheit, Versicherung) der Unterschied zwischen einem produktiven Bot und einem Compliance-Risiko.

Research-Assistenten sind die dritte typische Domäne: Agenten, die externe Quellen lesen, zusammenfassen und mit internen Daten verknüpfen. Hier spielt die Retrieval-Memory ihre Stärken aus, kombiniert mit MCP-Servern für Filesystem-Zugriff, Web-Suche und Datenbank-Queries. Solche Agenten ersetzen keine Analysten, aber sie verkürzen die Vorrecherche von Stunden auf Minuten und liefern dabei Quellenangaben, die ein Mensch nachprüfen kann.

Es gibt klare Anti-Use-Cases. Echtzeit-Massenverarbeitung ist keiner: Wenn du pro Sekunde tausende Anfragen bedienen willst, ist ein Agent-Loop mit mehreren LLM-Calls pro Anfrage strukturell zu langsam und zu teuer. Hier nimmst du eine spezialisierte Pipeline mit klassischem ML oder eine einzige, gut getunte LLM-Inferenz pro Request. OpenClaw ist Werkzeug für Aufgaben, bei denen Latenz von einigen Sekunden akzeptabel ist und das Mehr an Intelligenz den Mehraufwand rechtfertigt.

Auch hochregulierte Domänen ohne Audit-Log sind heikel. OpenClaw liefert die Bausteine für nachvollziehbare Entscheidungen, aber wenn du diese Bausteine nicht mit OpenTelemetry, Datenbank-Logs und Versionierung der Prompts kombinierst, fehlt die forensische Tiefe, die etwa eine BaFin-Aufsicht erwartet. Die gute Nachricht: Mit der Standard-Observability lässt sich das Audit-Log sauber bauen, du musst es aber bewusst tun.

Ein weiteres realistisches Einsatzfeld ist Developer-Productivity. Agenten, die Code-Reviews vorbereiten, Migrations-Skripte generieren oder CI-Logs nach Fehlerursachen durchsuchen, sind in vielen Engineering-Teams 2026 normal geworden. OpenClaw eignet sich dafür ausgezeichnet, weil die MCP-Integration den direkten Zugriff auf das Filesystem, GitHub-APIs und Build-Systeme ohne Maßanfertigung erlaubt. Du beschreibst die Aufgabe im System-Prompt, hängst zwei oder drei MCP-Server ein und hast einen Agenten, der konkrete Pull-Request-Vorschläge erzeugt. Die Wartung solcher Agenten bleibt überschaubar, weil jedes Tool isoliert testbar ist.

OpenClaw vs. LangChain, Crew, AutoGen

LangChain ist das große Schweizer Taschenmesser unter den Agent-Frameworks. Es deckt enorm viel ab, von Document-Loadern über Vektor-Stores bis zu Agent-Templates, und bezahlt diesen Funktionsumfang mit einer steilen Lernkurve und vielen ineinandergreifenden Abstraktionen. Wer einen Prototyp in zwei Stunden braucht, kommt mit LangChain schnell ans Ziel. Wer in einem halben Jahr noch verstehen will, warum ein Agent eine bestimmte Antwort gibt, fängt mit OpenClaw besser an.

Crew (oft als CrewAI bezeichnet) zielt auf Multi-Agent-Orchestrierung: Mehrere spezialisierte Agenten arbeiten als Team zusammen, jeder mit eigener Rolle, eigenem Toolset und eigener Memory. Das ist mächtig, aber auch komplex. OpenClaw bietet Multi-Agent als optionales Pattern, nicht als Default, und macht damit Single-Agent-Use-Cases einfacher. Wenn dein Problem wirklich mehrere kollaborierende Rollen erfordert, ist Crew einen Blick wert. Für die meisten DACH-Praktiker reicht ein gut gebauter Single-Agent.

AutoGen aus dem Microsoft-Ökosystem positioniert sich ähnlich wie Crew, mit Schwerpunkt auf konversationsbasierter Agent-zu-Agent-Kommunikation. Es eignet sich gut für Forschungs-Setups und experimentelle Multi-Agent-Architekturen, ist in der Produktion aber schwerer zu zähmen. OpenClaw verzichtet bewusst auf die „Agenten unterhalten sich”-Metapher und bevorzugt klare Tool-Aufrufe und definierte Policies. Das macht das Verhalten besser vorhersagbar.

Die wichtigste praktische Differenz liegt im MCP-Support. OpenClaw spricht MCP nativ, ohne Adapter-Layer. Bei LangChain, Crew und AutoGen ist MCP über Plugins oder Community-Pakete möglich, aber nicht erste Klasse. Wer sein Tool-Ökosystem strategisch auf MCP setzt (was 2026 der naheliegende Pfad ist, weil Claude, Cursor und mehrere andere Hosts MCP sprechen), kommt mit OpenClaw schneller voran und bleibt portabler.

Auch die Frage der Wartungslast unterscheidet die Frameworks deutlich. LangChain-Anwendungen müssen häufig bei Minor-Releases nachziehen, weil sich Imports oder Default-Verhalten ändern; das kostet pro Quartal mehrere Stunden Refactoring. OpenClaw versioniert kleinen, stabilen Core und delegiert riskante Erweiterungen an separate Pakete, sodass du gezielt entscheidest, welches Risiko du upgradest. Crew und AutoGen liegen dazwischen: stabilisiert, aber mit größerer Oberfläche, was Lernzeit und Migrationsaufwand erhöht. Für ein Team, das nicht permanent Framework-Pflege betreiben will, ist diese Differenz finanziell relevant.

Kriterium	OpenClaw	LangChain	Crew	AutoGen
Lernkurve	Sanft	Steil	Mittel	Mittel
Abstraktionstiefe	Niedrig	Hoch	Mittel	Hoch
Multi-Agent	Optional	Add-On	Native	Native
MCP-Support	Nativ	Plugin	Plugin	Plugin
DACH-Community	Klein, wachsend	Groß	Mittel	Mittel

Voraussetzungen für die Akademie

Damit du den folgenden Lektionen ohne Reibung folgen kannst, brauchst du eine kleine, klar umrissene Toolchain. Die Akademie geht davon aus, dass du grundlegend mit Python und Node.js vertraut bist, einen Editor wie VS Code oder Neovim nutzt und die Kommandozeile nicht scheust. Vorkenntnisse in LLM-APIs sind hilfreich, aber kein Muss: Wir führen Begriffe wie System-Prompt, Tool-Call und Token-Limit dort ein, wo sie zum ersten Mal auftauchen.

Auf Hardware-Seite reicht jeder halbwegs aktuelle Laptop, denn OpenClaw ruft die LLM-Inferenz remote bei Anthropic, OpenAI oder einem lokalen Ollama-Server auf. Ein Linux-System oder macOS sind die unkompliziertesten Setups; unter Windows arbeitest du am besten mit WSL2, weil einige MCP-Server stdio-Pipes nutzen, die in nativem Windows zickig werden können. Ein API-Key bei Anthropic oder OpenAI kostet wenige Euro für die Trainingsphase und reicht für mehrere hundert Iterationen.

Hier die konkreten Anforderungen als Checkliste, die du vor der nächsten Lektion abhaken solltest:

• Python 3.11 oder neuer, idealerweise per pyenv oder uv verwaltet, sodass du Versionen sauber pinnen kannst.
• Node.js 20 oder neuer, falls du TypeScript-Beispiele ausprobieren oder MCP-Server in JavaScript schreiben willst.
• Git, um die Beispiel-Repos zu klonen und eigene Branches für Experimente anzulegen.
• Einen API-Key bei Anthropic oder OpenAI; für die ersten Lektionen reichen Beträge unter zehn Euro Guthaben.
• Linux, macOS oder Windows mit WSL2; native Windows-Shells sind möglich, aber wir testen die Beispiele primär auf POSIX-Systemen.
• Optional: Docker für Memory-Backends wie Qdrant oder Postgres, sobald wir zur Retrieval-Lektion kommen.

Wenn du noch keinen API-Key hast, ist Anthropic für die ersten Lektionen die pragmatischste Wahl, weil Claude bei Tool-Use konsistent gute Ergebnisse liefert und das MCP-Ökosystem ursprünglich aus diesem Umfeld stammt. OpenAI funktioniert ebenfalls; der entscheidende Punkt ist, dass beide Provider OpenAI-kompatible Schnittstellen anbieten oder einen offiziellen SDK-Adapter bereitstellen, sodass dein Code austauschbar bleibt. Wer komplett lokal arbeiten will, installiert Ollama mit einem Modell wie Llama 3.1 oder Mistral Nemo; die Qualität reicht für Lerneinheiten aus, ist aber bei komplexen Tool-Calls geringer als bei Frontier-Modellen.

Nächster Schritt

Wenn du die Voraussetzungen erfüllst, ist der nächste Schritt der Bau des ersten Agents: ein minimaler Loop mit einem einzigen Tool, einem definierten System-Prompt und einer sauber konfigurierten Provider-Anbindung. Diese praktische Übung macht die hier erklärten Konzepte greifbar und ist die Grundlage für alle weiteren Module. Du wirst dort sehen, wie wenig Code es tatsächlich braucht, um aus einem reinen Chat-Prompt ein handelndes System zu machen, und welche Stolperfallen typischerweise im ersten Loop auftauchen. Weiter geht es in Modul 2 - Erster Agent.