Luka niezawodności: dlaczego twój najlepszy agent pęka pierwszy

Gdy wybierasz agenta, niemal na pewno wybierasz go z leaderboardu. Model na szczycie SWE-bench, ten z najwyższym wskaźnikiem przejść, ten, który wygrał benchmark — to ten, którego wdrażasz. To rozsądny instynkt i po cichu błędny. To, co mierzy leaderboard, i to, czego naprawdę potrzebujesz, to nie to samo, a luka między nimi to miejsce, w którym mieszka większość rozczarowań agentami.

Benchmarki mierzą zdolność: czy model potrafi odnieść sukces przy pojedynczej próbie? Produkcja wymaga niezawodności: czy odnosi sukces konsekwentnie, na przestrzeni powtarzanych prób, przy zadaniach, które działają długo? Brzmi to jak ta sama właściwość. Nie jest — a badanie z 2026 roku czyni tę lukę na tyle konkretną, by zmienić sposób, w jaki wybierasz.

Liczba, która powinna cię zaniepokoić

Praca to Beyond pass@1: A Reliability Science Framework for Long-Horizon LLM Agents (arXiv 2603.29231). Badacze przepuścili 10 modeli przez 23 392 epizody na benchmarku 396 zadań, celowo rozciągniętym na cztery koszyki czasu trwania i trzy domeny — od zadań krótkich po długie, w różnych rodzajach pracy. Chodziło o to, by zobaczyć, co dzieje się z agentem nie przy jego najlepszej pojedynczej próbie, lecz na przestrzeni wielu prób, gdy horyzont zadania się rozciąga.

Dwa odkrycia powinny cię zatrzymać. Pierwsze: rankingi zdolności i niezawodności rozjeżdżają się znacząco, z wielomiejscowymi inwersjami przy długich horyzontach. Model, który zajmuje pierwsze miejsce w zdolności przy pojedynczej próbie, może spaść o kilka pozycji, gdy zmierzysz konsekwencję przy długich zadaniach. Kolejność na leaderboardzie nie jest kolejnością wdrożeniową.

Drugie, i bardziej wbrew intuicji: modele frontierowe mają najwyższe wskaźniki meltdownu — do 19%. Nie najsłabsze modele. Najmocniejsze. Najzdolniejsi agenci najczęściej zawodzą katastrofalnie przy pracy o długim horyzoncie, a praca wprost mówi dlaczego: „próbują ambitnych strategii wieloetapowych, które czasem wymykają się spod kontroli”. To samo sięganie, które wygrywa benchmarki, wysadza długi przebieg.

Przeczytaj to jeszcze raz, bo odwraca logikę zakupu. Agent, który jest na szczycie twojego benchmarku zdolności, może być najmniej niezawodnym, jakiego mógłbyś wystawić na produkcję.

Zdolność to jedna próba; niezawodność to setna

Warto uściślić to rozróżnienie, bo to cała gra. Zdolność to pytanie o możliwość: czy ten agent w ogóle potrafi wykonać zadanie? Wynik pass@1 na nie odpowiada — daj modelowi jedną szansę, zobacz, czy trafi. To właśnie raportuje niemal każdy nagłówkowy benchmark i jest to naprawdę przydatne do jednej rzeczy: wiedzy, czy dana zdolność istnieje.

Niezawodność to pytanie o solidność: czy ten agent wykona zadanie za każdym razem, gdy poproszę, włącznie z długimi i niewygodnymi przypadkami? To rozkład, a nie punkt. To pass@1 przy próbie pierwszej i przy próbie pięćdziesiątej, przy zadaniu trzyetapowym i przy dziewięćdziesięcioetapowym, w dobry dzień i w gorszy. Produkcja działa na rozkładzie. Twoi użytkownicy nie doświadczają najlepszej próby twojego agenta; doświadczają jego typowej próby i pamiętają tę najgorszą.

Dlatego wysoki wynik benchmarku i frustrujące wdrożenie tak często współistnieją. Wynik jest prawdziwy — zdolność tam jest. Ale zmierzono ją na łatwym końcu osi czasu trwania, przy pojedynczej próbie, a potem wystawiłeś agenta do długiej, powtarzanej, zróżnicowanej pracy, gdzie rządzi inna właściwość. Kupiłeś zdolność, a potrzebowałeś niezawodności, i nikt ci nie powiedział, że to różne produkty.

Jest tu przydatna analogia ze sprzętu. Szczytowa benchmarkowa częstotliwość zegara układu mówi ci, co potrafi w zrywie przy idealnym chłodzeniu; jego podtrzymywany zegar pod obciążeniem termicznym mówi, co faktycznie dostaniesz przez cały dzień. Kupujący, którzy czytają tylko liczbę szczytową, są nieustannie zaskakiwani rzeczywistą przepustowością. Wyniki zdolności agentów to zegar szczytowy. Niezawodność to zegar podtrzymywany — a dla czegokolwiek, co uruchamiasz na produkcji, liczba podtrzymywana to jedyna, która płaci rachunki.

Dlaczego najmocniejszy model pęka

Mechanizm łączy się wprost z czymś, o czym pisaliśmy wcześniej. Argumentowaliśmy, że agenci stają się gorsi, im dłużej działają — że jakość eroduje tura po turze, gdy horyzont się rozciąga. Framework niezawodności dodaje ostre ostrze: im zdolniejszy model, tym bardziej dramatycznie potrafi zawieść dokładnie na tej osi, bo zdolność kupuje ambicję, a ambicja na długim horyzoncie to sposób, by wymknąć się spod kontroli.

Słabszy model próbuje skromnego planu i albo go kończy, albo zawodzi w małej skali. Model frontierowy próbuje rozległej, wieloetapowej strategii — zrefaktoryzuj to, uogólnij tamto, podepnij jeszcze coś innego — i gdy jeden wczesny krok pójdzie subtelnie źle, każdy późniejszy krok buduje na błędzie. Plan nie zawodzi łagodnie; pęka. Do 19% przypadków, przy długich zadaniach, najzdolniejsi agenci robią dokładnie to.

To horyzont jest miejscem, gdzie to się ujawnia. Spójrz, jak wyniki się załamują, gdy benchmark naprawdę rozciąga zadanie: na SWE-EVO (arXiv 2512.18470), benchmarku ewolucji oprogramowania o długim horyzoncie obejmującym 48 zadań, z których każde dotyka średnio 21 plików, z zestawami testów liczącymi średnio 874 testy, agenci lądują w okolicach 25% — wobec ~73%, które ta sama rodzina modeli notuje na jednoissue’owym SWE-bench Verified. Mniej więcej te same modele. Rozciągnij horyzont z „popraw jeden problem” do „rozwiń całą bazę kodu”, a większość pozornej zdolności wyparowuje. Liczba jednoissue’owa nigdy nie była obietnicą dotyczącą zadania o długim horyzoncie.

Nie naprawisz tego, czego nie mierzysz

Jeśli zdolność i niezawodność to różne właściwości, to pojedynczy wynik zdolności nie powie ci, któremu agentowi ufać — a produktywną odpowiedzią jest mierzenie niezawodności wprost. Framework niezawodności oferuje słownictwo warte przyjęcia choćby nieformalnie: Reliability Decay Curve (jak wskaźniki sukcesu spadają wraz ze wzrostem horyzontu zadania), Variance Amplification Factor (jak bardzo wydajność rozprasza się na przestrzeni powtarzanych prób), Graceful Degradation Score (czy zawodzi miękko, czy pęka) i Meltdown Onset Point (przy jakim horyzoncie spada z urwiska). Nie potrzebujesz dokładnej matematyki, by użyć tej idei. Musisz przestać pytać „czy to potrafi?” i zacząć pytać „jak to zawodzi, gdy zadanie robi się dłuższe, i jak często?”.

A gdy już mierzysz tryby porażki zamiast szczytowej zdolności, naprawą przestaje być „kup lepszy model”, a staje się „zaprojektuj pętlę”. Model z gorszym wynikiem zdolności, ale płaszczą krzywą rozpadu i łagodniejszym trybem porażki jest często lepszym wyborem na produkcję — a harness, który skaluje pracę na małe jednostki, często robi checkpointy i weryfikuje przed kontynuacją, zamienia model podatny na meltdown w godny zaufania. To ten sam argument, na którym wciąż lądujemy: harness jest produktem, a zła pętla wypuszcza zły kod szybciej. Niezawodności nie kupujesz z leaderboardu. To właściwość, którą budujesz, mierząc właściwą rzecz i kształtując wokół niej pętlę. Model dostarcza zdolności; pętla dostarcza niezawodności.

Praktyczny ruch: zanim wdrożysz, uruchom agenta na długich wersjach twojego prawdziwego zadania, wiele razy, i obserwuj rozkład — nie najlepszy przebieg, lecz rozrzut i najgorszy przypadek. Wybierz agenta, który degraduje się łagodnie, a nie tego, który ma najwyższy szczyt. Potem zaprojektuj harness tak, by horyzont był na tyle krótki, że punkt meltdownu nigdy nie zostanie osiągnięty.

Dlaczego sprzyja to Azji Południowo-Wschodniej

Oto część, która liczy się dla tego regionu, i ma ten sam kształt co każdy argument, który stawiamy. Inżynieria niezawodności nie jest zdolnością, którą się trenuje — to dyscyplina pomiaru i osądu. Nie kosztuje GPU. Nie potrzebuje frontierowego laboratorium. To niemal w całości praca polegająca na decydowaniu, co mierzyć, uruchamianiu agenta na długich i niewygodnych przypadkach, uczciwym odczytywaniu rozkładu i kształtowaniu pętli tak, by tryb porażki pozostał miękki. To inżynieria, która działa na laptopie.

I to prawdziwa przewaga, bo większość rynku robi coś odwrotnego. Domyślnym ruchem wszędzie jest chwycenie tego, co jest na szczycie leaderboardu zdolności, i wypuszczenie tego — co, jak pokazują badania, jest często agentem najbardziej skłonnym do meltdownu przy długich zadaniach, które naprawdę się liczą. Zespół w Phnom Penh albo Da Nang, który zamiast tego mierzy niezawodność, wybiera pod kątem łagodnej degradacji i inżynieruje pętlę utrzymującą krótki horyzont, wypuści godnych zaufania agentów, podczas gdy lepiej finansowani konkurenci gonią za liczbą benchmarku, która nie przeżywa kontaktu z produkcją. Ten sam instynkt pozwala pętlom działać bez nadzoru, gdy śpisz, bez zjeżdżania z torów — bo pętla została zbudowana na gorszy dzień, a nie na demo.

Leaderboard będzie dalej koronował najzdolniejszy model. Czego nigdy ci nie powie, to na którym modelu możesz polegać. Ta odpowiedź nie przychodzi z laboratorium — przychodzi z mierzenia niezawodności samemu, na własnych zadaniach, i inżynierowania pętli, aż odpowiedź brzmi „za każdym razem”. Ta praca to najbardziej niedoceniana robota w stosie agentowym, i jest dostępna dla każdego, kto zechce ją wykonać.