build-your-own-openclaw: ein Agent in 18 Schritten, ohne Framework-Magie
A step-by-step guide to build your own AI agent.
Auf einen Blick
- Was ist das?
- Das Repository ist ein Python-Tutorial, das einen Chat-Loop schrittweise zu einem ereignisgesteuerten, mehrkanaligen Agenten ausbaut. Es richtet sich an Entwickler, die verstehen wollen, was unter der Haube eines Agenten liegt, und die bereit sind, jeden Zwischenschritt selbst zu lesen und auszuführen.
- Für wen ist es gedacht?
- Sinnvoll ist das Tutorial für Entwickler, die einen Agenten von Grund auf verstehen und die Kontrolle über jede Schicht behalten wollen. Wer eine produktionsreife Bibliothek mit SLA, Support oder umfangreicher Dokumentation sucht, sollte woanders schauen.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 70 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Wem 18 nummerierte Verzeichnisse mehr bringen als ein Framework-Import
Die meisten Agenten-Bibliotheken liefern ein fertiges Objekt, das Werkzeuge registriert, Konversationen speichert und Antworten zurückgibt. Was zwischen Eingabe und Ausgabe passiert, bleibt verborgen. Genau dort setzt dieses Repository an. Es ist kein Paket, das man per pip installiert, sondern eine Sammlung von 18 Verzeichnissen, jedes mit einer eigenen README.md und einem lauffähigen Codebeispiel. Der Anspruch laut README: eine minimale Version von OpenClaw nachbauen. Die Zielgruppe sind Entwickler, die bereits Python schreiben und LLM-APIs aufgerufen haben, aber noch nie einen Agenten-Loop selbst implementiert haben. Wer nur eine Chat-Oberfläche braucht, ist hier falsch. Wer verstehen will, warum Kompaktierung von Gesprächsverlauf nötig wird, sobald Werkzeugausgaben den Kontext füllen, findet in Schritt 05-compaction den konkreten Mechanismus.
Vom Chat-Loop zur Ereignisarchitektur: die vier Phasen
Die Struktur ist in vier Phasen geteilt. Phase 1 (Schritte 0 bis 6) baut einen einzelnen Agenten auf: Chat-Loop, Werkzeuge, Skills über SKILL.md, Persistenz, Slash-Befehle, Kompaktierung, Web-Werkzeuge. Phase 2 (Schritte 7 bis 10) refaktoriert das Ganze zu einer ereignisgesteuerten Architektur mit Konfigurations-Neuladen ohne Neustart, Kanälen und WebSocket. Phase 3 (Schritte 11 bis 15) ergänzt Multi-Agent-Routing, Cron-Heartbeat, mehrschichtige Prompts, Post-Message-Back und Agent-Dispatch. Phase 4 (Schritte 16 und 17) behandelt Nebenläufigkeitskontrolle und Langzeitgedächtnis. Diese Reihenfolge ist didaktisch, nicht technisch zwingend. Wer nur den Chat-Loop verstehen will, kann nach Schritt 06 aufhören. Wer wissen will, wie ein Agent ohne Nutzereingabe arbeitet, springt zu 12-cron-heartbeat. Die Phasen bauen aufeinander auf, aber jede README.md steht für sich.
Der Mechanismus: was in jedem Schritt tatsächlich passiert
Das Repository beschreibt den Ablauf nicht als Fließband, sondern als wachsende Schleife. In 00-chat-loop ist es ein einfacher Austausch mit einem LLM. In 01-tools kommt Werkzeugaufruf hinzu: das Modell gibt eine Anfrage zurück, der Code führt sie aus und schickt das Ergebnis in die nächste Runde. In 02-skills wird die Fähigkeitsbeschreibung aus einer SKILL.md-Datei geladen, statt im Prompt zu stehen. Ab 03-persistence wird der Gesprächsverlauf gespeichert, was 05-compaction nötig macht, sobald der Kontext voll läuft. Ab 07-event-driven wird der Agent von der CLI entkoppelt: Ereignisse kommen aus verschiedenen Quellen, nicht mehr aus einer Eingabezeile. 09-channels und 10-websocket sind die sichtbaren Folgen davon. Die Konfiguration läuft über default_workspace/config.user.yaml, die Modellanbindung über LiteLLM, wie das README mit Verweis auf die LiteLLM-Provider-Liste angibt. Das ist der einzige feste externe Baustein, den das Material nennt.
Inbetriebnahme: zwei Befehle, eine Datei
Das README nennt genau zwei Schritte vor dem ersten Start. Erst die Beispieldatei kopieren: cp default_workspace/config.example.yaml default_workspace/config.user.yaml. Dann die Kopie mit den eigenen API-Schlüsseln füllen. Für die Anbieterauswahl verweist das README auf die LiteLLM-Provider-Dokumentation und auf PROVIDER_EXAMPLES.md im Repository. Danach heißt es im README schlicht: jeden Schritt lesen und ausprobieren. Es gibt keinen zentralen Startbefehl, keine Installation als Paket, keine Versionsnummer. Wer das Tutorial durchgeht, arbeitet sich durch Verzeichnisse, nicht durch eine Bibliothek. Das ist unbequem, aber es ist die Konsequenz aus dem Format. Die Konfigurationsdatei ist der einzige Berührungspunkt, den alle 18 Schritte teilen.
Wo das Tutorial an Grenzen stößt
Das Repository hat keine Releases. Die Versionshistorie fehlt, es gibt keine Tags, an denen man einen stabilen Stand festmachen könnte. Wer es als Grundlage für ein eigenes Projekt nimmt, arbeitet gegen den main-Branch und muss selbst entscheiden, welcher Commit als Basis taugt. Ein zweiter Punkt: die Lizenz ist MIT, das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung des Copyright-Hinweises. Wer den Code in ein Produkt übernimmt, muss diesen Hinweis mitführen. Drittens: das Tutorial ist kein Betriebshandbuch. Es zeigt, wie ein Agent aufgebaut wird, nicht wie er unter Last überwacht oder bei Ausfällen neu gestartet wird. 16-concurrency-control behandelt gleichzeitige Ausführungen, aber das ist ein Baustein, kein Betriebskonzept. Wer einen Agenten für echten Nutzerverkehr sucht, findet hier die Mechanik, nicht die Absicherung.
Der Unterschied zu einem Framework wie LangChain
LangChain und ähnliche Bibliotheken liefern Abstraktionen: Chains, Tools, Memory-Klassen, die man importiert und konfiguriert. Der Agent entsteht durch Zusammensetzen fremder Bausteine. Dieses Tutorial geht den umgekehrten Weg. Es gibt keine importierbare Agentenklasse, sondern 18 Verzeichnisse, in denen der Agent jeweils neu geschrieben wird, mit wachsendem Umfang. Der Unterschied liegt nicht in der Funktionalität, sondern im Verständnis. Wer LangChain nutzt, kann einen Agenten in wenigen Zeilen aufsetzen, weiß aber nicht, warum die Kompaktierung greift oder wann ein Werkzeugaufruf den Kontext sprengt. Wer das Tutorial durchgeht, hat jede dieser Entscheidungen einmal selbst getroffen. Der Preis ist Zeit und das Fehlen einer stabilen API. Der Gewinn ist, dass man bei Problemen nicht auf die Dokumentation eines Fremdanbieters angewiesen ist.
Wartung und Aktualisierung
Das Repository wird gepflegt, der letzte Push liegt nicht lange zurück, und es ist nicht archiviert. Es gibt aber keine Releases, also auch keine Versionsnummern, an denen man sich orientieren könnte. Updates erfolgen direkt auf main. Wer das Tutorial als Lernpfad nutzt, muss nichts weiter tun. Wer den Code als Basis für ein eigenes Projekt nimmt, sollte den Stand forken und selbst versionieren, weil upstream keine Stabilitätsgarantie gibt. Die MIT-Lizenz erlaubt das ausdrücklich, solange der Copyright-Hinweis erhalten bleibt. Ein Punkt, den das Material nicht klärt: ob und wie Breaking Changes kommuniziert werden. Ohne Releases und ohne Changelog bleibt nur der Blick in die Commit-Historie.
Redaktionelles Fazit
Sinnvoll ist das Tutorial für Entwickler, die einen Agenten von Grund auf verstehen und die Kontrolle über jede Schicht behalten wollen. Wer eine produktionsreife Bibliothek mit SLA, Support oder umfangreicher Dokumentation sucht, sollte woanders schauen. Vor dem Start lohnt es sich, die Datei config.user.yaml gegen PROVIDER_EXAMPLES.md zu prüfen und die Schritte 00-chat-loop und 16-concurrency-control zuerst zu lesen, weil sie die beiden Enden der Komplexitätsskala markieren.
Community-Notizen