Łogi audytu agentów AI wymagają 12 pól: co rejestrują LangChain, CrewAI oraz cztery inne narzędzia.

Ślad wygląda jak dowód, ale nim nie jest

Wyobraź sobie agenta używającego narzędzia: przeniesienie środków finansowych, usunięcie wiersza z bazy danych lub wysłanie wiadomości. Następnie ktoś musi odpowiedzieć na jedno pytanie – czy działania agenta można udowodnić. Otwiera się wtedy ślad, który pokazuje okres czasowy, nazwę, czas rozpoczęcia oraz dane wejściowe i wyjściowe. Wygląda to jak dowód, ale w rzeczywistości jest to narzędzie pomocnicze do debugowania ubrane w szaty dowodu.

Aby zmierzyć tę luki, sklonowano sześć frameworki agentów open-source oraz specyfikacji narzędziowych na podstawie ich najnowszych komitów z dnia 4 września 2026 roku: OpenAI Agents SDK, LangChain, CrewAI, LlamaIndex, smolagents i OpenInference. Wyodrębniono pola z rekordów wywołań narzędzi w każdym projekcie i porównano je z dwunastoma obowiązkowymi polami w najnowszym formacie śledzenia działań agentów. Wynik: typowy framework obejmuje pięć z dwunastu pól potrzebnych w rekordzie audytowym, a żaden z sześciu nie posiada pola potwierdzającego możliwość modyfikacji.

Te frameworki, które jakie pola obejmują, przydają się do debugowania. Rekordy audytowe służą innym celom, a odległość pomiędzy nimi można zmierzyć.

Pięć ustaleń wynikających z pomiarów

• Wśród pięciu frameworków mediana pokrycia wynosi 5 z 12 obowiązkowych pól: smolagents ma 1, LlamaIndex 3, OpenAI Agents SDK 5, CrewAI 5, a LangChain 6.
• Wartość trust_level występuje w zeru plikach we wszystkich sześciu bazach kodu. Przeszukanie każdego pliku w Pythonie i TypeScript w każdym repozytorium nie przynosi żadnych rezultatów.
• prev_hash, previous_hash oraz hash_chain również wskazują na zero plików. Żaden framework nie łączy jednego rekordu z następnym, więc magazyn śladów można edytować później bez pozostawiania śladów.
• OpenInference, najbardziej rozbudowana specyfikacja instrumentacji w tym ekosystemie z 119 atrybutami przestrzeni nazw, nadal obejmuje tylko 8 z 12 atrybutów i nie zawiera pola potwierdzającego zmiany.
• Tylko jedno pole, timestamp, jest rejestrowane przez wszystkie pięć frameworków. agent_id, session_id oraz record_phase występują po jednym w każdym z pięciu frameworków, natomiast agent_version, outcome i trust_level nie występują w żadnym z nich.

Frameworki oferują dobrą instrumentację do debugowania oraz słabą instrumentację do dostarczania dowodów. Te dwa elementy są na tyle do siebie podobne, że zamienna metoda pozostaje niezauważona, dopóki ktoś nie zażąda dowodów. Brakujące pola nie są niczym egzotycznym – one wskazują, kto działał, pod jakimi uprawnieniami oraz czy zapis został później zmodyfikowany, na pytania, na które ślad debugowania nigdy nie musiał odpowiadać.

Sposób przeprowadzenia liczenia

Poprawki zostały wprowadzone dla poszczególnych projektów: OpenAI Agents SDK (openai-agents-python) pod adresem 89c02c8, LangChain pod adresem 0d50cbd, CrewAI pod adresem 92eb5f9, LlamaIndex pod adresem d2ac544, smolagents pod adresem 30bb116 oraz OpenInference pod adresem 479d168. Lista pól dla każdego z nich pochodziła od klasy, która rejestruje pojedyncze wezwanie narzędzia, czyli całą strukturę wezwania wraz z jego specyficznym ciężarem danych, i była pobierana z definicji klas, a nie z dokumentacji. Następnie pola te porównano z dwunastoma obowiązkowymi polami w obecnym projekcie ścieżki audytowej.

Gdy pole spełnia wymóg jedynie częściowo, otrzymywało ocenę „częściowa” wraz z podaniem przyczyny. Na przykład pole error w LangChain informuje o niepowodzeniu, ale nie rozróżnia między niepowodzeniem a czasem oczekiwania, odrzuceniem lub eskalacją sytuacji.

Zdjęcie pokazuje sam proces: sześć repozytoriów na czele, każde pole z informacją o wywołaniu narzędzia zostało wydobyte i ocenione w odniesieniu do dwunastu pól. Wartości trust_level i prev_hash wynoszą wszędzie zero.

Dwanaście pól

Miernikiem jest dokument Internet-Draft dotyczący śledzenia działań agenta, wersja 02, opublikowany przez Razę Sharifa z CyberSecAI 3 września 2026 roku. Jest to indywidualna propozycja, a nie zatwierdzony standard IETF, więc stanowi starannie przemyślaną propozycję, a nie ostateczne rozwiązanie prawnicze. Mimo to jest to najkonkretniejsza dostępna publikowana odpowiedź, a jej dwanaście obowiązkowych pól jest trudnych do zakwestionowania:

• record_id to unikalny identyfikator zapisu.
• timestamp podaje czas zdarzenia w formacie RFC 3339.
• agent_id określa instancję agenta, która podjęła działanie, a agent_version wskazuje wersję jego oprogramowania.
• session_id łączy dane o działaniu z konkretną sesją.
• action_type wykorzystuje kontrolowany słownik, a nie tekst swobodny, natomiast action_detail zawiera dane specyficzne dla danego typu działania.
• outcome może przyjmować wartości success, failure, timeout, denied lub escalated.
• trust_level wskazuje poziom uprawnień, pod którymi działał agent, od L0 do L4.
• parent_record_id odnosi się do poprzedniego rekordu w łańcuchu, a prev_hash przechowuje jego hasz SHA-256.
• record_phase informuje, czy rekord został zapisany przed, w trakcie lub po wykonaniu.

Umieść tę listę obok obiektu span i pojawi się zarys problemu. Pierwsze osiem pól to takie, których naprawdę może potrzebować debugger, natomiast ostatnie cztery mają znaczenie tylko dla audytora, i to właśnie te cztery są brakujące.

Liczby według frameworków

Liczba pól w rekordzie wywołania narzędzia wraz z stopniem pokrycia dla dwunastu frameworków:

• CrewAI (ToolUsageFinishedEvent plus BaseEvent): 25 pól, z czego 5 jest kompletnych, 3 częściowych i 4 brakujących.
• LangChain i LangSmith (RunTree 0.12.1): 20 pól, z czego 6 jest kompletnych, 1 częściowy i 5 brakujących.
• OpenAI Agents SDK 0.22.0 (SpanImpl plus FunctionSpanData): 13 pól, z czego 5 jest kompletnych, 2 częściowe i 5 brakujących.
• LlamaIndex (SimpleSpan plus BaseEvent): 10 pól, z których 3 są kompletne, 1 częściowe, a 8 nieobecne.
• smolagents 1.26.0 (Timing plus TokenUsage): 6 pól, z których 1 jest kompletne, żadne nie są częściowe, a 11 nieobecne.
• OpenInference semantic conventions definiują 119 przestrzeni nazw pól typu span (odrębne stałe nazw atrybutów z kropkami w komitcie 479d168, pomijając kolejne 43, które są wartościami z typu enum), przy czym ocenia się 8 jako kompletnych, 1 jako częściowe i 3 jako nieobecne.

Liczba surowych pól nie przewiduje możliwości przeprowadzenia audytu. CrewAI rejestruje najwięcej pól, ale spełnia mniej wymagań niż LangChain, ponieważ wiele z jego dwudziestu pięciu dotyczy kontekstu zespołu, takich jak agent_role, from_task, plan_step_number i delegations. Są one przydatne, ale nadal nie odpowiadają na żadne pytania audytowe. Bogactwo narzędzi pomiarowych i odpowiedniość jako dowodów ledwo korelują ze sobą.

Wykres jasno to pokazuje: CrewAI posiada więcej pól niż jakikolwiek inny framework, jednak spełnia mniej wymagań niż LangChain, ponieważ większość jego dodatkowych elementów to kontekst zespołu, a nie dowody.

Jedna rzecz wyróżnia CrewAI. Wydziela on ToolUsageStartedEvent oraz ToolUsageFinishedEvent jako odrębne klasy, dzięki czemu posiada własny prawdziwy record_phase – zapis istniejący przed uruchomieniem narzędzia. Ma to większe znaczenie, niż się wydaje, ponieważ log napisany wyłącznie po fakcie może pokazać, że coś się wydarzyło, ale nie może udowodnić, że zostało to wcześniej zatwierdzone.

Czego nie rejestruje żaden framework

Cztery z dwunastu pól brakuje we wszystkich pięciu frameworkach, a dwa z nich pozostają nieobecne nawet przy uwzględnieniu specyfikacji instrumentacji.

• trust_level nie występuje w żadnym pliku z żadnego z sześciu repozytoriów. Bez niego nic nie rejestruje uprawnień, pod którymi działa agent, więc ślad nie może odróżnić działania dozwolonego od zabronionego.
• prev_hash występuje w zeru plikach, podobnie jak previous_hash i hash_chain. Nic nie łączy rekordów, a magazyn śladów to zwykła baza danych, której wiersze mogą być zmieniane.
• agent_version brakuje we wszystkich pięciu frameworkach. Istnieje on tylko w OpenInference jako odzwierciedlenie gen_ai.agent.version z OpenTelemetry – wartości, którą można ustawić, ale która, zgodnie z tą analizą, praktycznie nigdy nie jest ustawiana przez same frameworki.
• outcome jako kategoria klasyfikacyjna nie otrzymuje pełnej oceny od żadnego frameworku. Wszystkie posiadają pole błędu, jednak żadne nie rozróżnia przypadków odrzucenia od nieudanych, co jest kluczowym kryterium dla audytorów.

Wyszukiwania słów non_repudiation i pre_execution również nie przynoszą żadnych wyników.

Dlaczego te pola są brakujące

Te narzędzia zostały zaprojektowane do rozwiązywania innego problemu. Łączny zapis działań pomaga inżynierowi odkryć, dlaczego coś działało wolno lub błędnie, a input, output, duration oraz wskaźnik rodzica w dużej mierze wystarczają do tego celu. Dowody muszą wytrzymać próbę krytyki ze strony przeciwnika, w tym osoby kontrolującej dziennik zdarzeń, a żadne z tych systemów nie zostało stworzone z myślą o takim zagrożeniu. Te luki nie są błędem. Nikt nie spodziewał się, że zapisy działań będą pełnić funkcję dowodów, dopóki nie nadszedł ten rok.

Najsilniejszy argument przeciwny

Czy OpenTelemetry może wypełnić tę lukę? Częściowo. OpenInference obejmuje 8 z 12 przypadków, będąc najlepszym wynikiem w tym zestawieniu, a konwencje GenAI w OpenTelemetry definiują gen_ai.agent.id i gen_ai.agent.version, co teoretycznie eliminuje problem identyfikacji. Gdyby były one stosowane konsekwentnie, sama adopcja rozwiązałaby cztery z dwunastu przypadków bez dodatkowych działań.

Jednak dwa najtrudniejsze wymagania pozostają nierozwiązane. Dowód modyfikacji nie może być dodany do elementu jako atrybut, ponieważ należy do sklepu, a nie do rekordu. Łańcuch haszów ma sens tylko wtedy, gdy jest zapisany w miejscu, gdzie nikt nie może go przepisać. A record_phase wymaga rekordu wygenerowanego przed wykonaniem akcji, co jest decyzją architektoniczną dotyczącą momentu wykonywania, a nie polem dodawanym później. Żadne z tych rozwiązań nie odpowiada konwencjom semantycznym.

Ograniczenia pomiaru

Liczba jest przydatna tylko wtedy, gdy jej wartości są wiarygodne, dlatego te zastrzeżenia są istotne:

• Chodzi tu o analizę statyczną, a nie o rejestrowanie zachowań w czasie rzeczywistym. Zliczono pola zdefiniowane przez klasy. Sześć agentów nie zostało uruchomionych wraz z ich wygenerowanymi danymi do porównania, a framework może wypełniać pola za pomocą mechanizmu rozszerzeń, który nie został prześledzony.
• metadata, tags oraz extra to mechanizmy awaryjne i zostały uznane za nieobecne. Większość tych frameworków przyjmuje dowolne klucze, więc zdeterminowana grupa mogłaby przechowywać łańcuch hashów w polu extra. Liczba ta odnosi się do wartości domyślnych, a nie do maksymalnych ograniczeń.
• Najbliższym odpowiednikiem podpisu nie jest żaden konkretny element. OpenInference definiuje message_content.signature, ale jego dokumentacja opisuje nieprzejrzystą wartość wydaną przez dostawcę, przechowywaną w takiej formie, w jakiej została otrzymana, podobnie jak thoughtSignature w Gemini. Służy ona do potwierdzenia treści rozumowania modelu, a nie integralności zapisu, przy czym tylko dostawca może ją sprawdzić. Uznanie jej za nieobecną w celu uzyskania dowodu na manipulacje było celowe.
• Referencja z dwunastoma polami to jeden projekt jednego autora z wersją 02, więc nie została zatwierdzona, a ludzie będą uzasadnione kwestionować wartość trust_level. Jeśli lista wymagań się zmieni, zmienią się również liczby pokrycia.
• Sześć projektów to nie cały ekosystem. Nie uwzględniono Pydantic AI, Semantic Kernel, AutoGen oraz platform komercyjnych.
• Obecność nie mówi wiele o jakości. timestamp został uznany za spełniony we wszystkich pięciu przypadkach, jednak zwykły datetime.now() bez informacji o strefie czasowej lub bez odniesienia do punktu odniesienia jest znacznie słabszy od timestampu zgodnego z RFC 3161.

To nie może określić, czy cokolwiek z tego ma znaczenie dla danego systemu. Agent, który czyta dokumenty i tworzy tekst, dobrze poradzi sobie z śladem debugowania, natomiast rekordy klasy audytowej byłyby przesadą. Luka ta stanowi problem tylko wtedy, gdy działania agenta mają konsekwencje, które ktoś może później zakwestionować.

Trzy zmiany według kolejności korzyści

1. Zapisz rekord przed wykonaniem. Oznacza to zrobienie tego przed wywołaniem, a nie po nim, z odnotowaniem ID rekordu, daty i godziny, ID agenta oraz wersji, działania, które ma zostać uruchomione, oraz uprawnień za nim stojących. Szablonem jest podział na „started/finished” w CrewAI, natomiast inne rozwiązania wymagają ręcznego utworzenia takiego podziału.
2. Łącz rekordy w pamięć dołączaną tylko na końcu. Haszowanie poprzedniego rekordu za pomocą SHA-256 jest praktycznie bezkosztowe. Ważne jest miejsce, w którym rekord jest zapisywany, a nie sam hash.
3. Daj outcome słownictwo. Dzięki pięciu wartościom (success, failure, timeout, denied, escalated) różnica między błędem narzędzia a odmową staje się możliwa do zapytania i nie pozostaje ukryta w ciągu znaków.

Nie jest potrzebny żaden nowy framework – wystarczy około dwustu linijek kodu dodanych do istniejącego. Odzwierciedla to wzorzec niezauważanych awarii agentów, których nie dostrzegają panele kontrolne, gdyż brak jakichkolwiek zapisów sprawia wrażenie prawidłowego funkcjonowania.

Szybkie odpowiedzi

W czym różni się ślad działania agenta od dziennika audytowego? Ślady działania są tworzone dla inżynierów, którzy chcą później wyjaśnić zachowanie agenta, przy założeniu uczciwości osoby ich tworzącej. Dzienniki audytowe natomiast służą stronom w sporze i muszą potwierdzić tożsamość, uprawnienia oraz integralność danych, czyli określić, kto działał, z jakimi uprawnieniami oraz czy dane zostały później zmienione. W porównaniu frameworki zawierają od 6 do 25 pól z danymi o śladach działania, ale spełniają jedynie średnio 5 wymagań dotyczących dzienników audytowych.

Czy ślady LangChain można przygotować do audytu? Tylko częściowo, poprzez budowanie rozwiązań wokół tej ramy zamiast jej konfigurowania. Funkcja RunTree z LangSmith dostarcza bezpośrednio 6 z 12 wymaganych danych, w tym session_id i parent_run_id. Nadal trzeba dodać informacje o tożsamości agenta i wersji, która została użyta, ustaloną listę wartości wyników, poziom zaufania, zapis przed wykonaniem oraz łańcuch hashów przechowywany wyłącznie w trybie dodawania nowych danych. Dane niestandardowe mogą być umieszczone w polu extra, choć nic nie wypełnia go automatycznie.

Czy OpenTelemetry rozwiązuje ten problem? Obejmuje ono kwestię tożsamości. Dowody na ingerencje oraz nagrywanie przed wykonaniem pozostają nierozwiązane, ponieważ zależą one od czasu i miejsca zapisu danych, a nie od atrybutów, które posiada dany element.

Która platforma jest dziś najbardziej przyjazna audytom? LangChain za pośrednictwem LangSmith obejmuje najwięcej przypadków – 6 z 12 – podczas gdy CrewAI oferuje unikalny rzeczywisty zapis przed wykonaniem wraz z pierwszoklasowym agent_id. Żadna z nich nie jest gotowa do przeprowadzenia audytów. Jeśli możliwość audytowania jest bezwzględnie konieczna, należy osobno stworzyć warstwę dowodową i traktować ślady pozostawione przez platformę jako surowy materiał wejściowy.

Czy łańcuch haszów jest przesadą dla narzędzia wewnętrznego? Zazwyczaj tak. Decydującym kryterium jest to, czy ktoś poza zespołem mógłby kiedykolwiek polegać na tym logu – na przykład klient, kontrahent, ubezpieczyciel lub osoba przeprowadzająca analizę incydentu o rzeczywistym znaczeniu. Jeśli nie, wystarczy dobry zapis śledzenia. Jeśli jednak tak, dodanie łańcucha teraz kosztuje znacznie mniej niż jego odtworzenie później.

Debaty na temat nadzoru agentów trwają już od miesięcy. Liczenie rozstrzyga część pytania, ponieważ nazwa pola albo znajduje się w klasie, albo nie.

Literatura pokrewna

• Gdy panel jest zielony, a agent błędnie wykrywa: śledzenie stanu: Jak błędy agentów ukrywają się w stanie przekazywanym pomiędzy prawidłowymi krokami oraz co musi zostać uchwycone poprzez śledzenie, ograniczenia w czasie wykonywania, zapisy routingu i oceny.
• Praktyczne notatki: programowanie agenta: rozbijanie pętli agenta: Szczegółowy przewodnik po Praktycznych notatkach: programowanie agenta: rozbijanie pętli agenta: kontrakty, sprawdzania oraz gotowe fragmenty kodu dla zespołów wdrażających ten wzorzec.

Minimalna platforma do eksperymentowania dla agentów AI: testy A/B i testy cieniowe: Jak zdecydować, czy wersja B agenta powinna zastąpić wersję A, wykorzystując definicje pipeline’ów, lokalne przypisywanie zadań, wydarzenia ekspozycji, ślady działania, ocenę w środowisku sandbox, testy cieniowe oraz zasady bezpieczeństwa.

Notatki praktyczne: Agent nigdy nie użył narzędzia do zwrotów pieniędzy. Dwa z trzech przypadków: Szczegółowy przewodnik po notatkach praktycznych: Agent nigdy nie użył narzędzia do zwrotów pieniędzy. Dwa z trzech przypadków: umowy, sprawdzania oraz miejsca na kod do wstawienia dla zespołów wdrażających ten wzorzec.

Notatki praktyczne: Sprytne sposoby na poprawę odpowiedzi agentów AI w środowisku produkcyjnym: Szczegółowy przewodnik po Notatkach praktycznych: Sprytne sposoby na poprawę odpowiedzi agentów AI w środowisku produkcyjnym – umowy, sprawdzenia oraz gotowe fragmenty kodu przeznaczone dla zespołów wdrażających ten model.

Gdy agent AI zawodzi, kogo winić? Śledzenie przyczyn awarii: Dlaczego stwierdzenie „model wytworzył halucynację” jest niewystarczające: przegląd procesu awarii agenta, od określenia intencji i wyszukiwania informacji po używanie narzędzi, próby ponowne oraz śledzenie przyczyn, oraz co należy obserwować.