Qwen выбирает по одному шагу, runtime проверяет: как устроен управляемый AI-агент

Подключить агента к инструментам несложно. Сложнее другое: что делать, когда уверенного ответа модели мало. Если агент предлагает вернуть деградировавший сервис в строй, кто убедится, что инфраструктура переживёт переключение трафика и что сервис в итоге действительно восстановился? Автор разбора на Habr решил проверить это на практике и построил для этого отдельную среду.

Модель предлагает, runtime решает

Стенд называется Governed Agent Runtime. Он имитирует платёжный сервис: версии и реплики, нагрузку в RPS, метрики зависимостей, ограничения по мощности и отказоустойчивости N-1. В роли агента выступает локальная Qwen (в статье указана Qwen3.8:27b Q4_K_M). Модель выбирает следующий шаг, а допустимость и выполнение операций контролирует детерминированный код. Он проверяет предусловия, запрашивает подтверждение человека перед любым изменением состояния и ведёт бюджеты на обращения к модели и вызовы инструментов.

Важная деталь в том, что runtime различает состояния, которые легко спутать. «Запрошено 8 реплик» не значит, что 8 реплик здоровы. «Трафик перенесён» не значит, что сервис восстановился. «Операция разрешена» не значит, что она выполнена. «Модель считает задачу завершённой» не значит, что конечное состояние подтверждено.

Когда виноват оказался evaluator

На пяти одношаговых сценариях по три запуска Qwen набрала 12 из 15, а контроль runtime прошёл 15 из 15. Провалился сценарий S12, подготовка плана отката: модель добавила в план пороги вроде «5xx выше 5%» и «восстановление при 5xx ниже 1% за 5 минут». В её контексте этих цифр не было.

После добавления в контекст расчётов платформы (при 820 RPS шести реплик мало, семи не хватает по N-1, восьми достаточно) модель снова получила отрицательную оценку. Автор сопоставил три вещи: что модель видела на входе, что требовал evaluator и что она ответила. Выяснилось, что часть требований evaluator не имела основания во входных данных. Результат пересмотрели с «отрицательного» на «неопределённый».

В ответ появился Evaluation Traceability Gate. Каждый существенный критерий оценки должен ссылаться на факт из контекста модели или иметь документированный вывод, а решение подтверждает человек. Критерий обязательной проверки восстановления перед удалением старой версии так и не получил основания, и gate его заблокировал. В повторном прогоне Qwen допустила уже настоящую ошибку: переключила трафик раньше, чем подтвердила готовность восьми реплик.

Один шаг за раз

Тогда автор поменял постановку. Модель на каждом вызове предлагает ровно одно действие или STOP, а после шага получает обновлённые наблюдения. В успешном прогоне Qwen прошла цепочку: масштабирование до 8 реплик, отдельная проверка состояния, перенос 820 RPS, проверка восстановления, завершение отката. Это пять вызовов модели, девять операций с инструментами и три подтверждения человека. Перед зависимыми шагами модель сама запрашивала свежие наблюдения и не принимала разрешённую операцию за выполненную.

В негативном сценарии платформа вернула FAIL при проверке восстановления. Вместо завершения отката Qwen выбрала STOP, runtime зафиксировал SAFE_FALLBACK, а деградировавшие экземпляры остались на месте.

Что из этого взять

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

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