Context engineering: miért butul el az agented a 40. körre

Az Anthropic 2025 szeptemberében húzta meg a vonalat, és a két mondatnak egymás mellett a helye. A prompt engineering „módszerek LLM-utasítások írására és szervezésére az optimális eredményekért”. A context engineering „stratégiák összessége az optimális tokenkészlet (információ) gondozására és fenntartására LLM inference közben, beleértve minden más információt is, amely a promptokon kívül oda kerülhet”.¹

A működésbeli különbség az, hogy mikor, és ki által. Egy prompt egyszer készül, egy ember írja, és átnézik. Egy context minden hívásnál összeáll, olyan kód által, amelyre senki sem néz rá, olyan anyagokból, amelyeket senki sem írt kézzel: negyven kör előzmény, hat tool-eredmény, négy retrieved részlet, egy felhasználói profil, tizenkét JSON schema. A 15. fejezet megmérte, mit érnek a jobb utasítások. Ez a fejezet a tokenek másik kilencven százalékáról szól, amelyek maguktól érkeznek.

Ugyanez a dokumentum megnevezi azt az erőforrást, amelyet mind költenek: a modelleknek „attention budgetjük” van, amelyből a nagy mennyiségű context feldolgozásakor merítenek. Minden újonnan bevezetett token valamennyit lemerít ebből a budgetből. És megnevezi a tünetet is: „ahogy nő a tokenek száma a context window-ban, csökken a modell képessége arra, hogy pontosan felidézze az adott contextben lévő információt” — context rot.¹

Ez az utolsó mondat viselkedésről szóló állítás, ami azt jelenti, hogy ellenőrizhető, és az oldal tetején lévő táblázat az ellenőrzés.

Negyven sor a 22. fejezet helyi endpointja ellen — egy kis Python-szerver, amely Qwen2.5-0.5B-Instruct-t tart a CPU-n, és a chat-completions formát beszéli, így a loop TypeScript marad, a tenzorok pedig a port túloldalán.

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

A other számláló tesz egy csalódást keltő eredményt hasznossá: amikor a modell téved, elveszett, vagy magabiztos?

A válasz: magabiztos. A nyolc nem első pozícióban a 205 rossz válaszból 136 egy másik jegy melléke volt — valódi négyjegyű szám, helyesen formázva, csak rossz sorról leolvasva. Az 1. helyen az öt hibából csak egy volt ilyen; a 7. helyen huszonhatból huszonegy.

Éles rendszerben ez a különbség számít. Az a modell, amely azt mondja: nem találom, olyan bug, amelyet észreveszel; az a modell, amely egy szomszédos sor számát adja vissza, olyan bug, amelyet kiszállítasz, mert a képernyőn a kettő ugyanúgy néz ki. Ez az a hiba, amely ellen a 19. fejezet ellenőrizhető hivatkozásokat épített, csak most nem az indexből, hanem a prompt belsejéből érkezik.

A pozíció az egyik tengely. A hossz a másik, és könnyebb tesztelni: tartsd a választ középen, és növeld a listát.

Egy rekord és 97 token: 90 %. Három rekord és 159 token: 55 %. Nyolc rekord és 315 token: 15 %, és onnantól végig lapos és alacsony, egészen 140 rekordig és 4 477 tokenig. A teljes összeomlás a lista első és nyolcadik sora között történik.

Az utolsó oszlop minden, ami se nem a helyes mellék, se nem egy másik rekordé; ha egyetlen rekord van az oldalon, a rossz válasz csak ide eshet. Az egy rekordnál látott két hibát érdemes jelenteni, nem elsimítani, mert egyik sem elutasítás volt: az egyik 5806-ot válaszolt egy olyan nyilvántartásra, amelynek egyetlen sora 5805-öt mond. 97 tokennél, egyetlen jelölttel ez a modell még mindig kétszer húszból elír egy számjegyet, és ez az alapzaj, amelyhez minden mást mérünk.

Két dolog következik. A nagyobb context jogot ad arra, hogy többet küldj, nem bizonyosságot arra, hogy el is olvassák: ennek a modellnek 32 768 tokenes window-ja van, de ezen a feladaton a működő tartománya néhány száz token. És nincs küszöb, nincs szakadék, nincs „context megtelt” állapot — a romlás már a harmadik rekordnál folyamatban van, és a nyolcadikra teljes, a window egy százalékánál. Bármi is a context limit, nem ez irányítja.

Általában két mechanizmust szokás felhozni. Az első a 9. fejezet aritmetikája, amelyet az Anthropic ugyanazokkal a fogalmakkal ír le, mint ez a kurzus: a modellek „a transformer architektúrán alapulnak, amely lehetővé teszi, hogy minden token az egész contexten belül minden másik tokenre attendeljen. Ez n token esetén n² páronkénti kapcsolatot eredményez”.¹ A hosszabb sorozaton végzett attention nem ugyanaz a művelet több anyagra alkalmazva; egy rögzített valószínűségi tömeg budgetje oszlik el több versenytárs között. A második a training: a modellek sokkal több rövid sorozatot látnak, mint hosszút, ezért a hosszú távú pozicionális minták a hálózat legkevésbé begyakorolt részei. Ez érv, nem mérés, és ez a fejezet nem tudja eldönteni.

Ami eldőlt, az a forma, és 2023 óta eldőlt. Liu és mtsai. többdokumentumos kérdés-válaszolást és key-value retrievalt teszteltek modellcsaládokon és méreteken át, és azt találták, hogy „a teljesítmény gyakran akkor a legmagasabb, amikor a releváns információ az input context elején vagy végén fordul elő, és jelentősen romlik, amikor a modelleknek a releváns információt hosszú contexteken belül középről kell elérniük, még kifejezetten long-context modellek esetén is”.² A 15. fejezet ebből a cikkből vette a pozíciószabályát; a 19. fejezet ebből vette azt az okot, hogy húsz retrieved chunk miért érhet el rosszabb eredményt, mint négy. A tény gyakorlati formája az egyetlen mondat itt, amely alapján cselekedned kell: ezt öt perc alatt megmérheted a saját modelleden a saját adataiddal, és egyetlen publikált görbe sem helyettesíti a tiédet.

Kérdezz meg egy csapatot, mi tölti meg az agent contextjét, és becslést kapsz, mert egyetlen API sem adja vissza a választ: a válasz prompt_tokens-t ad, egyetlen számot az egészre.

A bontás négy számlálással és három kivonással visszanyerhető — a teljes renderelt prompt, ugyanaz tool definíciók nélkül, a system message önmagában velük és nélkülük, és minden úgy, hogy a tool results el vannak távolítva:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

A countPrompt a modell saját chat template-jét alkalmazza tokenizálás előtt, ami fontosabb, mint amilyennek hangzik: nem a te szövegedet számolják. A role markerek, a tool-calling preambulum és a schema renderelése mind olyan token, amelyért fizetsz, de soha nem gépelted be. A 7. fejezet épített egy tokenizálót, a 16. fejezet pedig js-tiktoken-val számolt; itt a szám ugyanattól a modelltől jön, amely a promptot olvasni fogja, és ez az egyetlen pontos szám.

Most futtass át rajta egy valódi agentet: negyven kör egy incidens kivizsgálásából, tizenkét tool, egy hamis üzemeltetési környezet valószerű log dumpokkal és metrikasorozatokkal.

Olvasd az első sort az utolsó ellenében.

Az 1. körben a prompt 2 547 token, és 71 %-a tool definíció. A system prompt 3 %. Amit a felhasználó begépelt, az 6 %. Az agent még semmit sem csinált, de már 1 817 tokennyi JSON schemát cipel.

A 40. körre a prompt 10 632 token, és az arányok megfordultak: definíciók 17 %, beszélgetés 29 %, tool results 53 %. A tool output az 5. körben megelőzte a definíciókat; a beszélgetés csak a 25. körben, ezért a session első hatvan százalékában a toolkatalógus nagyobb volt, mint minden, ami addig elhangzott.

Aztán a teljes összeg. 57 modellhíváson át a futás 370 291 input tokent számlázott egy 10 632-es végső contextért — az utolsó promptért nagyjából harmincötször fizettünk, a 16. fejezet négyzetes növekedése az agent szorzójával a tetején. Ebből a 370 291-ből 103 569, vagyis a számlázott mennyiség 28 %-a a tizenkét tool definíció volt, byte-ra azonosan újraküldve minden hívásnál.

A toolkatalógus az agent legnagyobb fix költsége, és láthatatlan, mert soha nem látod: objektumok tömbjét adod át, a provider pedig helyetted rendereli a promptba. Ugyanazon a tizenkét toolon mérve:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

Toolonként a marginális költség 80 tokentől indul a get_current_time esetén, amely egy stringet kér, és 263-ig megy a search_tickets esetén, amely négy paramétert kér enummal és mindegyikhez egy mondatnyi útmutatással. Ez az átváltási ár a 18. fejezet központi tanácsa mögött, miszerint a leírás az API: egy jó leírás nagyjából száz tokenbe kerül minden kérésnél az agent élete végéig. Három következmény.

Az a tool is számláz, amelyet nem használsz. Az agent a tizenkettőből hetet hívott meg. A másik öt mind az 57 kérésnél 697 tokenbe került — összesen 39 729-be, a teljes futás számlájának több mint tizedébe, olyan képességekért, amelyekhez soha nem nyúlt. Az öt közül az egyik hordozza a trace legélesebb részletét: a modell háromszor próbálta meghívni a read_log-t, amely nem létezik. A tool, amelyet akart, a search_logs volt, a katalógus második legdrágább definíciója 237 tokennel. 57-szer fizetett ezért a definícióért, soha nem használta, és soha nem találta meg a nevét.

A próza megvágása a legolcsóbb optimalizáció, és trade-off. A leírások egy mondatra vágása és a paraméterdokumentáció elhagyása hívásonként 526 tokent spórolt, 29 százalékot, egyetlen logikai sor érintése nélkül — és rosszabbul hívta a modellel a toolokat, ahogy azt a 18. fejezet mérte. A lényeg az, hogy ennek a trade-offnak mindkét oldala most ugyanabban az egységben van.

Egy bizonyos skálán túl már nincs értelme definíciókat küldeni. Az Anthropic 2025 novemberében számot is tett mellé: sok csatlakoztatott szerver nagy készlete azt jelenti, hogy a kérés elolvasása előtt „százezernyi tokent” kell feldolgozni definíciókból, és ennek code executionnel való kiváltása — az agent csak azokat a definíciókat fedezi fel és tölti be, amelyekre szüksége van — „150 000 tokenről 2 000 tokenre csökkenti a tokenhasználatot, ami 98,7%-os idő- és költségmegtakarítás”.³ Ugyanaz az ötlet, mint a fejezet többi része, csak előzmények helyett schemákra alkalmazva: tartsd meg az indexet, és igény szerint oldd fel a bejegyzést.

Két dolgot ültettünk el abban a negyvenkörös átiratban. A 2. körben, bármilyen valódi munka előtt, a felhasználó megad egy állandó szabályt: minden megnyitott jegyet a 4417-es munkavállalói számom alá kell iktatni. A 19. körben, az incidens közepén, egy tényt: az érintett shard a pay-shard-7, a payments csapat megerősítette. A 40. körben a felhasználó megkéri az agentet, hogy nyissa meg az incidensjegyet, amihez mindkettő kell. Minden probe hat különböző megfogalmazásban hangzik el, és hatból pontozzuk — a greedy decoding determinisztikus, így egy hívás megismételhetetlen igen vagy nem, hat pedig arányt ad.

Az átiratot ezután hét context policy alatt játsszuk vissza. Szándékosan visszajátszás, nem újrafuttatás: az üzenetek, a tool calls és a tool results mind a hétben byte-ra azonosak, ezért az egyetlen változó az, hogy az adott policy mit döntött megtartani. A 16. fejezet megmutatta, miért rossz gazdasági lépés a sliding window, mert elpusztítja a cache-elhető prefixet. Itt van, mit tesz a viselkedéssel:

A compaction sorok tartalmazzák a compactálás költségét: 18 581 input token hét összefoglalóért, és további 3 392 a jegyzetelőért. A kontrollsor azért van ott, hogy a nullát nullaként lehessen olvasni — a két üzenettel önmagában, egy 1 981 tokenes promptban ez a modell mindkét probe-ra tökéletesen válaszol, tehát egyik sor sem azért nulla, mert túl nehéz a feladat.

A teljes előzmény emlékszik, és ez a legdrágább dolog a táblázatban: 370 291 input token egy olyan sessionért, amelynek tartós tartalma két mondat.

Ez megválaszolja a kérdést, amelyet a nyitás nyitva hagyott. Miért tartalmaz egy 10 632 tokenes átirat olyan tényt, amelyet egy 853 tokenes nyilvántartás elveszít? Mert a hossz a rossz változó. A nyilvántartás huszonöt négyjegyű melléket tartalmaz huszonöt azonos mondatban — huszonnégy majdnem tökéletes csalit az egyetlen keresetthez. Az átirat pontosan egy munkavállalói számot és egy shard-nevet tartalmaz. A context rot előbb interferencia, mint mennyiség, ezért volt odafent a 205 rossz válaszból 136 egy szomszéd értéke. A hasznos kérdés egy window-val kapcsolatban nem az, hogy milyen hosszú; hanem az, hogy hány dolog van benne, amely úgy néz ki, mint a válasz.

A sliding window 57 %-kal olcsóbb, és elvesztette az incidenst. A munkavállalói szám csak azért marad meg, mert az agent megismételte a közelmúlt köreiben. A shard, amely egyszer hangzott el a 19. körben, nincs benne az utolsó tizenkét üzenetben — és a modell ezt nem mondja ki. Hatszor kérdezve azt válaszolta: „az érintett payment shard a shard 4417”, a munkavállalói szám felé nyúlva, amely az egyetlen másik azonosító volt a window-jában, és kétszer azt: „pool”, amelyet a pool_exhausted stringből emelt ki egy log sorban.

A compaction olcsó, és ugyanazt a tényt veszítette el. Hét összefoglaló, amelyet a modell írt azzal az explicit utasítással, hogy tartsa meg az azonosítókat, számokat, állandó utasításokat és nyitott kérdéseket, és a pay-shard-7 egyik fontos összefoglalóban sincs benne; a hat tipp shard 1, pay_shard_1 és pool volt. A compaction nem hangosan hibázik. Folyékony, hihető, sokkal rövidebb sessiont hoz létre, amely csendben elhagyott egy sort.

Három sor ért el 0/6-ot a 19. kör tényén — a sliding window, a compaction és a jegyzetes compaction. Összesen tizennyolc rossz válasz, és egyik sem volt az, hogy „nem tudom”.

Aztán a sor, amelynek kínosnak kellene lennie. A felhasználó saját negyven üzenetének szó szerinti megtartása, plusz az utolsó négy kör teljes egészében és semmi más, 168 550 tokenbe kerül — 54 %-kal kevesebbe, mint a teljes előzmény —, és mindkét probe-ra olyan jól vagy jobban válaszol, mint a teljes előzmény. Nincs summariser, nincs jegyzetelő, nincs második modell: egy szűrő a role === "user"-n. A felhasználó szavai az agent window-jának legolcsóbb nagy értékű tokenjei, és a legtöbb design mindennel együtt kidobja őket.

Az utolsó két sor újra a nyitó táblázat, csak az agent belsejében. Ugyanaz a pinelt blokk a system message-ből a prompt végére mozgatva: 5/6-ból 6/6 lesz. Hat próbán ez nem szignifikáns különbség, és nem is annak kínáljuk — csak emlékeztető arra, hogy a hol is egy paraméter, amelyet beállítasz, akár tudsz róla, akár nem.

Az alábbi négy stratégia az Anthropicé, az ő sorrendjükben, bár csak az utolsó három tartozik a long-horizon listájukhoz.¹ Mind a négy ugyanannak az utasításnak a variációja: ne hordozd, amit le tudsz kérni, és ne hordozd nyersen, amit tömörítve is hordozhatsz.

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

A sub-agent nincs a fenti táblázatban, mert nem fut negyven körön át: egyszer fut, egy olyan window-ban, amelyet valaki neki scope-olt. A system prompttal, a 17–19. körrel és semmi mással — 2 737 tokennel — a shard probe-ra 6/6-ot válaszolt, jobban, mint a táblázat bármely policyje, a munkavállalói probe-ra pedig 0/6-ot, mert azt a számot nem kapta meg a három körben.

A sub-agents lényege két számban: a tiszta window nem intelligencia, hanem scope, és a scopingot előre végzi a kód, amelynek már tudnia kell, mely körök számítanak. Még egy dolgot érdemes megőrizni ezekből a válaszokból. Ez volt az egyetlen policy, amely azt válaszolta: „Nincs elérhető adat”, ahelyett hogy kitalált volna valamit. Egy kicsi, koherens contexttel rendelkező modell tudja, mi hiányzik neki; egy nagy, zajos contexttel rendelkező nem.

Az agent memóriáról szóló zavaros beszélgetések szinte mindig három mechanizmust takarnak egy szó alatt. Különböző élettartamuk, tulajdonosuk és hibamódjuk van, és az a rendszer, amely ugyanott tartja őket, olyan problémával küzd, amelyet még nem vett észre.

Az akadémiai keret a CoALA-é, amely a language agenteket „moduláris memóriakomponensek” köré szervezi, és elválasztja a working memoryt az episodic, semantic és procedural táraktól.⁴ A MemGPT ugyanezt az ötletet szó szerint veszi, az operációs rendszerek virtuális memóriáját kölcsönözve: egy gyors réteg a window-n belül, egy lassú réteg rajta kívül, és maga a modell mozgatja az adatot a kettő között function calls segítségével.⁵ Mindkettő kikényszeríti azt a kérdést, amelyet egy terméknek amúgy is meg kell válaszolnia — nem azt, hogy mennyit tudok megtartani, hanem azt, hogy melyik tárba tartozik ez, és mikor jár le.

A gyakorlati teszt tényenként egy kérdés: minek kell holnap is igaznak lennie? Egy tool result a 12. körből: semminek. A session összefoglalója: a session végéig. Az, hogy a felhasználó munkavállalói száma 4417: amíg munkahelyet nem vált. Három válasz, három tár.

Most már meg tudod mérni, mi van egy window-ban, el tudod dönteni, mi maradjon benne, és meg tudod különböztetni azt az agentet, amely elfelejtett valamit, attól, amely cipelte, csak nem nézett rá.

A négy stratégia közül az utolsó az, amely ide nem fér be. Egy sub-agent nem context policy, hanem egy második agent, és abban a pillanatban, hogy kettő van, el kell döntened, mi halad át közöttük, és melyik van irányításban. A 25. fejezet ez: az öt orchestration minta és hogy valójában honnan származik mindegyik neve, a két topology, amelyet összekevernek — megkérdezni egy sub-agentet és visszakapni a választ, szemben azzal, hogy átadod neki a beszélgetést és nem kapod vissza —, valamint a mért eredmény, hogy azon a feladaton, amelyet beáraz, az egyszerűbb elrendezés nyer — majd a teszt, hogy mikor nem nyer többé.

Pontosan azt is örökli, amit ez a fejezet most mért. Egy sub-agent összefoglalót ad vissza. Az összefoglaló olyan compaction, amelyet nem te írtál, egy olyan modell készíti, amelynek window-ját nem látod, és a szülőnek nincs módja megkülönböztetni a jót a magabiztos rossztól — ugyanaz a különbség, amely az oldal tetején elválasztotta a 84 %-ot a 19 %-tól, és amely tizennyolc hiányzó tényből tizennyolc kitaláltat csinált. Tehát: amikor a sub-agent téved, pontosan mit nézhet meg a szülő?

Itt minden szám ezen a gépen készült, és egyik sem becslés. A modell Qwen2.5-0.5B-Instruct float32-ben CPU-n greedy decodinggal, loopbacken kiszolgálva egy kis Python endpoint által, amely a chat-completions formát beszéli és token-count route-ot ad — újra a 14. fejezet varrata, tenzorok a Python-oldalon, loop a TypeScript-oldalon —, így minden szám a modell saját tokenizálója a saját chat template-jére alkalmazva. A pozíciótáblázat 288 hívás, kilenc pozíció szorozva harminckét próbával, minden próbában más jeggyel; a hosszúságtáblázat 140 hívás; az agent futása 57 modellhívás 43 perc falióra-idő alatt; a policy táblázat ugyanannak az egy átiratnak a visszajátszása hét policy alatt. Az intervallumok Wilson-intervallumok, a 4. fejezetből. Fizetős API-hívás nem történt, ezért nincs egyetlen ár sem a fejezetben: a token countok pontosak, a szorzandó díjak pedig a 16. fejezetben vannak.