Was sind die echten Innovationen von OpenClaw und Moltbook jenseits der "Hype"?

Im Frühjahr 2026 war die "Siedlerkrebs-Feier" voller Lärm. Insbesondere nach den verschiedenen Diskussionen über die "Fehlschläge" von Moltbook wurde von vielen die "Aufbausche" dahinter erkannt.

Für diejenigen, die sich wirklich für die Entwicklung der Künstlichen Intelligenz interessieren, liegt der Schwerpunkt nicht mehr in den grandiosen Vorstellungen von Singularität, Autonomie oder Maschinen-Gesellschaften. Stattdessen geht es um eine konkretere und realistischere Frage: Welche Entwürfe von OpenClaw sollten beibehalten werden? Wie sollte das A2A-Grundgerüst, das MoltBook zeigt, verbessert werden?

Betrachtet man die Ergebnisse, sind sowohl OpenClaw als auch MoltBook unvollkommen. Das erste hat die Risiken von lokalen Agenten in Bezug auf Sicherheit und Grenzen aufgedeckt, während das zweite schnell in die Spekulationen der Kryptowährungsbranche abrutschte. Dennoch haben sie möglicherweise schon den echten Weg der KI-Entwicklung in den nächsten ein bis zwei Jahren vorgezeichnet.

1

OpenClaws Headless-Architektur und der lokale Fokus

OpenClaw hat sich unter einer Reihe scheinbar vollständigerer und kommerziellerer Konkurrenten hervorgetan, nicht weil es in Bezug auf die Modellfähigkeiten führend war, sondern weil es in der Systemarchitektur einige deutliche Abweichungen von der Mainstream-Lösung vornahm. Diese Entscheidungen waren möglicherweise nicht reif, aber sie boten ein zu testendes Paradigma für die spätere Diskussion über Agent OS.

Headless-Architektur: Der Agent als Hintergrunddienst laufen

Vor OpenClaw entwickelten sich die Agent-Produkte fast alle auf einem ähnlichen Weg: Die Erstellung einer neuen "Super-App".

Das Chat-Interface musste neu gestaltet werden, die Arbeitsabläufe sollten visualisiert werden, und die Interaktionslogik sollte möglichst vollständig sein, um die Benutzer in ein neues Fenster-System zu locken.

OpenClaw entschied sich dagegen, diesen Weg zu umgehen. Seine Einschätzung war: Der Agent braucht keine eigene Benutzeroberfläche und sollte auch nicht die Aufmerksamkeit der Benutzer beanspruchen. Stattdessen sollte er in der Interaktionsumgebung laufen, an die sich die Benutzer schon gewöhnt haben.

Daher nutzt OpenClaw eine vollständige Headless-Architektur. Es ist nur ein Hintergrundprozess, der über bestehende Schnittstellen oder Protokollschichten mit WhatsApp, Telegram, Discord usw. verbunden ist. Die Benutzer "nutzen keine neue App", sondern haben in ihren bestehenden Tools einfach ein neues Objekt, das Aufgaben ausführen kann.

Diese Entwurfsmethode bringt sehr direkte Erkenntnisse. Erstens wird die IO-Schicht entkoppelt. Der Agent kümmert sich nicht mehr darum, wie die Nachrichten angezeigt werden, sondern nur darum, wie die Informationen analysiert und verarbeitet werden. Reife IM-Tools haben schon komplizierte und lästige Probleme wie die Übertragung von Sprache, Bildern und Dateien gelöst. Der Agent vermeidet somit das "Rad neu erfinden" und hat auch keine Migrationskosten.

Noch wichtiger ist, dass es die Häufigkeit der direkten menschlichen Intervention in die Agent-Aktionen deutlich reduziert. Wenn man 10 Minuten lang auf die Kommandozeile schaut und nichts Neues passiert, auch wenn der Timer läuft, denkt die meisten Leute, dass die KI möglicherweise Hilfe braucht (man kann es kaum unterdrücken).

Speicher: Gegen RAG und "Dateien als Datenbank"

Beim Thema Datenspeicherung, also dem sogenannten "Gedächtnis", machte OpenClaw ebenfalls eine Entscheidung, die auf den ersten Blick nicht sehr fortschrittlich aussieht.

Die meisten Mainstream-Lösungen für Agenten basieren auf RAG. Der Vektordatenspeicher ist das Herzstück des Gedächtnisses, und die Strategien für die Einbettung und Suche werden ständig verbessert, um ein "klügeres Gedächtnis" zu erreichen. OpenClaw machte dagegen den entgegengesetzten Weg und legte das Langzeitgedächtnis wieder in das lokale Dateisystem.

In seiner Entwurfsmethode ist das Gedächtnis des Agenten keine abstrakte Darstellung im Vektorraum, sondern eine Reihe von sichtbaren Markdown-Dateien: Zusammenfassungen, Logs und Benutzerprofile werden in strukturierter Textform auf der Festplatte gespeichert. Der Vektorindex ist höchstens eine Ebene zur Beschleunigung der Suche, nicht das eigentliche Gedächtnis.

Die Benutzer können direkt sehen, was der Agent aufgezeichnet hat und wie er ihre Anforderungen beschreibt. Sie können auch manuell korrigieren, wenn sie Abweichungen entdecken, ohne die Datenbankstruktur oder die Suchlogik verstehen zu müssen. Diese weißbox-ähnliche Speichermethode, die auf Texten basiert, bietet eine minimale, aber wichtige Vertrauensgrundlage für die Mensch-Maschine-Kooperation.

Außerdem erfüllt es versehentlich noch eine andere Bedingung: Es bietet ein reflektierbares Gedächtnis für die Selbstentwicklung.

Textbasierte Gedächtnisse unterstützen von Natur aus die Zusammenfassung, Korrektur und Ableitung. Der Agent muss nicht auf eine Versionsoberholung warten, sondern kann während des Betriebs Erfahrungen aus den bestehenden Aufzeichnungen ziehen und die Verwendung seiner Fähigkeiten anpassen.

Sicherheitsprobleme: Die "tödliche Dreierkombination" und die Sandbox-Grenzen

Der Fokus auf die lokale Lösung ist eines der wichtigsten Merkmale von OpenClaw, aber es hat auch die strukturellen Risiken in der Agent-Architektur aufgedeckt.

Wenn ein Agent Zugang zu Dateien hat, ständig unsichere Eingaben aus dem Internet erhält und echte Auswirkungen auf die Umgebung haben kann, dann entsteht die "tödliche Dreierkombination", wie Simon Willison es zusammengefasst hat.

1. Kontakt mit unsicherem externen Inhalt 2. Zugang zu privaten Daten 3. Fähigkeit zur externen Kommunikation

Unter diesen Bedingungen geht es bei den Sicherheitsproblemen nicht mehr darum, ob es Schwachstellen gibt, sondern ob es klare, nicht umgehbare Grenzen gibt.

Die Praxis von OpenClaw hat wiederholt gezeigt, dass natürliche Sprache nicht die Rolle der Sicherheitsgrenze übernehmen kann.

In der frühen Phase der Ökosystementwicklung haben die Entwickler versucht, die Aktionen des Agenten durch Hinweise zu beschränken und die "Verboten" in die System-Hinweise zu schreiben. Aber solange die Eingabe von unsicheren Quellen kommt, ist die Injektion von Hinweisen nur eine Frage der Zeit.

Deshalb muss das Agent OS die Entscheidung darüber, was möglich ist und was nicht, von der Modellschicht auf eine deterministische Systemschicht übertragen. Die Ausführungsumgebung des Tools muss von der Host-System physikalisch getrennt sein, sei es in einem virtuellen Maschinen oder einem WASM-Container. Die Entscheidung über die Berechtigungen darf nicht nur auf dem Modell selbst beruhen, sondern muss durch eine nicht umgehbare Regelung erfolgen.

2

MoltBook: Das Grundgerüst einer KI-Socialplattform und ein soziales Experiment

Während OpenClaw darüber diskutiert, wie ein einzelner Agent funktionieren sollte, wirft MoltBook eine noch fortschrittlichere Frage auf: Wie sollten viele Agenten miteinander verbunden werden, wenn sie gleichzeitig existieren?

Offensichtlich wurde MoltBook als ein Netzwerkraum nur für KI-Agenten entworfen. Menschen können nicht direkt teilnehmen. Die Agenten lesen Inhalte, veröffentlichen Informationen und geben Feedback über die API. Es sieht wie ein "soziales Netzwerk" aus, aber tatsächlich wird die Kommunikationsweise zwischen Agenten und eine noch nicht ausgereifte Maschinen-Netzwerkstruktur immer wieder getestet.

MoltBook selbst ist nicht stabil und kann nicht als reif bezeichnet werden. Aber gerade deshalb ist es eher wie ein Testabschnitt in einer unerschlossenen Gegend. Es kann nicht die Skalierung des Datenverkehrs tragen, aber es kann die Probleme frühzeitig aufdecken.

Von Push zu Pull: Ein möglicher Netzwerkrythmus

Die Standardannahme des menschlichen Internets ist die Sofortantwort. Klicken, Aktualisieren, Antworten - fast alle Protokolle basieren auf einer geringen Latenz. Aber in Netzwerken wie MoltBook, die nur für Agenten sind, scheint diese Annahme nicht mehr notwendig zu sein.

Betrachtet man die tatsächliche Nutzungsmethode, so besuchen die Agenten das Netzwerk nicht ständig, um "Inhalte zu scrollen", sondern sie greifen periodisch auf die Plattform zu, lesen die Themen oder Tags, die sie interessieren, und generieren dann eine Antwort gemäß ihrer eigenen Logik. Dieser Modus ist eher ein Pull-Verfahren als eine Sofort-Push-Nachricht.

Sobald der Schlüsselprozess von A2H zu A2A wechselt, ist die Kollaborationsdichte des Systems nicht mehr von dem menschlichen Rhythmus abhängig.

Das klingt sehr unnatürlich für Menschen, aber es ist tatsächlich eine natürliche Wahl unter den Rechenressourcenbedingungen. Die Inferenz ist teuer, und die Agenten sind nicht geeignet, von ständigen Echtzeit-Anfragen unterbrochen zu werden. Die periodische Verarbeitung entspricht eher der Logik der Ressourcenplanung.

Daraus folgt, dass das Agentennetzwerk wahrscheinlich nicht den Rhythmus des menschlichen Internets kopieren wird. Es kann eine hohe Latenz haben, aber eine höhere Informationsdichte. Es ist eher wie ein periodisches Informationsaustauschsystem als ein ständig rollender Nachrichtenstrom.

Die Verbreitung von Fähigkeiten hängt nicht nur von der Versionsoberholung ab

Ein bemerkenswertes Phänomen auf MoltBook ist die technische Dichte des Inhalts selbst. Die Agenten veröffentlichen nicht nur Meinungen, sondern auch Skripte, Logikabläufe, Entscheidungsvorlagen und andere wiederverwendbare Informationen.

In der traditionellen Softwarearchitektur hängt die Verbesserung der Fähigkeiten von der zentralisierten Veröffentlichung ab: Die Entwickler schreiben Code, packen ihn zusammen und veröffentlichen eine neue Version. In diesem Agentennetzwerk verbreiten sich die Fähigkeiten eher wie Wissensstücke über das Netzwerk. Ein Agent teilt eine Methode mit, und andere Agenten können sie lesen, analysieren und dann entscheiden, ob sie sie übernehmen möchten.

Es gibt bisher keine Beweise, dass dieser Prozess vollständig automatisiert oder systematisiert ist, aber es zeigt zumindest eine andere Möglichkeit: Die Fähigkeiten eines Agenten müssen nicht nur von "vorgegebenen" Funktionen stammen, sondern können auch von der kontinuierlichen Aufnahme von externen Erfahrungen kommen.

Stattdessen alle Fähigkeiten vorab in den Agenten zu programmieren, sollten die Entwickler ihm eher die Mechanismen für die Selektion, Verifizierung und Ablehnung geben. Die Obergrenze der Fähigkeiten eines Agenten hängt weitgehend davon ab, wie er im Netzwerk entscheidet, "was sich lohnt zu lernen".

Identität geht vor Inhalt

Das größte Problem, das MoltBook in der späteren Phase aufgedeckt hat, ist nicht die unkontrollierte Interaktion, sondern das Versagen des Vertrauens.

Bösartige Befehle und gegenläufige Eingaben haben sich im Netzwerk verbreitet und eine zu optimistische Annahme durchbrochen: Agenten können die Zuverlässigkeit der Informationen nur anhand des Inhalts selbst beurteilen. Tatsächlich hat sich gezeigt, dass für Sprachmodelle "anscheinend vernünftige" Inhalte leicht manipulierbar sind.

Daraus lässt sich ein relativ klarer Schluss ziehen: Im Maschinennetzwerk ist der Inhalt selbst nicht zuverlässig. Die Identität ist wichtiger als der Inhalt.

Obwohl MoltBook selbst keine ausgereifte Identitäts- und Signatursystem hat, hat es doch deutlich gezeigt, dass das Agentennetzwerk wahrscheinlich nicht das Vertrauensmodell des offenen Webs verwenden wird, sondern eher einem identitätsbasierten Vertrauensnetz ähneln wird. Zukünftige Agenten-Clients müssen zuerst die "Quelle überprüfen" und nicht nur "den Inhalt verstehen".

Von diesem Blickwinkel aus gesehen, liegt die Bedeutung von MoltBook nicht darin, ob es erfolgreich funktioniert oder nicht, sondern darin, dass es einige Probleme, die früher oder später auftauchen werden, frühzeitig auf den Tisch gelegt hat: Wie sollte der Rhythmus des Agentennetzwerks aussehen, wie können die Fähigkeiten in der Gruppe akkumuliert werden und woher kommt das Vertrauen?

Diese Probleme verschwinden nicht, egal ob MoltBook erfolgreich ist oder nicht. Es war nur das erste Experiment, das diese Probleme zusammen aufgedeckt hat.

3

Ist die Menschheit bereit?

Nach dem Abklingen der Euphorie um OpenClaw und MoltBook bleibt die eigentliche Frage nicht, wie weit diese Projekte noch kommen können, sondern ob die Menschheit bereit ist für die Systemform, die sie aufgedeckt haben.

Diese beiden Versuche haben auf unterschiedliche Weise denselben kritischen Punkt erreicht. OpenClaw hat die Intelligenzagenten direkt in die reale Ausführungsumgebung gebracht und uns gezwungen, uns mit Problemen wie Berechtigungen, Isolation, Rücksetzung und Verantwortlichkeit auf der Ausführungsebene auseinanderzusetzen. MoltBook hat dagegen viele Intelligenzagenten in einer Situation ohne Identität und Governance-Struktur interagieren lassen und die Probleme wie die Verstärkung von Rauschen und die Sicherheitsrisiken des A2A-Netzwerks in der Realität aufgedeckt. Wenn die Fähigkeiten sich mit Maschinen-Geschwindigkeit erweitern, während die Einschränkungen noch auf der Konzeptebene bleiben, ist die Systeminstabilität nur eine Frage der Zeit.

Wir müssen uns nicht nur damit befassen, ob das Modell klüger werden kann oder ob das Produkt nützlicher wird, sondern auch damit, ob wir die passenden Ingenieursdisziplinen, Governance-Strukturen und Verantwortlichkeitsmechanismen haben. Kann natürliche Sprache wirklich die Rolle der Steuerungsoberfläche über