Paměť a znalosti

K čemu paměť slouží

Bez paměti začíná každá konverzace s agentem od nuly: stejnou konvenci je potřeba vysvětlit znovu, stejné rozhodnutí znovu obhajovat a stejnou slepou uličku znovu prozkoumat. Paměť je úložiště vázané na pracovní prostor, které přežije běhy. Existuje proto, aby znalost vytvořenou jedním agentem později našel jiný.

Má tři vrstvy a každá odpovídá na jinou otázku:

Fakta – co platí (konvence, výsledek, rozhodnutí).
Politiky – co s tím agenti musí udělat (normativní pravidlo).
Pracovní paměť – u čeho jeden agent zrovna byl.

Rozlišení je důležité, protože k agentovi se dostávají různými cestami. Fakta se vyhledávají. Politiky se do kontextu vkládají. Pracovní paměť je soukromá.

Fakta

MemoryFact je jednotka znalosti vázaná na pracovní prostor a doménu.

Atribut	Co to je
`domain`	Doména znalosti („conventions“, „decisions“, „codebase“)
`topic`	Krátký štítek tématu
`content`	Text znalosti
`confidence`	0.0–1.0, výchozí hodnota vychází z původu a roste při opětovném zmínění
`memoryType`	Druh faktu – řídí křivku jeho časového útlumu
`veracity`	Jak se o něm systém dozvěděl – nasazuje jistotu a určuje přírůstek při každém dalším zmínění
`sourceObservationIds`	Která pozorování k němu vedla
`supersededBy`	Novější fakt, který ho nahradil, pokud nějaký je
`validUntil`, `recallCount`, `mentionCount`	Signály expirace a používání, se kterými se počítá při vyvolání

Poslední dva řádky lidé často přehlédnou a právě ony rozhodují, který fakt se vynoří. memoryType nese parametry Weibullova útlumu podle druhu, takže časově omezený závazek rychle vybledne, zatímco stabilní fakt o profilu ne. veracity zaznamenává původ – řekl to člověk (váha 1.0), odvodil to agent (0.7), vyprodukoval to nástroj (0.5), bylo to importované (0.6) – a touto vahou se nasadí výchozí jistota faktu.

Fakta se při rozporu nikdy neupravují na místě. Zápis faktu spustí detekci konfliktů proti faktům ve stejné doméně a se stejným tématem, poražený fakt nahradí a zapíše řádek konfliktu. Smyslem je auditní stopa: vždy uvidíš, čemu se věřilo předtím a co to nahradilo.

Politiky

MemoryPolicy je normativní pravidlo odvozené z fakt, vázané na pracovní prostor a doménu, s příznakem aktivity a volitelným requiredRole.

Každá aktivní politika v pracovním prostoru se vloží do každého odeslání, bez filtru – žádné filtrování podle domény, role, úkolu ani prostoru. Stojí za to to vědět, než napíšeš dvacátou politiku, protože politiky soutěží o stejné kontextové okno jako úkol. Proto je requiredRole u politiky jen orientační: říká, na koho pravidlo míří, ale nezabrání tomu, aby se dostalo i ke všem ostatním.

Domény

MemoryDomain sdružuje fakta a politiky v rámci pracovního prostoru. Domény dávají znalostem organizační strukturu a jsou jednotkou, vůči které se zapisují přístupové granty. Než ale budeš doménu brát jako hranici důvěrnosti, podívej se na upozornění níže.

Doména je buď pro celý pracovní prostor (architecture), nebo vázaná na jeden repozitář (repo:<slug>/architecture). Stejný název v obou rozsazích jsou dvě nezávislá úložiště: fakt, který platí pro jeden repozitář, nepřepíše ten platný pro celý pracovní prostor. search_memory a preambule odeslání dají paměti vázané na repozitář přednost, když agent v tom repozitáři pracuje; zbytek neodfiltrují. Parametr repo u propose_fact / propose_policy / search_memory do tohoto rozsahu zapíše, nebo ho při hledání zvýhodní.

Řízení přístupu je u čtení ve výchozím stavu otevřené

MemoryAccessGrant mapuje roli agenta a doménu na jednu ze tří úrovní oprávnění:

Oprávnění	Význam
`none`	Žádný přístup
`read`	Může fakta vyhledávat a načítat
`write`	Vyžaduje ho `propose_policy`. Zápisy fakt (`propose_fact`, `supersede_fact`) na grant vázané nejsou

Asymetrie, u čtení měkká a u zápisu politik tvrdá, je záměrný kompromis. Paměť je nejužitečnější, když koluje, a odmítnuté čtení vyrobí agenta, který tiše ví méně, místo agenta, který problém nahlásí. Odmítnutí zápisu politiky je hlasité a dá se opravit, a právě tam vynucení sedí. Nově vytvořená doména nasadí write každé roli; pozdější zpřísnění je úprava jen přes RPC, protože rozhraní pro granty není.

Pracovní paměť

Každý agent má AgentWorkingMemory: volný textový zápisník klíčovaný pracovním prostorem a agentem. Přežívá mezi běhy, patří jen tomu agentovi a při každém odeslání se vloží do jeho promptu. Sem patří „Byl jsem v půlce refaktoringu autentizace“ – stav, který stojí za přenos do dalšího běhu, ale ne za povýšení na trvalý fakt.

Co se skutečně dostane do promptu agenta

Při odeslání se preambule paměti skládá přesně ze tří věcí:

Každá aktivní politika pracovního prostoru, jako řádky - [domain] rule.
Vlastní pracovní paměť agenta, doslova.
Krátký seznam fakt vybraných podle klíčových slov pro tento úkol – nejvýš pět, v rozpočtu zhruba 1 200 znaků a jen když má popis úkolu alespoň 20 znaků. Kratší úkoly nedostanou žádná fakta.

Krátký seznam je jen FTS a klíčová slova a strop má schválně. Spočítat embedding dotazu je pomalé a cesta odeslání je to místo, kde je latence hned vidět, takže pomalá sémantická cesta na ní záměrně není. Preambule končí tím, že agentovi řekne, ať nosné položky ověří přes search_memory. Tam žije úplný model vyvolání.

Na této cestě se přístupové granty nekontrolují. Agent vidí to, co krátký seznam najde.

Vyvolání: jeden dotaz, čtyři hlasy

Nástroj search_memory, se kterým pracuje agent, má tři režimy a každé je jiné hledání:

keyword – jen FTS5.
semantic – výsledky BM25 a vektorů sloučené fúzí recipročního pořadí.
hybrid (výchozí) – polyfonní vyvolání: čtyři seřazené hlasy se sloučí a výsledek se pak rozrůzní.

Čtyři hlasy jsou lexikální (FTS), sémantický (vektorové KNN), časový (nedávná aktivní fakta) a grafový: dvouskokový průchod po epizodických hranách od nejsilnějších lexikálních a sémantických semen. Grafový hlas je důvod, proč epizodické hrany vůbec jsou: vynese fakt, který je s odpovědí spojený, aniž by se shodoval s nějakým tvým slovem. Váhu hlasů určuje klasifikovaný záměr dotazu (ve výchozím stavu má největší váhu sémantika, pak graf a lexikální hlas, pak aktuálnost), skóre každého kandidáta se přenásobí jeho Weibullovým útlumem a sada výsledků se diverzifikuje pomocí MMR, aby pět přeformulování jednoho faktu nevytlačilo čtyři jiná.

Hledání v paměti na počítači a na webu je samostatná, jednodušší cesta: RPC operace memory_fact.search je jen FTS5, protože tenký klient neumí poslat embedding dotazu a hybridní cesta zůstává uvnitř hostitele. Pořadí, které vidíš v prohlížeči paměti, tedy není pořadí, které agent dostane z search_memory. Je to očekávané chování. „Hledal jsem to a nenašel“ v rozhraní neznamená, že to nenajde ani agent.

Kde paměť žije a kdo ji zapisuje

Prohlížeč paměti je v Nastavení → Pracovní prostor → Paměť (/workspaces/<id>/settings/memory), s kartami Fakta, Politiky a Graf znalostí.

Je tam asymetrie, která lidi překvapí: paměť můžeš upravit a smazat, vytvořit ji nemůžeš. Ani karta Fakta, ani karta Politiky nemá ovládání pro přidání. Vytváření je na straně agenta, přes propose_fact a propose_policy (supersede_fact / supersede_policy je nahrazují). remember zapíše položku horké vrstvy vázanou na relaci a consolidate_memory ji může později povýšit na fakt; record_observation a update_my_notes zapisují soukromý zápisník, který se vkládá při odeslání. Prohlížeč slouží ke kontrole a opravě. Chceš-li fakt do paměti, řekni to agentovi.

Dvě údržbové operace se stejně tak volají z agenta a neběží podle plánu: consolidate_memory slučuje a prořezává nahromaděná fakta a harmonize_memory srovnává přesvědčení, která se mezi agenty rozešla. list_memory_conflicts ukáže, co detekce konfliktů už zaznamenala. Žádný časovač je za tebe nespouští. Rozhodnutí ze schůzek se sklízejí do domény decisions, když je zapíše krok uložení schůzky. Není to časovač nad dokončenými běhy agentů.

Související koncepty

Model agentů: role jsou to, vůči čemu se granty zapisují
Pracovní prostory a izolace: paměť je vázaná na pracovní prostor a leží v jeho vlastním databázovém souboru
Spravujte paměť pracovního prostoru: práce s pamětí v praxi