AWS разделила мониторинг AI-агентов на качество и инфраструктуру

Зелёные метрики ещё не означают полезный ответ

AWS предлагает рассматривать production-мониторинг многоагентных систем как две независимые задачи. Первая — понять, выполнил ли агент намерение пользователя. Вторая — выяснить, исправны ли сервисы, разрешения и вызовы моделей. Обычные инфраструктурные показатели отвечают только на часть вопроса: агент может успешно вызвать инструменты и вернуть текст, но неверно понять запрос или выбрать не тот инструмент. Обратная ситуация тоже возможна — потерянное IAM-разрешение проявится пустым ответом, хотя наружу не выйдет привычная ошибка HTTP 500.

Для демонстрации AWS собрала систему бронирования авиаперелётов из четырёх специализированных агентов. Supervisor Agent принимает запрос и планирует подзадачи, Flight Agent ищет маршруты, User Agent получает профиль, статус лояльности и сертификаты, Reservation Agent создаёт и изменяет бронирования. Они работают по Swarm pattern: управление после входа передаётся тому специалисту, который лучше подходит для следующего шага, а не всегда возвращается центральному маршрутизатору.

Такая динамика полезна для сложного запроса с несколькими перелётами, корпоративной политикой и льготами, но лишает систему фиксированного графа исполнения. Сбой может возникнуть на любом handoff, а качество ответа и инфраструктурная проблема снаружи выглядят одинаково. Поэтому один общий индикатор здоровья недостаточен.

Первый слой: измерять результат работы агента

Amazon Bedrock AgentCore Evaluations асинхронно оценивает выбранную долю живых взаимодействий. В описанном примере используются Helpfulness, Correctness и Goal Success Rate: вместе они показывают полезность отдельного ответа, фактическую корректность и достижение цели всей сессии. Оценки и объяснения отправляются через OpenTelemetry в Amazon CloudWatch рядом с операционными метриками, поэтому по ним можно строить alarms и искать ухудшение после изменений.

AWS перечисляет 16 встроенных evaluators: 13 используют подход LLM-as-a-Judge, ещё три детерминированно сопоставляют траектории. Online evaluation допускает sampling от 0,01 до 100 процентов и выполняется в фоне, не добавляя задержку пользовательскому ответу. Это одновременно преимущество и ограничение: выборочная асинхронная проверка может обнаружить проблему уже после того, как ответ увидел пользователь.

Для синхронной защиты AWS предлагает дополнять Evaluations сервисом Amazon Bedrock Guardrails. Он может фильтровать нежелательный контент, запрещённые темы, проверять grounding и маскировать чувствительные данные до выдачи ответа. Роли не следует смешивать: Guardrails блокирует известные риски на каждом ответе, тогда как Evaluations ищет накопившиеся изменения качества и помогает анализировать конкретные сессии on-demand.

Следующий слой анализа группирует низкие оценки, отделяет повторяющиеся дефекты от единичных случаев и предлагает изменения prompt или выбора инструментов. AWS подчёркивает, что рекомендации должны опираться на статистику и trace evidence: частоту, затронутые session IDs и конкретные фрагменты исполнения. После этого новую версию можно проверить в CI/CD и наблюдать в следующем production-цикле.

Второй слой: расследовать причину технического сбоя

AWS DevOps Agent работает как автономный расследователь инфраструктурного инцидента. После запуска через подписанный webhook он собирает Amazon CloudWatch logs и metrics, строит топологию ресурсов, связывает ошибки между AgentCore runtime, Amazon Bedrock и IAM, затем выдаёт предполагаемую первопричину и шаги исправления. В показанном сценарии система сопоставила пустые ответы с отсутствующим разрешением bedrock:InvokeModel на execution role.

Вручную аналогичное расследование потребовало бы проверить application logs, последние deployments, IAM policies, метрики нескольких сервисов и цепочку взаимодействий агентов. Авторы оценивают такую работу в 30–60 минут при хорошем знании архитектуры. AWS DevOps Agent восстановил полный путь: пользовательский запрос, AgentCore runtime, вызов Amazon Bedrock API, отказ в доступе и затем сбой агента. Рекомендация заключалась не только в добавлении разрешения, но и в его ограничении конкретным ресурсом foundation model.

Архитектура не утверждает, что ещё один агент заменяет наблюдаемость. Напротив, оба слоя питаются подробными traces, logs и metrics, а качество измеряется отдельно от доступности. Итоговый практический принцип прост: команда должна заранее определить пользовательские критерии успеха, собирать траекторию инструментов, защищать ответы синхронно и иметь отдельный путь расследования IAM, throttling и скрытых tool failures. Только комбинация этих сигналов отличает работающую инфраструктуру от действительно работающего AI-продукта.