Zespół Microsoft Foundry dodał śledzenie (tracing) oparte na OpenTelemetry do swojego frameworka agentów, dając programistom możliwość śledzenia pełnego procesu wykonania (end-to-end) w heterogenicznych agentach napędzanych przez LLM.

Dlaczego systemy wieloagentowe potrzebują czegoś więcej niż plików logów

Typowe ćwiczenie z reagowania na incydenty oparte na AI wykorzystuje agenta dowodzącego (commander agent), który koordynuje pracę kilku agentów specjalistycznych: jeden analizuje logi, inny wykrywa anomalie w metrykach, trzeci dopasowuje objawy do instrukcji postępowania (runbooks), a router wybiera najlepszy model językowy dla każdego podzadania. Każdy specjalista może wywoływać inny model – na przykład wariant „gpt-5-mini” – i korzystać z własnych narzędzi. Gdy coś idzie nie tak, inżynierowie analizują odizolowane logi, które pokazują, co zrobił każdy komponent, ale nie dają wglądu w to, jak poszczególne elementy łączą się w całość.

Bez ujednoliconego śladu (trace), przyczyna źródłowa ukrywa się w procesie przekazywania zadań między agentami. Dowódca może wysłać żądanie, które czytnik logów przetworzy poprawnie, jednak specjalista od metryk błędnie zinterpretuje dane i zasugeruje niewłaściwy runbook. Ręczne debugowanie takiego łańcucha zajmuje dużo czasu i sprzyja błędom.

Jak OpenTelemetry spaja przepływ pracy

OpenTelemetry definiuje dwa kluczowe pojęcia: traces (ślady) i spans (zakresy). Trace to unikalny identyfikator, który towarzyszy żądaniu od momentu wejścia do otrzymania końcowej odpowiedzi. Span rejestruje pojedynczą operację – taką jak wywołanie modelu językowego lub narzędzia – w ramach danego trace.

Gdy agent otrzymuje żądanie, pobiera Trace ID z metadanych żądania i tworzy span potomny (child span), który dziedziczy ten sam identyfikator. Span potomny rejestruje czas rozpoczęcia, czas trwania, atrybuty (nazwa modelu, użyte narzędzie) oraz wszelkie błędy. Proces ten powtarza się dla każdego kolejnego agenta (downstream agent), budując drzewo odzwierciedlające logiczny przepływ całego zadania.

OpenTelemetry obsługuje również Baggage – lekki nośnik dla niestandardowych par klucz-wartość. Poprzez dołączenie „drill-id” lub innego kontekstu biznesowego do Baggage na początku trace, każdy kolejny span automatycznie dziedziczy ten identyfikator. Następnie procesor spanów (span processor) przekształca Baggage w zwykłe atrybuty, co ułatwia przeszukiwanie wszystkich spanów należących do konkretnego ćwiczenia incydentu.

Jak wygląda nowy interfejs śledzenia

Dzięki wprowadzonej instrumentacji, Azure Monitor (lub dowolny backend zgodny z OpenTelemetry) generuje wizualną hierarchię:

  • Agent name / ID – pokazuje, który komponent wykonał operację.
  • Tool usage – rejestruje, jaka zewnętrzna usługa lub funkcja została wywołana.
  • Model version – loguje dokładnie użyty model LLM, co jest przydatne do śledzenia regresji po aktualizacji modelu.
  • Token consumption – rejestruje, ile tokenów wysłano do modelu i ile z niego odebrano, co pomaga zespołom zarządzać kosztami.
  • Latency / duration – wskazuje miejsca powstawania wąskich gardeł, niezależnie od tego, czy występują one podczas wnioskowania modelu (inference), czy operacji wejścia/wyjścia narzędzi (tool I/O).

W przykładzie z ćwiczeniem incydentu, główny span (root span) dowódcy tworzy spany potomne dla każdego specjalisty, a każdy specjalista tworzy kolejne spany dla swoich wywołań modelu. Kliknięcie w dowolny węzeł ujawnia pełny zestaw atrybutów, dzięki czemu inżynier natychmiast widzi szczegóły każdej operacji.

Co jest na szali w operacjach skoncentrowanych na AI

  • Szybkość analizy przyczyn źródłowych – Zespoły mogą prześledzić awarię aż do konkretnego spanu, który zgłosił błąd, co skraca średni czas rozwiązania problemu (MTTR).
  • Widoczność kosztów – Liczba tokenów jest wyświetlana obok opóźnień, co pozwala działom finansowym wykryć niekontrolowane zużycie, zanim rachunki za chmurę drastycznie wzrosną.
  • Optymalizacja wydajności – Spany o wysokim opóźnieniu u poszczególnych agentów wskazują miejsca, w których buforowanie (caching), wybór modelu lub przeprojektowanie narzędzi mogłoby zwiększyć przepustowość.

Co dalej

Projekty zbudowane na LangChain, OpenAI SDK lub innych warstwach orkiestracji mogą przyjąć te same konwencje semantyczne dla GenAI, torując drogę do śladów (traces) przepływających między różnymi dostawcami chmury i wdrożeniami on-premise.

Organizacje muszą jedynie włączyć OpenTelemetry SDK w swoich agentach i przesyłać dane do Azure Monitor lub kolektora open-source.

Podsumowanie

OpenTelemetry dostarcza systemom wieloagentowym AI brakujący element łączący, który zamienia rozproszone logi w spójną narrację. Dzięki propagacji pojedynczego Trace ID przez heterogeniczne modele LLM, routery i wywołania narzędzi, programiści mogą lokalizować awarie, monitorować koszty i optymalizować wydajność bez konieczności wymyślania infrastruktury do śledzenia od nowa.