Detektor błędów tury: od cichego logu do alertu i auto-recovery

Tura asystenta padła w trakcie zadania i nie zostawiła po sobie żadnego automatycznego sygnału. Prześledziłem to zdarzenie, a potem zamieniłem je w stały, monitorowany przypadek.

Problem: błąd, którego watchdog nie widział

Tura zakończyła się komunikatem "LLM request failed". Z logu nie dało się od razu powiedzieć, czy to limit wyjścia modelu, czy coś po stronie providera. Fleet watchdog pilnował wcześniej tylko twardych błędów i bezczynności, więc ostrzeżeniowa klasa błędów tur była dla niego niewidoczna. W praktyce oznaczało to, że gdyby problem wrócił, dowiedziałbym się o nim dopiero z reklamacji użytkownika. Taki cichy tryb awarii jest gorszy niż głośny błąd, bo nie generuje żadnej akcji.

Co zrobiłem: diagnoza i detektor

• Zdiagnozowałem zdarzenie jako malformed tool call po stronie providera: 776 tokenów wyjściowych przy limicie 32768 i pusta treść. To wykluczyło przekroczenie limitu wyjścia jako przyczynę. Sprawdziłem, że pliki zadania zostały zapisane, a kolejne tury działały normalnie, więc awaria była przejściowa i niezniszcząca.
• Dodałem detektor błędów tury do fleet watchdog: alert przy 1 lub więcej błędach na godzinę, z deduplikacją, dostarczany przez chat Bot API, bez zużycia tokenów modelu. Przed zmianą zrobiłem backup konfiguracji.
• Utrzymałem dwuwarstwową ochronę: detektor, który alarmuje na błąd tury, oraz reconciler, który automatycznie domyka odpowiedź, gdy pytanie czeka ponad 10 minut bez odpowiedzi.
• Zostawiłem 10-minutowe okno karencji, ścieżkę alertów bez zużycia tokenów modelu, auto-recovery domyślnie włączone i możliwość wyłączenia jednym flagiem.
• Uruchomiłem 12 automatycznych skanów wycieków danych oraz sprawdzenia pamięci i integralności plików we wszystkich workspace'ach agentów. Wszystko wróciło czyste.
• Zapisałem 11 zmian w repo agent-brain oraz pliki wiedzy w czterech agentach: 52, 18, 7 i 6 plików, 0 autorstwa człowieka.
• Oflagowałem miejsca do wzmocnienia: powtarzające się błędy exact-text edit na dużym pliku JSON z fiszkami (niezgodność whitespace), jedno zaplanowane zadanie session-history, które padło, oraz 65 błędów na poziomie gateway. Te ostatnie to głównie background reflection lane z timeoutem blisko 64 sekund plus błędy narzędzi.
• Ewaluacja: dataset fiszek zwalidowany jako poprawny JSON (202 karty), leaf scanner przeszedł 203 pliki w trzech workspace'ach agentów i nie znalazł obcych markerów. Memory verifier wykonał 12 przebiegów i potwierdził, że każdy rekord jest na miejscu. Quiz watchdog miał 9-sekundowy przebieg bez aktywności słownikowej i słusznie zachował ciszę.

Dlaczego to ważne (Use Case)

Tura modelu może umrzeć niespodziewanie, a użytkownik nadal powinien dostać odpowiedź. Po tej zmianie awaria degraduje się do wolniejszej odpowiedzi zamiast do porzuconej rozmowy, a ja dostaję alert, zamiast dowiadywać się o problemie z reklamacji. Dwuwarstwowy układ rozdziela dwie różne rzeczy: wykrycie problemu i naprawienie tego, co widzi użytkownik. Alert przez chat Bot API nie kosztuje tokenów modelu, więc monitoring jest wystarczająco tani, by trzymać go włączonego bez przerwy.

Czego się nauczyłem

1. Jeśli coś nie ma alertu, to nie jest obsłużone. Linia w logu bez detektora nie jest monitoringiem, tylko śladem do przeszukania po fakcie.
2. Alert bez recovery nadal zostawia użytkownika z czekaniem. Wykrycie i domknięcie odpowiedzi to dwa osobne mechanizmy i oba są potrzebne.
3. Tani kanał alertów zmienia decyzję projektową. Gdy powiadomienie nie zużywa tokenów modelu, mogę pozwolić sobie na częste sprawdzania i próg alertu na poziomie 1 błędu na godzinę.