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

Dit onderzoek toont aan dat de persistentie van interpreter-estadoe tijdens het trainen van agenten een cruciale semantische eigenschap is die de efficiëntie en stabiliteit bepaalt, maar niet de uiteindelijke oplossingskwaliteit, en benadrukt dat trainingsdata moet worden afgestemd op de runtime-omgeving om kosten te verlagen en fouten te voorkomen.

De kern

Stel je voor dat je een slimme robotassistent (een AI-agent) aan het trainen bent om een complexe puzzel op te lossen, zoals het inpakken van een rugzak met waardevolle spullen. Deze robot kan niet alleen praten, maar ook Python-code schrijven om de rekenwerkjes te doen.

Het centrale vraagstuk van dit onderzoek is heel simpel: Hoe onthoudt de robot wat hij al heeft gedaan?

Er zijn twee manieren om dit te regelen:

1. De "Eeuwigdurende Geheugenbank" (Persistent): De robot werkt in een werkruimte waar alles wat hij schrijft (variabelen, lijsten, resultaten) blijft staan. Als hij in stap 1 een lijst maakt, is die in stap 10 nog steeds daar.
2. De "Vergeetachtige Werkbank" (Stateless): Na elke stap wordt de werkruimte volledig schoongeveegd. Alles wat de robot schreef, is weg. Hij moet in de volgende stap alles opnieuw uitleggen in zijn tekstbericht, alsof hij het voor het eerst doet.

De onderzoekers wilden weten: Is dit geheugen gewoon een hulpmiddel tijdens het werken, of is het iets wat de robot leert en meeneemt naar zijn toekomstige taken?

Het Experiment: De "Ondoorzichtige Rugzak"

Om dit te testen, bedachten ze een nieuwe puzzel: de Ondoorzichtige Rugzak.
Stel je voor dat je een rugzak moet vullen met de meeste waarde, maar je ziet de gewichten en waarden van de spullen niet. Je moet ze eerst "inspecteren" met een dure tool (die maar een beperkt aantal keer mag). Je moet dus slim plannen, inspecteren, en je resultaten onthouden.

Ze maakten twee soorten trainingsdata voor dezelfde robot (een model genaamd Qwen3-8B):

• Groep A leerde op basis van een eeuwigdurende werkbank. Hier mocht de robot gewoon doorgaan met zijn variabelen.
• Groep B leerde op basis van een vergeetachtige werkbank. Hier moest de robot in elke nieuwe stap zijn eerdere resultaten opnieuw uitschrijven in de tekst, omdat de werkbank leeg was.

Daarna testten ze deze robots in twee verschillende werelden:

1. Een wereld met een eeuwigdurende werkbank.
2. Een wereld met een vergeetachtige werkbank.

De Resultaten: De "Amnesie-taks" en de "Naamfouten"

Wat bleek? De manier waarop je de robot traint, bepaalt hoe hij werkt, zelfs als je hem later in een andere omgeving zet.

1. De "Amnesie-taks" (De dure prijs van vergeten)
Als je een robot traint die gewend is aan een vergeetachtige werkbank (Groep B), en je zet hem neer in een wereld waar het geheugen wel blijft staan, doet hij het nog steeds alsof hij alles moet herhalen.

• Analogie: Stel je voor dat je een kok traint in een keuken waar je na elke taak alle borden moet afwassen en de ingrediënten opnieuw moet tellen. Als je die kok daarna in een superkeuken zet waar de borden gewoon schoon blijven staan, zal hij toch blijven afwassen en opnieuw tellen. Hij doet het dubbel werk.
• Gevolg: Deze robots gebruiken ongeveer 3,5 keer meer "tokens" (rekenkracht en tijd) dan nodig is. Ze betalen een "amnesie-taks": ze vergeten wat ze al deden, terwijl het systeem het juist voor hen zou kunnen onthouden.

2. De "Naamfouten" (De crash bij verandering)
Als je een robot traint die gewend is aan een eeuwigdurende werkbank (Groep A), en je zet hem neer in een vergeetachtige wereld, gaat het mis.

• Analogie: Stel je voor dat je een chauffeur traint die gewend is aan een auto met een navigatiesysteem dat de route onthoudt. Als je hem dan in een auto zet zonder navigatie, blijft hij toch naar het scherm kijken en roepen: "Waar is de route?" terwijl de weg leeg is. Hij raakt in paniek en rijdt in cirkels.
• Gevolg: In ongeveer 80% van de gevallen probeert de robot variabelen te gebruiken die er niet zijn. Hij krijgt foutmeldingen (zoals "Naam niet gevonden"), probeert het opnieuw, krijgt weer een fout, en blijft hangen in een eindeloze lus van mislukkingen.

De Grootste Les

Het verrassende is: De kwaliteit van het eindresultaat was ongeveer hetzelfde. Of de robot nu 3,5 keer meer werk deed of in een cirkel liep, hij kon de puzzel vaak toch oplossen.

Maar de efficiëntie en stabiliteit waren enorm verschillend.

Wat betekent dit voor de toekomst?
De onderzoekers concluderen dat de "werkbank" (het geheugensysteem) niet zomaar een technisch detail is dat je achter de schermen regelt. Het is een gedragspatroon dat de robot leert tijdens zijn training.

Als je een AI-agent bouwt die in de echte wereld moet werken, moet je heel bewust kiezen:

• Wil je dat hij zijn werk onthoudt in het systeem? Dan moet je hem trainen met een systeem dat onthoudt.
• Wil je dat hij alles in tekst uitlegt? Dan moet je hem trainen met een systeem dat vergeet.

Als je deze twee niet op elkaar afstemt, krijg je een robot die ofwel onnodig veel werk doet (en geld kost), ofwel constant crasht. De "werkbank" is dus geen onzichtbare hulpmiddel, maar een essentieel onderdeel van wat de robot leert te zijn.

Technische samenvatting

Probleemstelling

Tool-geaugmenteerde Large Language Model (LLM) agents lossen taken op door natuurlijk taalredenering te combineren met uitvoerbare Python-acties in een interpreter. Veel agent-frameworks (zoals CodeAct) gebruiken een persistent interpreter, waarbij variabelen en datastructuren over meerdere interactierondes (turns) heen behouden blijven. Echter, de trainingsdata (traces) die worden gebruikt om deze modellen te finetunen, laten deze aanname van persistentie vaak impliciet of inconsistent na.

De kernvraag van dit onderzoek is: Is interpreter-persistentie slechts een runtime-scaffold (een hulpmiddel tijdens inferentie), of is het een eigenschap van de trainingsdata die bepaalt hoe agents leren om de interpreter te gebruiken?

Als persistentie een leerbaar gedrag is, kan er een misalignatie ontstaan wanneer een model is getraind op persistentie maar wordt ingezet in een stateless (toestandsloze) omgeving, of vice versa. Dit kan leiden tot inefficiëntie of stabiliteitsproblemen.

Methodologie

De auteurs voeren een gecontroleerde 2x2-studie uit om dit effect te isoleren. Ze kruisen twee trainingscondities met twee runtime-condities:

1. Trainingscondities: Finetuning op traces gegenereerd in een persistent interpreter versus een stateless interpreter.
2. Runtime-condities: Evaluatie van het getrainde model in een persistent versus een stateless interpreter.

De Taak: OPAQUE KNAPSACK
Om dit te testen, introduceren ze een nieuwe benchmark genaamd OPAQUE KNAPSACK. Dit is een variant van het klassieke knapsack-probleel met de volgende kenmerken:

• Deels waarneembaar (Partially Observable): Itemattributen (gewicht, waarde, klasse) en beperkingen zijn verborgen.
• Budget-gedreven: Agents moeten items inspecteren via een tool met een beperkt budget voordat ze ze kunnen selecteren.
• Niet-kollapsbaar: De taak kan niet in één script worden opgelost; het vereist iteratieve informatieverzameling, planning en state-handhaving over meerdere stappen.

Voor elke taakinstantie genereren ze twee identieke trajecten die alleen verschillen in hoe de interpreter omgaat met state:

• Persistent: Variabelen blijven levend tussen stappen.
• Stateless: De interpreter-state wordt na elke stap gereset; de agent moet state expliciet in tekst herleiden of opnieuw definiëren.

Ze finetunen identieke Qwen3-8B modellen op elk van deze trajecttypes en evalueren alle vier de combinaties (Persistent/Stateless Train × Persistent/Stateless Runtime).

Belangrijkste Bijdragen

1. OPAQUE KNAPSACK Benchmark: Een nieuwe, niet-kollapsbare benchmark met gepaarde trajecten die alleen de persistentie-contract variëren, terwijl taken, tools en supervisie constant worden gehouden.
2. Evidentie dat persistentie wordt geleerd: De studie toont aan dat interpreter-persistentie wordt opgenomen als een gedrags-prior tijdens post-training. Agents leren niet alleen wat ze moeten doen, maar ook hoe ze state moeten managen (in de interpreter vs. in de context).
3. Identificatie van specifieke faalmodi: De auteurs kwantificeren de kosten van misalignatie tussen training en runtime, waaronder "amnesie-taks" en cascade-fouten.

Resultaten

De resultaten tonen aan dat de uitlijning tussen trainingssemantiek en runtime cruciaal is voor efficiëntie en stabiliteit, hoewel de oplossingskwaliteit (oplossingskwaliteit) statistisch niet significant verschilt.

1. De "Amnesia Tax" (Stateless Train → Persistent Runtime)
Wanneer een model is getraind op stateless traces maar wordt ingezet in een persistent runtime:

• Het model herhaalt redundant state die de interpreter al kan bewaren.
• Het model gebruikt ongeveer 3,5x meer tokens dan een persistent-getraind model in dezelfde omgeving.
• Het model blijft state opnieuw importeren en herleiden, zelfs als de runtime state zou kunnen behouden. Dit is een geleerd gedrag, geen runtime-noodzaak.

2. Cascade-fouten en Instabiliteit (Persistent Train → Stateless Runtime)
Wanneer een model is getraind op persistentie maar wordt ingezet in een stateless runtime:

• Het model probeert variabelen te gebruiken die in eerdere stappen zijn gedefinieerd, maar die nu zijn gewist.
• Dit leidt tot NameError-uitzonderingen (ontbrekende variabelen) in ongeveer 80% van de episodes.
• Het model valt in cascade-herstelloops (recovery loops) die zijn tokenbudget verbruiken zonder vooruitgang te boeken, wat leidt tot instabiliteit en hoge foutdichtheid.

3. Efficiëntie vs. Kwaliteit

• Efficiëntie: De best presterende combinatie is Persistent Train + Persistent Runtime. Deze bereikt vergelijkbare oplossingskwaliteit als stateless-baselines maar gebruikt aanzienlijk minder tokens (ongeveer 1/3e van de kosten).
• Kwaliteit: Er is geen statistisch significant verschil in de kwaliteit van de gevonden oplossingen (normalized optimality) tussen de verschillende condities. De persistentie beïnvloedt hoe de oplossing wordt bereikt (efficiëntie en stabiliteit), niet of deze wordt bereikt.

Significantie en Conclusie

De studie concludeert dat interpreter-persistentie geen louter runtime-implementatiedetail is, maar een leerbare inductieve bias.

• Design Choice: De runtime die wordt gebruikt om trainingsdata te genereren, moet een expliciete ontwerpprincipes zijn. Als agents in een persistente omgeving worden ingezet, moeten ze ook op persistente traces worden getraind om de voordelen van compacte externe geheugen (variabelen) te benutten.
• Risico van Misalignatie: Het wisselen van runtime (bijv. van persistent naar stateless) zonder het model aan te passen, kan leiden tot catastrofale prestatiedalingen door leerprocessen die afhankelijk zijn van state die niet meer beschikbaar is.
• Token Volume is geen proxy: De studie waarschuwt dat meer tokens in trainingsdata (zoals bij stateless traces) niet per se leiden tot betere leerbaarheid; het kan juist leiden tot inefficiënte patronen die de agent "leert" te kopiëren.

Kortom: Agents leren hun runtime. De semantiek van de uitvoeringsomgeving tijdens het trainen vormt de strategie van de agent voor state-management, en deze strategie moet worden afgestemd op de productieruntime om maximale efficiëntie en stabiliteit te garanderen.