Kontextteknik för AI-agenter med lång horisont

Sammantaget pekar Arizes analys, arXiv-artikeln om överflöd i kontextfönster, Redis produktionsförklaring och Atlans jämförelse av harness-teknik på en praktisk förändring i agentdesign. Långkörande agenter bedöms allt mindre efter storleken på modellens kontextfönster och allt mer efter styrskiktet runt det. Arize gör den förändringen konkret. De nämner levererade agentverktyg och minnes-/harness-system, däribland Pi, OpenClaw, Claude Code och Letta, som exempel på kontextteknik på harness-nivå, och beskriver en interaktiv simulator som visar hur ett fönster på 200K token fylls upp.

De offentliga detaljerna i de citerade källorna är ojämna. Arize ger konkreta implementeringssiffror för Pi, OpenClaw, Claude Code och Letta. En forskningsartikel om att lösa överflöd i kontextfönster för AI-agenter ger en mer generell mekanism för att hantera verktygsutdata som kan överskrida vilket praktiskt fönster som helst. Redis förklaring av överflöd i kontextfönster sammanfattar produktionssymptomen: hårda API-fel, tyst kvalitetsförsämring, ackumulering av verktygsutdata och längre latens när prompter växer. Atlans jämförelse av prompt-, kontext- och harness-teknik ger den användbara stackmetaforen: promptteknik formar meddelandet, kontextteknik formar vad modellen ser och harness-teknik formar hela agentmiljön.

Den viktiga nyheten är inte att kontextfönster är för små. Det vet byggare redan. Den mer användbara poängen är att de citerade agentsystemen konvergerar mot fyra harness-mekanismer som håller arbetet vid liv efter att transkriptet slutar vara en säker källa till sanning.

En ytlig agent läser filer, anropar verktyg, lägger till resultatet och hoppas att modellen klarar av det. En harness-först-agent blockerar eller omformar stora indata innan de når modellen.

Ett tydligare sätt att läsa den första uppsättningen gränser är:

• Pi: filläsningar stoppas vid 2 000 rader eller 50 KB, beroende på vilket som inträffar först. Det returnerade innehållet innehåller en fortsättningshint som talar om för modellen vilket radintervall som visades och hur den kan fortsätta med offset och limit. OpenClaw ärver det beteendet och lägger sedan till separata tak: bootstrap-filer är begränsade till 12 000 tecken per fil och 60 000 tecken totalt. Verktygsresultat får ytterligare en budget på 16 000 tecken eller 30 % av kontextfönstret, beroende på vilket som är mindre.

Claude Code använder en design med två grindar. Enligt Arize kontrollerar den ett bytetak på 256 KB innan en fil öppnas och räknar sedan token i resultatet mot en budget på 25 000 token efter läsningen. Även för filer under taket returnerar den som standard 2 000 rader från början och trunkerar rader som är längre än 2 000 tecken. Om modellen läser om samma filintervall och filen inte har ändrats kan Claude Code returnera en stub i stället för att upprepa hela innehållet.

Det är inte bara optimering. Det ändrar felläget. I stället för att låta en stor läsning tränga undan uppgiften gör harnessen ”läs allt” till ”läs en kontrollerad del”. Om modellen behöver mer kan den be om det. För byggare som designar agentharnessar från grunden är detta första försvarslinjen: låt aldrig rå extern data bli transkriptet som standard.

Nästa mönster är att behandla kontext som ett viewport, inte som lagring.

Pi och Claude Code exponerar paginering via offset och limit. OpenClaw lägger till huvud-/svantrunkering på vissa ställen, där början och slutet behålls när mitten är mindre sannolik att spela roll. Arize säger att OpenClaw använder en uppdelning på 75 % huvud / 25 % svans för överdimensionerade bootstrap-filer och kan behålla både huvud och svans för verktygsresultat när svansen verkar viktig, till exempel fel, avslutande JSON-klamrar eller sammanfattningslika nyckelord.

Letta går längre genom att låta filer finnas utanför prompten. Uppladdade filer parsas, delas upp i segment och bäddas in i en vektorlagring, vilket ger agenten direkt visning, exakt sökning och semantisk sökning. När en fil är öppen i kontext visar Letta en hanterad vy vars storlek skalas med modellens kontext: 5 000 tecken för 8K kontext, 15 000 för 32K, 25 000 för 128K och 40 000 för 200K+. Antalet samtidigt öppna filer skalas också, från 3 för små modeller upp till 15 för mycket stora, med en LRU-policy som kastar ut de minst nyligen åtkomna filerna.

Det här är samma designidé som ligger bakom RAG i produktion: stoppa inte in hela korpusen i prompten; hämta den del som spelar roll. Skillnaden är att agentharnessar måste göra det kontinuerligt, över filer, verktygsutdata, minne och mellanliggande planer. Samma begränsning gäller för RAG-system: hämtning handlar inte bara om relevans, utan också om att bevara tillräckligt med kontextbudget för själva resonemangssteget.

Redis gör en relaterad poäng: större kontextfönster tar inte bort behovet av kontexthantering. Systemprompter, hämtade dokument, konversationshistorik och verktygsutdata konkurrerar alla om samma utrymme. Redan innan en hård gräns nås kan modeller försämras när relevant information begravs i långa indata.

Överflöd är det uppenbara felet. Målförlust är tystare. Agenten har fortfarande utrymme att svara, men glömmer det ursprungliga målet, missar en begränsning eller börjar optimera en lokal deluppgift.

Det är där komprimering spelar roll. Dåligt utförd ersätter sammanfattning en rörig men trogen historik med en prydlig men förlustbringande berättelse. Rätt utförd bevarar den uppgiftens tillstånd, det senaste arbetet, väntande poster och verktygsanropens integritet.

Arize rapporterar att Pi triggar komprimering när uppskattade kontexttoken överstiger kontextfönstret minus reservtoken, med en standardreserv på 16 384 token. Den behåller de ungefär 20 000 senaste token och sammanfattar äldre innehåll till ett syntetiskt användarmeddelande som läggs före den behållna svansen. Den undviker också att klippa genom par av verktygsanrop/verktygsresultat.

OpenClaw lägger till en mer aggressiv historikpolicy. När historiken överstiger 50 % av kontextfönstret delar den upp meddelanden i tokenblock med lika stor massa, tar bort det äldsta blocket, sammanfattar det borttagna innehållet genom stegvis flerstegssammanfattning och reparerar parningen mellan verktygsanrop och resultat. Den utför också en tömning före komprimering: en tyst agentisk tur ger agenten en chans att spara tillstånd i minnesfiler innan historiken försvinner. Separat beskär den verktygsresultat i minnet med soft-trim- och hard-clear-beteende på en cache-TTL på 5 minuter.

Claude Code komprimerar nära slutet av fönstret. Arize säger att dess trigger är det effektiva kontextfönstret minus en buffert på 13 000 token, vilket placerar komprimering runt 167K token för en modell med 200K kontext. Dess sammanfattningsprompt ber om strukturerade avsnitt som täcker den primära begäran, tekniska koncept, filer och kod, fel och fixar, problemlösning, användarmeddelanden, väntande uppgifter, aktuellt arbete och nästa steg. Efter komprimering kan den återansluta upp till 5 nyligen lästa filer inom en tokenbudget.

Mönstret är tydligt: komprimering är inte ”sammanfatta chatten”. Det är checkpointing. En långkörande agent behöver motsvarigheten till en sparfil: mål, begränsningar, beslut, öppna handtag, färska bevis och nästa åtgärd.

Vissa utdata ska aldrig placeras i kontextfönstret alls.

arXiv-artikeln gör detta konkret med ett arbetsflöde inom materialvetenskap. Ett verktyg genererar en elektronisk rutnätsstruktur för en molekyl: en 3D-matris med dimensionerna 128 × 128 × 128, totalt 2 097 152 float32-element. Den utdatan överstiger vida kontextfönstret för vanligt använda LLM:er. Men nästa verktyg behöver rutnätet som indata.

Den föreslagna lösningen är att lagra stora värden utanför modellkontexten och returnera korta identifierare, eller pekare. Verktygswrappers inspekterar indata för att se om de är råa värden eller minnessökvägar. Utdata som är för stora lagras i runtime-minne under en sökväg, och senare verktyg kan ta emot pekaren och lösa upp den internt. Modellen manipulerar referenser, medan harnessen bevarar kompletta data. I ett jämförande experiment där båda metoderna lyckades använde den pekarbaserade metoden ungefär sju gånger färre token än det traditionella arbetsflödet, enligt artikeln.

Det här är den renaste separationen mellan resonemang och datatransport. Modellen behöver inte ”se” en matris med 2 miljoner element för att skicka den vidare till ett annat verktyg. Den behöver veta att matrisen finns, vad den representerar och vilken operation som ska använda den härnäst.

Samma logik gäller bortom vetenskapliga arrayer. Stora JSON-svar, PDF:er, loggar, embeddings, mediefiler och databasexporter hör ofta hemma i lagring, inte i prompten. För system byggda kring MCP-verktyg eller anpassade API-connectors bör pekarpassning vara ett förstahandsval i designen, inte en lapp efter det första överflödet.

Ett kontextfönster på 200K token känns stort tills en agent börjar agera. En systemprompt, verktygsdefinitioner, några hämtade dokument, filläsningar, loggar, felspårningar och sammanfattningar kan förbruka det snabbare än väntat. Den praktiska ramen är inte hur stort fönstret ser ut på papper, utan hur snabbt agenter spenderar det vid körning. Redis vägledning om agentminne pekar mot externt, hållbart minne för tillstånd som ska överleva mellan anrop, medan Atlans inramning av kontextteknik skiljer bättre prompter från bättre kontextsammansättning. Tillsammans behandlar de kontextfönstret mindre som ett lager och mer som en begränsad arbetsmängd.

Den djupare lärdomen är att ett kontextfönster är en knapp runtime-resurs. Att behandla det som ”minne” är hjälpsamt, men bara om harnessen beter sig som ett operativsystem: allokerar, vräker, paginerar, komprimerar, deduplicerar och sparar beständigt. Atlans skiktdistinktion är användbar här. Promptteknik kan inte fixa en filläsare som dumpar 80 000 irrelevanta token i nästa anrop. Kontextteknik kan förbättra arbetsmängden. Harness-teknik avgör om den arbetsmängden skyddas från början.

Detta förändrar också hur team bör utvärdera agenter. En demoprompt räcker inte. Utvärdering med lång horisont bör inkludera växande transkript, upprepade filläsningar, stora verktygsutdata, misslyckade verktygsanrop, återupptaganden efter komprimering och uppgifter där rätt nästa steg beror på en tidig begränsning. Vår guide till kontextteknik för agenter tar upp modellversionen av det problemet; harness-skiktet är där det blir operationellt.

Först: sätt budgetar på varje kontextkälla. Filer, verktygsutdata, hämtade segment, minnesinfogningar och konversationshistorik bör alla ha explicita gränser. Ett enda globalt maxtal för token är för trubbigt.

För det andra: gör trunkering möjlig att agera på. Om harnessen klipper innehåll bör modellen veta vilket intervall den såg och hur den begär mer. Tyst trunkering är värre än avvisning eftersom den skapar självsäkert arbete på saknade data.

För det tredje: komprimera kring tillstånd, inte prosa. Sammanfattningar bör bevara användarens mål, begränsningar, beslut, väntande uppgifter, berörda filer, verktygsresultat som spelar roll och det omedelbara nästa steget. Verktygsanropspar bör förbli intakta.

För det fjärde: flytta stora värden ut ur prompten. Lagra dem, namnge dem och skicka pekare genom verktyg. Detta är särskilt viktigt för agenter som anropar API:er, bearbetar dokument eller koordinerar multiagentsystem.

Slutligen: testa målförlust separat från överflöd. En agent kan hålla sig under det hårda fönstret och ändå börja driva. Rätt fråga är inte bara ”accepterade API:t prompten?” Den är ”tjänar nästa åtgärd fortfarande den ursprungliga uppgiften?”

Sammanfattningen nedan gör de här mönstren till en snabb checklista före FAQ:n.

• Agenter med lång horisont misslyckas genom både kontextöverflöd och målförlust, så harnessen måste hantera mer än promptlängd.
• Agentsystem i produktion använder hårda budgetar för filer, verktygsutdata och historik innan rådata når modellen.
• Paginering, sökning och hanterade vyer behandlar kontext som ett begränsat viewport snarare än permanent lagring.
• Komprimering fungerar bäst som checkpointing: den bevarar mål, begränsningar, beslut, väntande arbete och verktygsanropens integritet.
• Stora verktygsutdata hör ofta hemma i extern lagring med korta pekare som skickas mellan verktyg i stället för fullständiga värden i prompten.

Det här avsnittet besvarar de praktiska frågorna bakom kontextteknik för agenter med lång horisont: vad som svämmar över, hur mål går förlorade och vilka harness-mönster som håller arbetet på rätt spår.

Kontextöverflöd uppstår när en agents ackumulerade prompt, historik, hämtade data, filer och verktygsutdata överskrider modellens användbara kontextfönster eller försämrar kvaliteten innan den hårda gränsen nås.

Målförlust uppstår när den ursprungliga uppgiften fortfarande finns någonstans i transkriptet men inte längre styr agentens nästa åtgärd, ofta efter långa historiker eller dålig sammanfattning.

De sätter budgetar per källa, paginerar filläsningar, hämtar bara relevanta vyer, komprimerar historik kring tillstånd, deduplicerar upprepade läsningar och lagrar stora utdata utanför prompten.

Pekare låter modellen hänvisa till stora värden som lagras i runtime-minne, till exempel matriser, loggar eller PDF:er, medan efterföljande verktyg löser upp fullständiga data utan att placera dem i kontextfönstret.

Nej. Större fönster hjälper, men systemprompter, verktygsdefinitioner, hämtade dokument, loggar och historik konkurrerar fortfarande om utrymme, och relevant information kan begravas innan en hård gräns nås.