Dlouhý chat vypadá jako paměť. Ve skutečnosti je to často jen rostoucí fronta zpráv, kterou musí model znovu a znovu zpracovávat. Jakmile se do ní přimíchají výpisy z terminálu, volání nástrojů a několik hodin práce, člověk už neřeší jen úkol. Řeší také, co všechno se ještě vejde do kontextového okna.
Čerstvá Rychlá zpráva o Mnemonic Proxy popisuje projekt, který na tento problém nejde dalším shrnutím. Proxy nechává agenta posílat celou historii, ale modelu v každém kroku ukáže jen část, která se do jeho okna skutečně vejde. Starší materiál přitom nemaže ani nepřepisuje do jedné uhlazené rekapitulace.
To je na první pohled technická pomůcka pro lokální coding agenty. Ve skutečnosti ale ukazuje důležitější věc: agentická paměť nemusí znamenat, že model všechno drží v hlavě. Může znamenat dobře vedený archiv, ze kterého si umí na požádání vytáhnout původní podklad.
Paměť není větší okno
Podle dokumentace v oficiálním repozitáři funguje Mnemonic Proxy jako průhledná HTTP mezivrstva mezi agentem a lokálním nebo OpenAI-kompatibilním modelem. Podporuje OpenAI Chat Completions, Anthropic Messages i OpenAI Responses. Projekt je napsaný ve standardní knihovně Pythonu a jeho hlavní myšlenka je jednoduchá: model nemusí pokaždé číst celý spis jen proto, aby našel jednu starou větu.
Proxy schovává starší výpisy nástrojů a odpovědi do stabilních bloků. V promptu zůstane krátká účtenka s identifikátorem a agent může přes interní nástroj recall požádat o původní obsah. Nevrací parafrázi, ale doslovný záznam: první zápis souboru, celou historii úprav nebo dvojici příkaz–výstup.
Tady se Mnemonic liší od běžného automatického zkracování konverzace. Shrnutí může být praktické, ale vždy rozhoduje, co považuje za důležité. Proxy se snaží tuto volbu odsunout až na okamžik, kdy je starý detail skutečně potřeba. Podobnou disciplínu kolem objemu vstupu jsme na Radyzu řešili u nástroje CtxWise, jenže Mnemonic jde dál od auditu promptu k ukládání celé pracovní historie.
To ovšem není kouzelná paměť. Model stále vidí jen jednu omezenou část historie a musí si o zbytek říct. Přesnější je mluvit o kurýrovi než o mozku: kurýr si nepamatuje zásilku, ale dokáže ji najít, přenést a vrátit bez toho, aby ji cestou převyprávěl.
Kurýr mezi agentem a modelem
Projekt rozděluje dlouhý běh do několika operací. Nejprve skryje starší obsah a ponechá jeho identifikátor, potom umožní strukturované dohledání, při zaplnění okna uzavře segment s předávacími poznámkami a nakonec ukládá stav enginu na disk, pokud to daný backend podporuje. V dokumentaci se výslovně počítá s llama-serverem a Strata, ale také s dalšími OpenAI-kompatibilními enginy.
Zajímavá je role KV cache. Mnemonic udržuje prefix promptu mezi bloky beze změny, takže lokální engine nemusí při každém požadavku zpracovávat úplně jiný začátek konverzace. To není trik, který by zvětšil schopnosti modelu. Je to provozní rozhodnutí, které může zmenšit opakovanou práci při dlouhém běhu.
Právě tady se projekt potkává s jiným směrem vývoje agentních nástrojů. V rozboru TaskWire jsme psali o tom, že tým potřebuje vidět stav úkolu, vlastníka a výsledek, ne jen další zprávy v chatu. Mnemonic řeší opačnou stranu stejného nepořádku: neříká, kdo má úkol, ale pomáhá uchovat, co se během práce opravdu stalo.
To rozlišení je důležité. Pracovní board může zlepšit koordinaci, ale nevrátí ztracený výpis příkazu. Archiv může vrátit starý výpis, ale sám nezajistí, že agent správně pochopí jeho význam nebo že někdo zkontroluje výsledek. Ve firemním provozu budou obě vrstvy potřebovat vlastní pravidla.
Čísla vypadají dobře. Právě proto je třeba číst drobný text pod nimi
Autoři v repozitáři uvádějí měření z jedné tříhodinové patnáctiminutové relace na jednom GPU s 12 GB paměti. Historie měla 448 tisíc tokenů, zatímco model v jednom okamžiku dostal nejvýše 105 tisíc. Relace podle jejich záznamu obsahovala 430 požadavků bez chyby a dva přechody mezi segmenty, při nichž psaní předávacích poznámek trvalo přibližně dvě minuty.
Ještě zajímavější je srovnání na AgentLongBench. Při 32tisícovém okně dosáhl Mnemonic v testu 86 správných odpovědí ze 100, zatímco shrnutí stejným modelem 47 a prosté zkrácení historie 49. Plné okno s větším limitem skončilo na 69 správných odpovědích. To je dobrý argument pro doslovné dohledávání, ne však univerzální tabulka kvality všech modelů a všech agentů.
Samotná dokumentace uvádí podmínky, které marketingová zkratka snadno schová: jeden model, jeden engine, jeden seed a sto otázek. Proxy byla v tomto testu přesnější než shrnutí, ale také pomalejší než práce s plným oknem, protože při dlouhém běhu znovu přehrává část historie přes mezivrstvu. U lokálního modelu tak výměnou za přesnější návrat starého detailu platíme časem a úložištěm.
Aktuální repozitář už uvádí vydání v0.3.9, ale čísla v benchmarku se vztahují ke konkrétní starší verzi proxy a konkrétnímu testovacímu nastavení. To je přesně ten rozdíl, který stojí za zachování: novější release může přinést opravy, ale sám o sobě nepřepisuje výsledky staršího měření.
Doslovný archiv je také archivem tajemství
Největší praktický problém není velikost databáze. Její obsah. Dokumentace otevřeně říká, že lokální archiv ukládá vše, co agent viděl: obsah souborů, výstupy příkazů, reasoning i tajné hodnoty. Ukládá se také journal požadavků, poslední prompt a podle použitého enginu soubory se stavem konverzace.
Autoři uvádějí, že proxy standardně komunikuje jen s nastaveným upstreamem, neposílá telemetrii ani nekontroluje aktualizace a váže dashboard i MCP server na localhost. Zároveň ale upozorňují, že výchozí režim nemá autentizaci a nemá se vystavovat do sdílené sítě. Lokální uložení tedy není automaticky bezpečné uložení; znamená jen, že odpovědnost zůstává na stroji, disku a jeho přístupu.
Dokumentace navíc popisuje, že zatím neexistuje příkaz pro zapomenutí konverzace. Smazání vyžaduje ruční práci se SQLite tabulkami, indexy a soubory uloženého stavu. Kdo si podobný nástroj nasadí do práce s produkčním kódem, měl by si před prvním během odpovědět na nepříjemnou otázku: jak rychle dokážu odstranit jeden citlivý projekt, pokud se historie dostane na špatný disk nebo do špatné zálohy?
Stejnou hranici jsme viděli u Personal Agent Proxy. Vlastní mezivrstva může omezit, komu se data posílají, ale sama neuděluje bezpečnostní záruku. U Mnemonic je navíc nutné chránit samotný archiv, protože jeho předností je právě to, že nic důležitého nezahodí.
Model nevidí 448 tisíc tokenů. A to je v pořádku
Nejpřesnější věta z celé dokumentace zní jinak, než by se hodila do titulku: model 448 tisíc tokenů nevidí. Vidí jen jedno kontextové okno a zbytek je dohledatelný. To je menší slib než „nekonečná paměť“, ale také poctivější popis toho, co systém skutečně dělá.
Limit se ukáže ve chvíli, kdy je důležitý detail roztroušený přes několik starých zpráv nebo zůstal jen v úvahách modelu. Autoři sami uvádějí, že dlouhé otázky z první hodiny tříhodinové relace nebyly vždy zodpovězené úplně. Lexikální vyhledávání může minout parafrázi bez společných slov a staré reasoning části se při maskování ztrácejí snadněji než viditelné výstupy.
Mnemonic proto není náhrada za testy, code review ani dobré zadání. Je to spíš pojistka proti tomu, aby pracovní historie zmizela jen proto, že prompt narazil na velikostní limit. Pokud agent neumí vyhodnotit nalezený podklad, přesný archiv mu nepomůže; může pouze udělat jeho omyl lépe dohledatelným.
To je podle nás nejzajímavější pointa celého projektu. Budoucnost agentů se nebude rozhodovat jen podle toho, kolik tokenů dokážou přečíst najednou. Rozhodne také, zda umí rozlišit živý úkol, starý důkaz, nejistou vzpomínku a záznam, který je třeba znovu ověřit.
Mnemonic Proxy na tuto otázku neodpovídá hotovým produktem ani nezávislou studií. Nabízí ale rozumný směr: méně předstíraného porozumění v podobě krátkého shrnutí a více dohledatelné historie, kterou lze znovu otevřít. Pro agenta je to možná skromnější schopnost než „pamatovat si všechno“. Pro člověka, který za jeho prací ručí, je to často užitečnější.
