Kontextové inženýrství pro AI agenty: Jak nastavit, co model vidí, a nezruinovat rozpočet

Stavíš AI agenta. Prvních pár iterací funguje skvěle — agent čte soubory, volá nástroje, dělá rozhodnutí. Po hodině ale začne zapomínat, co dělal před dvaceti kroky, míchá si výsledky a pátý pingne stejnou funkci, protože už neví, že ji volal. Účet za API mezitím vyletěl do stovek dolarů za den.

Problém není v modelu. Problém je v tom, co vidí.

Tomu se říká kontextové inženýrství (context engineering) a v roce 2026 je to dovednost, která odděluje agenty, kteří fungují v produkci, od těch, co zhavarují u prvního delšího úkolu.

Proč prompt engineering už nestačí

Prompt engineering řeší jednu otázku: jak se na něco zeptat modelu v jednom kole. Optimalizuješ formulaci, strukturu, příklady.

Kontextové inženýrství řeší jinou otázku: co celkově vidí model v každém kole. System prompt, uživatelský vstup, historie konverzace, definice nástrojů, načtené dokumenty, výsledky volání nástrojů — to všechno se skupekne do jednoho kontextového okna a model se s tím musí poprat.

Rozdíl je zásadní. Při prompt engineeringu optimalizuješ jeden dotaz. Při kontextovém inženýrství optimalizuješ signál-šum v okně, které se neustále mění.

Agent běžící v cyklu na kroku 47 má v okně residuum ze všech předchozích 46 kroků. Pokud je to residuum plné šumu — zbytečné výpisy z grepů, duplicitní volání nástrojů, příliš podrobné logy — model se utopí. A ty zaplatíš za každý token toho topení.

Kontextové okno jako rozpočet, ne jako úložiště

Nejužitečnější mentální model: kontextové okno není místo, kam nasypat všechno relevantní. Je to rozpočet s omezenou kapacitou, který musíš každé kolo strategicky naplnit.

Anthropic ve svém průvodci kontextovým inženýrstvím popisuje čtyři pilíře, které spolu tvoří dobrou architekturu agenta:

1. Kontextová assembly — co se v každém kole dostane do okna (system prompt, relevantní historie, definice nástrojů, načtená data)
2. Kompakce — komprimace starších kol do hutnějšího souhrnu, když okno roste
3. Paměť — přesun informací mimo okno, aby přežily napříč sezeními
4. Tool clearing — odstranění starých, znovu-načítatelných dat z okna

Pojďme si je rozebrat prakticky.

Kompakce: největší úspora, kterou většina neumí

Kompakce je vzor, kdy se stará konverzace automaticky shrne do hutnější podoby, jakmile okno narazí na nastavený limit. Místo 50 000 tokenů historie má agent najednou 7 000 tokenů souhrnu, který zachovává klíčová fakta.

SentinelOne Labs v červenci 2026 zveřejnil čísla z reálného bezpečnostního workflow: kompakce snížila počet vstupních tokenů o 86 % bez měřitelného zhoršení kvality. To není okrajová optimalizace — je to rozdíl mezi workflow, který stojí desítky dolarů za běh, a workflow, který stojí jednotky.

OpenAI zabudoval kompakci přímo do Responses API. Nastavíš threshold a runtime se o zbytek postará:

response = client.responses.create(
    model="gpt-5.5",
    input=conversation,
    store=False,
    context_management=[
        {"type": "compaction", "compact_threshold": 200_000}
    ],
)

Anthropic nabízí jemnější kontrolu přes compact_20260112 edit, kde můžeš určit, co má souhrn zachovat. Pro research agenta to může vypadat takto:

context_management = {
    "edits": [{
        "type": "compact_20260112",
        "trigger": {"type": "input_tokens", "value": 150_000},
        "instructions": (
            "Shrň tento research transcript. Zachovej každé "
            "kvantitativní číslo s jeho zdrojem a poznamenej, "
            "které dokumenty už byly přečtené a které zbývají."
        ),
    }]
}

Klíčový trik: nechoď s defaultními instrukcemi. Řekni kompresi explicitně, co je důležité (čísla, ID, odkazy, rozhodnutí), a co může zahodit (mezivýsledky, opakující se logy). Generický souhrn zahodí přes ty detaily, které agent potřebuje.

Paměť: krátkodobá vs. trvalá

Agent bez paměti je amnezik. Dvě úrovně, které potřebuješ:

Krátkodobá paměť je historie konverzace v aktuálním sezení. Typicky se udržuje v plném rozlišení pro posledních pár kol a starší se kompaktuje (viz výše).

Trvalá paměť přežije napříč sezeními. Anthropic doporučuje pattern, kdy si agent vede vlastní scratchpad soubor mimo kontextové okno — zapisuje si do něj poznámky a čte si ho, když to potřebuje. Okno zůstává čisté, ale agent nic neztratí.

Praktická implementace: na konci každého významného kroku nech agenta zapsat jedno- nebo dvěvětěný souhrn (co udělal, co zjistil, co je další krok) do souboru memory.md. Na začátku nového sezení tento soubor načti do system promptu. Máš levnou, robustní dlouhodobou paměť bez dependency na vektorové databázi.

Tool clearing: co může pryč, ať je pryč

Nejmenší známý trik. Mnoho výsledků volání nástrojů je v okně zbytečně dlouho. Pokud agent zavolal read_file('config.yml') v kroku 3, výsledek tam visí i v kroku 40 — ale agent už ten obsah nepotřebuje, a kdyby ano, může si ho přečíst znovu.

Tool clearing tyto staré, znovu-načítatelné bloky z okna odstraní. U coding agenta procházejícího monorepo to ušetří desítky tisíc tokenů za běh.

Pravidlo: co lze znovu získat voláním nástroje, nemusí viset v okně. Soubory, výsledky SQL dotazů, seznamy issues — všechno kandidát na vyčištění po spotřebě.

Context assembly: pořadí a signál-šum

Co se dostane do okna, na tom záleží stejně jako komprimace. Pár principů, které fungují:

• System prompt nahoře, stabilní. Definice role, pravidla, formát výstupu. Caching-friendly (viz níže).
• Definice nástrojů jen ty relevantní. Dvacet nástrojů, kdy agent reálně používá pět, jen zvyšuje šum. Dynamicky filtruj podle fáze úkolu.
• Historie od nejnovější, s kompakcí starších kol.
• Načtená data až když jsou potřeba — ne "pro jistotu" nahoru.

Sourcegraph ve své příručce dává konkrétní příklad, kde agent zkusil grep přes milion-řádkový monorepo, dostal 4 000 hitů a spotřeboval celé okno čtením irelevantních řádků. Skutečná příčina chyby se do okna vůbec nedostala. Řešení není lepší model — je lepší kontextová assembly, která omezí, co grep vůbec vrátí.

Bonus: kontextové inženýrství + prompt caching = 90 % sleva

Když už optimalizuješ, co je v okně stabilní, využij prompt caching. Anthropic i OpenAI umožňují označit statickou část promptu (typicky system prompt + definice nástrojů) jako cacheable — a při opakovaném volání stojí čtení z cache 0,1× standardní sazby, tedy 90 % slevu.

Anthropic: cache write stojí 1,25× (5 min) nebo 2× (1 hod), cache read 0,1×. OpenAI GPT-5.6+: explicitní režim 1,25× write, čtení s 90% slevou. Gemini 3.x: implicitní i explicitní, 90% sleva na čtení.

Implementačně stačí jeden parametr. U Claude přidáš cache_control na horní úroveň bloku. U OpenAI zapneš explicitní režim od GPT-5.6. Pro aplikaci, která dělá stovky podobných dotazů za hodinu (např. agent zpracovávající tickety), je to rozdíl mezi $150/den a $1 500/den.

Kontrolní seznam před produkčním nasazením agenta

Než pustíš agenta do reálné práce:

1. Máš kompakci? Threshold nastavený na 60–70 % okna, instrukce specifikují, co zachovat.
2. Máš trvalou paměť? Scratchpad nebo externí úložiště pro křížová sezení.
3. Čistíš staré výsledky nástrojů? Znovu-načítatelné bloky pryč po spotřebě.
4. Filtruješ definice nástrojů? Agent vidí jen nástroje, které v dané fázi potřebuje.
5. Máš caching na stabilní části promptu? System prompt + nástroje cacheable.
6. Měříš signál-šum? Po každém běhu projdi, kolik procent okna bylo irelevantní.

Šest bodů, každý z nich řeší konkrétní selhání, které jinak objevíš až ve výrobě.

Kdy kontextové inženýrství nezachrání

Upřímně: velké kontextové okno (200K, milion tokenů) snižuje tlak, ale neodstraňuje problém. Model, který má v okně všechno, se v tom stejně ztratí — attention se rozptýlí, relevantní fakta se utopí v šumu. SentinelOne to popisuje přímo: bez kompakce jsou reálné dlouhé workflow "příliš velké, hlučné a drahé na to, aby se daly čistě měřit".

Silný model se špatnou správou kontextu ztratí nit u složitého úkolu. Slabší model s dobrou kontextovou kázní může udělat stabilnější pokrok a dokončit víc úkolů. Kontextové inženýrství je v roce 2026 stejně důležité jako výběr modelu.

Shrnutí

Prompt engineering je mrtvý v tom smyslu, že už nestačí. Kontextové inženýrství je jeho nástupce pro kohokoliv, kdo staví agenty, kteří musí vydržet víc než pět kol.

Praktický postup: nastav kompakci s explicitními instrukcemi, zavedi trvalou paměť přes scratchpad, čistí staré výsledky nástrojů, filtruj definice nástrojů dynamicky a zapni caching na stabilní části promptu. Šest kroků, 86 % úspora tokenů, agent, který dokončí úkol místo toho, aby se zacyklil.

Začni jedním bodem z kontrolního seznamu. Nejdeš o dokonalost — jde o to, aby tvůj agent zvládl krok 47 stejně dobře jako krok 3.