FlowState: Preprint will Agentengedächtnis aus dem Ausführungszustand bauen

FlowState: Agentengedächtnis aus dem Ausführungszustand soll Tokens sparen und Erfolgsrate heben

Das Preprint „FlowState: Execution State as Memory for Long-Horizon LLM Agents“ schlägt vor, den Ausführungszustand eines LLM-Agenten als Gedächtnis zu nutzen. Dieses Gedächtnis soll über einzelne Anfragen hinweg erhalten bleiben und sich bei Bedarf wieder abrufen lassen. Als Autoren nennt das Verzeichnis memorypapers.org „Minghao Li, Bangyan Li et al.“ (arXiv, 2026). Eine Institution geht aus dem Material nicht hervor.

Die Autoren begründen den Ansatz mit einem Zielkonflikt. Eine vollständige Historie treibt die Kontextkosten nach oben. Kompression spart dagegen Platz, kann aber Details verlieren, die später gebraucht werden. Außerdem zeigt sich die Relevanz früherer Informationen oft erst im Verlauf der Aufgabe.

Nach Angaben der Autoren steigt die durchschnittliche Erfolgsrate auf MemoryArena gegenüber einer Full-Context-Baseline mit DeepSeek-V4-Flash um 4,55 Prozentpunkte. Der Gesamtverbrauch an Tokens sinkt um 43,2 Prozent. Der Abstract nennt außerdem einen weiteren Durchschnittswert auf einem zweiten Benchmark. Im vorliegenden Auszug ist dieser abgeschnitten, eine Zahl liegt also nicht vor.

Typisierte Knoten, ISU und PSA: So soll der Zustandsspeicher arbeiten

FlowState bewahrt semantisch typisierte Zustandsknoten, deren Relationen und Verweise auf rohe Tool-Beobachtungen. Dauerhafte Speicherung und Zugriff bei Bedarf sind getrennt. Was gespeichert ist, wandert nicht automatisch in den Kontext des Modells.

Dafür sorgen zwei Mechanismen. Das Incremental State Update (ISU) pflegt den aktuellen Zustand anhand neuer Eingaben und Rückmeldungen. Das Progressive State Access (PSA) legt historische Zustände und stützende Belege während des Schlussfolgerns schrittweise offen, und zwar erst dann, wenn sie gebraucht werden. Beide laufen in einer einzigen Ausführungsschleife.

Laut Paper-Verzeichnis besteht die Architektur aus einem Persistent State Repository, einem Historical State Index und einem Active State. ISU und PSA koordinieren diese Teile. Die Autoren behaupten, die Mechanismen erlaubten es Agenten, frühere Entscheidungen im Licht neuer Informationen neu zu bewerten und Folgehandlungen entsprechend zu steuern. Das ist eine Herstellerangabe. Überprüfen lässt sie sich nur anhand der Ablationsstudien und Fehleranalysen im Volltext sowie durch unabhängige Replikation auf MemoryArena und weiteren Benchmarks.

Nur Selbstauskunft der Autoren: Replikation fehlt, dev.to-Text weicht ab

Alle genannten Zahlen stammen aus der Selbstberichterstattung der Autoren. Eine unabhängige Einordnung oder Replikation gibt es bislang nicht.

Ein dev.to-Beitrag beschreibt FlowState anders: als versionierten Graphen aus Variablen, Tool-Ausgaben und Kontrollfluss-Flags, mit Checkpoints nach relevanten Tool-Aufrufen, Snapshot-Replay und Audit-Trail. Der Beitrag zitiert das Paper nicht. Er erwähnt weder ISU noch PSA, auch keine Benchmarks. Stattdessen stützt er sich auf eine unbelegte Zahl von 32 Prozent, die einem „Stanford LLM Lab“ zugeschrieben wird. Als Quelle für die Methode taugt er deshalb nicht. Maßgeblich bleibt die Beschreibung im Paper. Woher die Abweichung rührt, ist nicht abschließend geklärt.

Offen bleibt, wem der Ansatz nützt. Entwickler langlaufender Agenten und Betreiber mit hohen Tokenkosten könnten profitieren, falls sich die Ersparnis bestätigt. Ob sich der Umstieg auf einen strukturierten Zustandsspeicher in der Praxis lohnt, belegt das vorliegende Material nicht.