Monitorowanie agentów AI: co logować, zanim coś się zepsuje

Dashboardy świecą na zielono, a agent się myli

Najpierw jedno zastrzeżenie, bo wyszukiwarka miesza te tematy. Nie chodzi tu o „monitoring LLM” w sensie GEO, czyli sprawdzanie, czy ChatGPT wspomina waszą markę. Chodzi o waszego własnego agenta i o to, co on robi z klientami i danymi.

Klasyczny monitoring odpowiada na jedno pytanie: czy zapytanie się udało i jak szybko. Przy agencie to nie wystarcza: endpoint zwraca 200 OK na czas, a odpowiedź cytuje regulamin zwrotów, który wycofaliście wiosną, i APM nie ma skąd wiedzieć, jaka była dobra odpowiedź.

Agenci kręcą się też w pętli, wołają to samo narzędzie cztery razy z lekko innymi argumentami albo ogłaszają, że zadanie zrobione, choć nie jest. Autorzy taksonomii MAST przeanalizowali ponad 1600 trace'ów z siedmiu frameworków wieloagentowych i opisali 14 rodzajów porażek. Jedna z trzech głównych kategorii to weryfikacja zadania: system kończy pracę, nie sprawdziwszy, czy robota naprawdę jest zrobiona.

Większość zespołów to wie, przynajmniej w teorii. W raporcie LangChain State of Agent Engineering (1340 odpowiedzi, ankieta z przełomu 2025 roku, publikacja w czerwcu 2026) 89% respondentów ma jakąś formę obserwowalności, a 62% śledzi pojedyncze kroki i wywołania narzędzi, ale tylko 37,3% ocenia ruch na żywo. To ankieta dostawcy (LangChain sprzedaje LangSmith), ale luka jest prawdziwa. Same klasy awarii (nieaktualny kontekst, zmyślone fakty, rozsypka w szczycie) mają osobny post-mortem. Tu chodzi o to, jak je złapać.

Jak monitorować agenta AI? Jednostką jest przebieg, nie zapytanie

Przebieg (run) to jedno zadanie od początku do końca: pytanie użytkownika, każde wywołanie modelu i narzędzia, które agent wykonał, żeby odpowiedzieć, i sposób, w jaki się to skończyło. W języku tracingu przebieg to trace, a każdy krok to span zagnieżdżony w środku. Logi zapytań pokażą osiem wywołań modelu; dopiero trace pokaże, że to była jedna zagubiona próba obsłużenia jednego zwrotu.

Potrzebnych spanów jest niewiele: wywołania modelu i narzędzi, retrieval, odczyty i zapisy pamięci, przekazania do innego agenta i zatwierdzenia przez człowieka. SDK frameworków już tak myślą: OpenAI Agents SDK owija każde Runner.run() w trace i emituje spany dla agentów, generacji, wywołań funkcji, guardraili, przekazań oraz audio z rozpoznawania i syntezy mowy.

Na spanie głównym zapisujcie wersję agenta, wersję promptu, id modelu, wersję schematów narzędzi, pseudonimowy identyfikator użytkownika, łączne tokeny i koszt oraz sposób zakończenia, jako jedno pole z zamkniętą listą wartości: sukces, limit kroków, limit budżetu, błąd narzędzia, rezygnacja. Przebieg, który wyczerpał limit kroków i grzecznie przeprosił, to nadal porażka.

Łatwo przeoczyć jedną pułapkę. SDK tracingu wysyłają spany w tle, żeby agent nie czekał na upload, i wsparcie LangSmith opisuje status „incomplete”, który z tego wynika: jeśli proces zakończy się przed wysłaniem, zdarzenie końca nigdy nie dociera, a lekarstwem jest wait_for_all_tracers() przed wyjściem. Przebieg, który się wysypał, najłatwiej traci końcówkę, więc opróżniajcie bufor przy zamykaniu i na każdej ścieżce błędu.

Te sygnały podepnijcie przed startem

Minimum, które podpięlibyśmy w każdym agencie przed pierwszymi użytkownikami. Progi są celowo względne: ustawcie je z własnych pierwszych dwóch tygodni ruchu.

Jeśli macie tylko tydzień, zacznijcie od wyniku przebiegu, wyników narzędzi z argumentami i wersji na spanie głównym. Razem zamieniają „agent był wczoraj jakiś dziwny” w zapytanie, które da się uruchomić.

Agenci AI psują się na wywołaniach narzędzi

Źle wywołany model daje zły akapit. Źle wywołane narzędzie coś zmienia: zamyka zgłoszenie, wysyła maila, nadpisuje rekord w CRM. Każdy span narzędzia powinien mieć nazwę, argumenty dokładnie w takiej postaci, w jakiej wygenerował je model, wynik walidacji, status odpowiedzi i czas. Trzymajcie argumenty także przy sukcesie: klasyczny błąd agenta to poprawne wywołanie z numerem niewłaściwego klienta.

Liczcie błędy per narzędzie i per klasa (złe argumenty, timeout, autoryzacja, błąd usługi): zdrowa średnia potrafi ukryć jedno narzędzie, które sypie się, odkąd partner zmienił klucz API.

Zapisy potrzebują dwóch dodatkowych pól. Klucza idempotencji, żeby ponowiony przebieg nie wysłał tego samego zwrotu dwa razy i żebyście mogli to udowodnić. I śladu zatwierdzenia, gdy przed akcją stoi człowiek: kto zatwierdził, co dokładnie widział, jaka była decyzja i ile trwała. Zatwierdzenie logujcie jako osobny span, a nie notatkę przy spanie narzędzia. Czas decyzji pokazuje, czy ludzie czytają, czy klikają w ciemno, a każde odrzucenie to czysta etykieta jakości.

Które narzędzia w ogóle mogą zapisywać, to kwestia uprawnień, opisana w tekście o podłączaniu AI do danych firmy: odczyt może być autonomiczny, zapis przechodzi przez bramkę. Obserwowalność to dowód, że bramka zadziałała.

Jakości nie widać we wskaźniku błędów

Odpowiedź może być błędna, choć nic nie rzuciło wyjątkiem, i jedyny sposób, żeby to zobaczyć, to ją ocenić. Online ewaluator (reguła, model w roli sędziego albo kciuk w dół od użytkownika) ocenia próbkę trace'ów na żywo. Offline złoty zestaw prawdziwych pytań ze sprawdzonymi odpowiedziami przechodzi przez każdą zmianę promptu lub modelu, zanim trafi do użytkowników.

Próbkowanie trzyma rachunek za sędziego w ryzach. Poradnik HoneyHive (aktualizacja 1 listopada 2026) proponuje oceniać cały ruch poniżej 1000 zdarzeń dziennie, 25-50% między 1000 a 10 000 i 5-25% powyżej, a nieudane zapytania zawsze. To punkt startowy jednego dostawcy, nie norma. Nieudane i zgłoszone przebiegi trzymajcie zawsze w 100%.

Złoty zestaw budujcie z trace'ów, nie z wyobraźni. Za każdym razem, gdy ewaluacja albo użytkownik oznaczy przebieg, kopiujcie wejście i poprawioną odpowiedź do zestawu. Konkretne testy na zmyślone fakty, jak ugruntowanie każdego twierdzenia i log pustego retrievalu, są w tekście o halucynacjach AI.

Uważajcie na styk z rozliczeniami. W LangSmith ewaluator online, który oceni trace przy włączonym przedłużaniu retencji, podnosi go do retencji extended, a to kosztuje dodatkowo.

Monitorowanie agentów AI: alerty, dla których warto się obudzić

Gdy dzwoni wszystko, nic nie ma znaczenia. Zanim napiszecie pierwszą regułę, podzielcie alerty na poziomy.

Opóźnienie potrzebuje budżetu na krok, a nie jednej liczby na cały przebieg. Zapiszcie docelowy czas od początku do końca i podzielcie go: rozpoznawanie mowy, pierwsze wywołanie modelu, każde narzędzie, końcowe wywołanie modelu i synteza mowy w agencie głosowym, albo retrieval i wywołania modelu w tekstowym. Alertujcie na krok, który przekracza swoją część: „wolne zapytanie do CRM” da się naprawić przed obiadem, „wolny przebieg” nie.

Według HoneyHive progi ustawiacie z własnej linii bazowej. Wyjątkiem jest limit kosztu na przebieg: wpiszcie go w kod pierwszego dnia, a potem przesuńcie tuż nad najdłuższy prawidłowy przebieg.

Konwencje OpenTelemetry GenAI tak, ale z przypiętą wersją

Rynek dostawców zmienia się szybko, i to najmocniejszy argument za instrumentacją przez OpenTelemetry. Langfuse jest zbudowany na OpenTelemetry i przyjmuje OTLP, a Arize Phoenix stoi na OpenTelemetry i OpenInference, więc kod zinstrumentowany przez OTel zmienia backend zmianą konfiguracji, a nie przepisywaniem.

Warto jednak wiedzieć, na czym się standaryzujecie. W wydaniu v1.42.0 z 12 czerwca 2026 OpenTelemetry oznaczył jako przestarzałe wszystkie atrybuty, metryki, zdarzenia i spany gen_ai.* w głównym repozytorium konwencji i przeniósł je do osobnego repozytorium semantic-conventions-genai. 13 listopada 2026 to repozytorium nie ma żadnych otagowanych wydań, a sekcja schema URL wciąż brzmi „TODO”. Specyfikacja spanów agentów ma status Development i nazywa operacje takie jak invoke_agent, invoke_workflow czy plan. Nazwy będą się jeszcze zmieniać.

Dlatego przypinajcie. Zablokujcie wersję biblioteki do instrumentacji, zapisujcie wersję konwencji jako atrybut zasobu i traktujcie aktualizację jak migrację schematu: przed wdrożeniem sprawdźcie dashboardy i zapytania alertów pod nowe nazwy. Zwróćcie uwagę, że treść wiadomości (gen_ai.input.messages, gen_ai.output.messages) jest Opt-In, z ostrzeżeniem, że to atrybut „likely to contain sensitive information including user/PII data”, czyli prawie na pewno z danymi osobowymi. Standard domyślnie ją wyłącza nie bez powodu.

Wasze trace'y to kopia danych klientów

Trace z agenta obsługi klienta zawiera wiadomość klienta, historię zamówień, którą agent pobrał, dane przekazane narzędziom i odpowiedź. W większości wdrożeń to dane osobowe w rozumieniu RODO, czyli narzędzie do obserwowalności staje się podmiotem przetwarzającym, z którym potrzebna jest umowa powierzenia, region i polityka retencji, dokładnie jak z CRM.

Ustawienia domyślne ciągną w przeciwną stronę. W OpenAI Agents SDK tracing jest włączony domyślnie, a trace_include_sensitive_data ma domyślnie wartość True, czyli zapisuje wejścia i wyjścia generacji modelu i wywołań funkcji. Spany audio zawierają domyślnie nagranie wejścia i wyjścia w base64 (PCM), dopóki nie wyłączycie trace_include_sensitive_audio_data, więc agent głosowy może trzymać w trace'ach nagrania ludzkich głosów.

Checklista RODO dla trace'ów, do przejścia z osobą od ochrony danych:

Cel i podstawa. Zapiszcie w rejestrze czynności przetwarzania, po co trzymacie trace'y (debugowanie, ocena jakości, bezpieczeństwo) i na jakiej podstawie. „Na wszelki wypadek” nie jest celem.

Minimalizacja przed wysyłką. Maskujcie we własnym procesie, zanim dane opuszczą aplikację. SDK Langfuse przyjmują funkcję maskującą (mask_otel_spans w Pythonie, mask w LangfuseSpanProcessor w JS/TS), a dokumentacja maskowania ostrzega, że maskowanie w kolektorze OTel dzieje się już po wyjściu danych z aplikacji. LangSmith ma `LANGSMITH_HIDE_INPUTS`, `LANGSMITH_HIDE_OUTPUTS` i anonimizator oparty na regexach, również po stronie klienta.

Umowa powierzenia i region. Langfuse oferuje DPA i deklaruje, że nie trenuje modeli na danych klientów. LangChain nie ma podmiotu w UE do zawierania umów, choć region EU jest dostępny na każdym planie. Region wybierzcie przy zakładaniu konta, bo żaden z nich nie przenosi danych między regionami.

Usuwanie na żądanie. Przypinajcie do każdego trace'a pseudonimowy userId, żeby żądanie usunięcia danych było jednym zapytaniem. W Langfuse usuwa się trace'y przez UI albo DELETE /api/public/traces, zwykle w ciągu 15 minut.

Retencja jako liczba. Wpiszcie konkretny okres i sprawdźcie, czy plan go w ogóle obsługuje: w Langfuse Cloud własne usuwanie po zadanym czasie jest dopiero od planu Pro.

Teraz AI Act, bo tu dwa porządki prawne ciągną w przeciwne strony. Art. 12 wymaga, żeby systemy wysokiego ryzyka technicznie umożliwiały automatyczne rejestrowanie zdarzeń. Art. 19 każe dostawcom trzymać te logi przez okres stosowny do przeznaczenia, co najmniej 6 miesięcy, a art. 26 ust. 6 nakłada to samo minimum na podmioty stosujące, w obu przypadkach z zastrzeżeniem prawa o ochronie danych osobowych. Po Omnibusie cyfrowym, który wszedł w życie 27 lipca 2026, przepisy te obowiązują od 2 grudnia 2027 dla systemów z załącznika III i od 2 sierpnia 2028 dla załącznika I. Pełny kalendarz i pytanie, czy jesteście dostawcą, czy podmiotem stosującym, są w przewodniku po AI Act.

AI Act wyznacza więc minimum, a RODO, z zasadą ograniczenia przechowywania, ciągnie w stronę maksimum. Większość firmowych agentów nie jest systemem wysokiego ryzyka i wtedy decyduje głównie RODO. Jeśli jednak wasz jest, zderzcie wymóg z narzędziem. Maksymalna retencja w LangSmith SaaS to od 14 września 2026 180 dni, a sześć miesięcy kalendarzowych to od 181 do 184 dni. Czy trace w zewnętrznym narzędziu w ogóle jest „logiem” w rozumieniu art. 12 i jak liczyć te sześć miesięcy, to pytanie do prawnika, nie do nas. Na szczęście log, którego wymagałby AI Act, to mniej więcej ten sam log, który i tak chcecie mieć do debugowania.

Ile kosztuje tracing: pięciu dostawców, pięć jednostek rozliczeniowych

Każdy dostawca liczy co innego. Ceny katalogowe w dolarach pobraliśmy 13 listopada 2026; przed planowaniem budżetu sprawdźcie stronę dostawcy.

Przeliczony miesiąc pokazuje, czemu jednostka ma znaczenie. Załóżmy 1000 przebiegów dziennie, czyli 30 tys. miesięcznie, a w każdym jeden trace, pięć wywołań modelu, osiem wywołań narzędzi, jeden retrieval i jedna ocena. To arytmetyka na cenach katalogowych, nie pomiar.

Langfuse Core: 16 jednostek na przebieg, 480 tys. w miesiącu. 29 USD plus 380 tys. dodatkowych jednostek po 8 USD za 100 tys. daje około 59 USD, z 90 dniami dostępu do danych.

Datadog Pro, umowa roczna: płacicie tylko za pięć wywołań modelu, czyli 150 tys. spanów LLM. 160 USD plus pięć pakietów po 10 tys. za 3,50 USD to około 178 USD. Spany narzędzi są tu darmowe, wszędzie indziej płatne.

LangSmith Plus, jedno stanowisko: 30 tys. trace'ów, z czego 20 tys. ponad wliczone 10 tys. Stawki za nadwyżkę nie ma dziś w publicznym cenniku, więc wynik to 39 USD plus to, co pokażą wasze ustawienia rozliczeń.

Braintrust i Arize AX: zależą od wielkości danych, a Arize nie podaje stawek za nadwyżkę. Przy 20 KB na przebieg miesiąc to 0,6 GB, w darmowym gigabajcie Braintrusta; jeśli każdy przebieg ciągnie 200 KB pobranego kontekstu, robi się 6 GB, ponad 5 GB w Pro. Arize AX Pro obejmuje 50 tys. spanów, a ten miesiąc daje ich 450 tys.

W&B Weave też liczy objętość danych: jego cennik, dziś na stronie CoreWeave, podaje 1 GB miesięcznie za darmo i plan Pro od 60 USD z 1,5 GB, potem 0,10 USD za MB.

Narzędzia do obserwowalności LLM na rynku, który się konsoliduje

Firma, która dziś prowadzi wasze narzędzie do tracingu, za rok może już nim nie zarządzać. ClickHouse przejął Langfuse w styczniu 2026, obiecując brak zmian licencji i self-hosting jako pełnoprawną ścieżkę. Mintlify kupił Helicone w marcu i przełączył go w tryb utrzymania, oferując klientom pomoc w przenosinach. Cisco sfinalizowało przejęcie Galileo w maju i włącza je do Splunk Observability. Dostawcy nadal mają sens, tylko instrumentacja powinna być na tyle przenośna, żeby dało się od nich odejść.

Pytanie „Langfuse czy LangSmith” rozstrzyga się bardziej na hostingu i uzależnieniu od dostawcy niż na funkcjach: Langfuse jest open source i da się go postawić u siebie, a LangSmith to przede wszystkim chmura, z wdrożeniem hybrydowym lub własnym dopiero w planie Enterprise.

Self-host czy SaaS to w dużej mierze pytanie, kto podniesie ClickHouse o trzeciej w nocy. Instrukcja self-hostingu Langfuse wymienia kontenery web i worker oraz PostgreSQL, ClickHouse, Redis lub Valkey i magazyn zgodny z S3. Jeśli nikt w zespole nie utrzymuje takiego stosu, region EU w chmurze z umową powierzenia bywa bezpieczniejszym wyborem. Jeśli umowa z klientem mówi, że trace'y nie opuszczają waszej infrastruktury, stawiajcie u siebie i policzcie czas na utrzymanie.

Co podpiąć w tym tygodniu

Nic z tego nie wymaga wcześniejszego wyboru platformy. Przy agencie, który już działa, tydzień pracy wygląda tak:

1. Dajcie każdemu przebiegowi id trace'a i pole wyniku. Ustawiane w kodzie na każdej ścieżce wyjścia, łącznie z błędami i limitem kroków.

2. Wersje na span główny. Bez nich regresja i przypadkowy szum wyglądają tak samo.

3. Logujcie każde wywołanie narzędzia z argumentami i statusem. Do zapisów dodajcie klucz idempotencji i osobny span dla każdego zatwierdzenia przez człowieka.

4. Opróżniajcie bufor przy zamykaniu i przy błędach. Potem celowo zabijcie proces w trakcie przebiegu i sprawdźcie, czy trace dotarł.

5. Maskowanie przed wysyłką i region EU. Wyłączcie zapis surowej treści tam, gdzie SDK włącza go domyślnie, dodajcie pseudonimowy identyfikator użytkownika i wpiszcie okres retencji do rejestru czynności przetwarzania.

6. Złoty zestaw 20 prawdziwych pytań. Wyciągnijcie je z trace'ów i puszczajcie przed każdą zmianą promptu lub modelu.

7. Budżet czasu na krok i limit kosztu na przebieg. Alert na krok, nie na całość.

8. Policzcie własny miesiąc. Z jednego dnia trace'ów wyciągnijcie liczbę spanów i wielkość danych na przebieg i przepuśćcie je przez tabelę wyżej, zanim cokolwiek podpiszecie.

Pasuje tu jedna lekcja z naszej pracy. W Race Engineerze, agencie głosowym, który odpowiada kierowcy iRacing w niecałe dwie sekundy przez 19 narzędzi MCP, agent celowo trzyma w kontekście tylko pytanie kierowcy i swoją końcową odpowiedź (MAX_HISTORY = 4). Każde pośrednie wywołanie narzędzia wykonuje się na świeżo i jest potem odrzucane, bo czas okrążenia sprzed 30 sekund jest już błędny. Dla odpowiedzi to dobra decyzja, ale historia rozmowy przestaje być zapisem tego, co agent zrobił: wywołania usunięte z kontekstu istnieją tylko wtedy, gdy coś zapisze je osobno, podobnie jak potwierdzenie kierowcy na bramce przed komendą pit-stopu. Jeśli wasz agent przycina sobie pamięć, pilnujcie, żeby logi się nie przycinały.

A jeśli przyda się drugie spojrzenie na to, co wasz agent zapisuje, zanim trafi do klientów, to część naszego bezpłatnego audytu.

FAQ