AI И НЕЙРОСЕТИ

Datadog призывает наблюдать за ИИ-агентами как за продакшеном

9 октября Datadog обсудил наблюдаемость ИИ-агентов: почему недетерминированные системы требуют трассировки, контроля безопасности и токенов.

✍️ Редакция iTech News | 10.10.2026 | ⏱ 4 мин | Источник: Stack Overflow Blog
🎯

ИИ-агент может выполнить одну и ту же задачу двумя разными путями — и оба раза формально «успешно». Именно поэтому наблюдаемость ИИ-агентов становится не приятным дополнением к LLM-проекту, а частью его эксплуатации: без неё команда не понимает, почему выросла цена запроса, откуда взялся рискованный ответ или на каком шаге агент принял странное решение. Эту тему 9 октября обсудили Ryan и Chief Product Officer Datadog Яньбин Ли, сообщает Stack Overflow Blog.

Datadog позиционирует себя как платформу наблюдаемости и безопасности для облачных приложений, распределённых систем и поведения ИИ-агентов. В центре разговора — практическая проблема: привычные инструменты мониторинга хорошо показывают ошибки, задержки и загрузку инфраструктуры, но агентные системы ведут себя менее предсказуемо. Они выбирают инструменты, строят цепочки действий, обращаются к моделям и меняют ход работы в зависимости от промежуточного ответа. Один итоговый статус «запрос обработан» для такой системы почти бесполезен.

Недетерминированность здесь не баг, который можно вылечить парой условий в коде. Два запуска с похожим контекстом способны привести к разным рассуждениям, вызовам инструментов и расходу токенов. Для команды это означает необходимость видеть не только финальный ответ модели, но и всю траекторию выполнения: входные данные, выбранные действия, обращения к сервисам, ошибки и стоимость каждого этапа. Наблюдаемость превращается в способ расследовать поведение агента, а не просто считать uptime его API.

Ли также затронула стирание границы между разработкой и эксплуатацией. В классическом ПО разработчик собирает логи и метрики, а затем передаёт сервис в продакшен. У агентов этот цикл становится плотнее: качество промпта, набор доступных инструментов, ограничения доступа и поведение модели приходится проверять на реальных сценариях постоянно. Изменение инструкции или модели может поменять не только формулировку ответа, но и последовательность действий системы. Значит, вопросы, которые раньше относили к разработке, быстро становятся вопросами надёжности и контроля в проде.

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

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

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

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

Главный вопрос для рынка теперь не в том, смогут ли агенты писать код, искать ответы или заполнять карточки задач. Они уже это делают с разной степенью пользы. Вопрос в том, смогут ли компании объяснить и контролировать их действия, когда агент получит доступ к реальным данным и рабочим инструментам. Чем больше автономии получает система, тем меньше у команды права считать наблюдаемость ИИ-агентов задачей «на потом».

Поделиться: Telegram X LinkedIn