🛠 Отлаживать AI-агента нужно по шагам, а не по ответу

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

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

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

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

#ИИагенты #Отладка #AgentOps #Наблюдаемость