Как проверить код тремя ИИ-ролями: исследователь, критик и верификатор

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

Шаг 1. Ограничьте область проверки

Выберите один сервис, конкретную ветку и два класса ошибок. Например, обход проверки доступа и небезопасную обработку пользовательского ввода. Зафиксируйте commit hash. Не подключайте рабочие секреты и не давайте агентам сетевой доступ. Если проект нельзя собрать в отдельной среде, сначала подготовьте её; анализ фрагментов без зависимостей часто создаёт больше догадок, чем пользы.

Составьте карту границ: какие папки разрешено читать, где агент может писать временные файлы, какие команды запускать и какой лимит времени действует. Любая команда вне списка должна останавливаться до ручного подтверждения. Это тот же принцип минимальных прав, который полезен при проверке любого ИИ-агента перед доступом к системе.

Шаг 2. Дайте исследователю узкую задачу

Исследователь получает код, описание точки входа и просьбу проследить движение данных. Требуйте не общий аудит, а один путь: от HTTP-параметра до операции с базой или файловой системой. В ответе нужны файлы, функции, условия и неизвестные места. Запретите объявлять проблему доказанной. Хороший результат этой роли — проверяемая гипотеза и перечень фрагментов, которые должен открыть следующий участник.

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

Шаг 3. Попросите критика опровергнуть вывод

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

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

Шаг 4. Верификатор строит минимальный тест

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

Ограничьте объём создаваемого кода. Один тест, одна ожидаемая ошибка и команда запуска понятнее большого «исправленного» модуля. После выполнения сохраните stdout, версию окружения и изменённые файлы. Для опасных операций используйте ручной барьер и журнал; в гайде о защите от prompt injection разобрано, почему содержимое репозитория тоже следует считать недоверенным вводом.

Шаг 5. Инженер принимает решение

Человек видит не сводку, а цепочку доказательств: гипотезу, возражение, тест и точный diff. Он присваивает статус — подтверждено, отклонено или нужны данные — и коротко объясняет причину. Не заставляйте инженера подтверждать десятки карточек подряд: усталость быстро превращает контроль в декоративную кнопку.

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

Шаг 6. Сведите результаты в короткий журнал

На каждый кандидат достаточно строки: commit, класс риска, файлы, решение критика, команда воспроизведения, статус человека и время проверки. Отдельно отмечайте ложные тревоги. Через десять–двадцать случаев станет видно, какие роли приносят сигнал, а какие повторяют друг друга.

Не меняйте сразу модель, запрос и набор инструментов. Иначе улучшение нельзя будет связать с причиной. После каждой версии прогоняйте несколько старых подтверждённых и отклонённых случаев. Такой небольшой регрессионный набор ценнее субъективного впечатления от нового ответа.

Когда остановить эксперимент

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

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

FAQ

Обязательно ли использовать три разные модели?

Нет. Важнее независимые контексты и разные цели ролей. Разные модели полезны как дополнительная проверка, но сначала убедитесь, что процесс работает хотя бы с одной.

Что делать, если исследователь и критик не согласны?

Передать случай инженеру и явно показать обе аргументации. Не усреднять оценки и не выбирать ответ по уверенности формулировки.

Можно ли запускать такой контур в CI?

После локального пилота — да, но сначала в режиме отчёта без блокировки сборки и без права менять код. Автоматические действия добавляют только после устойчивой проверки на контрольном наборе.