Håll långa agentturer inom kontextfönstret

En modell kan bara läsa så mycket åt gången: dess kontextfönster. Mythex-agenten gör långt arbete: läser många filer, kör kommandon och lämnar avgränsade uppgifter till underagenter. Vi hittade tre sätt som långt arbete gick sönder på: underagenter växte tills modellen vägrade varje förfrågan, en underagent stannade tidigt eftersom den trodde att den var slut på utrymme, och vår tokenräkning var kraftigt fel för rysk, kinesisk och japansk text. Här är vad vi ändrade.

Några termer först

• Tokens är de bitar som en modell läser. Gränser och kostnader räknas i dem, inte i tecken eller ord.
• Kontextfönster är det mest en modell kan läsa i en förfrågan. Vi sätter också vår egen lägre budget för varje förfrågan, så att kostnader och hastighet håller sig rimliga.
• Verktygsresultat är det agenten får tillbaka från sina verktyg: innehållet i en fil den läste, utdata från ett kommando den körde. I långt arbete är de det mesta som skickas.
• En underagent är en hjälpare som huvudagenten startar för en avgränsad uppgift, till exempel „kontrollera de här kapitlen mot anteckningarna”. Den får en instruktion och arbetar sedan igenom många verktygsanrop på egen hand.

Problem 1: underagenter växte tills modellen vägrade dem

Varje steg skickar agenten konversationen hittills till modellen. När den blev för stor klippte vår kod den, men bara vid början av ett användarmeddelande, så att ett verktygsanrop och dess resultat aldrig delades. Den behöll första meddelandet, lade till en notis om att tidigare konversation klippts, och behöll de nyaste hela turerna som fick plats.

En underagent har exakt ett användarmeddelande: sin instruktion. Där fanns ingen plats att klippa. Så den skickade hela sin historik vid varje steg, och växte varje gång, tills förfrågan var större än vad modellen överhuvudtaget accepterar, ungefär en miljon tokens. I ett test med 8 sådana underagenter vägrades alla 8.

Lösningen: rensa gamla verktygsresultat först

Förfrågningar får nu plats i budgeten i tre steg, där varje steg bara prövas om föregående inte räckte:

1. Rensa de äldsta verktygsresultaten. Deras innehåll ersätts med en kort notis: resultatet rensades för att hålla konversationen inom modellens kontext, och agenten kan köra verktyget igen om den behöver det. En fil som lästes för en timme sedan är oftast det största och minst användbara i förfrågan, och filen finns kvar att läsa igen. De nyaste resultaten förblir hela.
2. Behåll hela användarturer. Som tidigare: första meddelandet, en notis och de nyaste kompletta turerna som får plats.
3. Behåll hela verktygsrundor. Inom en lång tur, den enda sorten en underagent har, behåll första meddelandet, en notis och de nyaste kompletta rundorna av „anropa ett verktyg, få dess resultat”.

Detta formar bara vad som skickas. Agentens sparade historik behåller allt. I samma test vägrades 0 av 8, och alla 8 blev klara.

Rensning i omgångar, så att cachen fungerar

Modellleverantörer kan återanvända arbete för början av en förfrågan om den är identisk med den förra, en prefixcache. Om vi rensade ytterligare ett resultat vid varje anrop skulle början av förfrågan ändras vid varje anrop, och cachen skulle aldrig hjälpa.

Så de äldsta resultaten rensas fyra åt gången, inte ett. Den rensade delen förblir då densamma under flera anrop. Ett resultat som inte är mycket större än notisen lämnas orört: att rensa det skulle spara nästan ingenting och ändå ändra förfrågans början. Hur mycket som förblir helt avgörs av storlek, inte antal: de nyaste resultaten som får plats i en fjärdedel av budgeten behålls, och alltid minst ett. En tidigare version behöll ett fast antal av sex hela, vilket var rätt för korta kommandoutdata men, med långa filläsningar, lämnade största delen av budgeten åt gamla resultat.

Vägrade förfrågningar säger nu det

En förfrågan som modellen avvisar som ogiltig görs inte om längre; att skicka samma förfrågan igen ger samma svar. Om konversationen är för lång för modellen ser personen: „Den här konversationen blev för lång för att modellen ska kunna läsa den på en gång. Starta en ny chatt för nästa steg — allt som byggts hittills finns kvar.” Det är personens sak att agera på, inte ett driftstopp, så det larmar oss inte.

Problem 2: agenten stannade för att „spara plats”

En underagent som bad att läsa 40 långa kapitel slutade efter 2 och sa att den ville spara plats. Den hade använt cirka 100 000 tokens av en budget på 400 000.

Den hade inget sätt att veta att gamla resultat nu skulle rensas åt den. Så vi berättade det. Agentens instruktioner säger nu att när en konversation växer förbi vad modellen kan ta, rensas de äldsta verktygsresultaten och de nyaste förblir hela. Så avbryt inte en lång uppgift för att spara plats; fortsätt, och läs en fil igen om du behöver det som rensades.

En fix som modellen inte kan se är inte en fix ur modellens synvinkel. Mekanismen hjälper bara om agenten litar på den.

Problem 3: att räkna tokens som om allt vore engelska

Vi uppskattade tokens utan att köra en tokenizer, som tecken delat på fyra. Det är en rimlig tumregel för engelska. Det är det inte för andra skriftspråk: ryska ligger på ungefär 2,2 tecken per token, och kinesiska eller japanska på ungefär ett.

Så en underagent som läste ryska kapitel skickade en förfrågan på cirka 640 000 tokens, medan vår uppskattning sa att den låg under budgeten på 400 000. Uppskattningen kunde lika gärna ha satt en förfrågan över modellens hårda gräns.

Uppskattningen räknar nu per skriftsystem: vanlig ASCII med fyra tecken per token, kinesiska, japanska och koreanska med ett, och allt annat (kyrilliska, grekiska, arabiska, accenterade bokstäver, emoji) med två. Den är tänkt att hellre överskatta. På ett rysk kapitel uppskattar den nu 43 423 tokens mot cirka 44 600 uppmätta; förut sa den 25 023. Eftersom ett meddelande aldrig ändras när det väl är skrivet räknas dess uppskattning ut en gång och minns, i stället för vid varje steg.

Vad vi tog med oss

• Klipp där storleken faktiskt finns. I agentarbete är det verktygsresultat, inte användarmeddelanden.
• Berätta för agenten om dess egna skyddsnät. Annars planerar den runt gränser som inte längre gäller.
• „Tecken ÷ 4” är ett engelskt antagande. Allt som räknar tokens för flerspråkiga användare behöver räkna per skriftsystem, eller använda en riktig tokenizer.
• Tänk på cachen. En förfrågan som ändras i början vid varje anrop kostar mer och går långsammare.

Om du bygger AI-funktioner i din egen app täcker våra guider om vad en LLM är och hur du använder LLM-API:er kontextfönster och tokens från början. Mer om hur underagenter fungerar i Mythex finns i dokumentationen om underagenter.