Die meisten KI-Agents laufen pro Runde einen Schritt. Du tippst, sie antworten, sie warten. Den Loop führst du. Der Agent ist nur ein Function Call.
Hermes Agent hat diesen Modus auch — der ist sogar der Default. Aber er bringt noch einen anderen Modus mit, /goal, in dem der Agent den Loop führt. Du setzt ein Ziel plus Erfolgskriterien, der Agent schlägt vor, führt aus, bewertet, versucht es nochmal und läuft weiter, bis ein separater Judge-LLM bestätigt, dass die Kriterien erfüllt sind. v0.14.0 (16. Mai 2026) hat /subgoal ergänzt, damit du auf einen laufenden Loop weitere Kriterien draufpacken kannst, ohne ihn neu zu starten (#25449).
Dieser Beitrag schaut sich an, was darunter wirklich passiert, wann das Werkzeug das richtige ist und welche Failure-Modes daraus das falsche machen.
Der Default-Modus (zum Vergleich)
Jede Chat-Session in Hermes ist eine Runde pro Nutzer-Nachricht. Der Agent liest deine Nachricht, ruft bei Bedarf Tools, gibt eine Antwort zurück. Ist die Aufgabe nicht durch, musst du stupsen: „mach weiter", „nochmal", „und was ist mit X". Den äußeren Loop führst du.
Für exploratives Arbeiten passt das — „erklär mir diesen Code", „schreib eine Notiz", „such mir einen Bug". Du willst, dass der Agent nach jedem Schritt pausiert, damit du umlenken kannst.
Für Aufgaben, bei denen die Erfolgsbedingung konkret und der Weg dorthin iterativ ist, passt es nicht. „Refaktoriere dieses Modul, bis pytest durchläuft" ist eine Aufgabe von dreißig Runden, wenn du jede Runde fährst. Mit /goal ist es ein einziger Befehl.
Was /goal wirklich macht
/goal Make all tests in tests/api/ pass. Don't change the test assertions. Done when pytest exits 0.
Wenn du das absetzt, passieren drei Dinge:
- 1.Der Ziel-Text wird zum Target-Prompt des Workers. In jeder folgenden Runde bekommt das Worker-Modell eine System-Message, die das Ziel und den aktuell besten Versuch enthält.
- 2.Nach jeder Worker-Runde läuft ein separater Judge-LLM-Call. Der Judge sieht das Ziel, den aktuellen Stand und den vorgeschlagenen Abschluss. Er gibt entweder „done" zurück (Loop endet) oder „weitermachen, das fehlt noch".
- 3.Der Loop läuft, bis der Judge done sagt — oder bis du ihn mit
/stopanhältst, oder bis er das konfigurierte Iterationslimit erreicht.
Der Judge ist die zentrale Stelle. Er ist nicht derselbe LLM-Call wie der Worker und sieht die Gedankenkette nicht — nur das Ziel und den aktuellen Stand. Diese Trennung macht /goal erst möglich: Ein Worker, der sich schon eingeredet hat, dass seine Antwort stimmt, ist ein schlechter Richter. Ein frischer LLM-Call ohne Kontext ist viel besser geeignet.
Dieses Muster heißt in der Hermes-Codebase intern „Ralph-Loop", nach dem kanonischen Pseudocode while not done: do(work); ralph = judge(work). Die /subgoal-Erweiterung von v0.14.0 lässt den Nutzer neue Judge-Kriterien in einen laufenden Loop einspeisen.
/subgoal — Kriterien mittendrin nachschieben
Du hast einen /goal zur Refaktorisierung eines Moduls gestartet. Drei Loops drin merkst du, dass die Refaktorisierung außerdem die zyklomatische Komplexität pro Funktion unter 10 halten soll. Du willst den Loop nicht anhalten und neu starten.
/subgoal Each function must have cyclomatic complexity <= 10.
Beim nächsten Lauf des Judges fließt diese neue Bedingung mit ein. Erfüllt der aktuelle Beste sie nicht, läuft der Loop weiter. Erfüllt er sie, beendet sich der Loop.
Das ist die Art Feature, die in den Release Notes als kleine Bullet wirkt — „vom Nutzer hinzugefügte Kriterien werden an ein aktives /goal angehängt" — und für jeden, der den Loop wirklich benutzt, zu einem tragenden Pfeiler wird. Echte Ziele werden während des Beobachtens des Agents nachgeschärft. Ohne /subgoal ging Nachschärfen nur über /stop + neu definieren + erneut /goal — und der Zwischenstand war weg.
Praktische Beispiele
Refaktorisieren, bis die Tests durchlaufen
/goal Refactor src/api/users.py so the User class follows the new naming convention in src/conventions.md. Don't break any existing tests. Done when:
1. pytest exits 0
2. The User class matches the convention rules in conventions.md
Der Worker probiert Refactorings, der Judge prüft beide Bedingungen. Wenn beide grün sind, beendet sich der Loop.
An einer UI iterieren
/goal Make the button on /pricing more prominent. Done when:
1. The button is the largest interactive element above the fold on desktop
2. It uses the primary brand color (#FF5A50)
3. Existing Lighthouse accessibility score doesn't drop
Der Worker bearbeitet CSS, der Judge macht über das Browser-Tool einen Screenshot und prüft nach. Viele Iterationen ohne dass du daneben sitzen musst.
Einen Bug suchen
/goal Find the cause of the intermittent test failure in tests/auth/test_session.py::test_logout_clears_cookie. Done when you produce a minimal failing repro and a one-paragraph explanation.
Der Judge prüft hier, ob beide Teile des Outputs da sind — Repro und Erklärung — nicht ob einer oder der andere geliefert wurde. /subgoal lässt dich Einschränkungen wie „die Erklärung muss den relevanten Request/Response-Zyklus benennen" nachschieben, falls der erste Entwurf zu vage ist.
Wann du es nicht nehmen solltest
/goal ist das falsche Werkzeug für Aufgaben, bei denen:
- •Die Erfolgsbedingung diffus ist. „Mach das hier eleganter" — der Judge kann das nicht konsistent bewerten, also schwankt der Loop oder stempelt einfach ab. Hier geht's Runde für Runde.
- •Du den Lauf live mitsehen willst. Jede Iteration läuft komplett durch, bevor der Judge feuert, du hast also nicht dieselbe Pro-Runde-Sicht. Wenn dir Zwischenreviews wichtig sind, nimm Runde-für-Runde oder
/handoff. - •Kosten dir mehr zählen als Tempo. Jede Loop-Iteration ist ein Worker-Call plus ein Judge-Call. Bei zehn Iterationen zahlst du zwanzig LLM-Calls. Lohnt sich für Refactorings; ist Verschwendung für „wie soll ich diese Variable nennen?".
- •Du dich nicht um die Erfolgskriterien gekümmert hast. Müll-Kriterien → Müll-Loop.
/goalbelohnt Konkretheit, und der Agent wird jede Mehrdeutigkeit ausnutzen.
Wie /goal mit /handoff zusammenspielt
v0.14.0 hat auch /handoff mitgebracht, das eine laufende Session zwischen Modellen überträgt, ohne Kontext zu verlieren (#23395). Die beiden komponieren: Du übergibst ein laufendes Goal von einem schnellen Modell an ein Modell mit tiefem Reasoning, sobald das Goal auf etwas trifft, das das schnelle Modell nicht löst. Der Judge bewertet weiter nach denselben Kriterien; nur der Worker wurde besser.
Genauso mit /sessions (#20805) — du kannst ein Goal unterbrechen, in eine andere Session schauen und das Goal später wieder aufnehmen. Der Loop-Zustand ist als Checkpoint gesichert.
Wo das in den Agent-Stack passt
Drei verschiedene Formen autonomer Arbeit, sortiert danach, wie viel du den Agenten lenkst:
- 1.Runde für Runde — du fährst, der Agent antwortet. Konversationell.
- 2.
/goal— du setzt die Kriterien, der Agent läuft im Loop, bis sie erfüllt sind. Begrenzte Autonomie. - 3.Cron-Scheduling — der Agent läuft unbeaufsichtigt nach Plan, mit Auslieferung an Messaging-Plattformen. In der Zeit unbegrenzte Autonomie.
/goal ist die mittlere. Es ist der richtige Griff für eine Klasse Aufgaben, die früher entweder schweres Babysitten oder ein Custom-Skript verlangt haben. Das /subgoal von v0.14.0 macht den Loop mittendrin lenkbar, und genau das macht aus einer Kuriosität ein Alltagswerkzeug.