Dies ist die zweite Notiz einer Reihe zum Design von Agenten für langfristige Aufgaben, angeregt durch eine genaue Lektüre von BEACON (Zhejiang University, arXiv:2605.06078).
Die erste Notiz argumentierte, dass Schleifenerkennung einen feststeckenden Agenten nicht erfassen kann, weil Wiederholung ein eingabeseitiges Signal ist, Fortschritt dagegen ein ausgabeseitiges. Dieses Argument funktioniert nur, wenn es etwas gibt, woran sich Fortschritt messen lässt. Darum geht es in dieser Notiz.
Die Frage richtig stellen
Die Frage lautet nicht: „Woher weiß der Agent, dass er einen Schritt abgeschlossen hat?“ Sie lautet: „Woher weiß das System, dass er wirklich abgeschlossen wurde, statt nur als abgeschlossen gemeldet zu werden?“
Eine Ebene Unterschied — und die Glaubwürdigkeit ist nicht vergleichbar.
Wir hatten bereits zwei Hälften und verbanden sie nie
Beim Lesen unserer eigenen Implementierung war das der überraschende Teil.
Die erste Hälfte. Meilensteine gibt es bereits im Produkt. Ein Tool führt einen dauerhaften Aufgabenplan: wie eine lange Aufgabe zerlegt wird und welchen Zustand jeder Schritt hat — ausstehend, in Bearbeitung, abgeschlossen, blockiert. Sein erklärter Zweck ist, langen Aufgaben einen stabilen Fortschrittsanker zu geben. Aber wie wird ein Schritt „abgeschlossen“? Das Modell erklärt ihn dazu.
Die zweite Hälfte. Nach jedem Tool-Aufruf erfasst die Host-Anwendung deterministische Fakten: ob sich der Inhalts-Hash einer Datei tatsächlich geändert hat, welchen Exit-Code ein Befehl lieferte, ob eine Zeitüberschreitung auftrat. Diese Fakten werden auf Host-Seite erfasst und gelangen nie in den Modellkontext. Genau deshalb können sie nicht erfunden werden.
Dort liegt die Lücke. Eine Zeile sagt Ich bin fertig. Die andere sagt Der Hash einer Datei hat sich von A zu B geändert. Nichts hat beides je nebeneinandergestellt.
Es fehlt weder eine Datenstruktur noch Beobachtbarkeit. Es fehlt die Verbindung zwischen beiden.
Das Nützlichste im Fachartikel ist nicht die Formel
BEACON ist vor allem für seinen Advantage auf zwei Ebenen bekannt. Übernehmenswert ist aber, wie es den Detektor Φ einordnet.
Φ benötigt kein trainiertes Modell und keine menschlichen Annotationen. Es liest nur Zustandsänderungen, die im Umgebungsfeedback beobachtbar sind: Objektzustandsübergänge in ALFWorld — erfolgreich aufgenommen, Erwärmung abgeschlossen —, Seitenwechsel in WebShop. In ScienceWorld nutzt es einfach das Teilzielsignal, das die Umgebung bereits ausgibt.
Kein zusätzliches Modell, keine zusätzlichen Sampling-Kosten. Zum Vergleich die Alternativen: Ein Prozess-Belohnungsmodell benötigt teure Annotationen und lässt sich austricksen; Monte-Carlo-Wertschätzung erfordert zusätzliche Rollouts an jedem Entscheidungspunkt. Genau diese Kosten vermeidet Φ.
Wer ein Agentenprodukt baut, hat einen Vorteil gegenüber den Umgebungen des Fachartikels: Tool-Aufrufe sind von Anfang an strukturiert, mit explizitem Erfolg und Misserfolg. Der Fachartikel musste Signale aus einer Umgebung gewinnen. Unsere sind schon da.
Drei Schichten für eine mögliche Umsetzung
Schicht eins: deterministische Belege in einem Strom sammeln. Ganz ohne semantisches Urteil, nur als mechanische Aufzeichnung unumkehrbarer, überprüfbarer Änderungen. Der Inhalts-Hash einer Datei hat sich geändert. Ein Befehl endete mit null. Ein externer API-Aufruf meldete Erfolg. Eine Zeile wurde festgeschrieben. All das existiert bereits. Es ist nur verstreut und wurde nie zu einer einzigen Aufzeichnung der bisher feststehenden Fakten zusammengeführt.
Schicht zwei: die beiden Hälften verbinden. Der wertvollste Schritt. Wenn das Modell einen Schritt als abgeschlossen meldet, nehmen Sie das nicht länger auf Glauben hin, sondern suchen in diesem Zeitfenster nach Belegen aus Schicht eins. Belege vorhanden: als nachweislich abgeschlossen markieren. Keine Belege: als als abgeschlossen gemeldet markieren. Das hindert das Modell an keiner Aussage; es trennt nur Belegtes von Unbelegtem.
Schicht drei: Φ pro Fähigkeitstyp definieren. Die Autoren räumen ein, dass Φ Fachwissen erfordert und sich schlecht verallgemeinern lässt. Erwarten Sie daher keinen universellen Detektor. Programmieraufgaben prüfen Test-Exit-Codes. Datenanalyseaufgaben prüfen, ob die Ausgabedatei entstanden ist. Nachrichtenaufgaben prüfen die API-Antwort. Diese Schicht wird schrittweise ausgebaut, Fähigkeit für Fähigkeit.
Ein von uns ergänztes Kriterium: Unumkehrbarkeit statt Wichtigkeit
Dieses steht nicht im Fachartikel.
Die Meilensteine von BEACON funktionieren, weil sie Zustandsübergänge markieren, die sich nicht zurückgehen lassen. Sobald Sie den Schlüssel haben, ist die Welt anders. Das Kriterium sollte deshalb lauten: Hat diese Aktion eine unumkehrbare externe Nebenwirkung erzeugt? statt War dieser Schritt wichtig?
Unumkehrbar: eine Datei schreiben, Code committen, eine Nachricht senden, eine kostenpflichtige API aufrufen, in eine Datenbank committen. Umkehrbar: eine Datei lesen, suchen, eine Seite abrufen, nachdenken.
Daraus folgen zwei Dinge. Es lässt sich mechanisch entscheiden, weil der Aktionstyp ausschlaggebend ist — kein semantisches Verständnis nötig, keine eingeschlichene Subjektivität nach dem Muster „Das Modell hielt diesen Schritt für wichtig“. Und es fällt mit Wiederherstellungspunkten zusammen: Das Fortsetzen an einer unumkehrbaren Grenze ist die einzige sinnvolle Art der Wiederaufnahme, denn umkehrbare Aktionen lassen sich einfach wiederholen.
Zwei Zahlen: eine zur Ermutigung, eine zur Vorsicht
Ermutigend ist das Experiment zum Leistungsabfall. Entfernt man zufällig die Hälfte der Meilensteine, liegt der Wert noch bei 82.8 gegenüber einer Baseline von 72.8 — zehn Punkte vorn. Der Abfall ist allmählich, kein Absturz. Für die Auslieferung ist das entscheidend: Φ muss nicht perfekt sein, bevor Sie es einschalten können. Schon die Hälfte abzudecken lohnt sich.
Zur Vorsicht mahnt der Vergleich der Aufteilungen.
| Aufteilung | Wert | gegenüber Baseline (72.8) |
|---|---|---|
| Zufällige Aufteilung in 5 Teile | 74.2 | +1.4 |
| Echte Meilensteine | 91.4 | +17.2 |
Die erste Notiz zitierte diese Zahlen ebenfalls, hier ist ihre Bedeutung aber unmittelbarer. Wenn Sie Meilensteine nach Intuition setzen, entsprechen sie ungefähr einer zufälligen Aufteilung, und die Arbeit ist verschwendet. Meilensteine sind genau dann wertvoll, wenn sie zur echten Aufgabenstruktur passen.
Wo Einschränkungen nötig sind
Der Anhang des Fachartikels selbst nennt die automatische Meilensteinerkennung als offenes Problem. Alle drei Benchmarks gewinnen ihre Meilensteine aus Regeln: Mustervergleich von Umgebungsantworten, Seitenwechsel oder ein direkt von der Umgebung geliefertes Signal. Wirklich offene Aufgaben — Browserbedienung, Refactoring von Codebasen, tiefgehende Recherche — haben keinen solchen fertigen, überprüfbaren Übergang.
Es ist also ein in strukturierten Umgebungen validiertes Paradigma, keine vollständig übernehmbare Lösung. Die strukturierte Grenze des Tool-Aufrufs macht es in einem Agentenprodukt nutzbar, nicht eine bereits vom Fachartikel gelieferte Antwort.
Die andere Falle ist die Granularität. Zu grob, und Sie haben nichts erreicht; zu fein, und das Signal auf Segmentebene wird zu Rauschen. Im Produkt entspricht das der Granularität der Aufgabenzerlegung. Hier gibt es einen Vorteil, der den Umgebungen des Fachartikels fehlt: Planschritte sind ausdrücklich für Nutzer sichtbar. Die Granularität kann sich daher daran orientieren, ob ein Mensch den Schritt versteht, statt rein algorithmisch abgestimmt zu werden.
Wenn Sie nur eine Sache tun
Setzen Sie Schicht zwei um.
Sie ist günstig, weil die Daten aus Schicht eins schon existieren und Schicht zwei sie nur mit den Aussagen des Modells abgleicht. Sie ist unabhängig überprüfbar, weil das Verhältnis verifizierter zu gemeldeten Abschlüssen selbst eine beobachtenswerte Kennzahl ist. Und sie ist die Voraussetzung für alles Weitere: Ohne Begriff eines verifizierten Meilensteins fehlt sowohl der Stillstandserkennung aus der ersten Notiz als auch der Verdichtungsgrenze aus der nächsten jede Grundlage.
Außerdem hat sie eine angenehme Eigenschaft: Ihre Auslieferung ändert kein Verhalten — das Modell meldet Schritte genau wie zuvor, es gibt nur eine zusätzliche Markierung. Sobald sich Daten angesammelt haben, können Sie entscheiden, ob Sie bei unbelegten Abschlussmeldungen eingreifen möchten.
Die nächste Notiz behandelt Kontextverdichtung: warum ein Schnitt an einem Token-Schwellenwert wenig damit zu tun hat, was gefahrlos vergessen werden kann, und eine Korrektur der naheliegendsten Fortführung dieser Notiz — der Annahme, dass nach der Verifizierung eines Meilensteins alles davor zusammengefaltet werden kann.