Авито держит ИИ-агентов скриптами, а не промптами: что такое ИИ-агент под контролем

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

Если коротко, что такое ИИ-агент в разработке: это программа на основе языковой модели, которая сама читает код, пишет его и запускает команды, а не просто отвечает в чате. Чем длиннее у неё цепочка действий, тем легче потерять договорённости.

Почему агент забывает правила из AGENTS.md?

Почтарёв называет пять причин:

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

Что понадобится?

• Отдельный репозиторий команды. В Авито его называют стором, там лежат проекты, база знаний, спецификации сервисов и описание процесса.
• Трекер задач. У Авито это Jira.
• Стенд, куда ветку сервиса можно выкатить отдельно от остальных. В Авито он называется kbranch.
• Сквозные автотесты (e2e, проверка пользовательского сценария целиком).
• Хуки, то есть скрипты, которые срабатывают автоматически при событии.
• Время на перенос договорённостей из голов в файлы. Сроков источник не называет.

Шесть шагов от карточки в Jira до архива

1. Запускайте сессию агента из репозитория команды, а репозитории сервисов держите в соседних папках. Так агент читает контекст раньше кода. Для задачи на несколько сервисов не нужно заранее выбирать «главный» репозиторий.
2. Пусть агент сначала заводит описание изменения (в Авито его называют change). В нём спецификация, дизайн, разбиение на запросы на слияние кода (PR, pull request) и тест-план. Человек одобряет план, это контрольная точка 1, до неё код трогать нельзя.
3. Изолируйте каждую задачу в отдельной рабочей копии репозитория (worktree) от свежей основной ветки. Ветка от устаревшего master уже стоила команде переделанной работы, поэтому скрипт всегда подтягивает изменения:

new-worktree.sh   # делает fetch и строит ветку от origin/master

1. Пишите автотесты параллельно с кодом. По умолчанию кейс в тест-плане автоматический. Ручной допускается только с записанной причиной: наблюдение по метрике, особая сборка или одноразовые данные.
2. Проверку на стенде отдавайте не тому агенту, что писал код, а отдельной сессии или сабагенту (вспомогательному агенту) без истории реализации. Сбои тестов из-за окружения фиксируются как FAIL с причиной. Переводить автотесты в ручные ради зелёного отчёта нельзя.
3. Перед ревью человек одобряет итог, это контрольная точка 2: разница с планом, результат прогона на стенде, описание PR. После слияния спецификация задачи вливается в спецификации сервиса, а задача уходит в ретроспективу (разбор итогов) и архив.

На каком шаге задача, решает не модель, а скрипт. Он проверяет, есть ли описание изменения, одобрен ли план, есть ли рабочая копия и коммиты, открыт и влит ли PR, есть ли отчёт. Текущим считается первый шаг с непройденным гейтом (контрольной точкой). Хук подкладывает эту позицию агенту на каждую реплику, где упомянута задача.

Одобрение человека остаётся единственным фактом, который нельзя вывести из файлов, поэтому его фиксируют отдельно. Как именно, в доступном фрагменте материала не раскрыто. Отчёт о проверке машина читает по двум полям: вердикт строго pass и хэш проверенного коммита.

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

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

Что с этого взять автору, маркетологу и предпринимателю?

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

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

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