Degradacja pamięci agentów AI: dlaczego modele LLM załamują się w rozmowach wieloturowych

Po dziewięćdziesięciu minutach pracy nad moim systemem deliberacji⁹ agent przestał odwoływać się do architektury, którą omawiał pół godziny wcześniej. Z logów sesji wynikało, że Claude skompresował graf zależności między modułami, żeby zrobić miejsce na nowe wyniki narzędzi. Agent nadal pisał kod, tyle że ten kod nie odzwierciedlał już kontraktów międzymodułowych ustalonych w pierwszej godzinie. Testy przechodziły. Integracja padała. Agent zapomniał o własnym projekcie.

Ta awaria kosztowała mnie cały dzień debugowania. Badania wyjaśniają dziś, dlaczego do niej doszło.

W skrócie

Microsoft Research i Salesforce przebadały 15 modeli LLM w ponad 200 000 symulowanych rozmów i wykryły średni spadek skuteczności o 39% przy przejściu z jednej tury na wiele.¹ Degradacja zaczyna się już przy dwóch turach. Za załamaniem stoją trzy niezależne mechanizmy: kompresja kontekstu odrzuca krytyczny stan, spójność rozumowania rozpada się w miarę kurczenia się budżetu tokenów, a koordynacja między agentami załamuje się bez wspólnego punktu odniesienia. Dłuższe okna kontekstu nie naprawiają żadnego z nich. Wzorzec pętli Ralph (świeży kontekst w każdej iteracji, stan w systemie plików) omija straty wynikające z kompresji, ale wprowadza własne koszty. Poniżej: badania, trzy mechanizmy, metody wykrywania, które można uruchomić od razu, oraz protokół odporności na rozmowy wieloturowe.

Urwisko dziewięćdziesiątej minuty

W tekście o kontekście jako architekturze⁸ opisałem siedmiowarstwowy system kontekstu rozpięty na 650 plikach. Budowa tego systemu wymagała długich sesji kodowania, w których agent musiał utrzymywać złożony stan architektoniczny: granice modułów, łańcuchy zależności, kolejność wykonywania punktów zaczepienia i kontrakty rozpięte między plikami.

Zmierzyłem jakość sesji w 30 iteracjach pętli Ralph w styczniu i lutym 2026 roku.⁷ Dane pokazały powtarzalny wzorzec:

Minutes 0-30:   Precise multi-file edits, correct cross-references
Minutes 30-60:  Occasional missed imports, still recoverable
Minutes 60-90:  Single-file tunnel vision, loses architectural context
Minutes 90+:    Repetitive attempts, contradicts earlier decisions

Urwisko jakości pojawiało się niezależnie od rodzaju zadania. Długie refaktoryzacje, budowanie zestawów testów i przebiegi dokumentacyjne degradowały się według tej samej krzywej. Różniła się tylko dotkliwość: zadania wymagające stanu rozpiętego na wielu plikach spadały ostrzej niż odizolowana praca w pojedynczym pliku.

Przypisywałem ten wzorzec presji okna kontekstu i zbudowałem pętlę Ralph, żeby go obejść. Nowa instancja Claude w każdej iteracji, stan wstrzykiwany z systemu plików, zero polegania na pamięci rozmowy poza bieżącą iteracją. Wzorzec działa. Badanie MSR i Salesforce opublikowane w maju 2025 roku pokazało jednak, że problem jest bardziej strukturalny, niż wynikałoby to z samego rozmiaru okna kontekstu.

Trzy mechanizmy załamania w rozmowie wieloturowej

Laban i współautorzy rozłożyli degradację wieloturową na niezależne mechanizmy, a rozróżnienie ma znaczenie, bo każdy z nich wymaga strukturalnie innej interwencji.¹

Mechanizm 1: kompresja kontekstu

Każda rozmowa z AI toczy się w ramach skończonego budżetu tokenów. W miarę jej wydłużania system kompresuje wcześniejsze tury, żeby zrobić miejsce na nowe treści. Kompresja jest stratna. Decyzje architektoniczne udokumentowane w turze trzeciej mogą nie dotrwać do tury piętnastej.

Przyłapałem na tym agenta wprost przy budowie systemu deliberacji. W pierwszych 20 minutach ustalił graf zależności modułów: deliberation_engine.py zależy od consensus_calculator.py, który zależy od vote_aggregator.py. W 75. minucie łańcuch zależności był już skompresowany, a agent napisał cykl importów. Kod był poprawny składniowo. Cykliczny import wywołał awarię w czasie działania.

Wykrywanie: warto śledzić w czasie udział odwołań międzyplikowych w wyjściu agenta. Gdy agent przestaje odwoływać się do plików omawianych wcześniej, kompresja najprawdopodobniej usunęła odpowiedni kontekst.

# Count unique file references per 30-min window in a session log
# Declining count signals compression loss
git log --since="2 hours ago" --pretty=format:"%s" | \
  grep -oP '[a-z_]+\.(py|js|ts)' | sort -u | wc -l

Mechanizm 2: utrata spójności rozumowania

Badanie MSR i Salesforce wykazało, że degradacja wieloturowa rozkłada się na dwa składniki: niewielką utratę zdolności (aptitude) i znaczny wzrost zmienności wyników (reliability).¹ Zdolność mówi o tym, czy model w ogóle potrafi wygenerować poprawną odpowiedź. Zmienność — czy robi to konsekwentnie.

W trybie jednoturowym modele osiągały średnio około 90% skuteczności w sześciu zadaniach generacyjnych. W trybie wieloturowym wynik spadał do mniej więcej 65%, czyli o 25 punktów procentowych. Kluczowy wniosek: „Kiedy modele LLM skręcą w złą stronę w rozmowie wieloturowej, gubią się i już się nie podnoszą”.¹

Utrata spójności rozumowania objawia się tym, że agent zaprzecza własnym wcześniejszym decyzjom. Nie dlatego, że system skompresował kontekst (mechanizm 1), lecz dlatego, że łańcuch rozumowania modelu rozpadł się na granicach tur. Rozumowanie w każdej turze jest lokalnie poprawne, ale globalnie niespójne.

Wprost odnosi się do tego mechanizmu praca Du i współautorów o kognitywnym routingu decyzji.² Inspirowany teorią dwóch systemów Kahnemana (szybkie reakcje intuicyjne kontra wolne rozumowanie rozważne) system dobiera głębokość rozumowania do wymagań zadania. Sedno: nie każda tura agenta wymaga tej samej głębokości, a stosowanie jednej miary dla wszystkich marnuje budżet na krokach trywialnych i skąpi go przy decyzjach krytycznych.

Wykrywanie: warto szukać sprzeczności między wczesnym a późnym wyjściem sesji. Jeśli agent w 15. minucie broni podejścia A, a w 60. minucie podejścia B, nie odnotowując zmiany zdania, spójność już się rozpadła.

Mechanizm 3: awaria koordynacji

Systemy wieloagentowe nakładają na degradację wieloturową jeszcze awarię koordynacji. Gdy nad zadaniem pracuje dwóch lub więcej agentów, kontekst każdego z nich degraduje się osobno. Agent, który zapomniał o wspólnym ograniczeniu, nie potrafi się wokół niego koordynować.

Agent Context Protocols autorstwa Bhardwaja i współautorów rozwiązują to, ustanawiając ustrukturyzowane kanały komunikacji między agentami.³ Ich rozwiązanie osiągnęło 28,3% dokładności na AssistantBench dzięki jawnym protokołom współdzielenia kontekstu, propagacji błędów i synchronizacji stanu. Unified Agent Communication Protocol Krishnana idzie dalej i dokłada granice bezpieczeństwa w modelu zero-trust między agentami.⁴

Awarię koordynacji spotkałem podczas deliberacji dziesięciu agentów, w której trzech recenzentów oceniało tę samą zmianę w kodzie. Do czwartej rundy recenzji agenci rozjechali się co do tego, jak wygląda „bieżąca wersja” kodu. Każdy trzymał w kontekście inną migawkę. Ich recenzje przeczyły sobie nawzajem nie dlatego, że się nie zgadzali, lecz dlatego, że recenzowali różny kod.

Wykrywanie: w przepływach wieloagentowych warto porównać założenia o stanie, jakie przyjmuje każdy agent. Jeśli agenci odwołują się do różnych wersji tego samego artefaktu, koordynacja zawiodła.

Dlaczego dłuższe okna kontekstu tego nie naprawiają

Odruchowa odpowiedź na degradację wieloturową brzmi: „dać modelowi więcej tokenów”. Badanie MSR i Salesforce obala tę intuicję sprytnym układem eksperymentu.

Przetestowano w nim wariant „Concat”: cała rozmowa wieloturowa podana jako jedno sklejone zapytanie. Wariant Concat osiągnął 95,1% skuteczności trybu jednoturowego.¹ Długość kontekstu była identyczna jak w wariancie wieloturowym. Zawartość informacyjna również. Różniła się wyłącznie struktura interakcji: jedna tura kontra wiele tur.

39-procentowa degradacja nie jest problemem długości kontekstu. Podwojenie okna z 200 tys. do 400 tys. tokenów jej nie usunie, bo bierze się ona z samych granic tur, a nie z braku miejsca.

Wynik wariantu Concat zgadza się z moimi danymi produkcyjnymi. Claude pracuje na mniej więcej 200 000 tokenów kontekstu. Moje pomiary zarządzania oknem kontekstu pokazały, że najdłuższe pojedyncze sesje (ponad trzy godziny, intensywne użycie narzędzi) zużywają około 180 000 tokenów, zanim uruchomi się kompaktowanie. Jakość spada jednak na długo przed zapełnieniem okna. Urwisko dziewięćdziesiątej minuty wypada przy mniej więcej 60–70% wykorzystania kontekstu, a nie na jego granicy. Narastający dług poznawczy kumuluje się, bo agent produkuje kod szybciej, niż programista jest w stanie go zweryfikować. To ten sam problem kontekstu składanego w innej skali: każda tura dokłada informacje, które wchodzą w nieliniowe interakcje z tym, co było wcześniej.

Kognitywny routing decyzji Du i współautorów przestawia problem na inne tory: nie chodzi o to, ile tokenów model potrafi pomieścić, lecz jak sprawnie rozdziela zasoby rozumowania między te tokeny.² Ich system obniżył koszty obliczeniowe o 34% i poprawił spójność o 23%, kierując proste decyzje do szybkiego rozumowania, a złożone — do rozważnego.

Rozwiązanie: świeży kontekst (i jego koszty)

Pętla Ralph rozwiązuje mechanizm 1 (kompresję) i częściowo mechanizm 2 (spójność), bo nigdy nie prowadzi rozmowy dość długo, by którykolwiek zdążył się ujawnić. Każda iteracja uruchamia świeżą instancję Claude z pełnym kontekstem 200 tys. tokenów. Stan utrwala się w systemie plików, nie w pamięci rozmowy.

# Simplified Ralph loop iteration (from jiro-artisan.sh)
while [ "$stories_remaining" -gt 0 ]; do
  # Orient: inject current state from filesystem
  state=$(cat jiro.state.json)
  progress=$(cat jiro.progress.json)
  git_state=$(git diff --stat HEAD)

  # Spawn fresh context with injected state
  claude --print \
    "State: $state" \
    "Progress: $progress" \
    "Git: $git_state" \
    "Task: implement next story from prd.json"

  # Update filesystem state from agent output
  update_state_from_output
done

Każda iteracja dostaje pełny budżet kontekstu. Żadnych artefaktów kompresji z poprzednich tur. Żadnych okruchów po wcześniejszych łańcuchach rozumowania. System plików pełni funkcję pamięci zewnętrznej agenta: jiro.state.json śledzi bieżącą historyjkę, jiro.progress.json zapisuje pracę ukończoną w kolejnych iteracjach, a git diff dostarcza twardej prawdy o tym, co faktycznie się zmieniło.

Komplementarne podejście proponują Recursive Language Models autorstwa Zhanga, Kraski i Khattaba: zamiast uruchamiać świeże instancje, model przenosi kontekst do środowiska REPL w języku Python i rozumuje o nim w kodzie, a nie w przestrzeni tokenów.⁵ RLM-Qwen3-8B pobił swój punkt odniesienia o 28,3% w zadaniach długokontekstowych, traktując długie zapytania jak zewnętrzne struktury danych, a nie pamięć wewnętrzną. Tam, gdzie pętla Ralph wynosi stan do plików, RLM wynoszą go do kodu. Oba wzorce rozwiązują ten sam problem kompresji, tyle że innym mechanizmem.

System Wink autorstwa Nandy i współautorów zajmuje się tym, co dzieje się, gdy degradacja już trwa.⁶ Analiza ponad 10 000 rzeczywistych trajektorii agentów wykazała, że niepożądane zachowania (dryf względem specyfikacji, zapętlenia, nieudane wywołania narzędzi) występują w około 30% wszystkich sesji. Wink obserwuje trajektorię agenta i podaje ukierunkowaną korektę kursu, rozwiązując 90% przypadków wymagających pojedynczej interwencji. Wykrywanie działa w czasie rzeczywistym: Wink rozpoznaje wzorce degradacji w chwili ich powstawania, zamiast czekać, aż awaria rozejdzie się po całej bazie kodu.

Koszty

Iteracja na świeżym kontekście nie jest darmowa. Trzy koszty:

1. Narzut orientacji. Każda iteracja zużywa tokeny na ponowne wczytanie stanu, który poprzednia już rozumiała. Z moich pomiarów wynika, że na etap orientacji idzie 15–20% budżetu tokenów iteracji: odczyt plików stanu, przegląd świeżej historii gita, odbudowanie kontekstu na tyle, by móc kontynuować. Iteracja z oknem 200 tys. tokenów startuje więc z około 160–170 tys. tokenów użytecznej pojemności.

2. Utrata wiedzy niejawnej. Kontekst rozmowy niesie wiedzę niejawną, której stan zapisany w plikach nie uchwyci: uzasadnienie decyzji projektowej, rozważone i odrzucone alternatywy, niuans tego, dlaczego wybrano podejście A zamiast B. Etap orientacji wstrzykuje fakty (co się zmieniło, co dalej). Uzasadnienie — owo „dlaczego” — wyparowuje między iteracjami.

3. Koszt koordynacji. Jeśli równolegle biegnie kilka pętli Ralph (równoległa realizacja historyjek), każda utrzymuje własny, niezależny stan. Koordynacja między nimi wymaga jawnej logiki scalania i rozwiązywania konfliktów — czegoś, co pojedyncza długa sesja załatwia w sposób dorozumiany.

Bilans jest czytelny: przy sesjach krótszych niż 60 minut wydajniejsza jest jedna rozmowa. Powyżej 90 minut wzorzec świeżego kontekstu daje wyższą jakość mimo narzutu orientacji. Punkt przecięcia zależy od złożoności zadania: duży stan rozpięty na wielu plikach przesuwa go wcześniej, odizolowana praca w jednym pliku — później.

Jak zmierzyć degradację, zanim uderzy

Nie trzeba czekać na awarię na produkcji, żeby wykryć degradację wieloturową. Trzy metody, od najprostszej do najbardziej dogłębnej:

Metoda 1: monitorowanie presji kontekstu

Wykorzystanie kontekstu warto śledzić w czasie rzeczywistym. Mój punkt zaczepienia context-pressure.sh uruchamia się po każdym wywołaniu narzędzia i ostrzega, gdy wykorzystanie przekroczy 60%:

# Simplified context pressure check
context_used=$(wc -c < "$CONVERSATION_LOG" | awk '{print int($1/4)}')
context_max=200000
utilization=$(( context_used * 100 / context_max ))

if [ "$utilization" -gt 60 ]; then
  echo "[WARN] Context at ${utilization}% — quality degradation likely"
fi

if [ "$utilization" -gt 80 ]; then
  echo "[CRITICAL] Context at ${utilization}% — start new session"
fi

Metoda 2: śledzenie odwołań międzyplikowych

Warto obserwować, do ilu różnych plików agent odwołuje się w jednym wyjściu. Trend spadkowy sygnalizuje straty po kompresji:

# Track file reference diversity in recent commits
for commit in $(git log --oneline -5 --format="%H"); do
  files=$(git diff-tree --no-commit-id --name-only -r "$commit" | wc -l)
  echo "$commit: $files files touched"
done

Metoda 3: wykrywanie sprzeczności

Wystarczy porównać architektoniczne wypowiedzi agenta w czasie. Jeśli w 20. minucie twierdzi, że „moduł A zależy od modułu B”, a w 70. minucie, że „moduł A nie ma zewnętrznych zależności”, spójność się rozpadła. Wersja zautomatyzowana: porównać różnicowo wypowiedzi EXPLAIN agenta (lub komentarze projektowe) z wczesnych i późnych wyjść sesji.

Protokół odporności wieloturowej

Trzy poziomy, każdy wymierzony w inny mechanizm. Warto zacząć od poziomu 1 i dokładać kolejne warstwy w miarę potrzeb.

Poziom 1: punkty kontrolne stanu

Co 30 minut warto zserializować do pliku bieżące rozumienie architektury przez agenta. Nie całą rozmowę, tylko stan strukturalny: jakie moduły istnieją, jak się łączą, jakie obowiązują ograniczenia.

# Pre-compaction checkpoint (runs before Claude compresses context)
mkdir -p .claude/checkpoints
cat > ".claude/checkpoints/$(date +%s).md" << 'CHECKPOINT'
## Architectural State
- Module graph: [current understanding]
- Active constraints: [list]
- Design decisions made this session: [list with reasoning]
CHECKPOINT

Gdy zachowanie agenta zaczyna się psuć, lepiej odtworzyć stan z punktu kontrolnego, niż ciągnąć pracę na zdegradowanym kontekście.

Poziom 2: iteracje na świeżym kontekście

Przy sesjach dłuższych niż 60 minut warto przejść na wzorzec pętli Ralph. Klucz tkwi w etapie orientacji: wstrzyknąć tyle stanu, by nowy kontekst mógł produktywnie kontynuować pracę bez odczytywania całej historii rozmowy.

Stan wymagany na etapie orientacji: 1. Bieżące zadanie i kryteria akceptacji 2. Pliki zmodyfikowane w poprzedniej iteracji (z git diff) 3. Decyzje architektoniczne wraz z uzasadnieniem 4. Znane ograniczenia i tryby awarii

Poziom 3: protokoły koordynacji agentów

W przepływach wieloagentowych warto ustanowić wspólny dokument stanu, który wszyscy agenci czytają i zapisują. Pełni on rolę źródła prawdy i zapobiega rozjeżdżaniu się wersji, które obserwowałem podczas recenzji deliberacyjnych.

{
  "version": 7,
  "last_updated": "2026-02-22T14:30:00Z",
  "active_files": ["engine.py", "calculator.py", "aggregator.py"],
  "constraints": [
    "No circular imports between modules",
    "All public functions require type annotations"
  ],
  "decisions": [
    {"decision": "Use RRF for vote aggregation", "reasoning": "Handles rank-only data", "turn": 3}
  ]
}

Każdy agent czyta ten dokument na początku swojej tury i aktualizuje go na końcu. Konflikt uruchamia pauzę koordynacyjną zamiast cichego rozjazdu. Najlepsi agenci robią to niezauważalnie — jak pokazuję w tekście Niewidzialny agent, celem jest infrastruktura, która działa, a programista jej nie zauważa.

Najważniejsze wnioski

• Degradacja wieloturowa jest strukturalna, nie wynika z długości kontekstu. Badanie MSR i Salesforce pokazało 39-procentową degradację nawet przy stałej długości kontekstu. Załamanie napędzają granice tur, a nie limity tokenów.¹
• Trzy niezależne mechanizmy wymagają trzech różnych interwencji. Straty po kompresji — punktów kontrolnych stanu. Utrata spójności — iteracji na świeżym kontekście. Awaria koordynacji — protokołów wspólnego stanu.
• Urwisko dziewięćdziesiątej minuty jest realne i mierzalne. Śledzenie wykorzystania kontekstu, różnorodności odwołań międzyplikowych i sprzeczności architektonicznych pozwala wykryć degradację, zanim wyjdzie awariami na produkcji.
• Iteracja na świeżym kontekście działa, ale kosztuje 15–20% narzutu. Pętla Ralph wymienia narzut orientacji na pełny budżet kontekstu w każdej iteracji. Powyżej 60–90 minut ta wymiana się opłaca.
• Adaptacyjny przydział rozumowania bije jednolitą głębokość. Kognitywny routing decyzji Du i współautorów obniżył koszty o 34% i poprawił spójność o 23%, dopasowując głębokość rozumowania do wymagań zadania.²

FAQ

Źródła