Agents Learn Their Runtime: Interpreter Persistence as Training-Time Semantics

Die Studie zeigt, dass die Persistenz von Interpreter-Zuständen während des Trainings die Effizienz und Stabilität von Agenten-LLMs maßgeblich beeinflusst, indem sie bei Nichtübereinstimmung mit der Laufzeitumgebung zu hohen Token-Kosten oder häufigen Fehlern führt, ohne die Lösungsqualität selbst zu verändern.

Das Wesentliche

Titel: Warum KI-Agenten ihre „Gedächtnis-Regeln" beim Lernen mitbekommen

Stell dir vor, du trainierst einen sehr klugen, aber etwas vergesslichen Assistenten, der komplexe Aufgaben löst, indem er Code schreibt und ausführt. Die Forscher aus diesem Papier haben eine spannende Frage gestellt: Muss dieser Assistent das „Gedächtnis" seines Computers (den Interpreter) erst beim eigentlichen Einsatz lernen, oder lernt er die Regeln dafür schon während des Trainings?

Die Antwort ist überraschend: Er lernt die Regeln beim Training. Wenn du ihn falsch trainierst, scheitert er später, egal wie gut er eigentlich ist.

Hier ist die Erklärung mit ein paar einfachen Analogien:

1. Das Szenario: Der Architekt und sein Bauplan

Stell dir den KI-Agenten als einen Architekten vor, der ein Haus bauen soll.

• Der Interpreter (die Arbeitsumgebung): Das ist die Baustelle.
• Die Variablen (der Code): Das sind die Materialien und Werkzeuge, die der Architekt benutzt.

Es gibt zwei Arten von Baustellen:

• Baustelle A (Persistierend): Alles, was du heute auf die Baustelle legst (z. B. einen Stapel Ziegel oder ein Werkzeug), bleibt dort liegen. Morgen kannst du es einfach wieder aufgreifen.
• Baustelle B (Zustandslos): Jeden Abend wird die Baustelle komplett geleert. Alles, was du heute gebaut hast, wird weggeräumt. Wenn du morgen weiterarbeiten willst, musst du dir alles, was du brauchst, neu beschreiben und neu aufbauen.

2. Das Experiment: Der „Undurchsichtige Rucksack"

Die Forscher haben ein Spiel namens „OPAQUE KNAPSACK" (Undurchsichtiger Rucksack) erfunden.

• Die Aufgabe: Du musst Gegenstände in einen Rucksack packen, um den höchsten Wert zu erreichen. Aber du kannst die Gegenstände nicht einfach ansehen. Du musst erst einen „Scanner" (ein Werkzeug) benutzen, um zu sehen, wie schwer und wertvoll sie sind.
• Das Problem: Du hast nur begrenzte Zeit und begrenzte Scans. Du musst also planen, scannen, entscheiden und dann den nächsten Schritt machen.

Die Forscher haben nun zwei Gruppen von KIs trainiert:

1. Gruppe A: Trainiert auf Baustelle A (wo alles bleibt).
2. Gruppe B: Trainiert auf Baustelle B (wo alles jeden Tag weggeräumt wird).

Dann haben sie sie in beiden Umgebungen getestet.

3. Die Ergebnisse: Was passiert, wenn die Regeln nicht passen?

Fall 1: Der „Amnesie-Tax" (Vergesslichkeit)

• Situation: Ein KI-Agent, der auf Baustelle B trainiert wurde (wo alles weggeräumt wird), arbeitet nun auf Baustelle A (wo alles bleibt).
• Das Verhalten: Der Agent ist so daran gewöhnt, dass er jedes Mal alles neu beschreiben muss. Er schreibt also in sein Notizbuch: „Ich habe gestern Ziegel gesammelt, also schreibe ich heute auf: Ziegel = 10 Stück."
• Das Ergebnis: Er verschwendet riesige Mengen an Platz und Zeit (Token), um Dinge neu zu schreiben, die eigentlich schon da sind. Die Forscher nennen das die „Amnesie-Steuer". Er ist ineffizient, aber er schafft die Aufgabe trotzdem.
• Analogie: Es ist wie ein Koch, der jeden Morgen das ganze Haus ausmietet und alle Zutaten neu einkauft, obwohl er in einem voll ausgestatteten Supermarkt arbeitet. Er kommt an, aber es kostet ihn ein Vermögen.

Fall 2: Der „Katastrophen-Loop" (Der Absturz)

• Situation: Ein KI-Agent, der auf Baustelle A trainiert wurde (wo alles bleibt), arbeitet nun auf Baustelle B (wo alles weggeräumt wird).
• Das Verhalten: Der Agent geht davon aus, dass seine Werkzeuge noch da sind. Er sagt: „Ich nehme den Hammer, den ich gestern gefunden habe." Aber auf Baustelle B ist der Hammer weg!
• Das Ergebnis: Der Agent bekommt einen Fehler („NameError: Hammer nicht gefunden"). Er versucht, den Fehler zu beheben, indem er den Hammer neu sucht, scheitert wieder, versucht es erneut und gerät in einen endlosen Kreislauf aus Fehlern. Er verbraucht sein ganzes Budget, ohne auch nur einen Schritt voranzukommen.
• Analogie: Stell dir vor, du fährst mit einem Auto, das so gebaut wurde, dass es immer auf einer Autobahn fährt. Plötzlich setzt du es auf eine Straße ohne Asphalt. Das Auto denkt immer noch, es könne Gas geben, aber die Räder drehen sich im Leeren. Es kracht in einen Kreislauf aus Panik und versucht, das Lenkrad zu reparieren, während es eigentlich nur die Straße wechseln müsste.

4. Die große Erkenntnis

Das Wichtigste an dieser Studie ist: Die Qualität der Lösung war in beiden Fällen fast gleich gut.

• Der „vergeßliche" Agent (Amnesie-Tax) hat das Haus gebaut, aber es hat ihn 3,5-mal so viel Zeit gekostet.
• Der „verwirrte" Agent (Katastrophen-Loop) hat das Haus gar nicht gebaut, weil er im Fehler-Loop stecken blieb.

Das Fazit für Entwickler:
Das „Gedächtnis" des Computers ist keine unsichtbare technische Detailsache, die man einfach so ändert. Es ist eine Regel, die der KI beim Lernen eingebrannt wird.

• Wenn du einen Agenten für eine Umgebung trainierst, in der Daten gespeichert bleiben, musst du ihn auch so trainieren.
• Wenn du ihn in einer Umgebung einsetzt, die alles vergisst, musst du ihn so trainieren, dass er alles neu schreibt.

Wenn du die Trainingsregeln und die Einsatzregeln nicht zusammenpasst, bekommst du entweder einen extrem ineffizienten Bot oder einen, der sofort abstürzt. Es ist wie beim Autofahren: Du kannst nicht einen Fahrer trainieren, der nur auf der Autobahn fährt, und ihn dann mitten in der Stadt losfahren lassen, ohne dass er verwirrt ist.

Kurz gesagt: Das Training bestimmt nicht nur, was die KI kann, sondern auch, wie sie denkt und wie sie mit ihrem Gedächtnis umgeht. Das Design der Trainingsumgebung ist also genauso wichtig wie die KI selbst.

Technische Zusammenfassung

1. Problemstellung

Tool-erweiterte Large Language Model (LLM) Agenten lösen Aufgaben zunehmend durch das Verknüpfen von natürlichsprachigem Denken mit ausführbaren Python-Aktionen in einer Interpreter-Umgebung. Viele Agenten-Frameworks nutzen einen persistenten Interpreter, bei dem Variablen und Datenstrukturen über mehrere Interaktionsschritte hinweg erhalten bleiben.

Das zentrale Problem, das dieses Paper adressiert, ist die oft implizite Annahme bezüglich der Laufzeit-Umgebung (Runtime) in den Trainingsdaten:

• Werden Agenten auf Trajektorien trainiert, die eine persistente Umgebung voraussetzen, aber in einer zustandslosen (stateless) Umgebung eingesetzt, oder umgekehrt?
• Ist die Persistenz des Interpreters nur eine Infrastruktur-Abstraktion zur Laufzeit, oder ist sie eine Lernpriorität, die während des Fine-Tunings verinnerlicht wird und das Verhalten des Agents prägt?

Die Autoren untersuchen, ob eine Fehlausrichtung zwischen Trainingsbedingungen und Laufzeitumgebung zu signifikanten Ineffizienzen oder Instabilitäten führt.

2. Methodik

Die Studie verwendet ein kontrolliertes 2 × 2-Experiment, das auf einer einzigen Aufgabenfamilie und einem Basis-Modell (Qwen3-8B) basiert.

A. Die Benchmark-Aufgabe: „Opaque Knapsack"

Die Autoren stellen eine neue, absichtlich nicht-kollabierbare (non-collapsible) Variante des Rucksackproblems vor:

• Partielle Beobachtbarkeit: Item-Attribute (Gewicht, Wert, Klasse) und Constraints sind versteckt.
• Budgetierte Werkzeugnutzung: Informationen können nur durch begrenzte „Inspection"-Werkzeugaufrufe abgerufen werden.
• Zwang zur Iteration: Da Constraints versteckt sind und Budgets begrenzt sind, kann die Aufgabe nicht durch ein einziges Skript gelöst werden. Sie erfordert iterative Informationsbeschaffung, Planrevision und Zustandsverwaltung über mehrere Schritte hinweg.

B. Experimental Design (2 × 2 Cross-Evaluation)

Für jede Instanz der Aufgabe wurden gepaarte Trajektorien generiert, die sich nur in der Behandlung des Interpreter-Zustands unterscheiden:

1. Persistente Ausführung (Persistent): Variablen bleiben über die Schritte hinweg erhalten.
2. Zustandslose Ausführung (Stateless): Der Interpreter-Zustand wird nach jedem Schritt zurückgesetzt; der Agent muss den Zustand im Text (Context Window) explizit neu ableiten.

Es wurden zwei Modelle feinabgestimmt (Fine-Tuning):

• Ein Modell trainiert auf persistenten Trajektorien.
• Ein Modell trainiert auf zustandslosen Trajektorien.

Beide Modelle wurden dann unter beiden Laufzeitbedingungen (persistent vs. zustandslos) evaluiert, was vier Bedingungen ergibt:

1. Persistent-Train / Persistent-Run (Ausgerichtet)
2. Stateless-Train / Stateless-Run (Ausgerichtet)
3. Persistent-Train / Stateless-Run (Fehlausrichtung)
4. Stateless-Train / Persistent-Run (Fehlausrichtung)

3. Wichtige Beiträge

1. OPAQUE KNAPSACK Benchmark: Eine neue Benchmark mit gepaarten Trajektorien, die ausschließlich die Persistenz-Contract variiert, während Aufgaben, Tools und Überwachung konstant bleiben. Dies erzwingt Multi-Turn-Control-Flow und iterative Zustandsrevision.
2. Nachweis des Gelernten: Die Studie zeigt, dass Interpreter-Persistenz keine reine Zero-Shot-Fähigkeit ist, sondern als verhaltensbezogene Priorität (behavioral prior) während des Fine-Tunings absorbiert wird.
3. Analyse von Fehlausrichtungen: Identifikation charakteristischer Fehlermodi, die auftreten, wenn Trainings- und Laufzeitsemantiken nicht übereinstimmen.

4. Ergebnisse

Die Ergebnisse zeigen, dass die Ausrichtung von Training und Laufzeit entscheidend für Effizienz und Stabilität ist, auch wenn die Lösungsqualität (Optimalität) statistisch ähnlich bleibt.

A. Effizienz und Token-Kosten („Amnesia Tax")

• Stateless-Train / Persistent-Run: Ein auf zustandslose Daten trainiertes Modell nutzt auch in einer persistenten Umgebung nicht die verfügbare Speicherfunktion. Es re-importiert Bibliotheken und leitet Zustände redundant im Text ab.
  • Ergebnis: Es verbraucht ca. 3,5-mal mehr Tokens als das auf Persistenz trainierte Modell, um die gleiche Lösung zu erreichen. Dies wird als „Amnesia Tax" (Amnesie-Steuer) bezeichnet.
• Persistent-Train / Persistent-Run: Das Modell nutzt den Interpreter-Speicher effektiv, was zu deutlich kürzeren Interaktionen und geringerem Token-Verbrauch führt.

B. Stabilität und Fehlermodi

• Persistent-Train / Stateless-Run: Dies führt zu katastrophalen Fehlern. Da das Modell erwartet, dass Variablen aus vorherigen Schritten existieren, treten in ca. 80 % der Episoden NameError-Ausnahmen (fehlende Variablen) auf.
  • Folge: Der Agent gerät in kaskadierende Wiederherstellungsschleifen (recovery loops), die das Token-Budget verbrauchen, ohne Fortschritt zu machen.
• Stateless-Train / Stateless-Run: Das Modell ist robust, da es den Zustand explizit im Text neu ableitet, was jedoch ineffizient ist.

C. Lösungsqualität

Interessanterweise führt die Fehlausrichtung nicht zu einer statistisch signifikanten Verschlechterung der Lösungsqualität (Normalisierte Optimalität). Der Agent findet die Lösung oft trotzdem, aber der Weg dorthin ist entweder extrem ineffizient (hoher Token-Verbrauch) oder instabil (Fehlerketten).

5. Bedeutung und Schlussfolgerung

Das Paper widerlegt die Annahme, dass Interpreter-Persistenz nur eine Laufzeit-Infrastruktur sei. Stattdessen ist sie ein lernbares Merkmal der Trainingsdaten.

• Design-Entscheidung: Die Wahl der Laufzeit-Semantik (persistent vs. zustandslos) beim Generieren von Fine-Tuning-Daten muss eine explizite Design-Entscheidung sein und darf keine versteckte Implementierungsdetail sein.
• Risiko der Fehlausrichtung: Ein Wechsel der Laufzeitumgebung nach dem Training (z. B. von einem Framework mit persistenter Session zu einem zustandslosen) kann die Stabilität des Agents gefährden und die Kosten drastisch erhöhen, ohne dass die Modellgewichte geändert werden.
• Empfehlung: Agenten-Entwickler sollten Fine-Tuning-Trajektorien generieren, die exakt die Semantik der Ziel-Laufzeitumgebung widerspiegeln, um effiziente und stabile Agenten zu erhalten.

Zusammenfassend zeigt die Arbeit, dass Agenten nicht nur was sie tun lernen, sondern auch wie sie es tun, basierend auf den impliziten Annahmen über ihre Ausführungsumgebung in den Trainingsdaten.