Sådan holder vi lange agent-forløb inden for context-vinduet

En model kan kun læse så meget ad gangen — dens context-vindue. Mythens agent laver lang arbejde: læser mange filer, kører kommandoer og uddelegerer afgrænsede opgaver til under-agenter. Vi fandt tre måder, hvorpå lang arbejde gik i stykker: under-agenter voksede, indtil modellen afviste hver forespørgsel, en under-agent stoppede tidligt, fordi den troede, at der var løbet tør for plads, og vores tokenoptælling var helt forkert for russisk, kinesisk og japansk tekst. Her er, hvad vi ændrede.

Nogle begreber først

• Tokens er de stykker, en model læser. Grænser og omkostninger tælles i dem, ikke i tegn eller ord.
• Context-vinduet er det mest, en model kan læse i én forespørgsel. Vi sætter også vores eget lavere budget for hver forespørgsel, så omkostninger og hastighed forbliver rimelige.
• Værktøjsresultater er det, agenten får tilbage fra sine værktøjer: indholdet af en fil, den læste, output fra en kommando, den kørte. I lang arbejde er de det meste af det, der sendes.
• En under-agent er en hjælper, hovedagenten starter til en selvstændig opgave, for eksempel „tjek disse kapitler op mod noterne“. Den får én instruktion og arbejder sig derefter igennem mange værktøjskald på egen hånd.

Problem 1: under-agenter voksede, indtil modellen afviste dem

Hvert trin sender agenten samtalen indtil videre til modellen. Når den blev for stor, klippede vores kode den — men kun ved starten af en brugerbesked, så et værktøjskald og dets resultat aldrig blev revet fra hinanden. Den beholdt den første besked, tilføjede en note om, at tidligere samtale var klippet, og beholdt de nyeste hele forløb, der passede.

En under-agent har præcis én brugerbesked: sin instruktion. Der var intet sted at klippe. Så den sendte hele sin historik ved hvert trin, voksende hver gang, indtil forespørgslen var større, end modellen overhovedet accepterer — omkring en million tokens. I en test med 8 sådanne under-agenter blev alle 8 afvist.

Rettelsen: ryd gamle værktøjsresultater først

Forespørgsler passer nu til budgettet i tre trin, hvert kun forsøgt, hvis det foregående ikke var nok:

1. Ryd de ældste værktøjsresultater. Deres indhold erstattes med en kort note: resultatet blev ryddet for at holde samtalen inden for modellens context, og agenten kan køre værktøjet igen, hvis den har brug for det. En fil, der blev læst for en time siden, er som regel det største og mindst nyttige i forespørgslen, og filen kan stadig læses igen. De nyeste resultater forbliver hele.
2. Behold hele brugerforløb. Som før: den første besked, en note og de nyeste komplette forløb, der passer.
3. Behold hele værktøjsrunder. Inde i ét langt forløb — den eneste slags, en under-agent har — behold den første besked, en note og de nyeste komplette runder af „kald et værktøj, få dets resultat“.

Dette former kun, hvad der sendes. Agentens gemte historik beholder alt. I samme test blev 0 af 8 afvist, og alle 8 blev færdige.

Rydning i batches, så caching virker

Modeludbydere kan genbruge arbejde på starten af en forespørgsel, hvis den er identisk med den sidste — en prefix-cache. Hvis vi ryddede ét resultat mere ved hvert kald, ville starten af forespørgslen ændre sig ved hvert kald, og cachen ville aldrig hjælpe.

Derfor ryddes de ældste resultater fire ad gangen, ikke ét. Den ryddede del forbliver så den samme over flere kald. Et resultat, der ikke er meget større end noten, bliver ladt være: at rydde det ville spare næsten intet og alligevel ændre starten af forespørgslen. Hvor meget der forbliver helt, afgøres af størrelse, ikke antal: de nyeste resultater, der passer i en fjerdedel af budgettet, bliver, og altid mindst ét. En tidligere version beholdt fast seks hele, hvilket var rigtigt for kort kommandooutput, men med lange filaflæsninger lod det det meste af budgettet gå til gamle resultater.

Afvisninger siger det nu

En forespørgsel, som modellen afviser som ugyldig, bliver ikke forsøgt igen; at sende den samme forespørgsel igen giver det samme svar. Hvis samtalen er for lang til modellen, ser personen: „Denne samtale blev for lang til, at modellen kunne læse den på én gang. Start en ny chat til næste trin — alt, der er bygget indtil nu, bliver.“ Det er personens at handle på, ikke et driftsstop, så det sender ikke en alarm til os.

Problem 2: agenten stoppede for at „spare plads“

En under-agent, der blev bedt om at læse 40 lange kapitler, stoppede efter 2 og sagde, at den ville spare plads. Den havde brugt cirka 100.000 tokens af et budget på 400.000.

Den havde ingen måde at vide, at gamle resultater nu ville blive ryddet for den. Så vi fortalte den det. Agentens instruktioner siger nu, at når en samtale vokser ud over, hvad modellen kan tage, ryddes de ældste værktøjsresultater, og de nyeste forbliver hele — så stop ikke et langt arbejde for at spare plads; fortsæt, og læs en fil igen, hvis du har brug for det, der blev ryddet.

En rettelse, modellen ikke kan se, er ikke en rettelse set fra modellens synspunkt. Mekanismen hjælper kun, hvis agenten stoler på den.

Problem 3: vi talte tokens, som om alt var engelsk

Vi estimerede tokens uden at køre en tokenizer, som tegn divideret med fire. Det er en rimelig tommelfingerregel for engelsk. Det er den ikke for andre skriftsystemer: russisk ligger på cirka 2,2 tegn pr. token, og kinesisk eller japansk cirka ét.

En under-agent, der læste russiske kapitler, sendte derfor en forespørgsel på cirka 640.000 tokens, mens vores estimat sagde, at den var under budgettet på 400.000. Estimatet kunne lige så nemt have skubbet en forespørgsel over modellens hårde grænse.

Estimatet tæller nu efter skriftsystem: almindelig ASCII til fire tegn pr. token, kinesisk, japansk og koreansk til ét, og alt andet — kyrillisk, græsk, arabisk, accenterede bogstaver, emoji — til to. Det er tænkt til at fejle opad. På ét russisk kapitel estimerer det nu 43.423 tokens mod cirka 44.600 målt; før sagde det 25.023. Da en besked aldrig ændrer sig, når den først er skrevet, udregnes dens estimat én gang og huskes, i stedet for ved hvert trin.

Hvad vi tog med

• Klip, hvor størrelsen faktisk er. I agentarbejde er det værktøjsresultater, ikke brugerbeskeder.
• Fortæl agenten om dens egne sikkerhedsnet. Ellers planlægger den ud fra grænser, der ikke længere gælder.
• „Tegn ÷ 4“ er en antagelse om engelsk. Alt, der tæller tokens for flersprogede brugere, skal tælle efter skriftsystem eller bruge en rigtig tokenizer.
• Pas på cachen. En forespørgsel, der ændrer sig forrest ved hvert kald, koster mere og kører langsommere.

Hvis du bygger AI-funktioner ind i din egen app, dækker vores guides til hvad en LLM er og sådan bruger du LLM-API'er context-vinduer og tokens fra starten. Mere om, hvordan under-agenter virker i Mythex, findes i under-agent-dokumentationen.