ENGINEERING DEVLOG
Codzienny zapis decyzji architektonicznych, testów systemów agentowych, postępów w Pythonie/TypeScript oraz automatycznych syntez dnia generowanych przez model Gemini z commitów w Git.
Alerty, które milczą, i granice między agentami
Wypuściłem 11 commitów w agent-brain: wyciszenie fałszywych alertów, twarde granice workspace i narzędzi dla każdego agenta oraz planer sprzedaży w Engineering Lab & DevLog.
Cztery watchery w bezczynności i dwa ciche sygnały awarii
Przepuściłem end-to-end cztery zaplanowane watchery i zebrałem dwa sygnały awarii: padnięty heartbeat cron joba oraz niestabilny odczyt SQLite w gatewayu. Sprawdziłem też, że brak aktywności w repo to prawdziwa cisza, a nie zepsuty zbierak danych.
Martwy slug modelu, cichy failover i jawny limit 8192 tokenów
Naprawiłem cron walidujący config, usunąłem martwy slug modelu z łańcucha fallback i domknąłem pipeline fiszek. Jawny limit 8192 tokenów zastąpił liczbę liczoną ze zgadywanego progu, a logi przestały puchnąć.
Brakujący import time, atomowy zapis stanu i watchdog, który rozumie retry
Naprawiłem panel Telegram, który przy każdym odświeżeniu wysyłał nową wiadomość, oraz wyciszyłem fałszywe alarmy watchdoga floty dla tur, które same się wyleczyły przez retry. Zacząłem też analizować niestabilność read-only workera w gatewayu SQLite.
Zatkany tmpfs, backup bez końca i osobny błąd watchdoga
Opróżniłem 4 GB tmpfs z 98% do 6% i przeniosłem katalog tymczasowy skryptu backupu obok jego celu kopii, dzięki czemu kopia kończy się z rc=0. Równolegle zdiagnozowałem crash watchdoga, który miał zupełnie inną przyczynę niż brak miejsca.
Dzień nadzoru floty agentów: fałszywy alarm i dwa throttlingi
Utrzymałem flotę agentów w ruchu przez cały dzień: skany wycieków, kontrola pamięci i quiz dzienny przeszły czysto, a dwa krótkie błędy limitu u dostawcy modeli obsłużyłem automatycznie, bez utraty pracy.
Weryfikator pamięci złapał 1 brakujący zapis na 372
Przeskanowałem 372 rekordy pamięci, znalazłem jeden brakujący zapis i odtworzyłem 2691 znaków w pliku dziennym. Zbadałem też nowy odcisk błędu providera, który wywołał trzy nieudane tury między 17:35 a 18:05 UTC.
Odzyskanie nocnego przebiegu agenta i naprawa klasyfikatora błędów
Odzyskałem utracony wynik nocnego joba agenta i naprawiłem klasyfikator błędów tak, by błąd providera z malformed tool call trafiał do klasy z retry. Efekt: przejściowy błąd nie kosztuje już całego dnia pracy.
Backup, który nie działał przez dobę: błąd kolejności argumentów w cronie
Naprawiłem zadanie backupu AOC/Hermes, które przez około 24 godziny w ogóle się nie uruchamiało z powodu złej kolejności argumentów w wrapperze crona. Dodałem stały guard w wrapperze i potwierdziłem ręczny przebieg: exit 0, świeże archiwum 48M, integralność ok.
Ograniczyłem przyrost logów i odzyskałem 1,8 GB na VPS
Zaudytowałem wszystkie źródła logów w mojej flocie agentów i wdrożyłem politykę retencji: limity dla cronów, watchdogów, kontenerów i journald. Dodałem wrapper logujący oraz przeniosłem stare artefakty z /tmp do wersjonowanego backupu.
Ślepe monitory kontekstu i zielone logi
Przepiąłem dwa monitory kontekstu na pola, które sessions API faktycznie zwraca, i dodałem strażnika schematu. Progi kompakcji 65% i 85% zaczęły działać, co potwierdziłem na żywej sesji o 06:51 UTC.
Detektor błędów tury: od cichego logu do alertu i auto-recovery
Prześledziłem błąd providera udający 'LLM request failed' i dodałem trwały detektor błędów tury z alertem oraz auto-recovery odpowiedzi. Cicha awaria stała się głośna i mierzalna.