Мониторинг ИИ-агентов AgentOps: что не покажет обычный MLOps-дашборд

Я, Арина Михална, вижу, что мониторинг ИИ-агентов в продакшене AgentOps ломается там, где заканчивается привычный MLOps: обычный стек смотрит на точность модели и код ответа сервера, а агенту важно видеть цепочку решений — какой инструмент он вызвал, зачем, и где логика свернула не туда при абсолютно зелёном статусе 200. Формально всё работает, по факту агент десять минут звонил в чужой API по кругу, а я узнала об этом от клиента, а не от дашборда.

Почему MLOps-дашборд врёт про агента

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

Классический APM (мониторинг производительности приложений) видит только финальный HTTP-статус. Агент может пять раз дёрнуть внешний API, получить пустой ответ, попробовать ещё раз с чуть другим промптом — и в итоге вернуть что-то похожее на правильный ответ. Дашборд покажет зелёный статус 200 и нормальную латентность. А по факту ты потратил токенов на пять вызовов вместо одного и получил ответ, который просто выглядит нормально.

Что смотрит	MLOps	AgentOps
Единица наблюдения	один запрос к модели	цепочка шагов внутри задачи
Метрика успеха	точность, латентность	завершённость цепочки, число лишних вызовов
Где ищут проблему	дрифт данных, деградация модели	логика решений, порядок вызовов инструментов
Что скрывает статус 200	почти ничего	реальный провал задачи
Стоимость ошибки	пересчёт метрик	реальные действия — файлы, деньги, чужие системы

Три метрики, с которых стоит начинать

Если стека мониторинга нет и денег на дорогой инструмент тоже нет — не нужно сразу ставить весь трейсинг. Хватает трёх метрик, которые реально предсказывают, где будет больно.

Стоимость токенов на успешную задачу. Не общий расход, а именно на успешную — то есть где агент дошёл до правильного результата с первого раза. Разница между «средним расходом» и «расходом на успех» показывает, сколько денег уходит на циклы и повторы, которые ты не видишь напрямую.

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

Время до обнаружения сбоя человеком. Не время работы агента, а время между тем, когда он свернул не туда, и тем, когда об этом узнал живой человек. У большинства команд без AgentOps-стека это время измеряется часами или днями — потому что узнают из отзыва клиента, а не из дашборда.

Где именно рвётся обычный лог

Обычный лог пишет одну строку на один вызов API. Когда агент делает один вызов — этого достаточно. Когда агент вызывает инструмент, тот инструмент вызывает ещё один сервис, а результат агент передаёт следующему шагу — лог превращается в набор несвязанных строк без контекста, кто кого вызвал и зачем.

Разница — это переход от логирования к трейсингу. Трейс — это не строка, а дерево: корневая задача, а внутри неё вложенные шаги с временем и причиной каждого. Без трейса ты видишь «вызов API — успех», «вызов API — успех», «вызов API — ошибка» тремя разными строками и не знаешь, что это была одна задача, которая упала на третьем шаге.

Ты настраиваешь логирование для агента на Claude Code,
который вызывает несколько
инструментов подряд в рамках одной задачи. Перед каждым
вызовом инструмента агент
должен вывести одну строку в формате: [шаг N] вызываю
{{название инструмента}},
потому что {{причина в одно предложение}}. После получения
результата — вторую
строку: [шаг N] результат: {{успех/ошибка}}, следующий шаг:
{{что делает дальше}}.
Не меняй остальную логику работы, только добавь эти строки
перед и после
каждого вызова инструмента.

Кому AgentOps не нужен ещё

Не всякий агент требует отдельного стека мониторинга. Если у тебя один скилл, который делает один вызов модели без цепочки инструментов — читать обычные логи вполне достаточно, отдельный трейсинг будет избыточен.

Порог, после которого без AgentOps начинает болеть:

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

Если хотя бы два пункта из списка совпадают — пора закладывать хотя бы минимальный трейсинг, а не ждать первого инцидента. Про то, как собрать самого первого агента и на что обратить внимание до продакшна, я писала в статье как собрать агента на Claude — там база, без которой мониторинг ставить рано.

Что почитать дальше по теме безопасности агентов

Мониторинг — это половина истории; вторая половина — что агент физически может сделать, если сорвётся с цепочки. Про конкретный случай, где агент дошёл до реального взлома, я писала в статье Claude агент взломал сайт спортзала, а про то, как заранее ограничить агенту права, чтобы он не наделал того же самого — в статье как ограничить права ai агента. Обе статьи из той же линии рассуждений, что и мониторинг: сначала ограничиваешь, потом наблюдаешь, а не наоборот.

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

По материалам: AgentOps is not MLOps на Towards Data Science; цифры по стоимости и скорости генерации статей — из собственных замеров на шлюзе vibecode.moe, август 2026.

Читайте также

• Разработка ИИ-агентов в 2026: заказывать или собирать самому
• Как защитить файлы от удаления ИИ агентом Claude Code в 2026
• Anthropic выпустила стандарт MHS для управления устройствами через агентов
• На портале «Мастерская нейросетей»: Безопасность ИИ-агентов для бизнеса в 2026: как не потерять контроль

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