Obserwowalność agentów AI: widzieć, co robi agent w czasie rzeczywistym

Im większą autonomię zyskuje agent AI, tym bardziej centralne staje się pytanie „co dokładnie zrobił?”. Agent działający nieprzerwanie, otrzymujący zgłoszenia z kilku kanałów, wywołujący narzędzia i czasem zlecający pracę subagentom, generuje aktywność trudną do śledzenia gołym okiem. Obserwowalność to techniczna odpowiedź na ten problem: uczynić widocznym, śledzalnym i zrozumiałym to, co faktycznie dzieje się wewnątrz systemu.

Definicja szczegółowa

Obserwowalność, w szerokim sensie tego terminu w inżynierii oprogramowania, to zdolność do zrozumienia wewnętrznego stanu systemu poprzez analizę tego, co produkuje na zewnątrz, zwykle śladów, metryk i dzienników (logów). To definicja przyjęta przez OpenTelemetry, referencyjny otwarty standard instrumentacji oprogramowania, wspierany przez wielu dostawców narzędzi obserwowalności. Te trzy typy danych pełnią uzupełniające się role: ślady śledzą zapytanie na jego drodze przez rozproszony system, dzienniki rejestrują opatrzone znacznikiem czasu zdarzenia, powiązane lub nie z konkretnym zapytaniem, a metryki agregują liczbowe pomiary w czasie.

Obserwowalność agentów stosuje tę samą zasadę do specyficznego przypadku autonomicznego agenta AI. Nie istnieje jeszcze jedna, szeroko ustabilizowana norma precyzyjnie definiująca, co powinna obejmować obserwowalność agentowa, w odróżnieniu od klasycznej obserwowalności oprogramowania, korzystającej z dojrzałego standardu takiego jak OpenTelemetry. W praktyce platformy uruchamiające agentów zbiegają się jednak we wspólnych potrzebach: wiedzieć, jakie działanie agent wykonał, na jakim narzędziu, w jakim momencie, z jakim wynikiem i z inicjatywy jakiego wyzwalacza (rozmowy, e-maila, zaplanowanego zadania).

To nie jest techniczny luksus zarezerwowany dla dużych zespołów. Gdy tylko agent może działać bez systematycznego zatwierdzania na każdym etapie, obserwowalność staje się konkretnym sposobem odpowiedzi na pytanie „dlaczego to zrobił?” po fakcie lub wychwycenia nietypowego zachowania, zanim spowoduje ono prawdziwy problem.

Jak to działa

W praktyce obserwowalność agenta opiera się na trzech nałożonych na siebie warstwach. Pierwsza to przechwytywanie zdarzeń: każda decyzja, każde wywołanie narzędzia, każdy istotny etap rozumowania jest rejestrowany w momencie, gdy się dzieje, ze znacznikiem czasu, statusem (w toku, powodzenie, błąd) i pochodzeniem wyzwolenia. Druga to strukturyzacja: te surowe zdarzenia są kategoryzowane (działanie na pliku nie jest rejestrowane tak samo jak wywołanie narzędzia zewnętrznego czy etap rozumowania modelu), aby można było skutecznie filtrować i wyszukiwać. Trzecia to udostępnianie: interfejs lub eksport pozwalający człowiekowi przejrzeć tę aktywność, czy to dla konkretnego agenta, czy dla całej organizacji.

Dobry system obserwowalności agentowej odróżnia też pracę zleconą: gdy agent powierza podzadanie efemerycznemu subagentowi, ta delegacja musi pozostać widoczna w chronologii agenta nadrzędnego, w przeciwnym razie część rzeczywistej pracy staje się niewidoczna.

Konkretny przykład z Atako

W Atako obserwowalność na poziomie agenta opiera się na osi czasu aktywności w czasie rzeczywistym: każde zdarzenie jest w niej kategoryzowane (sieć, pliki, pamięć, kod, integracja, planowanie, delegacja, rozumowanie modelu, inne), ze statusem (w toku, powodzenie, błąd), czasem trwania i precyzyjnym pochodzeniem (czat, e-mail, webhook, zaplanowane zadanie, wiadomość między agentami, subagent lub system). Dedykowany panel, „Tool logs”, wymienia osobno każde wywołanie integracji wykonane przez agenta, wraz z wynikiem (sukces, odmowa, błąd).

Ta obserwowalność na poziomie agenta jest uzupełniona widokiem obejmującym całą firmę, zarezerwowanym dla administratorów: strona „Integration logs” filtrowana według zespołu, agenta, dostawcy i daty, z eksportem CSV do 50 000 wierszy, oraz zagregowanym widokiem użycia według dostawcy integracji. Każde zarejestrowane wywołanie zachowuje informacje o zaangażowanym agencie, użytym połączeniu, dostawcy, konkretnym działaniu, jego argumentach (z systematycznie maskowanymi polami wrażliwymi, jak treść e-maila czy zapytanie wyszukiwania), statusie, kodzie HTTP zwróconym przez dostawcę, opóźnieniu i znaczniku czasu. Bariery ochronne uprawnień (granty) i obserwowalność działają ręka w rękę: jedna decyduje, czy działanie jest dozwolone, druga zachowuje ślad tego, co faktycznie się wydarzyło.

Częste błędy

Częstym błędem jest mylenie obserwowalności ze zwykłym dziennikiem błędów. System obserwowalny nie ogranicza się do sygnalizowania, gdy coś się psuje, daje też widoczność normalnego działania, co pozwala zrozumieć nieoczekiwane zachowanie, nawet gdy technicznie nic nie zawiodło.

Drugi błąd: myślenie, że obserwowalność uniemożliwia agentowi błędne działanie. To nie mechanizm blokujący, lecz mechanizm widoczności. Łączy się z uprawnieniami oraz, przy wrażliwych działaniach, z punktem zatwierdzenia przez człowieka, ale nie zastępuje żadnego z nich.

Trzeci błąd: rezerwowanie obserwowalności dla administratorów bez udostępniania jej zespołom, które faktycznie na co dzień korzystają z agenta. Użyteczna obserwowalność musi pozwolić osobie, która utworzyła lub używa agenta, zrozumieć jego zachowanie, nie tylko odizolowanej roli technicznej.

Wreszcie niedocenianie znaczenia delegacji do subagentów w chronologii aktywności to klasyczny błąd. Agent, który zleca podzadanie, w oczach użytkownika pozostaje odpowiedzialny za wynik: jeśli ta delegacja nie pojawia się wyraźnie w osi czasu, część rzeczywistej pracy staje się niewidoczna i niezrozumiała po fakcie.