Kontekstteknik til langsigtede AI-agenter

Tilsammen peger Arizes analyse, arXiv-artiklen om overløb i kontekstvinduer, Redis’ produktionsforklaring og Atlans sammenligning af harness engineering på et praktisk skift i agentdesign. Langvarige agenter vurderes mindre på størrelsen af modellens kontekstvindue og mere på kontrollaget omkring det. Arize gør skiftet konkret. De nævner udsendte agentværktøjer og hukommelses-/harness-systemer, herunder Pi, OpenClaw, Claude Code og Letta, som eksempler på kontekstteknik på harness-niveau og beskriver en interaktiv simulator, der viser et 200K-token-vindue blive fyldt op.

De offentlige detaljer i de citerede kilder er ujævne. Arize giver konkrete implementeringstal for Pi, OpenClaw, Claude Code og Letta. En forskningsartikel om at løse kontekstvindue-overløb i AI-agenter giver en mere generel mekanisme til at håndtere tool-outputs, der kan overstige ethvert praktisk vindue. Redis’ forklaring af overløb i kontekstvinduer opsummerer produktionssymptomerne: hårde API-fejl, stille kvalitetsforringelse, ophobning af tool-outputs og længere latenstid, efterhånden som prompts vokser. Atlans sammenligning af prompt-, kontekst- og harness engineering giver den nyttige stack-metafor: prompt engineering former beskeden, kontekstteknik former det, modellen ser, og harness engineering former hele agentmiljøet.

Den vigtige nyhed er ikke, at kontekstvinduer er for små. Det ved byggere allerede. Det mere brugbare punkt er, at de citerede agentsystemer samler sig om fire harness-mekanismer, der holder arbejdet i live, efter transskriptionen ikke længere er en sikker kilde til sandhed.

En overfladisk agent læser filer, kalder værktøjer, tilføjer resultatet og håber, at modellen kan klare det. En harness-first-agent blokerer eller omformer store inputs, før de når modellen.

En renere måde at læse det første sæt grænser på er:

• Pi: fillæsninger stopper ved 2.000 linjer eller 50 KB, alt efter hvad der kommer først. Det returnerede indhold inkluderer et fortsættelseshint, der fortæller modellen, hvilket linjeinterval der blev vist, og hvordan den kan fortsætte med offset og limit. OpenClaw arver den adfærd og tilføjer derefter separate grænser: bootstrap-filer er begrænset til 12.000 tegn pr. fil og 60.000 tegn i alt. Værktøjsresultater får endnu et budget på 16.000 tegn eller 30 % af kontekstvinduet, alt efter hvad der er mindst.

Claude Code bruger et design med to porte. Ifølge Arize tjekker det en bytegrænse på 256 KB, før en fil åbnes, og tæller derefter resultatet i tokens mod et budget på 25.000 tokens efter læsningen. Selv for filer under grænsen returnerer det som standard 2.000 linjer fra begyndelsen og afkorter linjer, der er længere end 2.000 tegn. Hvis modellen genlæser det samme filinterval, og filen ikke har ændret sig, kan Claude Code returnere en stub i stedet for at gentage hele indholdet.

Det er ikke kun optimering. Det ændrer fejltypen. I stedet for at lade én stor læsning fortrænge opgaven forvandler harnessen “læs alt” til “læs et kontrolleret udsnit”. Hvis modellen har brug for mere, kan den bede om det. For byggere, der designer agent-harnesses fra bunden, er dette den første forsvarslinje: Lad aldrig rå eksterne data blive til transskriptionen som standard.

Det næste mønster er at behandle kontekst som et viewport, ikke som lager.

Pi og Claude Code eksponerer paginering gennem offset og limit. OpenClaw tilføjer head/tail-afkortning nogle steder, hvor begyndelsen og slutningen bevares, når midten sandsynligvis er mindre vigtig. Arize siger, at OpenClaw bruger en 75 % head / 25 % tail-opdeling til overdimensionerede bootstrap-filer og kan bevare både head og tail for værktøjsresultater, når tail ser vigtig ud, f.eks. fejl, afsluttende JSON-klammer eller opsummeringslignende nøgleord.

Letta går længere ved at lade filer leve uden for prompten. Uploadede filer parses, opdeles i chunks og embeddes i et vector store, så agenten får direkte visning, eksakt søgning og semantisk søgning. Når en fil er åben i kontekst, viser Letta en styret visning, hvis størrelse skalerer med modellens kontekst: 5.000 tegn for 8K-kontekst, 15.000 for 32K, 25.000 for 128K og 40.000 for 200K+. Antallet af samtidigt åbne filer skalerer også, fra 3 for små modeller op til 15 for meget store, med en LRU-politik, der smider de mindst nyligt tilgåede filer ud.

Det er den samme designidé bag produktions-RAG: Lad være med at proppe hele korpusset ind i prompten; hent den del, der betyder noget. Forskellen er, at agent-harnesses skal gøre det løbende på tværs af filer, tool-outputs, hukommelse og mellemliggende planer. Den samme begrænsning gælder for RAG-systemer: retrieval handler ikke kun om relevans, men også om at bevare nok kontekstbudget til selve ræsonneringstrinnet.

Redis gør en relateret pointe: Større kontekstvinduer fjerner ikke behovet for kontekststyring. Systemprompts, hentede dokumenter, samtalehistorik og tool-outputs konkurrerer alle om den samme plads. Selv før en hård grænse rammes, kan modeller forringes, når relevant information begraves i lange inputs.

Overløb er den åbenlyse fejl. Måltab er mere stille. Agenten har stadig plads til at svare, men den glemmer det oprindelige mål, overser en begrænsning eller begynder at optimere en lokal delopgave.

Det er her, komprimering betyder noget. Gjort dårligt erstatter opsummering en rodet, men trofast historik med en pæn, men tabsgivende fortælling. Gjort godt bevarer den opgavens tilstand, seneste arbejde, udestående punkter og tool-call-integritet.

Arize rapporterer, at Pi udløser komprimering, når estimerede konteksttokens overstiger kontekstvinduet minus reservetokens, med en standardreserve på 16.384 tokens. Den bevarer de seneste cirka 20.000 tokens og opsummerer ældre indhold til en syntetisk brugerbesked, der lægges foran den bevarede hale. Den undgår også at skære på tværs af tool-call/tool-result-par.

OpenClaw tilføjer en mere aggressiv historikpolitik. Når historikken overstiger 50 % af kontekstvinduet, opdeler den beskeder i token-chunks med lige stor masse, fjerner den ældste chunk, opsummerer det fjernede indhold via trinvis multi-pass-opsummering og reparerer tool-call/result-parring. Den udfører også et pre-compaction flush: en stille agentisk tur giver agenten mulighed for at gemme tilstand i hukommelsesfiler, før historikken forsvinder. Separat beskærer den værktøjsresultater i hukommelsen med soft-trim- og hard-clear-adfærd på en cache-TTL på 5 minutter.

Claude Code komprimerer nær slutningen af vinduet. Arize siger, at dens trigger er det effektive kontekstvindue minus en buffer på 13.000 tokens, hvilket placerer komprimering omkring 167K tokens for en model med 200K-kontekst. Dens opsummeringsprompt beder om strukturerede afsnit, der dækker den primære anmodning, tekniske begreber, filer og kode, fejl og rettelser, problemløsning, brugerbeskeder, udestående opgaver, nuværende arbejde og næste trin. Efter komprimering kan den vedhæfte op til 5 nyligt læste filer igen inden for et tokenbudget.

Mønstret er klart: Komprimering er ikke “opsummer chatten”. Det er checkpointing. En langvarig agent har brug for svarende til en save file: mål, begrænsninger, beslutninger, åbne handles, nylig evidens og næste handling.

Nogle outputs bør aldrig placeres i kontekstvinduet overhovedet.

arXiv-artiklen gør dette konkret med et workflow fra materialevidenskab. Ét værktøj genererer en elektronisk gitterstruktur for et molekyle: en 3D-matrix med dimensionerne 128 × 128 × 128, i alt 2.097.152 float32-elementer. Det output overstiger langt kontekstvinduet for udbredte LLM’er. Men det næste værktøj har brug for gitteret som input.

Den foreslåede løsning er at gemme store værdier uden for modelkonteksten og returnere korte identifikatorer, eller pointere. Tool-wrappere inspicerer inputs for at se, om de er rå værdier eller hukommelsesstier. Outputs, der er for store, gemmes i runtime-hukommelse under en sti, og senere værktøjer kan modtage pointeren og opløse den internt. Modellen manipulerer referencer, mens harnessen bevarer de komplette data. I ét sammenlignende eksperiment, hvor begge metoder lykkedes, brugte den pointer-baserede tilgang cirka syv gange færre tokens end det traditionelle workflow, ifølge artiklen.

Dette er den reneste adskillelse mellem ræsonnering og datatransport. Modellen behøver ikke at “se” en matrix med 2 millioner elementer for at sende den videre til et andet værktøj. Den skal vide, at matrixen findes, hvad den repræsenterer, og hvilken operation der skal bruge den næste gang.

Den samme logik gælder ud over videnskabelige arrays. Store JSON-svar, PDF’er, logs, embeddings, mediefiler og databaseeksporter hører ofte hjemme i storage, ikke i prompten. For systemer bygget omkring MCP-værktøjer eller tilpassede API-connectors bør pointer-passing være et førsteklasses designvalg, ikke en lap efter det første overløb.

Et kontekstvindue på 200K tokens føles stort, indtil en agent begynder at handle. En systemprompt, tool definitions, nogle få hentede dokumenter, fillæsninger, logs, fejltraces og opsummeringer kan forbruge det hurtigere end forventet. Den praktiske ramme er ikke, hvor stort vinduet ser ud på papiret, men hvor hurtigt agenter bruger det ved runtime. Redis’ vejledning om agenthukommelse peger mod ekstern, holdbar hukommelse til tilstand, der skal overleve på tværs af kald, mens Atlans konteksttekniske indramning adskiller bedre prompts fra bedre kontekstsamling. Samlet behandler de kontekstvinduet mindre som et lager og mere som et begrænset working set.

Den dybere lektie er, at et kontekstvindue er en knap runtime-ressource. At behandle det som “hukommelse” er nyttigt, men kun hvis harnessen opfører sig som et operativsystem: allokerer, smider ud, pager, komprimerer, deduplikerer og persisterer. Atlans lagopdeling er nyttig her. Prompt engineering kan ikke fikse en fillæser, der dumper 80.000 irrelevante tokens ind i næste kald. Kontekstteknik kan forbedre working settet. Harness engineering afgør, om det working set overhovedet er beskyttet.

Det ændrer også, hvordan teams bør evaluere agenter. En demo-prompt er ikke nok. Langtidsevaluering bør omfatte voksende transskriptioner, gentagne fillæsninger, store tool-outputs, fejlede tool calls, genoptagelser efter komprimering og opgaver, hvor det korrekte næste trin afhænger af en tidlig begrænsning. Vores guide til kontekstteknik for agenter dækker model-side-versionen af det problem; harness-laget er der, hvor det bliver operationelt.

Først: Sæt budgetter på hver eneste kontekstkilde. Filer, tool-outputs, hentede chunks, hukommelsesindsættelser og samtalehistorik bør hver have eksplicitte grænser. Én global maks. tokenoptælling er for grov.

For det andet: Gør afkortning handlingsbar. Hvis harnessen skærer indhold væk, bør modellen vide, hvilket interval den så, og hvordan den kan bede om mere. Stille afkortning er værre end afvisning, fordi det skaber selvsikkert arbejde på manglende data.

For det tredje: Komprimer omkring tilstand, ikke prosa. Opsummeringer bør bevare brugerens mål, begrænsninger, beslutninger, udestående opgaver, berørte filer, værktøjsresultater der betyder noget, og det umiddelbare næste trin. Tool-call-par bør forblive intakte.

For det fjerde: Flyt store værdier ud af prompten. Gem dem, navngiv dem, og send pointere gennem værktøjer. Det er især vigtigt for agenter, der kalder API’er, behandler dokumenter eller koordinerer multi-agent-systemer.

Til sidst: Test for måltab separat fra overløb. En agent kan holde sig under det hårde vindue og stadig drive væk. Det rigtige spørgsmål er ikke kun “accepterede API’et prompten?” Det er “tjener den næste handling stadig den oprindelige opgave?”

Opsummeringen nedenfor gør disse mønstre til en hurtig tjekliste før FAQ’en.

• Langsigtede agenter fejler gennem både kontekstoverløb og måltab, så harnessen skal styre mere end promptlængde.
• Produktionsagentsystemer bruger hårde budgetter på filer, tool-outputs og historik, før rå data når modellen.
• Paginering, søgning og styrede visninger behandler kontekst som et begrænset viewport snarere end permanent storage.
• Komprimering virker bedst som checkpointing: Den bevarer mål, begrænsninger, beslutninger, udestående arbejde og tool-call-integritet.
• Store tool-outputs hører ofte hjemme i ekstern storage med korte pointere sendt mellem værktøjer i stedet for fulde værdier i prompten.

Dette afsnit besvarer de praktiske spørgsmål bag kontekstteknik til langsigtede agenter: hvad der løber over, hvordan mål går tabt, og hvilke harness-mønstre der holder arbejdet på sporet.

Kontekstoverløb opstår, når en agents akkumulerede prompt, historik, hentede data, filer og tool-outputs overstiger modellens brugbare kontekstvindue eller forringer kvaliteten, før den hårde grænse nås.

Måltab opstår, når den oprindelige opgave stadig findes et sted i transskriptionen, men ikke længere styrer agentens næste handling, ofte efter lange historikker eller dårlig opsummering.

De sætter budgetter pr. kilde, paginerer fillæsninger, henter kun relevante visninger, komprimerer historik omkring tilstand, deduplikerer gentagne læsninger og gemmer store outputs uden for prompten.

Pointere lader modellen henvise til store værdier gemt i runtime-hukommelse, såsom matricer, logs eller PDF’er, mens downstream-værktøjer opløser de fulde data uden at placere dem i kontekstvinduet.

Nej. Større vinduer hjælper, men systemprompts, tool definitions, hentede dokumenter, logs og historik konkurrerer stadig om pladsen, og relevant information kan blive begravet, før en hård grænse rammes.