Slovník AI

Pohyblivá nálepka, nikoliv technologie. „Umělá inteligence“ nepojmenovává pevně danou věc tak, jak to činí model nebo token – ukazuje na to, co počítače nově a působivě dokážou. Právě teď odkazuje na velké jazykové modely. V minulosti ukazovala na velmi odlišné věci:

Ukazatel se posouvá známým mechanismem, kterému se někdy říká efekt AI: jakmile nějaká technika spolehlivě funguje, je přejmenována – je to „pouze“ vyhledávání, „pouze“ statistika – a „AI“ se posouvá vpřed k dalšímu nevyřešenému problému. Toto pozorování je staré. Bertram Raphael to v roce 1971 vyjádřil takto: „AI je souhrnný název pro problémy, které ještě neumíme počítačem správně vyřešit.“ Verze Larryho Teslera z doby kolem roku 1979: „Inteligence je to, co stroje ještě neudělaly.“

To je důvod, proč se konverzace o AI tak často míjejí účinkem. Tvrzení typu „AI nedokáže uvažovat“ nebo „AI je přeceňovaná“ nese skryté časové razítko – může se týkat expertních systémů, obrazových klasifikátorů z 10. let nebo loňského LLM, přičemž každá reference podporuje jiný závěr. Když diskuse o AI uvízne na mrtvém bodě, řešením obvykle bývá nahradit toto slovo přesným termínem, který je ve skutečnosti míněn: modelem, nástrojem, agentem, kontextem, který mu byl dán.

Vyhněte se: „AI“ v jakémkoli technickém tvrzení – místo toho pojmenujte tu část, kterou máte na mysli. „Kódování pomocí AI“ jako označení pro tuto praxi je v pořádku; „AI halucinuje“ nikoli.

Použití:

„Technický ředitel chce vědět, zda by AI zvládla frontu triáže.“

„Před vymezením rozsahu to přeložte – myslí tím LLM v nástroji s přístupem do systému tiketů. „AI“ sama o sobě není specifikace.“

Parametry. Bez stavové paměti — provádí predikci dalšího tokenu a nic jiného. „Claude Opus 4.x“ a „GPT-5.x“ jsou modely. Sám o sobě model nedokáže samostatně jednat; musí být zapojen do harnessu.

Modely nedokážou číst soubory, spouštět příkazy, procházet web ani si pamatovat včerejšek — přijmou tokeny a předpovídají výstupní tokeny, jednou na každý požadavek na poskytovatele modelu. Všechno, co působí jako práce agenta — výběr nástrojů, čtení výsledků, opakování cyklu až do dokončení úkolu — je harness, který řídí mnoho těchto předpovědí za sebou.

Poskytovatelé modelů nabízejí modely v úrovních: velký, který je nejchytřejší, ale pomalý a drahý, a menší, které jsou rychlejší a levnější, ale méně schopné. Volba úrovně je skutečné rozhodnutí — těžká váha pro plánování a obtížné ladění, lehká pro mechanické změny — a harnessy umožňují přepnutí během relace.

Důsledné používání tohoto slova také zpřesňuje diagnostiku. „Model tohle nezvládá“ je konkrétní tvrzení — tentýž model v jiném harnessu nebo s jiným kontextem se často chová zcela jinak. Než obviníte model, ověřte, co dostal: většina zklamání z výstupu má původ v kontextu či harnessu, nikoli v parametrech.

Použití:

„Máme pro plánování přepnout model ze Sonnet na Opus?“

„Zkus to — většinu práce v tomto úkolu ale dělá harness. Změna modelu nepomůže, pokud jsou špatně systémový prompt a nástroje.“

Čísla uvnitř modelu — často jich jsou miliardy — upravená při trénování. Všechno, co model „ví“, žije v nich. Trénování je nastaví; inference je používá beze změny. Říká se jim také váhy.

Z mechanického hlediska parametry mění vstup na výstup. Predikce dalšího tokenu je obrovský výpočet: vstoupí do něj tokeny z kontextového okna, pronásobí se přes parametry a vznikne předpověď dalšího tokenu. Uvnitř modelu není databáze faktů ani vyhledávací tabulka kódu — jen tato čísla uspořádaná tak, aby výpočet obvykle vytvářel užitečný výstup. Fakta, která model umí odříkat z trénování, například API standardní knihovny, jsou parametrické znalosti: uložené v parametrech, nikoli odněkud vyhledané.

Je důležité si osvojit, že po trénování jsou parametry zmrazené. Nic, co uděláte v relaci, je nezmění — žádná vaše oprava, ukázaná kódová základna ani chyba, z níž se poučí. Každá relace běží nad stejnými čísly. Proto je model bez stavové paměti, jeho vestavěné znalosti končí na mezním datu znalostí a vše specifické pro projekt musí přijít prostřednictvím kontextu. Parametry změní jen další trénování, které v podstatě vytvoří jiný model.

Použití:

„Můžeme ho dotrénovat na našem kódu?“

„To by aktualizovalo parametry — pak by to byl jiný model. Pro jeden projekt je téměř vždy levnější načíst kód do kontextu než model znovu trénovat.“

Proces, který nastavuje parametry modelu tím, že mu ukazuje obrovské množství textu a upravuje parametry pro lepší predikci dalšího tokenu. Jde o jednorázový nákladný proces prováděný poskytovatelem modelu. Zahrnuje předtrénování (hlavní běh) i následné trénování (pozdější vylepšení, například dodržování instrukcí a bezpečnost); na úrovni tohoto slovníku není rozdíl důležitý.

Mechanismem je opakování ve velkém: ukázat modelu úsek textu, nechat ho předpovědět další token, posunout parametry směrem ke skutečnému dalšímu tokenu a opakovat to přes biliony tokenů. Nic se neukládá jako fakta nebo pravidla — všechno, co model „ví“, je vedlejším výsledkem zlepšování predikce, stlačeným do parametrů jako parametrické znalosti.

Pro běžnou práci jsou důležité dva důsledky. Trénování končí v určitém okamžiku, takže model má mezní datum znalostí — neviděl verzi knihovny, na kterou jste přešli minulý měsíc. A trénování není něco, co můžete provést vy: když model nezná váš kód, konvence nebo interní API, řešením nikdy není „naučit model“, ale vložit dané materiály do kontextu, jediného vstupu, který ovládáte.

Použití:

„Můžeme ho přimět znát naše interní API?“

„Ne trénováním — to je několikaměsíční proces poskytovatele modelu. Raději načti dokumentaci API do kontextu, to je páka, kterou skutečně máš.“

Spuštění trénovaného modelu pro generování výstupu — co se stane při každém požadavku poskytovatele modelu . Parametry zůstávají pevné; model provádí pouze predikci dalšího tokenu nad poskytnutým kontextem . Levné v porovnání s tréninkem , ale účtované za token a představující dominantní náklady na používání modelu.

Život modelu se dělí na dvě fáze:

Nic, co uděláte během inference, se nezapíše zpět do parametrů — to je důvod, proč oprava, kterou provedete dnes, zítra nezůstane. Model, který udělá stejnou chybu v příštím sezení , poté, co jste pečlivě vysvětlili opravu, vás neignoroval; není schopen se z výměny poučit. Model je bezstavový — kontinuita musí přicházet zvenčí — z kontextového okna nebo systému paměti .

Tento mechanizmus také vysvětluje, jak vám je účtováno. Každý požadavek spouští model nad celým kontextem, takže náklady rostou s vstupními tokeny a výstupními tokeny a agent provádějící desítky volání nástrojů platí za inferenci při každé zpětné cestě. Proto je velikost kontextu otázkou nákladů i kvality.

Použití:

„Proč se účet odvíjí od použití namísto paušální licence?“

„Platíte za inferenci — každý požadavek poskytovatele modelu spouští model na hardware poskytovatele. Trénink již proběhl, ale náklady na inferenci nabíhají za každý požadavek a jedno kolo se může při volání nástrojů rozrůst v mnoho požadavků.“

Úsilí je míra toho, kolik uvažování model provede, než odpoví. Nastavuje se na základě požadavku poskytovatele modelu a řídí délku přemýšlení, které model provede, než začne psát odpověď, kterou vidíte. Toto přemýšlení se generuje ve fázi inference jako všechno ostatní; rozhraní ho často skrývá, ale je to reálná práce, kterou model odvádí.

Vyšší úsilí stojí více a běží pomaleji. Úvaha se generuje ve formě tokenů, účtovaných jako výstupní tokeny, i když je nikdy neuvidíte, a jsou produkovány po jednom tokenu – takže zvýšení úsilí prodlužuje čekání na příchod odpovědi a zvyšuje účet. Kompromisem je větší hloubka uvažování oproti rychlosti a ceně.

Většina rozhraní vystavuje úsilí jako malý žebříček:

Příznak špatného nastavení se projevuje oběma směry. Nastavíte-li příliš nízké úsilí na složitý problém, získáte sebevědomou, povrchní odpověď, která přeskočila uvažování, jež problém vyžadoval – čte se hezky, ale je špatná způsobem, který vás později bude stát peníze. Nastavíte-li maximum pro jednorádkové přejmenování, protrpíte dlouhé přemýšlení, které neprodukuje nic, co by nejnižší nastavení nezvládlo také.

Přizpůsobte úsilí úkolu, nikoli relaci. Zvyšte ho pro část, která je skutečně složitá na uvažování, a snižte ho pro rutinní práci okolo.

Použití:

"Pořád to kazí tuto opravu souběžnosti – vysvětloval jsem to třikrát."

"Zvedni úsilí. To je chyba náročná na uvažování a ve výchozím nastavení nepřemýšlí dostatečně dlouho, než se pustí do řešení."

Atomická jednotka, kterou model čte a zapisuje. Přibližně odpovídá slovu, ale ne přesně — běžná slova tvoří jeden token, vzácná či dlouhá se dělí na více tokenů. Velikost kontextového okna, cena i latence se počítají v tokenech.

Text se mění na tokeny pomocí tokenizátoru: pevného slovníku desítek tisíc fragmentů vytvořeného před trénováním, který rozděluje vstup na posloupnost položek slovníku. Model nikdy nevidí znaky ani slova — každý text se při vstupu převede na tokeny a predikce dalšího tokenu vytváří výstup při odchodu po jednom tokenu.

Orientačně odpovídá token asi třem čtvrtinám anglického slova, takže tisíc tokenů je přibližně 750 slov. Kód je méně předvídatelný: běžná klíčová slova a obraty se tokenizují úsporně, zatímco generované identifikátory, hashe, bloky base64 a minifikovaný výstup se rozpadají na mnoho tokenů na jedno „slovo“. Platí, že text, který se často objevoval ve zdrojových datech tokenizátoru, má krátké a efektivní kódování; vzácný text se rozseká na mnoho malých částí. Hash jako `a3f9c2e1` se nikde nevyskytoval, takže se rozdělí na mnoho tokenů, zatímco `function` je jeden. Proto může i malý soubor plný neobvyklých řetězců zabrat překvapivou část kontextového okna.

Tokeny jsou jednotkou, ve které se měří všechno ostatní. Cena je za token — poskytovatelé zvlášť účtují vstupní tokeny a výstupní tokeny. Rychlost se měří v tokenech za sekundu, protože výstup vzniká po jednom tokenu. A kontextové okno má pevný počet tokenů, takže počet tokenů vašich souborů rozhoduje o tom, kolik se jich vejde.

Nepoužívat: „slovo“ — hranice tokenů neodpovídají hranicím slov a důležité jsou jednotky tokeny za sekundu a tokeny za dolar.

Použití:

„Jak velký bude tento prompt?“

„Prožeň ho tokenizátorem — schéma je kompaktní, ale klíče JSON jsou nezvyklé, takže se rozdělí na více tokenů, než čekáš.“

To, co model skutečně dělá. Z daného kontextu vybere jeden další token, připojí ho a běží znovu. Každý výstup — věta, volání nástroje, tisíciřádkový soubor — vzniká po jednom tokenu. Jiný režim fungování model nemá.

Každý krok funguje stejně: tokeny v kontextovém okně projdou parametry, které vytvoří pravděpodobnost každého tokenu ve slovníku — tento další token je velmi pravděpodobný, jiný méně. Jeden token se z těchto pravděpodobností vybere, připojí se a cyklus se zopakuje s o něco delším kontextem. Tento výběr způsobuje různé výstupy stejného promptu v různých bězích: nedeterminismus je součást mechanismu, nikoli dodatečná chyba.

Pochopení tohoto mechanismu vysvětluje jinak zvláštní chování. Model před vytvořením tokenu neověřuje, zda je pravdivý, ale jen zda je pravděpodobný — v tom tkví kořen halucinací. Ke každému tokenu se průběžně zavazuje, takže sebejistá úvodní věta může odvést zbytek odpovědi špatným směrem. A protože výstupní tokeny vznikají striktně po jednom, rychlost generování určuje spodní mez času práce každého agenta.

Použití:

„Jak se agent ‚rozhodne‘ zavolat nástroj?“

„Nerozhoduje — od začátku do konce jde o predikci dalšího tokenu. Volání nástroje je jen strukturovaný řetězec, který harness rozparsuje z proudu výstupu.“

Stejný vstup může vytvořit jiný výstup. Spusťte model dvakrát s totožným kontextem a můžete dostat dvě různé odpovědi — někdy se liší slovem, jindy celým přístupem. Nemusí se přitom změnit nic ve vašem kódu.

Je to vlastnost generování textu modely i způsobu, jak poskytovatelé modelů obsluhují požadavky. Při inferenci model vytváří pravděpodobnostní rozdělení možných dalších tokenů, z něhož se jeden vybere — obvykle záměrně s určitou náhodností, protože trvalý výběr nejpravděpodobnějšího tokenu vede k opakujícímu se a méně kvalitnímu textu. Jeden jinak vybraný token na začátku odpovědi změní všechny další, a tak se jediné odlišné slovo může změnit v úplně jiný postup. Další proměnlivost přidává provoz poskytovatele: požadavky se dávkují na sdíleném hardwaru a drobné rozdíly ve výpočtech s plovoucí čárkou mezi dávkami mohou rozhodnout těsný souboj dvou tokenů. Neexistuje nastavení, které by to celé odstranilo.

U stejného úkolu čekejte od agenta rozptyl výsledků. Většina odpovědí spadá do rozumné zvonové křivky kvality — proto je nedeterminismus vůbec snesitelný — ale krajní výsledky existují: některé dny bude model působit bystře, jiné úplně mimo. Stejný úkol, jiné hody kostkou. Má to dva praktické důsledky. Opakovaný pokus je oprávněná strategie: neúspěch je jeden výběr z rozdělení a nový pokus o tentýž úkol může prostě dopadnout lépe. A ověřování je důležitější než u deterministických nástrojů — chování agenta nelze otestovat jednou a spoléhat na opakování, takže automatické kontroly musí zachytit špatné výsledky.

Dávejte pozor, abyste si kolem toho nevytvářeli příběhy. Lidé hledají vzorce a série špatných běhů může působit jako důkaz, že „se model tento týden zhoršil“. Obvykle jde jen o rozdělení výsledků.

Použití:

„Claude je dnes hrozný. Vydali horší verzi?“

„Asi ne — výstup modelu je nedeterministický. U stejného úkolu budou dobré i špatné dny. Zkus to zítra znovu, než začneš hledat příčinu.“

Cokoli, co poskytuje model pro inferenci. Obvykle vzdálená služba (Anthropic, OpenAI, Google), ale může být i místní — Ollama, LM Studio nebo llama.cpp na vašem počítači. Harness model sám neprovozuje; žádá o to poskytovatele.

Poskytovatel vlastní technické zázemí: parametry žijí na jeho hardwaru a každý požadavek na poskytovatele modelu znamená, že harness odešle tokeny po síti a dostane předpovědi. Poskytovatel je tak zdrojem celé kategorie problémů chybně připisovaných modelu nebo harnessu — limitů požadavků, snížené kapacity a výpadků. Když se agent zasekne uprostřed relace nebo chybuje v každém tahu, stojí za to nejdřív zkontrolovat stavovou stránku poskytovatele.

Poskytovatel také určuje obchodní podmínky: ceny vstupních a výstupních tokenů, slevy mezipaměti prefixu a dostupné modely. Poskytovatel a tvůrce modelu mohou být jiné společnosti — Bedrock, Vertex a OpenRouter poskytují cizí modely.

Místní poskytovatelé vyměňují schopnosti za kontrolu: modely, které se vejdou na vlastní hardware, jsou mnohem menší než špičkové, ale nic neopouští počítač a neplatí se za tokeny.

Použití:

„Můžeme to pro klienta s oddělenou sítí provozovat offline?“

„Vyměň poskytovatele modelu za místního — Ollama nebo llama.cpp na jeho stroji. Harnessu je to jedno, jen osloví jiný endpoint.“

Všechno kolem modelu, co z něj dělá agenta: nástroje, systémová výzva, správa kontextového okna, oprávnění, háčky (hooks). Claude.ai a Claude Code běží na stejném modelu, ale chovají se jinak, protože se liší jejich obálky (harnesses).

Samotný model dělá jedinou věc: přijme text a vydá text. Nedokáže číst soubor, spustit příkaz ani si vzpomenout na poslední kolo. Obálka (harness) zajišťuje toto všechno. Sestavuje kontext pro každý požadavek poskytovateli modelu, vykonává volání nástrojů, o která model požádá, vrací výsledky nástrojů zpět, ukládá historii relace, ptá se vás na oprávnění před rizikovými akcemi a rozhoduje, kdy provést zahuštění (compaction). Smyčka agenta – model navrhne, obálka vykoná, opakovat – je spouštěna obálkou.

To má význam pro diagnostiku. Když se chování liší mezi dvěma produkty, nebo mezi včerejškem a dneškem, proměnnou často není model – je jí obálka. Jiná systémová výzva, jiná sada nástrojů, změněné výchozí oprávnění nebo nová strategie správy kontextu – to vše mění chování bez jakékoli změny modelu. Znamená to také, že v obálce se nachází většina vaší konfigurace: soubory AGENTS.md, nastavení oprávnění a háčky jsou instrukce pro obálku, nikoli pro model.

Příklady: Claude Code, Cursor, Codex CLI – a Claude.ai, což je spíše chatovací obálka než kódovací.

Použití:

„Stejný model, proč Claude Code upravuje soubory a Claude.ai jen odpovídá na otázky?“

„Různé obálky – Claude Code má nástroje pro souborový systém, jinou systémovou výzvu a vrstvu oprávnění. Model tady není proměnná.“

Jedna zpáteční cesta z harnessu k poskytovateli modelu. Harness odesílá aktuální kontext; poskytovatel vrátí jednu odpověď (volání nástroje nebo konečnou odpověď). Jediná uživatelská zpráva může vyvolat mnoho požadavků na poskytovatele modelu, pokud agent volá nástroje — každý výsledek nástroje spouští další požadavek.

Každý požadavek nese vše: systémovou výzvu, dosavadní celou konverzaci a každý výsledek nástroje. Model je bezstavový, takže poskytovatel mezi požadavky nic neuchovává — čtyřicátý požadavek znovu odešle to, co odeslal požadavek třicátý devátý, plus jeden další výsledek nástroje. Mezipaměť prefixů existuje proto, aby bylo toto opakování finančně dostupné.

Požadavek je zároveň jednotkou účtování. Vstupní tokeny, výstupní tokeny a slevy na mezipaměti se počítají za každý požadavek zvlášť, což je důvod, proč zdánlivě nevinná otázka může stát překvapivě mnoho peněz: náklady nejsou úměrné vaší zprávě, jsou úměrné počtu požadavků vynásobenému velikostí kontextu, který každý z nich nese.

Vyplatí se udržovat požadavek oddělený od kola. Kolo je jedna výměna s vámi a jedno kolo – „oprav selhávající test“ – se odehrává jako řetězec požadavků:

Šest požadavků na jedno kolo – každý z nich znovu odesílá celý kontext. Když přemýšlíte, kam se poděly tokeny, počítejte požadavky, nikoli kola.

Použití:

„Jedna otázka spálila čtyřicet tisíc tokenů?“

„Podívej se na volání nástrojů – dvanáctkrát grep, osmkrát čtení, čtyřikrát úpravy. Každý výsledek nástroje spouští další požadavek na poskytovatele modelu a prefix celé relace se pokaždé odesílá znovu.“

Tokeny, které harness posílá při každém požadavku na poskytovatele modelu — systémový prompt, historii konverzace, výsledky nástrojů, všechno, co model čte před psaním. Účtují se levněji než výstupní tokeny, protože jejich zpracování stojí méně než tvorba výstupních tokenů.

Při programování s AI tvoří vstupní tokeny většinu účtu. Model je bez stavové paměti, takže každý tah znovu posílá celou relaci jako vstup: první zprávu, všechny odpovědi i všechny dosavadní výsledky nástrojů. Vstup padesátého tahu obsahuje předchozích devětačtyřicet. Jediný požadavek může vytvořit několik set výstupních tokenů, ale znovu poslat sto tisíc vstupních tokenů nahromaděné historie.

Mezipaměť prefixu snižuje cenu: historie přesně odpovídající předchozímu požadavku se účtuje jako levné tokeny z mezipaměti, nikoli plný vstup. Pokud vstup stále bolí, je třeba zmenšit opakovaně posílaný obsah — mezi úkoly vymazávat nebo kompaktovat.

Použití:

„Účet je vysoký, ale agent skoro nic nepíše.“

„To jsou vstupní tokeny — každý tah znovu posílá celou relaci. Bez mezipaměti prefixu platíš historii znovu při každém požadavku.“

Tokeny, které model generuje zpět. Účtují se vyšší sazbou než vstupní tokeny — běžně kolem pětinásobku — protože jejich tvorba vyžaduje více výpočtů.

Počítá se všechno, co model napíše: próza, kterou čtete, vytvořený kód, volání nástrojů i rozšířené přemýšlení před odpovědí. To poslední lidi překvapuje — tokeny uvažování se účtují jako výstup, i když je harness často neukazuje, a zvýšení úsilí jich spotřebuje víc.

Výstupní tokeny také určují tempo relace. Model čte vstup rychle, ale výstup generuje po jednom tokenu, takže když tah působí pomalu, téměř vždy se píše výstup, nikoli čte vstup. Dlouhé čekání obvykle znamená dlouhou odpověď.

Použití:

„Relace refaktoringu pálí kredit, i když jsou vstupy malé.“

„Agent přepisuje celé soubory místo záplat. Výstupní tokeny stojí asi pětkrát víc než vstupní — nech ho vytvářet jen úpravy a účet klesne.“

Úložiště na straně poskytovatele, díky němuž mohou po sobě jdoucí požadavky na poskytovatele modelu přeskočit opětovné zpracování společného začátku. Když začátek požadavku odpovídá začátku nedávného požadavku — stejný systémový prompt, stejná historie až do určitého bodu — poskytovatel znovu využije předchozí práci a tyto tokeny účtuje jako tokeny z mezipaměti za výrazně nižší sazbu.

Mezipaměť se vyplatí, protože relace rostou přidáváním na konec. Každý požadavek znovu posílá celou historii jako vstupní tokeny (důvod vysvětluje příslušné heslo) a v běžné relaci se historie mění jen na konci — každý požadavek obsahuje předchozí obsah a několik nových zpráv. Poskytovatel zpracuje dlouhý společný začátek jednou, uloží výsledek a pokračuje od konce tohoto prefixu. Bez mezipaměti by se v relaci s 50 tahy platilo za zpracování prvního tahu padesátkrát.

Mezipaměti také vyprší platnost. Jak dlouho záznam zůstane aktivní, záleží na poskytovateli modelu — obvykle jde o minuty, nikoli hodiny. Pokud relaci necháte nečinnou déle, další požadavek jednou znovu sestaví prefix za plnou cenu, než se ukládání obnoví. To je hlavně starost tvůrce harnessu; uživatel vidí především to, že požadavky po dlouhé pauze stojí více než před ní.

Použití:

„Proč uprostřed relace vyskočil účet?“

„Harness začal při každém tahu vkládat do systémového promptu aktuální čas. Mezipaměť prefixu se přeruší u prvního změněného tokenu, takže každý další požadavek byl účtován plnou sazbou.“

Vstupní tokeny, které si poskytovatel uložil z předchozího požadavku na poskytovatele modelu, aby je nemusel znovu zpracovat. Když navazující požadavky sdílejí prefix, poskytovatel využije práci prostřednictvím mezipaměti prefixu a uloženou část účtuje výrazně levněji. Díky tomu jsou dlouhé relace dostupné — bez toho by každý tah znovu platil celou historii.

Důvod spočívá v účtování relací. Model je bez stavové paměti, takže každý požadavek znovu posílá celou konverzaci — systémový prompt, každou zprávu i každý výsledek nástroje — jako vstupní tokeny. V padesátém tahu každý požadavek nese historii padesáti tahů a pokaždé byste ji celou platili plnou sazbou. Mezipaměť mění výpočet: tokeny už zpracované v totožném prefixu se účtují jako tokeny z mezipaměti, často za desetinu vstupní sazby nebo méně. V dlouhé relaci většinu odesílaného tvoří tokeny z mezipaměti a účet zůstává rozumný.

Příklad ukazuje, kdy se tokeny ukládají a kdy ne. Každé písmeno představuje blok konverzace; každý požadavek posílá dosavadní konverzaci:

Mezipaměť je křehká konkrétním způsobem: porovnává přesné prefixy. Pokud se dříve v konverzaci cokoli změní — harness přeuspořádá obsah, aktualizuje se časová značka, změní se reprezentace souboru — od tohoto bodu už shoda neplatí a vše další se účtuje plnou vstupní sazbou. Po několika minutách nečinnosti mezipaměť také vyprší, takže relace obnovená po dlouhé pauze jednou znovu zaplatí svou historii. Když cena relace bez zjevné příčiny vyskočí, porovnejte ve výkazu tokeny z mezipaměti se vstupními — porucha se projeví nejdřív tam.

Použití:

„Dlouhé relace stojí hrozně moc — osm dolarů za refaktoring.“

„Zkontroluj tokeny z mezipaměti. Pokud harness mezi tahy přerovnává systémový prompt nebo soubory, prefix se přeruší a každý požadavek znovu platíš plnou vstupní sazbou.“

Nepřenáší žádné informace dopředu. Model je bezstavový napříč požadavky poskytovatele modelu — každý požadavek odesílá znovu celé kontextové okno, protože model nemá způsob, jak vidět cokoliv jiného. Agent je ve výchozím nastavení bezstavový napříč relacemi: nová relace začíná prázdná, bez jakékoliv stopy po těch předchozích. Protějšek k stavový.

Samotný model je trvale bezstavový: jeho parametry jsou po trénování zmrazené a nic, co uděláte při inferenci, je nezmění. Model se z vašich oprav neučí, nepamatuje si, že mu bylo včerejší den řečeno totéž, a nepoznává vás — bez ohledu na to, jak moc konverzace takto působí. Pocit kontinuity v rámci relace vytváří řídicí vrstva, která uchovává přepis a odesílá jej znovu s každým požadavkem. Model si konverzaci nepamatuje; on ji znovu čte.

Praktický důsledek: pokud chcete, aby si něco pamatoval napříč relacemi, musíte to zapsat někam, odkud si to agent zase přečte. To jsou soubory AGENTS.md, paměťové systémy a artefakty předání — soubory, které se načítají do kontextu budoucích relací a nahrazují paměť, kterou model nemá. Když agent neustále opakuje chybu, kterou jste už dříve opravili, otázkou není, proč se neučil — to neumí —, ale kam by měla být tato oprava zapsána, aby si ji každá budoucí relace přečetla.

Použití:

„Proč pokaždé, když vymažu, zapomene na tu konvenci?“

„Model je bezstavový — nová relace začíná prázdná. Pokud chcete, aby se to přeneslo, zapište to do souboru AGENTS.md nebo do souboru paměti, který řídicí vrstva načte na začátku relace.“

Relevantní informace, k nimž má agent právě přístup. Abstraktní pojem — nikoli surový vstup modelu (to je kontextové okno) ani průběžná historie (to je relace), ale to, co agent ví a co je podstatné pro úkol. „Načíst něco do kontextu“ znamená přidat to do této množiny; „kontextové inženýrství“ je obor jejího sestavování.

Tyto tři pojmy lze jasně oddělit:

Rozlišení je důležité, protože kontext měří kvalitu, nikoli množství. Kontextové okno může být skoro plné a kontext přesto špatný — tisíce tokenů zastaralých výstupů nástrojů bez vztahu k aktuálnímu úkolu. Může být i téměř prázdné a kontext výborný: jediná typová definice, na které úkol závisí.

Většina běžných selhání má původ v kontextu. Když si agent vymyslí API, odporuje rozhodnutí nebo hádá schéma, první otázkou je, co měl tehdy v kontextu — obvykle relevantní fakt nebyl načten nebo zapadl kvůli zhoršování pozornosti. Řešením je cílený výběr: načíst, co úkol potřebuje, a vynechat, co nepotřebuje.

Použití:

„Pořád si vymýšlí pole, která v typu nejsou.“

„Soubor s typem nemá v kontextu — čte místa volání a hádá. Nejdřív načti definici.“

Všechno, co model vidí při každém požadavku poskytovateli modelu. Konečné, specifické pro daný model a jediný povrch, přes který model cokoli vnímá.

Je to jediná sekvence tokenů: systémová výzva, dosavadní konverzace, každý výsledek nástroje, který obálka (harness) vrátila zpět. Pokud je něco v této sekvenci, model to může použít; pokud to tam není, model neví, že to existuje – ne vaše kódová základna, ne soubor, který jste upravili včera, ne instrukce, kterou jste dali před třemi relacemi. Cokoli mimo okno musí být přнесеno dovnitř, obvykle pomocí volání nástroje, než to může cokoli ovlivnit.

Konečné znamená, že se plní. Každé kolo přidává další – vaše zprávy, odpovědi modelu, výsledky nástrojů – a dlouhá relace nakonec narazí na limit, což vynutí zahuštění (compaction) nebo vyčištění. Znamená to také, že všechno v okně spolu bojuje: každý token, který načtete, je o jeden méně dostupný pro zbytek a obsah, který jste nepotřebovali, stále zabírá pozornost modelu. Praktickým přístupem je brát okno jako rozpočet – načíst, co úkol potřebuje, a zbytek nechat stranou.

Vyhněte se: „paměť“ – kontextové okno je pracovní stav a nepřetrvává napříč relacemi. Paměť je samostatný koncept vrstvený navrch.

Použití:

„Můžu prostě vložit celý monorepo do promptu?“

„Kontextové okno má 200 tisíc tokenů – to je možná pětina repa. Vyberte soubory, kterých se úkol dotýká, a zbytek nechte za voláním nástroje.“

Přenáší informace dopředu. Relace si zachovává stav napříč koly — kontext se v průběhu relace hromadí, což je důvod, proč dlouhé relace sklouzávají do zóny hlouposti. Agenta lze přimět, aby si zachoval stav napříč relacemi, a to přidáním paměťového systému, který ukládá informace do prostředí a na začátku budoucích relací je opět načte. Model nemá stav nikdy; jakákoliv zdánlivá kontinuita je způsobena tím, že řídicí vrstva znovu vkládá kontext. Protějšek k bezstavový.

Kde stav žije na jednotlivých vrstvách:

Stavovost každé vrstvy je tvořena opětovným čtením něčeho uloženého o vrstvu níže: relace působí souvisle, protože řídicí vrstva znovu odesílá historii zpráv bezstavovému modelu, a agent si pamatuje informace napříč relacemi, protože řídicí vrstva znovu načítá soubory z prostředí. V samotném modelu není nikdy uložen žádný stav.

Stav není vždy žádoucí. Vše, co se přenáší dopředu, ovlivňuje to, co přijde potom, takže chybný předpoklad učiněný na začátku relace se přenese také. Vymazání je záměrná akce, při které se zahodí stav relace a začne se od toho, co je zapsáno.

Použití:

„Pamatuje si moje preference ze včerejška – znamená to, že se je model naučil?“

„Ne, agent má stav, protože je řídicí vrstva zapsala do souboru paměti a na začátku relace je znovu načetla. Samotný model včerejšek vůbec neviděl.“

Model vybavený nástroji, systémovou výzvou a kontextovým oknem, který střídavě provádí kroky s uživatelem. Claude Code je agent. Cursor je agent. Claude.ai je agent. Agent je to, s čím ve skutečnosti mluvíte – je to model v pohybu, konfigurovaný pro určitý účel.

Na rozdíl od většiny termínů v tomto slovníku „agent“ neoznačuje mechanickou část. Model je soubor parametrů; obálka je software, na který můžete ukázat. Agent není ani jedno – je to jednotka, se kterou mluvíte. Lidé neustále antropomorfizují umělou inteligenci a agent je touto antropomorfizovanou jednotkou: věc, které delegujete úkoly, věc, která čte vaši zprávu a odpovídá, to „ono“ ve větě „ono to zase rozbilo sestavení“. Když řeknete, že agent něco udělal, myslíte tím, že to udělala kombinace modelu a obálky, ale oslovujete tuto kombinaci jako jediného aktéra.

Myšlenka je starší než tato vlna AI. Softwaroví agentech – programy, kterým delegujete cíl a které jednají vaším jménem – jsou konceptem tak dlouho, jak dlouho existuje AI.

Vyhněte se: „AI“, „bot“ (příliš nejasné – skrývají, zda máte na mysli parametry, nebo věc opatřenou obálkou).

Použití:

„Kterého agenta používáš na migraci?“

„Claude Code lokálně, Cursor pro práci s UI – pod tím je stejný model, ale různé obálky.“

Pokyny, které harness připojuje před každý požadavek na poskytovatele modelu — trvalé zadání agenta: kdo je, jak se má chovat, které nástroje smí volat a jaké konvence má dodržovat. V rámci relace bývají stabilní.

Systémový prompt píše dodavatel harnessu, nikoli vy, a v programovacích harnessích je rozsáhlý — často jde o desítky tisíc tokenů pravidel chování, popisů nástrojů a řešení okrajových případů, které se v každém tahu platí jako vstupní tokeny. Vaše vlastní trvalé pokyny jej doprovázejí: soubory jako AGENTS.md se na začátku relace načítají vedle systémového promptu, takže model čte zadání dodavatele i vaše ještě předtím, než uvidí vaši zprávu.

Protože je v každém požadavku totožný, tvoří začátek mezipaměti prefixu — i proto jej harnessy nechávají stejný po celou relaci místo průběžných úprav.

Modely jsou trénovány tak, aby systémový prompt upřednostňovaly před zprávami uživatele. Když tedy agent trvá na konvenci, kterou jste nikdy nepožadovali, nebo formátuje výstup způsobem, který se vám nedaří změnit, obvykle poslouchá systémový prompt — a vaše zpráva tento spor prohrává. Některé harnessy lze přizpůsobit: umožňují plný přístup k systémovému promptu, abyste mohli přečíst, co se agentovi skutečně říká, a změnit to.

Použití:

„Dva harnessy, stejný model, ale na stejný prompt úplně jiné chování.“

„Jiné systémové prompty. Jeden je vyladěný na stručné úpravy kódu, druhý na vysvětlování — rozdíl vzniká tam, ještě než dorazí tvoje zpráva.“

Jedno ohraničené kolo interakce s agentem. Začíná prázdné, hromadí zprávy, výsledky nástrojů a přečtené soubory a končí, když je vymazáno, zavřeno nebo zkompaktováno do nové relace. Relace je to, co vyplňuje kontextové okno: pokud je kontextové okno krabice, relace je to, co ji pomalu naplňuje. Práce příliš velká pro jediné kontextové okno musí být rozdělena mezi relace.

Historie zpráv relace je pracovní pamětí agenta. Model je bezstavový, takže vše, co si zdánlivě pamatuje – na co jste se ptali, co říkaly testy, co se rozhodl před třemi tahy – je v historii zpráv odesílané při každém požadavku poskytovateli modelu. Cokoliv není v relaci, pro agenta neexistuje.

Tato paměť končí relací. Nová relace začíná od nuly: agent, který na konci včerejší relace dobře znal vaši kódovou základnu, z toho dnes ráno nezná nic. Co přežije, je souborový systém – soubory zapsané během jedné relace mohou být přečteny v následující, což je to, na čem závisí předávky, paměťové systémy a AGENTS.md.

Sami si zvolíte, kde relace končí. Vše v relaci ovlivňuje každý pozdější tah, takže nesouvisející úkoly provedené v jedné relaci zanechávají zbytek, který ovlivňuje další odpověď. Jeden úkol na relaci udržuje kontext relevantní; dokončení úkolu je přirozeným bodem pro vymazání.

Použití:

„Jak dlouho může jedna relace běžet, než se zhroutí?“

„Záleží na práci – soustředěný refaktoring zůstává ostrý déle než otevřený výzkum. Jakmile relace nabobtná, předejte ji nebo zkompaktujte, netlačte to na sílu.“

Jedna uživatelská zpráva plus všechno, co agent udělá jako reakci, až do okamžiku, kdy řízení vrátí uživateli. Obsahuje jeden nebo více požadavků na poskytovatele modelu — v případě, že agent volá nástroje, jich může být mnoho. Doplňující otázka uzavírá kolo; vaše odpověď otevírá další. Hierarchie je relace > Kolo > Požadavek na poskytovatele modelu.

To, co dělá kolo hodným pojmenování, je fakt, že jeho délku určuje agent, nikoli vy. Předáte jednu zprávu; agent se rozhodne, kolik volání nástrojů zřetězí, než vrátí řízení. Kolo může být odpovědí o jedné větě nebo dvaceti minutami čtení, úprav a pouštění testů. Jde o stejnou vlastnost ze dvou úhlů: dlouhá kola umožňují práci mimo klávesnici (AFK) a dlouhá kola jsou také místem, kde se věci bez dozoru mohou zvrtnout — než agent vrátí řízení, může se velmi vzdálit tomu, co jste měli na mysli.

Kolo je také přirozenou jednotkou pro řízení směru. Všechno uvnitř kola probíhá bez vás; mezery mezi koly jsou místem pro přesměrování. Většina harnessů to zmírňuje: můžete zasáhnout uprostřed kola, agenta zastavit a přesměrovat, nebo napsat zprávu během jeho práce, která se přečte po dokončení kola. Pokud zjistíte, že nejste opakovaně spokojeni s tím, kde kola končí, řešením bývá obvykle vyžádat si kratší kola — nejprve plán, krok za krokem — a vyměnit autonomii za častější mezery pro zasahování.

Použití:

„Jedno kolo trvalo dvě minuty?“

„Uvnitř toho kola provedl čtrnáct volání nástrojů — každé představuje samostatný požadavek na poskytovatele modelu. Latence se hromadí, než agent konečně vrátí řízení zpět vám.“

Svět, na který agent působí — cokoli mimo harness, co agent vnímá prostřednictvím výsledků nástrojů a mění pomocí volání nástrojů. Harness agenta provozuje; prostředí je to, v čem agent pracuje. Soubor jako `AGENTS.md` je v prostředí; harness jej načítá do kontextového okna. Souborový systém je nejběžnějším typem prostředí, ale nikoli jediným: prostředím může být databáze, vzdálené API i relace prohlížeče.

Agent prostředí vidí pouze tehdy, když se podívá. Všechno, co o něm ví, přišlo ve výsledku nástroje, takže jeho obraz tvoří sbírka snímků platných v okamžiku pořízení. Pokud se soubor po přečtení změní — ručně jej upravíte nebo jej znovu vytvoří sestavení — agent dál uvažuje nad zastaralou kopií, dokud jej něco nepřiměje číst znovu. Když agent sebejistě popisuje soubor, který už vypadá jinak, obvykle se změnilo prostředí, ale ne snímek.

Prostředí je také trvalou vrstvou — jedinou, která je vždy stavová. Kontext relace po jejím skončení zmizí, ale soubory zapsané do prostředí zůstávají pro další relaci — právě na tom závisejí paměťové systémy, předávací artefakty a `AGENTS.md`. Všechno, co má agent vědět i zítra, musí skončit v prostředí.

O velikosti prostředí rozhodujete vy. Izolované prostředí je zmenšuje a omezuje dosah agenta; přidání nástroje jej rozšiřuje a zpřístupní databázi či API. Uvnitř hranice je vše, co agent může vnímat a měnit; vně ní pro agenta nic neexistuje. To, jak dobře je prostředí připravené pro jeho práci, je AX kódové základny.

Nepoužívat: „prostředí“ ve významu běhového prostředí nebo samotného harnessu — harness je obal, prostředí je pracovní prostor.

Použití:

„Agent nevidí schéma stagingové databáze.“

„Zapoj ji do prostředí — dej mu nástroj `psql` omezený na čtení ve stagingu. Harness je v pořádku, jen nemá s čím pracovat.“

Strom souborů a adresářů, ze kterých agent čte, do kterých zapisuje a v rámci kterých spouští – výchozí druh prostředí pro kódovacího agenta. AGENTS.md, schopnosti, zdrojový kód, sestavovací skripty a konfigurace nástrojů – to vše žije v souborovém systému. Když harness „začne ve vašem projektu“, odkazuje agenta na souborový systém.

Agent se ho dotýká pouze prostřednictvím volání nástrojů – čtením souboru, zápisem souboru, spuštěním příkazu shellu. Nic na disku není v kontextovém okně, dokud to volání nástroje nenačte, což umožňuje agentovi pracovat v repozitáři mnohem větším, než je okno: souborový systém drží všechno, kontext drží pouze to, co aktuální úkol přečetl. Některé harnessey ve výchozím nastavení načítají názvy souborů aktuálního adresáře do kontextového okna – nikoli obsah, pouze strom –, které fungují jako kontextové ukazatele: agent vidí, co existuje, a čte soubory, které potřebuje.

A je to sdíleno s vámi. Soubory, které agent upravuje, jsou ty samé, které otevíráte ve svém editoru a porovnáváte v gitu – souborový systém je společným pracovním prostorem, kde kontrolujete, co agent udělal.

Použití:

"Proč to nenačítá můj soubor AGENTS.md?"

"Běží to proti jinému souborovému systému – sandbox připojil nadřazený adresář, nikoli kořen projektu. Přesměrujte harness."

Funkce, kterou harness poskytuje pro agent k volání – Read, Write, Bash, Search. Nástroje představují způsob, jakým agent vnímá environmenta působí na něj: nemůže prostředí vidět jinak než prostřednictvím tool resultsa nemůže jej měnit jinak než pomocí tool calls. Každé volání nástroje stojí další model provider request, protože výsledek se musí vrátit modelu, než se může rozhodnout, co dělat dál.

Nástroje, které většina programovacích agentů obsahuje:

Nástroj je definován třemi věcmi: názvem, popisem toho, co dělá, a schématem svých parametrů. Harness odesílá tyto definice model u s každým požadavkem a model si vybírá nástroj stejným způsobem, jakým produkuje vše ostatní – zápisem tokens, v tomto případě strukturovaného volání s argumenty. Model nikdy sám nic nevykonává; harness přečte volání, spustí funkci a odešle zpět výsledek.

Seznam nástrojů určuje, co agent může dělat. Schopný model s úzkou sadou nástrojů je omezeným agentem: všechno bude směrovat přes to, co má k dispozici, což je důvod, proč se agenti tolik spoléhají na Bash – shell je jeden nástroj, který dosáhne do větší části systému. Chcete-li agentovi čistě přidat schopnost, přidejte pro ni nástroj; MCP je standard pro připojování nástrojů z vnějšku harnessu.

Definice nástrojů zabírají context při každém požadavku, takže velká sada nástrojů má stálé náklady ještě před zavoláním jakéhokoli nástroje – a mnoho podobně popsaných nástrojů zhoršuje schopnost modelu vybrat ten správný.

Použití:

„Může agent provádět dotazy přímo na stagingu?“

„Přidejte `psql` nástroj do harnessu, s omezením pouze pro čtení na stagingu. Bez nástroje pro to je agent slepý vůči všemu mimo souborový systém.“

Výstup modelu pojmenovávající nástroj a jeho argumenty — pouze strukturovaný text. Sám o sobě nic nedělá; harness jej musí přečíst a vykonat. Model jej vytvoří v jednom požadavku na poskytovatele modelu.

Životní cyklus volání nástroje:

Jeden tah práce agenta obvykle tvoří mnoho takových navazujících oběhů.

Protože se volání generuje pomocí predikce dalšího tokenu jako všechno ostatní, může se mýlit stejně jako jakýkoli výstup modelu: neexistující cesta, přepínač, který příkaz nemá, argumenty, které jsou spíš věrohodné než správné. Harness vykoná to, co bylo napsáno, nikoli to, co bylo zamýšleno — překlep v cestě neskončí elegantní chybou, ale úpravou nesprávného souboru.

Použití:

„Tvrdil, že spustil testy, ale časové značky souborů se nezměnily.“

„Podívej se do přepisu — opravdu vytvořil volání nástroje, nebo jen popsal jeho spuštění? Model vytvoří volání, ale pokud jej harness nevykoná, nic se nestalo.“

To, co harness vrací po vykonání volání nástroje — obsah souboru, výstup příkazu, chybu. Jediný pohled agenta na prostředí. Vrací se k modelu v dalším požadavku na poskytovatele modelu, kde model rozhodne, co s ním. Volání a výsledek nástroje jsou dva konce stejné výměny v rámci jednoho tahu.

Životní cyklus výsledku nástroje:

Výsledek zůstává v kontextu po zbytek relace. Výsledky nástrojů obvykle tvoří většinu kontextu programovací relace: každé přečtení souboru, každý běh testů a každé hledání do něj vstoupí v plném rozsahu a dál zabírá tokeny, i když už dávno není užitečné. Několik velkých výsledků — podrobný protokol testů, celý přečtený generovaný soubor — může relaci posunout k hranici kontextového okna rychleji než samotná konverzace.

Protože model vidí jen tento výsledek, nemůže ověřit prostředí za ním. Pokud byl výstup zkrácen, příkaz tiše selhal nebo harness vrátil místo obsahu chybu, model uvažuje nad tím, co dostal. Když má agent zjevně chybnou představu o vašem systému, hledejte ve výsledcích nástrojů: někde v přepisu je výsledek, který říká něco jiného než vám známá skutečnost.

Použití:

„Uvažuje o tom souboru, jako by byl prázdný.“

„Nástroj vrátil zamítnutí oprávnění, nikoli obsah. Model viděl jen chybový řetězec — jiný způsob pohledu na soubor nemá.“

Model Context Protocol. Protokol pro připojování externích serverů nástrojů do harness — způsob, jakým agent získává tools nad rámec toho, co harness obsahuje. Agent nikdy „nevola MCP“; volá nástroj a harness tento nástroj shodou okolností získal ze serveru MCP. Také zpřístupňuje zdroje (data pouze pro čtení) a prompty (opakovaně použitelné šablony), ale poskytování nástrojů je hlavním účelem.

Protokol řeší problém integrace. Bez standardu by každý harness potřeboval vlastní integraci Linear, vlastní integraci Slack, vlastní integraci databáze — napsanou a udržovanou pro každou zvlášť. S MCP je integrace napsaná jednou jako server a může ji používat jakýkoliv harness kompatibilní s MCP. Harness se připojí k serveru, server inzeruje, jaké nástroje nabízí, a tyto nástroje se stanou pro agenta dostupné vedle těch vestavěných.

Cena se platí v context. Každý nástroj, který server inzeruje, přichází jako definice — název, popis, schéma parametrů — a model může volat pouze nástroje, které zná. Naivní přístup nahraje každou definici do context window předem: nainstalujete několik štědrých serverů a session začíná s tisíci tokens schémat nástrojů, aniž byste cokoliv napsali, čímž utrácíte attention budget na nástroje, které úkol nikdy nepoužije.

Mnoho harnessů to nyní zmírňuje pomocí vyhledávání nástrojů: namísto úplných definic drží kontext context pointer na dostupné nástroje — agent vyhledá nástroj podle názvu nebo účelu a načte jeho definici pouze tehdy, když ji potřebuje. Pokud váš harness toto nedělá, stále platíte počáteční náklady a vyplatí se povolit pouze ty servery, které projekt skutečně potřebuje.

Použití:

"Agent potřebuje číst tikety z Linear."

"Nakonfigurujte harness tak, aby používal server Linear MCP — zpřístupňuje rozhraní Linear API jako nástroje, které může agent volat. Ušetří vám to psaní vlastních obalů nástrojů."

To, co harness ukazuje uživateli před vykonáním předem neschváleného volání nástroje. Model vytvoří volání; harness jej místo okamžitého spuštění pozastaví a zeptá se. Po schválení ho spustí, po zamítnutí vrátí modelu odmítnutí jako výsledek nástroje. Mechanismus, kterým harness zapojuje člověka do rozhodovacího cyklu u riskantních nebo citlivých akcí.

Životní cyklus žádosti o povolení:

Zamítnutí žádosti agenta usměrňuje. Model čte odmítnutí jako kterýkoli jiný výsledek nástroje a reaguje — zkusí jiný přístup nebo se zeptá na vaši představu. Většina harnessů dovoluje k zamítnutí připojit zprávu, takže se žádost stává bodem řízení: „takto ne, použij raději migrační skript“ dorazí právě ve chvíli, kdy model rozhoduje o dalším kroku.

Cena spočívá v tom, že každá žádost synchronně čeká na vás. Agent je blokovaný do vaší odpovědi, což je v pořádku pod dohledem a problém bez něj — agenta, který neustále vyvolává žádosti, nelze nechat pracovat AFK. Ovladačem je režim oprávnění: která volání poběží volně a která se nejdřív zeptají, ideálně s izolovaným prostředím, díky němuž lze volnou množinu bezpečně rozšířit.

Použití:

„Deset minut čeká na povolení — byl jsem na schůzce.“

„To je cena zapojení člověka do cyklu. Bezpečné nástroje schval předem, aby se žádost objevovala jen u skutečně riskantních volání.“

Část režimu agenta řídící oprávnění — která volání nástrojů vyvolají žádost o povolení a která proběhnou automaticky. Původní účel režimových systémů, než k nim harnessy začaly přidávat pokyny k chování.

Harnessy nabízejí žebříček těchto režimů:

Volba úrovně je kompromisem mezi bezpečností a vyrušováním a obě krajnosti bolí. Příliš přísná pravidla z vás udělají úzké hrdlo: agent každých pár sekund zastavuje kvůli neškodnému čtení, vy automaticky schvalujete a souhlas přestane něco znamenat — bezmyšlenkovité odklikávání spojuje nejhorší z obou světů, všechna vyrušení bez ochrany. Příliš volná pravidla zase nechají agenta upravovat soubory a spouštět příkazy, které byste nejdřív chtěli vidět.

Volnější nastavení se nejlépe obhájí v izolovaném prostředí, kde je rozsah škod špatného volání nástroje omezený. Mimo ně většina lidí automaticky schvaluje čtení a u všeho nevratného zachovává člověka v rozhodovacím cyklu.

Použití:

„Zastavil se u každého grep — úplně to zabilo běh AFK.“

„Uvolni režim oprávnění pro nástroje pouze ke čtení, ale u zápisů a shellu nech dotazy. Většina žádostí o povolení při výzkumné relaci je jen šum.“

Předvolba, která formuje způsob, jakým agent funguje za běhu – sdružuje režim oprávnění s pokyny chování vloženými do systémové výzvy. Příklady: výchozí nastavení, které vyzývá k zadání při rizikových volbách, režim plánování, který blokuje úpravy a směřuje agenta k průzkumu, režim přijímání úprav, který automaticky schvaluje úpravy, režim obcházení oprávnění (hovorově režim YOLO), který automaticky schvaluje vše. Lze přepnout uprostřed relace.

Toto sdružení odlišuje režim od pouhého nastavení oprávnění. Režim oprávnění je pouze brána: rozhoduje o tom, která volání nástrojů projdou. Samotná brána vytváří agenta, který chce provádět úpravy, ale nemůže – navrhne zápis, je zablokován a zkusí jinou cestu. Vložené pokyny odstraňují tuto touhu: režim plánování nejenže blokuje úpravy, ale říká agentovi, že je ve fázi plánování, takže čte, ptá se a navrhuje namísto toho, aby se vzpíral bráně. Brána a řízení ukazují stejným směrem.

Měnit režim v průběhu úkolu lze podle toho, jak roste vaše důvěra. Stejný úkol může projít několika režimy: režim plánování, dokud se ještě tvaruje přístup, výchozí režim výzev pro první jemné úpravy, režim přijímání úprav, jakmile agent projeví pochopení změny, a režim obcházení pro spuštění bez přítomnosti uživatele AFK uvnitř sandboxu. Změna režimu vás nestojí nic: konverzace pokračuje přesně tam, kde byla, s novými oprávněními a novými pokyny. Pokud zjistíte, že schvalujete každou výzvu, aniž byste ji četli, režim je nastaven přísněji než vaše skutečná důvěra; pokud úpravy neustále odmítáte, je nastaven příliš volně.

Termíny dodavatelů: Claude Code je nazývá „režimy oprávnění“, Codex „režimy schvalování“ – oba termíny předcházejí sdružování chování.

Použití:

„Pořád upravuje soubory, když chci jen plán.“

„Přepněte do režimu plánování – zablokuje zápisy a zůstane u průzkumu.“

„A co pozdější spuštění bez přítomnosti uživatele (AFK)?“

„Režim obcházení, ale pouze uvnitř sandboxu.“

Izolované prostředí, ve kterém agent běží – kontejner, virtuální počítač (VM), dočasný souborový systém nebo shell s omezenými oprávněními. Omezuje rozsah dopadu akcí agenta: i když agent spustí destruktivní příkazy nebo načte něco škodlivého, škoda je obsažena v tomto rámci. Bezpečnostní podklad, díky kterému je AFK praktické.

Sandbox a režim oprávnění řeší stejný problém z opačných stran. Oprávnění se ptají před spuštěním akce; sandbox omezuje, kam může akce dosáhnout, pokud se spustí. Oprávnění vyžadují, abyste byli v obraze (in the loop) – každý prompt je přerušením – a relace, která se neustále ptá, je stěží autonomní. Sandbox utrácí infrastrukturu místo pozornosti: čím silnější je izolace, tím méně otázek je třeba klást.

Izolace má různé stupně:

Co žádný sandbox neobsahuje: akce, které z něj legitimně odcházejí. Agent s vašimi přihlašovacími údaji pro git může provést push; agent s přístupem k síti může volat produkční API. Než se rozhodnete, jak silnou izolaci vytvořit, rozhodněte se, co překračuje tuto hranici.

Použití:

„Chci to nechat běžet přes noc s obcházením oprávnění, ale ještě na to nejsem připravený.“

„Dejte to do sandboxu – čerstvý kontejner, žádné připojené přihlašovací údaje, žádná síť ven. Nejhorší scénář je, že odpálí svůj vlastní souborový systém a kontejner zahodíte.“

Sebedůvěřivě vyhovující model výstup. Způsobeno tréninkem: model byl utvářen tak, aby upřednostňoval odpovědi, které se lidem líbí, a lidé mají tendenci mít raději souhlas než slyšet, že se mýlí. Model se tak naučil, že souhlas je odměňován – a to i v případě, kdy je nesprávný.

Projevuje se jako:

• Podlehnutí nátlaku – odvolá správnou odpověď, když řeknete „jseš si jistý?“.
• Chválení špatného vstupu – souhlasí, že váš chybný plán je skvělý, aniž by ho analyzoval.
• Zaujaté rámování – recenze je pozitivní, když naznačíte, že jste ji napsali vy; negativní, když naznačíte, že ji napsal někdo jiný. Stejný artefakt, jiný verdikt.
• Mimikry – opakuje vaše chyby zpět jako potvrzení.

Diagnostický test: řekl by to model i bez vašeho navedení? Pokud se změnilo pouze vaše tónování nebo rámování, jde o přisluhovačství (sycophancy), nikoli o skutečný posun v analýze.

Oprava: skrývejte své preference. Formulujte prompty neutrálně – „zkontrolujte tento kód“ namísto „je tento kód dobrý?“.

Vyhněte se: používání termínu „přisluhovačství“ pro jakoukoli chybnou odpověď, která se vám náhodou zavděčí. Bez diagnostického testu nemá termín větší hodnotu než „špatně“.

Použití:

„Řekl, že můj plán refaktoringu vypadá skvěle, pak jsem se zeptal ‚jseš si jistý?‘ a celo věc vzal zpět.“

„Klasické přisluhovačství – souhlasil nejdříve, protože jste zněli sebevědomě, pak ustoupil, protože jste zněli nejistě. Kvalita plánu se nezměnila, váš tón ano. Vymažte a zeptejte se znovu, aniž byste cokoliv naznačovali.“

Jistě-chybný model výstup. Dvě varianty s různými příčinami a řešeními:

Predikce dalšího tokenu produkuje plynulý výstup bez ohledu na to, zda je podkladový fakt reálný – model nemá vnitřní signál o tom, že něco neví, takže vymyšlená metoda dorazí ve stejném jistém tónu jako ta správná. Halucinovaný kód je konstrukcí plauzibilní: je to tak, jak by API vypadalo, kdyby existovalo, což je přesně to, co způsobuje, že proklouzne zběžnou recenzí a selže až při spuštění.

Musíte vědět, na jakou variantu se díváte, protože oprava jedné zhoršuje druhou. Fakticita znamená chybějící znalost: řešením je přidání kontextu – dokumentace, definice typů, soubor. Věrnost znamená, že znalost je přítomna, ale prohrává boj o pozornost: řešením je odebrání kontextu. Pokud chybně diagnostikujete věrnost jako fakticitu a vložíte další dokumentaci, zvětšíte kontext a odchylka se ještě zhorší. Když agent udělá chybu, zkontrolujte, zda správné informace již v kontextu byly, než se rozhodnete, jaký problém řešíte.

Vyhněte se: termínu „halucinace“ jako holému synonymu pro „špatně“ – bez pojmenování varianty nemá termín žádnou diagnostickou hodnotu.

Použití:

„Zahalucinoval [`parseAsync` metodu na schématu.“

„Fakticita nebo věrnost?“

„Metoda existuje v dokumentaci, kterou jsem vložil – jen přestal číst po kole čtyřicet.“

„Pak tedy věrnost. Zkompaktnit a znovu načíst, neobtěžovat se přidáváním dalších dokumentů.“

To, co model „ví“ z trénování, uložené v jeho parametrech. Zmrazené v okamžiku trénování — model vlastní parametry nevidí ani je nemůže aktualizovat. Při stlačení se ztrácejí detaily: miliardy faktů se vměstnají do pevného počtu parametrů a ta vzácná se rozmazávají. Zdroj plynulosti u běžných témat i výmyslů u neobvyklých. Protějšek kontextových znalostí.

Parametrické znalosti nejsou uložené jako fakta. Trénování modelu nikdy nedá databázi pro vyhledávání; upravuje parametry, dokud model dobře nepředpovídá text, a model dobře předpovídající text o tématu se chová, jako by téma znal. Spolehlivost znalostí odpovídá četnosti výskytu v trénovacích datech: téma s miliony příkladů se reprodukuje přesně, u tématu s hrstkou příkladů model odhaduje podle podobných témat. Reprodukce a odhad jsou pro model stejným procesem, takže nepozná, který provádí. Smyšlená odpověď zní stejně plynule jako správná. Halucinace je chybný odhad modelu.

Parametrické znalosti také stárnou. Parametry se přestanou měnit na mezním datu znalostí, takže knihovna vydaná nebo přejmenovaná později v nich neexistuje a změněné API si pamatují ve staré podobě.

Na oba nedostatky — vzácnost i novost — platí stejné řešení: znalost nelze přidat do parametrů, a proto musí přijít jako kontextová znalost.

Použití:

„Píše bezchybný React, ale vymýšlí si metody našeho interního SDK.“

„React je v parametrických znalostech hustě zastoupen — miliony trénovacích příkladů. Tvoje SDK ne, takže model doplňuje věrohodně vypadající tvary. Načti dokumentaci SDK do kontextu.“

Datum, po němž model nemá žádné parametrické znalosti. Knihovny, API a události po tomto datu jsou pasti na smyšlené odpovědi, pokud se jejich dokumentace nenačte jako kontextové znalosti. Každé vydání modelu má vlastní mezní datum znalostí.

Tato hranice existuje kvůli způsobu vzniku modelů: trénování zapeče snímek textů do parametrů modelu, které se pak zmrazí. Model neví, že jeho znalosti mají okraj — při dotazu za hranicí neodmítne odpovědět, ale extrapoluje z nejbližší známé věci. Právě proto je tato past nenápadná: kód psaný pro starou verzi knihovny působí věrohodně, často se zkompiluje a selže až tam, kde se něco změnilo.

Řešení je vždy stejné: dostat aktuální informace do kontextu. Načíst záznam změn, odkázat na typové definice nainstalované verze nebo nechat agenta přečíst webovou dokumentaci. Cokoli v kontextu je lepší než nic v parametrech.

Použití:

„Pořád píše syntaxi SDK v3 — používáme v5.“

„Verze v5 vyšla po mezním datu znalostí. Načti její záznam změn jako kontextové znalosti, jinak bude dál vymýšlet podle starší parametrické verze.“

Fakta, která agent může číst přímo z kontextu právě teď – úkol uživatele, soubory, které agent načetl, výsledky nástrojů, obsah AGENTS.md načtený na začátku relace. Protějšek parametrických znalostí: parametrické jsou vyvolávány z parametrů; kontextové jsou čteny z okna. Halucinace jsou mnohem méně časté, když agent pracuje s kontextovými znalostmi – odpověď má přímo před sebou, není vydolovaná z rozostřené paměti.

Ze dvou typů znalostí máte pod kontrolou pouze kontextové znalosti. Parametry jsou zmrazené, takže jediný způsob, jak dát modelu znalosti, které mu chybí – interní SDK, knihovna vydaná po časovém ohraničení znalostí, rozhodnutí učiněné včera – je vložit je do kontextu. Spousta praktického programování s AI se omezuje na toto: dostat správná fakta před model v okamžiku, kdy je potřebuje.

Když se kontextové a parametrické znalosti dostanou do konfliktu, kontextové obvykle vyhrávají. Vložte aktuální dokumentaci API a model se jí bude řídit spíše než svou zastaralou pamětí na staré API – ačkoliv stará verze může stále prosakovat, zejména hluboko v dlouhé relaci. Pokud se agent neustále vrací k zastaralému vzoru, přestože je dokumentace načtena, jde o prosakování parametrických znalostí za kontextové; pomáhá zopakování opravy nebo její přesunutí blíže k práci.

Na rozdíl od parametrických znalostí něco stojí kontextové znalosti používat. Všechno načtené do okna spotřebovává tokeny a bojuje o rozpočet pozornosti modelu, takže načítání většího množství není automaticky lepší – cílem je mít v okně relevantní fakta, ne všechna fakta.

Tento termín používejte pouze při srovnání s parametrickými znalostmi; jinak říkejte jednoduše kontext.

Vyhněte se: „pracovní paměti“ – kontextové znalosti jsou to, co je v okně teď; paměťový systém je to, co do něj dostává obsah napříč relacemi. Různá měřítka, neslučujte je.

Použití:

„Proč to trefí API, když vložím dokumentaci, a vymýšlí si to, když ji nevložím?“

„S dokumentací uvnitř jde o kontextové znalosti – čtení ze stránky. Bez ní je to parametrické a vzácné koncové body se rozostří.“

Při předpovídání každého tokenu model zohledňuje všechny ostatní tokeny v kontextu — některé silně, jiné téměř vůbec. Vazba mezi dvěma tokeny je vztah pozornosti a významné dvojice („jí“ se „Sarah“ nebo volání `getUser()` s definicí `function getUser`) se ovlivňují více než nesouvisející. Kontext s N tokeny má řádově N² vztahů.

V těchto vazbách sídlí zdánlivé porozumění modelu. Když rozpozná zájmeno, je to díky silnému vztahu pozornosti mezi „jí“ a „Sarah“. Když zavolá funkci se správnými argumenty, pracuje vztah mezi místem volání a dříve přečtenou definicí. Nic se nevyhledává — při každém požadavku na poskytovatele modelu se vše pro každou dvojici znovu počítá.

U hodnoty N² se vyplatí zastavit, protože roste rychleji, než napovídá intuice:

Každá dvojice se počítá také vícekrát. Modely mají více hlav pozornosti — přesné počty špičkových modelů nejsou zveřejněny, ale padesát až sto je rozumný odhad — a každá hlava počítá vlastní podobu každého vztahu. Každá dvojice v tabulce se tedy opakuje napříč všemi hlavami. To je spousta dvojic.

Pro konkrétní úkol je důležitá jen malá část těchto vztahů. Vazba mezi vaším pokynem a kódem, který řídí, patří k té hrstce podstatných; téměř všechno ostatní je šum. A obě množiny rostou jinak: důležité vztahy zůstávají přibližně stejné, zatímco celkový počet roste s velikostí kontextu kvadraticky. U 1 000 tokenů je hledaná dvojice jedna z milionu; u 100 000 jedna z deseti miliard. To je matematika za rozpočtem pozornosti a zhoršování pozornosti je pocit, když na důležité vztahy připadá příliš malý podíl.

Použití:

„Pořád si plete dva symboly `user` napříč diffem — vypadá to na hloupou zónu.“

„Jo, vztah pozornosti mezi každým voláním a jeho deklarací soupeří s tím druhým — stejný tvar tokenu, jiné vazby. Jeden přejmenuj a dvojice se vyjasní.“

Každý token má konečné množství vlivu, které může rozdělit mezi zbytek kontextu. Velký vliv na jeden vztah zanechává méně pro ostatní. Rozpočet je na jeden token a neroste s tím, jak roste kontext, což je důvod, proč dlouhá sezení ředí vliv.

Představte si to jako signál a šum. Vaše instrukce je signál o pevné hlasitosti; každý jiný token v kontextovém okně představuje konkurující zvuk. Instrukce není tichší – je tam pořád, znak po znaku –, ale jak kontext roste, místnost kolem ní je hlučnější a poměr signálu k šumu klesá. Instrukce, která byla nejhlasitější věcí při 10 tisících tocích kontextu, je při 150 tisících pouhým hučením v pozadí. To je mechanismus stojící za degradací pozornosti: model nezapomíná, ale signál se ztrácí v šumu.

Příznak vypadá jako neposlušnost – agent zpočátku souhlasil s omezením a pak od něj ustupuje a opětovné vložení omezení pomáhá jen na chvíli. Příčinou není instrukce; je jí všechno ostatní v okně, co s ní soupeří.

To, co můžete ovlivnit, je to, co se dostane do kontextu. Obsah, který neslouží úkolu, není neutrální – je to šum pro všechno, co mu slouží. Udržujte okno malé, vyčistěte, když nahromaděný kontext přestane přinášet užitek, a zopakujte důležitá omezení místo toho, abyste spoléhali na to, že jejich dřívější zmínka vydrží.

Použití:

"Proč stále ignoruje schéma, které jsem vložil nahoře?"

"Jsme hluboko v hloupé zóně – rozpočet pozornosti každého tokenu je pevný, ale kontext neustále rostl. Signál schématu nyní soupeří s tisíci novějších tokenů."

Jak session roste, rozpočet pozornosti každého token se rozprostírá mezi více konkurentů. Signál u jakéhokoli jednoho smysluplného vztahu slábne; šum z irelevantního kontextu se tlačí dovnitř. Stejný model, stejné parametry — jen více úst ke krmení ze stejného talíře. Příčina efektu chytré zóny / hloupé zóny.

Projevuje se to tak, že se model v průběhu relace zhoršuje: omezení, která dodržoval hodinu, se začínají hroutit, znovu se ptá na věci, které mu byly sděleny, a píše kód, který ignoruje soubor, jejž si přečetl dříve. Na modelu se nic nezměnilo — jedinou proměnnou je to, nad jak velkým kontextem nyní věnuje pozornost.

Je to postupné, což ztěžuje odhalení uvnitř relace. Neexistuje žádná chyba ani prahová hodnota; každé otočení je jen o něco horší než to předchozí, a než jsou nedostatky zjevné, jste už nějakou dobu v hloupé zóně.

Zotavíte se tak, že kontext odeberete, a ne tím, že ho přidáte víc. Opětovné vložení ignorované instrukce přidá dalšího konkurenta do stejného přeplněného okna a pomůže jen na chvíli. Co funguje: vymazat a znovu načíst pouze to, co úkol potřebuje, nebo zkompaktovat, případně předat nové relaci. Klesající schopnost dodržovat instrukce berte jako signál o délce kontextu, nikoli o modelu.

Použití:

„Je hluboko v hloupé zóně — vymýšlí generika, která v souboru typů nejsou.“

„Degradace pozornosti. Definice typů jsou stále v kontextu, ale signál na nich je pohřben pod vším, co jsme od té doby přidali. Vymažte a znovu načtěte.“

Na začátku sezení je agent v „chytré zóně“ – bystrý, soustředěný, vybavování vzpomínek funguje dobře. Jak se sezení prodlužuje, sklouzává do „hloupé zóny“: je lajdáčtější, zapomnětlivější, dělá více chyb – a více věrných halucinací. Stejný model, stejný harness – jen větší kontext. Pociťovaný účinek degradace pozornosti. U špičkových modelů hloupá zóna obvykle začíná kolem 125K–150K tokenů – ačkoliv se o tom vedou debaty. Vyčistěte nebo zkomprimujte, když se sezení nafoukne; netlačte to silou dál.

Pokles je pozvolný, což usnadňuje jeho přehlédnutí. Neexistuje žádná chybová zpráva ani viditelná hranice; agent prostě začíná fungovat o něco hůře, pak znatelně hůře. Běžné známky: zapomene instrukci, kterou jste zadali před dvaceti koly, opakuje chybu, kterou již dříve opravil, nebo sebevědomě tvrdí něco, co kontext popírá. Protože je propad plynulý, obvyklou reakcí je pokračovat a věc znovu vysvětlit – což přidává další kontext a problém ještě zhoršuje.

Zóny neodpovídají limitu kontextového okna. Sezení může být hluboko v hloupé zóně a většina okna je stále volná: limitem je bod, kdy harness odmítá pokračovat, ale kvalita klesá dlouho předtím. Plánujte podle chytré zóny, nikoli podle okna – praktickým rozpočtem pro úkol jsou tokeny, se kterými agent dobře pracuje, nikoli tokeny, které technicky dokáže pojmout.

Chytrá zóna je rozpočet a nesouvisející práce jej utrácí. Každý úkol provedený v rámci sezení spotřebovává tokeny, takže zahájení druhého úkolu ve stejném sezení znamená jeho zahájení blíže hloupé zóně. Provádění jednoho úkolu na jedno sezení dává každému úkolu tu nejbystřejší část sezení. Když je jediný úkol větší než jedna chytrá zóna, rozdělte ho: předejte nebo zkomprimujte na přirozené hranici a nechte nové sezení udělat další část.

Použití:

"První tři komponenty zvládl skvěle a tu čtvrtou úplně zoral."

"Jste mimo chytrou zónu – stejný model, jen už hluboko v hloupé zóně. Zkomprimujte a znovu načtěte plán, další komponenta se vydaří."

Ukončení aktuální relace a zahájení nové. Další zpráva začíná prázdnou relací a prázdným kontextovým oknem. Obvykle iniciováno uživatelem.

Vymazání je lékem na znečištěný kontext. Relace kumuluje vše: neúspěšné pokusy, špatné odbočky, zastaralé výsledky nástrojů, opuštěné plány. Model to všechno znovu čte při každém kroku a špatná historie táhne novou práci dolů. Hluboko v dlouhé relaci se agent stává vágnějším a méně poslušným – pokyny, které jste dali jasně, jsou ignorovány, kvalita klesá a pobízení k lepšímu nepomáhá, protože šum, kterým se prohrabuje, je stále v jeho kontextu. Vymazání odstraní tento šum.

Vymazání nesmaže konverzaci. Většina rozhraní uchovává historii relace ve vašem počítači, takže přepis je stále k dispozici ke čtení nebo obnovení. Pryč je však pracovní stav agenta: model je bezstavový, takže nová relace neví nic z toho, co věděla stará. Pokud relace obsahuje rozhodnutí nebo postup, který bude další relace potřebovat, nechte agenta nejdříve zapsat předávací artefakt a teprve poté spusťte novou relaci odkazem na něj.

Porovnejte s kompaktací, která shrne relaci do nového kontextu namísto zahájení od prázdna. Vymazání je drsnější nástroj: nic se nepřenese, včetně zbytků.

Použití:

"Zaseknulo se to v smyčce na selhávajícím testu."

"Prostě to vymaž — začni novou relaci s dokumentem plánu a testovacím souborem. Nemá smysl bojovat s existujícím kontextem."

Přenesení kontextu agenta z jedné relace do jiné. Způsob přenosu se liší — může jít o písemný předávací artefakt, souhrn v paměti (kompakci) a další. Liší se od vymazání, při němž se nepřenáší nic. Důvody jsou různé: změna role (plánovač → implementátor), zahájení běhu AFK, rozvětvení do souběžných relací nebo uvolnění místa v kontextovém okně.

Přijímající relace začíná s nulovým kontextem — model je bez stavové paměti a z původní relace nevidí nic. Všechno potřebné pro další relaci se musí výslovně přenést; vše ostatní zmizí. „Bez cesty zpět“ je omezení, které podobu přenosu určuje: nová relace se nemůže staré zeptat, co tím myslela, takže přenesený materiál musí obstát sám.

Viditelným selháním špatného předání je znovuotevírání sporů: nová relace rozebírá rozhodnutí už uzavřená v původní, protože přenos zaznamenal co, ale ne proč. Předání posuzujte podle toho, co by s ním zvládla relace s nulovým kontextem.

Použití:

„Plánovací relace už je těžkopádná — mám prostě pokračovat?“

„Předej práci. Napiš rozhodnutí do dokumentu, vymaž kontext a začni implementaci v nové relaci, která si jej přečte.“

Zdroj pravdy v původním formátu – kód, přepis konverzace, surový log, skutečná odpověď API. Nejde o popis věci, ale o samotnou věc. Protějšek sekundárního zdroje.

Pokud chcete vědět, co vaše codebase dělá, primárním zdrojem je kód. Dokumentace, diagram architektury a soubor README jsou pouze jejími popisy – v době napsání byly přesné, ale od té doby žijí vlastním životem. Když agent s jistotou tvrdí něco špatného o vašem projektu, musíte se zeptat, z jakého zdroje vycházel: agent, který četl dokumentaci, přebírá její zastaralost; agent, který četl kód, čte aktuální pravdu.

Nákladem je to, co brání tomu, aby byly primární zdroje výchozí volbou. Načtení jednoho z nich do kontextového okna je drahé – celý soubor, celý přepis, každý token účtovaný jako vstup, který bojuje o rozpočet pozornosti. Za tuto cenu získáváte úplnost: nic nebylo předem vyfiltrováno cizím úsudkem o tom, co bylo důležité. Shrnutí napsané minulý měsíc nemůže obsahovat detail, který se dnes ukázal jako podstatný; primární zdroj ho ale stále má.

Sáhněte po primárním zdroji, když záleží na přesnosti – přesná signatura, skutečná chyba, řádek, který ji vyvolá. Velká část správy kontextu spočívá v rozhodování, kdy se vyplatí zaplatit za primární zdroj a kdy stačí sekundární zdroj.

Použití:

"Agent říká, že logika opakování pokusů se exponenciálně prodlužuje, ale já vidím, jak bombarduje koncový bod."

"Přečetl to z návrhové dokumentace. Nasměrujte ho na skutečný modul pro opakování pokusů – když záleží na chování, pracujte s primárním zdrojem."

Záznam o primárním zdroji, o jeden krok odstraněný — dokumentace popisující kód, shrnutí popisující přepis, zpráva popisující výsledky vyhledávání. Levnější na načtení do kontextového okna než zdroj, který popisuje, a ztrátový podle návrhu: ten, kdo ho napsal, rozhodl, na čem záleží, a cokoli, co vynechal, je neviditelné pro čtenáře, který má pouze shrnutí.

Mnoho inženýrství kontextu je výroba sekundárních zdrojů. Kompaktace přeměňuje historii relace na shrnutí, které je základem pro další relaci. Subagent spálí svůj vlastní kontext při hlučném vyhledávání a vrátí krátkou zprávu. Artefakt předání shrnuje rozhodnutí relace do dokumentu, který si další relace přečte. Systémy paměti destilují to, co se relace naučila, do poznámek. Každý dělá stejný kompromis: věrnost za prostor.

Sekundární zdroje selhávají dvěma způsoby. Jsou ztrátové — shrnutí kompaktace, které ztratilo rozhodnutí o schématu, zpráva, která nezmínila okrajový případ. A dochází k jejich posunu — primární zdroj se mění a záznam ho nenásleduje, takže dokumenty popisují architekturu z minulého čtvrtletí s jistotou pro toto čtvrtletí. Když agent jedná na základě sekundárního zdroje, který selhal jedním či druhým způsobem, pracuje sebevědomě s chybnými informacemi; nápravou je vrátit ho k primárnímu zdroji.

Žádná z těchto chyb nedělá ze sekundárních zdrojů omyl. Kontextové okno je konečné a primární zdroje jsou drahé; bez shrnutí, zpráv a dokumentů o předání se nic velkého nevejde. Dovednost spočívá v tom, vědět, které detaily mohou ztrátu přežít — a ověřit je oproti primárnímu zdroji, když to jeden nedokáže. Dobře vytvořený sekundární zdroj nese kontextový ukazatel zpět k originálu — shrnutí, které uvádí přepis, ze kterého pochází, dokument, který uvádí soubor, jejž popisuje —, takže když záznam nestačí, čtenář může sledovat ukazatel namísto práce se ztrátou.

Použití:

„Dokument o předání říká, že ověřování je hotové, ale nová relace stále nachází nefunkční obnovení tokenu.“

„Dokument je sekundární zdroj — poslední relace si zapsala to, čemu věřila, ne to, co je pravda. Nechte novou relaci spustit testy ověřování a důvěřujte primárnímu zdroji.“

Dokument sloužící jako mechanismus přenosu handoff — zapsaný do environment jedním session, aby si jej přečetl jiný. Specs, tickets a plánovací dokumenty jsou handoff artefakty.

Důvod pro jeho napsání: model je stateless, takže nic v relaci nepřežije její clearing. Rozhodnutí, omezení, nedokončené plány — vše je pryč s context, který je držel. Prostředí přetrvává. Zapsání důležitého stavu do souboru jej přesune tam, odkud si jej může další relace zase přečíst.

Artefakty jsou secondary source — zpráva o práci relace, nikoli práce samotná. Právě proto jsou dost malé na to, aby mohly sloužit jako briefing pro novou relaci, a také proto mohou uvést v omyl: zaznamenávají to, čemu věřila zapisující relace, a cokoli vynechala nebo popletla, je pro čtenáře neviditelné. Tam, kde na tvrzení záleží, by si jej další relace měla ověřit oproti primary source — kódu, testům — namísto jeho pouhého převzetí.

Dobrý artefakt je napsán tak, aby se četl do relace, která má nulový kontext. Konkrétní cesty k souborům namísto „souboru, o kterém jsme diskutovali“. Co bylo rozhodnuto a proč, aby to další relace nemusela řešit znovu. Co je hotové a co zbývá. Pomáhá sdělit zapisující relaci, kam artefakt směřuje: „napiš handoff dokument pro novou relaci, která o této práci nic neví“.

Alternativním přenosovým mechanismem je compaction, která sumarizuje data v paměti. Artefakt má dvě výhody: žije na disku, kde si jej můžete přečíst a opravit, než na něm cokoli začne záviset, a lze jej opakovaně použít — stejná specifikace může instruovat pět paralelních relací.

Použití:

„Jak to mám rozdělit mezi plánovacího agent a toho implementačního?“

„Nech plány zapsat do handoff artefaktu — cesty k souborům, rozhodnutí, omezení. Relace implementátora se otevírá odkazem na tento artefakt a pracuje z něj jako ze svého zadání.“

@ Předávací artefakt popisující vícesasionskou práci – co se staví, nikoli jak každá relace odvádí svůj díl. Mění se s tím, jak práce postupuje. Skládá se z lístků.

Specifikace existuje, protože relace jsou jednorázové a velká práce nikoliv. Cokoli, co zabere více než jedno kontextové okno úsilí, potřebuje domov mimo kontext – někde v prostředí agenta, které přežije vyčištění, ať už je to soubor v repozitáři, problém na GitHubu nebo sledovač problémů, kam agent dosáhne. Specifikace je tím domovem: cíl, omezení, dosud učiněná rozhodnutí a seznam lístků s jejich stavem. Každá nová relace si ji může přečíst a vědět, jak na tom práce je, aniž by zdědila nahromaděný šum z předchozí relace.

Specifikace přicházejí v rozpoznatelných stylech, většinou zděděných od toho, jak týmy už věci sepisují. Dokument s požadavky na produkt (PRD) se opírá o to, co a proč vidí uživatel – funkce, chování, akceptační kritéria. Dokument o návrhu nebo RFC se opírá o technickou stránku – zvolený přístup, zamítnuté alternativy, kompromisy. Na té menší straně dělá obyčejné `plan.md` se seznamem lístků stejnou práci pro vícesasionskou funkci. Na stylu záleží méně než na roli: pro agenta je každá z těchto věcí totéž – trvalé prohlášení o záměru, které čte na začátku každé relace.

Použití:

"Mělo by to být všechno v jedné relaci?"

"Ne, sepiš to jako specifikaci – rozděl to na lístky, spusť každý v jeho vlastní relaci. Pokusit se udělat celou věc v jediném kontextu narazí na zónu hlouposti dřív, než budeš v polovině."

Artefakt předání handoff artifact] pro vymezení jedné relace práce. Stojí samostatně nebo je připojen k specifikaci jako jeden z jejích podřízených prvků. Úkoly mohou blokovat jiné úkoly nebo jimi být blokovány, takže pořadí práce vyplývá z jejich závislostního grafu namísto lineárního plánu.

Definujícím omezením je velikost: jedna relace. Úkol by měl být dokončitelný dříve, než se relace vymkne chytré zóně – a toto omezení je testovatelné. Pokud relace na vašich úkolech pravidelně degradují dříve, než je práce hotová, jsou úkoly příliš velké; rozdělte je. Pokud každá relace tráví většinu svého kontextu nastavováním před pěti minutami práce, jsou příliš malé; slučte je.

Dobrý úkol je napsán pro čtenáře bez jakéhokoli jiného kontextu. Cíl, kritéria přijetí a kontextové ukazatele na relevantní soubory a rozhodnutí – dost na to, aby relace mohla začít pracovat, aniž by znovu odvozovala to, co věděla ta předchozí.

Závislostní graf je také tím, co odemyká paralelismus. Nezávislé úkoly – listy grafu – mohou běžet každý ve své vlastní relaci současně. To je efektivní způsob, jak spouštět více agentů najednou. V softwarové továrně je úkol označený jako připravený sám o sobě spouštěčem, který zahájí svou relaci.

Použití:

„Kde mám začít se specifikací migrace?“

„Podívej se na graf úkolů – změna schématu blokuje zpětné naplnění, zpětné naplnění blokuje přepnutí API. Vyber list a spusť na něm relaci.“

Předání provedené v paměti: historie předchozí relace je shrnuta a souhrn slouží jako základ pro novou relaci. Ztrátové ze své podstaty: přepis je primárním zdrojem, souhrn sekundárním zdrojem – detail vyměněný za volný prostor v paměti. Spouštěno manuálně uživatelem nebo automaticky pomocí autokompakce.

Mechanismus: kontextové okno je konečné a dlouhá relace ho zaplní – každý výsledek nástroje, každé čtení souboru, každý špatný krok zůstává v historii. Když to začne být těžké, obálka požádá model o shrnutí relace, zahodí původní historii a založí novou relaci se souhrnem. Cokoliv se nedostalo do souhrnu, je z kontextu pryč. Některé obálky to zmírňují tím, že uchovávají starý přepis na disku a v souhrnu na něj zanechávají kontextový ukazatel – sekundární zdroj odkazuje zpět na svůj primární zdroj, takže detail, který souhrn ztratil, lze obnovit opětovným přečtením originálu.

Souhrn píše model, takže jej lze ovlivnit výzvou (promptem). „Zachovej rozhodnutí o schématu“ činí generovaný artefakt promyšlenějším. Na načasování také záleží – komprimujte na hranici fází, po ustálení plánu, nikoliv uprostřed úkolu.

Kontrast s vymazáním, které zahodí vše a začíná od nuly: komprese se snaží přenést základy přes předěl; vymazání sází na to, že jsou už někde zapsané lépe.

Použití:

„Kontext začíná být těžký a já mám před sebou ještě testovací průchod.“

„Zkompaktuj to, než začneš – napište do výzvy k souhrnu to, co musí přežít, aby si nová relace ponechala rozhodnutí o schématu a zahodila prozkoumávání.“

Kompakce, kterou harness automaticky spustí, když se kontextové okno blíží naplnění.

Harness sleduje zaplnění kontextového okna. Po překročení prahu — často kolem 80 % — se zastaví, požádá model o shrnutí dosavadní relace a souhrnem založí novou relaci. Práce pak pokračuje, jako by se nic nestalo.

Jenže něco se stalo. Kompakce je ztrátová a automatická kompakce je ztrátová v okamžiku, který jste si nevybrali. Ruční kompakce probíhá na hranici fází, kdy můžete říct, co má model zachovat. Automatická se spustí uprostřed úkolu při dosažení prahu — třeba v polovině refaktoringu, přičemž souhrn sám rozhodne, která vaše rozhodnutí stojí za uchování. Klasický příznak: agent sebejistě pokračuje, ale potichu zapomněl omezení stanovené před hodinou a všimnete si toho, až když mu práce začne odporovat.

Obranou je nenechat ji spustit. Sledujte ukazatel kontextu a ručně jej zkompaktujte na přirozené hranici nebo zapisujte rozhodnutí do plánu či předávacího artefaktu na disk, kde je žádný souhrn neztratí. Většina harnessů dovoluje nastavit i rezervu — posunout práh dříve či později nebo automatickou kompakci vypnout — a upravit tak prostor zbývající před jejím spuštěním.

Použití:

„Zdá se, že si nepamatuje, co jsme dřív rozhodli o schématu.“

„Mezi tahy proběhla automatická kompakce — starší rozhodnutí se shrnula a něco se muselo ztratit. Znovu načti plán nebo příště zkompaktuj ručně, abys určil, co se uchová.“

Systém, který se pokouší učinit agenta stavovým napříč relacemi. Ukládá informace do prostředí během relace a znovu je načítá do kontextového okna na začátku budoucích relací, takže agent udržuje kontinuitu i po tom, co uživatel vymaže relaci.

Paměťový systém má dvě poloviny. Cesta zápisu: během relace agent zaznamenává to, co se naučil – vámi vyjádřenou preferenci, fakt o projektu – jako soubory v prostředí. Cesta čtení: při spuštění relace harness načte tyto soubory nebo jejich index zpět do kontextového okna. Mnoho harnessů dodává vlastní paměťový systém – jedním z nich je `/memory` v Claude Code – ale můžete si jej postavit i sami: adresář poznámek plus instrukce v souboru AGENTS.md, aby do něj nahlížel.

Platí stejné kompromisy jako u jakéhokoli obsahu, který je vždy načten. Paměti se hromadí, takže většina systémů načte řádkový index a těla zanechává za kontextovými ukazateli namísto vkládání všeho dovnitř. A protože paměti jsou sekundárními zdroji, dochází u nich k posunu: fakt zaznamenaný v březnu je načten se stejnou jistotou v červnu, poté co se projekt posunul dál. Paměťový systém potřebuje prořezávání, stejně jako soubor AGENTS.md.

Použití:

"Pořád mu musím opakovat, že používám Postgres, ne MySQL."

"Připojte paměťový systém – zapište to, co se naučí, do souborového systému při prvním kroku a při spuštění relace to znovu načtěte. Samotný model je bezstavový; paměťová vrstva předstírá kontinuitu."

Soubor v environment, který harness načte do context window při spuštění session — stálé zadání projektu pro agent. Zvyklost napříč harnessy; některé harnessy mají také svou vlastní variantu (Claude Code má CLAUDE.md).

Protože se načítá automaticky, je to jeden ze způsobů, jak se vyhnout opakování se napříč relacemi. model je stateless — oprava, kterou zadáte v jedné relaci, je v té další pryč, a vy tak skončíte u toho, že každé nové relaci říkáte, že projekt používá pnpm, že testy běží s určitým příznakem, že nějaký adresář je generovaný a nemá se na něj sahat. Když agenta opravíte kvůli téže věci dvakrát, tato oprava je kandidátem na řádek v AGENTS.md.

Vhodným obsahem je cokoli, co agent nedokáže odvodit z kódu: příkazy pro sestavení a testování, konvence, které codebase nedělá zjevnými, tvrdá omezení („nikdy neupravujte generovaného klienta“). Stručně a deklarativně — jde o briefing, nikoli o dokumentaci.

Kompromisem je, že všechno v něm je neustále načteno. Instrukce se hromadí, většina z nich je pro daný úkol irelevantní a dlouhý soubor AGENTS.md stojí tokeny a zároveň se ředí — čím více instrukcí je v kontextu, tím méně spolehlivě model dodržuje kteroukoli z nich.

Vyhněte se: používání AGENTS.md pro obsah, který by měl být progressively disclosed — cokoli v něm platí token cenu v každém turn, v každé relaci, bez ohledu na to, zda daná relace tuto věc potřebuje, či nikoli. Stylová příručka může být schovaná za skill nebo context pointer; nechte v AGENTS.md pouze řádky platící všude.

Použití:

„Proč každá relace začíná s už propálenými 4 tisíci tokeny?“

„Zkontroluj AGENTS.md — někdo tam zkopíroval celou stylovou příručku namísto toho, aby ji schoval za skill.“

Načítání pouze takového context , jaké agent právě potřebuje, přičemž context pointers odkazují na zbytek. Převzato z návrhu uživatelského rozhraní, kde to znamená ukazovat uživatelům pouze ty ovládací prvky, které jsou relevantní pro jejich aktuální úkol, a zbytek schovat za kliknutí.

Tato technika existuje proto, že kontext stojí dvakrát tolik. Každý token načtený dopředu je účtován jako input tokens v každém turn, a každý token čerpá attention budget , ať už ho agent potřebuje, nebo ne. Soubor AGENTS.md nacpaný kompletním průvodcem stylem, příručkou pro nasazení a databázovými konvencemi dělá agenta horším ve všem – instrukce, na kterých pro aktuální úkol záleží, jsou naředěny těmi, na kterých nezáleží. Signálem je agent, který ignoruje pravidla, o nichž víte, že v kontextu jsou: jsou tam, ale jsou pohřbená.

Postupné odhalování (progressive disclosure) tohle obrací naruby. Udržujte neustále načtenou vrstvu malou – větu na téma a odkaz na místo, kde se nachází detail. Agent si přečte průvodce stylem, když píše komponentu, příručku pro nasazení, když nasazuje, a ani jedno, když opravuje test. Skills jsou vzor zabudovaný do harness: krátký popis načtený v každé session, úplné instrukce až po spuštění.

Použití:

„Mám nahrát celého průvodce stylem do AGENTS.md?“

„Ne – postupné odhalování. Odkazujte na průvodce stylem jako na dovednost (skill), kterou si agent načte, když opravdu potřebuje napsat komponentu. AGENTS.md platí cenu v 토кеnech (token cost) v každém kole.“

Zmínka v jednom dokumentu, která odkazuje na jiný, takže agent ho může natáhnout do kontextového okna pouze tehdy, když to úkol vyžaduje. Jednotka, ze které je postupné odhalování sestaveno.

Důvodem pro použití ukazatele (místo vkládání obsahu přímo) je cena. Ukazatel je jedním řádkem v kontextovém okně. Dokument za ním může mít tisíce tokenů, ale tyto tokeny nestojí nic, dokud agent ukazatel skutečně nenásleduje. Vložte 2 000tokenový manuál do AGENTS.md a každá relace za něj platí; nahraďte jej textem „proces nasazení: viz `internal/deploy.md`“ a načtou jej pouze relace, které probíhají při nasazování. Agent následuje ukazatel pomocí volání nástroje, když se úkol shoduje.

Ukazatel potřebuje ke své funkci dvě části: stabilní cestu a dostatečný popis, aby agent věděl, kdy se vyplatí jej následovat. Holá cesta je ukazatel, který agent nemá důvod následovat; „viz `internal/deploy.md`“ bez jakéhokoli náznaku toho, co je uvnitř, je přeskočeno relací, která to potřebovala. Napište řádek tak, aby odpovídal tomu, jak se úkoly objevují: „vydání, nasazení nebo vrácení zpět — nejprve si přečtěte `internal/deploy.md`“.

Ukazatele jsou všude, jakmile se podíváte: řádky v AGENTS.md, popisy dovedností (nástroj načte popis; tělo dovednosti čeká za ním), názvy souborů v seznamu adresářů, odkazy mezi dokumenty.

Ukazatel může také svázat sekundární zdroj s primárním zdrojem, ze kterého byl odvozen – souhrn zahuštění, který uvádí původní přepis, dokument, který uvádí zdrojový soubor, jejž popisuje. Díky tomu je ztrátovost sekundárního zdroje obnovitelná: když se ukáže, že souhrn nestačí, agent jde po ukazateli a přečte si originál, namísto toho, aby pracoval s tím, co souhrn zachoval.

Vyhněte se: „reference“ – příliš suché; nevyjadřuje, že její následování přináší další kontext. „Portál“ – příliš květnaté.

Použití:

„AGENTS.md začíná být obrovský.“

„Většina z toho by měla být kontextové ukazatele, ne obsah. Pravidla, která běží neustále, ponechte v textu; manuál nasazení a průvodce stylem proměňte v dovednosti a zanechte po sobě kontextový ukazatel.“

Učitelná schopnost zabalená jako jednotka – instrukce a zdroje pro dobré zvládnutí jednoho úkolu, uchovávané v prostředí, dokud kontextový ukazatel nepřitáhne tuto schopnost do kontextového okna pro daný úkol. Jednotka progresivního odhalování v harnessu.

Schopnosti jsou otevřeným standardem definovaným na adrese agentskills.io – původně vyvinutým společností Anthropic a od té doby přijatým většinou hlavních harnessů, takže schopnost napsaná jednou funguje napříč nimi. Formát je složka obsahující:

• Soubor `SKILL.md` – metadata (minimálně název a popis) a samotné instrukce
• Volitelně skripty, které agent může spouštět
• Volitelně šablony a referenční materiály, na které instrukce odkazují

Ve výchozím nastavení je v kontextu pouze název a popis. Když úkol agenta odpovídá, načte zbytek. Do té doby nezabírá schopnost téměř žádné místo – větu nebo dvě tokenů, bez ohledu na to, jak velké jsou její úplné instrukce.

To odlišuje schopnosti od souboru AGENTS.md, který se načítá do každé relace bez ohledu na úkol. Schopnost se čte, když se objeví určitý druh práce – vydávání, vytváření kostry nové služby, psaní migrace – a po zbytek času se ignoruje.

Vyhněte se:

„Nástroj“ – nástroj je to, co agent volá; schopnost jsou instrukce, které čte.

Použití:

"Kam mám umístit provozní příručku pro nasazení?"

"Jako schopnost – agent ji načte pouze tehdy, když úkol zahrnuje nasazení. V souboru AGENTS.md by to spotřebovávalo tokeny při každém kroku pro něco, co používáme jednou týdně."

Agent spuštěný jiným agentem prostřednictvím volání nástroje. Běží ve vlastní relaci s vlastním kontextovým oknem a hlásí zpět jediný výsledek nástroje. Odlišuje se od předání — rodič výslovně očekává návrat; předání nemá žádnou cestu zpět. Nemůže plodit další subagenty — strom je hluboký jednu úroveň. Subagenti existují k izolaci kontextu, nikoli k vytváření hierarchií.

Smyslem je udržet hlučnou práci mimo kontext rodiče. Široké vyhledávání nebo dlouhá výprava za čtením souborů vytvoří stránky výsledků nástrojů, z nichž většina má význam jen tak dlouho, dokud se nenajde odpověď. Spusťte to uvnitř rodiče a vše zůstane v kontextu rodiče po zbytek relace. Spusťte to uvnitř subagentu a hluk místo toho vyplní jednorázové okno — do kontextu rodiče se dostane pouze závěrečná zpráva. Zpráva je sekundárním zdrojem: rodič získá zprávu subagentu o tom, co našel, nikoli surové výsledky, takže cokoli, co zpráva vynechá, je pro rodiče neviditelné.

Subagenti také běží současně — rodič může spustit několik z nich najednou nad nezávislými kusy práce.

Použití:

„Výsledky grep mi zahlcují kontext.“

„Spusťte subagent, který provede vyhledávání — spálí své vlastní kontextové okno na hluku a nahlásí zpět dvě cesty k souborům, které opravdu potřebujete.“

Pracovní vzor, kdy jeden nebo více lidí spolupracuje s agentem během relace — kontrolují, přesměrovávají nebo spolupracují v reálném čase. Člověk je přítomný a zapojený, nejde jen o schvalování jednotlivých akcí.

Kontrastem je práce bez dozoru (AFK), kdy agent běží sám a výsledek posuzujete až zpětně. Být v těsné součinnosti (human-in-the-loop) znamená zachytit problémy v době, kdy je ještě snadné je vyřešit: vidíte, že agent sahá po špatném souboru, špatně pochopil zadání nebo se vydává slepou uličkou, a v jedné větě ho nasměrujete jinak — namísto toho, abyste po dvaceti minutách sebejisté práce zjistili, že je postavena na chybě. Agentům se nedá spolehlivě věřit, že poznají, kdy se odchýlili od cíle; pokud je necháte o samotě, mají tendenci tlačit věci kupředu, místo aby se zastavili a zeptali se.

To, který vzor se hodí, závisí na dané práci. Dobře specifikované úkoly s nízkým rizikem a snadným ověřením se hodí pro režim AFK. Úkoly, které jsou nejednoznačné, nevratné nebo u kterých byste měli problém zkontrolovat hotový výsledek — migrace schématu, zrádné rozhodnutí o designu, cokoliv, co se dotýká produkce — vyžadují setrvání v procesu (in-the-loop). Rozhodnutí se v podstatě opírá o otázku: jak drahý je špatný odbočení a jak pozdě byste ho zachytili?

Některá práce je ze své podstaty v procesu, protože vaše reakce jsou vstupem. Grilování funguje pouze tehdy, když jste u toho a odpovídáte na otázky; prototypování funguje pouze tehdy, když jste u toho a reagujete na artefakt.

Setrvání v procesu stojí vaši pozornost, což je vzácný zdroj. Součástí zlepšování práce s agenty je bezpečné přesouvání většího množství práce mimo tento okruh — pomocí plánů, automatizovaných kontrol a lidské kontroly na konci namísto neustálého dohledu. Softwarová továrna jde ještě dál tím, že spouští relace na základě spouštěčů, takže ani samotné zahájení práce nevyžaduje vaši účast.

Použití:

„Spustit to přes noc bez dozoru?“

„Ne, je to migrace schématu — ponech to v režimu human-in-the-loop. Chci vidět každý krok a zasáhnout, pokud si vybere špatný sloupec pro naplnění.“

Away from keyboard (Od klávesnice). Pracovní vzor, kdy uživatel spustí session a nechá agent běžet bez dozoru. Násobič propustnosti programování s AI — mnoho relací AFK může běžet paralelně, zatímco spíte, jíte nebo pracujete na něčem jiném. Obvykle vyžaduje benevolentní permission mode plus sandboxing, aby to bylo bezpečné.

Když tam nejste, agent přistupuje k nejednoznačnosti jinak. Zatímco se díváte, nejednoznačné rozhodnutí vyvstane jako otázka a vy na ni odpovíte; jakmile odejdete, agent zvolí výchozí možnost a pokračuje dál a každé další rozhodnutí staví na tomto odhadu. Charakteristickým selháním je návrat k hodinám hotové, sebevědomé práce postavené na špatném rozhodnutí učiněném v prvních deseti minutách. Práce není odbytá — je koherentní, jen je koherentní v něčem jiném, než by měla.

Jelikož během běhu nemůžete zadávat vstupy, poskytněte je předem a potom. Předem: vyřešte nejednoznačnost hned na začátku — grilling relace, písemná spec — aby zbývalo méně mezer, které musí agent vyplnit sám. Během: automated checks a automated review zastupují pozornost, kterou nevěnujete, a rychle selhávají u toho, co lze zachytit mechanicky. Potom: běh končí něčím, co lze zkontrolovat — pull requestem, nikoli již sloučenými změnami. AFK neodstraňuje human review; odsouvá ho celé až na konec, což je důvod, proč to, co dorazí na konci, musí stát za kontrolu. To je také důvod, proč AX záleží v AFK bězích nejvíce — když se nikdo nedívá, prostředí je jedinou podporou, kterou agent dostává.

Vyhněte se: „background agent“ (pozadový agent) — klade důraz na stroj („běží na pozadí“) namísto lidského vzoru („uživatel odešel“). AFK pojmenovává fakt, na kterém záleží: uživatel se nedívá.

Použití:

„Pouštím to AFK — tři sandboxovaní agenti na refaktoringu, ráno zkontroluju pull requesty.“

„Bypass permissions?“

„Jo, jen pro čtení filesystem, bez sítě.“

Deterministické ověření, které běží v prostředí – testy, kontroly typů, lintery, sestavení, háky před odevzdáním (pre-commit hooks). Úspěch/neúspěch, žádné posuzování. Signál, ze kterého se agent může sám zotavit, aniž by do toho zapojoval kohokoli jiného. Nestabilní test (flaky test) je rozbitá kontrola, nikoliv ne-kontrola; automatizované kontroly jsou deterministické ze své podstaty.

Sebeoprava funguje jako smyčka. Agent provede změnu, spustí kontrolu jako volání nástroje a výstup o selhání se dostane do jeho kontextového okna – chyba typu se souborem a řádkem, selhávající tvrzení (assertion) s očekávanými a skutečnými hodnotami. To agentovi stačí k tomu, aby problém opravil a spustil kontrolu znovu, stále dokola, dokud neprojde, bez lidského zásahu. Determinizmus je to, díky čemu je smyčka důvěryhodná: stejný kód vždy produkuje stejný verdikt, takže úspěch něco znamená. Nestabilní kontrola to otráví – agent „opravuje“ kód, který byl v pořádku, nebo opakuje pokusy za skutečným selháním.

To je důvod, proč jsou dobré kontroly velkou částí AX (zkušenosti agenta) základu kódu. Agent v repozitáři s přísnými typy, rychlou sadou testů a linterem zachytí většinu svých vlastních chyb dříve, než je uvidíte; agent v repozitáři bez těchto prvků doručí cokoliv, co vytvoří. Na tomto rozdílu záleží nejvíce při bězích bez dozoru (AFK), kde jsou kontroly jediným ověřením probíhajícím během běhu. Kontrola však zachytí pouze to, co tvrdí – zelené kontroly znamenají, že platí tvrzené vlastnosti, nikoliv to, že je kód správný. Mezerami ve tvaru posouzení jsou určeny automatizovaná recenze a lidská recenze.

Vyhněte se: „smyčka zpětné vazby“ / „zpětný tlak“ (backpressure) – obojí hází kontroly do jednoho pytle s recenzí. Vyhněte se: „test“ – testy jsou automatizované kontroly, ale ne všechny automatizované kontroly jsou testy.

Použití:

„Agent neustále dodává rozbitý kód v bězích AFK.“

„Jaké automatizované kontroly jsou zapojeny do sandboxu?“

„Pouze jednotkové testy.“

„Přidejte kontrolu typů a linter – agent se z nich sám opraví, než vůbec dojde k odeslání PR.“

Agent, který kontroluje práci jiného agenta, často s odlišným modelem nebo systémovým promptem. Nedeterministický: vytváří úsudek. Běží kdekoli — před sloučením v PR, dodatečně k historii commitů, uprostřed relace jako subagent. LLM jako rozhodčí v CI je automatizovaná kontrola, nikoli automatická kontrola; kategorii určuje to, co aserce dělá, nikoli kde běží.

Právě oddělení od pracovního agenta zajišťuje jeho funkčnost. Žádat agenta, který kód napsal, aby zkontroloval vlastní práci, vám přinese jen velmi málo — relace, která vytvořila chybu, obsahuje také úvahy, které ji vytvořily, a agent čte vlastní závěry zpět jako potvrzení. Recenzent s čerstvým kontextovým oknem nemá žádnou takovou vazbu: vidí diff tak, jak by ho viděl cizí člověk, na čemž kontrola závisí. Jiný model nebo systémový prompt specifický pro kontrolu to ještě více zostřuje — jiné slepé skvrny a systémový prompt zaměřený na to, na čem vám opravdu záleží (bezpečnost, smlouvy API, výkon), namísto nejasného „hledej problémy“.

Zapadá mezi ostatní vrstvy kontroly. Automatizované kontroly jsou nedeterministické a zachycují to, co lze mechanicky tvrdit; lidská kontrola je drahá a škáluje se nejhůře. Automatizovaná kontrola stojí uprostřed: zachycuje problémy ve tvaru úsudku – zavádějící název funkce, přehlédnutý okrajový případ – za cenu stroje. Protože je nedeterministická, může přehlédnout věci a označit ne-problémy; berte ji jako filtr, který zvyšuje laťku předtím, než se na ni podívá člověk, nikoli jako bránu, která ji nahrazuje.

Vyhněte se: „AI recenze“ / „recenze agentem“ — příliš vágní na to, aby se lišily od samotného pracovního agenta.

Použití:

„Dostáváme příliš mnoho špatných PR z AFK běhů.“

„Přidejte krok automatizované kontroly před sloučením — jiný model, samostatný systémový prompt, zaměřený na změny zabezpečení a smluv.“

Uživatel čte kód vytvořený agentem a posuzuje jej. Čtení diffu nebo změněných souborů se počítá; čtení agentova popisu toho, co udělal, ne — vyprávění není artefakt. Popis je sekundární zdroj napsaný posuzovanou stranou; diff je primární zdroj a kontrola znamená jeho přečtení.

Agenti zvyšují množství vytvářeného kódu, takže se kontrola stává úzkým hrdlem. Užitečná je kombinace různých kontrolních strategií. Automatické kontroly odhalí mechanická selhání, automatická revize ta popsatelná a lidská kontrola zůstává pro to, co můžete posoudit jen vy — zda je změna správná, přístup vhodný pro kód a zda to celé vůbec má existovat.

Kontrola je levnější i dříve. Přečíst plán před zahájením práce nebo malý diff v průběhu zabere minuty; rozplétat hotovou větev po běhu AFK trvá déle. Umístění kontrolního bodu je rozhodnutím o člověku v rozhodovacím cyklu, nikoli dodatečnou maličkostí.

Nepoužívat: samotné „code review“ — není jasné, zda jde o lidskou, nebo automatickou kontrolu.

Použití:

„Lidsky jsem zkontroloval výstup AFK.“

„Četl jsi diff, nebo jen souhrn?“

„Diff. Souhrn tvrdil, že smazal mrtvý kód — ukázalo se, že funkci volá generovaný soubor.“

Pracovní vzor, kdy uživatel akceptuje kód agenta bez lidské kontroly. S diffem se zachází jako s neprůhlednou věcí – záleží na tom, zda program funguje, nikoliv na tom, co je uvnitř. Automatická recenze a automatické kontroly mohou stále běžet, ale o těch vibe kódování mlčí.

Pojm pochází od Andreje Karpathyho, který ho vymyslel na začátku roku 2025: „zcela se poddáte atmosféře (vibes)“ a „zapomenete, že kód vůbec existuje“ – popíšete, co chcete, přijmete to, co se vrátí, a posoudíte to spuštěním.

Vibe kódování vyměňuje kontrolu za rychlost. Čtení diffů je obvykle nejpomalejším krokem v práci řízené agentem, takže jeho vynechání odstraňuje hlavní překážku. U kódu, jehož selhání stojí málo – prototypy, jednorázové skripty, interní nástroje – je to rozumná výměna. Riziko roste úměrně s životností kódu a sázkami ve hře.

Cena se dostaví později. Změny vytvořené pomocí vibe kódování se hromadí v kódu, který nikdo nečetl, a chování bylo jedinou zkontrolovanou věcí – takže cokoliv, co chování neodhalí, jako je tajný klíč zapsaný v logu, chybějící okrajový případ nebo potichu špatně zpracovaná data, projde bez povšimnutí. Když někdo poprvé ladi systém, je to poprvé, co někdo čte kód. Bez lidské kontroly je jakékoliv automatizované ověření, které stále běží – testy, typy, automatická kontrola – jedinou bránou, kterou kód projde. Stejný přístup uplatněný na celou kódovou základnu nebo její část, jejíž změny pocházejí ze softwarové továrny, je temná továrna.

Vyhněte se: použití „vibe kódování“ jako synonyma pro „nízkokvalitní AI kódování“ – tento pojem pojmenovává postoj ke kontrole, nikoliv výsledný kód.

Použití:

„Četl jsi, co to změnilo v autentizačním toku?“

„Vibe kódoval jsem to – přihlášení stále funguje, to je vše, co jsem zkontroloval.“

„Přečti si diff, než to pošleš dál, vibe kódování autentizace je způsob, jakým uníkají tajné klíče do logů.“

Sdílené porozumění tomu, co se vytváří, společné uživateli a agentovi, ale oddělené od každého jednotlivého podkladu. Brooksův pojem (The Design of Design): konverzace, předávací artefakty i kód jsou podklady snažící se zachytit nebo dosáhnout návrhové koncepce, ale žádný z nich není samotnou koncepcí. Její kvalitu lze vnímat podle kvality konverzace, která ji vytvořila.

Pojem pojmenovává mezeru za známou frustrací: agent napíše přesně to, co jste chtěli, a přesto je to špatně. Obvykle proto, že jste ještě úplně nevěděli, co chcete. Návrhová koncepce nebyla hotová ve vaší hlavě — prompt zachytil promyšlené části a mlčel o těch nepromyšlených. Agent tato prázdná místa vyplnil vlastními předpoklady, protože se neměl s čím sladit. Nic se neporouchalo. Sdílená návrhová koncepce neexistovala, protože ještě nebyla celá, aby ji šlo sdílet.

Že je návrhová koncepce sdílená, poznáte stejně jako u kolegy: druhá strana začne odpovídat na dosud nepoložené otázky tak, jak byste odpověděli vy. Do té doby je práce konverzací — její záměrnou podobou je důkladné vyptávání — a příliš brzy napsaná specifikace jen uloží nesoulad do trvalejšího podkladu. Koncepce se také mění s poznáním; podklady za ní zaostávají, a proto specifikace věrná minulému týdnu může tento týden zavádět.

Použití:

„Píše přesně to, co jsem chtěl, a pořád je to špatně.“

„Ještě nesdílíte návrhovou koncepci — mezery vyplňuje předpoklady. Mluvte dál, dokud se neshodnete na rušení, refundacích a částečném plnění, a teprve pak ho nech napsat specifikaci.“

Technika pro vývoj návrhového konceptu s agentem: agent vede s uživatelem sokratovský rozhovor, jedno rozhodnutí po druhém, a pro každé navrhuje doporučenou odpověď. Zpomaluje spěch k hotovému plánu – žádný předávací artefakt se nezapisuje, dokud se koncept nestabilizuje.

Technika existuje proto, že agenti zaplňují mezery tiše. Požádán o napsání specifikace na základě dvouřádkového promptu se agent nezastaví u rozhodnutí, která jste neučinili – vybere výchozí hodnoty a zapíše je. Výsledek vypadá kompletně a domněnky jsou k nerozeznání od volby, takže je odhalíte pozdě: při recenzi nebo když vytvořená funkce zpracuje okrajový případ způsobem, který jste si nikdy nezvolili. Grilování toto obrací – místo hádání se agent musí ptát.

Je to technika typu human-in-the-loop: vaše odpovědi jsou vstupem. Když nelze na otázku odpovědět v konverzaci – museli byste tu věc vidět – přepněte na prototypování.

Použití:

"Přejel rovnou k psaní specifikace a špatně pochopil logiku rušení."

"Nejprve ho vyzkoušejte – přimějte ho, aby se vás zeptal na částečná zrušení, vrácení peněz a načasování, než cokoliv zapíše do dokumentu. Je levnější to vyřešit v konverzaci než v kódu."

Nechte agent vytvořit rychlou, hrubou verzi něčeho pro chvíle, kdy je konverzace příliš málo věrná a vy potřebujete skutečný artefakt, o kterém by se dalo mluvit.

Grilování řeší designová rozhodnutí v konverzaci. Konverzace je levná, ale má nízkou věrnost: na některé otázky nelze odpovědět slovy – jak interakce působí, zda je tvar rozhraní API ergonomický ve skutečném volajícím kódu nebo zda rozvržení funguje při reálných velikostech dat. Pohovor narazí na otázku a vaše upřímná odpověď zní: „Nevím, musel bych to vidět.“ Za tímto bodem se diskuse točí v kruhu. Místo toho nechte agenta postavit danou věc, podívejte se na ni a vraťte se ke konverzaci s odpovědí.

Agenti snižují náklady na vývoj, což je to, co to činí praktickým. Hrubá verze, jejíž vytvoření dříve trvalo den, zabere nyní minutu, takže se to vyplatí dělat pravidelně. Jde o techniku člověka v smyčce: prototyp je tu od toho, abyste na něj reagovali.

Obvykle neskončíte u jednoho pohledu. S prototypem iterujte – reagujte, požádejte o změnu, opět reagujte –, takže každé kolo vyřeší další rozhodnutí oproti skutečnému artefaktu s vyšší věrností, než jakou konverzace umožňuje.

Prototyp nemusí být úplně odbytý. Můžete vytvořit části, které skutečně hodnotíte, v produkční kvalitě, takže jakmile padne rozhodnutí, komponenta nebo API, na které jste reagovali, se může přenést do skutečné kódové základny. Díky tomu je prototypování nezbytným materiálem pro referenci ve specifikaci.

Použití:

„Strávili jsme půl hodiny hádkami o tom, jestli by průvodce měl mít jednu stránku, nebo tři kroky.“

„Slova to nevyřeší – nechte agenta vytvořit prototyp obou verzí. Proklikáme se jimi a za pět minut budeme vědět.“

Zkušenosti vývojářů (DX) – jak moc kódová základna a její sada nástrojů usnadňují lidem dobrou práci. Dobré DX znamená rychlou zpětnou vazbu, jasné chybové zprávy, dokumentaci, která odpovídá na otázku, kterou opravdu máte, a nastavení, které funguje hned napoprvé. Tento termín předchází kódování pomocí AI; v tomto slovníku je hlavně jako protiklad k AX.

DX je interakce mezi člověkem a kódovou základnou – nic víc. Hlavní rozdíl mezi oběma publiky je v tom, že lidé mají stav a agenty jsou bezstavové. Člověk se kódovou základnu naučí jednou a přenáší si tyto znalosti do každého dalšího dne, a proto je špatné DX přežitelné: obcházejí pomalou CI dávkováním svých pushů, chybějící dokumentaci tím, že se jednou zeptají na Slacku, matoucí strukturu tím, že si pamatují, kde věci žijí. Obchizení se hromadí a tým nakonec produktivně funguje v kódové základně, která proti němu bojuje.

Agenti čelí stejné kódové základně bez jakéhokoliv tohoto nahromadění. Jako bezstavoví napříč relacemi se agent učí kódovou základnu pokaždé od začátku – těží z rychlé sady testů a jasných chybových zpráv, ale cokoliv, na co včera přišel, je pryč, pokud to nebylo zapsáno do prostředí, které agent vnímá pouze prostřednictvím výsledků nástrojů. To je mezera, kterou AX pojmenovává: ty části DX, které přežijí, když je vývojář agentem, plus obavy, které lidé nemají, jako je udržování kontextového okna volného.

Průnik znamená, že investice do DX často zlepšují AX zdarma – striktní typy, rychlé testy a předvídatelná struktura pomáhají oběma. Odchylka znamená, že tomu tak není vždy: nádherný dokument pro onboarding pomůže člověku na týden a agentovi vůbec, pokud není dosažitelný z AGENTS.md.

Použití:

"Naše DX je v pořádku – nováčci jsou produktivní za týden."

"Produktivní proto, že s nimi někdo sedí ten týden. Agent nedostane ten týden; zkontrolujte AX zvlášť."

Zkušenost agenta (Agent experience) — jak dobře je prostředí připraveno pro agenta, aby mohl odvádět dobrou práci ve zdrojovém kódu. Protějšek vývojářské zkušenosti (DX) zaměřený na agenty. Když stejný agent podává dobrý výkon v jednom repozitáři a špatný v jiném — při stejném modelu a stejném harnasu — rozdíl je obvykle v AX. Instinktem bývá vinit model nebo přepsat prompt; náprava přitom často spočívá v samotném repozitáři.

Dobrá AX má tři hlavní dimenze:

AX a DX se překrývají — dobré kontroly a čistá architektura pomáhají oběma publikům —, ale také se liší. Lidé tolerují kmenové znalosti, pomalé CI a „zeptejte se Sáry ohledně fakturačního modulu“; agenti nikoliv. Agentům nepomáhají nápovědy v IDE ani hezké řídicí panely; potřebují chyby jako text ve výstupu nástroje. Kódová základna může mít dobrou DX a špatnou AX.

Vyhněte se: považování AX za synonymum pro DX — obě skupiny publika vyžadují odlišné investice.

Použití:

„Agent píše skvělý kód v API repozitáři a odpad v rozhraní frontend.“

„API repozitář má přísné typy a rychlou testovací sadu; frontend nemá ani jedno a disponuje čtyřiceti trvale načtenými dovednostmi. To je mezera v AX, nikoli problém modelu.“

Pracovní systém, kde relace agenta spouštějí triggery – vytvoření problému, harmonogram, selhání CI, dokončení jiné relace – namísto člověka, takže více práce běží bez lidského dozoru a lidská pozornost je věnována zbývajícím rozhodnutím typu human-in-the-loop.

Bez továrny každá relace začíná proto, že ji někdo spustil. Dokonce i práce zcela bez lidského dozoru čeká na osobu, která relaci otevře, nasměruje ji na lístek a spustí ji. Týmy chtějí dodávat více, než to umožňuje. Továrna odstraňuje člověka ze spouštění relací, a ne nutně z ničeho jiného.

Běžné triggery a relace, které spouštějí:

Továrna nemusí pokrývat celý proces vývoje softwaru. Továrnou je i jediná úloha cronu, která spouští jeden druh relace a otevírá jeden recenzovatelný PR. Začít v takto malém měřítku je užitečné: úzká smyčka produkuje malé, podobné PR a jejich recenzování ukazuje, jak moc lze smyčce důvěřovat, než se rozšíří.

Lidé mohou sedět kdekoli v továrně – psát a označovat požadavky, které spouštějí relace, schvalovat plán před zahájením implementace, provádět lidskou recenzi před sloučením. Rozhodnutí, která z těchto rozhodnutí zůstanou v rukou lidí, je hlavní otázkou návrhu. Kódová základna nebo její část, kde žádný člověk nekontroluje výstup továrny, je temnou továrnou.

Použití:

"Kdo opravil všechna porušení `no-floating-promises`?"

"Továrna. Úloha cron vybere jedno pravidlo linteru za noc a otevře PR. Ráno to jen zkontroluju."

Zdrojový kód nebo jeho část, kde softwarová továrna píše kód a žádný člověk jej nečte. Neexistuje žádná lidská recenze. Lidé mohou stále psát požadavky (issues), které práci zahájí. Nikdo však nečte kód, který z toho vzejde. Název pochází z „bezobslužných“ (lights-out) továren, které vyrábějí věci bez lidí na provozní ploše.

Tmavá továrna (dark factory) je vibe kódování pro celou oblast kódu, nikoli pro jednu změnu. Když děláte vibe kódování, zvolíte si, že nebudete číst změnu, o kterou jste požádali. Víte ale, že tato změna existuje. V tmavé továrně tým činí tuto volbu jednou provždy pro celou oblast. Poté už žádný člověk o každou změnu nepožádá ani ji nevidí. Změny přicházejí tak rychle, jak spouštěče zahajují novou práci.

Problém se ukáže, když se něco rozbije. Nevíte, co se změnilo, protože nikdo změny nečetl. Musíte ladit kód, který nikdo v týmu nečetl. Příčina může být v kterékoli z mnoha změn a každá z nich prošla kontrolami.

Jedinými branami jsou automatizované kontroly a automatizovaná recenze. Pokud problém nenajdou, problém se dostane do kódu.

Vyhněte se: nazývání zdrojového kódu „tmavým“ jen proto, že jeho továrna běží, aniž by na ni někdo dohlížel. Pokud relace agenta běží bez dozoru (AFK) a člověk kontroluje jejich pull requesty, je to softwarová továrna. Není to tmavá továrna.

Usage

„Kdo změnil logiku opakování pokusů ve fakturační službě? Nikdo v týmu si na to vzpomíná.“

„Fakturační služba je tmavá továrna. Agenti sloučí všechny změny, které projdou CI. Tuto změnu nikdo nečetl.“