Lilith Lilith.

Złota zasada: Pamięć agenta nie jest magazynem wszystkiego, co model kiedykolwiek zobaczył. To kontrolowany system przypomnień, dowodów i poprawek. Jeśli czegoś nie da się wyjaśnić, wskazać źródła i usunąć, nie powinno być pamięcią długoterminową.

Pamięć to nie dłuższe okno kontekstu

Okno kontekstu jest blatem roboczym w danej chwili. Pamięć jest kartoteką, do której agent wraca między uruchomieniami. Te dwie rzeczy często się mylą, bo obie ostatecznie trafiają do modelu jako tekst. Operacyjnie są jednak czymś innym.

Dłuższy kontekst pomaga przy jednym długim zadaniu. Pamięć obsługuje pracę powtarzalną: co użytkownik preferuje, jak działa projekt, co ostatnio się nie udało, która decyzja nadal obowiązuje i czego następnym razem nie trzeba otwierać od nowa. Im bardziej agent działa w czasie, tym bardziej potrzebuje pamięci poza samym modelem.

Trzy warstwy, które warto rozdzielić

Pamięć robocza trzyma aktualny plan, wyniki pośrednie i fakty potrzebne do następnego kroku. Zwykle żyje w ramach jednego uruchomienia zadania i znika po jego zakończeniu.

Pamięć epizodyczna zapisuje to, co się wydarzyło: decyzje, błędy, interwencje człowieka i wyniki zadań. Jest użyteczna do audytu i do tego, żeby agent nie powtarzał tej samej ślepej uliczki.

Pamięć semantyczna przechowuje stabilniejszą wiedzę: zasady projektu, preferencje użytkownika, nazwy systemów, wewnętrzny słownik i sprawdzone procedury. Nie ma być nieograniczonym dziennikiem. Ma być uporządkowanym źródłem, które da się wyszukać i poprawić.

Przykład: użytkownik zmienia preferowany język z czeskiego na polski albo zespół wycofuje starą zasadę projektu. Zapisz nowy wpis wraz ze źródłem i okresem obowiązywania, oznacz stary jako nieaktualny i nie zwracaj go przy wyszukiwaniu tylko dlatego, że jest podobny do nowego żądania.

Największe ryzyko to zła pamięć

Pamięć jednocześnie zwiększa użyteczność i ryzyko. Agent, który zapamięta błędne założenie, może przenosić je do kolejnych zadań jak oczywistą prawdę. Personalizacja przestaje wtedy wyglądać jak błąd modelu i zaczyna wyglądać jak „system wie, czego chcesz” — tylko że wie to źle.

Dlatego pamięć potrzebuje pochodzenia, wieku i poziomu zaufania. Każdy wpis powinien mieć źródło: kto go utworzył, z jakiego zdarzenia powstał, kiedy był ostatnio użyty i czy człowiek go potwierdził. Pamięć bez metadanych to plotka z API.

Retrieval jest równie ważny jak zapis

Zapisać coś jest łatwo. Wyciągnąć właściwą rzecz we właściwej chwili jest trudniej. Agent nie musi widzieć całej swojej przeszłości; potrzebuje małego, trafnego wycinka z jasnym powodem, dlaczego trafił do kontekstu.

Dobra pamięć łączy więc wyszukiwanie, filtry, reguły priorytetu i prawo do milczenia. Jeśli wpis nie jest wyraźnie istotny, nie powinien trafiać do promptu tylko dlatego, że istnieje. Przeładowana pamięć potrafi pogorszyć odpowiedź równie skutecznie jak brak pamięci.

Reguła operacyjna: pamięć musi dać się czytać, usuwać i testować

Pamięć jest jednocześnie funkcją produktu i powierzchnią bezpieczeństwa. Użytkownik albo administrator musi widzieć, co system pamięta, móc to poprawić i móc to usunąć. Przy danych wrażliwych musi być jasne, czy w ogóle należą do pamięci długoterminowej.

Zespoły powinny testować nie tylko to, czy pamięć pomaga, ale też kiedy szkodzi: stare preferencje, zmienione role, anulowane projekty, sprzeczne instrukcje, prywatne dane i wpisy przejęte z niezaufanego źródła. Pamięć, której nikt nie ocenia, jest tylko wolniejszym sposobem na powielanie starych błędów. Długotrwały stan konwersacji i jego zarządzanie są osobną częścią systemu agenta, a nie jedynie dłuższym pojedynczym promptem. OpenAI: Conversation state

Źródła