Журнали аудиту AI-агентів потребують 12 полів: що фіксують LangChain, CrewAI та ще чотири інструменти.

Слід схожий на доказ, але не є ним

Уявіть собі агента, який використовує певний інструмент: переказ коштів, видалення рядка з бази даних чи надсилання повідомлення. Після цього хтось мусить відповісти на одне запитання — чи можна підтвердити дії агента. Відкривається слід, і він показує період часу з назвою, часом початку, вхідними та вихідними даними. Це схоже на доказ, але насправді це лише засіб для діагностики, одягнений у оболонку доказу.

Щоб виміряти розбіжність, було скопійовано шість фреймворків агентів з відкритим кодом та специфікацій інструментів на їхніх останніх версіях від 4 вересня 2026 року: OpenAI Agents SDK, LangChain, CrewAI, LlamaIndex, smolagents та OpenInference. Були вилучені поля з записів викликів інструментів кожного проекту та порівняні з дванадцятьма обов’язковими полями у найновішому форматі журналу аудиту агентів. Основний висновок: типовий фреймворк охоплює п’ять із дванадцяти полів, необхідних для запису аудиту, причому жоден із шести не має окремого поля для підтвердження недоторканості даних.

Ті фреймворки, які охоплюють потрібні поля, підходять для відлагодження. Записи аудиту виконують іншу функцію, і відстань між ними можна виміряти.

П’ять висновків з цього підрахунку

• У всіх п’яти фреймворках середній рівень охоплення становить 5 із 12 обов’язкових полів: smolagents — 1, LlamaIndex — 3, OpenAI Agents SDK — 5, CrewAI — 5, а LangChain — 6.
• Рядок trust_level зустрічається у нульох файлах у всіх шести кодових базах. Пошук у кожному файлі на Python та TypeScript у кожному репозиторії нічого не дає.
• prev_hash, previous_hash та hash_chain також вказують на нульох файлів. Жодна фреймворк-система не пов’язує одну запису з наступною, тому базу слідування можна змінювати пізніше без залишення слідів.
• OpenInference, найбільш повний специфікатор інструментування в екосистемі з 119 атрибутами просторів імен, все одно охоплює лише 8 з 12 атрибутів та не містить поля для підтвердження недоторканості даних.
• Лише одне поле, timestamp, фіксується усіма п’ятьма фреймворками. agent_id, session_id та record_phase зустрічаються по одному у кожному з п’яти фреймворків, а agent_version, outcome та trust_level — жодного разу.

Фреймворки мають хороші інструменти для дебагування та слабкі інструменти для отримання доказів. Ці два підходи настільки схожі між собою, що заміна залишається непоміченою, доки хтось не попросить доказів. Відсутні поля не є чимось екзотичним – вони визначають, хто діяв, під чиєю повноважністю, та чи змінювався запис пізніше, на що слід дебагування ніколи не мусив відповідати.

Як було здійснено підрахунок

Були виправлені комітти для кожного проекту: OpenAI Agents SDK (openai-agents-python) під ідентифікатором 89c02c8, LangChain під 0d50cbd, CrewAI під 92eb5f9, LlamaIndex під d2ac544, smolagents під 30bb116 та OpenInference під 479d168. Список полів для кожного з них був отриманий з класу, який фіксує кожен виклик інструменту, тобто повний обсяг даних разом із специфічним для інструменту навантаженням; цей список було отримано з визначень класів, а не з документації. Після цього поля порівнювалися з дванадцятьма обов’язковими полями у поточній версії проекту аудит-трейлу.

Якщо поле частково відповідає вимогам, йому присвоювався статус «часткове відповідність» із зазначенням причини. Наприклад, у LangChain поле error повідомляє про те, що щось зазнало невдачі, але не розрізняє невдачу від тайм-ауту, відмови чи ескалації проблеми.

На знімку показано сам процес виконання: шість репозиторіїв у верхній частині, кожне поле виклику інструменту було вилучено та оцінено за дванадцятьма полями. Значення trust_level та prev_hash скрізь дорівнюють нулю.

Дванадцять полів

Орієнтиром є документ Internet-Draft з описом аудит-сліду агента, ревізія 02, який Раза Шаріф з CyberSecAI опублікував 3 вересня 2026 року. Це індивідуальна пропозиція, а не затверджений стандарт IETF, тому вона вважається ретельно обґрунтованою пропозицією, а не остаточним законом. Проте це найбільш конкретна опублікована відповідь, і її дванадцять обов’язкових полів важко оскаржити:

• record_id — унікальний ідентифікатор запису.
• timestamp — час події у форматі RFC 3339.
• agent_id вказує ідентифікатор екземпляра агента, який виконував дію, а agent_version — версію його програмного забезпечення.
• session_id пов’язує дію з певною сесією.
• action_type використовує контрольований словниковий запас, а не вільний текст, тоді як action_detail містить дані, специфічні для цього типу дії.
• outcome може бути одним із значень: успіх, невдача, тайм-аут, відмова чи підвищення рівня серйозності.
• trust_level вказує рівень авторитету, за яким працював агент, від L0 до L4.
• parent_record_id вказує на попередній запис у ланцюзі, а prev_hash містить його хеш SHA-256.
• record_phase визначає, чи був запис створений до, під час чи після виконання дії.

Якщо розмістити цей список поруч із об’єктом span, з’явиться огляд проблеми. Перші вісім полів — це ті, які може знадобитися дебагеру, тоді як останні чотири мають значення лише для аудитора, і саме ці чотири є відсутніми.

Кількість полів за фреймворком

Кількість полів у записі виклику інструменту та ступінь їх покриття серед дванадцяти:

• CrewAI (ToolUsageFinishedEvent плюс BaseEvent): 25 полів, з них 5 повних, 3 часткових та 4 відсутніх.
• LangChain та LangSmith (RunTree 0.12.1): 20 полів, з них 6 повних, 1 частковий та 5 відсутніх.
• OpenAI Agents SDK 0.22.0 (SpanImpl плюс FunctionSpanData): 13 полів, з них 5 повних, 2 часткових та 5 відсутніх.
• LlamaIndex (SimpleSpan плюс BaseEvent): 10 полів, з яких 3 є повними, 1 — частковим, а 8 відсутніх.
• smolagents 1.26.0 (Timing плюс TokenUsage): 6 полів, з яких 1 є повним, жодного часткового та 11 відсутніх.
• OpenInference semantic conventions визначають 119 атрибутів span у просторі імен (окремі константи імен атрибутів у форматі з крапками при коміті 479d168, без урахування ще 43, які є значеннями з типу enum), причому 8 є повними, 1 — частковим, а 3 відсутніх.

Кількість сирих полів не є показником можливості аудиту. CrewAI фіксує найбільшу кількість полів, але задовольняє менше вимог, ніж LangChain, оскільки більшість з його двадцяти п’яти поля описують контекст команди, такі як agent_role, from_task, plan_step_number та delegations. Вони корисні, але все одно не відповідають на жодні запитання аудиту. Рівень наявності інструментів та придатність даних як доказів ледве корелюють.

Діаграма чітко це показує: CrewAI має більше полів, ніж будь-яка інша платформа, проте задовольняє менше вимог, ніж LangChain, оскільки більшість його додаткових елементів стосуються контексту команди, а не доказів.

Одна річ відрізняє CrewAI. Він генерує ToolUsageStartedEvent та ToolUsageFinishedEvent як окремі класи, тож у нього є справжній record_phase — запис, який існує ще до запуску інструменту. Це має більше значення, ніж здається, адже журнал, створений виключно після події, може показати, що щось сталося, але не може підтвердити, що це було схвалено заздалегідь.

Що не фіксується жодною фреймворком

Чотири з дванадцяти полів відсутні у всіх п’яти фреймворках, причому два з них залишаються відсутніми навіть при врахуванні специфікації інструментування.

• trust_level не зустрічається в жодному файлі жодного з шести репозиторіїв. Без нього ніщо не фіксує повноваження, під якими діяв агент, тому трекінг не може відрізнити дозволену дію від забороненої.
• prev_hash зустрічається у нульох файлах, так само як і previous_hash та hash_chain. Жодні зв’язки між записами відсутні, а сховище слідів — це звичайна база даних, рядки в якій можна змінювати.
• agent_version відсутній у всіх п’яти фреймворках. Він існує лише в OpenInference як копія поля gen_ai.agent.version з OpenTelemetry; його можна встановити, але, судячи з цього аналізу, самі фреймворки практично ніколи його не встановлюють.
• Поле outcome у форматі класифікації не отримує повного балу в жодному з фреймворків. У всіх є поле з помилкою, проте жоден з них не розрізняє випадки відмови та невдачі, що є найважливішим критерієм для аудитора.

Пошук за полями non_repudiation та pre_execution також не дає результатів — жодних файлів знайдено не було.

Чому ці поля відсутні

Ці інструменти були створені для іншої проблеми. Журнал подій допомагає інженеру з’ясувати, чому щось працює повільно або неправильно, і для цього input, output, duration та вказівник на батьківський об’єкт майже достатні. Докази мають витримати перевірку з боку супротивника, включаючи того, хто контролює журнал, проте жодна з цих систем не була створена з урахуванням такої загрози. Ці прогалини — не недбалість. Ніхто не очікував, що журнали подій зможуть виконувати функцію доказів, аж до цього року.

Найсильніший аргумент проти

Чи може OpenTelemetry заповнити цю прогалину? Частково. OpenInference охоплює 8 з 12 аспектів, що є найкращим результатом у цьому наборі, а конвенції GenAI від OpenTelemetry визначають gen_ai.agent.id та gen_ai.agent.version, що теоретично усуває проблему ідентифікації. Якщо їх послідовно застосовувати, саме впровадження дозволить вирішити чотири з дванадцяти проблем без додаткових зусиль.

Проте дві найскладніші вимоги залишаються нерозв’язаними. Докази пошкодження не можна додати до елемента як атрибут, оскільки вони належать до сховища, а не до запису. Ланцюг хешів має сенс лише тоді, коли він записується там, де автор не може його переписати. А record_phase потребує запису запису перед виконанням дії, що є архітектурним вибором щодо часу виконання, а не полем, яке додається пізніше. Жоден з цих варіантів не відповідає семантичним конвенціям.

Обмеження вимірювання

Число є корисним лише тоді, коли його значення є достовірними, тому важливі всі застереження:

• Це статичний аналіз, а не запис під час виконання. Було підраховано поля, визначені класами. Шість агентів не було запущено з їхніми відповідними навантаженнями для порівняння, а фреймворк може заповнювати поля за допомогою механізму розширень, який не було простежено.

metadata, tags та extra є запасними варіантами та були оцінені як відсутні. Більшість цих фреймворків дозволяють використовувати довільні ключі, тож рішуча команда могла б зберігати ланцюг хешів у полі extra. Цей показник відображає стандартні значення, а не максимальні обмеження.

Найближчим аналогом підпису немає жодного конкретного елемента. OpenInference визначає message_content.signature, але його документація описує непрозоре значення, надане постачальником, яке зберігається у такому вигляді, в якому його отримали, подібно до thoughtSignature у Gemini. Воно підтверджує зміст міркувань моделі, а не цілісність запису, і лише постачальник може його перевірити. Навмисно було оцінити його як відсутній для підтвердження цілісності даних.

Довідник із дванадцятьма полями — це лише чернетка одного автора у версії 02, тому він ще не затверджений, і люди цілком можуть заперечувати значення trust_level. Якщо змінюється список вимог, змінюються також показники охоплення.

Шість проектів — це не весь екосистема. Pydantic AI, Semantic Kernel, AutoGen та комерційні платформи не були враховані.

Наявність певних елементів мало що говорить про їхню якість. timestamp вважається задоволеним у всіх п’яти випадках, проте звичайний datetime.now() без вказання часової зони чи без посилання на орієнтир є значно слабкішим за таймстамп за стандартом RFC 3161.

Це не може визначити, чи має щось із цього значення для конкретної системи. Агенту, який читає документи та складає текст, буде корисною система відстеження помилок, тоді як записи аудитного рівня будуть зайвими. Розбіжності стають проблемою лише тоді, коли дії агента мають наслідки, які хтось може згодом оскаржити.

Три зміни в порядку ефективності

1. Запишіть запис перед виконанням. Це означає робити це до виклику, а не після, вказуючи ID запису, час створення, ID агента та версію, дію, яка має бути виконана, та повноваження, що стоять за нею. Формат розділення на «початок/кінець», використовуваний у CrewAI, є шаблоном, а інші системи повинні створювати його вручну.
2. Об’єднайте записи у сховище з можливістю лише додавання даних. Гешування попереднього запису за допомогою SHA-256 майже не коштує зусиль. Важливим є місце зберігання, а не сам геш.
3. Надайте outcome словниковий запас. За допомогою п’яти значень (успіх, невдача, тайм-аут, відмова, підвищення рівня) різниця між помилкою інструменту та відмовою стає можливою до пошуку та не залишається прихованою у рядку тексту.

Не потрібна жодна нова система — достатньо приблизно двохсот рядків до існуючої. Вона відображає закономірності безшумних збоїв агентів, які залишаються непоміченими дашбордами, коли відсутність даних видається ознакою належного функціонування, оскільки нічого не було зафіксовано.

Швидкі відповіді

У чому різниця між треками агента та журналом аудиту? Треки створюються для інженерів, які хочуть пояснити поведінку агента згодом, і вони передбачають чесного автора. Журнали аудиту створюються для сторін, які між собою сперечаються, і мають підтверджувати ідентичність, повноваження та надійність, тобто хто діяв, з якими дозволами та чи змінювався запис з того часу. Для порівняння, кожна з систем містить від 6 до 25 полів треків, проте задовольняє лише середнє значення у 5 вимог аудиту.

Чи можна зробити трекування LangChain готовим до аудиту? Лише частково, шляхом створення рішень на основі цієї фреймворк-структури замість її налаштування. Функція RunTree від LangSmith безпосередньо надає 6 з 12 необхідних елементів, зокрема session_id та parent_run_id. Ще потрібно додати інформацію про те, хто є агентом та яка версія використовувалась, фіксований набір значень результатів, рівень довіри, запис, створений перед виконанням, та ланцюг хешів, який зберігається у сховищі з можливістю лише додавання даних. Додаткові дані можна включити у поле extra, проте ніщо не заповнює його автоматично.

Чи вирішує цю проблему OpenTelemetry? Він покриває частину, пов’язану з ідентифікацією. Питання доказів втручання та запису перед виконанням залишаються нерозв’язаними, оскільки вони залежать від часу та місця створення записів, а не від того, які атрибути містить спан.

Яка фреймворк сьогодні найбільш придатна для аудиту? LangChain через LangSmith покриває найбільше функцій — 6 з 12, тоді як CrewAI унікально пропонує справжній запис перед виконанням та першокласний agent_id. Жоден з них не є готовим до аудиту. Якщо можливість аудиту є обов’язковою, створіть окремий шар доказів та розглядайте записи фреймворку як сирі дані.

Чи є ланцюг хешів зайвим для внутрішнього інструменту? Зазвичай так. Вирішальним критерієм є те, чи може хтось поза командою покладатися на ці записи — наприклад, клієнт, контрагент, страхова компанія чи особа, яка переглядає інциденти з великими наслідками. Якщо ні, достатнім буде нормальний запис. Якщо так, додавання ланцюга зараз коштуватиме значно менше, ніж його відновлення пізніше.

Дискусії щодо нагляду за агентами тривають вже кілька місяців. Підрахунок допомагає вирішити частину проблеми, адже ім’я поля або належить до класу, або ні.

Пов’язані матеріали

• Коли панель керування зелена, а агент помиляється: відстеження стану: як збої агента приховуються у стані, який передається між коректними кроками, та що потрібно фіксувати за допомогою відстеження, обмежень під час виконання, записів маршрутизації та оцінок.
• Практичні нотатки: програмування агента: розв’язання проблем з циклами агента: детальний посібник з програмування агента та розв’язання проблем з циклами: контракти, перевірки та готові фрагменти коду для команд, які використовують цю схему.

Мінімальна життєздатна платформа для експериментування з AI-агентами: тести типу A/B та тіньові запуски: Як вирішити, чи слід замінити версію A на версію B агента, використовуючи визначення конвеєрів обробки даних, локальне призначення завдань, події експозиції, трекінг даних, оцінку в сендбоксі, тіньові запуски та механізми контролю.

Практичні нотатки: Агент ніколи не викликав інструмент для повернення грошей. Два з трьох: Детальний огляд практичних нотаток „Агент ніколи не викликав інструмент для повернення грошей. Два з трьох“: контракти, перевірки та шаблони коду для команд, які використовують цю схему.

Практичні нотатки: розумні способи покращення відповідей AI-агентів у продакшені: Детальний огляд Практичних нотаток: розумні способи покращення відповідей AI-агентів у продакшені – контракти, перевірки та готові фрагменти коду для команд, які впроваджують цю модель.

Коли AI-агент зазнає невдачі – кого звинувачувати? Відстеження причин невдачі: Чому твердження «модель створила халюцинацію» є недостатнім: пошук причин невдачі агента від визначення наміру та пошуку інформації до використання інструментів, повторних спроб та відстеження, а також те, що потрібно спостерігати.