Классическая интеграция вызывается из понятного места: строки кода, стек вызовов, время. Агент - другое дело: он сам решает, какие инструменты вызвать и в каком порядке, поэтому обычное «посмотри в коде, что он делает» не работает. Чтобы понять, что произошло, нужен слой наблюдения - и здесь в зоне видимости две разные вещи, которые часто путают.
Аудит и observability отвечают на разные вопросы, дают разную пользу и требуют разных подходов. Разберём их по отдельности и покажем, как выстроить оба уровня, чтобы и безопасность была разрешима, и отладка не превращалась в гадание.
Агент непредсказуем - и потому требует наблюдения
У агента нет заранее зафиксированного пути. Задача «разберись с багом в репозитории» может пройти через поиск, чтение файлов, запуск тестов, коммит - и любой набор таких шагов уникален. Автономия - источник гибкости, но она же делает поведение невоспроизводимым: два запуска могут дать похожий, но не одинаковый след действий.
Это значит, что «наблюдение постфактум по коду» невозможно физически. Единственный способ понять, что агент сделал, - это журнал того, что он реально вызвал. Без него нет ни ответа на вопрос «кто отвечает за это действие», ни инструмента для отладки «почему оно сработало так».
Аудит vs observability: почему это разные вещи
Хотя оба уровня смотрят на одни и те же вызовы агента, цели у них разные:
- Аудит отвечает на вопрос «кто и что сделал» - с точки зрения безопасности и ответственности. Это корпоративные записи: какой пользователь, через какой инструмент, с какими правами, какие данные затронул. Аудит нужен для расследования инцидентов, проверки соответствия политике и ответа на вопрос «кто за это отвечает».
- Observability отвечает на вопрос «как система работает» - с точки зрения производительности и надёжности. Это метрики, трейсы и логи, которые показывают, где агент тормозит, падает, повторяет вызовы. Нужно для отладки и оптимизации.
Если слить их в один «журнал», у вас получится хранилище, в котором нельзя быстро найти ни ответственного за инцидент, ни узкое место по времени. Поэтому важно держать и то, и другое - но осознанно.
Что логировать для аудита
Аудит агентных действий должен фиксировать неизменяемый набор фактов, чтобы ответить на «кто за это в ответе»:
- Кто инициировал - пользователь и его контекст прав, под которыми сработал агент.
- Что вызвано - какой инструмент/операция, с какими параметрами.
- Какие данные затронуты - какие ресурсы и поля были запрошены или изменены.
- Когда и с каким результатом - временная метка, успех/ошибка, объём.
- С какими полномочиями - какие scope/права использованы для конкретного вызова (а не «в целом есть доступ»).
Аудит пишется однократно, его нельзя «поправить» записью-другой, и он рассчитан на чтение спустя время - для расследования. Журнал вызовов инструментов - база и для ответа на запросы безопасности, и для повторного разбора конкретного инцидента.
Что трейсить для производительности
Observability смотрит на те же вызовы, но глазами нагрузки:
- Сколько времени занимает вызов инструмента и вся агентная задача в целом.
- Число повторных попыток - агент зациклился на одном инструменте или движется вперёд.
- Ошибки и их доли - какие инструменты падают, как часто, по каким причинам.
- Потребление контекста - сколько токенов агент «сжигает» на каждом шаге (это напрямую связано с расходами).
- Корреляция шагов прогона - связь между шагами в рамках одной задачи, чтобы увидеть, куда ушло время.
Здесь работает стандартный инструментарий - трейсы/спаны, - но с учётом специфики: «задача» агента растянута на много вызовов инструментов, поэтому связывать их нужно в единый trace по идентификатору запуска.
Как связать аудит и observability на практике
Разводить их не значит строить две несвязанные системы. Практичный подход - общее ядро из журнала вызовов, к которому цепляются разные представления:
- Ядро: единый журнал «вызов инструмента» с правами, данными, параметрами и метадами времени.
- Аудит-вид: неизменяемые записи для ответа и соблюдения политик - кто, что, какие данные.
- Observability-вид: агрегаты и трейсы поверх тех же событий - latency, ошибки, повтор попытки, расход контекста.
Так вы пишете данные один раз, а читаете в двух целях. Ключевое - у каждого вызова есть стабильный идентификатор, по которому можно связать запись аудита («что случилось») с трейсом («почему медленно / почему упало»).
Где Codenik: журнал вызовов как общее ядро
В связке «аудит + observability» Codenik закрывает аудит-слой: он управляет доступом к инструментам и секретам и записывает каждый вызов - кто, с какими правами, какие данные. Именно из этого журнала можно ответить на вопрос «кто за это отвечает» и подать данные в инструменты трейсинга для отладки производительности.
То есть Codenik даёт assurance-ядро (безопасность, права, ответственность), а observability с метриками и трейсами вы поднимаете поверх этого журнала в своей инфраструктуре. Оба уровня опираются на одну запись вызова - и оба оказываются разрешимы, когда они разделены, но связаны. Больше про права и ответственность - в статье «Аудит для действий агентов».
Короткий вывод
Аудит и observability агентов - разные уровни, отвечающие на «кто за что отвечает» и «как это работает» соответственно. Агент без наблюдения - чёрный ящик: его нельзя ни защитить должным образом, ни отладить.
Стройте оба, но через общее ядро журнала вызовов: пишите событие один раз, аудит читает его для ответственности, observability - для производительности. И связывайте их стабильным идентификатором запуска - тогда любая медленная или подозрительная задача раскладывается на шаги в секунды.