The Story Deep Dive

Wenn eine KI ihre eigenen blinden Flecken diagnostiziert: Der Selbstverbesserungs-Loop von Hermes

Hermes Agent

Hermes Agent

@hermesagents

April 9, 2026

10 Min. Lesezeit

Es gibt eine bestimmte Art von Release-Notes-PR, die man zweimal lesen muss, weil beim ersten Mal nicht durchdringt, was eigentlich passiert ist. Der relevante Eintrag in den Hermes Agent v0.8.0 Notes lautet:

Selbstoptimierte GPT/Codex-Tool-Use-Guidance — Der Agent hat 5 Fehlermodi beim Tool-Calling von GPT und Codex durch automatisiertes Verhaltens-Benchmarking diagnostiziert und gepatcht, was die Zuverlässigkeit auf OpenAI-Modellen drastisch verbessert. (#6120)

Beim ersten Lesen dachte ich, jemand war etwas großzügig mit dem Wort „selbstoptimiert". Beim zweiten Lesen wurde mir klar, dass es wörtlich gemeint war. Der Agent hat eine Benchmark-Suite gegen sich selbst laufen lassen, systematische Fehler erkannt, wie OpenAI-Modelle seine Tools aufrufen, gezielte Guidance-Strings generiert, um diese Fehler zu beheben, und gemessen, dass die Fixes tatsächlich funktionieren. Menschen haben das Ergebnis freigegeben. Aber der gesamte Schritt Diagnose und Patch war automatisiert.

Das lohnt sich auseinanderzunehmen, denn es ist die Art von Fähigkeit, die sich als einzelne Zeile in ein Release schleicht und verändert, wie künftige Releases aussehen können.

Das konkrete Problem

Die Kombination von Hermes Agent mit OpenAI-Modellen — GPT-5, Codex — war seit ein paar Releases sichtbar wackelig. Nutzer berichteten, dass Anthropic Claude sauber lief, während GPT-5 manchmal Argumente in der falschen Form produzierte, Schritte übersprang oder mitten in einer Multi-Tool-Sequenz vergaß, was es schon erledigt hatte. Das sind keine subtilen Bugs; man kann ihnen beim Passieren zusehen. Aber sie von Hand zu fixen ist zum Verrücktwerden, weil die Fehlermodi modellspezifisch sind und auf Prompt-Formulierungen reagieren, die sich kaum intuitiv erraten lassen.

Laut PR-Beschreibung gab es fünf wiederkehrende Muster:

  • Empfohlene Vorab-Checks vor destruktiven Tool-Aufrufen überspringen.
  • Tool-Argumente als Rohstrings liefern, wo das Schema strukturierte Objekte oder Zahlen erwartete.
  • Den Überblick verlieren, welcher Tool-Call in einer verketteten Sequenz schon erfolgreich war, was zu doppelten Aufrufen führte.
  • Nach transienten Fehlern den Retry verweigern, obwohl die Guidance einen Retry vorsah.
  • Bei langen Kontexten von „den Plan ausführen" zu „den Plan neu planen" abdriften.

Keines davon ist theoretisch. Hinter jedem steckt eine Spur von GitHub-Issues.

Die Schleife, die sie gefixt hat

Der Ansatz in PR #6120 hat drei bewegliche Teile.

Erstens eine automatisierte Verhaltens-Benchmark-Suite. Ein Harness lässt den Agenten gegen einen Satz synthetischer Szenarien laufen, die so entworfen sind, dass sie jeden der fünf Fehlermodi provozieren. Für jedes Szenario protokolliert der Benchmark, was das Modell getan hat, was es hätte tun sollen und ob die Differenz als eines der bekannten Fehlermuster zählt.

Zweitens ein Guidance-Generierungsschritt. Wenn der Benchmark einen Fehler flaggt, produziert der Harness Kandidaten-Guidance-Strings — kurze, modellspezifische Anweisungen, die zum System-Prompt hinzugefügt werden und exakt auf das fehlgeschlagene Muster zielen. Nicht „Sei vorsichtiger", sondern Dinge wie: „Vor jedem destruktiven Tool-Aufruf erst das entsprechende Preview-Tool mit identischen Argumenten aufrufen und seine Ausgabe berichten." Die Kandidaten werden gegen die konkreten beobachteten Fehler generiert, nicht gegen eine generische Rubrik.

Drittens ein Re-Benchmarking-Schritt. Jeder Kandidaten-String wird gegen dieselbe Szenarien-Suite getestet. Guidance, die Scores verbessert, bleibt. Guidance, die andere Szenarien verschlechtert, fliegt raus. Die überlebenden Strings werden in den GPT/Codex-System-Prompt aggregiert, den Hermes ausliefert.

Warum das etwas anderes ist

Historisch gesehen wurden die Prompts, die mit einem Agent-Framework ausgeliefert werden, von Menschen geschrieben — manchmal einer, manchmal ein kleines Team —, die sich Meinungen darüber bilden, was funktioniert und was nicht, indem sie selbst Konversationen durchsehen. Dieser Prozess hat drei Probleme: Er skaliert nicht auf viele Modelle, er lässt sich nicht billig wiederholen, wenn ein Modell aktualisiert wird, und er produziert Prompts, die den Aberglauben einer Person zusammen mit ihren echten Erkenntnissen kodieren.

Die Schleife „Mensch schreibt, Mensch bewertet" durch „Benchmark schreibt Kandidaten, Benchmark bewertet sie" zu ersetzen, ist nicht dasselbe, wie eine KI sich ohne Aufsicht selbst tunen zu lassen. Menschen geben die finale Guidance noch immer frei. Aber die eigentliche Arbeit — Muster finden und Fixes vorschlagen — ist jetzt messbar und wiederholbar. Wenn GPT-6 erscheint, läuft derselbe Harness nochmal. Wenn ein neuer Fehlermodus gemeldet wird, kommt ein neues Szenario dazu und die Schleife läuft erneut. Der Aufwand, den Prompt mit dem tatsächlichen Verhalten des Modells synchron zu halten, sinkt um eine Größenordnung.

Die verwandten Änderungen in v0.8.0 deuten in dieselbe Richtung. Thinking-Only-Prefill-Continuation (#5931) behandelt den Fall, dass ein Modell einen Reasoning-Block ohne Content-Block produziert und dann stecken bleibt. Execution-Discipline-Guidance (#5414) fügt eine allgemeine Regel „Nicht neu planen, es sei denn, es hat sich wirklich etwas geändert" zum System-Prompt hinzu. Tool-Call-Argument-Coercion (#5265) wandelt Strings still in Zahlen und Booleans um, wenn das JSON-Schema sie erwartet — genau der Argument-Typisierungsfehler, den der Benchmark entdeckt hat. Einzeln im Changelog sehen diese drei PRs unzusammenhängend aus. Zusammen mit PR #6120 gelesen, sind sie die sichtbare Oberfläche einer gezielten Kampagne: den Agenten auf einer bestimmten Modellfamilie zuverlässiger machen, indem man misst, fixt und nochmal misst.

Die stille Implikation

Was das Ganze zu einem Wendepunkt macht und nicht nur zu einem guten Release, ist der Hinweis darauf, wie Agent-Engineering aussieht, wenn man aufhört, Prompts von Hand zu schreiben. Ein Repo wie Hermes muss zwölf verschiedene Provider und dreißig verschiedene Modelle bedienen. Das Verhalten jedes einzelnen manuell zu tracken ist schon jetzt unmöglich. Wenn man stattdessen „Wie sollten wir Modell X prompten?" als Tuning-Problem behandelt, das ein Benchmark-Harness löst, hat man einen Prozess, der mit der Größe des Modell-Zoos skaliert, statt darin zu ertrinken.

Nichts davon war die Schlagzeile von v0.8.0. Die Schlagzeile war „the intelligence release" und die Demo war der Live-Modellwechsel. Aber das Stille unter den Bodendielen ist: Hermes hat jetzt einen Weg, den Agenten auf jedem unterstützten Modell schlau zu halten, ohne dass ein Mensch pro Modell ein Wochenende mit System-Prompt-Tuning verbringt. Diese Fähigkeit wird auch im nächsten Release nicht als Feature auftauchen — sie wird als „GPT-Zuverlässigkeit auf Hermes wird immer besser" über die nächsten sechs aufeinanderfolgenden Releases sichtbar.

Und wenn du wie ich Release Notes zum Spaß liest, ist das die Form der Sache, die man im Auge behalten sollte.

Weiterlesen

Auf dem Laufenden bleiben

Community-Updates zu Hermes-Agent-Releases, neuen Skills und Integrationen. Kein Spam, jederzeit abbestellbar.