(Deep-Dive Edition)

Wir leben im Zeitalter der „Agentic AI“. Die Vision: Ein autonomer Butler wie OpenClaw sortiert Mails, schiebt Trello-Cards und orchestriert APIs. Doch wer den Vorhang lüftet, blickt in ein organisches Trümmerfeld aus Microservices, das produktives Arbeiten im Keim erstickt.

Letzte Woche habe ich genau das durchexerziert. Das Ziel: Ein simpler API-Call. Der Aufwand? 14,5 Stunden Netto-Arbeitszeit. Hier ist die Obduktion eines Systems, das vor lauter Isolation das Arbeiten verlernt hat.

Absicht und Setting waren:

• Openclaw im Docker aus einem Image auf einem Mac Mini 2018 (Intel Chip, was die Virtualisierung etwas leichter machen sollte als in Mac OS mit M2 oder M4) aufsetzen. Ein Aufsetzen direkt auf dem Mac Mini verbot sich mir. Ich habe da viele Sachen drauf und die Sicherheitslücken sind nicht so einfach überschaubar.
• WhatsApp als Client nutzbar machen (ist on board)
• Terminal UI aufrufen, erste Konfiguration, OpenAI GPT-5 Nano statt Claude (die haben sich gestritten und Claude wollte OpenClaw im Chat nicht mal mehr kennen)
• Web GUI aufrufen, angebotene Skills konfigurieren, z.B. Trello
• Matrix zusätzlich zu WhatsApp anbinden
• Einen externen Client anbinden API Call sollte eine andere KI aufrufen, einen Text-String übergeben, auf Antwort warten.

Das ist passiert:

• Der Docker-Container aus einem Alpine-basierten Image startete und rief ein Onboarding Skript im Terminal auf. Nach einigen Anläufen lief das.
• Meine Versuche, das GUI (Webinterface) aufzurufen scheiterten wegen integrierter Sicherheitsschranken (man braucht ein Token, das man sich aus dem Container holen muss mit einem docker exec -it-Befehl). LLMs halluzinierten übrigens gerne Funktionen/Optionen, die es nicht gibt.
• Irgendwann fand ich, dass es ein TUI gibt (Terminal User Interface) und wie man es aufruft. Lief, es dauerte aber etwas bis man durchsieht.
• WhatsApp lässt sich mit dem Onboarding-Skript anbinden.
• Der Versuch, Matrix als Client anzubinden, scheiterte. Es gibt zwar ein Matrix Software Development Kit, das dokumentiert ist und das man nutzen kann, aber die Verschlüsselung geschieht mit Rust. Damit wurde der Container viel schwerer (einiges an GBs). Viele Ressourcen hätten im Container nachinstalliert werden müssen. Dies scheiterte offenbar am Paketmanagement für Bibliotheken und Inkompatibilitäten/Abhängigkeiten/Diskrepanzen, die so leicht nicht aufzulösen waren. Die Installation scheiterte, weil der Container kaputt ging und Docker abstürzte (hatte ich vorher noch nicht so gesehen).
• Wechsel auf ein schlankes node-basiertes Image, das nur ein Gateway baut mittels einer in einer im Docker-Container laufenden Binary.
• Matrix Anbindung aufgegeben
• API Call nach vielen Fehlversuchen halbwegs funktional.

1. Das „Uncanny Valley“: Intelligence ohne Execution

Ein ernster Stolperstein ist die funktionale Halluzination des angebundenen LLMs. Ein modernes LLM wie GPT-5 Nano ist darauf programmiert, „hilfreich“ zu sein. Im Kontext von OpenClaw führt das zu einem bizarren Effekt: Die KI sieht deine Skill-Dateien im Verzeichnis. Aber wenn das interne Tool-Gateway die Funktion nicht korrekt registriert hat, schickt das System beim Aufruf nur ein leeres Schweigen zurück.

Anstatt ehrlich zu sagen: „Ich komme hier nicht raus“, fängt die KI an zu lügen. Ich nenne das Functional Gaslighting. Die KI gaukelt Erfolg vor: „Ich habe die API aufgerufen“, sagt sie im Chat, während im Backend absolut nichts passiert ist. Das LLM interpretiert das Schweigen des Gateways als Erfolg. Ohne eine saubere Fehlerkultur im Framework wird die Intelligenz des Agenten zur Sackgasse.

2. Die organische Bruchstelle: Docker spawnt Docker

Man muss verstehen, wie OpenClaw organisch vorliegt: Es ist kein kompaktes Programm, sondern ein hochgradig fragmentiertes Ökosystem. Da ist der Core Orchestrator (FastAPI), das hübsche Frontend (Next.js) und der berüchtigte Agent Runner. Letzterer nutzt die Docker-API deines Hosts, um on-the-fly neue „Worker-Container“ zu gebären.

Das Problem: Diese Container sind genetisch isoliert. Sie erben weder DNS-Settings noch Netzwerk-Bridges deines Haupt-Setups. Während „Hallo Welt“ (lokale Textausgabe) klappt, stirbt jeder API-Call am digitalen Stacheldraht der Sandbox. Die „Magie“ der Autonomie scheitert hier an basalen Infrastruktur-Hürden.

3. Das Dokumentations-Vakuum: Blindflug in der Registry

Was am meisten Ärger macht: Dokumentation bzw. Nicht-Dokumentation. Viele Images in der Docker-Registry kommen ohne viel README.md daher. Man steht eher im Regen mit Fragen wie:

• Basiert das Image auf Alpine (musl) oder Debian (glibc)? (Ein entscheidender Unterschied für fast alle KI-Libraries!)
• Welche Ports sind offen?
• Welches Token will das GUI?
• Welche Environment-Variables werden injiziert?

Wer hier nicht manuell per docker image inspect und docker exec eine Art Reverse-Engineering betreibt, hat wenig Chancen. Es ist ein „Move fast and break things“-Ansatz, bei dem die Developer-Experience auf der Strecke bleibt. Das dauert und man tippt sich im Terminal die Finger wund.

4. Die „Think-Modus“-Falle: Warum KI-Hilfe versagt

Vielleicht denkst du: „Frag doch Gemini oder ChatGPT im Think-Modus!“ Vergiss es. Diese Modelle kennen die Doku von gestern, aber nicht die „Breaking Changes“ von heute. OpenClaw ändert seine Architektur und Namen so oft, dass externe KIs nur planlos raten. Sie schlagen Configs vor, die seit drei Versionen deprecated sind. Wir sind zurück in der „MS-DOS-Phase“ der IT: Man muss die Jumper (Docker-Configs) wieder von Hand setzen, damit der Sound (die API) läuft.

5. Die Abrechnung: Wirtschaftlichkeit vs. Nerd-Spielerei

Lass uns die harte Rechnung aufmachen:

• Aufwand: 14,5 Stunden „Dev“-Zeit (Debugging, Container-Patching, Log-Analyse).
• Ergebnis: Ein mühsam erkämpfter API-Call.
• Fazit: Eigentlich ein wirtschaftliches Desaster. In dieser Zeit hätte ich ein klassisches Python-Skript oder einen n8n-Workflow erstellt, und das „Problem“ in 15 Minuten gelöst, (wenn es nur um die API geht).

Fazit: Magie oder Masochismus?

Die Vision ist großartig: Ein Butler, der Trello sortiert und Mails beantwortet. Aber solange wir 90 % der Zeit mit Infrastruktur-Debugging verbringen, bleibt der Agent ein aufwendiges Spielzeug.

Meine Empfehlung:

• JA zu Frameworks wie OpenClaw: Wenn du hunderte Agenten in einer hochgesicherten Enterprise-Umgebung skalieren musst und ein eigenes Ops-Team hast. Mach das!
• NEIN: Wenn du im Home Office oder für dein Zeug einfach nur produktiv sein willst. Greif zum „nackten“ Skript oder zu stabilen Low-Code-Plattformen.

Abschlussgedanke: KI-Agenten sollen unsere Probleme lösen, nicht neue erschaffen. Bevor du dich ins nächste Framework stürzt, frag dich: Baue ich gerade eine Lösung oder nur ein Denkmal, um der Komplexität zu huldigen?

Persönliches Resümee: Bin ich vielleich einfach nur zu dumm für OpenClaw?

Nach diesem Marathon stellt man sich zwangsläufig die Sinnfrage. Ist es Intelligenz-Defizit oder ein massiver Overhead-Fehler.

• Spezialwissen vs. Dummheit: Man braucht Spezialwissen, sollte Erfahrung haben wo und wie Dinge vielleicht dokumentiert sind. Man scheitert weniger an der KI, sondern an der Infrastruktur, die für den Zweck (hier gings um einen API-Call). Man muss darauf kommen oder es wissen, dass und wie Features blockiert sind aus Sicherheitsaspekten heraus.
• Das Framework-Paradoxon: High-End-Frameworks sind high end, heißt: Man muss sie kennen. Damit schießt man aber eben mit Kanonen für Spatzen. Wer versucht, mit einem Flugzeugträger über einen Bach zu setzen, scheitert nicht am Steuern, sondern an der Wahl des Gefährts.

Mein abschließendes Learning: Ich denke dafür zu pragmatisch, weil es mir nicht darum geht, 14 Stunden lang Komplexität zu generieren, wenn ein 30-Minuten-Skript den Job erledigt hätte. Aber wie schafft man sich sonst das Wissen drauf?

Ex-post-Analyse: Was hätte ich vorher wissen müssen?

Hinterher ist man immer schlauer. Aber bei der Analyse meiner 14,5 Stunden wurde mir klar: Mein Problem war, dass mir die impliziten technischen Anforderungen des Frameworks fehlten. Wer mit OpenClaw experimentiert, sollte diese drei Ebenen vorab validieren:

• Ebene 1: Die Architektur-Wahrheit (Docker-Orchestrierung): OpenClaw führt Agenten-Code nicht lokal aus. Es ist eine Schicht, die „on-the-fly“ neue Docker-Worker gebärt. Mein Problem war kein Python-Fehler, sondern ein Netzwerk-Routing-Problem im Docker-Stack.
• Ebene 2: Die Sicherheits-Philosophie (Zero-Trust-Isolation): Die Standard-Einstellung vieler Agent-Sandboxen ist „Nichts geht rein, nichts geht raus“. Für einen API-Call nach draußen muss man die Sandbox-Konfiguration aktiv aufbohren und im Einzelfall wissen, wie.
• Ebene 3: Die Dependency-Hölle (Base-Image-Check): Wer Python-KI-Libraries nutzt, braucht glibc. Wer ein Alpine-Image (musl) nutzt, hat verloren. Ein 5-minütiger Check des Base-Images vorab hätte vielleicht Stunden an Debugging gespart.

---

---