Kontext nástrojů a cache promptů

U každého požadavku vestavěného harnessu platí dvě věci: definice nástrojů tvoří největší pevný náklad a skoro žádná z nich se nepoužije. Tahle stránka vysvětluje, co s tím Control Center dělá a proč odpověď není prostě „posílat míň nástrojů“.

Problém je pozornost, ne bajty

Control Center registruje zhruba 126 nástrojů. Když se pošlou celé, stojí jejich definice přibližně 23 000 tokenů na každý požadavek — náklad, na který komprimace nesáhne, protože definice nástrojů jdou v požadavku jinou částí než konverzace.

Účet za tokeny je ta zjevná stížnost a s cache promptů zároveň ta menší. Skutečná cena je přesnost výběru. Publikovaná hodnocení volání nástrojů se shodují, že modely vyberou správný nástroj spolehlivě zhruba do 30–50 nástrojů v kontextu a za tou hranicí se postupně zhoršují. Pojmenovaná příčina není počet tokenů, ale sémantický překryv: jakmile katalog obsahuje několik nástrojů, jejichž popisy znějí podobně, model volí mezi dvojníky, místo aby si vybavoval schopnost.

Při 126 nástrojích je agent na každém tahu daleko za tím pásmem — včetně těch mnoha tahů, kde stačilo přečíst soubor.

Dvouúrovňová plocha

Běh proto vidí dvě věci:

• rezidentní sadu — zhruba dvě desítky nástrojů, poslaných s plným schématem při každém požadavku;
• jmenný index všeho ostatního, seskupený pod nadpisy jako „Tickets and projects“ nebo „Memory and knowledge“, za pár stovek tokenů na celý katalog.

Na současném katalogu to srazí blok nástrojů z ~23,1 tis. tokenů na ~5,0 tis., tedy asi o 78 %, a trvale viditelnou sadu dostane do pásma, kde je výběr spolehlivý.

Rezidentní sada jsou nástroje, které běh použije ve většině běhů: slovník souborů a shellu (read, write, edit, search, bash, …), nástroje pro objevování, kontrolní seznam úkolů, hledání v paměti a sloveso, které musí aktuální režim zavolat, aby odevzdal výstup. Vlastní výstupní sloveso režimu je vždy rezidentní. Běh nesmí hledat právě to volání, které jeho výstup vytvoří.

Odložený neznamená nedostupný

Tohle z návrhu dělá bezpečný, ne jen levný. Odložený nástroj jde zavolat už od prvního tahu. Zadržené je jen jeho schéma.

Agent vidí jméno v promptu. Když ho zavolá přímo, harness ve stejném kroku načte schéma a nástroj spustí — bez chyby a bez dalšího kola. Model nemusí vědět, že byl nástroj kdy „nenačtený“.

Když agent zná úkol, ale ne jméno, search_tools vezme popis běžným jazykem („přiřaď ticket někomu“), seřadí celou plochu běhu a vrátí shody už s načtenými schématy, takže hned další tah může jednu zavolat. Když hledání nic nenajde, řekne to napřímo a navrhne jiné znění nebo širší hledání. Schválně: agent, který prázdné hledání přečte jako „tahle schopnost neexistuje“, si vymyslí náhradu, místo aby hledal znovu.

search_tools existuje jen ve vestavěném harnessu. Externí klienti MCP mají místo něj search_tool_bm25, který řadí stejný index, ale shody jen popisuje. Ti klienti už každé schéma dostali z tools/list, takže není co načítat.

Co odložení nikdy nedělá

Odložení se uplatní až po filtru nástrojů režimu, nikdy místo něj. Skryje schéma. Nástroj, který režim zakázal, odhalit neumí. Aktivovaný nástroj pořád projde výzvou ke schválení a guardraily akcí úplně stejně jako rezidentní a nenačte jméno, které na ploše běhu od začátku nebylo.

Plocha MCP, kterou vidí externí klienti, se nemění. tools/list pořád vrací celý katalog. Dřívější pokus ho ořezat agenty rovnou rozbil: klienti MCP ověřují jména nástrojů proti vlastnímu seznamu v cache a cokoliv, co v něm není, odmítnou, aniž by se serveru zeptali, takže nástroj „skrytý, ale volatelný“ byl prostě nedosažitelný. Odložení žije v harnessu, kde načtení nástroje uprostřed běhu harness opravdu umí.

Jak to vypnout

--tool-deferral=off (nebo CC_SERVER_TOOL_DEFERRAL=off) znovu udělá rezidentním každý připuštěný nástroj a vyrobí přesně ty požadavky, které server posílal, než odložení existovalo. Viz referenční příručka CLI cc_server.

Cache promptů

Zátěž agentů je nevyvážená: posílají obrovské prompty a dostávají malé odpovědi, tah za tahem, pokaždé se stejným prefixem. Poskytovatelé ten prefix cachují a čtení z cache stojí asi desetinu čerstvého čtení. Míra zásahů cache je proto vlastnost harnessu, se kterou se počítá, ne dodatečná optimalizace — a u Anthropic k tomu získá i propustnost, protože nacachované tokeny se nepočítají do minutového limitu vstupu.

Cache funguje na přesné shodě prefixu a z toho plyne jedno řídící pravidlo.

Co už odešlo, se nepřepisuje

Jakýkoli změněný bajt zneplatní cache od toho místa dál. Harness proto jen připisuje: nové zprávy na konec a nově aktivovaná schémata nástrojů za nacachovaný blok nástrojů, ne sloučená do něj. Tohle pořadí je důvod, proč je aktivace levná — nacachovaný prefix zůstane stejný a běh zaplatí jen za schémata, která právě načetl.

Smyčka taky ořezává zastaralý výstup nástrojů ze starších tahů, aby kontext získala zpátky. Čeká, až je co získat natolik, aby se přepis vyplatil, takže ořez je vzácný hluboký přepis, ne průběžné minutí cache.

Kam patří značky

Poskytovatel dovolí omezený počet značek cache a Control Center je utrácí záměrně:

Značka	Pokrývá	Životnost
Poslední rezidentní nástroj	Blok nástrojů	1 hodina
Poslední systémový blok	Nástroje + systémový prompt	1 hodina
Ocas předchozího tahu	Historie až po poslední požadavek	5 min
Ocas aktuálního tahu	Celá historie	5 min

Poslední dvě jsou klouzavý pár a důvod páru je jemný: vyhledání v cache jde zpátky omezený počet bloků a hledá něco, co uložil dřívější požadavek. Jeden tah, který spustí hodně nástrojů paralelně, může vyrobit víc bloků, než to okno pojme. Jedna značka na ocasu pak mine potichu a požadavek zaplatí plnou cenu, aniž by to odpověď někde řekla. Označení přesného místa, kde předchozí požadavek skončil, udělá zásah strukturálním, ne výsledkem závodu.

Prefix nástrojů a systému má dlouhou životnost, protože je po celý běh stejný, sdílí ho každý běh a subagent stejného tvaru a protože hodiny se spustí, když požadavek začne — tah, který streamuje několik minut, už většinu krátkého okna spotřebuje, než se sestaví další požadavek.

Subagenti sdílejí jeden prefix

Subagenti stejného typu vyrábějí bajtově totožné prefixy promptů, takže mají číst jednu položku cache, ne si každý zapisovat vlastní. Položka je ale čitelná až ve chvíli, kdy požadavek, který ji zapsal, začne odpovídat. Rozvětvení spuštěné najednou proto nechá každého potomka platit přirážku za prefix, který mají společný.

Harness nechá nastartovat prvního potomka daného tvaru a sourozence pustí, jakmile začne streamovat. Čekání má mez: pomalý první potomek přijde o jeden zásah cache, o rozvětvení ne. Ze stejného důvodu dostane každý subagent stejnou rezidentní sadu nástrojů bez ohledu na profil — měnit ji podle profilu by společný prefix rozdrobilo bez zisku, protože profil už rozhodl, co potomek smí volat.

Jak to sledovat

Obě poloviny jdou pozorovat, ne jen předpokládat:

• Průzkumník kontextu u konverzace hlásí rezidentní nástroje, odložený index a to, kolik by každé zadržené schéma stálo. Počítá to stejná cesta v kódu, kterou používá skutečný běh.
• Každý běh si zapisuje, které odložené nástroje načetl a co načtení spustilo, takže hledání, které nic nenašlo, je vidět jako minutí vyhledání, ne že se ztratí v agentovi, který potichu dělá něco vedlejšího.
• Observabilita hlásí Míra cache jako čtení z cache vůči všem zpracovaným tokenům promptu, včetně zápisů do cache — běh, který si prefix pořád staví znovu, vychází nízko, ne jako běh, který cache nikdy nepotřeboval.