Pamięć agenta — typowane wpisy, które przeżywają każdą sesję

Pytanie ze scorecardu: Jak używasz auto-memory / pamięci trwałej? Odpowiedź na maksymalny wynik: Świadomie używam typów pamięci (user / feedback / project / reference) i usuwam nieaktualne wpisy.

Dlaczego to ważne w 2026

Pamięć to jedyny mechanizm w stacku agentowym, który za darmo przeżywa między sesjami. Każda inna dźwignia kontekstu kosztuje cię tokeny, uwagę albo jedno i drugie: CLAUDE.md jest ładowany w każdej turze, czy go potrzebujesz, czy nie; pliki planu trzeba odczytywać ponownie; rules w Cursorze są przycinane, kiedy kontekst się zapełnia; historia konwersacji znika pod kompaktowaniem w chwili, gdy sesja przekroczy okno modelu. Pamięć jest wyjątkiem — to trwały, typowany magazyn, do którego agent pisze sam sobie między turami, a kolejna sesja czyta go automatycznie, zanim użytkownik w ogóle coś napisze. Używana dobrze sprawia, że każda kolejna rozmowa zaczyna się dalej, niż skończyła się poprzednia. Używana niedbale puchnie do roli głośnego strychu, w którym stare „używamy jest” kontrastuje z nowym setupem vitest, a agent przez następne pół roku z pewnością siebie robi nie to, co trzeba. Różnica między „pozwalam, żeby auto-memory działała na mnie” a „świadomie steruję tym, co żyje w pamięci, i przycinam to, co nie powinno” to w Q5 największy predyktor tego, czy twoja piąta sesja w danym repo czuje się jak pierwsza, czy jak dziesiąta sesja seniora. Dobra wiadomość: dyscyplina jest mała — cztery typy pamięci do zrozumienia, jeden cotygodniowy przegląd na pruning, garstka slash commandów, żeby to zakodować. Zła wiadomość: bardzo niewielu programistów faktycznie to robi — większość siedzi w przedziale 0–1 pkt, czyli albo w ogóle nie używa pamięci, albo traktuje ją jak czarną skrzynkę „agent sobie poradzi”. Tę lukę zamykamy w tym przewodniku.

Jak naprawdę wygląda maksymalny wynik

Setup na maksymalny wynik w Q5 jest świadomy, typowany i przycinany. Konkretnie: kiedy w sesji wypływa coś użytecznego — preferencja, którą wyraziłeś trzy razy, feedback, który ciągle dajesz, świeżo podjęta decyzja projektowa, URL referencyjny, do którego agent ciągle dochodzi od zera — kierujesz to do pamięci z właściwym typem. Nie pozwalasz auto-memory wybrać za ciebie; potwierdzasz albo poprawiasz typ, kiedy agent proponuje zapis, i odrzucasz te, które są po prostu sesyjnym szumem. W rytmie tygodniowym (albo po każdym sensownym kamieniu milowym w projekcie) przeglądasz ~/.claude/memories/ lub odpowiednik, kasujesz wpisy, które już nie obowiązują, edytujesz te, które się rozjechały, i promujesz wpisy z poziomu project na user, jeśli mają cię śledzić między repo. Cztery typy pamięci znasz z pamięci mięśniowej i potrafisz w niecałe pięć sekund powiedzieć koledze, do którego typu pasuje dany snippet.

Cztery typy z konkretnymi przykładami tego, co należy do każdego:

User memory — fakty o tobie, które powinny iść za tobą przez każdy projekt i każdą sesję. „Podstawowy język to TypeScript; Python traktuję jako drugorzędny.” „Senior backend engineer uczący się Rusta; tłumacz Rust przez analogię do Go.” „Wolę kompozycję funkcyjną od hierarchii klas.” „Czytam kod na 13-calowym ekranie, więc łam diffy do 100 znaków w propozycjach.” User memory to najmniejszy z czterech typów (5–15 wpisów), ale najbardziej dźwigniowy — kształtuje sposób, w jaki każda przyszła sesja z tobą rozmawia.
Feedback memory — jak agent ma pracować z tobą, kumulowane z korekt, które mu zgłaszałeś. „Nie streszczaj na końcu wiadomości tego, co właśnie zrobiłeś.” „Zawsze odpal testy zanim ogłosisz koniec; nigdy nie ufaj, że build przeszedł, bez zobaczenia zielonego paska.” „Kiedy proponujesz refactor, w tej samej wiadomości dorzuć plan rollbacku.” „Bez emoji w kodzie ani w wiadomościach commitów.” Feedback memory to drugi najbardziej dźwigniowy typ, bo bezpośrednio zdejmuje tarcie z każdej przyszłej tury — każdy wpis to korekta, której więcej nie musisz powtarzać.
Project memory — stan, decyzje i ograniczenia tego projektu tu i teraz. „Migracja z subskrypcji Polar.sh na BetterAuth + Polar webhook bridge, faza 8/10 w toku.” „Drizzle schema żyje w src/lib/db/schema.ts; nie duplikuj definicji tabel w scripts/schema.sql.” „Logika paywalla świadomie siedzi w czystym JS w /public/paywall-inline.js — nie przerabiaj na Reacta.” Project memory najszybciej się starzeje z czterech typów — najczęściej będzie nieaktualna przy kolejnym przeglądzie.
Reference memory — wskazówki, gdzie żyje informacja w systemach zewnętrznych. „Bugi pipeline trzymane w projekcie Linear WND-INGEST.” „Tablica latencji w Grafanie pod grafana.internal/d/api-latency.” „Dokumentacja webhooków Polar: polar.sh/docs/integrate/webhooks.” Reference memory to twój „zewnętrzny mózg” — małe wpisy, które oszczędzają agentowi (i tobie) odkrywania tego samego URL-a w każdej sesji.

Niższe poziomy łatwo rozpoznać. 0 pkt („nie używam pamięci”): auto-memory wyłączone albo nigdy nie otworzyłeś katalogu; każda sesja startuje od zera. 1 pkt („pozwalam, żeby działo się samo”): auto-memory włączone, nigdy nie zaglądasz, nie wiesz, jakiego typu są twoje wpisy. 2 pkt („piszę okazjonalny wpis”): czasem szturchasz agenta przez #memorise this, ale nie myślisz typami i nie przycinasz. 3 pkt (maks): cztery typy są drugą naturą, cotygodniowy prune jest w kalendarzu, nieaktualne wpisy to rzadkość, a pierwsza tura świeżej sesji wyraźnie odzwierciedla to, co było wcześniej.

Aktualny krajobraz (zweryfikowany przez web search)

Trwała, typowana pamięć to dziś feature Claude Code. Cursor ma tylko rules (bez typowanego auto-memory). Codex ma kompaktowanie sesji (kształtem podobne do pamięci, ale to nie to samo). Wiedza o tym, co który tool ci daje, determinuje, jaką dyscyplinę możesz zbudować.

Claude Code typed memory (user / feedback / project / reference)

Claude Code to jedyny mainstreamowy tool agentowy z pierwszej klasy typowanym auto-memory w 2026. Mechanizm: w trakcie pracy Claude między turami pisze do siebie wpisy pamięci z polem metadata.type — jednym z user, feedback, project, reference — a kolejna sesja czyta je z powrotem przed pierwszą turą użytkownika. Nie musisz prosić. System prompt instruuje Claude’a, żeby dobierał właściwy typ i odświeżał, a nie duplikował, kiedy istniejący wpis pokrywa nowy fakt. Magazyn możesz przejrzeć bezpośrednio: pliki pamięci żyją pod ~/.claude/memories/ (i odpowiednikiem per-projekt dla wpisów typu project). Możesz je edytować w $EDITOR, usuwać wpisy, pisać ręcznie. Możesz też wymusić zapis w sesji przez #remember this: <fakt> albo prosząc „save this as a feedback memory”. Cztery typy podsumowane, do czego służy każdy:

user — trwałe fakty o tobie, które mają iść za tobą przez projekty. Rola, poziom doświadczenia, języki, preferencje co do sposobu wyjaśniania. Z definicji cross-project.
feedback — korekty i meta-instrukcje, jak Claude ma dla ciebie pracować. Rzeczy, które powiedziałeś więcej niż raz. Z definicji cross-project.
project — bieżący stan i aktywne decyzje w tym repo. Szybko się starzeje; wymaga częstego przeglądu.
reference — wskazówki do systemów zewnętrznych (kody projektów Linear, dashboardy, URL-e do dokumentacji, runbooki). Tanie, długowieczne, niskie ryzyko starzenia.

Znana ostra krawędź na maj 2026 (issue #58840 na GitHubie): wpisy user i feedback — które z definicji są cross-project — są domyślnie zapisywane do katalogu per-projekt, czyli nie wędrują automatycznie między repo. Społeczność do czasu, aż Anthropic dowiezie routing-po-typie, obchodzi to ręcznie: kopiuje albo symlinkuje wpisy typu user i feedback z folderu pamięci projektu do globalnego ~/.claude/memories/, żeby faktycznie żyły tam, gdzie sugeruje ich typ. Pilnuj tego issue; jest gorący i prawdopodobnie zostanie szybko naprawiony.

Cursor — przybliżenie przez rules

Cursor w 2026 nadal nie ma auto-memory w sensie Claude Code. To, co ma, to rules — pliki Markdown (.cursor/rules/*.md) wstrzykiwane w kontekst agenta w każdej istotnej turze. Rules pisze użytkownik, nie agent; nie ma czegoś takiego jak „agent się tego nauczył i zapisał na później”. To znaczy, że rules potrafią przybliżyć pamięć user i feedback, jeśli zdyscyplinujesz się, żeby je spisać — „zawsze TypeScript, nigdy any” może żyć w regule style.md — ale nie przybliżą pamięci project (stan projektu zmienia się za szybko, żeby ręcznie utrzymywane reguły nadążyły) ani pamięci reference (nie ma magazynu URL-i napędzanego przez agenta). Pragmatyczny pattern w Cursorze to: pisz rules na rzeczy trwałe (twoje sloty user i feedback) i pogódź się z tym, że dla stanu projektowego — który Claude Code zapamiętałby automatycznie — będziesz się powtarzać.

Codex — kompaktowanie sesji

Codex CLI w 2026 nie ma żadnej trwałej pamięci. Codex ma natomiast kompaktowanie sesji: kiedy okno kontekstu się zapełnia, agent streszcza wcześniejsze tury do skondensowanego bloku, żeby sesja mogła trwać dalej. Kompaktowanie pomaga w obrębie sesji — trzyma długie debugowanie przy życiu — ale w chwili, gdy sesja się kończy, streszczenie znika. Jeśli używasz Codex CLI jako głównego tool’a i chcesz cokolwiek o kształcie pamięci, musisz to skleić ręcznie: plik AGENTS.md w korzeniu repo, który traktujesz jak project memory, osobisty ~/.codex/AGENTS.md (jeśli go obwiązałeś), który traktujesz jak user memory, i dyscyplina, żeby aktualizować jedno i drugie samodzielnie. Jest to bardziej clunky niż typed memory w Claude Code, ale lepsze niż nic.

Rytm pruningu

Niezależnie od narzędzia pruning waży więcej niż pisanie. Nieaktualne wpisy są gorsze niż brak pamięci: przedawniony „używamy jest” będzie aktywnie wprowadzał agenta w błąd miesiącami po tym, jak przeszedłeś na vitest. Minimalna dyscyplina to cotygodniowy prune — otwórz katalog pamięci (albo folder reguł), przejrzyj wpisy, skasuj albo zaktualizuj to, co już nie obowiązuje. Lepsza dyscyplina to prune sterowany zdarzeniem: po każdym kamieniu milowym (faza dowieziona, stack wymieniony, refactor zmergowany) zrób ukierunkowany prune wpisów typu project związanych z tym kamieniem. Najlepsza dyscyplina łączy oba — cotygodniowy skim plus ukierunkowany prune po milestone — i traktuje wpisy user i feedback jako półtrwałe (przegląd miesięczny, nie tygodniowy).

Wdrożenie krok po kroku

Potwierdź model pamięci tool’a i miejsce, gdzie żyje. Dla Claude Code: ls ~/.claude/memories/ i ls .claude/memories/ (per-projekt). Dla Cursora: ls .cursor/rules/. Dla Codex CLI: sprawdź, czy masz AGENTS.md w korzeniu i swoją osobistą wersję. Nie da się zarządzać czymś, czego nie widzisz; krok zerowy to otwarcie katalogu i przeczytanie, co tam siedzi.
Zrób audyt tego, co już jest. Przeczytaj każdy istniejący wpis pamięci albo regułę. Dla każdego zdecyduj: do którego z czterech typów należy (user, feedback, project, reference)? Czy nadal jest prawdą? Czy jest actionable, czy to szum, który agent zapisał w trakcie długiej sesji? Przy pierwszym audycie typowo 30–50% wpisów będzie albo źle stypowane, albo nieaktualne. Skasuj nieaktualne, przetypuj źle przypisane — i już ruszyłeś z 1 pkt na 2 pkt.
Wejdź w nawyk czteropoziomowego słownika. Wydrukuj cztery typy na karteczce na tydzień. Za każdym razem, kiedy dajesz agentowi korektę albo wyrażasz preferencję, zapytaj się „jaki to typ?”, zanim wyślesz kolejną wiadomość. Po tygodniu zaczniesz sortować w głowie bez wysiłku.
Sterowanie zapisem — świadomie. Kiedy agent proponuje zapis do pamięci — albo kiedy sam chcesz wymusić — wypowiedz typ na głos. „Save this as a feedback memory: don’t summarise at the end of messages.” „Save this as a reference: kod projektu Linear dla bugów ingest to WND-INGEST.” „Save this as a project memory: logika paywalla zostaje w czystym JS.” Jawny typ wymusza czysty wpis i trenuje twój odruch.
Promuj wpisy user-level z katalogu projektu na globalny. Jeśli jesteś na Claude Code i widzisz, że wpis typu user lub feedback siedzi w katalogu pamięci per-projekt, przenieś go (albo skopiuj) do ~/.claude/memories/, żeby śledził cię wszędzie. Dopóki issue #58840 nie zostanie zamknięty, robisz to ręcznie. Trzydzieści sekund raz w tygodniu — i to jest najbardziej dźwigniowy nawyk w całym przewodniku.
Wpisz cotygodniowy prune w kalendarz. Postaw 10-minutowy slot — piątek po południu działa dobrze — z etykietą „memory prune”. Otwórz katalog. Przejrzyj każdy wpis project: nadal prawdziwy? Nadal istotny? Skasuj albo zaktualizuj. Przejrzyj reference: URL nadal działa? Kod projektu nadal w użyciu? Wpisy user i feedback przeglądaj raz w miesiącu, lekko. Cel to nie zero wpisów — cel to świeże wpisy.
Odpalaj prune po milestone. Kiedy dowozisz fazę, wymieniasz stack, mergujesz duży refactor, zrób ukierunkowany prune wpisów project związanych ze zmianą. Przykład z tego repo: kiedy faza 7 migracji Polar się zamknęła i legacy endpointy subskrypcji zostały usunięte, każda project memory referująca te endpointy musiała iść w tym samym commicie.
Weryfikuj pierwszą turę każdej nowej sesji. Otwórz świeżą sesję Claude Code w projekcie. Zapytaj „co pamiętasz o tym projekcie?” albo „streść istotne pamięci, zanim zacznę”. Jeśli pierwsza tura odzwierciedla to, co było — bieżąca faza, aktywne konwencje, twoje preferencje — twoja pamięć jest zdrowa. Jeśli jest mglista, sprzeczna albo błędna, masz prune do zrobienia.

Częste pułapki

Memory bloat. Pozostawione samo sobie auto-memory zapisuje wpis przy każdym lekko podkreślonym preferencyjnym sformułowaniu. Symptom: setki nakładających się wpisów, sprzeczne rady. Lekarstwo: prune co tydzień i zmerguj prawie-duplikaty w jedne kanoniczne wpisy.
Nieaktualne wpisy kłócące się z rzeczywistością. Pół roku temu zmigrowałeś z jest na vitest, ale wpis project nadal twierdzi „we use jest” i agent dalej pisze jest matchers. Lekarstwo: prune po milestone (krok 7) — każda zmiana stacku odpala sweep pamięci.
Zapisywanie nie tego, co trzeba. Drobiazgi sesyjne lądują jako trwałe preferencje. „Aktualnie debuguję webhook Polar” to stan sesji, nie pamięć. Lekarstwo: pytaj „czy to będzie istotne za miesiąc?”, zanim potwierdzisz zapis.
Zapisy ze złym typem. Preferencja user-level zapisana jako project memory ginie przy zmianie repo; notatka o stanie projektu zapisana jako user memory wlecze się wszędzie. Lekarstwo: krok 5 — promuj źle przypisane wpisy, potwierdzaj typ w chwili zapisu (krok 4).
Traktowanie pamięci jak czarnej skrzynki. Agent zapisał, agent czyta, nikt do środka nie zagląda. Lekarstwo: otwórz katalog. Płaskie pliki Markdown/JSON; czytanie zajmuje minuty.
Niespójność między toolami. Skakanie między Claude Code (typed), Cursor (rules), Codex (sama kompakcja) — wpisy nie wędrują. Lekarstwo: wybierz jeden tool jako memory-of-record (w 2026 oczywistym wyborem jest Claude Code), pozostałe traktuj jako best-effort.

Jak sprawdzić, czy już tam jesteś

Potrafisz wymienić cztery typy pamięci z głowy i dać przykład każdego osadzony w twojej realnej pracy.
ls ~/.claude/memories/ (albo odpowiednik w twoim toolu) zwraca niepusty, świeżo wyglądający katalog, którego dotykałeś w ciągu ostatnich 7 dni.
Cotygodniowy slot na memory-prune jest w twoim kalendarzu; potrafisz pokazać ostatnio zakończony prune.
Po milestone (faza dowieziona, stack wymieniony) pamiętasz, żeby przyciąć wpisy typu project w tym samym tygodniu.
Pierwsza tura świeżej sesji w znajomym projekcie odzwierciedla to, co było wcześniej — bieżąca faza, konwencje, twoje preferencje — bez konieczności przypominania.
Wpisy typu user i feedback, które powinny iść za tobą wszędzie, faktycznie idą (wyniosłeś je z katalogów per-projekt do ~/.claude/memories/ na czas, gdy issue #58840 jest otwarty).
Potrafisz wskazać co najmniej jedną feedback memory, która faktycznie zdjęła z twoich sesji powtarzającą się korektę.
Nieaktualne wpisy to wyjątek, nie reguła.

Dalsza lektura

Q4 · CLAUDE.md / AGENTS.md Warstwowe pliki kontekstu działające w parze z pamięcią — trwałe konwencje vs. ewoluujące wpisy pamięci.

Q6 · Plan mode Brama planowania, dzięki której pamięć kształtuje lepsze plany w każdej sesji.

Q24 · Nadążanie za narzędziami Reguły pamięci i kwirki narzędzi zmieniają się co miesiąc — jak zostać na fali zmian.

Wypełnij Developer Scorecard Zobacz, gdzie jesteś we wszystkich 25 pytaniach AI Developer Scorecard.