Cztery autonomiczne agenty AI potrafią teraz wykryć błąd w oprogramowaniu, edytować wadliwy kod i potwierdzić poprawkę – a wszystko to w czasie krótszym niż minuta, dzięki nowemu workflow opartemu na obserwowalności (observability), stworzonemu na hackathon SigNoz.

System nazwany AgentOps monitoruje SigNoz pod kątem skoków błędów, pobiera odpowiednie logi i ślady (traces), wskazuje dokładny plik i linię odpowiedzialną za problem, edytuje kod źródłowy w piaskownicy (sandbox), a następnie powtarza żądanie, aby udowodnić, że błąd został usunięty. Każdy pełny cykl trwa od 30 do 60 sekund, a cały proces przebiega bez ani jednego polecenia ze strony człowieka.

Dlaczego obserwowalność jest ważna dla agentów AI

Tradycyjna praktyka SRE traktuje logi, metryki i rozproszone ślady jako „oczy” usługi. Gdy żądanie kończy się niepowodzeniem, inżynier podąża za śladem do wadliwego komponentu. Ta sama zasada napędza teraz AgentOps, ale „usługą”, która podlega obserwacji, jest sam agent AI.

Każde narzędzie wywoływane przez agenta – czy to wywołanie modelu językowego, edycja systemu plików czy uruchomienie testów – tworzy span w śladzie. Span rejestruje czas rozpoczęcia, czas trwania i status sukcesu, dzięki czemu agent może zobaczyć, jak długo trwał każdy krok rozumowania i czy zakończył się powodzeniem. Łącząc te spany, agent buduje pełny obraz własnego procesu myślowego, dokładnie tak, jak zrobiłby to człowiek podczas ręcznego debugowania.

Kluczowa zmiana polega na przejściu od „obserwowalności jako warstwy raportowania” do „obserwowalności jako percepcji”. AgentOps przekazuje dane ze śladów z powrotem do agentów, pozwalając im analizować własne działania w czasie rzeczywistym. Wynikiem jest pętla, w której AI nie tylko generuje hipotezę, ale także weryfikuje ją w oparciu o tę samą telemetrię, której używa do wykrycia problemu.

Czteroetapowy workflow

  1. Monitorowanie – lekki proces monitorujący skanuje SigNoz w poszukiwaniu nowo zgłoszonych błędów.
  2. Diagnoza – agent pobiera powiązane logi i ślady, wyodrębnia stos (stack) oraz izoluje plik źródłowy i numer linii, które wywołały błąd.
  3. Naprawa – korzystając z serwera systemu plików w piaskownicy, agent zapisuje poprawkę w zidentyfikowanej linii. Piaskownica wymusza ścisłe uprawnienia i automatycznie wycofuje zmiany, jeśli edycja narusza przyjęte zasady.
  4. Weryfikacja – agent ponownie wysyła oryginalne żądanie do poprawionego kodu. Jeśli ślad wykaże poprawne wykonanie, poprawka zostaje zatwierdzona; w przeciwnym razie agent powtarza proces.

Wszystkie kroki są koordynowane przez ten sam zestaw agentów, z których każdy działa jako autonomiczny mikroserwis. Cały łańcuch jest obserwowalny dzięki spanom zgodnym z OpenTelemetry, które są pobierane i wizualizowane przez SigNoz.

Trudne lekcje dotyczące niezawodności

Jasność błędów

Ogólny status „failed” nic nie mówi. Zespół dodał szczegółowe powody awarii – np. „błędna hipoteza” lub „poprawka przerwała proces” – dzięki czemu kolejne agenty mogą zdecydować, czy spróbować ponownie, wycofać się, czy przerwać działanie. Odzwierciedla to sposób, w jaki ludzie opisują przyczyny źródłowe w raportach post-mortem.

Opóźnienie danych

Telemetria nie pojawia się natychmiast. Agenty uwzględniają teraz krótką pauzę i test poprawności (sanity check), aby upewnić się, że wymagane logi dotarły, zanim potwierdzą naprawę. Bez tego zabezpieczenia agent mógłby działać na podstawie niepełnych danych i wygenerować fałszywie pozytywny wynik.

Granice bezpieczeństwa

Pozwolenie AI na pisanie kodu niesie ze sobą ryzyko eskalacji uprawnień. Piaskownica działa za dedykowanym serwerem systemu plików, który ogranicza zakres zapisu do docelowego repozytorium i automatycznie przywraca poprzedni stan, jeśli test zakończy się niepowodzeniem. Ten model izolacji pozwala kontrolować możliwości AI.

Limity tokenów

Duże modele językowe zużywają tokeny API, a dzienne limity mogą zostać wyczerpane w trakcie dochodzenia. AgentOps śledzi zużycie tokenów na pojedynczy incydent i ogranicza dalsze wywołania po osiągnięciu progu, zapobiegając kaskadzie nieudanych napraw w przypadku wyczerpania limitu.

Co wykazało demo

Zespół wprowadził zupełnie nowy błąd, który nigdy wcześniej nie pojawił się w kodzie źródłowym. AgentOps wykrył anomalię, prześledził ją do dokładnej linii, wygenerował poprawkę, zastosował ją w piaskownicy i zweryfikował, że żądanie zakończyło się sukcesem – a wszystko to bez żadnych ręcznych zmian w kodzie ani nowych poleceń. Czas operacji end-to-end wyniósł mniej niż minutę, co zgadza się z raportowanym czasem 30–60 sekund.

Kontrargument: autonomia nie jest rozwiązaniem idealnym

Co warto obserwować dalej

  • Telemetria niezależna od modelu – W miarę jak coraz większa liczba dostawców udostępnia spany zgodne z OpenTelemetry, podejście to może stać się neutralne względem dostawcy, co ułatwi adopcję w heterogenicznych stosach technologicznych.
  • Mechanizmy zabezpieczające oparte na politykach – Wprowadzenie konfigurowalnych polityk określających, które pliki agent może edytować lub jakie zestawy testów muszą zostać zaliczone przed zatwierdzeniem zmian (commit), pozwoli rozwiązać kwestie związane z zarządzaniem (governance).
  • Budżetowanie tokenów uwzględniające koszty – Dynamiczna alokacja tokenów oparta na powadze incydentu mogłaby zapobiec wyczerpaniu limitów, zachowując jednocześnie zdolność do obsługi błędów o wysokim wpływie.

AgentOps pokazuje, że cykl naprawy błędów może trwać od 30 do 60 sekund. Eksperyment stanowi dowód koncepcji (proof-of-concept) na to, że obserwowalność może być wykorzystywana przez autonomicznych asystentów oprogramowania.