W pierwszym poście serii wyróżniliśmy pamięć jako jeden z czterech filarów agenta. Teraz wejdziemy w szczegóły: jak działa okno kontekstowe, co się dzieje gdy się kończy, jakie mechanizmy pamięci istnieją i jak je praktycznie konfigurować.

Okno kontekstowe — pamięć robocza agenta

Okno kontekstowe to odpowiednik pamięci RAM dla agenta. To ile tekstu model "widzi" jednocześnie: prompt systemowy, historia rozmowy, opisy narzędzi, treść czytanych plików — wszystko musi się zmieścić.

1M tokenów brzmi dużo, ale w kontekście agentycznym znika szybciej niż myślisz:

• System prompt + CLAUDE.md + pamięć: ~5 000–10 000 tokenów
• Opisy narzędzi (wbudowane + MCP): ~5 000–15 000 tokenów
• Jeden duży plik źródłowy (500 linii): ~3 000–5 000 tokenów
• Historia 20-turowej rozmowy z wywołaniami narzędzi: ~30 000–80 000 tokenów

Po godzinie intensywnej pracy z agentem okno kontekstowe może być zapełnione w 60–80%. A agent potrzebuje wolnego miejsca na nowe percepcje (wyniki narzędzi, nowe pliki).

Co się dzieje, gdy okno się kończy?

Gdy rozmowa zbliża się do limitu, Claude Code uruchamia kompakcję — automatyczne podsumowanie starszych wiadomości:

graph TD
    A[Pełne okno kontekstowe] --> B[Kompakcja]
    B --> C[Stare wiadomości → podsumowanie]
    C --> D[Podsumowanie + ostatnie wiadomości]
    D --> E[Kontynuacja pracy]

    style B fill:#ff9800,color:#fff

Kompakcja działa tak:

1. Claude Code identyfikuje starsze wiadomości w historii
2. Model generuje zwięzłe podsumowanie: co zostało zrobione, jakie pliki zmieniono, jakie decyzje podjęto
3. Oryginalne wiadomości są zastępowane podsumowaniem
4. Sesja kontynuuje z podsumowaniem + ostatnimi wiadomościami

Czego kompakcja nie zachowuje

Kompakcja to lossy compression — gubi szczegóły:

• Dokładne treści przeczytanych plików (zostają nazwy plików i podsumowanie zmian)
• Pełne wyniki poleceń (zostaje "test przeszedł" zamiast 200 linii output)
• Niuanse rozmowy (subtelne decyzje, alternatywy, które odrzuciłeś)

To ma praktyczne konsekwencje: jeśli na początku sesji ustaliliście z agentem architekturę, a po kompakcji agent "zapomni" niuanse — może wrócić do rozwiązania, które wcześniej odrzuciliście.

Jak minimalizować straty przy kompakcji

• Zapisuj kluczowe decyzje w plikach — nie w rozmowie. Decyzja w PLAN.md lub CLAUDE.md przetrwa kompakcję, bo agent przeczyta plik na nowo. Decyzja "pamiętaj, że wybraliśmy podejście A" w chacie — nie przetrwa.
• Używaj pamięci — system pamięci Claude Code (~/.claude/projects/) zapisuje fakty na dysk. Po kompakcji agent może je odczytać.
• Krótsze sesje — zamiast 4-godzinnej sesji z kompakcją, lepiej zrobić 4 sesje po godzinie. Każda zaczyna od świeżego kontekstu (CLAUDE.md + pamięć).

Dwa rodzaje pamięci agenta

Pamięć agenta dzieli się na dwa fundamentalnie różne mechanizmy:

Pamięć krótkoterminowa (in-context)

To historia bieżącej rozmowy — wszystko co agent "widzi" w oknie kontekstowym. Działa natychmiast, bez opóźnień, z pełną wiernością. Ale jest:

• Ograniczona rozmiarem okna (200k tokenów)
• Efemeryczna — ginie z końcem sesji
• Degradowana przez kompakcję — traci szczegóły

Pamięć długoterminowa (persistent)

Informacje, które przetrwają zamknięcie sesji. W ekosystemie Claude Code mamy trzy mechanizmy:

CLAUDE.md — pamięć strukturalna projektu

CLAUDE.md to nie typowa "pamięć" — to konfiguracja behawioralna wersjonowana w git. Ale z perspektywy agenta pełni funkcję pamięci: mówi mu, co wiedzieć o projekcie zanim cokolwiek przeczyta.

Co warto trzymać w CLAUDE.md:

• Architektura (entry points, wzorzec feature-driven, gdzie co żyje)
• Konwencje kodu (język zmiennych, styl, zakazy)
• Workflow (jak commitować, jak robić PoC, jak czekać na vibe check)
• Stack (Python 3.13, Flask 3.x, uv, pnpm)

Czego nie trzymać:

• Efemerycznych stanów ("teraz pracujemy nad X")
• Danych personalnych
• Rzeczy, które zmienią się za tydzień

CLAUDE.md jest współdzielony z zespołem (w git). To zasadnicza różnica od auto-memory, która jest lokalna.

Hierarchia CLAUDE.md

Claude Code czyta pliki CLAUDE.md w kolejności:

1. Globalny: ~/.claude/CLAUDE.md — preferencje osobiste (język odpowiedzi, styl)
2. Projektowy: CLAUDE.md w korzeniu repo — architektura, konwencje
3. Podkatalogowy: CLAUDE.md w podkatalogu — reguły specyficzne dla modułu

Bardziej specyficzny plik nadpisuje ogólniejszy. Możesz mieć globalną regułę "odpowiadaj po polsku" i per-projekt regułę "testy w pytest, nie unittest".

Auto-memory — pamięć, którą agent buduje sam

System auto-memory w Claude Code to pliki Markdown w ~/.claude/projects/<projekt>/memory/. Agent zapisuje je automatycznie, gdy:

• Użytkownik mówi "zapamiętaj to"
• Agent rozpoznaje korektę stylu ("nie rób X" → zapisuje jako feedback)
• Pojawia się fakt projektowy warty zachowania

Typy pamięci

user — kim jest użytkownik (rola, doświadczenie, preferencje):

---
name: experienced-backend-dev
description: Python/Flask senior, nowy w React — framuj frontend przez analogie do backendu
metadata:
  type: user
---
Użytkownik to doświadczony programista Python/Flask (10+ lat),
ale pierwszy raz dotyka Reacta w tym repozytorium.

- Pomijaj wyjaśnienia składni Pythona i wzorców backendowych.
- Skup się na architekturze i edge case'ach.
- Przy frontendzie tłumacz koncepty przez analogie do backendu
  (np. "komponent React to jak Jinja macro z własnym stanem").
- Preferuje Pydantic nad dataclass, pytest nad unittest.

feedback — co robić / czego nie robić:

---
name: no-auto-commit
description: git commit tylko na wyraźną instrukcję — użytkownik kontroluje treść commitów
metadata:
  type: feedback
---
Nigdy nie commituj samodzielnie — zawsze czekaj na jawne polecenie.

**Why:** użytkownik chce kontrolować treść commit message'y i zakres zmian
w każdym ucommitowanym logicznym kroku. Wcześniej agent commitował
zbyt wcześnie i z nietrafionym message'em, co komplikowało rebase.

**How to apply:** po zakończeniu implementacji wypisz zmienione pliki,
pokaż diff i zapytaj "czy commitować?". Jeśli użytkownik chce split —
przygotuj osobne commity wg jego instrukcji.

project — fakty o projekcie:

---
name: auth-jwt-to-sessions
description: Migracja auth z JWT na sessions — decyzja 2026-05-26, powód compliance
metadata:
  type: project
---
Projekt migruje moduł autoryzacji z JWT na server-side sessions.
Decyzja podjęta 2026-05-26, sponsor: zespół security.

**Why:** audyt bezpieczeństwa wykazał, że JWT refresh tokens przechowywane
w localStorage nie spełniają nowych wymagań compliance (PCI DSS 4.0).
Server-side sessions z httpOnly cookies eliminują ten wektor ataku.

**How to apply:** wszystkie zmiany w `app/auth/` powinny iść w kierunku
sessions (Flask-Session + Redis). Nie dodawaj nowych endpointów JWT.
Istniejące endpointy JWT działają do końca migracji (backward compat).

reference — wskaźniki do zewnętrznych zasobów:

---
name: ml-pipeline-tracking
description: MLflow + DVC — śledzenie eksperymentów i wersjonowanie datasetów
metadata:
  type: reference
---
Zasoby do śledzenia pipeline'u ML:
- **Eksperymenty:** mlflow.internal:5000 — metryki treningów (loss, accuracy,
  F1), porównanie runów, rejestr modeli. Każdy nowy trening logowany
  automatycznie przez `mlflow.autolog()` w `train.py`.
- **Datasety:** DVC remote na S3 (`s3://team-data/dvc-store/`) —
  wersjonowane dane treningowe. Przed zmianą preprocessing'u
  sprawdź `dvc diff` żeby nie nadpisać cudzego eksperymentu.
- **Ewaluacja:** Jupyter w `notebooks/eval/` — notebooki z benchmarkami
  per model. Wyniki publikowane w Confluence: wiki.internal/ml/benchmarks.

Przy zmianach w feature engineering lub augmentacji danych zawsze
uruchom baseline porównawczy (`make eval-baseline`) przed PR-em.

MEMORY.md — indeks pamięci

MEMORY.md to plik indeksowy — lista wskaźników do poszczególnych pamięci. Agent czyta go na starcie sesji, żeby wiedzieć, jakie pamięci istnieją. Każda linia to krótki opis + link do pliku:

# Memory Index
- [Doświadczony backend](user_backend.md) — Python/Flask, pomijaj składnię
- [Nie commituj](feedback_no_commit.md) — commit tylko na polecenie
- [Merge freeze](project_merge_freeze.md) — od 2026-03-05

MEMORY.md jest ładowany do kontekstu — dlatego powinien być zwięzły (limit ~200 linii).

Memory MCP — graf encji

Memory MCP ( opisany w serii MCP #5 ) to alternatywny mechanizm pamięci: serwer MCP przechowujący dane jako graf encji (entity-relation) w pliku JSON.

Różnica od auto-memory:

RAG — pamięć poza kontekstem

RAG (Retrieval-Augmented Generation) to wzorzec, w którym agent wyszukuje relevantne informacje z dużego zbioru danych zamiast trzymać je w kontekście:

graph LR
    Q[Pytanie agenta] --> R[Retriever]
    R --> VS[(Baza wektorowa)]
    VS --> D[Top-K dokumentów]
    D --> LLM[Model + kontekst]
    LLM --> A[Odpowiedź]

W kontekście agenta AI, RAG materializuje się na kilka sposobów:

RAG wbudowany w Claude Code

Claude Code ma natywny RAG — choć nie tak go nazywa:

• Grep — wyszukiwanie tekstowe w kodzie (regex)
• Glob — wyszukiwanie plików po wzorcu
• Agent (Explore) — subagent, który przeszukuje codebase i zwraca podsumowanie

Zamiast wczytywać cały projekt (niemożliwe przy 200k oknie), agent wyszukuje relevantne pliki, czyta je selektywnie i buduje kontekst inkrementalnie. To jest RAG — tylko bez bazy wektorowej.

RAG przez MCP

Serwery MCP mogą implementować RAG:

• Context7 — wyszukuje dokumentację bibliotek (odpowiednik RAG dla docs)
• PostgreSQL MCP — agent odpytuje bazę zamiast trzymać dane w kontekście
• Własny serwer MCP — możesz zbudować serwer z bazą wektorową (Pinecone, Weaviate, ChromaDB) i eksponować go jako narzędzie

Kiedy RAG, a kiedy kontekst

Kontekst (in-context) — gdy dane są małe (<50k tokenów), zmienne i potrzebne w każdej turze. Historia rozmowy, CLAUDE.md, aktualnie edytowany plik.

RAG — gdy dane są duże (>100k tokenów), relatywnie statyczne i potrzebne selektywnie. Dokumentacja, codebase, bazy wiedzy, logi.

Praktyczny przykład: pamięć w akcji

Prompt (poniedziałek): Refaktoruj moduł autoryzacji z JWT na sessions.

Sesja 1 — Implementacja i zapis do pamięci

Prompt (środa): Dokończ migrację auth.

Sesja 2 — Kontynuacja z pamięci

Bez pamięci sesja 2 wymagałaby pełnego briefingu: "pracujemy nad migracją JWT→sessions, dotychczas zmieniliśmy X, Y, Z, zostało A, B, C".

Co dalej

W tym wpisie zobaczyliśmy, jak agent zarządza kontekstem i pamięcią: okno kontekstowe, kompakcja, pamięć krótko- i długoterminowa, RAG i strategie zarządzania kontekstem. W następnym poście zajmiemy się rozszerzaniem agenta w praktyce — custom skills, własne serwery MCP i budowanie workflow dopasowanych do konkretnych projektów.