Tworzenie pamięci agenta, która przetrwa rozmowę bez gromadzenia nadmiaru informacji.

Scena, która powtarza się niemal przy każdym agencie, który trafia do fazy produkcji, wygląda tak.

W poniedziałek użytkownik mówi, że zarządza regionem Północno-Zachodnim, interesują go tylko aktywne projekty i nie znosi długich odpowiedzi. Agent mówi „Zrozumiałem”, a przez resztę sesji oznacza to dokładnie to: odpowiedzi są krótkie, dotyczą wyłącznie regionu Północno-Zachodniego i nie ma w nich wersji roboczych. Użytkownik jest zadowolony.

We wtorek ta sama osoba otwiera nową rozmowę i pyta, jak idą jej projekty. Agent wesoło pyta, o który region chciałby usłyszeć.

Wyraz twarzy tego użytkownika jest powodem, by dokładnie przemyśleć kwestię pamięci.

Dlaczego przechowywanie wszystkiego zawodzi

Prawie każdy programista ucieka się do tego samego rozwiązania: przechowuje całą rozmowę i ładuje ją ponownie jutro. Wydaje się to oczywiste, ale to pułapka. Sposób, w jaki to zawodzi, uczy o projektowaniu agentów więcej niż większość tutoriali.

Załóżmy, że cała historia jest przechowywana i odtwarzana za każdym razem, gdy użytkownik wraca. Wydarzenia zachodzą w przewidywalnej kolejności.

W pierwszym tygodniu wszystko działa dobrze. Agent rzeczywiście pamięta wszystko, a ty czujesz się sprytny. To jest niebezpieczny etap, ponieważ wydaje się potwierdzać poprawność projektu.

W trzecim tygodniu system staje się wolny i kosztowny. Każda kolejna interakcja wymaga przetworzenia tysięcy tokenów ze starych rozmów. Płacisz za błahe rozmowy z poniedziałku, odpowiadając na pytanie z piątku. Okno kontekstowe jest biurkiem agenta, a ty już przed rozpoczęciem dzisiejszej pracy zasypałeś je dokumentami z zeszłego tygodnia.

Szósty tydzień – sytuacja się pogarsza. Nikt nie ostrzega przed tą fazą. Stare rozmowy zawierają stwierdzenia, które przestały być prawdziwe. Użytkownik skupiał się na północnym zachodzie, dopóki awans nie postawił go na czele całego kraju. Projekt był opóźniony aż do momentu jego wdrożenia. Odtwarzanie wszystkiego zmusza agenta do równego traktowania zarówno przestarzałych, jak i aktualnych faktów. Problemem nie jest już to, że pamięta zbyt mało – pamięta za dużo, bez pojęcia o tym, co już przeminęło.

Odtwarzanie pełnych historii to w istocie maszyna do tworzenia przestarzałego kontekstu. Dlatego pytanie „jak zapisać wszystko?” nigdy nie było właściwym pytaniem. Prawidłowe pytania brzmią:

Które informacje warto zachować, które należy pobrać w razie potrzeby, a które należy usunąć i stworzyć od nowa?

Odpowiedz na nie, a architektura pamięci będzie jasna.

Projekt trójpoziomowy

Porównaj to z sposobem, w jaki radzisz sobie z informacjami w pracy. Niektóre rzeczy zachowujesz w pamięci podczas spotkania, a potem z radością o nich zapominasz. Inne zapisujesz w notatniku, ponieważ będziesz ich potrzebować w przyszłym miesiącu. Jeszcze inne nigdy nie zapamiętujesz, ponieważ się zmieniają i sprawdzasz je za każdym razem. Agenci potrzebują tych samych trzech poziomów przechowywania.

Poziom 1: pamięć sesji, która ma zniknąć

Na tym poziomie przechowywane są wszystkie informacje związane z bieżącą rozmową: historia wiadomości, wyniki pośrednich narzędzi, nieukończona wieloetapowa zadanie oraz stan LangGraph przemieszczający się między węzłami.

Gdy sesja się kończy, ten poziom może zniknąć. To nie jest zapomniane zapisanie – został tak zaprojektowany, by zniknąć, i to jest jego zaleta.

Początkujący czują się z tego powodu winni, choć nie muszą. Opis rozmowy krok po kroku przypomina spotkanie: liczy się nie transkrypcja, lecz wnioski. Dlatego interesujące pytanie brzmi, co trafia do poziomu 2 po zakończeniu sesji.

Nie transkrypcja. Mały, wyraźny krok ekstrakcji wyodrębnia trzy kategorie:

1. Stabilne fakty o użytkowniku, takie jak „zarządza regionem Północny Zachód”, obowiązujące do czasu odwołania.
2. Preferencje, takie jak „chce krótkich odpowiedzi” i „wykluczyć projekty w wersji roboczej”.
3. Decyzje, takie jak „zgodził się na format cotygodniowego podsumowania”.

Rozmowa w tamten poniedziałek może osiągnąć cztery tysiące tokenów. To, co zasługuje na przetrwanie po niej, to około czterdzieści tokenów strukturyzowanych faktów, co stanowi kompresję o około stu razy większą. W odróżnieniu od streszczenia, nic ważnego nie zostaje zatarte, ponieważ wyodrębniono nazwane kategorie zamiast ogólnego wrażenia. Streszczenia po cichu pomijają określone ograniczenia, natomiast metoda wyodrębniania jest rozwiązaniem: preferencja albo trafia do listy słowo w słowo, albo nie, i można napisać test w tym celu.

Poziom 2: pamięć długoterminowa, mała, strukturyzowana i edytowalna

To jest kompaktowy magazyn, który przetrwa między sesjami – notatnik użytkownika. Opieraj się pokusie bycia sprytnym. Właśnie nudny format sprawia, że to działa:

{
  "user_id": "u-2481",
  "facts": [
    {"fact": "manages Northwest region", "updated": "2026-08-03"},
    {"fact": "prefers concise answers", "updated": "2026-07-19"}
  ],
  "preferences": [
    {"pref": "exclude draft projects from reports", "updated": "2026-08-03"}
  ],
  "decisions": [
    {"decision": "weekly summary every Monday", "updated": "2026-07-28"}
  ]
}

Kilkadziesiąt wierszy JSON na użytkownika, ładowanych do kontekstu na początku każdej sesji. Są na tyle tanie, że można je zawsze uwzględniać, a na tyle małe, że nie powodują przeciążenia.

Trzy zasady zapewniają ich prawidłowe funkcjonowanie.

Struktura jest lepsza od prozy. Niejasne opisy typu „ten człowiek prawdopodobnie zajmuje się regionem Northwest i lubi zwięzłość” okazują się bezużyteczne później. Natomiast poszczególne fakty można pokazać użytkownikowi, skorygować i usunąć pojedynczo.

Zaznaczaj datę każdej informacji i zastępuj dane, zamiast je dodawać. Gdy użytkownik przechodzi z regionu Northwest do National, nie dodaje się drugiego faktu obok pierwszego – zastępuje się go. Gdy w bazie znajdą się zarówno informacja „zarządza regionem Northwest”, jak i „zarządza National”, powstaje problem starego stanu w połączeniu z bazą danych, co jest jeszcze gorsze, ponieważ taki stan pozostaje nieaktualny na zawsze.

Pozwól użytkownikowi to zobaczyć i to naprawić. Nawet prosta instrukcja typu „oto, co pamiętam o tobie” zmienia sytuację. Pamięć, której użytkownik nie może sprawdzić, z czasem staje się pamięcią, której nie ufa – zazwyczaj w momencie, gdy agent z pełną pewnością siebie podaje informację, która jest już przestarzała od miesięcy.

To, co pozostaje poza Poziomem 2, to wszystko, co można sprawdzić. Należy ono do Poziomu 3, a zespoły najczęściej tracą tam czas na niewłaściwe rzeczy.

Poziom 3: regeneracja na żądanie, celowe nieraportowanie

Tutaj znajduje się wszystko, co zmienia się samo z siebie: statusy projektów, liczby, daty, schematy organizacyjne, aktualne dane, zawartość baz danych i API.

Zasada jest taka, że ten poziom informacji nigdy nie powinien być zapamiętywany. Nie należy go podsumowywać, przechowywać w pamięci ani przenosić z wcześniejszej rozmowy. W momencie potrzeby agent wywołuje narzędzie i uzyskuje aktualną wartość.

Gdy to zapisać, brzmi to oczywiste. Jest to jednak najbardziej problematyczna zasada w pamięci agenta, ponieważ przechowywanie aktualnych danych jako informacji w pamięci wygląda jak optymalizacja. W rzeczywistości jest to bomba zegarowa o wolnym zapalniku:

• Zapisuje się „Projekt Falcon jest opóźniony”, a potem projekt zostaje dostarczony. Przez tygodnie agent nadal mówi o projekcie, który już został ukończony.
• Zapisuje się „zespół składa się z 8 osób”, a potem dołączają dwie osoby. Wszystkie odpowiedzi dotyczące pojemności zespołu są błędne.

Najlepszym podsumowaniem całej tej architektury jest prawdopodobnie to:

Dla informacji o osobie używaj pamięci. Dla informacji o wszystkim innym używaj narzędzi.

Preferencje użytkowników rzadko się zmieniają, a oni sami powiadomią cię o tym. Świat zmienia się nieustannie, ale nic ci o tym nie mówi. Dlatego pamiętaj o użytkowniku i pytaj świat.

Przypadek awarii: „dziel się wszystkim” spotyka system wielu agentów

To wersja uproszczona. Droga do niej prowadziła przez incydent w fikcyjnym systemie dwóch agentów w firmie świadczącej usługi sieciowe.

Agent A rozmawiał z użytkownikami i zbierał wymagania dotyczące raportów. Agent B przygotowywał te raporty. Gdy A przekazywał pracę B, zespół powtórzył błąd początkujących w skali architektury: przekazali cały kontekst A, w tym pełną rozmowę, wszystkie wyniki narzędzi oraz stan systemu. Rozumowanie wydawało się bezbłędne. Czyż więcej kontekstu nie oznacza lepiej poinformowanego B?

Sposób, w jaki to się zepsuło, jest najważniejszy. Podczas jednej sesji użytkownik powiedział na głos do Agenta A: a co, gdyby dodać projekty archiwizowane? Po chwili namysłu stwierdził jednak, że to zniekształci sumy, więc lepiej je pominąć. To było zupełnie normalne rozważanie na głos, a Agent A postąpił we właściwy sposób.

Następnie nastąpiła przenoszenie informacji i Agent B otrzymał cały zapis rozmowy, włączając boczne tematy. Jednak B nie miał żadnego kontekstu rozmowy A, który pomógłby mu to ocenić. W treści nie było nic, co wskazywałoby na odrzucenie pomysłu dodania projektów archiwizowanych, a poza kontekstem wyglądało to jak instrukcja. Agent B wiernie dodał projekty archiwizowane, w wyniku czego sumy w oficjalnym raporcie były błędne – z powodu, którego nikt nie mógł się dowiedzieć, analizując kod B, ponieważ jego kod był w porządku.

To jest wieloagentowa wersja wszystkiego powyżej: przekazanie informacji stanowi granicę sesji. Gdy Agent B rozpoczyna swoją pracę, to nowa rozmowa z wtorku. Zespół popełnił ten sam błąd „zapisania wszystkiego” pomiędzy agentami, zamiast robić to w ciągu kolejnych dni.

Rozwiązanie było takie samo. Przekazywanie transkryptów ustąpiło miejsca strukturyzowanemu pakietowi informacji do przekazania, w praktyce tymczasowemu elementowi typu Tier 2, który Agent A tworzy dla Agenta B:

{
  "task": "generate weekly regional report",
  "requirements": [
    "region: Northwest",
    "active projects only",
    "exclude drafts AND archived"
  ],
  "format": "summary table first, details after",
  "constraints_confirmed_by_user": true
}

To około pięćdziesiąt tokenów bez żadnej niejednoznaczności. B otrzymuje wnioski, a nie krętą drogę prowadzącą do nich. Kategoria archived-projects błędów stała się niemożliwa do zastosowania, a nie tylko trudna do wykrycia czy obsłużenia, ponieważ porzucone pomysły fizycznie nie mogą przetrwać po wyjęciu ich na listę wymagań.

Weźmy jedno zdanie w dowolnym projekcie opartym na wielu agentach: agenci powinni przekazywać sobie nawzajem wnioski, a nigdy transkrypcje.

Lista kontrolna do zastosowania w tym tygodniu

Pięć decyzji, które możesz podjąć w odniesieniu do istniejącego agenta:

1. Pozwól pamięci sesji zniknąć. Dodaj krok wydobywania na końcu sesji lub po N ruchach, który przeniesie jedynie fakty, preferencje i decyzje, pozwalając na to, by reszta zniknęła wraz z rozmową.
2. Zachowaj Tier 2 jako nudny JSON. Dyskretne elementy, daty i godziny, aktualizacje zastępujące stare dane. Nigdy rosnący blok tekstu, a także nigdy tylko dodawanie nowych danych na końcu.

Daj użytkownikom możliwość dostępu do informacji. Pytanie typu „Co pamiętasz o mnie?” – nawet proste – buduje zaufanie i pozwala bezkosztowo wykryć przestarzałe dane.

Przeprowadź audyt poziomu 2 dotyczący faktów o świecie. Wszystko, co narzędzie mogłoby pobrać w aktualnej formie – takie jak statusy, liczby, daty i wartości numeryczne – powinno zostać usunięte. Pamięć służy użytkownikowi, a narzędzia – światu.

Przekazuj wnioski w trakcie przekazywania zadań. Używaj ustrukturyzowanego pakietu danych zawierającego zadanie, wymagania i ograniczenia. Jeśli twoje przekazanie zawiera surowy zapis rozmowy, to już przeniosłeś powyższy błąd, nawet o tym nie wiedząc.

Główny wniosek

Sprawianie, że pamięć oznacza przechowywanie większej ilości danych, jest zupełnie błędne. Każdy z powyższych problemów – od prób rozwiązania amnezji na wtorek, przez przestarzałe informacje, aż po raporty o archiwizowanych projektach – wynika z zbytniego i nieostrożnego gromadzenia danych.

Dobrze funkcjonująca pamięć agenta opiera się przede wszystkim na umiejętności zapominania. Stan sesji może zniknąć, notatki długoterminowe są na tyle krótkie, że można je przeczytać jednym spojrzeniem, a nic z tego, co nowe może ci powiedzieć świat, nie zostaje zapamiętane. Agenci, które sprawiają wrażenie naprawdę osobistych, to nie te, które pamiętają wszystko – one pamiętają właściwe czterdzieści tokenów.