Gdy agenci stają się gorsi, im dłużej działają

Większość opowieści o porażkach agentów kodujących dotyczy pojedynczej złej odpowiedzi: agent źle odczytał zadanie, zhalucynował API, wypuścił błąd. Ale istnieje cichszy, droższy tryb porażki, który ujawnia się tylko wtedy, gdy pozwolisz agentowi pracować dalej. Nie zawodzi w pierwszej turze. Odnosi sukces — a potem znowu odnosi sukces, i jeszcze raz, i z każdą kolejną iteracją kod, który buduje, staje się odrobinę gorszy, aż to, co zaczęło się jako czyste rozwiązanie, staje się rozdętym, splątanym tworem, który technicznie przechodzi swoje testy i jest udręką w utrzymaniu. Agent staje się gorszy, im dłużej działa, i przez większość tego przebiegu nikt tego nie zauważa.

To nie jest przeczucie. W 2026 roku zbudowano zestaw benchmarków specjalnie po to, by zmierzyć zachowanie agentów o długim horyzoncie, i liczby są otrzeźwiające. Opowiadają spójną historię: agenci są znacznie słabsi w pracy ciągłej, iteracyjnej i w prawdziwej skali, niż sugerują benchmarki jednorazowe — a sporą część tej luki stanowi degradacja zadana przez nich samych.

Benchmark zbudowany, by zmierzyć rozpad

Najostrzejszym z nich jest SlopCodeBench (arXiv 2603.24755), a cały jego projekt celuje w powyższy problem. Zamiast zadań jednorazowych daje agentowi ewoluującą specyfikację i każe mu wielokrotnie rozszerzać własne wcześniejsze rozwiązanie — 36 problemów na 196 punktach kontrolnych — pozostawiając wewnętrzną strukturę kodu całkowicie agentowi. To ostatnie ma znaczenie: większość benchmarków iteracyjnych ogranicza przestrzeń projektową tak ściśle, że nie widać, jak wczesne decyzje agenta zatruwają jego późniejsze. SlopCodeBench celowo tego nie robi.

Główny wynik jest ponury. W gronie 15 agentów kodujących, otwartych i zamkniętych, żaden agent nie rozwiązał w pełni ani jednego problemu od początku do końca, a najlepszy przeszedł zaledwie 14,8% punktów kontrolnych. Ale ciekawsze są liczby o jakości w czasie. Benchmark śledzi dwa rodzaje rozpadu: erozję strukturalną (złożoność piętrząca się w niewłaściwych miejscach) i rozwlekłość (nadmiarowy, rozdęty kod). Erozja strukturalna rosła na przestrzeni punktów kontrolnych w 77% trajektorii; rozwlekłość rosła w 75,5%. W porównaniu z 473 prawdziwymi repozytoriami Pythona o otwartym kodzie, kod agentów był 2,3x bardziej rozwlekły i 2,0x bardziej zerodowany — a repozytoria ludzkie, mierzone na przestrzeni własnych historii git, degradowały się rzadziej i o mniejsze marginesy.

Innymi słowy: agenci przechodzą punkty kontrolne, produkując kod, który eroduje i puchnie z każdą turą. Zadanie zostaje wykonane. Baza kodu staje się gorsza. To właśnie slop, i on się kumuluje.

To nie tylko „slop” — sam długi horyzont jest trudny

SlopCodeBench można odczytać jako opowieść o jakości kodu. Dwa towarzyszące benchmarki pokazują, że to także opowieść o surowej zdolności: agenci po prostu rozpadają się przy prawdziwej skali inżynierskiej.

RoadmapBench (arXiv 2605.15846) osadza swoje zadania w prawdziwych aktualizacjach wersji oprogramowania o otwartym kodzie — 115 zadań o długim horyzoncie w 17 repozytoriach i 5 językach, z których każde wymaga mediany 3700 linii zmian w 51 plikach. Tak wygląda prawdziwa iteracja wersji, a nie poprawka błędu w jednym pliku. Przetestowane na trzynastu modelach frontierowych, najmocniejszy — Claude-Opus-4.7 — rozwiązał zaledwie 39,1% zadań, podczas gdy najsłabszy poradził sobie z 5,2%. Autorzy nie owijają w bawełnę, że jest to „w jaskrawym kontraście do istniejących benchmarków poprawiania błędów”, gdzie wyniki są znacznie wyższe: skróć horyzont, a agenci wyglądają świetnie; rozciągnij go do prawdziwej skali, a większość zdolności wyparowuje.

AgencyBench (arXiv 2601.11044) przesuwa horyzont jeszcze dalej — 32 scenariusze ze świata rzeczywistego, 138 zadań, z których każde wymaga średnio 90 wywołań narzędzi, 1 miliona tokenów i godzin wykonania, by je rozwiązać. Nawet najlepsza klasa modeli, zamknięte systemy frontierowe, osiągnęła jedynie 48,4% (wobec 32,1% dla otwartego kodu). Gdy pojedyncze zadanie zajmuje dziewięćdziesiąt wywołań narzędzi i milion tokenów, każda słabość w ciągłym rozumowaniu dostaje dziewięćdziesiąt szans, by się skumulować.

Zestaw te trzy razem, a wzorzec jest nie do pomylenia. Benchmarki, w których agenci błyszczą, są krótkie. W chwili, gdy horyzont robi się długi — wiele iteracji, wiele plików, wiele wywołań narzędzi — wydajność się załamuje, a znaczący kawałek tego załamania to agent degradujący po drodze własną pracę.

Dlaczego jakość spada w miarę piętrzenia się iteracji

Warto być precyzyjnym co do tego, dlaczego tak się dzieje, bo to inny mechanizm niż ten, który omówiliśmy w inżynierii kontekstu. Context rot dotyczy pamięci modelu degradującej się w miarę, jak okno wypełnia się szumem — to problem percepcji. Degradacja o długim horyzoncie jest tego pochodną, ale czymś odrębnym: dotyczy artefaktu degradującego się, gdy każda tura buduje na poprzedniej.

Oto kumulująca się pętla. Agent podejmuje wczesną decyzję strukturalną — odrobinę za szeroka funkcja, skrót, brakująca abstrakcja. Następny punkt kontrolny każe mu rozszerzyć ten kod. Zamiast refaktoryzować (co jest ryzykowne i czego nic w pętli nie nagradza), doczepia nową funkcję do istniejącego kształtu. Teraz fundament jest odrobinę bardziej zerodowany, a następne rozszerzenie powstaje na tym. Każda tura przechodzi swój punkt kontrolny, więc nie ma sygnału, że coś jest nie tak — ale struktura po cichu koncentruje złożoność i kumuluje nadmiarowość. Do dwudziestego punktu kontrolnego agent rozumuje nad bazą kodu, którą jego własne wcześniejsze tury uczyniły trudniejszą do rozumowania. Slop rodzi slop.

Dlatego łączy się to tak bezpośrednio z tezą, którą stawialiśmy wcześniej: zła pętla wypuszcza zły kod szybciej. Długi autonomiczny przebieg bez bramki jakości nie tylko ryzykuje jednym złym commitem — ryzykuje powolną erozją, niewidoczną, dopóki nie przeczytasz diffa. Benchmark przetestował nawet oczywistą naprawę: jawne wskazówki jakościowe w prompcie. Pomogło to punktowi startowemu — redukując początkową rozwlekłość i erozję nawet o jedną trzecią — ale nie zmieniło tempa degradacji. Powiedzenie agentowi „pisz czysty kod” czyni pierwszą turę czystszą. Nic nie robi z nachyleniem krzywej spadku.

Naprawą jest harness, nie prompt

Jeśli instrukcja jakościowa nie potrafi zatrzymać rozpadu, to co potrafi? Szczera odpowiedź z literatury o agentach działających długo jest strukturalna, nie werbalna — i to ta sama dyscyplina, do której wciąż wracamy: pętlę trzeba zaprojektować, a nie tylko zachęcić promptem.

Trzy ruchy wykonują najcięższą pracę. Skaluj każdą jednostkę pracy na małą. Krzywa degradacji jest funkcją tego, ile tur jedzie na tym samym erodującym fundamencie; jeśli rozłożysz funkcję na niezależne, dobrze obramowane podzadania, każde startuje z czystej linii bazowej strukturalnej, zamiast dziedziczyć dwadzieścia tur slopu. Resetuj kontekst na każde zadanie. Świeże okno dla każdej obramowanej jednostki odmawia gniciu miejsca do kumulowania się — trwały stan żyje w artefaktach, nie w wciąż rosnącym transkrypcie. I rób checkpointy z prawdziwymi punktami odzysku. Zatwierdzaj działający stan do git po każdej zweryfikowanej jednostce, by zdegradowaną gałąź można było porzucić, a nie rozszerzać. To dokładnie ta dwuczęściowa architektura, jedna funkcja naraz, którą opisaliśmy w harness jest produktem: inicjalizator, który przygotowuje trwały stan, a potem agent kodujący, który wybiera jedną funkcję, weryfikuje ją end-to-end, zatwierdza i przekazuje czyste artefakty następnej sesji.

Idea spinająca: degradacja jest właściwością kształtu pętli, a nie IQ modelu. Model frontierowy w niechlujnej pętli o długim horyzoncie zerodzi własną pracę. Skromny model w pętli, która ciasno obramowuje, twardo weryfikuje i często resetuje, utrzyma jakość znacznie dłużej. Benchmarki mierzą agentów w długich, nieprzerwanych przebiegach właśnie dlatego, że to najtrudniejszy przypadek — i to przypadek, w który dobry harness jest zaprojektowany, by nigdy nie wejść.

Dlaczego sprzyja to Azji Południowo-Wschodniej

Oto część, która liczy się dla tego regionu, i jest to ten sam argument wyostrzony. Naprawą degradacji o długim horyzoncie nie jest większy model ani więcej GPU — to osąd co do dekompozycji, weryfikacji i tego, kiedy zresetować. To inżynieria systemów, i działa na laptopie.

Zespół, który to przyswoi, ma prawdziwą przewagę. Odruch, za którym podąża wszyscy inni — wskaż agentowi frontierowemu wielkie zadanie i pozwól mu działać godzinami — to dokładnie ten reżim, w którym te benchmarki pokazują najgorszy rozpad i najwyższe rachunki za tokeny. Zespół w Phnom Penh albo Da Nang, który zamiast tego rozkłada pracę na małe zweryfikowane jednostki, dostaje lepszy wynik za mniej tokenów, co — jak argumentowaliśmy w ekonomii agentic AI — jest dźwignią, która naprawdę się kumuluje. Dziewięćdziesiąt wywołań narzędzi i milion tokenów na zadanie to ogromna powierzchnia kosztów; dyscyplina, która kurczy horyzont, kurczy rachunek w tym samym czasie, gdy podnosi jakość.

I jest trwała. Wiedza o tym, jak nie pozwolić długiemu przebiegowi zgnić — gdzie przeciąć zadanie, jaką bramkę wstawić, kiedy wyrzucić gałąź i zacząć od nowa — to ciężko wypracowany osąd inżynierski, którego żadne wydanie modelu nie czyni przestarzałym. Frontierowe laboratorium będzie dalej wypuszczać agentów, którzy potrafią działać dłużej. Czego nie potrafi wypuścić, to dyscyplina, by uruchamiać ich dobrze. Ta dyscyplina jest najbardziej niedocenianą umiejętnością niezawodnościową w stosie agentowym, i jest dostępna dla każdego, kto zechce zaprojektować pętlę, zamiast ufać przebiegowi.