Команда Авито встроила процесс работы ИИ-агентов в код с двумя точками одобрения

Вы просите агента сначала согласовать план, затем написать код и проверить его на стенде. Через час он приносит готовый PR, но согласование пропущено, а вместо результатов проверки — уверенное объяснение, почему всё должно работать. Добавить ещё одно предупреждение в AGENTS.md можно. Гарантии исполнения от этого не появятся.

Валерий Почтарёв из команды Checks, которая занимается антифродом в Авито, описал другой подход: перенести проверяемые требования из инструкций в скрипты и хуки. Они определяют, на каком этапе находится задача, разрешены ли правки и можно ли отдавать результат на ревью. Сетап называется af-checks-context; сейчас автор распространяет его с личного использования на команду.

Как требование превращается в блокировку

Основа системы — отдельный git-репозиторий с контекстом команды: спецификациями, планами, знаниями и описанием процесса. Репозитории сервисов лежат рядом. Сессия агента начинается с командного контекста, чтобы межсервисная задача не сводилась к содержимому одного проекта.

Дальше работает последовательность этапов: задача, план, одобрение, реализация, проверка на отдельном стенде, одобрение результата и PR на ревью. Положение задачи вычисляет скрипт по существующим артефактам. Модель не может просто объявить, что обязательный этап уже пройден.

Допустим, агент меняет проверку доступа. До одобрения плана хук блокирует правки кода в рабочем каталоге задачи. Человек подтверждает план отдельным сообщением с ключом задачи. Хук создаёт краткоживущую отметку, на основании которой команда записывает одобрение. Самостоятельно создать эту отметку агенту запрещено.

После реализации нужен отчёт со стенда. В нём проверяются вердикт pass и хэш проверенного коммита. Если агент после успешного прогона добавил ещё одну правку, прежний отчёт больше не подтверждает текущую версию. Даже маленькое изменение требует актуального свидетельства проверки.

Где первые ограничения оказались дырявыми

Самая полезная часть материала — описание неудачных проверок. Ранний гейт принимал любое непустое поле одобрения: значение false тоже проходило. Другой проверял только существование пути к отчёту, поэтому его устраивал даже каталог с нужным именем. Формально этап закрывался, фактически доказательств не было.

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

Проверка другим агентом тоже не гарантирует правоту. Однажды проверяющий нашёл противоречие между спецификацией и соседним сервисом. Его локальная копия отставала на 36 коммитов; нужное поведение уже существовало. Теперь такие находки сначала сверяют с обновлённым origin. Разделение ролей полезно, но свежесть исходных данных всё равно приходится проверять.

Что стоит перенести в свой процесс

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

За контроль приходится платить сопровождением. У автора стартовый хук выполнялся 14,6–18 секунд при таймауте 15 секунд, из-за чего контекст иногда молча не попадал к агенту. Служебные галочки меняли хэш плана и вызывали повторные согласования. Систему пришлось упростить, отделить быстрые проверки от медленных и исключить служебные строки из расчёта версии плана.

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