Ciche awarie: gdy Twój agent AI udaje, że wszystko jest OK

Dzień Ojca nauczył mnie jednej, brutalnej prawdy: kiedy w domu robi się podejrzanie cicho, to nie znaczy, że jest spokój. To znaczy, że dziecko właśnie coś przeskrobało. W inżynierii systemów agentowych działa to identycznie. Cisza nie jest dowodem zdrowia. Bywa dowodem, że coś już poszło nie tak — tylko nikt nie krzyknął.

Systemy, które „same się naprawiają"

Większość z Was buduje systemy z wbudowanym instynktem samozachowawczym. Request nie przeszedł? Retry. Model wypluł błąd? Fallback na tańszy model. Wszystko po cichu, bez dzwonków, bez alertów. To brzmi jak dobra inżynieria agentowa i czasem nią jest. Problem zaczyna się wtedy, gdy ten mechanizm staje się jedyną reakcją systemu i nie zostawia po sobie żadnego śladu.

Z zewnątrz wygląda jak sukces, bo system zwraca „OK". Status 200, odpowiedź jest, dashboard zielony. Ale pod spodem jakość leci na łeb na szyję. Retry zadziałał dopiero za trzecim razem, na innym, słabszym modelu. Fallback po cichu podmienił kontekst. Użytkownik dostał odpowiedź gorszą o klasę i nikt się o tym nie dowiedział, bo nigdzie nie zapaliła się żadna lampka.

Dlaczego w ogóle budujemy to tak po cichu? Bo każdy z nas oberwał kiedyś budzikiem o trzeciej nad ranem od alertu, który okazał się niczym. Zmęczenie alertami jest realne, więc instynktownie wyciszamy wszystko, co „samo się ogarnia". Tyle że między „nie budź mnie pojedynczym retry" a „nie loguj retry w ogóle" leży przepaść. Pierwsze to higiena. Drugie to ślepota. I właśnie z tej ślepoty rodzą się ciche awarie, których potem nikt nie umie wytłumaczyć.

1/3 błędów to rate-limity zamiatane pod dywan

Raport Datadog State of AI Engineering 2026 nie pozostawia złudzeń: 1/3 wszystkich błędów w LLM-spanach to rate-limity, które „ciche retry" zamiata pod dywan. Jedna trzecia. To nie statystyczny szum, to systematyczny sygnał, że Twoja infrastruktura non stop uderza w limity, a Ty tego nie widzisz, bo retry łata dziurę, zanim ktokolwiek zdąży ją zauważyć.

Brak alertu to nie to samo co brak problemu. To dwie zupełnie różne rzeczy, które bardzo łatwo pomylić. Rate limit, który dziś jest po cichu retry'owany, jutro — przy większym ruchu — przestanie się mieścić w oknie. I wtedy „ciche" zrobi się bardzo głośne. W najgorszym możliwym momencie, dokładnie wtedy, gdy najbardziej potrzebujesz stabilności.

I tu jest sedno: rate limit to nie awaria losowa, to kwestia pojemności. Jeśli jedna trzecia Twoich błędów to ograniczenia przepustowości, których nie widzisz, to nie masz problemu z modelem — masz problem z planowaniem. A tego nie rozwiążesz kolejnym retry. Rozwiążesz to świadomą decyzją: większy limit, kolejka albo backpressure, który ktoś faktycznie zobaczy na wykresie.

„Cisza w logach to najgłośniejszy sygnał, że Twój agent przestał pracować, a zaczął tylko udawać."

Retry i fallback to nie automatyzacja. To dług.

Jeśli Twój system robi retry albo zjeżdża na fallback bez zostawienia śladu w monitoringu — licznik, log, cokolwiek — to nie masz automatyzacji. Masz ukryty dług techniczny. Taki, który nie krzyczy, dopóki nie urośnie, a potem wybucha Ci w twarz. Budujesz wtedy systemy, które kłamią, że są zdrowe, bo boją się krzyczeć.

Różnica między dojrzałą observability agentów AI a teatrem jest banalnie prosta: każdy retry i każdy fallback ma być policzalny. Nie chodzi o to, żeby ich nie było. One są normalną częścią odpornego systemu. Chodzi o to, żeby każdy z nich zostawiał ślad, który da się zliczyć, wykreślić i obudzić nim alert. Brzmi jak dodatkowa robota, ale to kilka linijek w warstwie, którą i tak już masz.

Cicha awaria ma wiele twarzy. Czasem to retry, czasem fallback, a czasem model, który sam siebie ocenia i wystawia sobie piątkę. O tej drugiej pułapce — modelu, który myli pewność z poprawnością — pisałem w osobnym wpisie o samoocenie modelu. Mechanizm jest dokładnie ten sam: system zwraca „OK", bo nikt go nie zmusił, żeby przyznał się do błędu.