Der "Hermès" will die "geistig behinderten" Krebse retten.

Text | Lambda

Redaktion | Xiaojing

Anfang April war Hermes Agent in Mode. Der Name lässt direkt an die Luxusmarke Hermès denken, weshalb es auch als „Hermès Agent“ gescherzt wird.

Es wurde von Nous Research im Februar veröffentlicht und hat die Positionierung „The agent that grows with you“ (Der Agent, der mit Ihnen wächst). Der Kernverkaufspunkt ist ein geschlossener Lernzyklus: Nachdem der Agent eine komplexe Aufgabe abgeschlossen hat, wird die Erfahrung automatisch zu einer Fähigkeit (Skill) festgelegt. Bei ähnlichen Aufgaben kann diese Fähigkeit direkt wiederverwendet werden und sich im Gebrauch stetig verbessern. Die automatische Generierung von Fähigkeiten und deren stetige Verbesserung ist eines der derzeit attraktivsten Konzepte im Agentenbereich.

Doch dieses Konzept verdecken ein grundlegendes Problem: Ist die Fähigkeit (Skill) wirklich der Hauptengpass bei der Umsetzung von Agenten?

Bild generiert von KI

01 Fähigkeiten (Skills) sind sexy, aber möglicherweise nicht das wichtigste Problem

Ein leicht zu übersehender Fakt ist: Eines der derzeit am besten bewerteten Programmier-Agentenprodukte, Claude Code, basiert nicht auf der automatischen Evolution von Fähigkeiten, sondern auf einer Vielzahl solider CLI-Tools.

Mit GlobTool werden Kandidatendateien gesucht, mit GrepTool werden relevante Codeausschnitte lokalisiert, mit FileReadTool werden Implementierungsdetails betrachtet und mit LSPTool werden Codesymbolsprünge und Referenzanalysen durchgeführt. Jede dieser Aktionen ist eine deterministische, tokenfreie Atomoperation.

Aber über diese Tools erzählt man selten Geschichten. Sobald man von Agenten spricht, die Fähigkeiten automatisch generieren und stetig verbessern können, wird die ganze Branche sofort aufgeregt.

Dieser Kontrast zeigt: Die CLI (Befehlszeilenschnittstelle) ist nicht sexy und schwer zu vermarkten, aber sie ist der wahre Grundstein für die Fähigkeiten von Agenten.

Wenn der Grundstein instabil ist, wächst eine Fähigkeit, wie stark sie auch sein mag, nur auf schlechtem Sand.

02 Die am meisten beanstandeten Probleme bei OpenClaw können nicht durch die autonome Evolution von Fähigkeiten gelöst werden

Dies wird deutlicher, wenn man sich OpenClaw (allgemein als „Hummer“ bezeichnet) anschaut.

Die beiden am meisten beanstandeten Punkte bei OpenClaw sind einerseits der hohe Tokenverbrauch und die damit verbundenen hohen Kosten, andererseits die schlechte Stabilität bei längerem Betrieb und die häufigen Verbindungsverluste. Auf den ersten Blick erscheinen dies als zwei separate Probleme, aber wenn man genauer hinsieht, stellt man fest, dass sie oft von der gleichen Quelle stammen: Der Agent verwendet schlechte Tools – wie z. B. instabile Browserautomatisierung – um Aufgaben zu erledigen, die eigentlich von deterministischen Tools erledigt werden sollten.

Diese Kosten sind in der Community keine abstrakten Beschwerden, sondern es gibt zahlreiche konkrete Beispiele.

Ein OpenClaw-Benutzer auf Reddit berichtete, dass er nur eine automatische Veröffentlichung auf einem X-Konto wollte, aber schon nach drei Versuchen 10 US-Dollar ausgegeben hatte, ohne dass die Aufgabe tatsächlich funktioniert hatte. Ein anderer Nutzer in r/automation sagte direkt, dass viele sogenannte KI-Agenten-Browsersteuerungen im Wesentlichen nur „instabile Automatisierungen mit einem intelligenten Anstrich“ seien – das Problem liege nicht an der Dummheit des Modells, sondern an der Unzuverlässigkeit der zugrunde liegenden Tools. Sobald sich die Seite ändert, das DOM (Dokumentobjektmodell) verändert oder der Zustand eines Buttons sich ändert, muss der Agent immer wieder beobachten, wiederholen und neu planen.

Und diese „fehlgeschlagenen, aber nicht fatalen“ Versuche kosten nicht weniger, nur weil die Aufgabe nicht abgeschlossen wurde – jedes Mal, wenn der Agent die Seite beobachtet, den Zustand analysiert und den nächsten Schritt bestimmt, werden weitere Token verbraucht.

Somit sind das Problem der Stabilität und das Problem der Kosten eigentlich zwei Seiten einer Medaille: Je instabiler die Tools, desto mehr Versuche; je mehr Versuche, desto schneller werden die Token verbraucht; je länger die Aufgabenkette, desto höher ist die Wahrscheinlichkeit von Verbindungsverlusten und Unterbrechungen.

Von dieser Perspektive aus löst die autonome Evolution von Fähigkeiten das Problem, wie man ein Tool intelligenter einsetzt, aber nicht das Problem, dass es an guten Tools mangelt. Fähigkeiten können einem Agenten helfen, ein lahmes Pferd besser zu reiten, aber sie können das lahme Pferd nicht in ein Wunderpferd verwandeln.

Hier liegt das eigentliche Problem bei vielen Agentensystemen heute: Es fehlt nicht an starken Fähigkeiten, sondern an hochwertigen Atomtools, die der Agent nutzen kann.

03 Fähigkeiten (Skills) sind eine Ergänzung für die Modellfähigkeiten

Was Hermes macht, ist im Wesentlichen die Automatisierung der Generierung und Optimierung von Fähigkeiten – der Agent distilliert Wissen aus Erfahrungen, ohne dass es von Hand geschrieben werden muss. Dies löst tatsächlich ein echtes Problem.

Aber Fähigkeiten haben ein tieferes Problem: Sie werden durch natürliche Sprache angetrieben und sind im Wesentlichen eine Erweiterung der Modellfähigkeiten oder eine Art Kredit auf die Modellfähigkeiten.

Derzeit nutzen viele Agenten Fähigkeiten und die Fähigkeit, Probleme selbst zu lösen, um Aufgaben zu erledigen, die eigentlich von der CLI erledigt werden sollten – wie z. B. die Abfrage eines Aktienkurses, das Herunterladen eines Bildes oder das Absenden eines Formulars mit einer ineffizienten Browserautomatisierungslösung. Die Kosten sind klar: Teuer, langsam, instabil und schwer zu debuggen.

Hier gibt es auch einen häufigen Denkfehler, den man als „Illusion der übertragbaren Fähigkeiten“ bezeichnen kann: Viele Menschen denken, dass Fähigkeiten, die mit einem starken Modell geschrieben wurden, nahtlos auf ein schwächeres Modell übertragen werden können. Tatsächlich ist dies nicht der Fall. Fähigkeiten sind natürliche Sprachbefehle, die eine implizite Abhängigkeit von der Modellfähigkeit haben; wenn man das Modell wechselt, kann sich das Verhalten ändern. Die CLI ist dagegen anders – es ist Code: Bei gleichen Eingaben gibt es immer die gleichen Ausgaben, unabhängig davon, welches Modell im Hintergrund läuft.

Der Unterschied zwischen den beiden ist sehr deutlich:

Fähigkeiten sind schwer zu debuggen, die CLI ist einfach zu debuggen;

Fähigkeiten verbrauchen Token, die CLI verbraucht fast keine Token;

Fähigkeiten sind abhängig von der Modellversion, die CLI ist es nicht;

Fähigkeiten sind Assets auf der semantischen Ebene, die CLI ist ein Asset auf der Ausführungsebene.

Wenn man Fähigkeiten als Kernrichtung für die Akkumulation ansieht, setzt man im Wesentlichen auf die Stabilität der Modellfähigkeiten. Zumindest in der gegenwärtigen Phase lohnt es sich eher, hochwertige CLI-Tools zu akkumulieren.

04 Wenn die Tools und der Kontext gut genug sind, sinkt die Priorität von Fähigkeiten (Skills) automatisch

Die obige Analyse kann auch aus der eigenen Produktentwicklung von Anthropic bestätigt werden.

Jenny Wen, die Leiterin der Designabteilung bei Anthropic und die Designverantwortliche für das Cowork-Produkt, erwähnte in einem kürzlichen Interview ein Detail: Sie selbst nutzt die Skills-Funktion in Cowork eigentlich nicht so oft. Der Grund ist nicht, dass sie Fähigkeiten ablehnt, sondern dass sie in Cowork einen Ordner angehängt hat, in dem sich ihre langfristig gesammelten persönlichen Notizen, Einträge aus persönlichen Meetings, spontane Ideen und Arbeitsbeobachtungen befinden. Für sie hat Cowork bereits genug Informationen aus diesen Materialien gelernt, sodass ihr Bedarf an Fähigkeiten und Memory deutlich reduziert ist.

Dies bedeutet nicht, dass Fähigkeiten keinen Wert haben, sondern: Wenn der Kontextmanagement gut genug und die zugrunde liegenden Tools stark genug sind, sinkt die Priorität von Fähigkeiten automatisch.

Mit anderen Worten: Die von Hermes betonte autonome Evolution von Fähigkeiten ist nicht falsch, aber das Problem, das es löst, ist möglicherweise nicht so grundlegend wie man denkt.

05 Etwas passiert leise: Die Benutzer der CLI sind von Menschen zu Agenten geworden

Wenn Fähigkeiten das Problem der Orchestrierung auf der Anwendungs Ebene lösen, dann passiert die tiefere Veränderung bei der CLI.

In der Vergangenheit wurde die CLI für Menschen entwickelt. Eine CLI für Menschen kann Interaktionshinweise geben, unklare Ausgaben tolerieren und auch bei unvollständiger Dokumentation auf die Intuition des Benutzers vertrauen – weil Menschen anhalten, Mehrdeutigkeiten verstehen, wiederholen und in der Dokumentation nachschlagen können.

Agenten sind anders.

Agenten schlafen nicht, tolerieren keine Mehrdeutigkeiten, können parallel arbeiten und wiederholen unendlich oft, wenn sie es nicht erwarten. Eine CLI, die für Menschen „gerade noch brauchbar“ ist, kann für einen Agenten eine häufige Störungsquelle sein.

Eine CLI für Agenten muss eine ganz andere Reihe von Anforderungen erfüllen:

Ein Befehl darf nur ein eindeutiges Ergebnis liefern;

Die Ausgabe muss ein strukturiertes JSON sein;

Fehlermeldungen müssen nicht nur sagen, wo der Fehler liegt, sondern auch dem Agenten sagen, was er als nächstes tun soll;

Lange Aufgaben müssen asynchron unterstützt werden, damit der Agent nicht stumm warten muss;

Die Schnittstelle muss von Natur aus idempotent, wiederholbar und parallelisierbar sein.

Im Grunde genommen geht es nur um eine Sache: Früher ging man davon aus, dass Softwarebenutzer schlafen, abgelenkt werden und Geduld haben; Agenten erfüllen diese Voraussetzungen nicht.

Sobald die Benutzer von Menschen zu Agenten werden, muss die Designphilosophie der CLI von Grund auf neu geschrieben werden. Agenten kümmern sich wirklich um Tokenverbrauch, Cache-Trefferquote, Halluzinationskontrolle und Langzeitstabilität, nicht um „wie elegant ein Befehl aussieht“.

06 Alles, was im Browser sichtbar ist, ist für die CLI geeignet

Ein Experiment verdeutlicht das sehr gut: Die Webversion von ChatGPT wird in eine CLI umgewandelt, die von einem Agenten aufgerufen werden kann.

Die Methode ist nicht geheimnisvoll – man steuert den Browser direkt über das Chrome CDP-Protokoll, manipuliert das DOM, füllt Eingabefelder aus, klickt auf Senden, wartet auf das Erscheinen von Text und holt dann das Ergebnis ab. Da man den bestehenden Anmeldestatus wiederverwendet, unterscheidet sich das Verhalten im Wesentlichen nicht von dem eines Menschen, der im Browser arbeitet.

Die größere Erkenntnis hinter diesem Experiment ist: Alles, was im Browser sichtbar ist, kann prinzipiell in eine CLI umgewandelt werden.

Nicht nur ChatGPT – auch Gemini, Musikgenerierung, Videogenerierung, Aktiencharts und alle anderen Prozesse, die im Browser durchgeführt werden können, können von Code wiederholt ausgeführt werden und schließlich zu einem Befehl zusammengefasst werden, den ein Agent aufrufen kann.

Sobald ein Web-Prozess in eine CLI umgewandelt wird, wird er von einem Prozess, bei dem der Agent Schritt für Schritt die Webseite beobachten und Fehlversuche machen muss, zu einer „parallelisierbaren, asynchronen, idempotenten Atomoperation“. Was zuvor mit einer Browserautomatisierung und einem hohen Tokenverbrauch erledigt werden musste, wird zu einem Befehl und einem strukturierten Ergebnis zusammengefasst.

In gewisser Weise ist dies ein unintuitiver, aber sehr realistischer Optimierungspfad: Die Methode, um Token zu sparen, besteht nicht darin, den Agenten weniger arbeiten zu lassen, sondern darin, zunächst etwas Token zu verbrauchen, um häufige Prozesse in eine CLI umzuwandeln. Ein guter Anfang macht die Arbeit halb.

Dieser Gedanke gilt nicht nur für das Web. Desktopanwendungen und Mobil-Apps können im Wesentlichen auch schrittweise in eine CLI umgewandelt werden, was man sieht, kann man in eine CLI umwandeln. Derzeit gibt es bereits viele Open-Source-Projekte, die in diesen drei Richtungen voranschreiten, aber es gibt noch keine einheitliche Designsprache und keine ausreichende Aufmerksamkeit.

07 Schichtung ist der Endzustand

Die Zukunft von Agenten hängt neben der Verbesserung des Modells selbst auch davon ab, wie man zwei Arten von Logik behandelt: Deterministische Logik und Semantische Logik.

Die erste wird von der CLI unterstützt, die zweite von der Anpassungsfähigkeit und Evolution von Fähigkeiten. Hermes löst das Problem der zweiten, aber die erste ist der eigentliche Mangel bei vielen Systemen heute.

Wenn man die CLI-Umwandlung bis ins Extrem treibt, passiert etwas sehr unintuitives: Bei einer Art von Aufgaben mit vollständig festgelegten Prozessen muss der Agent nur den Aufgaben Typ bestimmen, zum entsprechenden CLI weiterleiten und das Ergebnis abholen – theoretisch braucht man hierfür sogar kein LLM, ein paar if-else-Anweisungen reichen. Man kann sogar den Eingabe-Ausgabe-Schnittstellen des LLM mit Code nachahmen, ohne Tokenverbrauch und ohne Verzögerung, und das bestehende Agenten-Scheduling-System weiterverwenden, und erst an den Stellen, wo wirklich eine Entscheidung getroffen werden muss, das echte Modell aufrufen.

Dies ist wie eine Art „Renaissance der Code“ im Jahr 2026 – Menschen beginnen erneut zu entdecken, dass nicht alle Probleme, die „intelligent aussehen“, an das Modell delegiert werden sollten.

Die Endzustandliche Aufteilung sollte in drei Ebenen erfolgen:

CLI-Ebene: Deterministische Ausführung, kein Tokenverbrauch, parallelisierbar, einfach zu testen, keine Abhängigkeit von einem Modell;

Fähigkeiten (Skills)-Ebene: Orchestrierung des Kontexts und Distillation von Erfahrungen, je öfter man sie nutzt, desto stärker wird sie;

LLM-Ebene: Bereitstellung von Intelligenz, Durchführung der Teile, die wirklich semantische Entscheidungen erfordern.

Die drei Ebenen stehen nicht in Konkurrenz zueinander, sondern in einer Abhängigkeitsbeziehung.

Das Problem bei vielen Systemen heute ist, dass sie die CLI-Ebene überspringen und direkt Fähigkeiten und LLM nutzen, um die Lücken zu füllen. Das Ergebnis ist: Das System ist teuer, langsam und instabil. Der richtige Weg sollte sein – die Entwickler erstellen CLI-Tools im Voraus, die oberen Anwendungen verwalten Fähigkeiten automatisch, und das LLM nutzt die CLI mit der Unterstützung von Fähigkeiten, um Probleme zu lösen.

Das Auftauchen von Hermes ist nicht das Ende, sondern ein Signal: Das Problem auf der Fähigkeiten (Skills)-Ebene wird möglicherweise gelöst, aber das nächste echte Schlachtfeld liegt auf der CLI-Ebene.

Die systematische CLI-Umwandlung auf den drei