Wyjaśnienie pamięci agenta: pamięć robocza, epizodyczna, semantyczna i proceduralna
Agent naprawił ten sam błąd dwa razy, ponieważ nic nie zapobiegało powrotowi tego problemu. Pamięć agenta – robocza, epizodyczna, semantyczna i proceduralna – to, co przechowuje, oraz sposoby, w jakie zawodzi.
Źródła: **Agent Memory Explained: Working, Episodic, Semantic & Procedural**
Agen kodujący kiedyś naprawił ten sam błąd w dwóch sesjach z rzędu. Nikt mu tego nie kazał, a z modelem nie było nic nie tak.
W pierwszej sesji agent przejął ticket BUG-142, zlokalizował przyczynę awarii w kolejności wykonywania migracji, zmienił kod, uruchomił testy integracyjne i obserwował, jak przepuszczają je. Następnie sesja się zakończyła.
Przed następną sesją system usunął historię rozmów, aby obniżyć koszty tokenów. Był to rozsądny wybór, ponieważ odtwarzanie coraz dłuższych zapisów kosztuje pieniądze, powoduje opóźnienia i zawęża pole wprowadzania zapytań. Ale to nie jedyna rzecz, która zniknęła. Wyniki testów przepuszczonych istniały tylko w starym oknie kontekstowym. Żaden zapis nie wskazywał, że błąd został naprawiony, a system śledzenia zadań nadal wymieniał BUG-142 jako otwarte.
Zatem rozpoczęła się druga sesja – zobaczyłem otwarty ticket i wykonałem to, czego wymagał. Przeprowadziłem dochodzenie, doszedłem do tego samego wniosku i zastosowałem tę samą poprawkę.
Model nie zapomniał, jak rozwiązywać ten problem. System nie był w stanie zachować informacji o tym, że problem został rozwiązany.
To niepowodzenie zmienia kwestię, którą zwykle stawiamy. Zamiast pytać, jak dać agentowi pamięć, należy zapytać, jaki rodzaj informacji powinien przetrwać po zakończeniu sesji. Odpowiedź na to pytanie prowadzi do czterech odrębnych zadań:
- Pamięć robocza: zadanie aktualnie wykonywane.
- Pamięć epizodyczna: to, co się wydarzyło i kiedy.
- Pamięć semantyczna: to, co jest uznawane za prawdę.
- Pamięć proceduralna: sposób, w jaki należy wykonywać czynności.
Pamięć to nie jedna całość – obejmuje co najmniej cztery funkcje, a większość błędów pamięci wynika z ich mylonego traktowania. To rozdzielenie czerpie z nauk poznawczych i znajduje odzwierciedlenie w badaniach takich jak CoALA (Cognitive Architectures for Language Agents), które opisuje agenty językowe w kategoriach modułowej pamięci, strukturyzowanych działań oraz procesu decyzyjnego.
Zanim przejdziemy po kolei do tych czterech elementów, należy oddzielić od samej pamięci dwie inne koncepcje: okno kontekstowe oraz autorytatywny stan aplikacji.
Okno kontekstowe to praca
Kontekstem są wszystkie informacje, które model może dostrzec podczas jednej próby inferencji. Zazwyczaj obejmują one instrukcje systemu, definicje narzędzi, najnowsze wiadomości, pobraane dokumenty, edytowane pliki, wyniki działania narzędzi oraz aktualny plan. To aktywna przestrzeń robocza agenta.
Jest to również tymczasowe. Gdy sesja się kończy, rozmowa jest kompresowana lub stare wiadomości są usuwane, aby dostosować się do limitu tokenów – wtedy treść znika, chyba że aplikacja celowo zapisała ją gdzie indziej. Model nie ma prywatnych wspomnień dotyczących wcześniejszych wywołań. Albo aplikacja wprowadza te informacje ponownie, albo łączy model z zewnętrznym magazynem.
Dlatego duże okno kontekstowe nie stanowi pamięci długoterminowej. Większe okno kontekstowe to po prostu większa praca, a nie szafa na akta. Więcej materiałów pozostaje widocznych podczas pracy agenta, ale gdy praca zostanie zakończona, wszystko znika, chyba że coś najpierw zapisze ważne elementy.
W tym przypadku skuteczne rozwiązanie znajdowało się na „pracowni”, ale nic go nie promowało. Mimo to przechowywanie całego transkryptu nie byłoby rozwiązaniem, ponieważ przeoczono kolejną różnicę.
Pamięć to nie aktualna prawda systemu
Porównaj dwa stwierdzenia. Jedno to informacja z pamięci: „BUG-142 został naprawiony podczas wczorajszej sesji”. Drugie to stan aplikacji: pole statusu zgłoszenia pokazuje COMPLETED.
Są ze sobą powiązane, ale należą do różnych kategorii. Pierwsze to zapis historyczny potwierdzający, że doszło do jakiegoś wydarzenia. Drugie to aktualne źródło prawdy w systemie śledzenia. Pamięć rejestruje to, co się wydarzyło, natomiast stan rejestruje to, co obowiązuje w danym momencie.
Różnica ta ma znaczenie, ponieważ wspomnienia mogą stawać się przestarzałe, pozostawać niekompletne lub okazać się błędne. Wyobraźmy sobie, że agent odzyskuje notatkę mówiącą, iż BUG-142 jest otwarty. Ta notatka mogła być prawdziwa w momencie jej napisania, ale nic nie dowodzi jej aktualności dzisiaj. Zanim podejmie działanie na jej podstawie, agent powinien sprawdzić system śledzenia, przejrzeć repozytorium, uruchomić odpowiednie testy lub spróbować odtworzyć problem. Odzyskane wspomnienie to twierdzenie dotyczące przeszłości, a nie dowód na teraźniejszość.
Pierwotny incydent nie powiódł się dwukrotnie. Nie zachowano żadnych użytecznych informacji o zakończonej korekcie, a oficjalny stan zadania nigdy nie został zaktualizowany. Gdy to ustalimy, możemy określić, co agent faktycznie musiał zachować.
Pamięć robocza: aktualne zadanie
Pamięć robocza przechowuje to, co agent potrzebuje do dalszego wykonywania bieżącego zadania, oraz niewiele więcej. W przypadku BUG-142 może to obejmować samo zadanie, obecną hipotezę (tabela zależności jest inicjalizowana zbyt późno), bieżący krok (wykonanie zestawu integracyjnego), najnowsze obserwacje (trzy testy migracji nie udają się) oraz pliki, które są edytowane.
Odpowiada na praktyczne pytania: Jaki jest cel? Który krok jest w trakcie? Co zwróciło ostatnie wezwanie narzędzia? Które pliki uległy zmianie? Co jeszcze nie jest zakończone?
W praktyce znajduje się w instrukcjach, w obiekcie stanu agenta, w punkcie kontrolnym procesu pracy lub w pamięci sesji o krótkim czasie trwania. Jest tymczasowa i powiązana z jednym zadaniem; nie ma na celu tworzenia trwałego rejestru wszystkiego, czego system się nauczył. Opis pamięci krótkoterminowej przez IBM jest podobny: najnowsze informacje wykorzystywane do natychmiastowych decyzji i kontynuacji rozmowy.
Pamięć robocza różni się również od pozostałych trzech typów. Pamięć epizodyczna, semantyczna i proceduralna może przetrwać między sesjami, podczas gdy pamięć robocza opisuje to, co jest aktywne w danym momencie, niezależnie od tego, czy znajduje się ono w „oknie pamięci”, czy zostało zapisane w pobliżu.
Jej krótki czas trwania nie jest wadą. Gdy zadanie zostanie zakończone, rzadko istnieje powód, by przechowywać każdą pośrednią hipotezę, nieukończony fragment tekstu, nieudaną komendę czy porzucony tok myślenia. Problemy pojawiają się, gdy ważny wynik istnieje tylko tutaj. W tym przypadku zniknęły dwie rzeczy: wynik zdania testu oraz fakt, że BUG-142 został naprawiony. System traktował ten istotny wynik jak tymczasową przestrzeń do zapisów.
Pamięć robocza wspomaga wykonywanie zadań. Nigdy nie powinna być jedynym zapisem ukończonej pracy.
Pamięć epizodyczna: zapis wydarzeń
Pamięć epizodyczna przechowuje konkretne doświadczenia. Epizod to coś więcej niż zwykły fakt – wydarza się w określonej sytuacji, zazwyczaj z określonym czasem, działaniem i rezultatem.
Dla BUG-142 przydatny opis epizodu mógłby mieć postać krótkiego, ustrukturyzowanego zapisu:
- Zdarzenie: BUG-142 został odtworzony podczas inicjalizacji migracji.
- Kontekst: tabela zależności nie była dostępna przy uruchamianiu usługi.
- Działanie: zmieniono kolejność wykonywania migracji.
- Rezultat: testy integracyjne przeszły pomyślnie.
- Dowód: commit a7f43d2.
- Czas: 8 września 2026 roku, 14:20.
Taki zapis informuje przyszłego agenta, że ta sytuacja już się pojawiła. Pomaga uniknąć powtarzania pracy, dostarcza przykładów i pokazuje, które wcześniejsze próby się udały, a które nie. CoALA rozróżnia pamięć epizodyczną od semantycznej, ponieważ zapis doświadczenia służy innemu celowi niż wiedza uogólniona.
Episod nie jest również tym samym co historia rozmowy. Transkrypcja może zawierać setki wiadomości, wyników narzędzi, spekulacji, korekt i powtórzeń. Obok streszczonego epizodu, np. „pewnie powinniśmy sprawdzić kolejność inicjalizacji”, umieść luźną notatkę z surowego logu: przestawienie kolejności inicjalizacji zależności rozwiązało problem BUG-142, a testy przeszły pomyślnie przy komitcie a7f43d2. Ten drugi rodzaj informacji jest znacznie łatwiejszy do odnalezienia i o wiele bardziej przydatny przy późniejszych zadaniach.
Pamięć epizodyczna może nadal zawodzić na dwa sposoby. System może zapamiętać działanie, ale stracić jego rezultat. Proste komunikaty typu „próba przeprowadzona: zmieniono kolejność migracji” sprawiają, że przyszły agent nie wie, czy powinien spróbować ponownie. Albo agent może odzyskać informację o sukcesie sprzed sześciu miesięcy, po tym jak architektura uległa zmianie. Pamięć epizodyczna przechowuje przeszłość i nie opisuje teraźniejszości, dlatego każdy epizod powinien zawierać informacje o czasie, kontekście, dowodach oraz rezultacie.
Pamięć semantyczna: to, co wie agent
Episod rejestruje to, co się wydarzyło. Pamięć semantyczna rejestruje to, czego się z tego nauczyło.
Episod BUG-142 może dostarczyć informacji, które można ponownie wykorzystać: usługa migracyjna wymaga istnienia tabeli zależności przed rozpoczęciem inicjalizacji. Nie chodzi tu już o jedną sesję debugowania – to ogólne stwierdzenie dotyczące systemu.
Typowe elementy obejmują informację o bazie danych używanej przez usługę, limit szybkości API, zasadę zakazującą umieszczania identyfikatorów klientów w dziennikach, wzorzec architektoniczny repozytorium, preferencję użytkownika dotyczącą zwięzłych odpowiedzi technicznych oraz wymóg, aby skrypty migracyjne były zgodne ze starszymi wersjami. Pamięć semantyczna obejmuje fakty, koncepcje, ograniczenia, relacje oraz preferencje. Ma tendencję do długotrwałego istnienia, ale musi pozostać podatna na modyfikacje, ponieważ fakty i preferencje się zmieniają.
Różnica pomiędzy pamięcią epizodyczną a semantyczną jest subtelna, ale warto ją pamiętać. Wersja epizodyczna mówi, że BUG-142 wystąpił wczoraj, ponieważ przy uruchamianiu brakowało tabeli zależności. Wersja semantyczna stwierdza, że inicjalizacja wymaga wcześniejszego istnienia tej tabeli. Jedna pamięta sam doświadczenie, druga – wyciągniętą z niego lekcję.
Jego charakterystyczną wadą jest przestarzałość. Załóżmy, że zespół później przyjmie nowy mechanizm inicjalizacji, który nie będzie już zależał od tabeli. Jeśli system pamięci po prostu doda nowy fakt, agent może pobrać oba – jeden mówiący, że tabela musi istnieć najpierw, a drugi, że to już nie ma znaczenia. Wtedy mamy pamięć bez jasności. Przestarzały fakt może być gorszy niż brak faktów, ponieważ agent będzie na jego podstawie działał z pewnością siebie.
Dlatego pamięć semantyczna potrzebuje ścieżki korekty, zawierającej odpowiedzi na kilka pytań. Ktoś musi być odpowiedzialny za aktualizacje faktów. Potrzebuje ona nazwanego źródła oraz daty ostatniej weryfikacji. Gdy pojawi się nowsza wersja, stara powinna zostać oznaczona jako zastąpiona, a następnie usunięta lub zachowana jako historia. To należy do samej inżynierii pamięci. Na razie chodzi o to, że pamięć semantyczna przechowuje wiedzę nadającą się do ponownego użycia, a nie tylko zapis wydarzenia.
Pamięć proceduralna: jak wykonywane są zadania
Pamięć proceduralna podaje agentowi, jak wykonać zadanie. Zawiera umiejętności, procedury pracy, zasady działania oraz metody powtarzalne.
Na podstawie błędu zespół może opracować procedurę: przed uruchomieniem inicjalizacji migracji sprawdzić, czy tabela zależności jest dostępna; uruchomić testy integracyjne migracji; zapisać wynik; zaktualizować tracker zadań; dołączyć odnośnik do komitów; potwierdzić, że problem się już nie powtarza.
To nie jest fakt, chociaż wynika z jednego. Faktem semantycznym jest to, że tabela musi istnieć przed inicjalizacją. Zasadą proceduralną jest sprawdzenie jej dostępności przed inicjalizacją. Pamięć semantyczna mówi, co jest prawdą, natomiast pamięć proceduralna wskazuje, co należy zrobić. Inne przykłady: cofnięcie nieudanej implementacji, zbadanie awarii płatności, jakie testy muszą przejść przed zamknięciem błędu, jak przeglądać prośbę o połączenie kodu, kiedy poprosić o zatwierdzenie przez człowieka oraz jakie narzędzie należy użyć przed modyfikacją danych produkcyjnych.
Implementacje obejmują od szybkich instrukcji i wersjonowanych przewodników postępowania po spakowane umiejętności, definicje procesów pracy, zwykły kod lub wzorce nabyte z doświadczenia. CoALA zapewnia procedurom własne miejsce w pamięci agenta, powiązane zarówno z możliwościami modelu, jak i z wyraźnym kodem agenta.
Z tego powodu procedury powinny być wersjonowane jak oprogramowanie, a nie gromadzone jak historia rozmów. Jeśli organizacja zmienia swój proces wdrażania, agent nie powinien pobierać pięciu starych procedur i próbować odgadnąć, która z nich jest aktualna. Wszystko, co działa w środowisku produkcyjnym, powinno wskazywać, kto jest za to odpowiedzialny, jaka to wersja, od kiedy obowiązuje, co obejmuje, co ją zastępuje oraz skąd wiemy, że nadal działa.
W tym przypadku bezpośredni wpływ miał brakująca procedura. Agent naprawił kod, ale żadna zasad nie wymagała, aby przekształcił ten sukces w zaktualizowany stan aplikacji. Brakowało nie powtórzenia całej rozmowy, lecz stałej instrukcji w stylu: gdy testy przejdą, zapisz wynik i zamknij ticket. To właśnie jest luka proceduralna.
Jeden błąd, pięć wersji
Taksonomię najłatwiej zobaczyć, zapisując ten sam błąd na pięć różnych sposobów.
- Pamięć robocza: „Obecnie naprawiamy BUG-142; następnym krokiem są testy integracyjne”. Umożliwia kontynuację bieżącej pracy.
- Pamięć epizodyczna: „W pierwszej sesji BUG-142 został naprawiony poprzez zmianę kolejności zależności, a testy przeszły pomyślnie”. Przechowuje konkretne doświadczenia.
- Pamięć semantyczna: „Usługa migracji potrzebuje tabeli zależności przed inicjalizacją”. Zachowuje wiedzę nadającą się do ponownego użycia.
- Pamięć proceduralna: „Przed inicjalizacją migracji sprawdź tabelę i uruchom testy integracyjne”. Przechowuje metody, które można powtarzać.
- Stan autorytatywny: status COMPLETED, commit a7f43d2, testy PASSED. Rejestruje to, co aplikacja uznaje za prawdę.
Są ze sobą powiązane, ale nie można ich zamieniać. Epizod nie zastępuje rekordu zadania, a rekord zadania nie zawiera wszystkiego, czego nauczyło się podczas incydentu. Ten fakt nie określa pełnej procedury debugowania, a procedura ta nie dowodzi, że dany błąd został naprawiony. Nie można oczekiwać, że pamięć robocza przetrwa sesję.
System nie tylko nie był w stanie zapamiętać jednej rzeczy – nie potrafił też przekształcić ukończonej pracy w odpowiednie, trwałe formy.
Każdy typ awarii ma swój własny sposób występowania
Gdy wszystko przechowywane jest w jednym, nierozróżnionym magazynie, diagnostyka staje się trudna. Lepiej zapytać, która informacja nie została przetworzona prawidłowo.
- Pamięć robocza zawodzi, gdy agent traci swój bieżący plan po sformatowaniu, zwykle dlatego, że postępy w realizacji zadania znajdowały się tylko w oknie lub w lokalnym procesie.
Każda praca wymaga własnych zasad dotyczących tego, kto może pisać, w jaki sposób pobierane są dane, jak długo są przechowywane, jak naprawiane są błędy oraz jak oceniana jest jakość. Indeks wektorowy może pomóc w odzyskiwaniu różnych rodzajów pamięci, ale nie decyduje o typie zawartych w niej informacji. Praktyczna zasada: sklasyfikuj dane przed wyborem technologii przechowywania.
Krótki wykaz kryteriów klasyfikacji
Gdy agent napotka jakąś informację, zadaj następujące pytania w kolejności.
- Czy jest potrzebna tylko do bieżącej operacji? Pamięć robocza. Przykładem mogą być aktualny plan, najnowszy wynik narzędzia lub tymczasowa hipoteza.
- Czy chodzi o konkretny zdarzenie, które się wydarzyło? Pamięć epizodyczna. Przykładem może być wczorajsza nieudana implementacja, nieudana próba naprawy lub projekt odrzucony przez użytkownika.
- Czy są to wiedze nadające się do ponownego użycia? Pamięć semantyczna. Przykładem mogą być architektura, preferencje, ograniczenia dziedzinowe oraz definicje biznesowe.
Jedno doświadczenie często wymaga kilku reprezentacji. Nieudane wdrożenie może stanowić epizod (pękło o godzinie 14:20), fakt (usługa X wymaga wersji schematu 17), procedurę (sprawdź zgodność schematu przed wdrożeniem) oraz zmianę stanu (wdrożenie zostało cofnięte). To nie jest marnotrawne duplikowanie, ponieważ każda forma odpowiada na inne pytanie.
Co powinno było zrobić narzędzie
Kontekst nigdy nie musiał istnieć wiecznie. Zadaniem narzędzia było promowanie ważnych wyników przed zakończeniem sesji: zapisanie odcinka, wyodrębnienie faktów, jeśli takie istniały, dodanie lub aktualizacja procedury oraz ustawienie statusu zgłoszenia wraz z dowodami z komitetów i testów.
Gdy to jest już załatwione, bezpiecznie jest usunąć stare rozmowy. Surowy zapis rozmowy może zostać usunięty, ponieważ wszystko, co warto zachować, zostało już przekształcone w formy, które muszą przetrwać. Kontekst może zniknąć, ale ważne wyniki nie powinny zniknąć razem z nim.
Gdzie to prowadzi
Klasyfikacja jest początkiem, a trudniejsze pytania inżynieryjne pojawiają się później. Co zasługuje na przechowywanie? Gdzie powinien znajdować się każdy typ danych i kto może je edytować? Kiedy są one odzyskiwane i w jaki sposób trafiają do systemu? Kiedy są aktualizowane i kiedy wygasają? Co się dzieje, gdy dwa źródła pamięci są sprzeczne, i jak ocenić, czy pamięć w ogóle poprawiła funkcjonowanie agenta?
To właśnie te pytania stanowią podstawę inżynierii pamięci, a żadne z nich nie może zostać dobrze odpowiedziane przed klasyfikacją informacji. Dlatego przed wyborem bazy danych wektorowej, frameworku do zarządzania pamięcią lub strategii wyszukiwania, zastanów się, jakie informacje agent próbuje zachować.
Celem nie jest sprawienie, by agent pamiętał wszystko. Chodzi o to, aby przydatne informacje przetrwały, przechowywane w formie odpowiadającej sposobowi ich wykorzystania. Następnie następuje cykl życiowy, którym kieruje się pamięć: doświadczenie, wydobywanie informacji, decyzja o tym, co zachować, przechowywanie, odzyskiwanie, włączanie do kontekstu, weryfikacja, działanie, a na końcu aktualizacja lub zapomnienie.