Я давно привыкла первым делом спрашивать «а как это упадет?». Когда в наш ландшафт пришли ИИ‑агенты, выяснилось интересное: привычные ответы на этот вопрос здесь просто не работают. Агент в проде, дашборды настроены по классике: latency, error rate, uptime. Алертов нет, агент исправно отвечает на каждый запрос. А то, что он три дня подряд уверенно врет, вы узнаете из жалобы пользователя, и никак иначе.

Эта статья для тех, кто уже запускает ИИ‑агентов в продакшен или только планирует это сделать: разберемся, чем агентный сбой отличается от сервисного, почему привычный мониторинг его не замечает и что можно сделать уже сейчас, не дожидаясь, пока подрастут специализированные инструменты.

Привет! Я Ольга, архитектор решений в группе развития платформы надежности Cloud.ru.

Моя работа начинается там, где что‑то пошло не так, и заканчивается там, где это «не так» больше не повторяется. С сервисами этот вопрос давно решен: микросервис упал, есть трассировка, есть алерт, есть дежурный инженер, который знает, где искать. С агентом все обстоит несколько интереснее.

Агент не падает. Он деградирует

Классический сервис ломается предсказуемо: есть стектрейс, есть спан, есть алерт. Больно, но хотя бы видно, куда бежать.

С ИИ‑агентом все по‑другому. Для него схема типичного отказа выглядит примерно так:

• Шаг 1. Пользователь задает вопрос.

• Шаги 2 и 3. Агент вызывает инструменты.

• Шаг 4. Агент выбирает не тот инструмент.

• Дальше продолжает работу как ни в чем не бывало.

• Финал: возвращает уверенный, связный, неправильный ответ.

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

Три отличия агентского сбоя от сервисного

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

1. Агент принимает решения, а не исполняет код

Микросервис делает ровно то, что вы написали. Он следует детерминированной логике, а значит, всегда можно открыть код и найти, где именно что‑то пошло не так.

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

2. Агент медленно теряет в качестве вместо явного отказа

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

Обнаружить такой отказ постфактум почти невозможно: это как искать иголку в стоге сена, не зная даже, где стог и что там вообще надо что‑то искать. Без измерения качества ответов вы этого не увидите.

3. Классические показатели надежности измеряют не то

Uptime, error rate, latency остаются метриками инфраструктуры. Они отвечают на вопрос «работает ли система?». Для агента же важен совсем другой вопрос: «делает ли система то, что должна?».

Агент может работать без единой ошибки и при этом системно выдавать неправильные ответы. Аптайм 100%. Полезность 0%. Дашборд зеленый, жалоба красная.

Агентная надежность измеряется поведением: выбрал ли агент правильный инструмент, выполнил ли задачу, остался ли в рамках контекста. Это совсем другие метрики, и продумывать их нужно до запуска, а не после того, как прилетит первый инцидент.

Давайте теперь посмотрим на метрики агентной наблюдаемости «здорового человека» чуть пристальнее.

Что значит «наблюдать» за агентом

Так куда же смотреть, если старые метрики молчат? Агентная наблюдаемость подразумевает намного больше, чем стандартная телеметрия. Это четыре принципиально разных уровня, и каждый из них решает свой вопрос.

Трассировать цикл рассуждений

Большинство команд честно инструментируют финальный ответ агента. И почти никто не инструментирует само рассуждение, которое к этому ответу привело.

А зря: именно там и живут сбои уверенности (confidence failure). Не в финальном ответе, а где‑то на шаге четыре из семи, где агент выбрал не тот инструмент и как ни в чем не бывало продолжил двигаться с этой ошибкой дальше.

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

Измерять агентские показатели качества вместо показателей инфраструктуры

Метрики, которые отвечают на вопрос «правильно ли ведет себя агент»:

• Точность выбора инструмента tool selection accuracy: как часто агент выбирает правильный инструмент для задачи. Измеряется на размеченной выборке или через автоматическую проверку.

• Процент завершения цели goal completion rate: как часто агент реально достигает нужного результата, а не просто генерирует складный ответ. Ответ есть, а цель может быть так и не достигнута.

• Соответствие источникам groundedness: насколько финальный ответ соответствует данным, к которым обращался агент. Агент способен галлюцинировать даже тогда, когда нашел правильный инструмент и получил правильные данные.

• Время до первого сбоя: метрика по аналогии с MTTF mean time to failure из классической надежности. Сколько запросов в среднем агент обрабатывает корректно до первого значимого отклонения. Устоявшегося названия для нее пока нет, но идея рабочая: если раньше агент держался на 500 запросах, а после обновления модели свалился до 50, этот сигнал появится куда раньше, чем жалоба пользователя.

Эти метрики никак не получить из инфраструктурного мониторинга. Их нужно проектировать отдельно до запуска, а не после того, как все уже сломалось. И наблюдать за ними вашим любимым способом — через классическую Grafana или отдельным агентом.

Оценивать качество через модель‑судью

Мониторинг говорит, что произошло. Оценка говорит, было ли это правильным.

Небольшая выборка ответов (обычно хватает 5%, при низком трафике — до 10%) проверяется на связность, соответствие источникам и полноту. Это дешевая страховка от регрессий, которые иначе заметят только ваши пользователи, и заметят не вовремя.

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

Версионировать промпты

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

Собираем базовый минимум наблюдаемости

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

Вот, что можно делать уже сейчас, чтобы завтра не краснеть перед пользователем:

1. Логируйте цикл рассуждений, а не только ответ (reasoning trace logging). Включите трассировку на уровне шагов агента: каждый вызов инструмента, каждое решение об оркестрации, входные и выходные токены, версию модели, идентификатор пользователя. Каждый такой шаг — это отдельный span в терминах распределенной трассировки, и все они должны быть связаны одним trace ID, который живет через весь сценарий выполнения от начала до конца.

2. Определите показатели качества до запуска. Если вы не можете сформулировать, что такое «хороший ответ» еще до запуска, вы просто не заметите момент, когда он станет плохим. Определите агентные SLO: точность выбора инструмента, процент выполненных задач, допустимый уровень соответствия источникам. Нет SLO — нет порога, нет порога — нет алерта.

3. Запустите оценку качества на выборке (LLM‑as‑judge evaluation). Берете от 5 до 10% ответов агента и прогоняете их через отдельную языковую модель, которая оценивает результат по заданным критериям: связность, соответствие источникам, достижение цели. Это и есть LLM‑as‑judge. Один такой прогон на выборке ловит регрессии раньше, чем их заметят пользователи, и обходится это ощутимо дешевле, чем потом три дня разбирать инцидент. Но помните о том, что делать подход к этому снаряду лучше регулярно, а то качество работы агента может атрофироваться как мышцы у космонавта.

4. Версионируйте промпты как код (prompt versioning). Git для промптов — это не роскошь, а минимум операционной гигиены. Каждое изменение промпта должно иметь версию, дату и автора, точно как коммит в репозитории. Промпт определяет поведение агента так же, как код определяет поведение сервиса: изменили промпт, значит, изменили систему. Без истории изменений и возможности откатиться (prompt rollback) регрессию просто не отладить.

5. Пишите телеметрию в два места с первого дня. Не привязывайтесь к одному инструменту, пока агент‑специфичные соглашения остаются в экспериментальном статусе: да, они уже существуют, но нет, они пока не стабилизированы. OpenTelemetry, открытый стандарт телеметрии, позволяет писать трейсы одновременно и к облачному провайдеру, и в специализированные инструменты наблюдаемости вроде Langfuse или Arize. Трейсы здесь — это записи каждого шага агента: какой инструмент вызвал, что получил, какое решение принял дальше. Это разом закрывает две задачи. Единый формат делает данные переносимыми: смените завтра облако или инструмент, а формат не изменится, переразмечать ничего не придется. А вторая точка записи, которую вы контролируете сами, делает вас независимыми от политики хранения конкретного вендора. Когда инструменты наконец дозреют, у вас уже будет история данных для сравнения, а не чистый лист. Profit!

Главный инсайт

Агент с несколькими вызовами инструментов, по сути, распределенная система с несколькими точками отказа. А мы давно умеем наблюдать за различными распределенными ИТ‑системами, и мне кажется вполне разумным применять ту же ментальную модель к агентам уже сейчас, не дожидаясь специализированного инструментария.

По своему опыту скажу: дело вообще не в технологиях. Настоящий барьер скорее в привычке думать о надежности агента в терминах аптайма, а не поведения.

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