Pamięć agenta

1. Przegląd koncepcji i problem systemowy

Bez pamięci systemowej każde uruchomienie autonomicznego agenta jest całkowicie izolowane (stateless). Model ograniczony jest fizycznym rozmiarem okna kontekstowego (Context Window Limit) i po zakończeniu sesji traci wszystkie wyciągnięte wnioski, naprawione błędy oraz ustawienia użytkownika.

Próba rozwiązania tego problemu „na siłę” – poprzez wysyłanie całej historii przed każdym promptem – prowadzi do trzech krytycznych ślepych zaułków inżynieryjnych:

1. Eksponencjalny wzrost kosztów tokenów oraz opóźnień (Time to First Token).
2. Degradacja uwagi modelu (Lost-in-the-Middle): nadmuchany kontekst rozprasza mechanizm Self-Attention, prowokując pomijanie krytycznych instrukcji.
3. Brak uczenia się na błędach: agent ponownie natrafia na te same bugi w bazie kodu, które rozwiązywał już w poprzedniej sesji.

Architektura Agent Memory dzieli przechowywanie stanu na wyspecjalizowane warstwy, zapewniając agentowi długoterminową pamięć przy minimalnym zużyciu tokenów.

2. Taksonomia architektoniczna i model mentalny

W nowoczesnej inżynierii agentowej pamięć standardowo dzieli się na cztery warstwy funkcjonalne:

• 1. Krótkotrwała (Working / Scratchpad Memory): Bufor operacyjny bieżącej iteracji (pętla ReAct). Przechowuje myśli pośrednie (thoughts), argumenty wywołań narzędzi (tool calls) oraz odpowiedzi środowiska systemowego. Żyje jedynie przez cykl życia bieżącego zadania (w pamięci procesu lub Redis).
• 2. Epizodyczna (Episodic Memory): Kronika przeszłych doświadczeń agenta: sekwencje działań, próby wykonania zadań, przyczyny awarii testów i znalezione poprawki. Pozwala agentowi przypomnieć sobie: „Już próbowałem wykonać tę migrację tą metodą wczoraj i wystąpił deadlock – wybiorę inną ścieżkę”.
• 3. Semantyczna (Semantic Memory): Baza wydobytych wiedzy, faktów i encji dotyczących otaczającego świata, użytkownika oraz repozytorium. Realizowana jako strukturalna baza faktów (Knowledge Graph) lub baza danych wektorowych z embeddingami.
• 4. Proceduralna (Procedural Memory): „Pamięć mięśniowa” agenta: algorytmy, ustalone workflow, składnia niestandardowych narzędzi, zasady formatowania kodu oraz instrukcje systemowe (w tym pliki .agents/skills i .agents/rules w repozytorium).

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia pamięci autonomicznego agenta realizowany jest poprzez czterostopniowy potok:

1. Extraction & Filtering (Ekstrakcja i filtrowanie faktów): Lekki parser LLM działający w tle lub heurystyczny ekstraktor analizuje zakończoną rozmowę lub krok narzędzia. Odcina szum komunikacyjny („dziękuję”, „zrozumiałem”) i wydobywa atomy faktów (Atomic Facts).
2. Hybrid Indexing (Indeksowanie hybrydowe): Uzyskane encje zapisywane są w magazynie z podwójnym indeksem: gęste wektory (Dense Embeddings) do wyszukiwania semantycznego + indeks BM25/full-text do dokładnego dopasowania identyfikatorów, nazw funkcji i stałych.
3. Context-Aware Retrieval (Selektywne pobieranie): Przed generacją następnej odpowiedzi ranker oblicza integralną ocenę trafności wspomnienia według wzoru: Score = w1 * Relevance + w2 * Recency (zanikanie wykładnicze) + w3 * Importance (istotność). Do roboczego promptu ładowane są tylko top-$K$ najważniejszych fragmentów.
4. Memory Compaction & Consolidation (Kompresja i konsolidacja): Okresowy proces zwija stare łańcuchy epizodyczne w wnioski wysokiego poziomu (Recursive Summarization), uwalniając zasoby bazy wiedzy.

4. Praktyczne scenariusze inżynieryjne w produkcji

01. Spersonalizowany kontekst dewelopera

Agent automatycznie rejestruje i przechowuje reguły konkretnego programisty: np. używanie strict TypeScript, specyfikę obsługi błędów przez Result<T, E>, niechęć do widzenia any czy preferencję określonych bibliotek do zarządzania stanem, eliminując potrzebę powtarzania tych informacji w każdym czacie.

02. Kontekst architektoniczny bazy kodu

Zachowywanie decyzji podjętych tygodnie temu: „Dlaczego w module billingowym używana jest kolejka Redis Streams zamiast bezpośredniego wywołania HTTP”. Agent sprawdza semantyczną pamięć repozytorium, zanim zaproponuje niebezpieczny refactoring.

03. Synchronizacja stanu między subagentami

W architekturach Multi-Agent (np. orkiestrator -> koder -> tester) wspólna pamięć stanu pozwala agentowi-testerowi natychmiast pobrać wszystkie hipotezy agenta-architekta bez pełnego przekazywania surowych logów.

5. Pułapki, typowe błędy i bezpieczeństwo

• Context Poisoning (Zatrucie pamięci): Jeśli agent zarejestruje halucynację jako wiarygodną wiedzę, będzie powtarzał ten błąd we wszystkich przyszłych sesjach. Zabezpieczenie: walidacja faktów przez oddzielny krok krytyki (Verification Step) oraz jawna możliwość usunięcia błędnych wspomnień przez UI/komendę.
• Retrieval Dilution (Rozmycie uwagi): Zbyt niski próg podobieństwa (similarity threshold) prowadzi do ładowania dziesiątek nietrafnych wspomnień, co wypiera aktualne instrukcje użytkownika.
• Secret Leakage (Wyciek sekretów): Przechowywanie w pamięci długoterminowej danych wrażliwych (klucze API, hasła z logów, tokeny). Zabezpieczenie: obowiązkowa warstwa sanitizacji (Secret Redaction Regex/detekcja entropii) na poziomie hooka pre-save pamięci.