O czym jest ten film
- Okno kontekstu to zasób, którego żaden agent się nie pozbędzie — umiejętność świadomego zarządzania nim to wciąż niedoceniana przewaga inżyniera.
- Claude Code i Codex pozwalają co najwyżej ustawić próg, przy którym odpala się automatyczna kompakcja; w agencie Pi można oddać tę decyzję samemu modelowi.
- Autor buduje agenta z dedykowanym narzędziem self-compact, którym agent zagęszcza własną historię i zostawia sobie notatkę.
- System ma trzy progi: delikatna sugestia, ostrzeżenie i wymuszona kompakcja — wszystkie widoczne na pasku kontekstu w interfejsie.
- Można w pełni przejąć kontrolę nad promptami kompakcji i nadpisać domyślne komunikaty narzędzia.
- Progi domyślne ustawiono pod cennik: w modelach GPT cena tokenów podwaja się po 270 tys. tokenów kontekstu, stąd ostrzeżenia przy 225 i 250 tys.
- Fundamentem pracy jest ręcznie pisanym plan w Markdownie, z sekcjami „definicja ukończenia” i „jak jesteś oceniany” — ta druga czerpie ze sposobu, w jaki modele są trenowane.
- Ten sam plan uruchomiono na trzech harnessach: Claude Code z Fable 5.1, Codex z GPT-6 Astra i agent Pi z GLM 5.2.
- GLM 5.2 przepełnił kontekst (98%) i nie ukończył zadania; Astra skończyła w 21 minut, Fable w 50 minut przy 500 tys. zużytych tokenów.
- Wniosek końcowy: panowanie nad „wielką czwórką” (kontekst, model, prompt, narzędzie) to panowanie nad agentem, a samokompakcja to warunek skalowania pracy „poza pętlą”.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Oddaj agentowi decyzję o momencie zagęszczenia kontekstu
Na czym polega: Standardowe narzędzia pozwalają ustawić tylko próg automatycznej kompakcji. Autor daje agentowi własne narzędzie (self-compact), którym model sam wybiera dogodny moment — np. po dokończeniu bieżącego kroku — i sam porządkuje własną historię rozmowy.
Jak stosować: Potrzebny własny lub mocno rozszerzalny harness (np. Pi Coding Agent). Narzędzie kompakcji ma być wywoływalne przez model jak każde inne, a progi i komunikaty sterujące podpięte przez flagi CLI oraz prompty.
Na co uważać: Nie każdy harness na to pozwala — w Claude Code nie podmienisz promptu kompakcji. Model bywa też ślepy na własne zużycie kontekstu, więc miękkie sugestie muszą iść w parze z twardym przymusem.
2.Trzy progi zamiast jednego sztywnego odcięcia
Na czym polega: System ma poziom delikatnej sugestii, ostrzeżenia i wymuszonej kompakcji. Po przekroczeniu twardej granicy harness blokuje agentowi wszystkie inne wywołania narzędzi.
Jak stosować: Rozstaw progi nierówno: duża przerwa między sugestią a ostrzeżeniem (agent ma czas domknąć pracę), krótka między ostrzeżeniem a przymusem. Nic nie stoi na przeszkodzie, by dodać więcej punktów pośrednich.
Na co uważać: Progi w procentach znają różne znaczenie przy różnych rozmiarach okna — bezpieczniej podawać wartości w tokenach (z sufiksami K/M), tak jak w CLI agenta Pi.
3.Nadpisz wbudowany prompt kompakcji
Na czym polega: Każde narzędzie agentowe ma domyślny komunikat uruchamiany przy zagęszczaniu. We własnym harnessie można go podmienić własnym — np. „nie odtwarzaj od nowa pracy, która już została wykonana”.
Jak stosować: Osobna sekcja planu: prompt dla miękkiej sugestii, osobny dla ostrzeżenia oraz nadpisanie właściwego komunikatu kompakcji (w agencie Pi służy do tego flaga —compact-prompt).
Na co uważać: Jakość takich promptów bywa różna — w teście Fable 5.1 wygenerował lepsze komunikaty niż GPT-6 Astra, więc wygenerowane prompty zawsze warto skontrolować.
4.Notatka do samego siebie — ciągłość między cyklami
Na czym polega: Przy zagęszczaniu agent dopisuje do podsumowania własną notatkę: cel, ustalenia, status, następny krok. Dociera ona do modelu jako dodatkowy prompt zaraz po kompakcji.
Jak stosować: Dodaj parametr „note to self” do narzędzia self-compact i wymuszaj go w prompcie kompakcji, żeby podsumowanie nie gubiło celu zadania.
Na co uważać: Notatka nie zastępuje porządnego promptu kompakcji — działa tylko w duecie z nim.
5.Progi ustawiaj pod cennik modelu, nie pod wygodę
Na czym polega: Według autora cena tokenów w modelach GPT podwaja się po przekroczeniu 270 tys. tokenów kontekstu. Domyślne progi (sugestia 225 tys., ostrzeżenie 250 tys., przymus 270 tys.) stoją dokładnie przed tym punktem.
Jak stosować: Zanim uruchomisz długiego agenta, sprawdź progi cenowe swojego modelu i ustaw wymuszoną kompakcję przed najdroższym progiem — agent zdąży wtedy dokończyć bieżący krok.
Na co uważać: Nie chodzi tylko o rachunek. Przepełnione okno to też degradacja jakości (tzw. context rot) — gorsze odpowiedzi za te same pieniądze.
6.Definicja ukończenia w każdym poważnym prompcie
Na czym polega: Sekcja, która mówi agentowi, kiedy praca jest skończona: plan gotowy, pliki we właściwych katalogach, workflow wykonany w całości. Bez niej agent nie wie, kiedy przestać.
Jak stosować: Pisz ją jako listę punktów do odhaczenia — może z powodzeniem zastąpić sekcję „deliverables”. Autor wkłada ją dziś do każdego promptu, który pisze.
Na co uważać: Producenci nie dostarczają „narzędzia stopu” (zarzut wobec OpenAI z wcześniejszego odcinka) — odpowiedzialność za zatrzymanie agenta spada wyłącznie na twój prompt.
7.Rubryka „jak jesteś oceniany” korzysta ze sposobu treningu modeli
Na czym polega: Modele w laboratoriach są trenowane pod ciągłą oceną. Jeśli agent dostanie rubrykę oceniania, po prostu się jej trzyma: ocena ciągła za każdy odhaczony punkt plus „natychmiastowa porażka” za złamanie reguł.
Jak stosować: Krótkie, jednoznaczne punkty: nie pisz efektów projektu poza katalogiem roboczym, nie czytaj planów i plików innych agentów, po błędzie natychmiast przerwij i zgłoś porażkę.
Na co uważać: Reguły muszą być sprawdzalne; przesadnie rozbudowana rubryka rozprasza model zamiast go prowadzić.
8.Równoległe agenty izoluj katalogami i regułami porażki
Na czym polega: Każdy agent pracuje we własnej podaplikacji (apps/
Jak stosować: Jeden plan plus zmienne plus justfile z aliasami — tak samo opisane zadanie odpalisz w wielu narzędziach i na wielu modelach bez przepisywania.
Na co uważać: Nie przesadzaj z restrykcjami: pliki tymczasowe i uruchamianie narzędzi w normalnych lokalizacjach muszą pozostać dozwolone, inaczej agent utknie.
9.Najpierw ręczny plan, potem prędkość agentów
Na czym polega: Poziom szczegółowości zakodowany w prompcie to poziom szczegółowości wyniku. Ręczne pisanie planu — choćby w notesie — to świadomy moment zwolnienia; potem przyspieszasz.
Jak stosować: Trzymaj szablon „draft” w edytorze: problem, rozwiązanie, workflow, definicja ukończenia, zasady oceniania. Dopiero z takim plikiem uruchamiaj agenty.
Na co uważać: Nie deleguj fazy myślenia modelowi. Kod napisze każdy — liczy się to, co budujesz, i detale, które znasz od podszewki.
10.Porównuj narzędzia pomiarami, nie sympatią
Na czym polega: To samo zadanie pobiegło trzema torami: GLM 5.2 przepełnił kontekst (98%) i nie skończył, Fable 5.1 domknął pracę w 50 minut przy 500 tys. tokenów, a GPT-6 Astra w 21 minut przy ułamku tej liczby.
Jak stosować: Mierz czas, zużycie tokenów i zajętość kontekstu. Trzymaj kilka narzędzi równolegle — myśl w „i”, nie w „lub”, bo zwycięskiej formuły dziś nie ma.
Na co uważać: Metryki mają znaczenie tylko przy ukończonym zadaniu — niedokończona praca nie wygrywa żadnym wynikiem. Modele otwarte bywają świetne, ale mają granice: GLM „bardzo dużo myślał” i zapchał okno samym rozmyślaniem.
Redakcyjne tłumaczenie
Okno kontekstu — problem, który nie znika
Cześć, inżynierowie! IndyDevDan na miejscu i kolejny odcinek z cyklu devlogów o kodowaniu z agentami. Dziś zmierzamy się z klasyką gatunku — problemem, który zna każdy agent.
To problem uporczywy: nie zniknie, niezależnie od tego, jak dobrym inżynierem agentów się staniesz. Dotyka każdego agenta, przed żadnym nie da się uciec, a każdy inżynier musi go rozumieć. Chodzi oczywiście o okno kontekstu.
Okno kontekstu to cenny zasób, na którym wykonuje się całą pracę z agentami. Towarzyszy nam od samego początku, a umiejętność świadomego nim zarządzania wciąż pozostaje wielką, niezagospodarowaną szansą.
Ruch myślowy: niech agent sam zdecyduje
Ale jeśli naprawdę chce się zostać inżynierem agentowym, trzeba ten sposób myślenia podnieść o poziom wyżej. Dzisiejsze modele są już na tyle inteligentne, że „widzą” własne okno kontekstu. Skoro tak — co się stanie, jeśli to agent zdecyduje, kiedy przyszedł czas na zagęszczenie?
(Informacja dodatkowa: kompakcja, czyli zagęszczanie kontekstu, to operacja, w której dotychczasowa historia rozmowy z agentem jest streszczana i zastępowana zwięzłym podsumowaniem, żeby zrobić miejsce na dalszą pracę.)
Większość narzędzi do kodowania z agentami — Claude Code, Codex — pozwala co najwyżej ustawić poziom zajętości kontekstu, przy którym odpala się automatyczna kompakcja. Przy inżynierii harnessów i agencie Pi możemy zrobić znacznie więcej.
(Informacja dodatkowa: Pi Coding Agent to otwartoźródłowy harness agentowy — czyli środowisko, w którym działa agent. W odróżnieniu od zamkniętych Claude Code i Codex można w nim zmienić praktycznie każdy element.)
Jeśli budujesz z agentami codziennie i uruchamiasz coraz dłużej pracujące instancje, każda dobrze przeprowadzona kompakcja będzie ci realnie zwracać pieniądze.
Potrzebuję tego rozwiązania dla moich agentów pracujących poza pętlą, bez człowieka przy klawiaturze, na coraz dłuższych zadaniach. Weźmy mój prosty system roju: odpalam w nim od dziesięciu do kilkuset agentów, które przez wiele godzin koordynują się wokół wspólnego celu. Taki rój nie obejdzie się bez samokompakcji — bez tej świadomości agent nie utrzyma tempa pracy. Łatwo sobie wyobrazić, ile to kosztuje, zwłaszcza gdy w grę wchodzi rój na modelu Fable albo Astra.
Dziś zbudujemy agenta Pi z samodzielną kompakcją: świadomego własnego kontekstu i wyposażonego w dedykowane narzędzie, którym sam decyduje, kiedy zagęszczać pamięć. Jeśli chcesz podnieść swoje umiejętności w inżynierii harnessów i promptów i zrozumieć, jak daleko sięga realna kontrola nad kontekstem — zostań z nami.
Bo automatyczna kompakcja istnieje od dawna, ale kwestionując domyślne ustawienia możemy zejść poziom głębiej. Kluczowe pytanie brzmi: czy agent potrafi wybrać lepszy moment na zagęszczenie niż sztywny próg?
Wszystko zaczyna się od ręcznie pisanego planu
Kiedy siadam do budowania, wszystko zaczyna się od roboczego planu. Bez agentów, bez fabryk software’owych, bez dyktowania do mikrofonu — tylko ja, moje myśli i klawiatura. Czasem sięgam po notes, co dla części inżynierów żyjących w tempie agentowym brzmi pewnie jak szaleństwo. Ale umiejętność skrystalizowania myśli w użyteczną informację, a potem przełożenia jej i przekazania agentom — to właśnie dziś sedno sprawy. Na tym polega przewaga każdego inżyniera agentowego: twoja wiedza ekspercka i umiejętność przełożenia jej na język, który agent potrafi wykorzystać.
W VS Code mam już przygotowane kilka rzeczy pod dzisiejsze zadanie: pusty katalog na specyfikacje, pusty katalog promptów, kompletną dokumentację agenta Pi i prosty skill Plan F3 — będę z niego korzystał.
Każda dobra robota zaczyna się od dobrego pisania. Otwieram więc nowy plik, draft-plan.md, i wklejam swój szablon „draft”. Ten szablon rozpoczyna moje prywatne pisanie — nie dla agentów, nie dla rojów. To ja, konkretnie przemyślający, czego właściwie szukam.
Modele potrafią robić niesamowite rzeczy i obowiązuje prosta zasada: poziom szczegółowości, jaki zdołasz zakodować w prompcie, to poziom szczegółowości, jaką dostaniesz od agenta. To jest dziś przewaga. Kod napisze każdy, software zbuduje każdy — liczy się to, CO budujesz. Detale, które znasz od podszewki i których nikt inny nie zna.
Wchodzimy więc we właściwy poziom szczegółu, żeby agent wiedział, czego od niego chcemy. A zrobię przy okazji coś zabawnego: gotowy plan przekażę trzem różnym harnessom z trzema różnymi modelami i zobaczymy, co z tego wyjdzie.
Pięć filarów rozwiązania
Tytuł: samokompakcja. Problem: długotrwałe, autonomiczne agenty wyczerpują kontekst. Przeciążone okno obniża jakość pracy przez degradację kontekstu i pali gotówkę.
Skoro rozumiemy problem, czas na rozwiązanie: zbudujemy samodzielnego agenta Pi z kilkoma kluczowymi funkcjami.
Pierwsza innowacja — agent dostaje własne narzędzie do tej pracy. Self-compact: pozwól agentowi zagęszczyć kontekst samodzielnie. W innych narzędziach tego się nie zrobi — wrócimy do tego za moment.
Trzy progi: poziom delikatnej sugestii, poziom ostrzeżenia i poziom wymuszonej kompakcji. Do tego interfejs, który te trzy poziomy zobrazuje.
Prompty kompakcji dla każdej interakcji — wszystkie wypisane wprost. Większość inżynierów nie wie, że można tu przejąć pełną kontrolę. Nie musisz używać wbudowanego promptu kompakcji, który daje Codex, Pi ani jakiekolwiek inne narzędzie — wszystkie go mają, ale władzę nad nim przejmujesz dopiero wtedy, gdy to ty kontrolujesz harness. Przygotujemy osobny prompt użytkownika dla miękkiej sugestii i osobny dla ostrzeżenia.
Bezpieczny fallback: komendy dla człowieka w pętli. Chcę widzieć ustawione progi i móc wymusić kompakcję ręcznie — to głównie na potrzeby testów. Patrzmy jednak szerzej: chodzi o długotrwałe, autonomiczne agenty działające poza pętlą, bez nadzoru. Trzeba to wyraźnie zaznaczyć w planie, bo dokładnie opisany problem komunikuje agentowi, który będzie to budował, co naprawdę rozwiązujemy.
To pięć filarów, przez które przejdziemy: samokompakcja, inżynieria promptów (przejmujemy kontrolę nad wszystkimi komunikatami), kontrola kontekstu, interfejs Pi i komendy dla człowieka w pętli. Z tego układu chcemy wyciągnąć kluczową wartość.
Workflow, definicja ukończenia i rubryka oceniania
Dopisuję zmienne, które będą towarzyszyć reszcie planu — sekcję notatek implementacyjnych na razie wycinam, może wróci. Kluczowa sprawa: katalog główny projektu. Chcę móc odpalać wiele agentów na tym samym planie, więc wprowadzam zmienne, które podmienimy przy uruchamianiu w wybranym narzędziu.
Teraz workflow: jak agent ma realnie wykonać tę robotę? Trzy proste kroki, standard dla większości inżynierów: zaplanuj, zbuduj, zweryfikuj. Agent ma przy tym skorzystać ze skilla Plan F3, który ma wbudowane kilka przepływów pracy. Na naszym poziomie operacyjnym nie schodzimy głębiej niż nazwy plików.
Dwie sekcje, które dziś wkładam do wszystkich promptów, są dla mnie najważniejsze: definicja ukończenia i zasady oceniania. Te drugie biorą się z pewnego genialnego w prostocie triku — zrozumienia, że modele podczas treningu w dużych laboratoriach AI są nieustannie oceniane. Jeśli dasz agentowi rubrykę, według której jest oceniany, będzie się jej trzymał. Bardzo mocna sekcja; koniecznie poeksperymentuj.
Definicja ukończenia to narzędzie prostsze: w ten sposób agent wie, kiedy przestać. Jak pokazywaliśmy w odcinku o rojach agentów — gdzie budowałem własny swarm i zwracałem uwagę, że OpenAI nie dostarczyło żadnego „narzędzia stopu”, naturalnego sposobu, by agent mógł się zatrzymać — ta kwestia będzie coraz ważniejsza. Właśnie tak wygląda dopasowanie agenta do naszych intencji realizowane samym promptem.
Czasem definicja ukończenia zastępuje mi sekcję „deliverables”, bo może je zawierać. Piszę ją wprost. Co ma być kompletne? Praca zaplanowana, harness we właściwej lokalizacji, cały workflow wykonany. O to chodzi w tej sekcji: moment, w którym praca jest domknięta.
Narzędziem przekazania jest self-compact — serce całości. Pozwala agentowi robić dwie rzeczy: autonomicznie zagęścić własny kontekst i zostawić sobie notatkę. To fajny dodatek, który chcę mieć w swojej kompakcji. Zwykła kompakcja to user prompt, który pod spodem odpala się, gdy kontekst jest mocno zapełniony albo gdy wyzwolisz ją sam. Notatka do siebie to warstwa wyżej: agent pisze wiadomość do samego siebie, a ta dołącza do podsumowania jako dodatkowy prompt.
Interfejs: pasek kontekstu pokazujący zajętość i progi. Na pierwszy rzut oka wygląda dziwnie, ale konstrukcja jest prosta — tokeny z cache i bez, wolny kontekst oraz trzy znaczniki: sugestia, ostrzeżenie i twarde odcięcie. Wpisuję go do definicji ukończenia: bez tego elementu w UI agenta Pi praca nie może zostać uznana za skończoną.
Właściwa inżynieria promptów — komunikaty, które realnie uruchamiają się przy kompakcji. Miękka sugestia self-compact z pełnym opisem, jakie pliki mają trafić w które miejsca. Flagi CLI ustawiające poziomy w tysiącach albo procentach (szczegóły progów opiszę sekcję niżej). Prompt ostrzeżenia — stanowczy komunikat: kompakcja wkrótce, po przekroczeniu twardego progu odcięcie. I ostatni: nadpisanie samej wiadomości kompakcji. Ten prompt podmienia domyślny komunikat agenta Pi. I to jest właśnie nasza inżynieria promptów: konkretna sekcja z detalami, które możemy modyfikować i nadpisywać.
Flagi przewiniemy szybko, bo powtarzają schemat — wszystkie cztery działają tak samo i przyjmują procenty albo sufiksy K (tysiące) i M (miliony). Limit 90% nam nie przeszkadza.
Progi dopasowane do cennika
Ustalamy domyślne wartości pod uruchomienie w rójach Astra, na GPT-6. Mało kto wie, że w modelach GPT cena w zasadzie podwaja się po przekroczeniu progu 270 tys. tokenów. Ustawiamy więc miękką sugestię na 225 tys., ostrzeżenie na 250 tys., a wymuszoną kompakcję na 270 tys. Agent dostaje przestrzeń, by dokończyć bieżącą robotę i domknąć to, co robi — twarda kompakcja odpala, zanim koszty zaczną się dublować.
To pomoże też przy weryfikacji. Opisuję warianty uruchomienia z pełniejszą składnią: katalog roboczy, domyślne progi, wsparcie procentów i sufiksów. Tak, się to dubluje i wchodzę może za bardzo w szczegóły — wolę jednak przesadną jasność niż zamęt. Dopisuję komendy z podstawionymi zmiennymi (compact-at, compact-buffer) oraz nadpisanie promptu kompakcji: „Nie odtwarzaj od nowa wykonanej pracy.” — dobre.
Komendy dla człowieka w pętli to temat mniej ekscytujący, przyznaję. Mamy self-compact info, self-compact now i zwykłe /compact — tego nie ruszamy.
To rdzeń definicji ukończenia. Coraz częściej po prostu wypisuję w niej wszystko, co ma być zrobione, jasno i po ludzku. Skupiamy się na stanie końcowym, nie na drodze do niego — a agenty radzą sobie z tym coraz lepiej. Mamy więc workflow jako wysokopoziomową rubrykę wykonania, dedykowany skill Plan F3, który przynosi nieproporcjonalnie duże zyski (chcę, żeby był użyty konsekwentnie), oraz zmienne. Do ich podmiany posłuży plik Just.
(Informacja dodatkowa: Just — lekki runner poleceń, popularna alternatywa dla make; plik justfile definiuje skróty uruchamiające złożone komendy.)
Najciekawsza jest jednak sekcja oceniania, bo sięga w to, jak te modele są trenowane. To zwykłe punkty, proste reguły: oceniany jesteś w sposób ciągły, za każdy odhaczony punkt definicji ukończenia i każdy krok workflow. Natychmiastowa porażka, jeśli zapiszesz efekty projektu poza katalogiem roboczym — z wyjątkiem katalogu planów, bo chcemy, żeby agent najpierw napisał plan, a potem go wykonał. Natychmiastowa porażka, jeśli przeczytasz jakikolwiek fragment plików w specs/, który nie jest twoim własnym planem. I to samo dla katalogu apps/: będę tam uruchamiał wielu agentów kodujących i każdy ma pracować we własnej podaplikacji. Wejście na teren innego agenta to natychmiastowa porażka. To trochę dodatkowej roboty, którą robię po to, by porównywać modele i narzędzia — dla ciebie całkowicie opcjonalne.
Dopisuję jeszcze parę punktów: uruchamianie narzędzi poza tymi katalogami jest dozwolone, pliki tymczasowe w normalnych lokalizacjach też — to nie jest porażka. Ale jeśli wywołasz błąd przez nieuwagę, natychmiast przerwij i zgłoś porażkę.
To nie jest zwykłe testowanie. Przechodzę z kodowania z agentem w pętli do kodowania poza pętlą i skaluję agentów na coraz dłuższe horyzonty — a skoro jeszcze jestem w pętli, chcę wiedzieć, którym agentom można realnie ufać przez rosnące odcinki czasu. W zeszłym tygodniu pokazywałem pięć moich benchmarków dla inżynierii agentów — wszystkie krążyły wokół jednej idei: pracy na długim horyzoncie, kiedy ciebie i mnie nie ma przy klawiaturze. Skoro jeszcze jesteś obecny, zbieraj z narzędzi i modeli jak najwięcej sygnału, żeby wiedzieć, komu ufać, gdy wyjdziesz. Dlatego coraz częściej mieszam to w swoją codzienną pracę.
Trzy harnessy, trzy modele — jeden plan
Mamy solidny kawałek pracy. Teraz tworzę plik Just, którym odpalę Codexa, Claude Code i agenta Pi — każdy z innym, znakomitym modelem. I to jest moment, w którym przestaję pisać ręcznie. Prompt jest gotowy, pomysły zakodowane w markdownie, poziom detalu na miejscu. Czas przyspieszyć do tempa agentów: zwalniamy wtedy, kiedy warto, przyspieszamy praktycznie wszędzie indziej.
Plik Just wygląda tak: cel dla Claude Code z Fable, dla Codexa z GPT-6 Astra i dla agenta Pi z GLM 5.2. Odpalamy wszystko równolegle. Stale testuję różne narzędzia — jeśli myślisz, że masz zwycięską formułę, gwarantuję ci, że nie masz. Ja też nie. W tej chwili nie ma zwycięskich narzędzi, może poza agentem Pi, bo jest konfigurowalny, rozszerzalny i należy do ciebie — to open source. Krajobraz kodowania z agentami nieustannie się przeobraża. Nie wybieram zwycięzców, wybieram wiele narzędzi. Myślę koniunkcjami, nie alternatywami — i tobie radzę to samo.
W pliku siedzą moje aliasy — CLDYF (Claude Code z Fable) i CDX (Codex). Odpalam terminal, dzielę na trzy okna i uruchamiam wszystko obok siebie. Każde z narzędzi ma dostarczyć działającą wersję naszego agenta z samokompakcją, a potem porównamy, który model poradził sobie najlepiej.
Claude Code, Codex, Pi — agenty ruszają do pracy. Widzimy modele: GLM 5.2, Astra i Fable 5.1. Agenty budują agentów i każdy przechodzi przez swój workflow: planuj, buduj, weryfikuj. Zobaczymy, jak sobie radzą. Dam im spokojnie popracować — to zadanie nietrywialne. Liczę na 20 minut do godziny. Przewijamy i do zobaczenia po drugiej stronie.
Wyniki wyścigu
Sprawdzamy wyniki. Wracam i patrzę, co agenty zrobiły. I — jakby o kontekście mówiąc — GLM 5.2 ma eksplozję kontekstu: 98% zajętości. Tego zadania nie wykona. Widzieliśmy to już w zeszłym tygodniu: ten model bardzo dużo myśli. Przewińmy odpowiedź w górę — większość jego aktywności to czyste rozmyślanie. Niektóre z tych mocarnych, otwartych modeli bywają świetne, ale mają swoje granice. Widać to tu wyraźnie.
Z drugiej strony mamy wyniki naprawdę ciekawe — dokładnie to, na co zwracaliśmy uwagę tydzień temu. Fable 5.1: 50 minut pracy. Codex na GPT-6 Astra ukończył w 21 minut — o połowę szybciej. A skoro połowa czasu, możesz być pewien, że zużył też ułamek tokenów.
Dwie roboty domknięte; GLM po prostu wyczerpał kontekst — i to jest najlepszy dowód, po co całe to rozwiązanie. Gdyby ten agent miał samokompakcję, dokończyłby zadanie. Agent Fable skończył z połową zajętego kontekstu — nietrywialna robota. Sprawdzam Astra: status pokazuje 136 tys. tokenów. A Fable działał na oknie miliona i zużył 500 tysięcy.
Gdyby jednak agenty poniosły klapę i nie dały wyniku, nic z powyższego by się nie liczyło. Trzeba się upewnić, że dostałem to, czego chciałem. Piszę więc do obu agentów tę samą notatkę — kopiuję, wklejam — mają zaktualizować plik Just. I można to po prostu obserwować: przebywanie w pętli i patrzenie, jak agenty robią swoje z prędkością światła, ma swój urok. Oto komenda run-cc i run-cdx — oba wskazują na nowe wersje. W katalogu specs mamy dokładnie to, o co prosiliśmy: specyfikacje dla trzech agentów. Najpierw planowały, potem budowały, wreszcie weryfikowały. Obok katalog apps/ — dla Fable, Astri i GLM.
Dopisuję jeszcze wpis dla GLM. Zwróćcie uwagę na wzorzec EFF obecny w każdym z agentów — to system prompt, który dziś włączam wszystkim, niezależnie od harnessu. Stale kontroluję „wielką czwórkę” w całym swoim kodowaniu z agentami, choć w narzędziach zamkniętych da się kontrolować tylko część.
Dowód na żywo: pasek kontekstu i samokompakcja w akcji
Mamy wszystkie trzy komendy. Zaczynamy od GLM: jak daleko zaszedł? Czy jest jakikolwiek konkretny rezultat? Odpalam nowy obszar roboczy, wpisuję „j”, widzę nową komendę. GLM startuje z niczym, piszę „ping”. Pasek kontekstu powinien być widoczny od razu — a go nie ma. Coś już jest nie tak; wycofuję się z tej wersji.
Następny: Claude Code. Nie mogę tu odpalić żadnego modelu, bo nie podstawiłem zmiennych środowiskowych. Szybki eksport i działamy na Gemini 3.5 Flash. Widać moje znaczniki: wykrzyknik ostrzeżenia i falka zwinięta w jedno miejsce. Kazę agentowi rozstawić pozycje progów szerzej, na potrzeby testu: sugestia 10%, ostrzeżenie 20%, twarde odcięcie 30%. Agent ma cały kontekst w oknie, więc szybko zrobi zwięzłą aktualizację progów. Przypomnę konstrukcję: punkt miękki, compact-at, a wymuszone odcięcie to compact-at plus compact-buffer — czyli 30%. Resetuję, odpalam i mamy wyraźnie rozstawione znaczniki.
Patrzcie: pasek kontekstu. Falka przy 10% — sugestia; wykrzyknik — ostrzeżenie; dalej pasek twardego odcięcia. Aktywnie ograniczamy okno kontekstu i pozwalamy agentowi zagęszczać je wtedy, kiedy potrzebuje.
Czas to udowodnić w praktyce. Wersja od Fable 5.1. Ustawiam model — weźmy DeepSeek V4 Flash przez OpenRouter, ten nowy, błyskawiczny 4.1. Zadanie: „znajdź największy plik”. Agent sprawdzi rozmiary plików i zacznie pochłaniać kontekst.
Widzimy procent: 1%. Za chwilę agent zacznie dostawać komunikaty o samokompakcji. Znalazł plan Astri — wygląda na największy. Czyta go kawałkami, dzieli plik, bierze największe, kroi po 40 KB i czyta dalej. Jesteśmy na 6% — a teraz to, co naprawdę ważne: tokeny myślenia, tokeny czytania… i proszę, komunikat. Zajętość kontekstu przekroczyła miękki próg. Agent przyjął wiadomość („mam okno miliona, miejsca dużo”) i działa dalej, ale ostrzeżenie już w nim siedzi. Za chwilę: próg ostrzeżenia przekroczony — „muszę zagęścić teraz”. I sam podejmuje decyzję: kompakcja. Pisze notatkę do siebie.
Rozszerzamy właśnie możliwości inżynierii agentowej. Notatka zapisana, przymus działa — linia samokompakcji przechodzi przez ekran i agent zagęszcza sam siebie. Poprzednie odczyty przepchnęły go za próg i mamy to: kompakcja działa. W podsumowaniu widnieje notatka do siebie — cel, ustalenia, status „gotowe”, następny krok — oraz komunikat kompakcji, ten, dla którego napisaliśmy dedykowany prompt. Agent działa dalej i doczytuje resztę pliku. Chcieliśmy udowodnić, że to działa — udowodnione.
Zerknijmy na wersję z Codexa. Widżet u góry, podmieniam zmienne środowiskowe. Progi są dokładnie tam, gdzie trzeba: sugestia przy 100 tys., ostrzeżenie przy 200 tys., wymuszona kompakcja przy 300 tys. Model? Niech będzie GLM 5.3 Flash. To znowu prosty test wyzwalający samokompakcję — agent ma zagęścić się sam. A żeby naprawdę spiąć te możliwości, chcemy szerokiego okna samokompakcji: duży odstęp między sugestią a ostrzeżeniem, krótszy między ostrzeżeniem a przymusem — bo po przekroczeniu twardego progu harness nie pozwoli agentowi wywołać niczego innego. I stąd bierze się spora część wartości: pozwól agentowi zdecydować, co chce zachować, a potem wymuś zagęszczenie.
Dla większości inżynierów to nic nowego; stosunkowo nowe jest to, że możesz sterować własnym harnessem i wyciągać z agenta takie rezultaty — dokładnie po swojemu. To, co dziś robią wszyscy w Claude Code i Codexie, to dopiero początek. Mamy prompt użytkownika z opcjonalną informacją o kontekście i komunikat kompakcji: co robić dalej — „możesz nadal korzystać ze wszystkich narzędzi; jeśli istnieje naturalny punkt zatrzymania, rozważ samokompakcję”.
Bardzo dobrze: agent kontynuuje i składa wyniki. Najważniejsze jest to, że nadpisujemy domyślny komunikat kompakcji. Każde narzędzie agentowe ma jakiś komunikat zagęszczający — my podmieniamy domyślny. Ten z Pi — tak; w Codexie chyba się da; w Claude Code — nie. Kolejny ukłon w stronę samodzielnego budowania własnego harnessu.
Oto miękka sugestia w wersji od Fable 5.1 i prompt ostrzeżenia. Czy coś już wyzwoliło progi? Nie, 12%. Zdetonujmy to ręcznie: wywołuję samokompakcję, odcinam przekazanie i używam go jako notatki do siebie. Chcemy tylko wiedzieć, że działa — to pojedyncze wywołanie narzędzia, którym agent w dowolnym momencie może zagęszczyć własną pamięć. To jest kluczowa idea. Widzimy notatkę do siebie wchodzącą do podsumowania i kontekst porządkowany.
Wersja Codex działa na GPT-6 Astra; w Pi mamy komplet promptów. Komunikat kompakcji od Astri… przyznać trzeba — słabszy niż ten od Fable. Miękka sugestia, potem ostrzeżenie. Z wyników wynika wprost: Fable jest lepszym inżynierem promptów niż Astra. Ciekawa obserwacja sama w sobie.
Zobaczmy całość zagęszczania: komunikat samokompakcji — prompt, który podaliśmy; potem właściwa kompakcja; na końcu samoprzekazanie — agent wręcza sobie wiadomość oprócz standardowego podsumowania. Kontekst sprowadzony w dół, agent gotowy do dalszej pracy. Widać „cykl 1” — gdyby było trzeba, moglibyśmy zliczać, ile zagęszczeń nastąpiło.
Co tu naprawdę robimy
Co tu właściwie robimy? Uczymy agenty zarządzać własnym oknem kontekstu: kiedy zagęszczać, co zachować, jak kontynuować. Robimy to przez inżynierię harnessu — a konkretnie przez własne prompty sterujące całym procesem od początku do końca.
Nie wiem, czy to już do ciebie dociera, więc powiem wprost: opanujesz wielką czwórkę — kontekst, model, prompt, narzędzie — a opanujesz agenta. Opanujesz agenta — a opanujesz pracę z wiedzą. Dołóż do tego ekspertyzę domenową i masz wszystko. Agent jest wszystkim. Umiejętność sterowania nim, zarządzania nim, budowania na nim, skalowania go i robienia tego tanio — technikami takimi jak ta — jest dziś bezcenna.
Trzeba myśleć szerzej niż siedzenie w terminalu i wymienianie się promptami. Sedno: przejście z pracy w pętli do pracy poza pętlą. Pracy w pętli nigdy nie zabraknie, ale naprawdę liczy się zdolność skalowania tego, co dzieje się poza pętlą — dryf w stronę bardziej autonomicznych systemów. Samokompakcja to jeden ze sposobów: przy długich zadaniach pozwala agentowi samemu wybierać moment zagęszczenia. Rozsuwam odstęp między miękką a twardą granicą, żeby agent realnie mógł wybrać czas. Chcesz więcej ostrzeżeń, więcej progów? Proszę bardzo — to twoja decyzja. Cała idea jest jedna: lepiej zarządzaj oknem kontekstu, żeby nie doprowadzać do eksplozji kosztów i nie degradować jakości.
Pakuję gotowego agenta z samokompakcją — zajrzyjcie sami. Wszystkie specyfikacje są na miejscu, a z planu agenty zbudowały całą aplikację. Klasyczny developerski cykl — planuj, buduj, weryfikuj — realizowany przez agentów jednym skillem.
Na koniec: narzędzia nie mogą zawężać wyobraźni
Zawsze to podkreślę: kiedy siadasz do pracy „ręcznie” — czyli faktycznie piszesz i faktycznie myślisz — poziom detalu, który wkładasz w robotę, jest tym, co cię dziś odróżnia. Kod napisze każdy, software zbuduje każdy, ale umiejętność poproszenia dokładnie o to, czego chcesz, to unikalna przewaga. Bo twoje agenty to wykonają, potężne roje zrobią to za ciebie, a ty wbudujesz to we własną fabrykę software’ową i stworzysz system, który konsekwentnie daje wyniki, jakich szukasz. Ale wszystko zaczyna się od wiedzy, czego chcesz.
Będziemy tu tydzień po tygodniu, pomysł po pomyśle, skalować moc obliczeniową, by skalować wpływ. Nie odpadnijcie po drodze — następny przeskok jest w zasięgu. Nadchodzi faza trzecia i bez odpowiedniej wiedzy trudno będzie za nią nadążyć. To nasz codzienny chleb: co potrafisz zrobić? Ile wartości umiesz stworzyć? Co zbudujesz — i jakie ograniczenia wymyślasz sobie sam? Narzędzia, których używasz, bezpośrednio zawężają to, co uznajesz za możliwe.
Nie myślę już o żadnym konkretnym narzędziu. Używam właściwych narzędzi, które pozwalają mi budować właściwą funkcję i poszerzać to, co mogę osiągnąć z agentami. Pi Coding Agent jest fantastyczny, bo przy nim nie widzę granic — a przy nim nie zobaczysz ich i ty. Chodzi o oprogramowanie konfigurowalne i sterowalne, które możesz zrobić swoim, dostosować i kontrolować do samego szpiku.
Zauważcie, że Claude Code powiela ten typ funkcji — wypuszcza własny system wtyczek do customizacji. Skąd, myślicie, to się wzięło? Z narzędzi takich jak Pi Coding Agent. Najlepsze pomysły są już na wolności. A najlepsze w ogóle jeszcze się nie wydarzyły — siedzą w twojej głowie i w głowach innych inżynierów. Cała sztuka polega na wbudowaniu ich w narzędzie, żeby wykonać pracę.
Linki w opisie. Wiecie, gdzie mnie znaleźć — w każdy poniedziałek. Trzymajcie fokus i budujcie dalej.