Tracing agentów AI z OpenTelemetry

Bo zachowuje przenośność traces dokładnie wtedy, gdy narzędzia wokół agentów zmieniają się najszybciej. Z konwencjami GenAI OpenTelemetry spany agentów idą wspólnym, otwartym schematem i lądują w tym samym backendzie co reszta usług, więc masz jeden widok całego stacku zamiast odizolowanego silosu agenta. SDK dostawcy z pewnością przechwyci bogate traces, a te dobre emitują lub czytają standard, ale budowanie wyłącznie na własnościowym formacie znaczy, że Twoja historia i dashboardy są zakładnikiem roadmapy i cennika jednego dostawcy. Pragmatyczna postawa to instrumentować najpierw pod otwartą konwencję, a dedykowane platformy traktować jako wartość dodaną na wierzchu — session replay, dashboardy agentów, time-travel debugging — a nie jako fundament. Wtedy możesz później zmienić lub dodać narzędzie bez reinstrumentacji agentów, co jest realnym ryzykiem w dziedzinie, gdzie dzisiejsza wiodąca platforma może nie być tą z przyszłego roku. Przenośność tanio wybrać teraz, drogo doszywać później.

Każdy span powinien zapisać dość, by odtworzyć i rozliczyć jeden krok przebiegu, czyli minimum sześć rzeczy: typ operacji (wywołanie modelu, narzędzia, retrieval lub krok podagenta), wejścia i wyjścia na odpowiednim poziomie szczegółu, liczbę tokenów, koszt pieniężny, opóźnienie oraz status mówiący, czy się powiodło. Przechwytywanie wejść i wyjść wymaga osądu — chcesz dość, by debugować, bez logowania sekretów czy ogromnych blobów, więc zawężaj lub redaguj wrażliwe pola i przycinaj, gdzie trzeba. Typ operacji pozwala wyświetlić przebieg jako czytelne drzewo; tokeny i koszt zamieniają ten sam span w zapis FinOps; opóźnienie i status czynią go sygnałem wydajności i awarii. Czytane z góry na dół, dobrze uformowane spany odtwarzają dokładnie, jak agent rozumował i działał, dlatego dyscyplina spójnego dołączania tych atrybutów liczy się bardziej niż konkretne narzędzie. Span bez tokenów nie da się wycenić; bez statusu nie da się triażować.

W praktyce nie, bo tracing jest tani względem tego, co dominuje opóźnienie i koszt agenta: inferencji modelu. Span to niewielka ilość ustrukturyzowanych metadanych; inferencja to setki milisekund i realne pieniądze, więc względny narzut zapisania kroku jest pomijalny. Dwie standardowe techniki tak go utrzymują. Asynchroniczny eksport przenosi pracę wysyłki spanów poza ścieżkę gorącą, więc agent nie czeka na backend telemetrii, a sampling pozwala zapisywać pełny szczegół na reprezentatywnej części przebiegów, wciąż licząc każdy przebieg do metryk zagregowanych. Błędem jest pominąć tracing dla oszczędności narzutu, a potem lecieć na ślepo, gdy agent się zapętla, zawodzi lub przepala budżet — koszt niewidzenia, co się stało, przyćmiewa koszt zapisu. Traktuj tracing jako część agenta, nie opcjonalny dodatek, i dostrajaj sampling oraz retencję do swojego wolumenu, a nie wyłączaj go.

Span to zapis pojedynczej operacji — jednego wywołania modelu, jednego wywołania narzędzia — z czasem startu, czasem trwania, atrybutami i statusem. Trace to drzewo spanów, które razem reprezentują jeden kompletny przebieg agenta, powiązane relacjami rodzic–dziecko, byś widział, że to wywołanie narzędzia stało się wewnątrz tego kroku planowania wewnątrz tego podagenta. Log z kolei to pojedynczy komunikat ze znacznikiem czasu, przydatny do doraźnego szczegółu, ale płaski: strumień linii bez struktury pokazującej, jak kroki się zagnieżdżają i wiążą. Dla agentów to trace jest jednostką, która się liczy, bo ciekawe awarie dotyczą sekwencji i przyczynowości — agent pobrał zatruty dokument, potem wykonał nietypowe wywołanie narzędzia — co drzewo ujmuje, a strumień logów zaciemnia. W praktyce wciąż emitujesz logi, ale dołączasz je do właściwego spanu, by dziedziczyły jego kontekst. Myśl o spanach jak o krokach, o trace jak o całej historii, a o logach jak o adnotacjach na pojedynczych krokach.