Context engineering: proč je váš agent ve 40. kole hloupější

Anthropic narýsoval hranici v září 2025 a obě věty patří vedle sebe. Prompt engineering jsou „metody psaní a organizace instrukcí pro LLM za účelem optimálních výsledků“. Context engineering je „soubor strategií pro kuraci a udržování optimální sady tokenů (informací) během inference LLM, včetně všech dalších informací, které se tam mohou dostat mimo prompty“.¹

Praktický rozdíl je kdy a kým. Prompt jednou napíše člověk a někdo ho zkontroluje. Kontext se skládá při každém volání, kódem, na který se nikdo nedívá, z materiálu, který nikdo nepsal ručně: čtyřicet tahů historie, šest výsledků toolů, čtyři retrieved pasáže, uživatelský profil, dvanáct JSON schémat. Kapitola 15 změřila, co koupí lepší instrukce. Tato kapitola je o zbylých devadesáti procentech tokenů, které přicházejí samy.

Tentýž dokument pojmenovává zdroj, který všechny utrácejí: modely „mají ‚attention budget‘, ze kterého čerpají při parsování velkých objemů kontextu. Každý nově zavedený token tento rozpočet o určité množství vyčerpává“. A pojmenovává symptom: „jak počet tokenů v context window roste, schopnost modelu přesně si vybavit informace z tohoto kontextu klesá“ — context rot.¹

Ta poslední věta je tvrzení o chování, což znamená, že se dá ověřit, a tabulka nahoře na této stránce je ověření.

Čtyřicet řádků proti lokálnímu endpointu z kapitoly 22 — malý Python server držící Qwen2.5-0.5B-Instruct na CPU a mluvící tvarem chat-completions, takže smyčka zůstává v TypeScriptu a tenzory zůstávají na druhé straně portu.

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++;
  }
}

Počítadlo other je to, co mění zklamání v užitečný výsledek: když se model mýlí, je ztracený, nebo je sebejistý?

Odpověď je: sebejistý. Napříč osmi neprvními pozicemi bylo 136 z 205 špatných odpovědí linkou jiného ticketu — skutečné čtyřmístné číslo, správně formátované, přečtené ze špatného řádku. Na pozici 1 byla taková jen jedna z pěti chyb; na pozici 7 to bylo dvacet jedna z dvaceti šesti.

Právě tento rozdíl je v produkci podstatný. Model, který řekne Nemůžu to najít, je chyba, které si všimnete; model, který vrátí číslo sousedního řádku, je chyba, kterou nasadíte, protože na obrazovce vypadají obě stejně. Je to selhání, proti kterému kapitola 19 postavila ověřitelné citace, tentokrát přicházející zevnitř promptu místo z indexu.

Pozice je jedna osa. Délka je druhá a snáze se testuje: nechte odpověď uprostřed a prodlužujte seznam.

Jeden záznam a 97 tokenů: 90 %. Tři záznamy a 159 tokenů: 55 %. Osm záznamů a 315 tokenů: 15 %, a odtud rovně a nízko až ke 140 záznamům a 4 477 tokenům. Celý kolaps se odehraje mezi prvním a osmým řádkem seznamu.

Poslední sloupec je všechno, co není správná linka ani linka jiného záznamu, což je u jediného záznamu na stránce jediné místo, kam špatná odpověď může dopadnout. Dvě chyby u jednoho záznamu stojí za reportování místo zaokrouhlení pryč, protože ani jedna nebyla odmítnutím: jedna odpověděla 5806 na registr, jehož jediný řádek říká 5805. Při 97 tokenech a jediném kandidátovi tento model pořád dvakrát z dvaceti špatně opíše číslici, a to je podlaha, vůči které se měří všechno ostatní.

Z toho plynou dvě věci. Větší context window kupuje právo poslat víc, ne jistotu, že to bude přečteno: tento model má 32 768tokenové okno a pracovní rozsah, na této úloze, pár stovek tokenů. A není tu žádný práh, žádný útes, žádný stav „kontext plný“ — degradace běží už u třetího záznamu a je dokončená u osmého, na jednom procentu okna. Ať už context limit znamená cokoli, tohle neřídí.

Obvykle se nabízejí dva mechanismy. První je aritmetika z kapitoly 9, kterou Anthropic uvádí ve stejných pojmech jako tento kurz: modely „jsou založené na architektuře transformer, která umožňuje každému tokenu věnovat attention každému jinému tokenu napříč celým kontextem. Výsledkem je n² párových vztahů pro n tokenů“.¹ Attention nad delší sekvencí není stejná operace aplikovaná na víc materiálu; je to jeden pevný rozpočet pravděpodobnostní hmoty rozprostřený přes více konkurentů. Druhý je trénink: modely vidí mnohem více krátkých sekvencí než dlouhých, takže dlouhodosahové poziční vzory jsou nejméně procvičenou částí sítě. To je argument, ne měření, a tato kapitola ho nemůže rozhodnout.

Co rozhodnuté je, je tvar, a to už od roku 2023. Liu et al. testovali odpovídání na otázky nad více dokumenty a key-value retrieval napříč rodinami a velikostmi modelů a zjistili, že „výkon je často nejvyšší, když relevantní informace leží na začátku nebo konci vstupního kontextu, a významně se zhoršuje, když modely musí přistupovat k relevantním informacím uprostřed dlouhých kontextů, dokonce i u modelů explicitně určených pro dlouhý kontext“.² Kapitola 15 si z tohoto článku vzala pravidlo pozice; kapitola 19 si z něj vzala důvod, proč dvacet retrieved chunků může skórovat hůř než čtyři. Praktická forma tohoto faktu je jediná věta, podle které byste tady měli jednat: změřit to na vlastním modelu s vlastními daty zabere pět minut a žádná publikovaná křivka nenahradí tu vaši.

Zeptejte se týmu, co plní kontext jejich agent, a dostanete odhad, protože žádné API nevrací odpověď: response vám dá prompt_tokens, jedno číslo pro všechno.

Rozpad můžete obnovit čtyřmi počty a třemi odečty — celý vyrenderovaný prompt, totéž bez definic toolů, samotná system message s nimi a bez nich a všechno s odebranými výsledky toolů:

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,
  };
}

countPrompt před tokenizací aplikuje vlastní chat template modelu, což je důležitější, než to zní: váš text není to, co se počítá. Značky rolí, preambule tool calling a renderování schématu jsou všechno tokeny, za které platíte a nikdy jste je nenapsali. Kapitola 7 postavila tokenizer a kapitola 16 počítala s js-tiktoken; tady počet pochází ze stejného modelu, který bude prompt číst, což je jediný počet, který je přesně správně.

Teď tím prožeňte skutečný agent: čtyřicet tahů vyšetřování incidentu, dvanáct toolů, falešné operační prostředí vracející realistické log dumpy a řady metrik.

Čtěte první řádek proti poslednímu.

V tahu 1 má prompt 2 547 tokenů a 71 % z něj tvoří definice toolů. System prompt jsou 3 %. To, co napsal uživatel, je 6 %. Agent ještě nic neudělal a už nese 1 817 tokenů JSON schématu.

Ve tahu 40 má prompt 10 632 tokenů a podíly se obrátily: definice 17 %, konverzace 29 %, výsledky toolů 53 %. Výstup toolů předběhl definice v tahu 5; konverzace je nepředběhla až do tahu 25, takže prvních šedesát procent seance byl katalog toolů větší než všechno, co bylo řečeno.

Pak celek. Napříč 57 voláními modelu běh účtoval 370 291 input tokenů za finální kontext 10 632 — poslední prompt zaplacený asi pětatřicetkrát, což je kvadratika z kapitoly 16 s násobičem agent navrch. Z těch 370 291 bylo 103 569, tedy 28 % všeho účtovaného, dvanáct definic toolů, znovu odeslaných byte-identical při každém volání.

Katalog toolů je největší fixní náklad v agent a je neviditelný, protože ho nikdy nevidíte: předáte pole objektů a provider ho za vás vyrenderuje do promptu. Změřeno na stejných dvanácti toolech:

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 %)

Na tool se marginální náklad pohybuje od 80 tokenů pro get_current_time, který bere jeden string, po 263 pro search_tickets, který bere čtyři parametry s enum a větou vodítka u každého. To je směnný kurz za ústřední radou kapitoly 18, že popis je API: dobrý popis stojí asi sto tokenů při každém requestu po zbytek života agent. Tři důsledky.

Tool, který nepoužíváte, se pořád účtuje. Agent zavolal sedm z dvanácti. Zbylých pět stálo 697 tokenů při každém z 57 requestů — celkem 39 729, víc než desetina všeho, co se běhu účtovalo, za schopnosti, kterých se nikdy nedotkl. Jeden z těch pěti nese nejostřejší detail ve stopě: model se třikrát pokusil zavolat read_log, který neexistuje. Tool, který chtěl, byl search_logs, druhá nejdražší definice v katalogu s 237 tokeny. Zaplatil za tu definici 57krát, nikdy ji nepoužil a nikdy nenašel její název.

Ořezání prózy je nejlevnější dostupná optimalizace a je to trade-off. Zkrácení popisů na jednu větu a odstranění dokumentace parametrů ušetřilo 526 tokenů na volání, 29 procent, bez dotyku jediné řádky logiky — a zhoršilo volání toolů modelem, což měřila kapitola 18. Pointa je, že obě strany tohoto trade-offu jsou teď ve stejné jednotce.

V určitém měřítku přestává posílání definic vůbec dávat smysl. Anthropic na to v listopadu 2025 dal číslo: velká sada připojených serverů znamená zpracování „stovek tisíc tokenů“ definic před přečtením requestu a nahrazení tohoto postupu code execution — tedy tím, že agent objevuje a načítá jen definice, které potřebuje — „snižuje spotřebu tokenů ze 150 000 tokenů na 2 000 tokenů, časovou a nákladovou úsporu 98,7 %“.³ Stejná myšlenka jako ve zbytku této kapitoly, aplikovaná na schémata místo historie: držte index, položku vyřešte na vyžádání.

Do toho čtyřicetitahového transkriptu byly zasazeny dvě věci. V tahu 2, před jakoukoli skutečnou prací, uživatel uvádí trvalé pravidlo: každý ticket, který otevřete, musí být založen pod mým zaměstnaneckým číslem, 4417. V tahu 19, uprostřed incidentu, fakt: zasažený shard je pay-shard-7, potvrzeno týmem payments. V tahu 40 uživatel žádá agent, aby otevřel incident ticket, což potřebuje obojí. Každá sonda je položena v šesti různých formulacích a skórována ze šesti — greedy decoding je deterministický, takže jedno volání dá neopakovatelnou odpověď ano/ne a šest dá míru.

Transkript je pak přehrán pod sedmi context policies. Přehrán, ne znovu spuštěn, záměrně: zprávy, tool calls a výsledky toolů jsou ve všech sedmi byte-identical, takže jediná proměnná je co se každá policy rozhodla ponechat. Kapitola 16 ukázala, proč je sliding window špatný ekonomický tah, protože ničí cacheovatelný prefix. Tady je, co dělá s chováním:

Řádky compaction zahrnují i cenu compactingu: 18 581 input tokenů za sedm souhrnů a dalších 3 392 za pořizovač poznámek. Kontrolní řádek je tam proto, aby nula šla číst jako nula — jen se dvěma zprávami v 1 981tokenovém promptu tento model zodpoví obě sondy dokonale, takže žádný řádek není o tom, že úloha je příliš těžká.

Plná historie si pamatuje a je nejdražší věc v tabulce: 370 291 input tokenů za seanci, jejímž trvalým obsahem jsou dvě věty.

To odpovídá na otázku, kterou úvod nechal otevřenou. Proč 10 632tokenový transkript udrží fakt, který 853tokenový registr ztratí? Protože délka je špatná proměnná. Registr obsahuje pětadvacet čtyřmístných linek v pětadvaceti identických větách — čtyřiadvacet téměř dokonalých návnad pro tu jednu, kterou chcete. Transkript obsahuje přesně jedno zaměstnanecké číslo a jeden název shardu. Context rot je interference dřív než objem, a proto 136 z 205 špatných odpovědí nahoře bylo hodnotou souseda. Užitečná otázka o okně není, jak je dlouhé; je to, kolik věcí v něm vypadá jako odpověď.

Sliding window je o 57 % levnější a ztratilo incident. Zaměstnanecké číslo přežije jen proto, že ho agent zopakoval do nedávných tahů. Shard, uvedený jednou v tahu 19, není v posledních dvanácti zprávách — a model to neřekne. Při šesti dotazech odpověděl „zasažený payment shard je shard 4417“, sáhl po zaměstnaneckém čísle, jediném dalším identifikátoru, který mu v okně zbyl, a dvakrát „pool“, zvednutém ze stringu pool_exhausted v řádku logu.

Compaction je levný a ztratil stejný fakt. Sedm souhrnů, napsaných modelem pod explicitní instrukcí ponechat identifikátory, čísla, trvalé instrukce a otevřené otázky, a pay-shard-7 není v žádném z těch, na kterých záleželo; šest odhadů bylo shard 1, pay_shard_1 a pool. Compaction neselhává nahlas. Produkuje plynulou, uvěřitelnou, mnohem kratší seanci, která potichu zahodila jeden řádek.

Tři řádky skórovaly 0/6 u faktu z tahu 19 — sliding window, compaction a compaction s poznámkami. Osmnáct špatných odpovědí mezi nimi a ani jedna nebyla „nevím“.

Pak řádek, který by měl být trapný. Ponechat vlastních čtyřicet zpráv uživatele doslova, plus poslední čtyři tahy v plném znění a nic jiného, stojí 168 550 tokenů — o 54 % méně než plná historie — a odpovídá na obě sondy stejně dobře jako plná historie nebo lépe. Žádný summariser, žádný note-taker, žádný druhý model: filtr na role === "user". Slova uživatele jsou nejlevnější tokeny s vysokou hodnotou v okně agent a většina návrhů je zahazuje se vším ostatním.

Poslední dva řádky jsou úvodní tabulka znovu, uvnitř agent. Stejný připnutý blok, přesunutý ze system message na konec promptu: 5/6 se stane 6/6. Na šesti pokusech to není významný rozdíl a není tak nabízen — je to připomínka, že kde je parametr, který nastavujete, ať už o tom víte, nebo ne.

Čtyři strategie níže jsou od Anthropic, v jeho pořadí, i když jen poslední tři jsou jeho long-horizon seznam.¹ Všechny čtyři jsou variace jedné instrukce: nenoste to, co můžete načíst, a nenoste raw to, co můžete nést komprimované.

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()}`);

Sub-agent není v tabulce výše, protože neběží čtyřicet tahů: běží jednou, v okně, které pro něj někdo vymezil. Se system promptem, tahy 17 až 19 a ničím jiným — 2 737 tokenů — zodpověděl sondu shardu 6/6, lépe než každá policy v tabulce, a sondu zaměstnance 0/6, protože to číslo není ve třech tazích, které dostal.

To jsou sub-agents ve dvou číslech: čisté okno není inteligence, je to scope, a scoping předem dělá kód, který už musí vědět, na kterých tazích záleží. V těch odpovědích stojí za ponechání ještě jedna věc. Byla to jediná policy, která odpověděla „Nic není k dispozici“ místo toho, aby si něco vymyslela. Model s malým, koherentním kontextem ví, co mu chybí; model s velkým, zašuměným ne.

Téměř každá zmatená konverzace o paměti agent je o třech mechanismech oblečených do jednoho slova. Mají různé životnosti, vlastníky a režimy selhání a systém, který je drží na stejném místě, má problém, kterého si ještě nevšiml.

Akademický rámec je CoALA, který organizuje language agents kolem „modular memory components“ a odděluje working memory od episodic, semantic a procedural stores.⁴ MemGPT bere stejnou myšlenku doslova a půjčuje si virtuální paměť z operačních systémů: rychlou vrstvu uvnitř okna, pomalou vrstvu mimo něj a samotný model přesouvající data mezi nimi pomocí function calls.⁵ Oba nutí položit otázku, na kterou produkt stejně musí odpovědět — ne kolik toho můžu držet, ale do kterého store to patří a kdy to expiruje.

Praktický test je jedna otázka na fakt: co má být pořád pravda zítra? Výsledek toolu z tahu 12: nic. Souhrn seance: dokud seance neskončí. Že zaměstnanecké číslo uživatele je 4417: dokud nezmění práci. Tři odpovědi, tři stores.

Teď umíte změřit, co je v okně, rozhodnout, co v něm zůstane, a rozlišit mezi agent, který něco zapomněl, a tím, který to nesl a nepodíval se.

Poslední ze čtyř strategií se sem nevejde. Sub-agent není context policy, je to druhý agent, a ve chvíli, kdy jsou dva, musíte rozhodnout, co mezi nimi prochází a kdo velí. Kapitola 25 je právě to: pět orchestration patterns a odkud jejich názvy opravdu pocházejí, dvě topologie, které se pletou — zeptat se sub-agent a dostat odpověď zpět, versus předat mu konverzaci a nedostat ji zpět — a změřené zjištění, že na úloze, kterou oceňuje, vyhrává jednodušší uspořádání — následované testem, kdy vyhrávat přestane.

Také dědí přesně to, co tato kapitola právě změřila. Sub-agent vrací souhrn. Souhrn je compaction, který jste nenapsali, vytvořený modelem, jehož okno nevidíte, a rodič nemá jak poznat dobrý souhrn od sebejistě špatného — tentýž rozdíl, který nahoře na této stránce oddělil 84 % od 19 % a proměnil osmnáct chybějících faktů v osmnáct vymyšlených. Takže: když se sub-agent mýlí, na co přesně se rodič může podívat?

Každé číslo zde vzniklo na tomto stroji a žádné nebylo odhadnuto. Model je Qwen2.5-0.5B-Instruct ve float32 na CPU s greedy decoding, obsluhovaný přes loopback malým Python endpointem, který mluví tvarem chat-completions a vystavuje route pro počítání tokenů — znovu šev z kapitoly 14, tenzory na straně Pythonu a smyčka na straně TypeScriptu — takže každý počet je vlastní tokenizer tohoto modelu aplikovaný na jeho vlastní chat template. Tabulka pozice je 288 volání, devět pozic krát třicet dva pokusů s jiným ticketem v každém pokusu; tabulka délky je 140 volání; běh agent je 57 volání modelu během 43 minut wall clock; tabulka policy je tentýž jeden transkript přehrán pod sedmi policies. Intervaly jsou Wilsonovy, z kapitoly 4. Nebylo zavoláno žádné placené API, a proto v kapitole není ani jedna cena: počty tokenů jsou přesné a sazby, kterými byste je násobili, jsou v kapitole 16.