Ihr Agent erreicht 80% seines Kontextfensters. Die Komprimierung wird ausgelöst und verwirft die ältesten Gesprächsschritte. Zehn Minuten später liest er eine bereits gelesene Datei erneut und stellt eine schon beantwortete Frage noch einmal.
Der Schwellenwert wusste, dass der Platz knapp wurde. Er wusste nichts darüber, was gefahrlos verloren gehen durfte.
Dies ist die dritte Notiz einer Reihe über den Entwurf von Agenten für langfristige Aufgaben, angeregt durch die genaue Lektüre von BEACON (Zhejiang University, arXiv:2605.06078). Die erste behandelte Stillstandserkennung, die zweite das Meilensteindesign.
Ausgangspunkt: unsere eigene Implementierung
Orkas ist ein Multi-Agenten-Desktop-Client. Lange Aufgaben sind hier der Normalfall, deshalb kommt Komprimierung täglich vor. Unsere Implementierung reagiert auf einen Token-Schwellenwert und komprimiert, sobald der Kontext ungefähr 80% des Fensters erreicht. Bis wir dies aufschrieben, sah niemand von uns darin ein Problem.
In der Praxis gibt es ungefähr drei gängige Grenzen: einen Prozentsatz des Fensters, eine Anzahl von Gesprächsschritten oder eine vom Modell geschriebene Zusammenfassung der alten Inhalte. Unsere gehört zur ersten Art.
Die ersten beiden betrachten den Inhalt überhaupt nicht. Die dritte tut es, überlässt aber die gesamte Frage, was wichtig ist, dem Modell.
Alle drei beantworten Wann muss ich etwas wegwerfen? Die eigentliche Frage lautet Was kann ich gefahrlos wegwerfen? Ein Schnitt am Schwellenwert verwirft die ältesten Inhalte, nicht die unwichtigsten.
Die Meilensteingrenze und die Annahme dahinter
Die Meilensteine aus der vorherigen Notiz könnten eine bessere Grenze liefern als alle drei Ansätze. Doch hier liegt eine Falle, die der vorige Beitrag etwas zu glatt dargestellt hat.
BEACON enthält eine Annahme namens Markov-Eigenschaft von Meilensteinen. Einfach ausgedrückt: Sobald Sie einen Meilenstein erreichen, hängt das weitere Geschehen nur von den verbleibenden Teilzielen ab, nicht davon, wie Sie dorthin gelangt sind. Sobald Sie den Schlüssel haben, zählt, welche Tür Sie öffnen, nicht, wie Sie ihn gefunden haben.
Das klingt wie eine Erlaubnis zur Komprimierung: Nach einem Meilenstein kann der vorherige Abschnitt weggepackt werden.
Aber es ist eine Annahme, keine Tatsache. Das Paper schreibt ≈, nicht =, und die Autoren besprechen, wo sie versagt.
Ausreichend fürs Training, unzureichend für die Komprimierung
Dieselbe Annahme, zwei Anwendungen, eine Größenordnung Unterschied in der Strenge.
Im Training muss sie nur statistisch gelten. Verstoßen einige Dutzend von mehreren Tausend Rollouts dagegen, mittelt sich die Verzerrung heraus. Das Training nutzt darunter außerdem ein Signal auf Trajektorienebene als Absicherung; entfernt man diese Ebene, fällt ALFWorld von 91.4 auf 23.4 — weit unter den Wert ohne jede Maßnahme.
Bei der Komprimierung muss sie punktweise gelten, für genau den Lauf vor Ihnen. Einmal das Falsche verwerfen, und diese Aufgabe ist verloren. Es gibt nichts, worüber man mitteln könnte.
Dass das Paper sich auf diese Annahme stützt, bedeutet also nicht, dass Sie sie auf die Komprimierung übertragen können. Die beiden Anwendungen stellen unterschiedliche Anforderungen an sie.
Vier Fälle, in denen sie versagt
Wir verwenden diese Fälle als Checkliste, wenn wir über eine Komprimierungsstrategie nachdenken.
1. Unterwegs angesammeltes implizites Wissen. Irgendwo zu Beginn stellt ein Schritt fest, dass eine bestimmte API Zeitstempel in UTC zurückgibt. Das gehört zu keinem Meilenstein, wird aber in jedem folgenden Schritt benötigt.
2. Bereits verbrauchte Ressourcen. Tokenbudget, Aufrufkontingent, verbleibende Zeit. Ein Meilenstein erfasst nicht Ich habe 60% des Budgets verbraucht, aber diese Zahl entscheidet darüber, ob ein weiterer Versuch noch bezahlbar ist.
3. Pfadabhängige Nebenwirkungen. Der Meilenstein sagt Refaktorierung abgeschlossen. Sobald das Debugging beginnt, müssen Sie wissen, welche fünf Dateien tatsächlich angefasst wurden.
4. Der Meilenstein selbst ist unzureichend spezifiziert. Das ist der schlimmste der vier Fälle. Im Paper ist ein Meilenstein ein vollständiger Umgebungszustand — Sie haben den Schlüssel oder nicht, ohne Mehrdeutigkeit. Ein Planschritt ist ein Satz in natürlicher Sprache. „Datenbereinigung abschließen“ beschreibt bei Weitem nicht, was in diesem Abschnitt passiert ist.
Was stattdessen erhalten bleiben sollte
Bewahren Sie nicht nur eine Zusammenfassung auf. Eine Zusammenfassung schreibt das Modell, das nach Gefühl entscheidet, was wichtig war.
Bewahren Sie einen festen, von einem Menschen gewählten Satz von Feldern auf. Mindestens vier:
- Wie der Arbeitsbereich jetzt aussieht — welche Dateien verändert wurden und in welchen Zustand.
- Welches Budget übrig ist — Tokens, Aufrufkontingent, Zeit.
- Was festgestellt wurde — die UTC-Erkenntnis und alles Vergleichbare, das spätere Entscheidungen prägt.
- Was noch offen ist — das Problem, das einmal blockiert hat, umgangen wurde und zurückkommen könnte.
Vergleichen Sie das mit den vier Fehlerfällen oben: Sie entsprechen einander eins zu eins. Diese Zuordnung ist der einfachste Maßstab dafür, ob eine Komprimierungsstrategie ausreicht.
Die Hälfte davon ist fast kostenlos. Wie die vorige Notiz beschrieb, erfasst der Host bereits nach jedem Tool-Aufruf deterministische Fakten: ob eine Datei wirklich neu geschrieben wurde, ob ein Befehl tatsächlich lief. Diese Daten wurden zur Meilensteinprüfung gesammelt, aber sie sind die Momentaufnahme des Arbeitsbereichs. Die Komprimierung kann sie daher direkt übernehmen, ohne ein Modell erneut um eine Zusammenfassung zu bitten.
Die schwierige Hälfte sind die anderen beiden Punkte. Was festgestellt wurde und was noch offen ist, existiert derzeit nur, wenn das Modell es aufschreibt. Genau deshalb geht es bei der Komprimierung zuerst verloren.
Das lässt sich messen, nicht ausdiskutieren
Wenn der Agent nach der Komprimierung eine entfernte Datei erneut liest oder eine bereits beantwortete Frage erneut stellt, hat die Annahme bei dieser Aufgabe versagt, und der Beleg liegt direkt vor.
Die Instrumentierung ist einfach: Bilden Sie die Schnittmenge der nach dem Komprimierungspunkt gelesenen Dateipfade mit den zuvor erfassten.
Mit dieser Zahl wird die Frage, welche Aufgabenarten aggressiv komprimiert werden können und welche nicht, zu einer Abfrage statt zu einer Designdebatte. Es ist derselbe Ansatz wie in der ersten Notiz dieser Reihe: zuerst messen, dann etwas ändern.
Wo Einschränkungen nötig sind
Nichts davon ist ausgeliefert. Wir befinden uns bei Entwurf und Instrumentierung.
Welche Felder in welcher Detailtiefe erhalten bleiben sollten, muss sich aus Daten darüber ergeben, was tatsächlich erneut abgerufen wird. Jetzt zu entscheiden ist ein guter Weg, falsch zu entscheiden.
Und dies ist ein Ansatz unter mehreren. Wo die Grenze liegt und wie die Felder definiert sind, könnte bei einer anderen Produktform völlig anders aussehen. Die Checkliste mit vier Fällen lässt sich übertragen, die konkrete Antwort nicht.
Die nächste und letzte Notiz dieser Reihe behandelt Selbstreflexion: Warum die verdichteten Lehren eines Agenten immer wieder so allgemein ausfallen wie „vorsichtiger sein“ — und eine wirklich überraschende Erkenntnis darüber, was seine Eingaben enthalten und was nicht.