Выкатка и сопровождение: ревью, ворота и замыкание цикла
До продакшена агентные изменения доходят через те же ворота, что и человеческие: ревью, защита веток, согласование выкатки. Меняются две вещи: первое ревью начинается через минуты после открытия пул-реквеста, а каждое согласование оставляет запись, по которой процесс можно измерять.
Агент в ревью пул-реквестов
Заголовок раздела «Агент в ревью пул-реквестов»Первый проход по каждому пул-реквесту (pull request) делает агент: баги и логика, безопасность, соответствие спецификации. Систематичность здесь важнее гениальности: агент проверяет один и тот же список на каждом изменении, не устаёт к пятому файлу и не пропускает пятничный пул-реквест.
Человек в этой схеме отвечает на два вопроса, которые агенту не делегируются: делает ли изменение то, что задумано в намерении, и приемлем ли риск. Право одобрения остаётся только у владельцев кода и закрепляется защитой веток, а не договорённостью. Стандарты ревью и уровни серьёзности замечаний описываются в отдельном файле, обычно REVIEW.md, куда не входит то, что уже ловит CI. Повторяющиеся находки ревью переезжают в файл памяти: ошибка, пойманная дважды, в третий раз не должна доходить до пул-реквеста.
Метрики: время до первого ревью и соотношение дефектов, пойманных до слияния, к инцидентам в продакшене.
Хуки как ворота согласования
Заголовок раздела «Хуки как ворота согласования»Хук срабатывает до действия агента и выносит вердикт: разрешить, спросить человека, заблокировать. На этапе выкатки хуки работают воротами согласования (approval gate): например, скрипт перед любой командой в продакшен проверяет переменную одобрения релиза и без неё останавливает агента. Инструкцию модель может забыть, хук сработает всегда, поэтому скилы годятся для советов, а ворота строятся на хуках.
Какие ворота нужны, решают руководители и комплаенс; кодирует их платформенный инженер в настройках харнеса. В регулируемых отраслях настройки распространяются централизованно, так что обойти ворота на своей машине инженер не может. Хуки пишут метку времени и вердикт в журнал, и время ожидания согласований из ощущения «выкатка вечно висит» превращается в число.
Агент в конвейере CI/CD
Заголовок раздела «Агент в конвейере CI/CD»Внутри конвейера агент работает без интерфейса, headless-запуском: разбирает упавшие сборки и предлагает диагноз, собирает черновик списка изменений, готовит заметки к релизу. Доступ устроен по правилам из Безопасности и приватности: изолированная среда, короткоживущие токены вместо постоянных ключей, запись только через пул-реквест.
Сама выкатка, статус и откат оформляются как узкие MCP-инструменты: агент получает список разрешённых действий вместо терминала с производственными доступами. Автономия распределяется по средам: в dev агент действует свободно, в staging с подтверждениями, в продакшен только через ворота релиз-менеджера.
Страница Рабочий цикл относит операции с продакшеном к ярусу «только вручную», и ворота этому не противоречат: они переводят продакшен из «агенту нельзя никогда» в «нельзя без записанного человеческого решения». Порог остаётся человеческим, меняется лишь форма: вместо инженера, вручную набирающего команды, человек, нажимающий «разрешаю» у ворот.
Сопровождение: аномалия становится новым intent.md
Заголовок раздела «Сопровождение: аномалия становится новым intent.md»После выкатки за системой следит не агент, а детерминированный скрипт со статистическими порогами: доля падений CI, ошибки после релиза, время цикла пул-реквеста. Ярусы реакции растут с уверенностью сигнала: слабое отклонение попадает в журнал, устойчивое получает диагностику агентом, подтверждённое превращается в предложение изменения.
Здесь цикл замыкается: подтверждённая аномалия оформляется как новый intent.md и проходит тот же путь, что и идея человека, через спецификацию, сборку и ревью. Инцидент вдобавок пополняет набор эвалов, чтобы та же регрессия второй раз не добралась до продакшена. Пороги, права и инструкции реагирования версионируются в репозитории, как и всё остальное в цикле.
Метрики всего цикла
Заголовок раздела «Метрики всего цикла»Каждый этап несёт свои метрики, а итог цикла удобно сводить к метрикам DORA (DevOps Research and Assessment): частота выкаток, время от коммита до продакшена, доля неудачных изменений, время восстановления. К ним добавляется доля падений конвейера, разобранных агентом без вызова человека. Если перестройка цикла работает, первые два числа растут, вторые два не ухудшаются: скорость приходит не ценой качества.
Что дальше
Заголовок раздела «Что дальше»- Жизненный цикл разработки с агентами: вернуться к карте всего цикла.
- Безопасность и приватность: почему доступы агента в конвейере устроены именно так.
- Субагенты и расширения: механика хуков, на которой стоят ворота.