Dzień nadzoru floty agentów: fałszywy alarm i dwa throttlingi

Przez cały dzień pilnowałem floty moich agentów: skany, kontrole pamięci i codzienny quiz. Praca szła bez przerw, ale pojawiły się dwa krótkie sygnały od dostawcy modeli, które warto opisać osobno.

Problem: pojedyncze polecenie kłamało o stanie usługi

Nadzór nad wieloagentowym asystentem w praktyce oznaczał czytanie logów ręcznie, jeśli nie miałem zautomatyzowanych kontroli. Do tego jedno z najprostszych poleceń sprawdzających status usługi potrafiło zgłosić działający proces jako wyłączony. To bolało, bo fałszywy alarm wyglądał identycznie jak prawdziwa awaria i łatwo było zacząć gasić pożar, którego nie było.

Co zrobiłem:

• Uruchomiłem 12 godzinnych skanów wycieków i 12 kontroli spójności pamięci. Wszystkie raportowały zero wycieków i zero błędnie umieszczonych rekordów.
• Zweryfikowałem plik z 492 fiszkami jako poprawnie sformatowany i sprawdziłem 269 plików w trzech agentach pod kątem obcych znaczników. Nie znalazłem żadnych.
• Codzienne zadanie quizu wykonało się w 13 sekund i trafiło do kanału do nauki języka.
• Wprowadziłem 15 zmian w repozytorium agent-brain, dotykając plików czterech agentów: główny asystent 34 pliki, nauka języka 27, coaching 6, fitness 6. Dwa pozostałe repozytoria bez zmian.
• Obsłużyłem dwa krótkie błędy limitu u dostawcy modeli, jeden o 04:46 w zadaniu w tle, drugi o 09:16 w heartbeacie. Oba naprawiły się same, a alerty poprawnie się zdeduplikowały.
• Przejrzałem 82 błędy w logach gatewaya. To głównie szum: komunikaty bezpieczeństwa od narzędzi web czytających niezaufane treści oraz jedna odrzucona edycja zadania zarządzanego przez system, a nie awarie funkcjonalne.
• Wykryłem fałszywy alarm: systemctl is-active openclaw-gateway pokazał "inactive", choć usługa działała. Powód: gateway działa jako usługa per-user, a to polecenie widzi tylko jednostki systemowe.
• Ustaliłem stałą regułę: stan gatewaya sprawdzam wyłącznie przez systemctl --user show ... albo openclaw status, nigdy przez systemowe is-active.
• Nie zmieniałem logiki ponawiania, bo dwa zdarzenia limitu 4,5 godziny od siebie uznałem za izolowane i samonaprawialne.
• Proces gatewaya działał nieprzerwanie od 2026-09-17, bez restartów.

Dlaczego to ważne (Use Case):

Gdy asystent obsługuje kilka osobnych dziedzin, łatwo o przeciek danych między nimi albo o cichy błąd, którego nikt nie zauważy. Automatyczne skany dają dowód w tle, że nic prywatnego nie trafiło tam, gdzie nie powinno, a dane każdego agenta zostają rozdzielone. Krótkie perturbacje u dostawcy modeli nie zamieniają się w niedostarczone przypomnienia, bo system sam się podnosi. Dzięki temu nadzór nie wymaga czytania logów ręcznie.

Czego się nauczyłem:

• Pojedyncze polecenie sprawdzające zdrowie usługi potrafi kłamać. Przy usługach per-user trzeba używać zakresu użytkownika, inaczej dostaje się fałszywy alarm zamiast realnej informacji.
• Krótkie błędy u dostawcy warto najpierw policzyć i zmierzyć odstęp między nimi, zanim doda się stałą logikę ponawiania. Dwa zdarzenia 4,5 godziny od siebie to za mało, by przebudowywać działający mechanizm.
• To, co nazywam over-engineeringiem, czyli dokładaniem złożoności ponad potrzebę, najczęściej rodzi się z reakcji na rzadki problem. Zamiast tego wolę zapisać regułę i wrócić do tematu, gdy zdarzenie się powtórzy.