Schleifenerkennung ist keine Stillstandserkennung: Agenten erkennen, die sich drehen, ohne sich zu wiederholen

Dies ist der erste einer Reihe von Entwurfsnotizen zu Agenten für langfristige Aufgaben, angeregt durch eine genaue Lektüre von BEACON (Zhejiang University, arXiv:2605.06078).

Damit ein Agent eine lange Aufgabe durchhält, müssen aus unserer Sicht zwei Dinge stimmen:

• Er macht kontinuierlich Fortschritte zum Ziel. Das gliedert sich in Kontextverdichtung — was gefahrlos vergessen werden darf —, Meilensteingestaltung — woran man erkennt, dass ein Schritt wirklich erledigt ist — und Stillstandsvermeidung: Wenn er feststeckt, muss es jemand bemerken.
• Er kann reflektieren und sich verbessern.

Dieser Beitrag behandelt die Stillstandsvermeidung, weil sie uns am meisten gekostet hat.

Das Symptom

Nutzer meldeten es, und wir sahen es auch intern: Manche sehr langen Aufgaben kommen mittendrin nicht mehr voran.

In den Protokollen ist der Agent beschäftigt — er liest Dateien, sucht, führt Befehle aus, ist nie untätig. Aber eine halbe Stunde später ist nichts vorangekommen.

Unsere erste Erklärung war Kontextverlust: Die Verdichtung hatte den Hinweis entfernt, dass ein Weg schon versucht worden war, also versuchte der Agent ihn erneut. Beim gemeinsamen Lesen von Code und Protokollen stellte sich heraus, dass dies nur die halbe Geschichte war.

Wir hatten bereits Schutzmechanismen — in drei Stufen

Der Kommentar zur dritten Stufe lautet wörtlich: Zusammengesetztes Signal für „möglicherweise Leerlauf nach Kontextverlust“. Jemand hatte das bereits kommen sehen. Das Problem war also nie, dass nichts gebaut worden wäre, sondern dass unsere Lösung es nicht erkennen konnte.

Der blinde Fleck: Alle drei Detektoren betrachten die Eingaben

Jede Stufe orientiert sich an der Signatur tool name + canonicalized args. Das beantwortet genau eine Frage: Tun Sie dasselbe zweimal?

Ein leistungsfähiges Modell, das feststeckt, wiederholt aber keine Aufrufe. Es tut Folgendes:

Datei A lesen → grep X → A mit einem anderen Zeilenbereich erneut lesen
  → einen leicht veränderten Befehl ausführen → Datei B lesen → erneut grep ausführen …

Jeder Aufruf hat eine andere Signatur. Alle drei Stufen bleiben still. Und über den gesamten Zeitraum beträgt die Zahl der überprüfbaren Zustandsänderungen null: keine Datei tatsächlich umgeschrieben, kein Befehl mit neuem Ergebnis, keinerlei unumkehrbarer Vorgang.

Schleifenerkennung ist keine Stillstandserkennung. Die erste betrachtet Eingaben, die zweite muss Ausgaben betrachten.

Der Fachartikel liefert genau diese ausgabeseitige Definition

Die Belohnung innerhalb eines Segments bei BEACON:

r_t = R_ms · γ^(t_k − t)    if the segment ends in a milestone
    = 0                     otherwise

Ein Segment, das nicht in einem Meilenstein endet, erhält genau null, unabhängig davon, wie viele Aktionen es enthielt. Die Aktionszahl geht nie in die Formel ein. Das ist die klarste Formalisierung von beschäftigt ≠ vorankommend, die wir gesehen haben.

Die Baseline-Schicht ist noch strenger. Die Baseline ist die gruppengemittelte Rendite pro Schritt. Ein Segment, das 8 Schritte benötigte, während die Gruppe im Mittel 5 brauchte, erhält daher einen insgesamt ins Negative verschobenen gesamten Advantage. Die Strafe wächst mit der Überschreitung. Leerlauf wird nicht nur nicht belohnt, sondern aktiv und proportional bestraft.

Abbildung 8 des Fachartikels zeigt eine gescheiterte Trajektorie, deren letzte zwei Aktionen identische −2.20 erhalten. Dieser Rest — der Abschnitt nach dem letzten Meilenstein, der keinen weiteren erreicht — ist die mathematische Form von Leerlauf. Und er ist häufig: Trajektorien, die mindestens ein Teilziel erreichen, aber an der Aufgabe scheitern, machen konstant 39–47% der Stichproben aus.

Eine Ablation spricht gegen Auslöser anhand der Schrittzahl

Eine Aufteilung nach beliebigen Schrittzahlen bringt fast nichts. Eine Aufteilung nach realer Struktur bringt viel.

Betrachten wir nun erneut unser Kriterium der dritten Stufe — 75% des Tool-Schleifenbudgets verbraucht. Das ist ein Auslöser anhand einer beliebigen Schrittzahl. Er fragt, wie viel verbraucht wurde, nicht was erreicht wurde. Die richtige Form ist:

✗  if steps > N                              → intervene
✓  if steps > N AND zero verified milestones → intervene

Der zweite Ansatz löst bei einer berechtigt langen, vorankommenden Aufgabe keinen Fehlalarm aus, weil diese unterwegs Meilensteine erreicht. Der erste schon.

Es gibt außerdem eine sich verstärkende Rückkopplung

Stellen wir die Konstanten nebeneinander. Die Verdichtung startet bei 82% des Kontextfensters. Die Leerlaufkonvergenz verlangt zwei Verdichtungen plus 75% des Schleifenbudgets, bevor sie auslöst.

im Kreis drehen → Kontext füllt sich → Komprimierung wird ausgelöst → dauerhafter Zustand geht in der Zusammenfassung verloren
                → Verlorenes erneut herleiten → weiter im Kreis drehen

Der Leerlaufdetektor schließt aus wiederholter Verdichtung auf Leerlauf — dabei ist gerade die Verdichtung der Schritt, der die Amnesie verursacht. Er erkennt ein nachgelagertes Symptom und muss dafür zwei Schleifendurchläufe abwarten.

Schlimmer noch: Sein Eingriff besteht darin, das Modell zur erneuten Orientierung am dauerhaften Zustand anzuhalten. Wenn genau dieser Zustand wegverdichtet wurde, bleibt nichts zur Orientierung übrig. Das ist ein Patch auf Prompt-Ebene für ein Problem auf Zustandsebene.

Was wir ergänzen: ausgabeseitige Stillstandserkennung

Eine vierte Stufe aus zwei Zählern. Beide werden mechanisch aus Tool-Beobachtungen abgeleitet, die die Host-Anwendung bereits erfasst. Keiner benötigt ein Modellurteil.

Schritte seit dem letzten verifizierten Meilenstein. Die einfachste mögliche Fortschrittsmetrik, eingesetzt im obigen zusammengesetzten Kriterium statt allein.

Deduplizierte neue Zustandsänderungen. Der nützlichere der beiden Zähler:

• Ein Dateilesevorgang, dessen Inhalts-Hash mit einem früheren übereinstimmt, liefert keine neue Information. Auch ein erneutes Lesen derselben Datei in einem anderen Zeilenbereich lässt den Hash unverändert.
• Ein Befehl, dessen Name, Exit-Code und Ausgabe-Hash mit einem früheren Lauf übereinstimmen, liefert keine neue Information.
• Ein Schreibzugriff, bei dem der Hash danach dem Hash davor entspricht, bedeutet, dass tatsächlich nichts geschrieben wurde.

Dieser Zähler erfasst genau den Fall, den der Signaturvergleich übersieht: jede Aktion anders, Informationsgewinn null. Das Kriterium ist mechanisch und benötigt kein semantisches Verständnis.

Der Druck sollte dann kontinuierlich statt nur als einmaliger Anstoß wirken:

den Zähler im Kontext anzeigen, damit das Modell ihn sehen kann
  → Überarbeitung des Plans erzwingen (diesen Weg als Sackgasse anerkennen)
    → den Nutzer fragen
      → abbrechen, aber bereits erreichte Meilensteine bewahren

Die letzte Stufe ist wichtig. Wenn der Lauf stoppen soll, sollte er mit dem bisher Erreichten stoppen — genau jenen 39–47% Teilfortschritt, die laut Fachartikel weggeworfen werden.

Was der Fachartikel uns nicht gibt

BEACON ist eine Trainingsmethode. Sie formt Gradienten so, dass die trainierte Strategie weniger zum Abschweifen neigt, besitzt aber keinen eigenen Erkennungs- oder Eingriffsmechanismus zur Laufzeit. Sie liefert eine Definition von Fortschritt, keinen Controller. Schwellenwerte, Eskalationsstufen und Abbruchbedingungen müssen wir selbst entwerfen.

Ihre Baseline pro Schritt benötigt außerdem eine gruppengemittelte Segmentlänge als Referenz. Im Produktivbetrieb läuft eine konkrete Nutzeraufgabe meist genau einmal, es gibt also keine Gruppe. Der beste verfügbare Ersatz sind historische Statistiken ähnlicher Aufgaben. Diese sind deutlich verrauschter und bieten keinerlei Garantie der Varianzisolation aus dem Fachartikel.

Der erste Schritt ist messen, nicht reparieren

Bevor wir Entscheidungslogik ändern, möchten wir die Messung ergänzen und eine Frage beantworten, die wir derzeit nicht beantworten können: Wie viele Stillstände im Produktivbetrieb sind vom Amnesietyp und wie viele vom Typ ohne Fortschrittssignal?

• Überwiegend begleitet von Informationsgewinn null bei lauter unterschiedlichen Aufrufsignaturen → Typ ohne Fortschrittssignal. Die vorhandenen drei Stufen können ihn strukturell nicht erkennen; ausgabeseitige Erkennung ist die Lösung.
• Überwiegend begleitet vom erneuten Lesen bereits wegverdichteter Inhalte → Amnesietyp. Korrigiert werden muss, was die Verdichtung bewahrt.

Diese beiden Schlussfolgerungen verlangen völlig unterschiedliche Investitionen. Erst messen ist günstiger als erst entwerfen, und die Instrumentierung ist nahezu kostenlos, weil die Beobachtungen bereits vorliegen.

Alles oben hängt von einem Begriff ab, den diese Notiz verwendet, ohne ihn zu definieren: einem verifizierten Meilenstein. Darum geht es in der nächsten Notiz. Warum die Meldung, ein Schritt sei abgeschlossen, kein Beleg dafür ist, welche beiden Hälften bereits unverbunden im Produkt existieren und welches Kriterium im Fachartikel fehlt: Unumkehrbarkeit statt Wichtigkeit betrachten.