Аудит логов автономного агента: что писать и чем читать

Автономный агент отличается от чат-бота одним: он не отвечает текстом, а совершает действия. Вызывает API, пишет в базу, отправляет письма, оформляет заказы, запускает код. Пока всё идёт по плану, это удобно. Когда агент удаляет не ту таблицу, покупает не тот товар или попадается на инъекцию в чужом письме — единственный способ понять, что произошло, это разобрать цепочку его решений по логам. Проблема в том, что стандартные логи приложения показывают что случилось на уровне HTTP-запросов, но не почему агент так решил.

Почему логи агента — отдельная задача

Обычное веб-приложение детерминировано: на один вход — один предсказуемый выход. Агент недетерминирован. На один и тот же запрос он может выбрать разные инструменты, разное число шагов и разные формулировки. Поэтому строчка «POST /api/orders 200 OK» ничего не объясняет: она не показывает, какой промпт увидела модель, что она рассудила, почему выбрала именно этот инструмент и какими были аргументы вызова.

Аудит агента — это восстановление всей траектории: от исходной задачи через промежуточные рассуждения и вызовы инструментов до конечного действия. В терминологии наблюдаемости это трейс, а каждый его шаг — спан. Один запрос пользователя разворачивается в дерево из десятков спанов, и именно это дерево, а не плоский текстовый лог, вам нужно уметь читать.

Что должно попадать в лог

Минимальный набор, без которого разбор инцидента превращается в гадание:

• Полный промпт и системная инструкция на каждом шаге — включая то, что подтянулось из внешних источников через RAG, потому что вредоносные данные приходят чаще всего оттуда.
• Ответ модели дословно, включая её рассуждения и запрос на вызов инструмента (tool call) с аргументами.
• Результат вызова инструмента — что вернул API или функция, с кодом ответа и телом.
• Метаданные шага: модель и её версия, температура, число токенов на входе и выходе, стоимость, задержка.
• Идентификаторы: сквозной ID трейса, ID сессии и пользователя, версия промпта и версия агента — чтобы связать инцидент с конкретным релизом.
• Решения о безопасности: сработал ли фильтр, запросил ли агент подтверждение человека, был ли шаг заблокирован.

Отдельный вопрос — персональные данные. В промпты и результаты инструментов утекают телефоны, адреса и платёжные реквизиты. Логировать их «как есть» бессрочно — риск: маскируйте чувствительные поля на этапе записи и задавайте срок хранения осознанно, а не «навсегда по умолчанию».

Лог агента — это не журнал ошибок, а доказательная база. Если вы не можете по нему воспроизвести, почему агент совершил спорное действие, значит, у вас нет ни отладки, ни защиты в споре с клиентом.

Чем это читать: инструменты трассировки

Рынок наблюдаемости для LLM-агентов вырос отдельным сегментом. Большинство инструментов работают по одной схеме: вы оборачиваете вызовы модели SDK или прокси, они собирают трейсы и рисуют дерево спанов. Ключевые различия — открытость кода, возможность self-hosting и привязка к фреймворку. Характеристики и цены меняются часто, актуальные условия смотрите на сайтах проектов.

Отдельно стоит OpenTelemetry с развивающимися семантическими соглашениями для GenAI: это не продукт, а стандарт формата трейсов. Если писать логи агента в нём, вы не привязаны к конкретному вендору и можете переключить бэкенд-хранилище, не переписывая инструментацию. На момент подготовки материала эти соглашения имеют статус экспериментальных — проверяйте текущую редакцию в документации проекта, поля ещё меняются.

Кому это пригодится, а кому нет

Пригодится в первую очередь:

• Командам, где агент имеет право на необратимые действия — платежи, рассылки, изменение прод-данных. Здесь лог нужен ещё до первого инцидента.
• Продуктам под регулированием (финансы, здоровье, работа с ПДн), где нужно предъявить, на каком основании система приняла решение.
• Тем, кто платит за токены заметные деньги: трассировка сразу показывает, какой шаг гоняет лишний контекст и жжёт бюджет.
• Разработчикам, которые борются с непостоянством агента: без сравнения трейсов «хорошего» и «плохого» прогона отладка вслепую.

Скорее избыточно:

• Для одношагового чат-бота без доступа к инструментам — там хватает обычного лога запросов и ответов.
• На стадии раннего прототипа в одиночку, где важнее проверить саму идею, чем инфраструктуру. Хотя даже здесь бесплатный локальный трейсер экономит часы.
• Если агент читает только публичные данные и ничего не меняет — риск ниже, требования к аудиту мягче.

С чего начать

1. Опишите, какие действия агента необратимы, и обеспечьте по ним самый подробный лог с подтверждением человека там, где цена ошибки высока.
2. Выберите формат — по возможности OpenTelemetry, чтобы не переезжать потом.
3. Настройте маскирование ПДн на записи и срок хранения трейсов.
4. Заведите сквозной ID трейса и версии промпта — без них связать инцидент с релизом невозможно.
5. Проверьте систему на учебном инциденте: сможете ли вы по логу за пять минут ответить, почему агент сделал спорный шаг.

RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает фрагменты из внешней базы знаний и добавляет их в промпт. Именно этот внешний контент — частый канал для инъекций, поэтому в аудите его логируют отдельно.