Towards AI описал схему critic-agent loop с ограничением итераций и эскалацией человеку

В материале о построении critic-agent loop описан подход, где одна модель готовит ответ, а вторая проверяет его перед отправкой пользователю. Worker Bot делает черновик, Critic Bot оценивает результат и, если находит ошибки, отправляет его на доработку. Если ответ не проходит проверку после трёх попыток, задачу передают человеку, чтобы не запускать бесконечный цикл исправлений.
Как пишет Towards AI, этот механизм рассматривается на примере LLM для поиска уязвимостей в коде. Авторы отмечают проблему однопроходной схемы: модель может уверенно выдавать ложные срабатывания. Например, принять параметризованный запрос или тестовый фрагмент за SQL injection. В итоге команде приходится тратить больше времени на ручную проверку, а доверие к инструменту снижается.
Отдельно в тексте разбирают слабые места «наивного» critic-loop. Проверяющая модель способна повторять ошибки worker-модели, сам цикл иногда не завершается, а система может вернуть неверный ответ после нескольких неудачных попыток исправления. Есть и практическая проблема: постоянный запуск critic-модели увеличивает стоимость обработки запросов. Чтобы снизить эти риски, авторы предлагают ограничивать число итераций, использовать структурированный JSON-ответ критика, разделять worker- и reviewer-модели, а также подключать confidence gate, который запускает проверку только при необходимости.
Авторы подчёркивают, что critic-модель не должна заново выполнять всю задачу. Вместо повторного анализа кода ей предлагают проверять конкретные выводы worker-модели по заранее заданным критериям: есть ли подтверждающие данные, правильно ли определён тип уязвимости и все ли проблемы были найдены.
Ключевые факты
После трёх неудачных попыток исправления задача передаётся человеку
Critic Bot возвращает структурированный JSON с полями score, verdict и issues
В качестве примера разбирается поиск SQL injection в коде
В материале описан confidence gate для выборочного запуска critic-модели