Невидимые ошибки ИИ: почему агент-ревизор, проверенный самим собой, бесполезен

# Невидимые ошибки ИИ: почему агент-ревизор, проверенный самим собой, бесполезен

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

Статья исследует концепцию «Harness Engineering» — создание жесткой обвязки вокруг модели, где ключевым элементом является независимый «гейт» (ворот). Без такого механизма система слепа к собственным ошибкам, а проверка превращается в пустую формальность.

Архитектура доверия: почему «себе верь» не работает

Ключевая ошибка в конфигурации большинства современных агентов заключается в попытке сэкономить ресурсы и упростить поток данных. Часто один и тот же чат выполняет две функции: он пишет код (или текст) и сам же утверждает его готовность, закрывая чек-лист. Формально все пункты выполняются, статус в шапке документа корректный, но фактически проверка отсутствует.

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

1. Управляющий проход: Назначает задачи и анализирует финальный результат. Он не пишет код и не выносит вердиктов сам. 2. Исполняющий проход: Работает с файлами, правит код и создает черновики. 3. Проверяющий проход (Ревизор): Отдельный агента, который открывает файлы исполнителя, но не имеет прав на их редактирование. Его единственная цель — написание файла вердикта.

Если эти роли не разделены физически (отдельными окнами чата и инструкциями), система ломается. Ревизор начинает видеть историю дискуссий исполнителя, что предвзято влияет на оценку. Кроме того, если один файл редактируется двумя разными проходами, возникают конфликты, которые невозможно отследить.

Механика гейта: жесткий контроль перед завершением

Гейт в данной системе — это точка невозврата. Работа не может продвинуться дальше, пока другой независимый проход не напишет файл с вердиктом. Это не просто совет ревьюера, который можно игнорировать; это системное требование.

Для реализации такого контура необходимо четко определить права доступа. Часто возникает иллюзия, что запретить ревизору писать что-либо в рабочие файлы достаточно. На практике это приводит к обратному эффекту: если у ревизора нет прав на запись, файл вердикта часто создает вызывающий чат или сам исполнитель, что снова возвращает нас к ситуации «самооценки».

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

Структура взаимодействия должна быть прозрачной. Исполнитель создает файлы по заданному пути (например, src/parser.py), а затем передает пути к этим файлам ревизору. Ревизор открывает их, анализирует содержимое и генерирует отчет. Файл вердикта должен содержать машиночитаемую первую строку, например verdict: PASS или verdict: FAIL, за которой следуют детали ошибок с указанием конкретных строк кода и путей к файлам.

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

Эффективность и стоимость: за что платим?

Внедрение такой системы требует дополнительных ресурсов. Автор статьи приводит данные по своему опыту: при переходе к схеме с гейтом количество обращений к языковой модели (LLM) выросло в 2,7 раза по сравнению с режимом «без контролера». Если без проверок было бы 167 обращений, то с проверкой их становится 444.

Ценой этого роста является, однако, качество. В системе с гейтом около 30% проходов ревизора заканчиваются отказом (FAIL). Это означает, что каждая шестая работа, которая бы прошла «свободно», была остановлена на раннем этапе из-за реальной ошибки. Медианное время от запуска исполняющего прохода до получения вердикта составляет около пяти минут.

Для сравнения: в многоагентных системах Anthropic отмечают увеличение расхода токенов до 15 раз по сравнению с обычным чатом. Хотя точные цифры могут варьироваться, порядок стоимости понятен: вы платите за то, чтобы ловить ошибки, которые иначе бы ушли в продакшн. Если доля ошибок на реальных задачах близка к нулю, наличие гейта может показаться избыточным, но именно на сложных проектах, где ошибка стоит дорого, этот механизм становится необходимым фильтром.

Заключение

Безопасность и качество работы ИИ-агентов зависят не от сложности их инструкций, а от жесткой архитектурной дисциплины. Попытка сэкономить токены, используя одного агента для создания и проверки, приводит к иллюзии завершённости. Реальная проверка возможна только при полном разделении ролей: исполняющий создает, независимый ревизор проверяет, а управляющий координирует процесс.

Эта система требует дополнительных затрат и времени, но она превращает хаотичный поток данных в контролируемый процесс разработки, где ошибки выявляются сразу после их появления, а не спустя дни работы над продуктом.