Przepełnienie okna kontekstowego i kompresja

1. Przegląd koncepcji i problem systemowy

W długotrwałych projektach inżynierskich agent może pracować przez wiele godzin: czytać pliki, uruchamiać testy, pobierać logi, naprawiać błędy. Wcześnie czy później nawet okno o pojemności 200 000 tokenów zostaje wypełnione:

• Naiwne podejście: proste obcinanie (Truncate) pierwszych wiadomości. Jednak wraz z nimi znika pierwotna instrukcja użytkownika, a agent nagle „zapomina”, jaką dokładnie zadanie realizuje.
• Inne naiwne podejście: zatrzymanie pracy i zgłoszenie błędu, co zmusza użytkownika do ręcznego powtarzania wszystkiego od początku.

Context Window Compaction (Kompresja okna kontekstu) to technika ciągłego kompresowania historii dialogu w locie, która pozwala agentowi prowadzić nieskończone sesje robocze bez awarii wynikających z przepełnienia oraz bez utraty początkowych celów.

2. Taksonomia architektoniczna i model mentalny

┌─────────────────────────────────────────────────────────────┐
│                 CYKL KOMPRESJI KONTEKSTU                    │
├─────────────────────────────────────────────────────────────┤
│ 1. MONITOROWANIE BUFORA (Łączna liczba tokenów: 165k / Limit 200k) │
│    • Próg wyzwalania: 80% wypełnienia okna                  │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Uruchomienie procesu kompresji   │
├─────────────────────────────────────────────────────────────┤
│ 2. PARTYCJONOWANIE I ROLLING SUMMARIZATION (Podsumowywanie w trybie ciągłym) │
│    ┌─────────────────────────────────────────────────────┐  │
│    │ [PRZYPNIĘTE] Prompt systemowy i zasady główne (Niezmienne) │  │
│    ├─────────────────────────────────────────────────────┤  │
│    │ [PODZIELONE] Starsze tury 1–30 ➔ Skondensowane do stanu wykonawczego: │  │
│    │          „Autoryzacja skonfigurowana, baza danych zmigrowana” │  │
│    ├─────────────────────────────────────────────────────┤  │
│    │ [ZACHOWANE SUROWE] Świeże tury 31–40 (Dokładne szczegóły dla dewelopera) │  │
│    └─────────────────────────────────────────────────────┘  │
├─────────────────────────────────────────────────────────────┤
│ 3. PONOWNE ZŁOŻENIE KONTEKSTU: Nowy rozmiar = 45k tokenów (Wolna przestrzeń!) │
└─────────────────────────────────────────────────────────────┘

3. Praktyczne scenariusze inżynierskie na produkcji

01. Nieskończona sesja vibe-codingu w IDE opartym na agentach

Programista pracuje w Cursor lub Claude Code już szóstą godzinę z rzędu. System co każde 40 wiadomości niezauważalnie zwija stare logi terminala w schludny blok markdown <previous_session_summary>, utrzymując sesję szybką, tanią i responsywną.

02. Zachowanie artefaktów decyzji (Architectural Decision Records)

Podczas kompresji agent osobno zapisuje odrzucone hipotezy: „Próbowaliśmy użyć biblioteki X, ale jest ona niekompatybilna z Windows”. Gwarantuje to, że po 100 wiadomościach agent nie spróbuje ponownie zainstalować biblioteki X.

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

• Utrata subtelnych szczegółów (Information Loss): Model streszczający może uznać, że konkretny numer portu lub nazwa rzadkiego pola są nieistotne, i usunąć je ze podsumowania. Ważne parametry powinny być przechowywane w wydzielonych polach JSON State, a nie w swobodnym tekście.
• Dryf celu przy wielokrotnej kompresji: Jeśli sesja trwa tygodniami, a podsumowanie jest streszczane dziesiąty raz, pojawia się efekt głuchego telefonu. Pierwotne żądanie użytkownika (User Intent) musi zawsze pozostawać niezmienne w korzeniu promptu.

5. Strategiczny wniosek dla inżyniera roku 2026

Kompresja kontekstu to klucz do tworzenia autonomicznych systemów długodziałających (Long-Running Agents). Umiejętność projektowania algorytmów rotacji i podsumowywania pamięci pozwala tworzyć agentów zdolnych do pracy nad projektem przez tygodnie bez utraty skupienia.