🤖 AI

Context as an Environment: Programmatic Context Management for Long-Horizon Agents

Das Paper stellt Scroll vor, ein programmatisches Kontextmanagementsystem, das Agenten-Sessions als ausführbare Umgebungen mit einem unveränderlichen Event-Log und einem persistenten Python-Kernel behandelt, wodurch LLMs in der Lage sind, den Langzeit-Zustand dynamisch durch Code zu verwalten und gleichzeitig Spitzenleistungen bei Long-Context-Benchmarks zu erzielen.

Ursprüngliche Autoren: Yin Lin, Elaine Ang, Erkang Zhu, Bolin Ding, Jingren Zhou

Veröffentlicht 2026-08-25

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Yin Lin, Elaine Ang, Erkang Zhu, Bolin Ding, Jingren Zhou

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich ein Gespräch vor, das niemals endet. Sie sprechen mit einem sehr intelligenten Computerprogramm, das Ihnen helfen kann, Code zu schreiben, komplexe Reisen zu planen oder tiefgründige Themen zu recherchieren. Zu Beginn ist das Gespräch einfach. Das Programm erinnert sich an alles, was Sie in den letzten Minuten gesagt haben. Doch wenn sich das Gespräch über Stunden oder Tage hinweg ausdehnt, wächst die Menge der Informationen. Schließlich wird es zu viel für das Programm, um es im unmittelbaren Gedächtnis zu behalten. In der Welt der künstlichen Intelligenz wird dieses unmittelbare Gedächtnis als Kontextfenster bezeichnet. Es hat eine feste Größe, wie ein Schreibtisch, der nur eine bestimmte Anzahl an Papieren halten kann. Wenn der Stapel an Papieren zu hoch wird, muss das Programm einige wegwerfen, um Platz für neue zu schaffen.

Das Problem ist, dass das Programm nicht weiß, welche Papiere wichtig sind, bevor es zu spät ist. Wenn Sie eine Frage zu etwas stellen, das Sie vor drei Tagen erwähnt haben, hat das Programm dieses Papier vielleicht schon entsorgt. Traditionelle Lösungen versuchen, dies zu lösen, indem sie die alten Papiere in einer kurzen Notiz zusammenfassen oder einige Fakten in einem separaten Notizbuch festhalten. Aber diese Methoden sind riskant. Wenn das Programm ein spezifisches Detail, wie ein Datum oder eine Zahl, wegwirft, ist dieses Detail für immer verloren. Es kann nicht wiederhergestellt werden. Für Aufgaben, die erfordern, auf eine lange Historie zurückzublicken, um exakte Fakten zu finden oder zu verfolgen, wie sich eine Situation im Laufe der Zeit verändert hat, kann der Verlust auch eines einzigen Details dazu führen, dass das Programm scheitert.

Ein Team von Forschern hat einen anderen Weg vorgeschlagen, um mit solch wachsenden Gesprächen umzugehen. Sie nennen ihr System Scroll. Anstatt zu versuchen, die gesamte Historie in das unmittelbare Gedächtnis des Programms zu quetschen, behandeln sie die Historie als eine separate, permanente Umgebung, die das Programm besuchen kann, wann immer es muss. Denken Sie an ein riesiges, organisiertes Archiv, das sich direkt außerhalb des Schreibtisches des Programms befindet. Das Programm liest das Archiv nicht auf einmal. Stattdessen schreibt es eine kleine Anweisung, wie eine Suchanfrage oder ein Befehl, um in das Archiv zu gehen, die spezifische Seite zu finden, die es benötigt, und gerade diese eine Seite zurück zum Schreibtisch zu bringen.

Der Kern dieses Systems ist ein permanentes Protokoll jeder einzelnen Interaktion, das Event Log. Dieses Log ist wie ein Tonbandgerät, das niemals aufhört aufzunehmen und jede Nachricht, jedes Werkzeugergebnis und jede Entscheidung in exakter Detailtreue erfasst. Es wird sicher außerhalb des unmittelbaren Gedächtnisses des Programms gespeichert, sodass nichts verloren geht. Neben diesem Log gibt es einen persistenten Arbeitsbereich, eine Art digitale Sandbox, in der das Programm seine aktuellen Gedanken und Berechnungen aufbewahren kann. Wenn das Programm sich an etwas aus der Vergangenheit erinnern muss, verlässt es sich nicht auf eine Zusammenfassung. Es schreibt ein Stück Code, um das Event Log zu durchsuchen, den exakten Moment zu finden, nach dem es sucht, und diese Information in seinen Arbeitsbereich zu laden.

Dieser Ansatz verändert die Art und Weise, wie das Programm über sein eigenes Gedächtnis nachdenkt. Anstatt zu raten, was es behalten soll, entscheidet das Programm in dem Moment, in dem es benötigt wird, was es nachschlagen muss. Wenn das Programm eine Reise plant und sich an eine Vorliebe erinnern muss, die der Nutzer vor Wochen erwähnt hat, schreibt es einen Befehl, um nach dieser spezifischen Vorliebe zu suchen. Es lädt dann die exakten Worte, die der Nutzer verwendet hat, und nutzt sie, um eine Entscheidung zu treffen. Das Programm bringt nur die notwendigen Informationen in seine unmittelbare Sichtweite. Der Rest der Gesprächshistorie bleibt sicher im Archiv gespeichert, bereit, abgerufen zu werden, falls das Programm ihn später benötigt.

Um zu verhindern, dass die unmittelbare Sicht zu voll wird, hat das System eine Möglichkeit, alte Informationen, die derzeit nicht verwendet werden, auszusortieren. Wenn der Arbeitsbereich zu voll wird, verschiebt das System die ältesten Teile des Gesprächs zurück in das Archiv. Das System erstellt jedoch im Gegensatz zu anderen Systemen, die diese alten Teile löschen oder zusammenfassen würden, keine Vereinfachungen, sondern bewahrt sie exakt so auf, wie sie sind. Es erstellt eine kleine Karte, einen Index, der dem Programm genau sagt, wo diese alten Teile im Archiv gespeichert sind. Wenn das Programm später merkt, dass es ein altes Gespräch überprüfen muss, kann es diese Karte nutzen, um direkt zur richtigen Stelle zu springen und den Originaltext abzurufen. Dies stellt sicher, dass das Programm immer zur Quelle zurückkehren kann, selbst wenn die Information nicht mehr in seiner unmittelbaren Sicht liegt.

Die Forscher testeten dieses System bei mehreren schwierigen Herausforderungen, die darauf ausgelegt waren, zu sehen, wie gut eine künstliche Intelligenz mit langen Gesprächen umgehen kann. In einem Test musste das System Fragen beantworten, die auf einer Historie von über einer Million Wörtern basierten. In einem anderen Test musste es als Agent agieren, der Entscheidungen über einen langen Zeitraum trifft und Werkzeuge nutzt, um Informationen zu sammeln und Probleme zu lösen. Die Ergebnisse zeigten, dass diese neue Methode äußerst effektiv war. In einem Test, der maß, wie gut das System über lange Historien erinnern und schlussfolgern konnte, erreichte es eine Punktzahl von 94,8 Prozent. In einem anderen Test, der eine Historie von zehn Millionen Wörtern beinhaltete, erreichte es 73,1 Prozent, was höher war als bei jedem zuvor veröffentlichten System. In einem Test, bei dem das System eine wachsende Umgebung verwalten musste, während es komplexe Aufgaben löste, erreichte es 86,7 Prozent und übertraf damit die besten bisherigen Ergebnisse bei weitem.

Der Erfolg dieses Systems beruht auf seiner Fähigkeit, das Gedächtnis als eine Programmieraufgabe zu behandeln. Indem es dem Programm ermöglicht, seine eigenen Anweisungen für das Finden und Nutzen von Informationen zu schreiben, nutzt das System die wachsende Fähigkeit des Programms, Code zu schreiben. Es zwingt das Programm nicht, seine Historie in eine Zusammenfassung zu komprimieren, die wichtige Details verlieren könnte. Stattdessen gibt es dem Programm die Werkzeuge, um jederzeit auf die vollständige, uneditierte Historie zuzugreifen, wenn es nötig ist. Die Forscher fanden heraus, dass diese Methode bei verschiedenen Arten leistungsstarker Programme gut funktioniert, was darauf hindeutet, dass die Fähigkeit, das Langzeitgedächtnis durch Code zu verwalten, eine allgemeine Fertigkeit ist, die von verschiedenen Systemen erlernt werden kann.

Diese Arbeit deutet auf einen Wandel in der Art und Weise hin, wie wir intelligente Agenten bauen. Anstatt zu versuchen, das unmittelbare Gedächtnis des Programms größer oder besser beim Zusammenfassen zu machen, können wir ihm Zugang zu einem permanenten, durchsuchbaren Protokoll seines eigenen Lebens geben. Das Programm lernt, dieses Protokoll zu navigieren und zu entscheiden, was es nach vorne holt und was es zurücklässt. Dies hält die unmittelbare Sicht klar und fokussiert, während gleichzeitig sichergestellt wird, dass die volle Wahrheit der Vergangenheit immer verfügbar ist. Die Forscher glauben, dass dieser Ansatz der künstlichen Intelligenz helfen könnte, in Zukunft noch längere und komplexere Aufgaben zu bewältigen, indem er es ermöglicht, aus einer viel tieferen Historie zu lernen, ohne die Details zu verlieren, die zählen.

Technisches Resümee: Scroll – Programmatisches Kontextmanagement für Langzeit-Agenten

1. Problemformulierung

Langzeitaufgaben für Large Language Model (LLM) Agenten – wie etwa die Softwareentwicklung auf Repository-Ebene oder tiefgehende Web-Recherche – erzeugen Interaktionsverläufe, die das Kontextfenster eines einzelnen Modells bei weitem übersteigen. Bestehende Lösungen verlassen sich primär auf Kontextkompression (das Abschneiden, Zusammenfassen oder Verwerfen veralteter Abschnitte) oder externes Gedächtnis (das Extrahieren von Fakten in einen separaten Speicher). Beide Ansätze sind fundamental verlustbehaftet: Sie legen fest, welche Informationen bewahrt werden sollen, bevor zukünftige Bedürfnisse bekannt sind. Folglich wird eine Information, falls die Zusammenfassung ein spezifisches Detail nicht erfasst oder eine Extraktion eine Nuance übersieht, unwiederbringlich verloren gehen, selbst wenn das Rohprotokoll auf der Festplatte existiert. Diese Einschränkung hindert Agenten daran, exakte historische Vergleiche oder nicht-triviale Berechnungen über vergangene Ereignisse durchzuführen, bei denen die benötigten Informationen im Voraus nicht bekannt sind.

2. Methodik: Das Scroll-Framework

Das Paper stellt Scroll vor, ein Kontextmanagement-System, das den Sitzungsverlauf nicht als Text betrachtet, der in Prompts serialisiert werden muss, sondern als eine ausführbare Sitzungsumgebung (Session Environment). Diese Umgebung ermöglicht es dem Agenten, programmatisch mit seinem eigenen Verlauf zu interagieren.

Kernkomponenten

Append-Only Event Log ( $L_t$ ): Ein dauerhafter, wahrheitsgetreuer Datensatz aller Interaktionen (Nutzer-Nachrichten, Modell-Antworten, Tool-Aufrufe, Ergebnisse). Jedem Ereignis wird eine unveränderliche, monoton steigende Sequenzadresse (seq) zugewiesen. Das Log wird in SQLite gespeichert und nutzt BM25 für die deterministische Volltextsuche anstelle von Embeddings.
Dauerhafter Speicher ( $P_t$ ): Rohdaten (z. B. vollständige Tool-Outputs, Artefakte) werden extern gespeichert (JSON, Dateisystem) und über verzögerte Handles (deferred handles) vom Event Log referenziert. Dies stellt sicher, dass das Event Log leichtgewichtig bleibt, während die volle Treue (Fidelity) gewahrt bleibt.
Persistenter Python-Kernel ( $V_t$ ): Ein sandboxgestützter Python-Kernel bleibt über Modellaufrufe hinweg bestehen. Er verwaltet einen typisierten Namensraum von residenten Variablen (Python-Objekte, DataFrames, verzögerte Handles). Entscheidend ist, dass Zwischenberechnungen und Tool-Ergebnisse in diesem Kernel verbleiben und nicht in den Prompt serialisiert werden, sofern dies nicht explizit angefordert wird.

Programmatische Schnittstelle

Das Modell konstruiert seinen Kontext, indem es Code schreibt, der innerhalb des persistenten Kernels ausgeführt wird. Die Schnittstelle, die über ein Capability-Objekt ms bereitgestellt wird, unterteilt die Kontextkonstruktion in vier Operationen:

LOCATE: ms.search(query, k, ...) findet Kandidaten-Datensätze im Event Log mittels Volltextsuche und strukturierter Filter und gibt stabile seq-Adressen zurück.
MATERIALIZE: ms.expand(seq) stellt exakte Turns oder Abschnitte wieder her und lädt externe Payloads als Python-Objekte.
COMPUTE: Das Modell führt Filterung, Joins, Aggregationen und Ableitungen unter Verwendung von Standard-Python und erlaubten Datenbank-Schnittstellen auf residenten Variablen durch.
EXPOSE: print(value) ist der einzige Mechanismus, der die Grenze zum Arbeitsbereich des Modells überschreitet. Nur explizit ausgegebene Projektionen gelangen in den nächsten Modellkontext.

Eviktierung und Navigation

Wenn der Arbeitsbereich das Token-Budget erreicht, nutzt Scroll ein Eviktierungsverfahren, das veraltete Abschnitte aus der Ansicht (View) entfernt, aber niemals aus dem Event Log.

Wiederherstellbarkeit: Eviktierte Ereignisse bleiben unverändert im Event Log erhalten.
Eviktierungs-Index: Um eine Volltextsuche im gesamten Log zu vermeiden, pflegt Scroll einen gestuften Index von „Schlagzeilen“ (Task, State, Next Action) für eviktierte Abschnitte. Dieser Index ermöglicht es dem Agenten, direkt zu evikierten Regionen zu navigieren, indem er Adressanker nutzt, wobei ältere Einträge zu gröberen Bereichen zusammengefasst werden, um eine Komplexität von $O(k \log k n)$ aufrechtzuerhalten.

3. Zentrale Beiträge

Das Paper leistet drei wesentliche Beiträge:

Deferred Selection Policy: Im Gegensatz zu bestehenden Methoden, die die Kontext-Map festlegen, bevor zukünftige Bedürfnisse bekannt sind, verschiebt Scroll die Auswahl der Arbeitsansicht auf den Abfragezeitpunkt (Query Time). Das Modell schreibt zu jedem Schritt ein Programm $\pi_t$ , um zu entscheiden, was abgerufen, berechnet und exponiert werden soll.
Ausführbarer Kontext-Substrat: Die Implementierung eines persistenten, sandboxed Python-Kernels kombiniert mit einem Append-Only Event Log. Dies verschiebt das Kontextmanagement von der Textverarbeitung hin zum Programmieren und nutzt die Codierungsfähigkeiten des LLMs, um Kontext dynamisch zu suchen, zu transformieren und zu materialisieren.
Verlustloser Navigationsalgorithmus: Ein Eviktierungsmechanismus, der die Arbeitsansicht begrenzt, ohne den Verlauf zu verlieren. Eviktierte Abschnitte bleiben intakt und werden durch kompakte, adressbasierte Einträge indiziert, was es dem Agenten ermöglicht, direkt zu evikierten Regionen zu navigieren, anstatt das gesamte Log zu durchsuchen.

4. Experimentelle Ergebnisse

Die Autoren evaluierten Scroll unter Verwendung von Qwen3.8-Max als Backbone über drei Benchmarks:

LongMemEvalS (Langzeitgedächtnis-Retrieval): Scroll erreichte eine Genauigkeit von 94,8 % und arbeitete wettbewerbsfähig mit State-of-the-Art-Systemen.
BEAM10M (10M Token Verlauf): Scroll erreichte 73,1 % und übertraf damit das beste veröffentlichte Gedächtnissystem um 5,1 Punkte. Es zeichnete sich besonders in Kategorien aus, die exakte historische Belege erfordern, wie Wissensaktualisierung (92,5 %) und Widerspruchsauflösung (88,1 %), bei denen verlustbehaftete Zusammenfassungen typischerweise scheitern.
LOCA256K (Langzeit-Handeln): Scroll erreichte eine Genauigkeit von 86,7 %. Im direkten Vergleich mit anderen Kontextmanagement-Strategien unter Verwendung desselben Backbones demonstrierte Scroll eine überlegene Stabilität mit zunehmendem Kontext, mit einem Rückgang von nur 2,6 % von 128K auf 256K Tokens, verglichen mit Rückgängen von ca. 21 % bei Summarization- und Retrieval-Agenten.

Ablationsstudien bestätigten, dass das verlustfreie Event Log entscheidend ist (das Entfernen führte zu einem Abfall auf ~20 % bei BEAM10M), der persistente Kernel die Leistung durch die Ermöglichung von In-Kernel-Aggregationen um 7,3 Punkte verbessert und der Eviktierungs-Index durch die Unterstützung der Navigation in verstreuten Verläufen einen Gewinn von 1,8 Punkten liefert.

Kosteneffizienz: Scroll setzt nur einen Bruchteil des Korpus für das Modell frei. Bei BEAM10M betrug die mediane Input-Token-Anzahl ~105K (ca. 1 % des Korpus), wobei die Output-Tokens um eine Größenordnung kleiner waren.

5. Bedeutung und Ansprüche

Das Paper behauptt, dass Scroll das Kontextmanagement grundlegend von einem Kompressionsproblem zu einer Programmieraufgabe verändert. Indem die Sitzung als ausführbare Umgebung behandelt wird, erbt der Agent die sich verbessernden Codierungsfähigkeiten von LLMs, um seinen eigenen Kontext dynamisch zu verwalten.

Die Autoren betonen, dass Scroll nicht diktiert, welchen Zustand man behalten soll oder wie man den Retrieval-Code schreibt; diese Entscheidungen werden dem Modell überlassen. Diese Flexibilität ermöglicht es dem System, mit den Fähigkeiten des Modells zu skalieren. Das Paper legt nahe, dass erfolgreiche Trajektorien von Frontier-Modellen auf kleinere Modelle via Supervised Fine-Tuning destilliert werden können, während die zugrunde liegenden Kontextmechanismen unverändert bleiben.

Die Arbeit postuliert, dass für Langzeitaufgaben, die exakte historische Belege oder komplexe Berechnungen über vergangene Ereignisse erfordern, der verlustfreie Abruf via programmatischem Zugriff einem präkomprimierten Zusammenfassungs- oder Fixed-Memory-Ansatz überlegen ist, da er die inhärente, unwiederbringliche Informationsverlust-Problematik aktueller Kompressionsparadigmen vermeidet.