Для журналов аудита ИИ-агентов необходимо 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 «agent audit trail», ревизия 02, опубликованный Разой Шарифом из CyberSecAI 3 сентября 2026 года. Это индивидуальное предложение, а не утвержденный стандарт IETF, поэтому оно считается тщательно обоснованным предложением, а не окончательным законом. Тем не менее это наиболее конкретный опубликованный ответ, и его двенадцать обязательных полей трудно оспорить:

• record_id — уникальный идентификатор записи.
• timestamp — время события в формате RFC 3339.
• agent_id указывает на экземпляр агента, совершивший действие, а agent_version — на версию его программного обеспечения.
• session_id связывает действие с сессией.
• action_type использует контролируемый словарь терминов, а не свободный текст; action_detail содержит данные, специфичные для данного типа действия.
• outcome может быть значением success, failure, timeout, denied или escalated.
• 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() без указания часового пояса или без связи с опорными данными значительно слабее по качеству, чем timestamp по стандарту 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. Однако ни один из них не готов к аудиту. Если возможность аудита является обязательной, необходимо отдельно создать слой доказательств и рассматривать трассировку действий фреймворка как сырой входной материал.

Является ли цепочка хэшей избыточной для внутреннего инструмента? Как правило, да. Решающим критерием является вопрос о том, может ли кто-то вне команды полагаться на эти логи — например, клиент, контрагент, страховая компания или участники расследования серьезных инцидентов. Если нет, достаточна обычная трассировка действий. Если же есть такая возможность, добавление цепочки хэшей сейчас обойдется значительно дешевле, чем ее воссоздание позже.

Дискуссии о контроле за агентами уже несколько месяцев ведутся. Подсчёт помогает решить часть вопроса, поскольку имя поля либо присутствует в классе, либо нет.

Связанные статьи

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

Минимально жизнеспособная платформа для экспериментов с ИИ-агентами: тесты типа A/B и тестирование в тени: Как решить, следует ли заменить версию агента B на версию A, с использованием определений пайплайнов, локального назначения задач, событий воздействия, трассировок, оценки в песочнице, тестирования в тени и механизмов контроля.

Практические заметки: агент никогда не вызывал инструмент возврата средств. Два из трех: Пошаговое руководство по использованию практических заметок «Агент никогда не вызывал инструмент возврата средств. Два из трех»: контракты, проверки и готовые блоки кода для команд, реализующих эту схему.

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

Когда ИИ-агент терпит неудачу: кого винить? Анализ причин сбоев: Почему объяснение «модель сгенерировала ошибочную информацию» недостаточно: пошаговый анализ цепочки сбоев ИИ-агента от определения цели и поиска данных до использования инструментов, повторных попыток и отслеживания событий, а также что следует наблюдать.