Pamięć i wiedza

Do czego służy pamięć

Bez pamięci każda rozmowa z agentem zaczyna się od zera: tę samą konwencję trzeba wyjaśnić od nowa, tę samą decyzję rozstrzygnąć ponownie, ten sam ślepy zaułek zbadać jeszcze raz. Pamięć to magazyn w zakresie obszaru roboczego, który przetrwa uruchomienia, i istnieje po to, aby wiedza wytworzona przez jednego agenta była później znajdowalna przez innego.

Ma trzy warstwy, które odpowiadają na różne pytania:

1. Fakty — co jest prawdą (konwencja, wynik, decyzja).
2. Zasady — co agenci mają z tym zrobić (reguła normatywna).
3. Pamięć robocza — to, co jeden agent miał w trakcie.

To rozróżnienie ma znaczenie, bo do agenta trafiają różnymi drogami. Fakty są wyszukiwane. Zasady są wypychane. Pamięć robocza jest prywatna.

Fakty

MemoryFact to jednostka wiedzy w zakresie obszaru roboczego i domeny.

Atrybut	Co to jest
domain	Domena wiedzy („conventions”, „decisions”, „codebase”)
topic	Krótka etykieta tematu
content	Tekst wiedzy
confidence	0.0–1.0, inicjowane na podstawie pochodzenia i podnoszone przy ponownym wspomnieniu
memoryType	Rodzaj faktu — steruje jego krzywą zaniku w czasie
veracity	Skąd wiadomo, że jest prawdziwy — inicjuje pewność i określa wielkość każdego wzrostu przy ponownym wspomnieniu
sourceObservationIds	Które obserwacje do niego doprowadziły
supersededBy	Nowszy fakt, który go zastąpił, jeśli taki istnieje
validUntil, recallCount, mentionCount	Sygnały wygaśnięcia i użycia wykorzystywane przy przywoływaniu

Ostatnie dwa wiersze to te, które ludzie pomijają, a właśnie one decydują o tym, który fakt się pojawi. memoryType niesie parametry zaniku Weibulla dla każdego typu, więc zobowiązanie ograniczone czasowo zanika szybko, a stabilny fakt profilowy nie. veracity rejestruje pochodzenie — podane przez człowieka (waga 1.0), wywnioskowane przez agenta (0.7), wytworzone przez narzędzie (0.5), zaimportowane (0.6) — i ta waga inicjuje początkową pewność faktu.

Fakty nigdy nie są edytowane w miejscu, gdy zostaną zaprzeczone. Zapis faktu uruchamia wykrywanie konfliktów względem faktów o tej samej domenie i temacie i zastępuje przegrany, zapisując wiersz konfliktu. Chodzi właśnie o ścieżkę audytu: zawsze możesz zobaczyć, w co wierzono wcześniej i co to zastąpiło.

Zasady

MemoryPolicy to reguła normatywna wyprowadzona z faktów, w zakresie obszaru roboczego i domeny, z flagą aktywności i opcjonalnym requiredRole.

Każda aktywna zasada w obszarze roboczym jest wstrzykiwana przy każdym wysłaniu, bez filtrowania — nie ma filtrowania według domeny, roli, zadania ani przestrzeni. Warto to wiedzieć, zanim napiszesz swoją dwudziestą zasadę, bo zasady konkurują o to samo okno kontekstu co zadanie. To także dlatego requiredRole w zasadzie ma charakter doradczy: opisuje, do kogo reguła jest skierowana, ale nie powstrzymuje reguły przed dotarciem do wszystkich pozostałych.

Domeny

MemoryDomain grupuje fakty i zasady w obrębie obszaru roboczego. Domeny nadają wiedzy strukturę organizacyjną i są jednostką, względem której zapisuje się granty dostępu — ale zanim uznasz domenę za granicę poufności, przeczytaj ostrzeżenie poniżej.

Domena obejmuje albo cały obszar roboczy (architecture), albo ma zakres jednego repozytorium (repo:<slug>/architecture). Ta sama nazwa w obu zakresach to dwa niezależne magazyny: fakt prawdziwy dla jednej bazy kodu nie nadpisuje tego obejmującego cały obszar roboczy. search_memory i preambuła wysyłania stawiają pamięć w zakresie repozytorium na pierwszym miejscu, gdy agent pracuje w tym repozytorium; nie odfiltrowują jednak reszty. Przekaż repo w propose_fact / propose_policy / search_memory, aby zapisać w tym zakresie lub go wzmocnić.

Kontrola dostępu działa w trybie fail-open przy odczytach

MemoryAccessGrant przypisuje rolę agenta i domenę do jednego z trzech poziomów uprawnień:

Uprawnienie	Znaczenie
none	Brak dostępu
read	Pozwala wyszukiwać i pobierać fakty
write	Wymagane przez propose_policy. Zapisy faktów (propose_fact, supersede_fact) nie wymagają grantu

Brak grantu oznacza odczyt, a nie odmowę

Gdy nie ma wiersza grantu dla pary (role, domain), obowiązujące uprawnienie to read. Odczyty są celowo fail-open. Jedyny zapis, który rzuca błąd, to propose_policy bez uprawnienia write (InsufficientMemoryPermission). Umieszczenie poufnych treści w domenie pamięci nie ogranicza tego, kto może je odczytać, chyba że jawnie zapiszesz grant none dla każdej roli, która nie powinna ich widzieć.

W produkcie nie ma też dziś nigdzie interfejsu do grantów. Ekran pamięci ma tylko karty Fakty, Zasady i Graf wiedzy — nic więcej; granty są osiągalne wyłącznie przez operacje RPC memory_access_grant.*.

Ta asymetria — łagodnie przy odczytach, surowo przy zapisach zasad — to świadomy kompromis. Pamięć jest najbardziej użyteczna, gdy krąży, a odmowa odczytu daje agenta, który po cichu wie mniej, zamiast takiego, który zgłasza problem. Odmowa zapisu zasady jest natomiast głośna i możliwa do naprawienia, więc to tam umieszczono egzekwowanie. Nowo utworzona domena inicjuje write dla każdej roli; zaostrzenie tego później to edycja wyłącznie przez RPC, bo nie ma interfejsu do grantów.

Pamięć robocza

Każdy agent ma AgentWorkingMemory: notatnik z dowolnym tekstem, kluczowany według obszaru roboczego i agenta. Przetrwa między uruchomieniami, jest prywatny dla tego agenta i jest wstrzykiwany do jego promptu przy każdym wysłaniu. To tam mieszka „byłem w połowie refaktoryzacji auth” — stan, który warto przenieść do następnego uruchomienia, ale nie warto awansować na trwały fakt.

Co faktycznie trafia do promptu agenta

Podczas wysyłania preambuła pamięci jest składana z dokładnie trzech rzeczy:

• Każda aktywna zasada obszaru roboczego, w postaci wierszy - [domain] rule.
• Własna pamięć robocza agenta, dosłownie.
• Krótka lista faktów dopasowanych słowami kluczowymi dla tego zadania — co najwyżej pięć, w budżecie ~1200 znaków i tylko wtedy, gdy opis zadania ma co najmniej 20 znaków. Krótsze zadania nie dostają żadnych faktów.

Krótka lista opiera się wyłącznie na FTS/słowach kluczowych i jest celowo ograniczona. Osadzanie zapytania jest wolne, a ścieżka wysyłania to jedyne miejsce, w którym opóźnienie jest natychmiast widoczne, więc wolna ścieżka semantyczna jest z niej celowo wyłączona. Preambuła kończy się poleceniem, aby agent zweryfikował kluczowe pozycje za pomocą search_memory, gdzie znajduje się pełny model przywoływania.

Na tej ścieżce nie sprawdza się żadnych grantów dostępu. Agent widzi to, co znajdzie krótka lista.

Przywoływanie: jedno zapytanie, cztery głosy

Narzędzie search_memory widoczne dla agenta ma trzy tryby i są to naprawdę różne wyszukiwania:

• keyword — tylko FTS5.
• semantic — wyniki BM25 i wektorowe scalane przez fuzję odwrotnych rang.
• hybrid (domyślny) — przywoływanie polifoniczne: cztery uszeregowane głosy scalane razem, a potem urozmaicane.

Te cztery głosy to leksykalny (FTS), semantyczny (wektorowy KNN), czasowy (ostatnie aktywne fakty) oraz grafowy — dwuskokowy spacer po krawędziach epizodycznych od najsilniejszych zalążków leksykalnych i semantycznych. Głos grafowy jest powodem, dla którego krawędzie epizodyczne w ogóle istnieją: wydobywa fakt, który jest powiązany z Twoją odpowiedzią, mimo że nie pasuje do żadnego z Twoich słów. Głosy są ważone na podstawie sklasyfikowanej intencji zapytania (semantyczny ma domyślnie największą wagę, potem grafowy i leksykalny, a na końcu świeżość), wynik każdego kandydata jest skalowany przez jego zanik Weibulla, a zbiór wyników jest urozmaicany metodą MMR, aby pięć powtórzeń jednego faktu nie wypychało czterech różnych.

Przywoływanie semantyczne milczy, dopóki model nie zostanie zainstalowany

Głos wektorowy wnosi coś dopiero wtedy, gdy model osadzania na urządzeniu zostanie pobrany. Do tego czasu przywoływanie hybrydowe działa z trzema głosami i nie ma uzupełniania wstecznego — fakty zapisane przed zainstalowaniem modelu nigdy nie zyskają wektorów. Ścieżka wektorowa degraduje się jeszcze bardziej, do skanowania w Dart po spakowanych osadzeniach, jeśli samo rozszerzenie wektorowe SQLite nie wczyta się; przywoływanie nadal odpowiada, tylko wolniej.

Wyszukiwanie pamięci na pulpicie i w sieci to osobna, prostsza ścieżka: operacja RPC memory_fact.search obsługuje tylko FTS5, bo cienki klient nie może przesłać osadzenia zapytania, a ścieżka hybrydowa pozostaje wewnętrzna dla hosta. Ranking widoczny w przeglądarce pamięci nie jest więc tym rankingiem, który agent otrzymuje z search_memory. To oczekiwane zachowanie, a nie błąd, ale oznacza, że „szukałem i nie znalazłem” w interfejsie nie jest dowodem, że agent tego nie znajdzie.

Gdzie mieszka pamięć i kto ją zapisuje

Przeglądarka pamięci znajduje się w Ustawienia → Obszar roboczy → Pamięć (/workspaces/<id>/settings/memory), z kartami Fakty, Zasady i Graf wiedzy.

Jest tam asymetria, która zaskakuje ludzi: pamięć możesz edytować i usuwać, ale nie możesz jej tworzyć. Ani karta Fakty, ani karta Zasady nie oferuje możliwości dodawania. Tworzenie odbywa się po stronie agenta, przez propose_fact i propose_policy (supersede_fact / supersede_policy, aby je zastąpić). remember zapisuje element gorącej warstwy ograniczony do sesji, który consolidate_memory może później awansować na fakt; record_observation i update_my_notes zapisują prywatny notatnik wstrzykiwany przy wysyłaniu. Przeglądarka służy do wglądu i korekty, a nie do tworzenia — więc jeśli chcesz mieć fakt w pamięci, jedynym sposobem jest powiedzieć o tym agentowi.

Dwie operacje konserwacyjne są również wywoływane przez agenta, a nie zaplanowane: consolidate_memory scala i przycina nagromadzone fakty, a harmonize_memory uzgadnia przekonania, które rozeszły się między agentami. list_memory_conflicts pokazuje, co już zarejestrowało wykrywanie konfliktów. Nic nie uruchamia ich za Ciebie według harmonogramu. Decyzje ze spotkań są zbierane do domeny decisions, gdy zapisze je krok utrwalania spotkania; nie jest to harmonogram działający na zakończonych uruchomieniach agentów.

Powiązane koncepcje

• Model agentów: względem ról zapisuje się granty
• Obszary robocze i izolacja: pamięć działa w zakresie obszaru roboczego i mieszka we własnym pliku bazy danych tego obszaru roboczego
• Zarządzaj pamięcią obszaru roboczego: praca z pamięcią w praktyce