Zarządzanie kontekstem agenta: budżety, przycinanie, kompaktowanie i wiedza, kiedy się zatrzymać
Kontekst 262K to nie licencja na wrzucanie do niego wszystkiego. Każdy token kontekstu kosztuje szybkość na każdym kroku. Jak budżetować kontekst agenta, przycinać wyjście narzędzi bez utraty sygnału, kompaktować historię bez psucia cache prefiksu, izolować pracę w subagentach i wykrywać pętle, zanim przepalą budżet.
Modele przyjmują dziś setki tysięcy tokenów kontekstu, a agenci szybko go zapełniają: definicje narzędzi, zawartość plików, wyjście poleceń, historia. Większość spowolnień i wiele błędów agentów, które widzę, to błędy kontekstu, a nie modelu. Poniżej to, jak nim zarządzam.
Każdy token kosztuje na każdym kroku
Za kontekst nie płaci się jednorazowo. Podczas dekodowania każdy nowy token czyta cały cache KV warstw atencji. Na mojej maszynie sufit przepustowości spada z około 59 przebiegów na sekundę przy krótkim kontekście do około 47 przy pełnym kontekście 262K (matematyka jest w notatce o dekodowaniu). Długie konteksty dodatkowo spowalniają prefill, powiększają cache KV i obniżają niezawodność przywoływania informacji: fakt sprzed 200K tokenów łatwiej przeoczyć niż fakt sprzed 2K.
Okno kontekstu to budżet, a nie worek.
Budżetuj go jawnie
Dzielę okno na stałe przydziały i egzekwuję je w harnessie:
| Część | Typowy udział | Uwagi |
|---|---|---|
| Prompt systemowy i schematy narzędzi | stały, kilka tysięcy tokenów | Stabilne, na początku, nigdy nieedytowane: to prefiks, którego cache używa ponownie |
| Pamięć robocza (plan, kluczowe fakty) | mały, ograniczony | Przepisywana celowo, a nie dopisywana w nieskończoność |
| Historia | większość okna | Tylko dopisywana między kompaktowaniami |
| Bieżące wyjście narzędzia | z limitem na wywołanie | Część, która najprędzej eksploduje |
| Rezerwa na odpowiedź | stały | Nigdy nie pozwól, żeby gigantyczne wyjście narzędzia zjadło miejsce na odpowiedź |
Schematy narzędzi zasługują na osobną uwagę. Pięćdziesiąt narzędzi po około 200 tokenów to 10K tokenów w każdym zapytaniu. Ładuj tylko narzędzia, których potrzebuje zadanie, albo zgrupuj rzadko używane za jednym wpisem „więcej narzędzi”.
Przycinaj wyjście narzędzi, ale zachowaj sygnał
Wyjście poleceń to klasyczny pogromca budżetu: przebieg testów, log, find po dużym repozytorium. Zasady przycinania, które działają:
- Zachowaj początek i koniec. Błędy są zwykle na końcu, a kontekst na początku.
- Napisz, co wycięto, na przykład
[... pominięto 4 812 linii ...], żeby model wiedział, że jest luka, i mógł poprosić o więcej. - Wybieraj węższe polecenia zamiast większych wyjść. Naucz agenta używać
grepi czytać zakresy linii zamiast całych plików. - Streszczaj ustrukturyzowane wyjście zgodnie z jego strukturą. Przy przebiegu testów podaj, ile testów przeszło, ile nie przeszło, oraz pełne komunikaty błędów.
Kompaktowanie bez psucia cache
W końcu historia musi się skurczyć. Naiwne podejście w każdej turze przepisuje ją na początku kontekstu, co unieważnia cache prefiksu i za każdym razem wymusza pełny ponowny prefill (dlaczego, wyjaśnia notatka o cache prefiksu).
Zamiast tego kompaktuj w rzadkich, przemyślanych krokach. Gdy historia przekroczy próg, zastąp najstarszy fragment streszczeniem decyzji, faktów i otwartych kwestii, zaakceptuj jedno chybienie cache i wróć do samego dopisywania. Dziesięć tur z ponownie używanym prefiksem wygrywa z dziesięcioma turami z prefiksem, który ciągle się zmienia.
Izoluj pracę w subagentach
Najczystsze kompaktowanie polega na tym, żeby w ogóle nie wpuszczać szumu do głównego kontekstu. Deleguj zamknięte zadanie, na przykład „znajdź, gdzie ładowana jest ta konfiguracja” albo „uruchom testy i zgłoś niepowodzenia”, do subagenta z własnym, świeżym kontekstem. Do głównego agenta wraca tylko jego krótki wynik. Tysiące tokenów zawartości plików z eksploracji nigdy nie trafiają do okna rodzica. amber obsługuje subagentów właśnie w tym celu, a mój benchmark ma scenariusz delegowania.
Wiedz, kiedy się zatrzymać
Pętle to też błędy kontekstu: agent ponownie czyta ten sam plik, ponownie uruchamia to samo polecenie i dopisuje to samo wyjście, aż budżet się skończy. Wykrywanie należy do harnessu:
- Wykrywanie identycznych wywołań. To samo narzędzie z tymi samymi argumentami dwa razy z rzędu to prawie zawsze pętla. Odrzuć takie wywołanie albo zwróć odnośnik do poprzedniego wyniku.
- Wykrywanie braku postępu. Kilka kroków bez nowych zmian w plikach, bez nowych informacji i z tym samym błędem powinno wymusić inny plan albo eskalację.
- Twarde limity. Maksimum kroków, tokenów i czasu zegarowego, z czystym przekazaniem sprawy człowiekowi, gdy zostaną osiągnięte.
amber-bench ma na to cały zestaw, loop-live, a rozrzut między modelami jest na nim duży. Qwen3.6-27B uzyskał 89,0, a wariant MoE 65,9 (cała dziesiątka jest w rankingu).
Zasady, których się trzymam
- Budżetuj kontekst osobno dla każdej części i egzekwuj budżety w kodzie, a nie w prompcie.
- Limituj i kształtuj każde wyjście narzędzia. Początek i koniec, jawny znacznik pominięcia i wąskie polecenia.
- Kompaktuj rzadko i na końcu prefiksu. Chroń stabilny prefiks, którego cache używa ponownie.
- Deleguj eksplorację do subagentów. Zwracaj wyniki, a nie transkrypcje.
- Wykrywaj pętle w harnessie. Nie licz na to, że model sam je zauważy.
Źródła: liczby dotyczące przepustowości pochodzą z notatki o dekodowaniu; wyniki dyscypliny pętli z mojego rankingu amber-bench. Reszta to praktyka z budowania amber i harnessów dla klientów.