У обычного сервиса дежурный знает, что искать: упало — значит, сломалось. С агентом этот рефлекс не срабатывает. Агент может не отвечать, а может отвечать уверенно и не по делу — и второй случай хуже первого: процессные метрики молчат, а пользователь уже получил мусор вместо результата. Поэтому дежурство по агенту начинается с одного вопроса, после которого порядок действий становится почти механическим.
Жёсткий или мягкий: первый вопрос дежурного
Прежде чем что-то трогать, разделите отказ на два класса.
Жёсткий — когда ответа нет: таймауты, ошибки, падения. Мягкий — когда ответ есть, но неправильный: не тот инструмент, не те данные, зацикливание, уверенная чушь в финале.
Деление указывает, где искать причину. Жёсткий отказ почти всегда сидит в инфраструктуре: процесс, сеть, внешние API. Мягкий — в данных, в собранном контексте, в модели за API или в вашей оркестрации. И вот что из этого следует до первого действия: рестарт и откат меняют процесс. Если причина вне процесса, вы получите чистый процесс, который повторит ту же ошибку.
Сигнал, который вас разбудил, сам подсказывает класс. Жалоба пользователя или сработавший контроль качества ответов — почти наверняка мягкий. Растущие ошибки и таймауты — жёсткий, и тут агент ничем не отличается от любого сервиса, который зовёт внешние API. Аномалия по расходу — отдельный случай, о нём ниже, в шаге про деньги.
И честная оговорка про мониторинг: процессные метрики — живость, латентность, доля ошибок — измеряют процесс, а не ответы. Мягкий отказ их не трогает. Так что ждать, будто «зелёные графики» опровергнут жалобу пользователя, не стоит: они измеряют другое.
Тупик: рестарт, откат и ночной хотфикс
Первое, что пробуют, — перезапуск. Второе — откат. Для обычного сервиса это правильные шаги: большинство сбоев коррелирует с недавним деплоем или состоянием процесса, и откат возвращает систему в известное рабочее состояние.
С агентом оба хода чаще всего мимо, и причина одна: состояние, которое порождает плохое поведение, лежит вне процесса. После рестарта промпт соберётся из тех же данных, модель за API та же, инструменты те же — эпизод воспроизведётся, а не излечится. Откат вашего кода не поможет, если в вашем коде ничего не менялось: поведение агента зависит от мира — от данных, которые он читает, от API инструментов, от модели у провайдера, которую обновили без единой строчки в вашем чейнджлоге. Чейнджлог покрывает репозиторий, а не мир.
Третий соблазн — поправить промпт на месте, «одной строчкой», не дожидаясь утра. Это самый дорогой из трёх ходов. Правка промпта — деплой без тестов: под давлением её не проверить, воспроизводимость эпизода она ломает, а если стало хуже, вы уже не знаете, от чего откатываться.
Общее у всех трёх одно: это действия над системой, которую вы ещё не прочитали. Дальше — как читать.
Порядок действий
Шаг 1. Возьмите один эпизод. Если сигнал агрегатный — жалоба, аномалия расхода, сработавший контроль, — спуститесь до конкретного прогона: идентификатор, вход, выход. Единица разбора — эпизод, а не среднее. Среднее скрывает механизм; механизм виден только в полной трассе одного прогона. Условие применимости: трассы с идентификаторами должны существовать. Если их нет, не щупайте систему вслепую — переходите сразу к сдерживанию, а «нет трассы» записывайте как главный дефект этого инцидента.
Шаг 2. Читайте эпизод в фиксированном порядке. Порядок не для красоты: каждый слой либо объясняет симптом, либо снимает с себя подозрение, и к проверенному вы не возвращаетесь.
Сначала вход — дословно. Часть «поломок» — это вход за пределами того, на что агент рассчитан: новый тип задачи, неожиданная формулировка. Это не поломка агента, а граница его охвата, и решается она не дежурной сменой.
Дальше собранный контекст — тоже дословно: что вернули поиск и выборка. Если контекст мусорный или устаревший, модель честно отработала то, что ей скормили, и копать надо в данные и пайплайны, а не в «интеллект».
Дальше вызовы инструментов: аргументы и сырые ответы. Именно сырые. Агент пересказывает ответы инструментов для модели, и если читать его пересказ, вы увидите отказ уже переваренным. Классика жанра — инструмент, который на любую беду возвращает пустую структуру или страницу «успеха» без данных: агент не видит ошибки, вы не видите ошибки, видит только пользователь.
Дальше цепочка шагов: где поведение разошлось с тем, что предполагает ваша схема. Повторяющиеся одинаковые вызовы с одинаковыми аргументами почти всегда означают инструмент, чей ответ агент не может разобрать как прогресс.
И в конце — финальный ответ против шагов. Бывает, что все шаги верные, а враньё появляется на последней синтезирующей генерации. Тогда виноват слой сжатия и модель; инструменты тут ни при чём.
Шаг 3. Спросите «что менялось» — с расширенной картой изменений. Ваш деплой — один пункт в списке. Остальные: данные, которые агент читает; схемы и поведение API инструментов; модель за API у провайдера. Если из вашего списка что-то менялось и коррелирует по времени — откатывайте, классика работает. Если у вас не менялось ничего — перестаньте подозревать свои деплои и смотрите на входы из мира.
Шаг 4. Сдерживайте, а не чините. Ночью задача дежурного — огородить поведение; ремонт утренний. Инструменты сдерживания, каждый со своим условием применимости:
- переключение на запасную модель или маршрут — если роутинг существует;
- выключение проблемного инструмента — если агент умеет деградировать без него, а не падать;
- понижение лимита шагов или бюджета на прогон — если лимит крутится без деплоя;
- переключение затронутого класса задач на человека — если поток это позволяет;
- флаг на детерминированный упрощённый путь — если он существует.
Если ничего из этого у вас нет, ваш план сдерживания — «выключить агента». Решать, приемлемо ли это, надо было до первого инцидента, а не в моменте. Какие именно вещи отказывают у агентов, запущенных без запасных путей, — тема нашего материала про агентов в продакшене.
Шаг 5. Проверьте деньги. У агента каждый шаг стоит денег, поэтому поведенческий отказ перемножается в финансовый. Нормальную скорость сгорания посчитайте сами: среднее число шагов на прогон, умноженное на цену шага и на число прогонов в час. Текущая скорость против вашей нормы — детектор зацикливания, который у вас уже есть, даже если контроля качества ответов нет. Аномалия по расходу часто и есть первый честный симптом мягкого отказа. Если шаги не тарифицируются по отдельности, ту же роль играет латентность: цикл проявляется как рост времени прогона.
Шаг 6. Запишите и передайте. Идентификатор эпизода, гипотеза, что сдержали, что не проверили. Следующая смена наследует гипотезы, а не догадки. И честный тест для утра: если для диагноза пришлось гадать, первый пункт постмортема — трассировка, а не агент. Что писать в неё, а что нет, — тема отдельного материала.
Позиция редакции
Наша позиция: при мягком отказе первое действие дежурного — прочитать одну полную трассу эпизода, прежде чем трогать систему чем бы то ни было. Не рестарт, не откат, не правка промпта — чтение. Всё, что вы делаете с непрочитанной системой, уничтожает улики и не лечит причину, которая живёт вне процесса.
Условие, при котором эта позиция неверна: жёсткий отказ. Если агент не отвечает вовсе, читать трассы — тормозить классическое восстановление; там порядок обычный — зависимости, процесс, рестарт, откат. Второе условие: медленный дрейф. Если качество просело понемногу у всех и одного плохого эпизода нет, разбор единичной трассы ничего не покажет — там нужен выходной контроль по выборке и сравнение с эталоном, а это уже не ночная работа.
И оговорка для несогласных: если ваш «агент» — один вызов модели без инструментов и памяти, вся специфика вырождается, и дежурьте по нему как по обычному сервису с внешним API.
Что остаётся открытым
Ночной дежурный не может отличить деградацию модели у провайдера от дрейфа данных на своей стороне: симптомы неразличимы, а чинится то и другое по-разному — одно письмом в поддержку, другое правкой пайплайна. Различить их можно только днём и только при наличии эталона: замороженной подборки задач с известными правильными ответами, по которой обе версии сравниваются. Если эталона нет, честный ответ на вопрос «что это было» — «не знаем», и это не слабость дежурного, а дыра в конструкции. Первое, что стоит построить после первого инцидента, — не новый контроль, а этот эталон.