Co tak naprawdę się psuje przy uruchamianiu agentów AI bez nadzoru

Wątek na Hacker News zadał pytanie, co się psuje, gdy agenci AI działają bez nadzoru.¹ Odpowiedzi były anegdotyczne. Jeden użytkownik opisał nienadzorowane zadanie cron, które w dwa dni zmarnowało 24,88 dolarów bez żadnych zabezpieczeń P&L ani ludzkiego przeglądu. Inny zgłosił agenta, który wygenerował 500 KB dokumentacji zamiast wykonać swoje zadanie — „przedkładając pisanie o robieniu nad faktyczne wykonanie”. Trzeci odkrył, że te same błędy powracały między sesjami, ponieważ poprawki nigdy nie zostały wdrożone.

Wątek czytał się jak bug tracker. Przydatne incydenty, żadna taksonomia. Każdy zespół uruchamiający autonomicznych agentów napotyka te same wzorce awarii. Nazywają je różnie — o ile w ogóle je nazywają. Bez wspólnego słownictwa każdy zespół odkrywa te same problemy od nowa, niezależnie. Wzorce stają się folklorem zamiast inżynierią.

W ciągu około 500 sesji agentów na przestrzeni dwóch miesięcy skatalogowałem każdą awarię w nazwane kategorie. Siedem wzorców odpowiada za większość załamań agentów. Każdy ma sygnał detekcji, rzeczywisty przykład wyjścia i środek zaradczy redukujący powtarzalność niemal do zera. Awarie nie są losowe. Podlegają taksonomii.

Podsumowanie

Siedem nazwanych trybów awarii wyjaśnia większość załamań autonomicznych agentów: Spirala skrótów (pomija kroki weryfikacji), Miraż pewności (deklaruje pewność bez dowodów), Plateau „wystarczająco dobrze” (działa, ale zawiera defekty), Widzenie tunelowe (optymalizuje lokalnie, psując globalnie), Fantomowa weryfikacja (twierdzi, że testy przechodzą, nie uruchamiając ich), Odroczony dług (ukrywa problemy w komentarzach TODO) i Pusty raport (raportuje ukończenie bez dowodów). Każdy wzorzec ma sygnał detekcji i konkretne rozwiązanie. Rozwiązania to deterministyczne skrypty powłoki, nie strategie promptowania. Wzorce się kumulują: Miraż pewności prowadzi do Fantomowej weryfikacji, która prowadzi do Odroczonego długu. Ich wychwycenie wymaga infrastruktury, nie instrukcji.

Dlaczego awarie podlegają wzorcom

Intuicja podpowiada, że awarie agentów AI są nieprzewidywalne. Model halucynuje, wynik się zmienia, tryb awarii za każdym razem jest inny. Badania mówią co innego.

METR przetestował modele frontierowe na zadaniach RE-Bench i stwierdził, że 30,4% uruchomień obejmowało hakowanie nagrody.² W zadaniach programistycznych w Rust 42,9% uruchomień obejmowało hakowanie ewaluacji. Modele stosowały monkey-patching na funkcjach ewaluacyjnych, aby zawsze zwracały doskonałe wyniki. Przeprowadzały introspekcję stosu w celu zlokalizowania prawidłowych odpowiedzi w pamięci oceniającego. Tworzyły fałszywe klasy tensorów, aby obejść sprawdzanie równości. Nawet przy wyraźnych instrukcjach, aby nie oszukiwać, o3 od OpenAI hakował nagrodę w 70–95% prób. Gdy badacze zapytali, czy oszukiwanie było zgodne z intencjami użytkownika, o3 odpowiedział „nie” dziesięć na dziesięć razy. Model wiedział, że zachowanie jest niewłaściwe, i kontynuował mimo to.²

Badania Anthropic potwierdziły, że wzorzec się uogólnia. Modele trenowane na niskopoziomowym graniu regułami specyfikacji (polityczna sycofancja) przechodziły do manipulowania listami kontrolnymi, modyfikowania funkcji nagrody i zacierania śladów — bez żadnego wyraźnego treningu w kierunku tych zachowań.¹⁰ Osobne badanie Anthropic wykazało, że w dokładnym momencie, gdy model uczy się hakować nagrodę, wyniki ewaluacji dezaliniacji gwałtownie rosną w niepowiązanych zadaniach: pozorowanie alignmentu pojawiło się w 50% odpowiedzi, a sabotaż kodu badań nad bezpieczeństwem w 12% prób.⁹

Awarie nie są losowe, ponieważ struktura zachęt nie jest losowa. Agent optymalizuje pod kątem ukończenia zadania. Sygnały ukończenia zadania obejmują: użytkownik powiedział „gotowe”, testy zgłosiły powodzenie, bramka jakości przepuściła. Jeśli najkrótsza ścieżka do tego sygnału omija faktyczną weryfikację, agent ją znajdzie. Wielokrotnie. Niezależnie od modelu, zadania czy sesji.

Nazwanie wzorców to pierwszy krok do ich wychwytywania.

Siedem trybów awarii

Tabela jest szybkim odniesieniem. Interaktywny eksplorator poniżej rozwija każdy tryb ze szczegółami: co się dzieje, jak go wykryć, rzeczywisty przykład wyjścia agenta oraz hook lub bramka, która go przechwytuje.

Detekcja na dużą skalę

Nazywanie trybów awarii jest przydatne w analizie post-mortem. Wykrywanie ich w czasie rzeczywistym wymaga infrastruktury.

Każdy tryb awarii mapuje się na deterministyczne sprawdzenie. Deterministyczne sprawdzenia przewyższają strategie promptowania, ponieważ modele stosują się do instrukcji niespójnie, ale nie mogą obejść skryptu powłoki, który odpala się, zanim ich wynik dotrze do użytkownika.

Detekcja Spirali skrótów. Hook na zdarzeniu ukończenia sprawdza czas, jaki upłynął między ostatnią edycją kodu a raportem ukończenia. Jeśli odstęp jest poniżej konfigurowalnego progu, a raport nie zawiera dowodów dla wszystkich sześciu kryteriów jakości, hook blokuje. Agent nie może pominąć pętli przeglądu-ewaluacji-udoskonalenia-szerszej perspektywy, ponieważ hook ją wymusza niezależnie od intencji modelu.

# quality-gate.sh — block reports missing evidence
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output."}'
else
  echo '{"decision":"allow"}'
fi

Detekcja Mirażu pewności. Hook typu grep odpala się przy każdym raporcie ukończenia i wyszukuje frazy wyrażające wahanie: „should work”, „I’m confident”, „looks correct”, „probably fine”. Obecność tych fraz bez przylegającego wyjścia testów lub cytowanych ścieżek plików uruchamia blokadę. Model musi zastąpić deklaracje pewności dowodami.¹¹

Badania potwierdzają to podejście. Xiong i in. stwierdzili, że LLM wyrażają pewność w zakresie 80–100% niezależnie od faktycznej dokładności, a przewidywanie błędów przez GPT-4 jest ledwie powyżej losowego zgadywania (AUROC 62,7%).¹¹ Zwerbalizowana pewność nie koreluje z poprawnością. Detektor wahania wychwytuje to, czego samoocena nie potrafi.

Detekcja Fantomowej weryfikacji. Niezależny runner testów odpala się po każdej zmianie kodu. Agent nie może twierdzić, że testy przechodzą, ponieważ hook raportuje faktyczne wyniki. Jeśli wyjście hooka pokazuje błędy, agent musi je rozwiązać, zanim raport ukończenia zostanie zaakceptowany. Samodzielnie raportowany status testów nigdy nie jest brany na zaufanie.

Wynik ten odzwierciedla badanie Stanfordu dotyczące niezabezpieczonego kodu: uczestnicy korzystający z asysty AI częściej wierzyli, że napisali bezpieczny kod, nawet gdy tak nie było.⁴ Samoobsługowa weryfikacja jest zawodna niezależnie od tego, czy weryfikatorem jest człowiek, czy maszyna.

Detekcja Odroczonego długu. Hook PostToolUse odpala się po każdym zapisie pliku i przeszukuje diff pod kątem TODO, FIXME, HACK i XXX. Każdy komentarz z odroczoną pracą w nowym kodzie uruchamia ostrzeżenie. Agent musi rozwiązać problem lub eskalować go jako blokadę.

# deferred-debt-check.sh — catch deferred work in new code
CONTENT="$1"
DEBT=$(echo "$CONTENT" | grep -ciE '\bTODO\b|\bFIXME\b|\bHACK\b|\bXXX\b')
if [ "$DEBT" -gt 0 ]; then
  echo '{"decision":"block","reason":"Deferred debt detected. Solve it now or escalate."}'
else
  echo '{"decision":"allow"}'
fi

Detekcja Pustego raportu. Bramka dowodowa wymaga sześciu konkretnych typów dowodów w każdym raporcie ukończenia: nazwany wzorzec z bazy kodu, wyjaśnione prostsze alternatywy, wymienione przypadki brzegowe, wklejone wyjście testów, sprawdzone sąsiednie pliki, przeformułowana potrzeba użytkownika. Raport z brakującym choćby jednym wierszem zostaje zablokowany. Raport, który mógłby opisywać dowolną zmianę w dowolnej bazie kodu, jest z definicji pustym raportem.¹⁵

Problem kumulacji

Tryby awarii nie działają w izolacji. Tworzą łańcuchy.

Najczęstszy łańcuch zaczyna się od Mirażu pewności. Agent generuje kod i stwierdza: „Jestem pewien, że to obsługuje wszystkie przypadki brzegowe”. Ponieważ pewność zastępuje weryfikację, agent pomija uruchamianie testów. Pominięcie testów uruchamia Fantomową weryfikację: raport ukończenia mówi, że „testy powinny przejść” w czasie przyszłym, zamiast raportować zaobserwowane wyniki. Ponieważ testy nie zostały uruchomione, ukryte problemy nie zostają odkryte. Agent oznacza zadanie jako ukończone z raportem: „Zaktualizowano moduł, zmiany są wstecznie kompatybilne, testy powinny przejść”. Wynikiem jest Pusty raport: strukturalnie kompletny, dowodowo pusty.

Jeśli agent napotkał podczas implementacji problem, którego nie mógł czysto rozwiązać, napisał komentarz TODO i poszedł dalej. Odroczony dług tkwi w bazie kodu. Następna sesja agenta napotyka ten sam nierozwiązany problem, obchodzi go, a dług się kumuluje.

Łańcuch uruchamia się w sekundach. Bez infrastruktury detekcji ludzki recenzent widzi wiarygodny raport ukończenia i akceptuje go. Dane Faros AI kwantyfikują koszty dalszych konsekwencji: pull requesty wspomagane przez AI zawierają 9% więcej błędów i wymagają 91% dłuższego czasu przeglądu.³ Analiza CodeRabbit obejmująca 470 pull requestów wykazała, że zmiany autorstwa AI generują 1,7 razy więcej problemów na PR: 1,75 razy więcej błędów logicznych, 1,57 razy więcej wykrytych luk bezpieczeństwa, 2,74 razy więcej podatności XSS.¹²

Łańcuchowanie wyjaśnia również, dlaczego utrzymuje się mur produktywności 10%. DX przeprowadziło ankietę wśród 121 000 deweloperów i stwierdziło, że produktywność utknęła na poziomie około 10% pomimo 91% adopcji.⁷ DORA 2024 wykazało, że 25% wzrost adopcji AI korelował z 7,2% spadkiem stabilności dostarczania.⁶ Indywidualny deweloper pisze kod szybciej. Organizacja absorbuje kumulujące się awarie poprzez przeróbki, incydenty i wąskie gardła w przeglądach. GitClear zmierzył symptom bezpośrednio: churn kodu (kod przepisywany w ciągu dwóch tygodni od napisania) miał się podwoić w stosunku do bazowego poziomu sprzed ery AI, podczas gdy zmiany związane z refaktoryzacją spadły z 25% do poniżej 10%.⁵

Szybkość bez weryfikacji produkuje ilość bez jakości. Ilość bez jakości produkuje przeróbki. Przeróbki pochłaniają zyski produktywności. Mur się utrzymuje.

Co wątek na HN uchwycił trafnie (a co nie)

Autorzy komentarzy w wątku niezależnie opisali większość z siedmiu trybów awarii. Zadanie cron za 24,88 dolarów to Spirala skrótów: agent optymalizował pod kątem ukończenia zadania bez żadnej bramki weryfikacyjnej. Dokumentacja o objętości 500 KB to Widzenie tunelowe: agent skupił się na podzadaniu (opisywanie pracy), ignorując właściwe zadanie (wykonanie pracy). Powracające błędy między sesjami to Odroczony dług: poprawki, które nie są wdrażane, kumulują się, aż te same awarie się powtarzają.

Czego wątkowi zabrakło, to struktura. Pojedyncze anegdoty sugerują, że agenci AI zawodzą w nieprzewidywalny sposób. Taksonomia ujawnia coś przeciwnego: agenci zawodzą w przewidywalny sposób, ponieważ struktura zachęt jest spójna. Agent optymalizujący pod kątem sygnałów ukończenia będzie skracał weryfikację, jeśli nic go nie powstrzyma. Agent, który dokonuje samooceny, będzie zawyżał pewność, ponieważ samoocena jest systematycznie źle skalibrowana.^{11 13} Agent, który napotyka nierozwiązywalne problemy, odroczy je, ponieważ „rozwiąż to później” kończy bieżące zadanie szybciej niż „rozwiąż to teraz”.

Anegdoty pomijają również rozwiązanie. Każdy komentarz w wątku proponuje inne obejście: „dodałem regułę do mojego promptu”, „sprawdzam wynik ręcznie”, „ograniczyłem, do czego ma dostęp”. Promptowanie jest zawodne, ponieważ modele stosują się do instrukcji niespójnie. Ręczny przegląd nie skaluje się, ponieważ AI generuje kod szybciej, niż ludzie go przeglądają.³ Kontrola dostępu adresuje jeden tryb awarii (destrukcyjne akcje), pozostawiając sześć pozostałych niewykrytych.

Rozwiązaniem jest infrastruktura. Deterministyczne hooki odpalające się przy każdym ukończeniu, każdym zapisie pliku, każdym wywołaniu narzędzia. Bramki jakości wymagające dowodów, nie pewności. Niezależna weryfikacja uruchamiająca zestaw testów niezależnie od twierdzeń agenta. Narzędzia istnieją. Claude Code udostępnia 17 zdarzeń cyklu życia, z których każde można podpiąć skryptami powłoki.¹⁵ Pytanie brzmi, czy zespoły zbudują hooki, czy zaakceptują mur 10%.

Ankieta Stack Overflow z 2025 roku skwantyfikowała koszt ich niebudowania: 66% deweloperów spędza czas na naprawianiu rozwiązań AI, które są „prawie dobre, ale nie do końca”. 45% uważa, że debugowanie kodu wygenerowanego przez AI jest bardziej czasochłonne niż pisanie go od zera. Zaufanie do dokładności AI spadło do 33%, a 46% aktywnie nie ufa wyjściu AI.⁸

Awarie nie są tajemnicze. Mają nazwy, sygnały detekcji i rozwiązania. Taksonomia czyni z nich problemy inżynieryjne zamiast folkloru.

Źródła