🤖 AI

Stop Comparing LLM Agents Without Disclosing the Harness

Dit position paper betoogt dat voor taken met een lange horizon de agent-uitvoeringsharness vaak een sterkere determinant van prestaties is dan het onderliggende taalmodel, en dringt er bij de gemeenschap op aan harness-bewuste evaluatieprotocollen te adopteren om te voorkomen dat winst door infrastructuur systematisch wordt toegeschreven aan modelverbeteringen.

Oorspronkelijke auteurs: Yunbei Zhang, Janet Wang, Yingqiang Ge, Weijie Xu, Jihun Hamm, Chandan K. Reddy

Gepubliceerd 2026-05-26

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Yunbei Zhang, Janet Wang, Yingqiang Ge, Weijie Xu, Jihun Hamm, Chandan K. Reddy

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

De Kernidee: Het Is Niet Alleen de Motor, Het Is de Auto

Stel je voor dat je probeert te beoordelen welke automotor de beste is. Je plaatst een Ferrari-motor in een roestige, kapotte sedan met platte banden en een stuurwiel dat niet werkt. Vervolgens plaats je een iets minder krachtige motor in een gloednieuwe, high-tech raceauto met perfecte banden en een GPS-navigatiesysteem.

Als de tweede auto de race wint, heeft hij dan gewonnen omdat de motor beter was? Nee. Hij won omdat de auto (het chassis, de banden, de navigatie) beter was.

Dit paper betoogt dat we momenteel precies deze fout maken met AI.

Wanneer we AI-"agenten" (AI-programma's die taken kunnen uitvoeren zoals het schrijven van code of het oplossen van softwarebugs) testen, kijken we meestal naar één enkele score en zeggen we: "Wauw, Model A is beter dan Model B." De auteurs stellen dat dit misleidend is. Zij betogen dat voor complexe, langetermijntaken de score veel meer afhangt van de "harnas" (de software-infrastructuur rondom de AI) dan van het AI-model zelf.

De "Harnas": Het Lichaam en Zenuwstelsel van de AI

Het paper noemt de infrastructuur het "harnas". Stel je het AI-model (het "brein") voor als een piloot. Het harnas is dan de cockpit, het autopilotsysteem, de brandstofmeter en de communicatieradio.

Het Model (Het Brein): Het is slechts het deel dat denkt en tekst genereert. Het is "open-loop", wat betekent dat het gewoon een antwoord uitstoot en wacht op de volgende prompt. Het weet niet of het een fout heeft gemaakt totdat iemand het dat vertelt.
Het Harnas (De Controller): Dit is de softwarelaag die:
- Beslist welke informatie aan de AI wordt getoond (Context).
- Controleert of het antwoord van de AI logisch is (Verificatie).
- De AI vertelt om het opnieuw te proberen als het faalt (Retry-logica).
- Voorkomt dat de AI in de war raakt door te veel informatie (Geheugenbeheer).

Het paper stelt dat voor lange, moeilijke taken het harnas de "bindende beperking" is. Dit betekent dat het harnas de bottleneck vormt. Als het harnas slecht is, zal zelfs de slimste AI falen. Als het harnas geweldig is, kan een iets minder slimme AI slagen.

De "Bindende Beperkingsthese"

De auteurs stellen een theorie voor die de Bindende Beperkingsthese heet. In gewone taal zegt deze:

"Wanneer we top-tier AI-modellen vergelijken op moeilijke, lange taken, wordt het verschil in hun scores meer veroorzaakt door hoe het harnas is gebouwd dan door welk model wordt gebruikt."

Ze ontdekten dat het veranderen van het harnas een score met 15 procentpunten kan laten schommelen, terwijl het veranderen van het model de score meestal slechts met 2 tot 4 punten verandert.

De Analogie: Stel je twee hardlopers voor. De ene is een olympische sprinter (Model A) en de andere is een zeer fit amateur (Model B).

Als je de olympische sprinter in modderige laarzen steekt en een zware rugzak geeft (Slecht Harnas), kan hij verliezen van de amateur die loopt in perfecte schoenen (Goed Harnas).
Het paper stelt dat huidige leaderboards zijn als een race waarbij iedereen verschillende schoenen draagt, maar we alleen rapporteren wie heeft gewonnen, terwijl we de schoenen negeren.

Waarom Huidige Leaderboards "Onvolledig" Zijn

Op dit moment doen benchmarks (zoals SWE-bench of Terminal-Bench) alsof ze alleen het "brein" testen. Maar in werkelijkheid testen ze het Brein + Het Harnas.

Omdat onderzoekers zelden precies publiceren hoe ze hun harnas hebben gebouwd (het "recept" voor de cockpit), kunnen we niet zeggen of een model werkelijk slimmer is of dat het team gewoon een beter harnas eromheen heeft gebouwd.

Het Bewijs uit het Paper:

Voorbeelden uit de echte wereld: Ze toonden aan dat hetzelfde AI-model (Claude Opus) een score van 45,9% behaalde met het ene harnas en 55,4% met het andere. Dat is een enorme sprong alleen door de software-wrapper te veranderen, niet het model.
Gecontroleerd Experiment: Ze namen drie verschillende top-tier modellen en voerden ze uit via drie verschillende harnassen (Minimaal, Verbeterd en Volledig).
- Resultaat: Het veranderen van het harnas veranderde de scores veel meer dan het veranderen van het model.
- De Twist: Soms won een "slechter" model met een "beter" harnas van een "beter" model met een "slechter" harnas. De ranglijten draaiden om!

De Oplossing: "Openbaarmaking" en "Variantiedecompositie"

Het paper zegt niet dat we moeten stoppen met het gebruik van modellen. Het zegt dat we moeten stoppen met doen alsof het harnas niet bestaat. Zij stellen een nieuwe manier voor om AI te evalueren:

De "Harnas-kaart": Net zoals voedsel-etiketten ingrediënten vermelden, moet elke AI-benchmark-indeling een "Harnas-kaart" bevatten. Deze kaart specificeert precies hoe de context is opgebouwd, hoe fouten worden afgehandeld en hoe de AI wordt geverifieerd.
Variantiedecompositie: In plaats van slechts één score te geven, moeten onderzoekers rapporteren:
- Hoeveel van het scoreverschil komt door het Model?
- Hoeveel komt door het Harnas?
- Hoeveel komt door de Interactie tussen hen?

De Conclusie

Als je een onderzoeker, investeerder of gebruiker bent die kijkt naar AI-leaderboards, waarschuwt het paper je: Vertrouw de ranglijten niet blindelings.

Tot we de "Harnas-kaart" zien, is een ranglijtpositie als het beoordelen van een race zonder te weten wie welke auto bestuurde. De "winnaar" had misschien gewoon een betere auto, niet een betere bestuurder. Om AI-vooruitgang echt te begrijpen, moeten we stoppen met het vergelijken van alleen de hersenen en beginnen met het vergelijken van het hele systeem – de hersenen en het lichaam waarin ze leven.

Technische Samenvatting: Stop met het Vergelijken van LLM-agenten Zonder de Uitvoeringsomgeving (Harness) te Openbaren

1. Probleemstelling

Huidige evaluatiepraktijken voor Large Language Model (LLM)-agenten op taken met een lange horizon verwarren systematisch de modelcapaciteit met de prestaties van de uitvoeringsomgeving (harness). De uitvoeringsomgeving is de infrastructuurlaag die verantwoordelijk is voor contextopbouw, bemiddeling bij tool-interacties, outputverificatie, orkestratie (logica voor opnieuw proberen/escaleren) en stopcriteria.

Standaard ranglijsten (bijv. SWE-bench, Terminal-Bench, AgentBench) rapporteren één score per {model, benchmark}-paar, waarbij het resultaat impliciet uitsluitend aan het model wordt toegeschreven. Dit artikel betoogt dat voor taken met een lange horizon waarbij vergelijkbare frontier-modellen worden gebruikt, de uitvoeringsomgeving vaak de beperkende factor is voor de prestaties. Bijgevolg worden bij huidige evaluatieprotocollen winsten op het niveau van de uitvoeringsomgeving ten onrechte toegeschreven aan modelverbeteringen, waardoor vergelijkingen tussen modellen onbetrouwbaar en potentieel misleidend worden. Deze verwarring ontstaat omdat:

Observationeel Bewijs: Het vasthouden aan een model terwijl alleen de infrastructuur van de uitvoeringsomgeving wordt gewijzigd, prestatieverschuivingen kan opleveren (bijv. 15 procentpunten) die de gerapporteerde modelverbeteringen (doorgaans 2–4 punten) ver overtreffen.
Structurele Realiteit: Agenten opereren als gesloten-lus dynamische systemen waarbij de uitvoeringsomgeving optreedt als controller en de LLM als een stochastisch beleid. Betrouwbaarheid op lange termijn hangt af van eigenschappen van de controller (stabiliteit, beheer van contextdrift, vertraging in besturing) en niet alleen van de ruwe capaciteit van het beleid.

2. Methodologie en Theoretisch Kader

De These van de Beperkende Factor

Het artikel formaliseert de These van de Beperkende Factor: In het regime van taken met een lange horizon met vergelijkbare frontier-modellen is de variantie in benchmarkscores die wordt veroorzaakt door de uitvoeringsomgeving ($HV$) vaak vergelijkbaar met of groter dan de variantie die wordt veroorzaakt door de keuze van het model ($MV$).

De totale prestatievariantie wordt ontbonden als:
$\text{Var}(B(M, H)) = \underbrace{\text{Var}_M[E_H[B(M, H)]]}_{MV} + \underbrace{\text{Var}_H[E_M[B(M, H)]]}_{HV} + \underbrace{\text{Var}(\text{interactie})}_{\text{Interactie}}$
De these stelt dat $HV$ en het interactie-item $MV$ domineren in huidige evaluaties.

Formalisering vanuit de Besturingstheorie

De auteurs reframen de uitvoering van agenten van een eenvoudige inferentielus naar een gesloten-lus dynamisch systeem:

De LLM ( $\pi_\theta$ ): Een open-lus stochastisch beleid dat een contextprojectie $c(s_t)$ ontvangt, maar geen directe toegang heeft tot de volledige staat $s_t$ .
De Uitvoeringsomgeving ( $C_H$ ): De controller die de staat update, observaties filtert en de feedbacklus beheert.
Betrouwbaarheidskwantiteiten: De uitvoeringsomgeving bepaalt drie kritieke structurele grootheden:
1. Stabiliteit: Of het systeem een niet-afnemende verwachte vooruitgang naar het doel maakt (Lyapunov-achtige maatstaf).
2. Contextdrift ( $\delta_t$ ): De snelheid waarmee taakrelevante informatie uit het contextvenster verloren gaat.
3. Besturingsvertraging ( $\tau$ ): De vertraging tussen detectie van een anomalie en de aankomst van een corrigerend signaal bij het beleid.

Empirische Aanpak

Het artikel ondersteunt de these via twee lijnen van bewijs:

Observationele Data: Analyse van publieke ranglijsten (SWE-bench Pro, Terminal-Bench, HAL) die aantoont dat "scaffold-only" variaties (de uitvoeringsomgeving wijzigen terwijl het model vaststaat) leiden tot dubbelziffrige prestatieschommelingen en omkeringen in de rangschikking.
Gecontroleerd Factorielexperiment: Een 3x3-gridexperiment waarbij drie frontier-modellen (GPT-5.4, Kimi K2.6, GLM-5.1) worden getest tegen drie verschillende configuraties van de uitvoeringsomgeving ( $H_1$ : Minimaal/Open-lus, $H_2$ : Verbeterd/Basis gesloten-lus, $H_3$ : Volledig/Geavanceerd gesloten-lus) op een gestratificeerde subset van SWE-bench Verified.

3. Belangrijkste Resultaten

Observationeel Bewijs

SWE-bench Pro: Onder een gestandaardiseerde scaffold variëren topmodellen over 4,9 punten. Echter, bij het vasthouden aan het model (Claude Opus 4.5) en het overschakelen van de SEAL-scaffold naar Claude Code, stijgt de score met 9,5 punten.
Omkering van Rangschikking: Het toevoegen van één zoeksubagent (WarpGrep) aan identieke infrastructuur keerde de rangschikking om tussen MiniMax 2.5 en Claude Opus 4.6.
Kloven tussen Scaffolds: Op SWE-bench Verified Mini toonde hetzelfde model (bijv. Claude Sonnet 4.5) een kloof van 34 punten tussen verschillende scaffolds (SWE-Agent versus HAL Generalist).

Resultaten van het Gecontroleerde Factorielexperiment

Dominantie van Variantie: De door de uitvoeringsomgeving veroorzaakte variantie ($HV$) was 7,80 keer groter dan de door het model veroorzaakte variantie ($MV$).
- Gemiddelde $HV$: 18,48 pp²
- Gemiddelde $MV$: 2,37 pp²
Prestatieschommelingen: Het wijzigen van de uitvoeringsomgeving verschuifde scores met 8,5 tot 13,0 procentpunten voor vaste modellen, terwijl het wijzigen van het model binnen een vaste uitvoeringsomgeving scores slechts met 2,5 tot 5,0 punten verschuifde.
Instabiliteit in Rangschikking: 6 van de 9 mogelijke vergelijkingen tussen modelparen/uitvoeringsomgevingsparen resulteerden in omkeringen van de rangschikking.
Mechanisme-analyse:
- Winsten van $H_1 \to H_2$ werden gedreven door verminderde besturingsruis (betere opmaak, ophaalfunctionaliteit, foutafhandeling).
- Winsten van $H_2 \to H_3$ werden gedreven door het sluiten van de verificatie- en herstel lus (zelfcontrole, anomaliedetectie, terugdraaien).

4. Voorgesteld Kader: Uitvoeringsomgeving-bewuste Evaluatie

Het artikel stelt een nieuw evaluatieregime voor dat drie componenten vereist:

Uitvoeringsomgeving-kaart (Gestructureerde Openbaarmaking): Elke benchmark-inschrijving moet een openbaarmaking bevatten die is georganiseerd volgens de ETCSOVG-taxonomie:
- Execute (runtime, sandboxing, time-outs)
- Tool (lijst, schema, foutcontracten)
- Context (venstergrens, compressie, ophaalfunctionaliteit, geheugen)
- Scheduling (lus, opnieuw proberen, escaleren, terugdraaien)
- Observability (logging, traces)
- Verification (parsing, zelfcontrole, anomaliedetectie)
- Governance (rechten, neveneffecten)
Protocol voor Variantieontbinding: Evaluaties moeten een van de volgende protocollen toepassen:
- Vaste-Uitvoeringsomgeving-protocol: Een enkele, gespecificeerde uitvoeringsomgeving die op alle modellen wordt toegepast voor een zuivere rangschikking.
- Factorieel protocol: Het variëren van zowel modellen als uitvoeringsomgevingen om $HV$, $MV$, interactie-items en aantallen omkeringen in de rangschikking te rapporteren.
Traject-niveau Metrieken: Om prestatieschommelingen toe te schrijven aan specifieke lagen van de uitvoeringsomgeving, stelt het artikel voor:
- Herstelpercentage (RR): De waarschijnlijkheid om binnen $k$ stappen terug te keren naar een taak-voortbrengende staat na een anomalie (meet Stabiliteit).
- Contextbehoud: Het fractie van taakrelevante bestanden/beperkingen dat aanwezig is in de context (meet Drift).
- Besturingsvertraging ( $\tau$ ): Aantal stappen tussen detectie van een anomalie en aankomst van het corrigerende signaal.

5. Betekenis en Aanspraken

Het artikel stelt dat benchmarkscores voor agenten met een lange horizon niet geldig zijn voor vergelijkingen tussen modellen tenzij de uitvoeringsomgeving wordt openbaar gemaakt.

Wetenschappelijke Nauwkeurigheid: Huidige ranglijsten meten een mengsel van model en uitvoeringsomgeving, wat leidt tot systematische verkeerde toewijzing van winsten. Dit vervormt onderzoeksstimulansen, waardoor investeringen worden gericht naar modelvergroting terwijl er te weinig wordt geïnvesteerd in engineering van de uitvoeringsomgeving, wat de grootste bron van variantie is.
Praktische Impact: Beslissingen over implementatie gebaseerd op huidige ranglijsten zijn gebrekkig omdat ze de bijdrage van het model niet isoleren. De "beperkende factor" is vaak de infrastructuur en niet de modelgewichten.
Oproep tot Actie: Het vakgebied moet verschuiven van het behandelen van de uitvoeringsomgeving als een verborgen variabele naar het behandelen ervan als een primaire experimentele voorwaarde. Totdat specificaties van de uitvoeringsomgeving worden openbaar gemaakt en variantieontbinding routine wordt, moeten vergelijkingen op ranglijsten worden beschouwd als onvolledig.

Het artikel verwerpt expliciet het idee dat "betere modellen dit zullen oplossen", met de opmerking dat naarmate modellen verbeteren, uitvoeringsomgevingen complexer worden (bijv. Claude Code die componenten herontwerpt in plaats van ze te verwijderen) om de toegenomen capaciteit te beheren. De oplossing is structurele openbaarmaking, niet alleen standaardisatie of schaalvergroting.