Ich habe OpenClaw zwei Wochen getestet: Das ist mein Fazit

Ich habe OpenClaw vor zwei Wochen installiert. Seitdem spreche ich fünf- bis zehnmal am Tag damit. Fangen wir mit den schlechten Nachrichten für Fans spektakulärer Demonstrationen an: Ich habe niemanden entlassen, meine Firma läuft nicht von selbst und keine Armee von Agenten arbeitet, während ich gemütlich meinen Kaffee trinke.

Die Realität ist weniger spektakulär, aber sie interessiert mich mehr. OpenClaw ist für einige bestimmte Aufgaben zu einem nützlichen verlängerten Arm geworden. Ich spreche normal mit ihm; er wählt seine Werkzeuge aus, arbeitet in einem Repository, öffnet einen Merge Request, transkribiert eine Sprachnachricht oder bereitet das Gerüst für eine Veröffentlichung vor. Und an manchen Tagen verbrennt er Tokens mit erstaunlicher Geschwindigkeit, zerstört seine eigene Konfiguration oder verlangt Zugriffe, die er niemals haben sollte.

Ich will gleich vorwarnen: Diese Geschichte wird bewusst bodenständig sein. Kein ‚Mein Leben wird nie wieder dasselbe sein‘, keine Szenen, in denen sechs digitale Agenten ein Unternehmen in meinem Schlaf leiten. Ich werde erzählen, was ich tatsächlich eingerichtet habe, was es mich gekostet hat, was kaputtgegangen ist und warum ich es trotzdem weiterhin nutze. Es ist weniger verkaufsfördernd, aber genau das hat mich interessiert, bevor ich es installiert habe.

Was OpenClaw einem LLM wirklich hinzufügt

Ein großes Sprachmodell erhält Text und gibt Text zurück. Die ganze scheinbare Magie beginnt dort. Ein Agent fügt eine Schleife hinzu: Mit der Nachricht übermittelt er dem Modell die Beschreibung der verfügbaren Werkzeuge. Das Modell antwortet dann nicht nur mit einem Satz; es kann in strukturierter Form darum bitten, eine Aktion auszuführen.

Diese Idee ist für mich immer noch ein kleiner intellektueller Schock. Wir sprechen von Modellen, die Code schreiben, ein Bild analysieren oder den Eindruck erwecken zu denken; doch im Kern des Systems gibt es immer noch nur eine Umwandlung von Text zu Text. In einem klassischen Chat schreibe ich eine Frage und bekomme eine Antwort. Mit einem Agenten fügt man einfach — "einfach" mit vielen Anführungszeichen — eine Liste von Dingen hinzu, die das System um das Modell herum ausführen kann.

Wenn ich ihm sage ‚Erinnere mich daran, in einer Stunde einen Kunden anzurufen‘, erkennt das Modell die Absicht, OpenClaw erstellt die Aufgabe, und das Ergebnis geht zurück zum Modell, damit es die Bestätigung formuliert. Um eine E-Mail zu senden, ein Repository zu prüfen oder einen Browser zu steuern, bleibt das Prinzip das gleiche: Das Modell gibt den Rat, das Gateway führt aus, und das Ergebnis geht zurück zum Modell.

Konkret wird mein Satz etwas, das wie ein JSON-Aufruf aussieht: Name des Tools, Uhrzeit, Erinnerungstext, eventuell die Gesprächs-ID. Das Gateway bekommt diesen Befehl, erstellt die Erinnerung und schickt dem Modell ein Ergebnis mit seiner ID zurück. Das Modell kann mir schließlich antworten: „Erledigt.“ Sogar dieser letzte Satz ist ein neuer Schritt. Der Agent feiert seinen Erfolg nicht alleine: Er fragt das LLM, wie er es mir ordentlich mitteilen kann.

Dieses Detail ist wichtig, weil es einen großen Teil des Mysteriums auflöst. OpenClaw ist kein digitales Bewusstsein, das in meinem Server versteckt ist. Ohne Modell „denkt“ es nicht. Es ist eine Orchestrierungsschicht, die Kontext transportiert, Werkzeuge bereitstellt, deren Aufrufe ausführt und die Ergebnisse zurückgibt. Bei jedem etwas unklaren Schritt fragt es beim LLM nach Rat. Das erklärt sowohl seine Flexibilität als auch seinen Verbrauch.

Die ersten Agenten funktionierten schon so, aber ihr Werkzeugkasten war festgelegt. Um das Versenden von E-Mails hinzuzufügen, schrieb ein Entwickler eine SMTP-Funktion, erklärte sie als Werkzeug – gegebenenfalls über MCP – und deployte dann die Anwendung neu. Das Modell erhielt dann bei jeder Anfrage die Beschreibung dieser neuen Funktion. Das war zwar effektiv, aber die Weiterentwicklung des Agenten blieb klassische Entwicklungsarbeit.

Wir hatten also schon vor OpenClaw Agenten. Wenn ihnen eine Funktion fehlte, konnte ich meine IDE öffnen, einen Code-Assistenten bitten, die Integration zu schreiben, sie in der Anwendung speichern und dann neu deployen. Das ging zwar viel schneller als früher, aber es blieb trotzdem immer noch ein Mensch dazwischen, um den generierten Code zu nehmen und an der richtigen Stelle einzufügen. Die Idee, die mir im Kopf herumschwirrte, war offensichtlich: Wenn der Agent dieses Bauteil schon schreiben kann, warum sollte er es dann nicht auch selbst installieren können?

Wo OpenClaw wirklich interessant wird, ist, dass es seine eigene Umgebung erweitern kann. Ich kann ihm sagen, dass es meine Sprachnachrichten akzeptieren soll: Es liest die Dokumentation, inspiziert die Maschine, installiert oder konfiguriert eine Komponente, fügt einen Hook hinzu und startet dann alles neu, was neu gestartet werden muss. Der Werkzeugkatalog ist nicht mehr festgelegt. Der Agent trägt selbst zur Entwicklung seiner Fähigkeiten bei.

Der Ablauf ist beim ersten Mal fast beunruhigend: Ich formuliere die Anforderung, er sucht die Dokumentation seiner eigenen Plattform, findet die Konfigurationsdatei und den erwarteten Hook-Typ, bereitet die Änderung vor und startet sich dann neu. Theoretisch muss ich den Entwickler des Agents nicht mehr anflehen, eine Funktion in einer nächsten Version hinzuzufügen. In der Praxis werde ich genau die Person, die überprüfen muss, dass der Agent kein Komma übersehen hat, bevor er sich selbst abschaltet.

Es ist berauschend. Es ist auch genau der Moment, in dem man vorsichtig sein sollte: Ein System, das seine Konfiguration ändern kann, kann ein Komma vergessen, ein ungültiges JSON erzeugen und sich danach weigern, neu zu starten. Mir ist das natürlich passiert.

Warum das ganze Internet ausgerastet ist

Die Idee eines Agenten, der sich selbst vervollständigen kann, lag schon eine Weile in der Luft. Mit Code-Assistenten war es schon viel schneller geworden, ein neues Tool zu schreiben. OpenClaw hat den Schritt überflüssig gemacht, bei dem ich den generierten Code nehmen, installieren, speichern und das System neu starten musste. Der Agent kann seine eigene Dokumentation lesen, verstehen, welche Datei geändert werden muss, die Komponente vorbereiten und seinen Dienst neu starten.

Natürlich haben sich die Demonstrationen sehr schnell verbreitet. Man hat gesehen, wie Assistenten E-Mail-Postfächer sortierten, Tickets reservierten, Formulare ausfüllten, Dashboards überwachten und andere Agenten koordinierten. Dann kamen die üblichen Versprechen: kein Team mehr nötig, kein Büro mehr nötig, alles arbeitet nachts von selbst. In dem Moment schaltet mein Reflex als alter Techniker ein.

Ich habe mir viele dieser Demonstrationen angesehen. Einige haben mir richtig gute Ideen gegeben; andere haben mich denken lassen: „Mein Gott, das sollte man auf keinen Fall machen.“ Ich werfe nicht alle Autoren in einen Topf – ich kann ja nicht jede Installation überprüfen – aber das Prinzip der Aufregung ist offensichtlich. Ein Video, in dem der Agent eine Reise bucht und auf Kunden antwortet, zieht mehr an als eine Geschichte, in der er korrekt einen Git-Branch erstellt. Trotzdem ist in meiner Arbeit die zweite Szene die wertvollere.

Seit Beginn meiner Karriere habe ich schon mehrere Technologien gesehen, die als unumkehrbare Spielveränderer präsentiert wurden. Virtuelle Welten sollten Büros ersetzen, Virtual Reality sollte unser Hauptbildschirm werden, und jede neue Welle sollte die vorherige überflüssig machen. Manche Bausteine überleben und werden nützlich. Die große Geschichte verschwindet dagegen meist viel schneller.

Ich arbeite seit 2008 in der IT. Ich habe mindestens fünf- oder siebenmal gehört, dass die Regeln sich endgültig geändert hätten. Sie entwickeln sich natürlich weiter, aber selten so, wie es in der Aufregungswoche angekündigt wurde. Dieser Skeptizismus hindert mich nicht daran, OpenClaw zu nutzen: Im Gegenteil, ich benutze es genug, um jeden Tag neue mögliche Fälle zu sehen. Er verhindert nur, dass ich den tatsächlichen Nutzen mit dem Trailer dieses Nutzens verwechsle.

Ich sage nicht, dass OpenClaw ein Gimmick ist. Ich benutze es tatsächlich mehrmals am Tag, was schon mehr ist als viele angeblich revolutionäre Werkzeuge, die getestet und dann vergessen wurden. Aber ich wollte eine bescheidenere Sache überprüfen: Wo ist der Wert, wenn man die Demo, das Video-Editing und das Science-Fiction-Vokabular weglässt?

Warum ich den Agenten nicht auf meinem Hauptrechner installiert habe

Der kürzeste Weg wäre, das Installationsskript auf meinem Arbeitscomputer zu starten und dann OpenClaw auf die Dateien, den Browser und die Anwendungen zugreifen zu lassen. In der Demo ist das genial: Der Agent findet einen Vertrag, ändert die Daten, vergleicht Tickets zwischen Brüssel und Amsterdam, füllt ein Formular aus oder nutzt eine bereits geöffnete Sitzung wieder.

Die Dokumentation bietet tatsächlich einen sehr kurzen Installationsbefehl für macOS, Linux, WSL oder PowerShell. Er lädt die Abhängigkeiten herunter, installiert den Dienst und legt ihn im Hintergrund ab. Das ist bequem, und genau deshalb rate ich davon ab, ihn einfach so auf dem Rechner auszuführen, auf dem sich dein ganzes digitales Leben und deine Arbeit befinden. Ein Ein-Zeilen-Befehl verkleinert den Vertrauensbereich nicht – er verschleiert ihn nur.

Auf dem Papier ist die positive Seite großartig. Ich kann sagen: „Finde den Vertrag dieses Kunden, aktualisiere das Datum und die Kontaktdaten und schick mir dann das Dokument zurück.“ Ich kann ihn bitten, den Browser zu öffnen, die Fahrpläne für eine Reise von Brüssel nach Amsterdam zu prüfen und eine Buchung mit den bereits gespeicherten Informationen vorzubereiten. Es ist die Jarvis-Fantasie, nicht mehr in einem Film, sondern direkt neben meinen echten Dateien und meiner echten Kreditkarte.

Das Problem liegt in genau dieser Demonstration: Er sieht die Dateien, den Browser und die Sitzungen. Ein Teil dieses Kontexts kann beim Anbieter des Modells landen. Dann reicht schon eine Halluzination, eine falsch verstandene Anweisung oder eine versteckte Injektion auf einer Webseite, um eine echte Aktion auszulösen. Ich habe überhaupt keine Lust, einem noch experimentellen Tool die Dokumente meiner Kunden, meine Schlüssel und meinen täglichen Browser anzuvertrauen.

Man könnte ein Filmszenario bauen, in dem der Anbieter des Modells gezielt nach meinen Geheimnissen sucht. Daran glaube ich nicht besonders. Ich halte mich nicht für interessant genug, als dass ein großes Unternehmen eine Spezialoperation gegen meine Festplatte starten würde. Aber technisch gesehen existiert die Vertrauenskette tatsächlich: OpenClaw übermittelt einem entfernten LLM die Beschreibung seiner Werkzeuge und einen Teil meines Kontexts; dieses LLM schlägt Werkzeugaufrufe vor; mein Rechner führt sie aus. Diesem Kreislauf die Möglichkeit zu geben, auf der Festplatte zu suchen oder einen Dienst zu installieren, verdient mehr als nur ein begeistertes Klicken auf ‚Weiter‘.

Es ist nicht einmal nötig, sich einen böswilligen Anbieter vorzustellen. Das glaubwürdigste Szenario ist viel alltäglicher: Eine Seite enthält eine Anweisung, die der Agent als Befehl versteht, ein Tool bekommt einen zu weiten Pfad, oder das Modell versteht „diesen Ordner aufräumen“ ein bisschen zu wörtlich. Die Gefahr besteht nicht nur darin, dass jemand meine Daten stiehlt. Die Gefahr ist auch, dass ein gut gemeinter Assistent genau das Falsche mit viel Begeisterung macht.

Modelle halluzinieren. Die besten irren sich seltener bei einfachen Additionen, aber bei komplexen Situationen machen sie immer noch Fehler – genau bei den Fällen, für die man ihnen ein Terminal und einen Browser gibt. Es ist also keine abstrakte Angst vor KI. Ich habe gesehen, wie Leute OpenClaw gefragt haben, „alles selbst zu regeln“, und dann um Hilfe kamen, als der Dienst nicht mehr startete. Das Modell hatte keine bösen Absichten: Es hatte einfach eine schlechte Datei geschrieben.

Der Browser vergrößert noch den Aktionsradius. Eine offene Sitzung enthält manchmal den Zugriff auf Rechnungen, ein Admin-Panel, Zahlungsmittel oder interne Werkzeuge. Wenn der Agent weiß, wie er für mich klicken kann, kann er mir zehn Minuten sparen. Er kann auch einen Denkfehler in einen Kauf, eine gesendete Nachricht oder eine Produktionseinstellung verwandeln. Bequemlichkeit und Risiko kommen vom selben Privileg.

Also habe ich es auf einer kleinen, separaten virtuellen Maschine installiert. Der nächste Schritt wird wahrscheinlich einen alten Laptop unter Ubuntu sein, mit eigenem Benutzer und eigenem Browser. Kein Rennpferd nötig: die Inferenz erfolgt beim Anbieter. Wichtig ist hier die Isolation. Wenn der Agent beschließt, alles kaputtzumachen, möchte ich lieber, dass er seinen eigenen Sandkasten zerstört als meinen Arbeitsplatz.

Das dafür vorgesehene Handy hat auch einen sehr banalen Vorteil: Ich kann mich aus der Ferne verbinden, selbst eine Seite öffnen und dem Agenten sagen „schau hier“, statt ihm permanenten Zugang zu meinem Alltag-Browser zu geben. Sein Nutzerkonto, sein Verlauf und seine Sitzungen gehören ihm. Im schlimmsten Fall kann er nur seine eigene Werkstatt beschädigen. Es ist genau die Art von etwas nerviger Grenze, die bei Präsentationen gerne weggekürzt wird.

Diese Wahl vermeidet auch ein häufiges Missverständnis. Ein High-End-Mini-Computer ist nicht nötig, um die Schnittstelle laufen zu lassen. Im Leerlauf verbraucht OpenClaw wenig; der schwere Teil, die Inferenz, läuft woanders, wenn ich ein entferntes Modell nutze. Ein alter Laptop, eine VM oder ein kleiner Server reichen oft aus. Ich investiere lieber in eine saubere Trennung von Konten und Geheimnissen, als in einen beeindruckenden Rechner auf dem Schreibtisch.

Es sei denn, man will das Modell lokal betreiben, lohnt es sich kaum, nur für OpenClaw einen leistungsstarken Rechner zu kaufen – das ist eher ein Vergnügen als eine Notwendigkeit. Das Gateway ist nicht der Motor: Es hält das Lenkrad und ruft den entfernten Motor auf. Meine wichtigste Investition bleibt eine Umgebung, die ich neu installieren kann, Backups und Rechte, die ich widerrufen kann.

• dedizierte Maschine oder VM, ohne automatische Einbindung meiner persönlichen Ordner;
• Systemkonto und Browsingprofil des Agenten;
• einzelner Zugang gewährt, für eine erkennbare Nutzung und Dauer;
• Getrennte, widerrufbare und auf das Absolut Notwendige beschränkte Geheimnisse;
• Versionierte Konfiguration, um genau zu sehen, was der Agent ändert;
• Keine sensible Bereitstellung, kein Kauf und kein Versand ohne menschliche Freigabe.

Die aktuelle Dokumentation bietet Richtlinien für Werkzeuge, Berechtigungslisten, ein Sicherheits-Audit und mehrere Sandbox-Modi. Man sollte sie bewusst nutzen: Die Ausführungs-Sandbox ist keine perfekte Grenze und wird nicht automatisch für alle Werkzeuge einer normalen Installation aktiviert.

Die dümmste Panne ist immer noch eine echte Panne

Ich habe bei mehreren Leuten ein sehr simples Problem wiederkommen sehen: Der Agent ändert seine JSON-Datei, vergisst ein Komma oder eine Klammer, und dann startet nichts mehr. Mit einem tollen Modell passiert das seltener. Bei einem günstigeren Modell, das man wählt, um Tokens zu sparen, werden Schemafehler schnell sichtbar.

Für einen Entwickler dauert die Reparatur manchmal nur zwei Minuten. Ich überprüfe das JSON, schaue mir den letzten Diff an und korrigiere den Fehler. Für jemanden, der den Agenten genau deshalb installiert hat, weil er die Konfiguration nicht anfassen will, endet die Erfahrung bei einem stillen Service. Dasselbe System, das sich selbst reparieren sollte, kann jetzt nicht mehr starten, um die Nachricht „Reparier dich“ zu lesen.

Ich bewahre also das Konfigurationsverzeichnis unter Git auf. Vor einer größeren Änderung möchte ich wissen, was sich ändern wird. Danach schaue ich mir das Diff an. Bei Start-Einstellungen, Berechtigungen und Mail-Verknüpfungen bearbeite ich lieber selbst das JSON. Es ist nicht sehr futuristisch, aber es ist eine großartige Art, einen ruhigen Dienstagabend wiederzufinden.

Die versteckten Kosten: Jedes ‚Hallo‘ trägt einen Koffer

OpenClaw selbst ist leicht. Die Rechnung hingegen kann schnell an Gewicht zunehmen. Jede Entscheidung erfordert eine Schlussfolgerung, und mein einfaches „Hallo“ reist niemals allein: Das Modell bekommt auch den System-Prompt, die Regeln des Agenten, seine Werkzeuge, seine Fähigkeiten, einen Teil des Speichers und den als nützlich erachteten Verlauf.

Während meines Tests, mit der aktuellen Konfiguration und den Tarifen, begann eine frische Sitzung bei etwa 10.000 Eingabe-Token. Die Sitzung zurückzusetzen und die Willkommensnachricht zu erhalten, kostete ungefähr zwei Cent. Eine einfache Erinnerung zu erstellen, lag bei etwa 45.000 Token und neun Cent. Das Hinzufügen von zwei Seiten zu einem Projekt verbrauchte etwa 263.000 Eingabe-Token, 6.000 Ausgabe-Token, davon 168.000 aus dem Cache: also rund ein paar Dutzend Cent für eine ziemlich kleine Änderung.

Warum schon 10.000 Tokens, bevor man überhaupt angefangen hat? Weil ein „Hallo“ mit einem kleinen administrativen Gepäck daherkommt: Wer ist der Agent, wie soll er antworten, welche Werkzeuge hat er, welche Fähigkeiten sind installiert, welche Regeln gelten, welches Gedächtnis ist relevant und welcher Teil des Gesprächs soll behalten werden. In einem normalen Chat wiegt mein Wort nur ein paar Tokens. Bei einem Agenten weckt es eine ganze Umgebung.

Der Erinnerungsauftrag mit 45.000 Tokens wirkt noch absurder, bis man sich die Vorgehensweise anschaut. Das Modell versteht die Anfrage, wählt das Werkzeug aus, schaut möglicherweise nach, wie man es korrekt aufruft, erhält das Ergebnis, prüft, ob die Aufgabe existiert, und bereitet dann eine lesbare Antwort vor. OpenClaw macht nicht all das mit einem kleinen, deterministischen Motor: Es fragt das Modell an mehreren Stellen ab.

Ich formuliere es absichtlich ein wenig brutal: Ohne LLM ist OpenClaw eine Maschine ohne Gehirn und ohne Willen. An jeder Gabelung geht es zurück zu seinem Berater: „Was muss ich tun, damit der Benutzer zufrieden ist?“ Dann, nachdem die Aktion abgeschlossen ist: „Wie soll ich ihm sagen, dass ich gute Arbeit geleistet habe?“ Diese Flexibilität ist das Produkt. Es ist auch die Rechnungslinie.

Nehmen Sie diese Zahlen nicht als universellen Preis. Das Modell, der Cache, der Anbieter und die Preise ändern sich. Sie zeigen einfach, was unter der Haube passiert. Bei Zahlung nach Nutzung wird eine unglückliche Schleife zur Rechnung. Bei einem gedeckelten Abo stößt der Agent irgendwann an die Grenze und hört auf. Das ist nervig, aber zumindest fliegt die Sicherung raus.

Bei längeren Entwicklungsaufgaben habe ich beobachtet, wie der Zähler sich der Million Eingabetokens näherte, mit Zehntausenden von Ausgabetokens und einem Teil des Kontexts, der aus dem Cache bereitgestellt wurde. Es handelt sich dabei nicht unbedingt um eine Million „neuer“ Tokens im menschlichen Sinne: Regeln, Dateien und Tool-Feedback werden mehrfach verwendet. Aber die Abrechnung summiert tatsächlich alle Durchläufe.

Das Täuschendste ist die Geschwindigkeit. Eine Änderung kann fünf Minuten dauern und den Eindruck eines kleinen, fast kostenlosen Dienstes erwecken. In diesen fünf Minuten hat der Agent vielleicht das Repository gelesen, das Modell befragt, ein Tool gestartet, die Ausgabe noch einmal geprüft, seinen Code korrigiert, die Tests ausgeführt und das Ergebnis zusammengefasst. Meine Stoppuhr zeigt nicht die Menge an Kontext an, die dabei geflossen ist.

Deshalb misstraue ich auch dem Ausdruck „der Agent ersetzt einen Mitarbeiter“. Er kann eine bestimmte Funktion übernehmen, zum Beispiel eine Zusammenfassung erstellen, einen Merge Request öffnen oder ein Postfach prüfen. Wenn man ihn stundenlang ununterbrochen mit einem teuren Modell denken und handeln lässt, wird die Ersparnis deutlich weniger attraktiv. Der Agent ist nicht kostenlos, nur weil niemand die Tastatur berührt.

Und welchen Mitarbeiter ersetzt man eigentlich genau? Denjenigen, der nur einmal pro Stunde die Mailbox öffnet und einen Digest erstellt? Wenn die gesamte Tätigkeit einer Person durch eine so enge Schleife reproduziert werden kann, lag das eigentliche Problem vielleicht schon in der Arbeitsorganisation. In meinem Team erhöhen die Code-Assistenten die Produktivität, aber ich habe keinen einzigen Entwickler entlassen. Es kann sein, dass ich für eine Weile langsamer einstelle; das ist nicht dasselbe wie zu sagen, ‚die Agenten haben das Team ersetzt‘.

Bezahlung nach Nutzung oder Abo?

Mit einer tokenbasierten API behalte ich viel Freiheit, aber ich trage auch das volle Risiko einer Endlosschleife oder eines wuchernden Kontexts. Ein Abonnement begrenzt die Katastrophe besser: Sobald das Kontingent erreicht ist, hört die Arbeit bis zur nächsten Erneuerung auf. Zum Experimentieren gibt mir diese Obergrenze mehr Sicherheit als eine offene Kreditkarte hinter einer nächtlichen Automatisierung.

Abos machen die Inferenz nicht unendlich. Günstige Angebote haben Zeitlimits und Obergrenzen; die höherwertigen Pläne kosten schnell mehrere hundert Dollar im Monat. Für eine einzelne Person kann das noch akzeptabel sein. Für ein ganzes Team wird es ernst, wenn man Konten und Tarife vervielfacht. Man sollte die Kosten mit der tatsächlich gesparten Zeit vergleichen, nicht mit einem abstrakten Versprechen von Autonomie.

Zum Zeitpunkt meines Tests erlaubte eine persönliche Einstiegsvariante hauptsächlich, es einmal auszuprobieren. Bei intensiver Nutzung durch einen Agenten war das Stundenkontingent schnell aufgebraucht, und dann kam das wöchentliche Limit dahinterher. Deutlich teurere Angebote verschafften mehr Luft, ohne unlimitiert zu sein. Das ist ein Punkt, den Marketingtabellen schlecht rüberbringen: Eine aktive menschliche Konversation und ein Agent, der die Tools mehrfach anruft, verbrauchen nicht annähernd im gleichen Tempo.

Auf Unternehmensebene ist es nicht automatisch die optimale Lösung, für jeden Entwickler ein großes Personal-Abo zu kaufen, und professionelle Verträge verändern die Berechnung noch einmal. Letztendlich haben wir mehrere Modelle hinter unserem eigenen Gateway zentralisiert, um den Zugriff und die Kosten zu kontrollieren. Ich präsentiere das nicht als universelles Rezept: Es ist einfach die Folge einer kollektiven Nutzung, bei der die persönlichen Limits zu schwer vorherzusagen waren.

Meine Empfehlung zum Einstieg ist also eher prosaisch: benutzt zuerst einen gedeckelten Rahmen. Ein Limit, das den Agenten nach fünf Stunden unterbricht, ist frustrierend, aber es ist besser als eine nächtliche Schleife, die direkt mit einer unbegrenzten Abrechnung verbunden ist. Sobald der Verbrauch verstanden ist, kann man bewusst entscheiden, den Hahn weiter aufzudrehen.

Cron und Heartbeat: Automatisierung verbraucht auch, wenn nichts passiert

Meine Nachrichten sind nicht die einzigen, die Ressourcen verbrauchen. Eine geplante Aufgabe kann den Agenten jede Stunde aufwecken, ihn die Mailbox überprüfen lassen, das Modell fragen, was zu tun ist, feststellen, dass nichts passiert, und dann wieder einschlafen. Selbst dieses großartige „nichts zu berichten“ hat Kontext, eine Entscheidung und ein paar Tokens gekostet.

Ich reserviere die wiederkehrenden Automatisierungen also für die Kontrollen, die wirklich eine Modellinterpretation rechtfertigen. Eine deterministische Prüfung, eine API-Abfrage oder ein paar Zeilen Skript kosten weniger und sind oft zuverlässiger. Das LLM kommt nur dann zum Einsatz, wenn das Ergebnis Sprache erfordert, eine unklare Einstufung nötig ist oder eine kontextabhängige Entscheidung getroffen werden muss.

Um beim Beispiel E-Mail zu bleiben: Ein Skript kann zuerst den Server fragen, ob es neue E-Mails gibt. Wenn es keine gibt, hört es auf, ohne das Modell aufzurufen. Gibt es zehn, werden nur diese zehn Nachrichten zum Sortieren und Zusammenfassen weitergegeben. Den gesamten Agenten jede Stunde aufzuwecken, um ein leeres Postfach zu entdecken, ist technisch möglich, aber eine sehr teure Art herauszufinden, dass nichts passiert ist.

Ich habe Konfigurationen gesehen, die alles, immer, automatisieren wollten. Nach ein oder zwei Tagen war das Kontingent weg oder die Rechnung sah viel weniger lustig aus. Das Problem war keine außergewöhnliche Aufgabe: Es war die Ansammlung kleiner Aufwecker, jeder begleitet vom Systemprompt, den Tools, dem Speicher und einer Anfrage an das Modell. Die agentischen Kosten verstecken sich oft in der Wiederholung, nicht im großen roten Knopf.

Erste nützliche Anwendung: die Erinnerungen, die mich nicht loslassen

Meine häufigste Nutzung ist fast banal. Ich sage zu ihm: „Erinnere mich daran, diesen Kunden in einer Stunde anzurufen, und erinnere mich dann alle zehn Minuten, bis ich bestätige.“ Ein klassischer Kalender kann eine Benachrichtigung anzeigen. OpenClaw hingegen behält die Absicht im Kopf und macht weiter, bis ich bestätige. Manchmal ist das nervig. Genau deshalb funktioniert es.

Es ist nicht revolutionär, aber es ist eine kleine Reibung, die beseitigt wurde. Die Regel bleibt die gleiche: Das Erinnerungs-Tool darf nicht auf meine komplette Mailbox, meine Festplatte und mein Produktions-Repository zugreifen, nur weil es weiß, wie man eine Aufgabe neu startet.

Der Karneval der möglichen Verwendungen

Sobald der Agent mit dem Browser, dem E-Mail-Client, dem Terminal und den APIs verbunden ist, kommen die Ideen wie von selbst. Er kann E-Mails lesen, einen Bericht verschicken, Metriken abrufen, ein Formular ausfüllen, ein Restaurant suchen, Tickets vergleichen oder andere Agenten überwachen. Manche Demonstrationen erinnern fast an ein Strategiespiel: Mehrere digitale Charaktere teilen sich den Code, die Bereitstellung und die Überwachung.

Ich finde es faszinierend anzusehen. Ich bin mir nicht sicher, ob ich wirklich so arbeiten möchte. Eine spektakuläre Oberfläche ist nicht unbedingt ein guter Prozess. Was ich suche, ist eher schlicht: das, was ich schon kann, zu erweitern, in Momenten, in denen meine Tastatur nicht verfügbar ist, und dabei einen klaren Kontrollpunkt zu behalten.

In einer privaten Community habe ich sogar eine Installation gesehen, die in ein Strategiespiel verwandelt wurde: Mehrere Agenten bewegten sich wie Einheiten, einer baute die Seite, ein anderer bereitete die Bereitstellung vor, ein dritter überwachte das Ergebnis. Ich hätte mir die Demonstration lange ansehen können. Aber ich hätte mir nicht vorgestellt, auch nur eine Sekunde so zu arbeiten. Es war eine sehr gute Show-Oberfläche, aber nicht unbedingt ein guter Arbeitstag.

Mein Kriterium ist ärmer an Spezialeffekten: Verlängert der Agent wirklich meine Reichweite? Führt er unter meiner Kontrolle eine Handlung aus, die ich schon kann, die ich aber gerade nicht bequem ausführen kann? Auf diesem Gebiet hat OpenClaw angefangen, sich bei mir einen Platz zu sichern.

Mein echter Anwendungsfall: ein Code-Bot in Telegram

Die Idee kam mir nach einem ganz normalen Zwischenfall — so einem, der immer passiert, wenn man nicht am Computer sitzt. Ein Anzeigefehler hatte die Preise für einen Service vervielfacht. Zwei Minuten am Keyboard hätten gereicht. Vom Handy aus wollte ich die große Komponente im Monorepo ändern, habe aber das Deployment zerschossen und musste zurückgehen, um den Service wieder zum Laufen zu bringen.

Ich war im Urlaub auf den Pisten, als mir ein Entwickler den Screenshot geschickt hat. Der Zugriff auf dieses Projekt war damals nur für mich eingerichtet. Ich habe die Git-Oberfläche übers Handy geöffnet, versucht, die fehlerhaften Werte zu teilen und vor allem geschafft, das gesamte im selben Monorepo abgelegte Lieferantenpaket zum Absturz zu bringen. Ich habe das Rollback angestoßen, das Team konnte seine Arbeit wieder aufnehmen, und ich blieb mit diesem ärgerlichen Gedanken zurück: Am Rechner hätten Korrektur und Deployment zwei oder drei Minuten gedauert.

Also habe ich mein ‚Rettungsboot‘ gebaut: ein Entwicklungsagent, der über ein spezielles Telegram-Thema erreichbar ist. Er darf nicht deployen und greift nie direkt auf den Hauptbranch zu. Sein Arbeitsbereich enthält einen Klon des Projekts. Er erstellt einen Branch, ändert den Code, startet die Checks, pusht den Branch und öffnet einen Merge Request. Danach übernehme ich wieder: Ich lese das Diff, teste und entscheide über das Merge.

Das Wort „Boot“ ist bewusst gewählt. Es ist nicht meine Hauptentwicklungsumgebung. Vor meinem Computer sind die IDE und mein gewohntes Code-Assistenztool immer noch schneller, komfortabler und vor allem transparenter. Ich möchte diesen Agenten für die Momente, in denen ich unterwegs bin, wenn eine einfache Korrektur vom Handy aus mühsam wird und mehrere Stunden zu warten nicht vernünftig ist.

In meiner Konfiguration sind der allgemeine Assistent und der Code-Agent getrennt. Der erste nutzt das allgemeine Standardmodell. Der zweite ist nur auf das Projektthema bezogen und verwendet ein auf Code ausgerichtetes Modell. Die Telegram-Bindings bestimmen, welches Konto, welche Gruppe und welches Thema welchen Agenten aktivieren. Unbekannte private Nachrichten werden abgelehnt, der Agent muss in normalen Gruppen erwähnt werden und antwortet automatisch nur in seinem Arbeitsthema.

Am Anfang habe ich ihm in der neuen Gruppe geschrieben: „Bist du da? Ping“. Komplettes Schweigen. Privat versicherte mir der Agent jedoch, dass alles funktionieren müsste und bot immer phantasievollere Erklärungen an. Die Realität war weniger clever: In dieser Gruppe musste man ihn erwähnen, und der Bot musste die nötigen Rechte haben, um die Nachrichten zu lesen. Sobald ich ihn getaggt habe, kam eine Reaktion und die Konversation begann.

Diese Trennung wirkt administrativ, aber sie verhindert, dass sich der ganze Kontext vermischt. Ein Austausch über eine Erinnerung braucht nicht die Regeln des Monorepos. Eine Code-Aufgabe braucht nicht das Gedächtnis meines allgemeinen Assistenten. Die Weiterleitung nach Konto, Gruppe und Thema erlaubt es mir, das Modell und den Workspace zu wählen, noch bevor die Nachricht verarbeitet wird.

Das Konfigurationsprinzip, befreit von meinen Zugangsdaten, sieht so aus:

{
  "agents": {
    "default": { "workspace": "/srv/openclaw/general", "model": "general" },
    "provider-code": { "workspace": "/srv/openclaw/provider", "model": "coding" }
  },
  "bindings": [
    {
      "channel": "telegram",
      "chatId": "<groupe-code>",
      "topicId": "<sujet-projet>",
      "agent": "provider-code"
    }
  ]
}

Das ist keine fertige Datei zum Kopieren: Die genauen Namen hängen von Version und Installation ab. Sie zeigt die Logik, die zählt. Das Telegram-Konto kommt in eine Gruppe, die Gruppe enthält ein Thema, und dieses Thema verweist auf einen bestimmten Agenten, ein bestimmtes Modell und einen bestimmten Arbeitsbereich. Das Routing wird entschieden, bevor das Modell anfängt zu improvisieren.

Ich hoste auch mehrere Agenten auf demselben Server. Jeder hat seine eigene Identität, seinen Workspace und seine Verbindungen. Eine VM pro Assistent zu erstellen wäre unnötig teuer, aber den Prozess zu teilen bedeutet nicht, alle Berechtigungen zu teilen. Das Wichtigste ist, sagen zu können: Dieses Telegram-Thema spricht mit diesem Agenten, mit diesem Modell, in diesem Repository und nirgendwo sonst.

In meiner echten Datei bleibt der Haupt-Bot für allgemeine Gespräche der Standard. Das Projektthema hat eine spezifischere Verbindung zum Code-Agenten. Ich habe die Themen-ID bekommen, indem ich das System gefragt habe, wo die aktuelle Nachricht ist, und sie dann manuell in das JSON übertragen. Für die Demo hatte ich eine bereinigte Kopie der Datei vorbereitet: ein Sicherheitsbeispiel mit den echten Tokens auf dem Bildschirm zu zeigen, wäre ein ziemlich schlechter Scherz gewesen.

Das Repository enthält auch eine Regeldatei: Monorepo-Architektur, Testbefehle, Konventionen, Pflicht zur Erstellung eines Branches und einer MR, Verbot des Deployments. Bei einer komplexen Aufgabe bitte ich ihn zuerst um einen Textplan. Das GitLab-Token ist dediziert und widerrufbar; der SSH-Schlüssel gehört zu dieser Umgebung, nicht zu meinem Hauptkonto.

Ich habe für ihn ein separates GitLab-Konto erstellt, eine eigene Adresse, einen eigenen SSH-Schlüssel und ein beschränktes Zugriffstoken. Der Agent hat seinen Schlüssel generiert und das Token in seiner Umgebung eingerichtet, aber ich habe die Rechte festgelegt. Seine Regeldatei sagt ihm, dass er einen Branch erstellen, pushen und einen Merge Request öffnen soll. Bei komplexen Anfragen muss er zuerst einen Plan abgeben, bevor er den Code schreibt, damit ich prüfen kann, ob er das richtige Problem verstanden hat.

Ich habe mit einem absichtlich lächerlichen Test angefangen: eine Versionsnummer durch eine andere ersetzen. Der Agent hat die Datei geändert, den Branch erstellt und die MR eröffnet. Ich habe den Diff gelesen, zusammengeführt und dann die automatische Bereitstellung überprüft. Erst nach dieser Generalprobe habe ich ihm die beiden neuen Seiten anvertraut. Ein Agent verdient nicht die Rechte an einem großen Projekt, nur weil er einen schönen Satz in Telegram geschafft hat.

Dieser erste Test bewies fast nichts über seine Fähigkeit zu programmieren. Er bewies etwas Wichtigeres für mich: Die ganze Kette funktionierte. Die Nachricht erreichte den richtigen Agenten, das Repository war das richtige, der Branch erschien, der Merge Request war sichtbar und die Pipeline startete erst nach meinem Merge. Bevor ich nach Intelligenz fragte, wollte ich die Grundlagen überprüfen.

Was funktioniert hat

Ich habe ihn gebeten, eine Angebotsseite und eine vorläufige Datenschutzseite nach dem Modell einer bestehenden Konditionsseite zu erstellen. Zwei Minuten später enthielt die MR beide Routen, die vorläufigen Texte und sogar den thematischen Selektor, der zum Rest der Website passt. Danach habe ich einen Kommentar hinterlassen, in dem ich bat, einen 'Entwurf'-Block zu entfernen: Der Agent hat den Kommentar gelesen, den Branch geändert und die MR aktualisiert.

In Telegram wurde der Indikator „schreibt…“ angezeigt, während er arbeitete. Unter der Haube las er den Kommentar, fand den Branch, änderte die Datei und pushte die neue Version. Als die Antwort kam, habe ich das Diff überprüft, anstatt sein „fertig“ als Beweis zu nehmen. Der Merge-Button blieb unter meinem Finger, nicht unter seinem.

Dieser letzte Hin- und Rückweg zählt mehr als die ursprüngliche Generation. Eine erste Codeversion ist leicht in einer Demo zu zeigen. Einen Review-Kommentar lesen, den richtigen Branch finden, eine begrenzte Änderung anwenden und dann die MR aktualisieren, ähnelt schon einem echten Stück Workflow. Ich konnte das Ergebnis in GitLab verfolgen, statt der Nachricht »fertig« zu glauben.

Das ist genau das Maß an Autonomie, das ich suche. Wenn ich vor meiner IDE sitze, bleibt mein gewohntes Codetool schneller und übersichtlicher. OpenClaw wird interessant, wenn ich draußen bin, die Korrektur per Sprachnachricht erklären kann und die Änderung in Form eines überprüfbaren Diffs auf mich wartet.

Ich betone diesen Punkt, weil er das Versprechen komplett verändert. Ich werde mich nicht vor meine sieben Bildschirme setzen, um Code in Telegram zu diktieren. An meinem Schreibtisch öffne ich die IDE, sehe die Dateien und kontrolliere die Schleife viel schneller. Dieser Agent ist ein Rettungsboot für den Moment, in dem ich im Auto, im Zug oder weit weg von meinem Arbeitsplatz bin — nicht der theatralische Ersatz für meine tägliche Umgebung.

Was nicht beim ersten Mal funktioniert hat

Die „automatische“ Konfiguration hat schnell ihren magischen Touch verloren. In einer neuen Gruppe blieb der Agent vollkommen still, während er mir versicherte, dass alles funktionieren müsste. Die Ursache war wirklich banal: man musste ihn erwähnen und ihm das Recht geben, die Nachrichten zu lesen. Am Ende habe ich das JSON selbst korrigiert. Ein Modell ohne Kontrolle seine eigene Startdatei neu schreiben zu lassen, schien mir eine ziemlich schlechte Art, den Abend zu beenden.

Der tatsächliche Startprozess erforderte mehrere Schritte: die Gruppe und ihre Themen erstellen, die Zugangsdaten abrufen, die Bindings deklarieren, das Projektthema mit dem Code-Agenten verknüpfen, die Hinweise einstellen, den Workspace vorbereiten, den SSH-Schlüssel installieren und ein eingeschränktes GitLab-Token bereitstellen. OpenClaw hat mir bei einem Teil dieser Arbeit geholfen, aber er hat es nicht in einen einzigen Knopf verwandelt.

In normalen Gruppen setze ich ihm eine explizite Erwähnung auf. Ohne sie hört er zwar zu, antwortet aber nicht. Im Kanal, der für den Code reserviert ist, ist die Erwähnung nicht nötig: Jede Nachricht ist für ihn bestimmt. Private Nachrichten von unbekannten Identitäten werden abgelehnt. Es sind kleine Einstellungen, aber sie machen den Unterschied zwischen einem nützlichen Assistenten und einem Bot, der überall dazwischenfunkt.

Dieses Detail fasst OpenClaw gut zusammen: Es kann eine überzeugende Codeänderung vornehmen und dann über seine eigene Konfiguration halluzinieren. Intelligenz ist nicht gleichmäßig verteilt. Ich überprüfe also die Berechtigungen, die geänderten Dateien und das tatsächliche Ergebnis, nicht nur die beruhigende Antwort des Bots.

Sprachnachrichten: die Erweiterung, die die mobile Nutzung verändert

Ich wollte lieber mit dem Agenten sprechen, als ein Pflichtenheft auf meinem Handy zu tippen. OpenClaw kann die verfügbaren Ressourcen prüfen und Whisper lokal vorschlagen. Meine kleine VM war für diese Transkription nicht geeignet, also habe ich ihm die Dokumentation unseres bestehenden Transkriptionsdienstes gegeben.

In unserer Infrastruktur ist dieser Service kein einfacher Direktaufruf eines Modells. Wir haben ein internes Gateway für mehrere KI-Funktionen: Transkription, LLM und Bilderzeugung. Bei der Stimme wird zuerst eine interne Ressource ausprobiert, dann auf eine andere Engine umgeschaltet, falls diese scheitert, und erst danach auf einen kostenpflichtigen Service. Einige Prozesse laufen asynchron ab: man erstellt eine Aufgabe, wartet, und holt dann das Ergebnis ab. Wir mussten die ganze Technik dahinter erklären, ohne dass OpenClaw die Hälfte erfindet.

Der Agent hat ein paar Fragen gestellt, einen Hook hinzugefügt und seine Konfiguration geändert. Jetzt geht eine Telegram-Sprachnachricht zuerst durch den Transkriptor; der Text kommt dann wieder in den normalen Ablauf und wird wie jede andere Anweisung behandelt. Die Änderungen bleiben versioniert, was es mir erlaubt, die hinzugefügten Hooks genau zu kontrollieren.

Unser Transkriptor arbeitet asynchron: Er empfängt das Medium, erstellt eine Aufgabe, wartet auf das Ergebnis und gibt dann den Text zurück. Statt dem Agenten das Protokoll mündlich zu erklären, habe ich meinen Code-Assistenten gebeten, daraus eine detaillierte Integrationsdokumentation basierend auf einem bestehenden Projekt zu erstellen. Ich habe dieses Dokument OpenClaw gegeben, seine Fragen beantwortet und es dann vorbereiten lassen.

Ich hatte schon einen kleinen internen Bot, der dieses Gateway nutzte: man schickte ihm eine Sprachnachricht, er transkribierte sie und ordnete die Ideen ein wenig neu. Ich habe den Code dieses Bots meinem Entwicklungsassistenten gegeben mit einer ganz genauen Anweisung: Erstelle ein Integrationsdokument, beschreibe die Authentifizierung, das Token-Format, das Anlegen von Aufgaben, das Warten auf Ergebnisse und die Fehlerfälle. Diese Markdown-Datei wurde zum Vertrag zwischen unserem Service und OpenClaw.

Die finale Pipeline ist einfach zu lesen: Eine Nachricht kommt von Telegram; wenn sie eine Sprachnachricht enthält, schickt der Hook sie an den Transkriptionsdienst; der erhaltene Text ersetzt das Medium in der normalen Schleife. Von da an behandelt der Agent meine Stimme wie jede andere schriftliche Anweisung. Genau das ist die Art von Erweiterung, die das Projekt rechtfertigt: Sie ändert tatsächlich meine Nutzung, wenn ich weit vom Büro entfernt bin.

Ich konnte beobachten, wie die Anfragen bei uns ankamen, die Transkriptionsaufgabe abgeschlossen wurde und der Text dann wieder in OpenClaw zurückkehrte. Das Ergebnis war also nicht nur „der Bot sagt, er versteht die Sprachaufnahmen“. Ich konnte den tatsächlichen Weg sehen. Und da die OpenClaw-Konfiguration versioniert ist, konnte ich den hinzugefügten Hook und die Regel, die ihn in die Pipeline vor der normalen Nachrichtenverarbeitung einfügt, nachlesen.

Nicht alles ist perfekt geblieben. Am Tag vor der Aufnahme habe ich noch mit den Hooks experimentiert und vorübergehend die Verarbeitung von Sprachnachrichten unterbrochen. Es ist fast eine ideale Demonstration des Produkts: sehr leistungsstark, wirklich praktisch und genug anpassbar, dass ich es selbst unbrauchbar machen konnte, bevor ich schlafen ging.

Das war das beste Beispiel für seine Fähigkeit, sich zu erweitern: Ich habe die Integration nicht von Hand geschrieben, aber ich habe auch keine uneingeschränkte Erlaubnis gegeben. Ich habe eine dokumentierte Schnittstelle, ein eingeschränktes Token und ein Repository unter Versionskontrolle bereitgestellt.

Zweiter nützlicher Einsatz: Meine Beiträge vorbereiten, ohne meine Stimme zu verlieren

Ich schreibe schon lange für meinen Kanal. Ich habe meine alten Beiträge als JSON exportiert und dann ein Modell gebeten, daraus einen detaillierten Stilguide zu erstellen: Rhythmus, Ausdrücke, Struktur, Übergänge und Fehler, die man vermeiden sollte. Ich habe diesen Guide in das Prompt eines Agenten eingefügt, der fürs Schreiben zuständig ist.

Früher habe ich praktisch jeden Tag etwas veröffentlicht. Dann hat der Aufwand für die erste Version – die Seite öffnen, die Ideen ordnen, den Winkel finden – schließlich das Tempo gebremst. Genau dieses ganz normale Problem wollte ich lösen. Keine Maschine erschaffen, die meine Meinungen für mich hat, sondern den Weg zwischen einer Idee, die beim Gehen entsteht, und einem Entwurf, den ich verbessern möchte, verkürzen.

Export ist sehr wichtig. Ich habe ihn nicht gebeten, drei ausgewählte Beiträge zu imitieren, nur weil sie mir gefallen haben. Ich habe ihm jahrelange Texte gegeben, mit meinen Gewohnheiten, Wiederholungen und Fehlern. Das Modell hat dieses Material in nutzbare Anweisungen verwandelt. Erst danach habe ich ein separates Thema für das Schreiben erstellt, wie ich es auch schon beim Code gemacht hatte.

Ich sage ihm nicht nur „schreib über OpenClaw“. Ich schicke ihm einen Entwurf, wichtige Punkte oder eine lange Sprachnachricht. Er erstellt eine Struktur und eine erste Version, die meinem Ton ähneln. Danach überarbeite ich den Text, ersetze einige Passagen und entscheide allein, wann ich veröffentliche.

Für die Demonstration hätte ich ihn vielleicht einfach mit einem vagen „Schreib einen Beitrag über die Gefahren von OpenClaw“ bitten können. Im echten Leben arbeite ich so aber nicht. Ich gebe ihm Bruchstücke, Einwände, eine Anekdote und manchmal noch eine etwas verworrene Schlussfolgerung. Er macht vor allem die Montagearbeit. Wenn ich weder Fakten noch Position noch Unebenheiten liefere, gibt er mir genau das zurück, was ich verdiene: einen glatten Text, den jeder hätte unterschreiben können.

Ich behaupte nicht, dass er für mich schreibt. Er lässt die leere Seite verschwinden und liefert mir ein Skelett, das gut genug ist, um loszulegen. Danach schneide ich, schreibe um und bringe meine eigenen Unebenheiten ein. Den Inhalt, das Urteil und die Verantwortung behalte ich; die Maschine erspart mir vor allem die erste mühsame Stunde.

Der Gewinn war sofort sichtbar: Ich fing wieder an, regelmäßig Entwürfe zu produzieren. Es liegt nicht daran, dass der Agent zum Autor geworden ist. Sondern daran, dass die für mich teuerste Phase – aus einem Haufen Notizen eine Struktur zu machen – kürzer geworden ist. Danach kann ich meine Energie auf das richten, was der Agent nicht hat: meine Erfahrung, mein Maß an Zweifel und die Entscheidung, jeden Satz öffentlich zu vertreten.

Der Flow, der am besten funktioniert, ist übrigens nicht „Gib mir ein Thema“. Ich schicke ihm meine Ideen durcheinander, manchmal als Stichpunkte, manchmal als lange Sprachnachricht, während ich unterwegs bin. Er ordnet die Elemente lesbar und schlägt einen Text vor. Je mehr mein Entwurf eine persönliche Meinung und eigene Beispiele enthält, desto weniger ähnelt das Ergebnis einer generischen Suppe.

„Er lernt ganz alleine“ verdient ein Sternchen

OpenClaw kann Komponenten installieren, seine Dateien ändern und seine Fähigkeiten erweitern. Zu sagen, dass er „selbst lernt“, ist jedoch eine Vereinfachung. Er wird nicht spontan weiser. Er setzt eine Anfrage mit den Werkzeugen und dem Modell um, auf die ich ihm Zugriff gegeben habe. Eine falsche Anweisung oder ein falsches Modell erzeugt einfach einen neuen Fehler in einem inzwischen komplexeren System.

Die neueren Versionen haben das Standardverhalten genau eingeschränkt. Um das permissivste Profil zu bekommen, muss man es absichtlich in der Konfiguration aktivieren. Ich finde diese Bremse gesund. Eine neue Installation sollte damit anfangen, zu diskutieren und zu beobachten, nicht sofort über Terminal, Browser, Geheimnisse und alle Dateien zu verfügen.

Anders gesagt vermischt die Abkürzung „er macht sich selbst klüger“ mehrere Dinge. Er kann eine Dokumentation lesen, ein Paket installieren, eine Fähigkeit erstellen, einen Hook hinzufügen oder einen Prompt ändern. Es ist eine sehr mächtige Erweiterungsfähigkeit. Aber sein Urteil hängt weiterhin vom Modell, Kontext und den Berechtigungen ab. Einen neuen Schlüssel in einen Werkzeugkasten zu legen, garantiert nicht, dass der Benutzer das richtige Schloss findet.

Meine Regel ist schrittweise: zuerst ein Kanal, dann ein leeres Workspace, dann ein Test-Repository, danach ein eingeschränkter Schlüssel und erst zum Schluss ein nützlicher Workflow. Bei jedem Schritt schaue ich mir die Logs und die geänderten Dateien an. Autonomie ist kein Schalter, den ich einschalte; es ist ein Bereich, den ich erweitere, nachdem ich das tatsächliche Verhalten gesehen habe.

Das ist vielleicht mein berufliches Vorurteil: Ich mag es nicht, dass eine Software, ein Dienstleister oder sogar eine Person die vollständige Kontrolle über meine Geräte hat. Ich behaupte nicht, diese Sichtweise anderen aufzuzwingen. Ich sage nur, mit der nötigen Bescheidenheit, dass sie absolut korrekt ist und die anderen falsch sind. Ernsthaft: Wenn Sie eine andere Risikopolitik wählen, wählen Sie sie zumindest mit voller Kenntnis der Sache.

Der Drang, alles zu automatisieren, ist eine Falle

OpenClaw verursacht ein sehr erkennbares Syndrom: Sobald es funktioniert, will man es überall anschließen. Das erinnert mich an den Tag, an dem ich meinen Führerschein bekommen habe: Ich hatte Lust, das Auto selbst für den Supermarkt auf der anderen Straßenseite zu nehmen. Es war teurer, manchmal langsamer und objektiv absurd, aber ich wollte fahren.

Zu Fuß war die Strecke kostenlos, wahrscheinlich sogar schneller, wenn man das Parken mit einrechnet, und obendrein besser für meine Gesundheit. Mit dem Auto hingegen habe ich Benzin ausgegeben, nach einem Parkplatz gesucht und mir immer neue Gelegenheiten geschaffen, irgendwo anzustoßen. Trotzdem nahm ich das Auto, einfach weil ich endlich das Recht und die Lust hatte, es zu benutzen. Der OpenClaw-Entusiasmus erzeugt genau dieses technische Kribbeln.

Für viele Aufgaben ist OpenClaw genau dieses Auto. Man könnte laufen — oder hier ein paar Zeilen Skript schreiben, einen Webhook setzen, eine geplante Funktion starten. Es wäre weniger spaßig, aber einfacher, vorhersehbarer und billiger. Ich behalte den Agenten für Anfragen, die sich ändern, sich besser in natürlicher Sprache beschreiben lassen und mehrere Tools zusammenarbeiten lassen müssen.

Was ich nach zwei Wochen mitnehme

Nach zwei Wochen hat OpenClaw weder mein Team noch meine Arbeit ersetzt. Dafür verwandelt es ein Voice in ein MR, besteht darauf, wenn ich eine Erinnerung ignoriere, erstellt den ersten Entwurf eines Textes und verbindet ein dokumentiertes Tool mit einem Chat-Kanal. Das ist keine tägliche Revolution. Es ist schon nützlich genug, dass ich weiter mit ihm reden werde.

Ich werde es weiter benutzen und ihm neue Fähigkeiten hinzufügen. Aber jede neue Fähigkeit muss drei Fragen beantworten: Ist sie wirklich effektiver als ein Skript? Wie viel könnte sie im schlimmsten Fall kosten? Was ist der maximale Schaden, wenn das Modell falsch liegt?

Ich werde wahrscheinlich weiterhin Hooks auseinandernehmen, Modelle vergleichen und neue Einsatzmöglichkeiten finden. Der Unterschied ist, dass ich nicht mehr nach einer Demonstration suche, in der OpenClaw allmächtig erscheint. Ich suche nach ein bisschen langweiligen Automatisierungen, die einer echten Arbeitswoche standhalten. Meine beiden aktuellen Erfolge — das Rettungsboot für Code und der Schreibassistent — gehören genau in diese Kategorie.

Ich suche also nicht mehr nach „einem Agenten, der alles kann“. Ich bevorzuge mehrere kleine Agenten, jeder mit seinem Modell, seinem Thema, seinem Repository und seinen Berechtigungen, mit menschlicher Kontrolle an Stellen, wo ein Fehler wehtut. Es ist weniger magisch, deutlich weniger verkaufsfördernd — und meiner Meinung nach viel seriöser.

Technische Referenzen

• OpenClaw: Definition und allgemeine Architektur
• OpenClaw: Installation und erste Schritte
• OpenClaw: Sicherheits- und Prüfungsmodell
• OpenClaw: Ausführung von Tools in einer Sandbox
• OpenClaw: Automatisierungen, Cron und Heartbeat
• OpenClaw: offizielles Repository

Als Nächstes lesen

• So habe ich Pi als Coding-Agent eingerichtet: LSP, MCP, Skills und Erweiterungen KI und Entwicklung · 34 Min.
• Synology AI mit einem lokalen LLM über Ollama oder LM Studio verbinden Synology, KI und Selbsthosting · 12 Min.

Über den Autor

Jeremy Kraft betreut die Infrastruktur und die selbst gehosteten Dienste des IBCSC. Diese Anleitungen beschreiben Konfigurationen, die tatsächlich im Einsatz waren und vor der Veröffentlichung erneut geprüft wurden.

Eine Frage stellen Alle Anleitungen

Diskussion

Kommentare

0

Noch kein Kommentar. Eröffnen Sie die Diskussion gern mit einer Frage oder Ihrem eigenen Erfahrungsbericht.

Website

Ihr Name Sie haben ein Konto? Anmelden

Ihr Kommentar

Reiner Text, höchstens 2 000 Zeichen. Neue Kommentare werden moderiert. Ihr Name wird mit dem Kommentar angezeigt. Es wird keine E-Mail-Adresse abgefragt; gegen Spam wird nur ein nicht umkehrbarer Fingerabdruck Ihrer IP-Adresse gespeichert.

Kommentar senden