Paměť AI agentů: proč dlouhý kontext není paměť

Dáte agentovi milionový kontext a čekáte, že přestane „zapomínat“. Týden nato vám klient ukazuje screenshot, kde agent dvakrát na stejné schůzce zopakuje, že o uživateli „nemá žádné informace“ — přestože ten samý uživatel s ním řešil onboarding před hodinou. Není to bug v délce kontextu. Je to záměna dvou věcí, které se obě jmenují „paměť“ a každá řeší něco jiného.

01„Paměť“ je zastřešující slovo pro několik různých mechanismů

Když uživatel řekne „pamatuj si, že nemám rád emoji“, myslí tím něco velmi konkrétního: zapsat fakt o mně a příště ho použít, i kdyby uplynul měsíc a tisíc jiných konverzací. Když inženýr řekne „máme dlouhý kontext“, myslí něco úplně jiného: do jednoho volání modelu se vejde víc tokenů. Tyhle dvě věci spolu skoro nesouvisí. Dlouhý kontext neumí překlenout dva běhy procesu. Pamatovat si fakt přes půl roku není o velikosti okna, je to o tom, mít datovou strukturu, která ten fakt přežije.

Praktická paměť v agentu se skládá z několika vrstev a každá z nich řeší jiný problém. Když je smícháte do jednoho slova, máte produkt, který „má paměť“, ale uživatelům zjevně nepamatuje to, co by měl.

02Pracovní kontext: co model aktivně drží v ruce

Pracovní paměť je obsah jediného volání modelu. Systémový prompt, dosavadní turn, vložené nástrojové výstupy. Tady je rozdíl mezi 8 k a 1 M tokenů reálný a měřitelný — model může najednou „vidět“ celý projekt místo jednoho souboru. Pracovní paměť je rychlá, přesná a drahá. A je dočasná: jakmile volání skončí, kontext je pryč, dokud ho někdo příště neposkládá znovu.

Naivní pohled je „velký kontext = velká paměť“. V praxi to skoro nikdy nestačí. Modely v dlouhém kontextu historicky vykazují lost-in-the-middle — pasáže uprostřed dlouhého vstupu mají reálně menší vliv na výstup než ty na začátku a na konci. Novější frontier modely (Opus 4.6 a novější, GPT-5+, Gemini 3.x) tenhle problém znatelně zmírnily, ale úplně nezmizel — a ten posun navíc není přímočarý napříč generacemi (viz hned níž): čím delší kontext a čím víc paralelních „needle“ informací, tím větší pravděpodobnost, že model relevantní pasáž nenajde nebo si protiřečí.

A pozor — ani generační skok modelu není automaticky skok v kvalitě dlouhého kontextu. Opus 4.7 na multi-needle retrievalu oproti 4.6 dokonce regredoval: na MRCR v2 8-needle spadlo skóre při 256k z cca 92 % na cca 59 %, při 1M dokonce z cca 78 % na cca 32 %. Ta čísla mají ovšem háček, který stojí za zmínku: Anthropic sám MRCR jako benchmark zpochybňuje (prý přeceňuje skládání distraktorů a vyřazuje ho) a ukazuje na GraphWalks, kde 4.7 naopak roste (z cca 39 % na cca 59 %). To je ale jen jiná ilustrace téhož, co tvrdí celý tenhle článek: jedno benchmarkové číslo není univerzální vlastnost modelu, je to skóre v jedné konkrétně definované úloze. Pro náš účel z toho plyne prostá věc — „novější model“ sám o sobě dlouhý kontext nevyřeší, natož paměť. A není to akademický nález, to vidíte na vlastních agentech ve chvíli, kdy jim do kontextu nacpete celý ticketovací systém.

03Dlouhý kontext jako paměť: kdy ano, kdy je to past

Dlouhý kontext je dobrý pro jednorázové úkoly, kde má smysl modelu jednou vysypat všechno relevantní: celá kniha, celý codebase, celý transcript. Pro jeden běh je to čistá výhra oproti řezání na kousky.

Past je v tom, použít dlouhý kontext jako náhražku trvalé paměti. Cena lineárně (nebo hůř) roste s každým voláním. Latence taky. A hlavně: dlouhý kontext mizí mezi sezeními. Když do něj na konci konverzace nacpete shrnutí toho, „co si má agent pamatovat“, a příště ho potřebujete znovu načíst, tak ho někdo musí někde uložit. V tu chvíli už nestavíte dlouhý kontext, stavíte retrieval — jen nepřiznaně a špatně.

04Retrieval (RAG): explicitní vyhledávání nad uloženým

Retrieval-augmented generation je nejviditelnější vrstva paměti: dotaz se převede na embedding, vyhledá podobné dokumenty, modelu se předhodí jako kontext. Funguje to dobře pro znalostní bázi — pravidla firmy, dokumentace, historické tickety. Tedy pro to, co je víceméně statické a velké.

Pro paměť agenta uvnitř konverzace je RAG horší, než se zdá. Embedding podobnost je sémantická, ne sekvenční ani kauzální. Když uživatel řekne „udělej to znova jako minule, ale s tou změnou, co jsme se domluvili ve středu“, embedding podobnost ten konkrétní moment nenajde — pokud to není přesně tak pojmenované. RAG zachycuje témata, ne události. Pro události potřebujete jiný typ paměti.

Produkční retrieval to dnes obvykle řeší hybridně: vector search se kombinuje s BM25 (lexikální), s filtry přes metadata (čas, entita, projekt) a s rerankerem nahoře. To pomáhá zachytit „ve středu“ jako časový filtr, ne jako sémantickou stopu. Ale i hybridní retrieval má strop tam, kde je potřeba kauzální řetězec napříč sezeními. Pro to potřebujete zápis, který si retrieval neumí vymyslet zpětně.

05Epizodická paměť: záznam, co se kdy stalo

Epizodická paměť je zápis interakce s časovou osou: kdy uživatel co řekl, jak agent reagoval, jak to dopadlo. Bez ní agent zachází se 100. konverzací jako s první.

Důležitý detail: epizodická paměť bez shrnutí a kondenzace se zhroutí do nepoužitelného surového logu. Praktický agent po každém významném turnu (nebo na pozadí) zápis kondenzuje: „uživatel preferuje X“, „v projektu Y používáme Z“, „chyba A se opakovala třikrát, řešení bylo B“. Bez kondenzace máte data; s kondenzací máte paměť.

Konkrétní implementační vzor stojí za zmínku, protože ukazuje, jak to vypadá v produkci. Mastra ve své observational memory nechá kondenzaci na dvou agentech v pozadí: Observer průběžně přepisuje surové zprávy na husté observace (datované, prioritizované) a Reflector observace v delším horizontu spojuje, deduplikuje a vyhazuje, co už neplatí. Agent ve foregroundu paměť aktivně nevyhledává; vidí ji jako stabilní prefix kontextu. Mastra na LongMemEvalu udává 94,87 % s gpt-5-mini — podle ní vůbec nejvyšší zaznamenané skóre na tomhle benchmarku, a hlavně bez vector databáze. To číslo je ale fér brát jako vendor benchmark (jedna úloha, výrobce si ji vybral sám): podle nezávislých rozborů OM v multi-session kategoriích, které jsou pro paměť přes sezení nejrelevantnější, existující systémy spíš dorovnává (řádově kolem 87 %) než drtí. Pozoruhodné na tom výsledku není ani tak výška skóre jako jak ho dosahuje — bez retrieval vrstvy. Jiné systémy jdou opačnou cestou: Mem0 a Zep staví nad konverzační historií explicitní paměťovou vrstvu s vyhledáváním, Letta (dříve MemGPT) tlačí na agentem řízenou paměť (LLM si sám rozhoduje, co kam zapíše). Žádný z přístupů není univerzálně lepší — liší se v tom, kdo nese cenu (latence vs. kontext vs. token cost) a co je laditelné.

06Sémantická paměť: fakta o uživateli a světě

Když uživatel řekne „pamatuj si, že jsem alergický na arašídy“, nechce, aby tahle informace seděla v epizodickém logu jednoho rozhovoru a čekala, až ji RAG omylem najde. Chce strukturovaný fakt s vysokou prioritou, který se přilepí ke všem budoucím volání. Tomu se v praxi říká memory store, „user facts“, profile — úzká, kurátorovaná část paměti, která se do kontextu sype skoro vždy. ChatGPT Memory („Memory updated“) i Claudova funkce paměti jsou produktové ztělesnění tohohle vzoru — explicitní fakta, vidět co je uložené, možnost mazat. (Pozor na záměnu: Claude Projects míří spíš na trvalý projektový kontext než na kurátorovaná user facts — je to příbuzný, ale ne totožný vzor.)

Disciplína je v tom, co do ní pustit. Když do user facts skončí všechno, co uživatel jen tak prohodil, máte v kontextu šum, který časem zhorší výstup. Kvalitní sémantická paměť vyžaduje explicitní zápis (model se zeptá, jestli si to má zapamatovat) nebo aspoň pozdější rekonciliaci (LLM proletí epizodické záznamy a navrhne, co povýšit na fakt).

07Procedurální paměť: naučené postupy

Poslední vrstva, na kterou se snadno zapomene: jak se agent naučil pracovat. Pro coding agenta je to znalost konvencí projektu (snake_case nebo camelCase, jaký test runner, kdy commitnout). Tohle není ani fakt, ani konverzace — je to vzor chování.

V praxi se procedurální paměť dělá po spektru. Na levném konci je textový dokument v repu, který se přilepí do systémového promptu (CLAUDE.md, AGENTS.md, .cursorrules, vlastní guidelines). Striktně vzato je to spíš parametrizace pracovního kontextu než „naučený postup“ — agent ho čte při každém běhu, žádné váhy ani embeddingy se nemění. Ale funkčně to roli procedurální paměti plní, dokud nepotřebujete víc. Uprostřed spektra jsou in-context exemplars (few-shot příklady, retrieval nad historicky úspěšnými prompty) a u některých systémů „skill files“ vytahované podle úlohy. Na drahém a méně reverzibilním konci je fine-tuning, případně LoRA adaptéry — propečení vzoru přímo do vah. Žádná z těchto vrstev nedělá totéž jako epizodická paměť — pamatovat si, co se stalo — ani sémantická — pamatovat si, co platí. Pamatuje si, jak to dělat.

08Co měří benchmarky a co tím vlastně říkají

Tady je důležité nehazet do jednoho pytle dvě věci, které se obě benchmarkují, ale měří různý problém.

Long-context benchmarky (MRCRv2 od OpenAI/Google DeepMind, RULER od NVIDIA, LongBench v2) testují, jestli model v rámci jednoho volání dokáže najít a propojit informace v dlouhém vstupu. MRCRv2 je multi-needle coreference: schovejte 2 až 8 „jehel“ do statisíců tokenů a chtějte zpátky konkrétní. Tohle není paměť přes sezení, je to kvalita pozornosti v dlouhém kontextu. Frontier modely tu dnes dosahují vysokých skóre (Opus 4.6 kolem 93 % na 8-needle do 128k), což ale neříká nic o tom, jestli si agent vzpomene na to, co padlo před týdnem. A jak ukázala regrese Opus 4.7 výše, ani vysoké skóre jedné generace negarantuje další — a samotný výběr benchmarku je věc, o které se výrobci přou.

Memory benchmarky (LongMemEval, BEAM, LoCoMo a — pro multimodální paměť — Mem-Gallery) testují tu druhou věc: schopnost přes mnoho sezení a turnů vybavit fakta, sledovat změny, řešit rozpory, respektovat časovou osu. BEAM (ICLR 2026) staví konverzace o délce až 10 M tokenů s 2 000 zkušebními otázkami napříč deseti paměťovými schopnostmi. LongMemEval je menší, ale citovanější — Mastra, Mem0, Letta na něm publikují čísla (a existuje už i novější LongMemEval-V2 zaměřený na agentní paměť). Tady už dlouhý kontext sám o sobě prohrává: model bez explicitní paměťové vrstvy buď celé conversation history nemá kam dát, nebo ho má a topí se v něm.

Z toho plyne věc, kterou článek opakuje: čísla z benchmarků neříkají „model X má paměť 9/10“. Říkají „model X v konkrétní úloze paměti dosáhl Y % úspěšnosti, s konkrétně definovanou pamětí“. Když si do produktu kupujete „model s nejlepší pamětí“, kupujete obvykle skóre v jedné konkrétní úloze, ne univerzální vlastnost.

09Praktický postup: vrstvit, ne nahrazovat

Když stavíte agenta a chcete, aby si „pamatoval“, neptejte se „jaký model má největší kontext“. Ptejte se postupně:

1. Co má agent vědět právě teď? → systémový prompt + pracovní kontext.
2. Co má vědět vždycky? → sémantická paměť (user facts, profile).
3. Co se kdy stalo? → epizodická paměť s kondenzací.
4. Kde najít znalost, kterou agent nemá v hlavě? → hybridní retrieval (vector + BM25 + filtry) nad znalostní bází.
5. Jak má pracovat? → procedurální vrstva (guidelines, skill files, případně fine-tuning).
6. Kdy se vejde všechno do jednoho volání? → dlouhý kontext jako jednorázová zkratka.

Tyhle vrstvy se nenahrazují, doplňují. A v praxi se navíc prolínají víc, než ten čistý seznam naznačuje: produkční systémy jako Mem0 nebo Zep jsou v jádru retrieval nad epizodickým a sémantickým úložištěm, takže hranice mezi „epizodickou pamětí s kondenzací“ a „hybridním retrievalem nad logy“ je rozmazaná. To rozdělení je tu spíš proto, abyste věděli, jaký problém zrovna řešíte, ne jako tvrzení, že každá vrstva musí být oddělená komponenta. Naivní agent řeší všechno jednou z nich (obvykle dlouhým kontextem nebo všeobjímajícím RAGem) a v každé úloze, na kterou ta vrstva nesedí, selhává.

10Souvislosti

Tento článek je technicko-praktický. Filozofickou stranu otázky — jestli je agent se vzpomínkami pořád ten samý agent — řeší článek AI a identita v čase. Otázku, kdo nese odpovědnost za to, co si agent z paměti vytáhne a co s tím udělá, otevírá Agency a odpovědnost u AI agentů. Jak paměťové vrstvy zapadají do širší firemní AI architektury, jde popsat skrze AI architektura pro firmy.

11Závěr

Dlouhý kontext je užitečný nástroj, ne řešení paměti. Paměť agenta není jedna věc; je to architektura několika vrstev, z nichž každá řeší jiný problém. Tým, který v product roadmapě „má paměť“ jako jednu odškrtnutou položku, obvykle koupil RAG nad konverzační historií — a zjistí to ve chvíli, kdy uživatel řekne „jako minule, ale jinak“ a agent v reakci vyhledá tři tematicky podobné konverzace místo té, na kterou se ptal. Tým, který si vrstvy pojmenuje a postaví je vědomě, dostane agenta, který odpovídá tomu, jak slovu „paměť“ rozumí uživatel.

Dlouhý kontext je nástroj, ne paměť. Paměť agenta je architektura několika vrstev, z nichž každá řeší jiný problém.

Článek popisuje stav k květnu 2026 — ber ho jako rozhodovací rámec, ne jako neměnný verdikt.