Агент возвращает пустой ответ. HTTP-код 200, время отклика в норме, в логах CloudWatch нет исключений, дашборд зелёный. Пользователь при этом не получил бронь. Такой сбой не видит ни одна инфраструктурная метрика.
Двухуровневый мониторинг продакшн-агентов в AWS закрывает этот разрыв. Первый уровень, Amazon Bedrock AgentCore Evaluations, оценивает качество работы на живом трафике: полезность, корректность и достижение цели. Второй уровень, AWS DevOps Agent, ищет первопричину инфраструктурных сбоев по логам и топологии ресурсов. Первый отвечает на вопрос «стало ли хуже», второй - «почему именно стало хуже».
Почему традиционный мониторинг не видит проблемы AI-агентов
Стандартный набор метрик продакшн-сервиса отвечает на два вопроса: жив ли сервис и успевает ли он отвечать. Загрузка CPU, потребление памяти, коды HTTP, время отклика. Про содержание ответа эти метрики не говорят ничего.
Показательный сбой: у IAM-роли агента нет разрешения bedrock:InvokeModel. Вызов модели не проходит, но агент не падает. Он перехватывает ошибку и возвращает пустую строку или заглушку. Пользователь видит пустой ответ, а система показывает 200 OK, нормальную задержку и ноль исключений. Инфраструктура здорова, задача не выполнена.
В мультиагентных системах добавляется второй фактор: неопределённость маршрута. В паттерне Swarm жёсткого графа выполнения нет, агенты передают задачи друг другу динамически, и сбой может возникнуть в любой точке передачи. Один агент вернул неполный список рейсов, второй на его основе собрал маршрут, третий оформил бронь. Ни один шаг не завершился ошибкой, а результат неверный.
Так выглядит деградация качества: система формально работает, но приносит пользователю неправильный результат. Механику таких поведенческих сбоев и способы их поиска через анализ трейсов без опоры на сигналы ошибок мы разбирали в материале о тихих сбоях AI-агентов, которых не видно на дашбордах.
Доступность и производительность ничего не говорят о семантике ответов. Пока в контур не добавлен слой оценки качества, деградация агента остаётся незамеченной до жалоб пользователей.
Что такое двухуровневый мониторинг и как он работает
Двухуровневый мониторинг разделяет два разных вопроса. Первый: насколько хорошо агент справляется с задачей. Второй: почему он перестал справляться.
Первый уровень закрывает Amazon Bedrock AgentCore Evaluations. Он непрерывно оценивает живые взаимодействия агентов по метрикам полезности, корректности и достижения цели. Вывод о деградации приходит из реального трафика, а не из синтетических тестов, которые пишут разработчики.
Второй уровень закрывает AWS DevOps Agent. Он работает как автономный дежурный инженер: собирает логи CloudWatch, строит топологию затронутых ресурсов и находит первопричину. Ответ на вопрос «что именно сломалось» приходит без ручного сопоставления логов по разным сервисам.
Границы между уровнями важны. Evaluations видит симптом на уровне поведения: метрика упала. DevOps Agent видит причину на уровне инфраструктуры: не хватает разрешения, не отвечает зависимость, изменилась конфигурация. Симптом без причины даёт долгий ручной поиск. Причина без симптома означает, что проблему ещё никто не заметил.
Дальше два слоя замыкают цикл: наблюдение, анализ, улучшение, деплой. Метрики показывают, где стало хуже, расследование объясняет почему, команда вносит правку, новая версия уходит в продакшн, и оценка снова проверяет результат на живом трафике.
AgentCore Evaluations: непрерывная оценка качества агентов
AgentCore Evaluations оценивает реальные взаимодействия, а не тестовые сценарии. Агент бронирования получает запрос, ведёт диалог, вызывает инструменты, выдаёт результат. Каждый такой прогон оставляет трассировку, и по ней считается качество.
Метрики: полезность, корректность, достижение цели
Полезность: решает ли ответ задачу пользователя. Если человек просил рейс с одной пересадкой и без ночного ожидания, а агент предложил вариант с двумя пересадками, ответ формально по теме, но пользы в нём мало.
Корректность: соответствует ли ответ фактам и правилам. Цена билета, дата, аэропорт, время вылета, наличие мест. Ошибка в одном поле делает бронь недействительной, даже если диалог звучал уверенно.
Достижение цели: выполнена ли конечная задача. В системе бронирования это оформленная бронь с верными параметрами. Метрика отвечает не на вопрос «красиво ли агент говорил», а на вопрос «получил ли пользователь то, за чем пришёл».
Набор метрик даёт разную диагностику. Если полезность падает, а корректность держится, проблема скорее в логике диалога или в промптах. Если падает корректность, стоит смотреть на инструменты и данные, которые агент получает. Если проседает достижение цели, сбой может быть на последнем шаге, где бронь не доходит до системы.
LLM-as-a-Judge и выборочный семплинг трассировок
LLM-as-a-Judge: одна модель оценивает ответы другой по заданным критериям. Судья получает запрос пользователя, трассировку и итоговый ответ, после чего выставляет оценку и, что важнее, объясняет её. Объяснение помогает понять, что именно пошло не так: агент не вызвал нужный инструмент, потерял параметр или подставил устаревшие данные.
Проверить все взаимодействия дорого: каждый прогон судьи расходует токены и время. Поэтому используется выборочный семплинг трассировок: оценка идёт по части взаимодействий. Это компромисс между полнотой картины и стоимостью. Сэмплирование работает, если выборка репрезентативна, а метрики не размываются редкими, но громкими случаями.
Похожая механика разбиралась на кейсе оценки длинных исследовательских отчётов, где LLM-as-judge проверяет faithfulness и калибровку, разбор кейса Similarweb и уроков внедрения. Там же описан пример ошибки калибровки, которая едва не замаскировала реальные улучшения агента.
На практике это выглядит так: агент бронирования начал выдавать неверный маршрут, метрика достижения цели снизилась, и это видно в динамике, ещё до потока жалоб в поддержку.
AWS DevOps Agent: автономный дежурный инженер для расследования сбоев
AWS DevOps Agent берёт на себя рутину дежурного инженера. Вместо ручного сопоставления логов разных сервисов он собирает их, строит картину зависимостей и указывает первопричину.
Анализ логов CloudWatch и построение топологии
Первый шаг: сбор логов из CloudWatch. Второй: построение топологии затронутых ресурсов, то есть графа зависимостей. В контуре агента такая цепочка выглядит так: агент, среда выполнения, модель, роль, политика с разрешениями. Граф показывает, где именно обрывается связь, и сужает область поиска с десятков сервисов до нескольких узлов.
Без топологии расследование превращается в перебор: логи среды выполнения, логи модели, конфигурация ролей, сетевые ограничения. С топологией поиск идёт по связям, а не по всему проекту.
Пример: отсутствующее разрешение bedrock:InvokeModel
Сценарий, который трудно поймать вручную. Агент возвращает пустой ответ. В логах нет явной ошибки: код обработки перехватил исключение и вернул заглушку. Метрика достижения цели просела, пользователи оставляют жалобы, но точка отказа неизвестна.
DevOps Agent смотрит на трассировки и видит, что вызов bedrock:InvokeModel не выполняется. Дальше топология показывает роль, от имени которой работает агент, и её политику. Причина: в политике нет нужного разрешения. Модель недоступна не из-за сбоя сервиса и не из-за сети, а из-за прав доступа.
Правка занимает минуты: добавить действие в политику и перезапустить агента. Основное время уходит на поиск, а не на исправление. Именно этот поиск автоматизируется.
Практический пример: мультиагентная система бронирования авиабилетов
Демонстрация, на которой удобно смотреть оба слоя, это мультиагентная система бронирования авиабилетов из четырёх агентов, построенная по паттерну Swarm.
Паттерн Swarm и отсутствие фиксированного графа
Swarm описывает децентрализованное взаимодействие: агенты передают управление друг другу по ситуации, а не по заранее заданному маршруту. Фиксированного графа выполнения нет, поэтому один и тот же запрос может пройти через разные цепочки.
Четыре агента в такой системе решают разные задачи: понимание запроса, поиск рейсов, работа с деталями брони, оформление. Передача задач динамическая. Отсюда два следствия для мониторинга. Первое: нельзя проверить «правильный» порядок шагов, его просто нет. Второе: сбой в любой точке передачи влияет на результат, и заранее неизвестно, в какой именно.
Часть сбоев выглядит как ошибка, часть как тихая деградация. Агент поиска вернул пустой список, следующий агент предложил то, что осталось в памяти, третий оформил не тот вариант. Ни одного исключения, ни одной красной метки в инфраструктуре.
Ещё один пример мультиагентной системы на AgentCore с ролевыми агентами и MCP-инструментами разобран в кейсе AvioBook и Connected Analytics на Amazon Bedrock AgentCore: там есть честные цифры экономии и ограничения proof-of-concept.
Как два уровня мониторинга работают вместе
Evaluations замечает симптом: доля броней с верным маршрутом падает, метрика достижения цели снижается. Это сигнал, но не диагноз. Причин может быть несколько: изменились промпты, устарели данные о рейсах, отвалился инструмент, у агента нет прав на вызов модели.
Дальше включается DevOps Agent: анализирует логи CloudWatch, строит топологию и указывает на конкретный узел. В сценарии с пустыми ответами это отсутствующее разрешение bedrock:InvokeModel. После правки и деплоя Evaluations подтверждает восстановление: метрики возвращаются к прежнему уровню на живом трафике.
Без второго слоя команда видит только падение качества и тратит часы на поиск. Без первого слоя инфраструктурная проблема остаётся незамеченной, пока её не заметит пользователь.
Ограничения подхода: что важно учитывать
Оценки LLM-as-a-Judge не имеют ground truth. Судья сравнивает ответ с критериями и своим представлением о правильном, а эталона рядом нет. Часть оценок будет спорной: судья может завысить балл уверенному, но неверному ответу или занизить корректный ответ из-за формата. В критичных сценариях, где цена ошибки высока, оценки стоит дополнять детерминированными проверками: сверка полей брони, наличие обязательных шагов, корректность вызовов инструментов.
Онлайн-оценка добавляет задержку. Прогон судьи расходует токены и время, а на больших объёмах трафика это заметная статья затрат. Выборочный семплинг снижает нагрузку, но не убирает её полностью и добавляет собственное ограничение: редкий сбой может не попасть в выборку.
Для продакшна Evaluations рекомендуют дополнять синхронными Amazon Bedrock Guardrails. Guardrails работают в реальном времени на пути запроса и отсекают нежелательный контент и нарушения политик до того, как ответ уйдёт пользователю. Разделение простое: Guardrails отвечают за безопасность каждого ответа, Evaluations измеряют качество системы в целом. Ждать вердикта судьи, чтобы заблокировать опасный ответ, поздно по определению.
Отдельное ограничение - стоимость и сложность настройки. Оба слоя требуют конфигурации: критериев оценки, правил семплинга, доступа к логам, политик для расследования. Это не готовое решение из коробки, а инструмент, который нужно настроить под свою систему.
Про метрики самописного агента и обработку ошибок есть практический разбор с кодом на Python, архитектура, метрики и код, включая сравнение latency, cost и reliability с готовыми решениями.
Как замкнуть цикл «наблюдение - анализ - улучшение - деплой»
Цикл состоит из четырёх шагов, и каждый опирается на свой инструмент.
- Наблюдение. AgentCore Evaluations считает метрики по выборке живых взаимодействий: полезность, корректность, достижение цели.
- Анализ. Когда метрика падает, AWS DevOps Agent разбирает логи CloudWatch и топологию ресурсов и указывает первопричину.
- Улучшение. Команда вносит правку: добавляет разрешение в политику, корректирует промпт, чинит инструмент или логику передачи задач между агентами.
- Деплой. Новая версия уходит в продакшн, и Evaluations снова измеряет те же метрики на живом трафике.
Замыкание цикла даёт то, чего не хватает при раздельном использовании инструментов: проверку, что правка действительно помогла. Метрика вернулась к прежнему уровню, значит, гипотеза о первопричине верна. Не вернулась, значит, причина была не одна.
Кому и когда стоит внедрять двухуровневый мониторинг
Подход оправдан, если мультиагентная система работает в продакшне на AWS и обрабатывает реальные запросы пользователей. Особенно когда агенты взаимодействуют динамически, как в Swarm: предсказать маршрут заранее нельзя, а значит, нельзя и покрыть все пути тестами.
Второй критерий - цена ошибки. Если неверный ответ агента приводит к финансовым потерям, испорченной брони или неверным данным в отчётности, слой оценки качества нужен. Ошибки, которые видит пользователь, дороже ошибок, которые видят только логи.
Если агент один, набор инструментов фиксирован, а система крутится в песочнице или в тестовом контуре, базовых метрик и логирования достаточно. Двухуровневый мониторинг добавит конфигурации и расходов на токены судьи без заметной отдачи.
Разумный порядок внедрения: сначала включить оценку качества на выборке трассировок и посмотреть, есть ли вообще деградация, которую стоит расследовать. Затем подключить автоматическое расследование сбоев по логам. Первый слой показывает, что чинить, второй сокращает время поиска причины.