Baza wiedzy

Najczęstsze problemy z agentami AI i jak je wykryć

Agenty rzadko psują się głośno. Najdroższe awarie są ciche: kod „działa”, testy świecą na zielono, a funkcja od tygodni nie robi nic. Poniżej awarie z prawdziwego wdrożenia — objaw, przyczyna, naprawa.

Opublikowano · Jakub Butryn, Founder · Lead engineer

Ciche awarie: operacja nie udała się, ale nikt tego nie wie

Wzorzec: kod wywołuje zapis do bazy albo API i ignoruje wynik. Zapytanie zwraca błąd 400, funkcja nie sprawdza `ok` i idzie dalej. Efekt: pole nigdy nie jest ustawiane, a użytkownik widzi „brak danych” zamiast błędu.

Naprawa: każda operacja zapisu zwraca wynik i loguje treść błędu, a wywołujący ten wynik sprawdza. Dobrym testem jest sztuczne zepsucie zapisu — jeśli nic nie krzyczy, masz cichą awarię.

Pętla wiadomości: agent przetwarza to samo od nowa

Objaw: po każdym uruchomieniu agent odbiera całą historię polecen i wykonuje je ponownie. Przyczyna jest zwykle po stronie serwera: kolejka oznacza wiadomość jako dostarczoną, ale zapytanie o nowe wiadomości nie filtruje po tym znaczniku. Klient startujący z kursorem zerowym dostaje wszystko.

Naprawa dwuwarstwowa: serwer wydaje wyłącznie niedostarczone wiadomości, klient trzyma kursor na dysku i wiąże go z kontem. Dostawa „co najwyżej raz” jest tu właściwym kompromisem — powtórka jest gorsza niż pominięcie.

Martwy token i wiszące zapytania

Objaw: agent zwiesza się na kilkanaście sekund przy każdej operacji sieciowej i kończy tracebackiem. Przyczyna: token wygasł, a klient przy każdym wywołaniu czeka na timeout, zamiast zapamiętać, że autoryzacja padła.

Naprawa: jednoznaczna odpowiedź 401 ustawia flagę „token nieważny” na czas procesu; kolejne wywołania zwracają błąd natychmiast, z komunikatem „zaloguj się ponownie”. Błędy sieci (5xx, brak internetu) nie mogą tej flagi ustawiać.

Testy, które przechodzą, choć nic nie sprawdzają

Realny przypadek: harness testów wołał funkcję asynchroniczną bez `await`. Test był liczony jako zdany, zanim wykonała się pierwsza asercja — dwadzieścia testów backendu nie sprawdzało niczego przez wiele wersji.

Drugi wariant: atrapa bazy ignorowała listę żądanych kolumn, więc test „endpoint zwraca pole X” przechodził, choć endpoint tego pola nie prosił. Jedyna obrona to test negatywny: zepsuj kod celowo i sprawdź, że test pada.

Sortowanie z NULL i inne pułapki bazy

Objaw: status pokazuje „nieaktywny”, mimo że agent zgłosił się sekundę temu. Przyczyna: w PostgreSQL przy sortowaniu malejącym wartości NULL są pierwsze, a zapytanie z `limit 1` brało wiersz bez znacznika czasu.

Naprawa: jawne `NULLS LAST` i test z dwoma wierszami, gdzie jeden ma NULL. Ta klasa błędów jest niewidoczna przy jednym rekordzie testowym — dlatego dane testowe muszą odwzorowywać rzeczywistość, w której konto ma wiele urządzeń.

Awarie zależne od środowiska

Instalacja edytowalna Pythona trzyma sztywną mapę modułów. Nowy plik nie jest widoczny dopóki pakiet nie zostanie przeinstalowany — a testy uruchamiane z katalogu projektu tego nie wykryją, bo katalog trafia na ścieżkę importu.

Wniosek ogólny: testuj tak, jak uruchamia użytkownik. Uruchomienie komendy z obcego katalogu, na czystym koncie i bez zmiennych środowiskowych wykrywa więcej niż setka testów jednostkowych z wnętrza repozytorium.

Najczęstsze pytania

Dlaczego agent AI powtarza te same działania?

Zwykle brakuje limitu iteracji i wykrywania powtórzeń albo narzędzie zwraca bezużyteczny wynik. Krótki komunikat błędu z podpowiedzią kolejnego kroku przerywa pętlę skuteczniej niż zmiana promptu.

Jak wykryć cichą awarię w agencie AI?

Zepsuj celowo daną operację i sprawdź, czy cokolwiek to zgłasza. Jeśli test przechodzi i logi milczą, masz cichą awarię: kod ignoruje wynik zapisu albo łapie wyjątek i idzie dalej.

Omów swój przypadek — konsultacja bezpłatna Telegram @sotius