От автора: в этой статье на пять шагов разберём, как спроектировать приёмочные ворота для агента, чтобы у долго работающего интеллектуального агента были явный финиш, надёжная обратная связь и контролируемая стоимость.
Агент работает без остановки несколько часов, а то и дней, возвращает результат, который выглядит законченным, — и всё равно никто не решается слить его в основную ветку. С этой проблемой сталкиваются многие команды разработчиков. В статье — 5-шаговый метод проектирования приёмочных ворот для агента: он помогает ещё до запуска долгой задачи определить «сделано» как критерий, который машина сможет проверять снова и снова.
27 октября 2026 года один из основателей CentOS Грегори Куртцер (Gregory Kurtzer) анонсировал проект Ginux. По сообщениям, за 11 дней он в основном опирался на одну непрерывно работающую задачу Codex, оставил около 139 тысяч строк кода и заставил это независимое ядро загрузить Rocky Linux 10 и запустить systemd. Когда его спросили, как он возвращает сбившегося с пути агента в нужное русло, ответ был простым: поставить побольше ворот.
Это не очередной сборник приёмов промптинга — статья о той инженерной структуре, на которую действительно опираются долгие задачи: цель, ворота, доказательства, регрессия и условия остановки.
Главная ценность: после прочтения вы сможете написать для своего проекта набор приёмочных ворот для агента и решить, какие этапы отдать машине, а какие решения обязательно оставить человеку.
Ключевые принципы приёмочных шлюзов Agent
Приёмочные шлюзы Agent — это набор заранее определённых и воспроизводимых контрольных точек. Они показывают Agent, достигнут ли текущий результат нужного уровня, а человеку — какие доказательства стоит проверить.
| Пункт | Описание | Ценность |
|---|---|---|
| Критерии приёмки заданы заранее | Перед запуском длительной задачи чётко описаны конечная точка и цели этапов | Снижает риск, что Agent примет частичный успех за полное выполнение |
| Проверки можно выполнять | Решение принимается по командам, скриптам, CI или результатам реального запуска | Agent может итеративно работать, не дожидаясь человека |
| Проверяется поведение системы | Смотрим, как программа ведёт себя при реальном выполнении | Позволяет находить «правдоподобные» ошибочные результаты |
| Ответственность разделена между человеком и машиной | Человек задаёт архитектуру и приёмку, Agent занимается реализацией и регрессией | Человек перестаёт быть самым медленным звеном цикла |
| Бюджет под контролем | Заранее заданы число неудач, лимиты использования и условия паузы | Длительная задача не тратит ресурсы, двигаясь в неверном направлении |
Приёмочные шлюзы Agent в кейсе Ginux
Kurtzer не отдал Agent задачу «написать ядро» напрямую, а выбрал жёсткие проверки: смогут ли запускаться программы пользовательского пространства Linux и стартовать ли systemd. systemd зависит от множества системных компонентов и является центральным процессом загрузки и работы всей системы, поэтому хорошо подходит для проверки того, действительно ли ядро пригодно к использованию.
Проект работает в двух согласованных циклах. Внешний цикл ведёт человек: от видения, архитектуры и ограничений до приёмочных шлюзов, анализа реального поведения и решения — исправлять или принимать. Внутренний цикл выполняет Agent: реализует, собирает и запускает в QEMU, измеряет и разбирает сбои, вносит правки и прогоняет регрессионные тесты.
Kurtzer также предупреждает: многие сбои выдают правдоподобные результаты, хотя на деле нарушают семантику, требования изоляции или поведение жизненного цикла. Без таких проверок легко получить код, который внешне работает, но внутри устроен очень хрупко.
Почему приёмочные проверки агента должны выполняться автоматически
Инженер Cursor Лорен Тан (Lauren Tan) тоже считает верификацию важнейшим навыком при работе с агентами. В её понимании верификация — это в том числе когда агент действительно запускает код, снимает профиль CPU или дамп кучи, открывает симулятор iOS и работает с приложением так, как это делал бы пользователь.
Она публично заявляла, что может вливать в продакшен 4000 PR в месяц. Даже если на проверку каждого PR человек тратит всего 5 минут, в сумме это около 333 часов — значит, при таком масштабе система проверки обязана работать без участия человека. Этот крайний случай вызывает немало споров, но он иллюстрирует принцип, применимый и к обычной команде: агент способен работать непрерывно только тогда, когда может проверить собственный результат; если проверка невозможна, ему остаётся лишь отдать вам diff и остановиться.
Двойной цикл со схемы легко перенести на повседневный проект. Если хочется, чтобы реализацию и ревью выполняли разные модели, можно подключиться через APIYI apiyi.com и включить вызовы моделей во внутренний цикл.
Быстрый старт с контрольными точками приёмки для Agent: метод из 5 шагов
Разберём на примере типовой задачи: пусть Agent перенесёт старый REST-сервис на новый фреймворк так, чтобы существующие клиенты ничего не заметили. Проверки из примера можно заменить на свои — сборку, тесты и деплой вашего проекта.
Шаг 1. Определите системный финиш для контрольных точек приёмки Agent
Сначала сформулируйте одно предложение, которое можно наблюдать, — что должно произойти с системой, когда задача выполнена. «Завершить миграцию сервиса» — слишком размыто, а «на одной и той же пачке воспроизведённых запросов коды состояния и ключевые поля ответа у старого и нового сервиса совпадают» уже можно проверить.
Хороший финиш обычно берётся из реального сценария использования. Для Ginux финиш — это Rocky Linux 10, дошедший до systemd-таргета multi-user.target; для веб-приложения финишем может быть успешное прохождение ключевых пользовательских сценариев; для задачи с данными — совпадение результата с эталонным набором данных.
Шаг 2. Разбиваем контрольные точки приёмки агента на пять уровней
Одна только обратная связь от финального теста слишком медленная, а после сбоя агента трудно понять, где именно возникла проблема. Поэтому проверки стоит выстраивать по возрастанию стоимости выполнения: пусть дешёвые сначала отсекают очевидные ошибки.
| Уровень | Что проверяем | Пример | Действия при сбое |
|---|---|---|---|
| L1. Статические ограничения | Формат, типы, границы зависимостей | Запрет перекрёстного импорта модулей | Агент сразу исправляет |
| L2. Поведение юнитов | Логика функций и модулей | Ключевые юнит-тесты | Агент локализует и исправляет |
| L3. Интеграционные контракты | Интерфейсы, базы данных, внешние зависимости | Контрактные тесты интерфейсов | Агент сверяет расхождения и вносит правки |
| L4. Работа системы | Реальное поведение сервиса целиком | Запуск сервиса и воспроизведение запросов | Агент собирает логи и данные о производительности |
| L5. Ручная приёмка | Архитектура, риски и бизнес-компромиссы | Проверка пакета доказательств и решение о слиянии | Человек задаёт новые ограничения или останавливает задачу |
Архитектура Dune, которую построила Лорен Тан, — крайний пример для L1. Она перестроила проект через более чем 600 PR и настроила проверку графа зависимостей в CI, чтобы каталоги main и renderer в Electron не могли импортировать друг друга; заодно запретила useEffect и комментарии в коде. Возможно, эти правила не подойдут вашей кодовой базе, но сама идея превращать командные ограничения в автоматические проверки стоит того, чтобы её перенять.
Шаг 3. Оформляем приёмочные гейты агента в виде исполняемых карточек
У каждого гейта должна быть короткая карточка, которую агент может прочитать в документации проекта при запуске. Когда карточка заполнена чётко, агенту не нужно гадать, что считается «пройденным», а человек может по ней проследить доказательства.
| Поле | Требования к заполнению | Пример миграции сервиса |
|---|---|---|
| Название гейта | Назовите по поведению | Согласованность воспроизведения запросов |
| Среда выполнения | Зафиксированные версии и зависимости | Изолированная тестовая среда с фиксированным снимком данных |
| Точка запуска | Укажите одну явную команду | make gate-replay (пример команды) |
| Критерий прохождения | Используйте сравнимый результат | Все коды состояния и ключевые поля совпадают |
| Артефакты-доказательства | Сохраняйте файлы, которые можно перепроверить | Отчёт о различиях, логи сервиса, запись производительности |
| Правила защиты | Отметьте, что нельзя изменять | Приёмочные образцы и скрипт проверки доступны только для чтения |
| Стратегия при сбое | Опишите следующее действие | Если одна и та же ошибка не устранена 3 раунда подряд — пауза |
Чаще всего забывают именно о правилах защиты. Агент склонен выбирать самый простой путь здесь и сейчас; если он может изменить приёмочные образцы или ослабить скрипт проверки, результаты тестов теряют смысл. Рекомендую держать эту часть в защищённом каталоге и проверять связанные изменения в CI.
Шаг 4. Встраиваем приёмочные проверки агента в цикл автоматической регрессии
Запишите внутренний цикл в описание задачи: сначала внесите небольшое изменение, запустите проверки текущего уровня, изучите свидетельства сбоя, исправьте и снова запустите те проверки, которые уже проходили. Регрессия здесь критична: иначе агент может починить одно место и незаметно сломать другое.
В конце каждого раунда просите агента фиксировать, что изменено, какие проверки запускались, каков результат и какие вопросы остались открытыми. Контекст длинных задач постоянно растёт, и такая запись помогает следующим сессиям быстро восстановить состояние, а человеку — понять, движется агент вперёд или топчется на месте.
Приёмочные проверки должны также защищать от «ложного прохождения». При долгих прогонах особенно часто встречаются такие случаи:
| Тип ложного прохождения | Типичное проявление | Соответствующая защита |
|---|---|---|
| Тесты изменены | Неудавшиеся кейсы удалили или ослабили критерии | Файлы проверок доступны только для чтения, CI отслеживает изменения |
| Тестируется только успешный сценарий | Обычные запросы проходят, а исключительные ситуации падают | Добавить инъекцию сбоев и граничные примеры |
| Моки заменяют реальные зависимости | Все mock-тесты зелёные, а интеграционная среда падает | L4 должен запускаться на реальных сервисах |
| Вывод выглядит правильным, но семантически неверен | Логи полные, а поведение жизненного цикла ошибочно | Сравнивать состояния, тайминги и побочные эффекты |
| Локальный успех скрывает риски | Отдельная метрика улучшилась, а общая стабильность упала | На каждом этапе запускать полную регрессию |
Шаг 5. Настраиваем точки принятия решений человеком и условия остановки на этапах приёмки агента
Работа человека должна концентрироваться на суждениях, которые агенту трудно заменить. Куртцер отвечает за архитектуру, цели совместимости с Linux, операционную модель, разбор сбоев и решения об остановке; когда его не устраивает код, сгенерированный агентом, он даже закрывает IDE, сдерживает желание поправить всё вручную и вместо этого даёт новые указания.
Рекомендуется задать как минимум три типа условий паузы: несколько неудачных раундов подряд на одной контрольной точке, попытка агента изменить защищённые материалы, приближение расхода задачи к бюджету. После паузы фокус проверки тоже стоит сместить на пакет доказательств: сначала смотреть на поведение системы и риски, а уже потом решать, стоит ли углубляться в чтение diff.
Совет для быстрого старта: сначала выберите небольшой этап, который можно закрыть за день, и напишите всего 3–5 карточек контрольных точек. APIYI apiyi.com предоставляет API-доступ к моделям семейств GPT, Claude и других, упомянутым в статье, и совместим с форматами интерфейсов OpenAI и Anthropic. Существующим инструментам обычно достаточно поменять адрес API и ключ по документации; конкретные доступные модели можно уточнить на странице цен APIYI.
Как контрольные точки приёмки агента меняют стоимость длительных задач
Стоимость длительной задачи нельзя оценивать только по тому, «сколько всего токенов израсходовано». В публикациях отмечается, что токены в статистике главной страницы Cursor делятся как минимум на четыре категории: обычный ввод, вывод модели, запись в кэш и чтение из кэша — и цены у них сильно различаются. Сообщество уже пыталось оценить счёт по одному и тому же объёму в 1,5 трлн токенов, и результаты разных методик расходились очень сильно — прежде всего из-за того, что включать в тарификацию и какую долю составляет кэш.
| Компонент тарификации | Основной источник в длительных задачах | Как контролировать | Тарифный ориентир |
|---|---|---|---|
| Обычный ввод | описание задачи, логи, фрагменты кода | передавать только доказательства, связанные с ошибкой | фактические данные со страницы цен APIYI |
| Вывод модели | код, анализ и план правок | ограничивать объём вывода на каждом раунде | фактические данные со страницы цен APIYI |
| Запись в кэш | новый или изменённый стабильный контекст | сохранять стабильную структуру правил проекта | фактические данные со страницы цен APIYI |
| Чтение из кэша | контекст, переиспользуемый между раундами | следить за попаданиями в кэш и не менять префикс слишком часто | фактические данные со страницы цен APIYI |
Общую стоимость публичных кейсов можно использовать, чтобы понять масштаб проекта, но нельзя напрямую пересчитывать в цену за единицу. Сообщается, что плата Ginux за вызовы API составила около 8 000 долларов, а эксперимент Nicholas Carlini, в котором 16 параллельных агентов Claude создавали компилятор C, обошёлся примерно в 20 000 долларов. За этими цифрами стоят разные модели, схемы кэширования и структуры задач, поэтому ваш проект всё равно нужно считать отдельно.
Надёжнее сначала закрыть один полный этап, зафиксировать расход токенов по четырём категориям и количество провалов на контрольных точках, а затем посчитать по актуальным данным со страницы цен APIYI: https://docs.apiyi.com/models. Такой бюджет будет основан на вашем профиле задач и окажется надёжнее, чем просто подставлять чужую среднюю цену за единицу.
Схема выше показывает, что сами контрольные точки тоже требуют ресурсов, но позволяют выявлять ошибки раньше. Для обычной команды цель — получить достаточную уверенность за ограниченный бюджет, а не гонять самую дорогую полную проверку для каждого изменения.
FAQ по приёмочным гейтам агента
Q1: Что такое приёмочный гейт агента?
Это заранее определённая исполняемая контрольная точка, которая показывает, достиг ли агент нужного результата на текущем этапе. Полный гейт включает среду выполнения, точку входа, критерии прохождения, доказательства и стратегию действий при сбое.
Q2: Чем приёмочный гейт агента отличается от обычного CI?
CI — распространённый способ выполнения, а приёмочный гейт — более полный дизайн контроля задачи. Он проверяет не только то, проходят ли код тесты, но и задаёт поведение системы, доказательства, область регрессии, точки принятия решений человеком и условия приостановки.
Q3: Когда обязательно проектировать приёмочные гейты агента?
Когда задача требует нескольких раундов правок, затрагивает несколько модулей, выполняется долго или ошибки в выводе трудно заметить глазами, гейт стоит продумать заранее. Для одноразового маленького скрипта можно упростить, но хотя бы один рабочий способ проверки определить всё равно нужно.
Q4: Если есть приёмочный гейт агента, нужен ли ещё ручной Code Review?
Нужно. Автоматический гейт хорошо проверяет известные критерии, но выбор архитектуры, оценка рисков и финальная приёмка остаются за человеком. Kurtzer также подчёркивает, что опыт критически важен, когда нужно понять, полон ли результат и не создаёт ли локальный успех риски на уровне системы.
Q5: Как подключить модель через API и запустить этот процесс?
1. Зарегистрируйтесь в APIYI на apiyi.com и создайте API-ключ.
2. Посмотрите в центре документации `docs.apiyi.com`, уточните адрес интерфейса и способ вызова.
3. В зависимости от инструмента выберите формат OpenAI или Anthropic и завершите настройку.
4. На `https://docs.apiyi.com/models` проверьте модель и цену, затем запустите небольшой пробный прогон.
Q6: Как упростить приёмочные гейты агента при ограниченном бюджете?
Сначала оставьте дешёвые гейты L1 и L2 и запускайте их в каждом раунде; L3 и L4 перенесите на момент завершения функции или на вехи. Статистика Jellyfish по 12 000 разработчиков показывает, что типичный пользователь расходует около 51 млн токенов в месяц, и это сильно отличается от крайних случаев, поэтому частоту проверок стоит выбирать по риску задачи. Стоимость моделей смотрите по актуальным данным на странице цен APIYI.
Q7: Какие ограничения есть у приёмочных гейтов агента?
Гейты покрывают только те риски, которые в них заложены, и полностью зелёные тесты ещё не означают, что код подходит для долгой поддержки. Ginux умеет загружать Rocky Linux 10, но до производственного ядра ему ещё далеко: поддержку оборудования, стабильность интерфейсов, аудит безопасности и поддержку сообщества нельзя доказать одним запуском. Критика сообществом модели с очень частыми PR тоже напоминает, что нужно постоянно следить за сопровождаемостью кода.
Ключевые тезисы о контрольных точках приёмки для агентов
- Сначала определите конечную точку: описывайте завершение задачи через наблюдаемое поведение системы, а не через размытые цели.
- Контроль должен быть многослойным: постепенно переходите от статических ограничений к реальному запуску и ручной приёмке.
- Сохраняйте доказательства: при каждом запуске сохраняйте логи, отчёты о различиях и записи о производительности.
- Критерии оценки неизменяемы: образцы приёмки и скрипты должны быть защищены, чтобы агент не мог пойти по короткому пути.
- Регрессия — в порядке вещей: после исправления новой проблемы повторно прогоняйте связанные пройденные контрольные точки.
- Решение остаётся за человеком: архитектуру, риски, остановку и финальную приёмку определяет ответственный.
- Сначала пробный запуск с оглядкой на затраты: проверьте в небольшом масштабе через APIYI apiyi.com, а затем рассчитайте бюджет по странице цен.
Итог: начните строить автономный рабочий процесс с контрольных точек приёмки для агентов
Способен ли агент долго работать автономно — зависит от того, есть ли у него чёткая цель и надёжная обратная связь. При проектировании контрольных точек приёмки для агентов держите в голове три вещи:
- Превратите «готово» в исполнимый критерий: пусть агент оценивает прогресс по результатам выполнения.
- Отдайте машине частую проверку: сокращайте цикл обратной связи с помощью многослойных контрольных точек, автоматической регрессии и пакетов доказательств.
- Ключевые решения оставьте человеку: ответственный определяет направление архитектуры, границы рисков и момент остановки.
Рекомендую начать со следующей задачи среднего масштаба: сначала напишите карточку контрольной точки, а затем запускайте агента. Когда понадобится протестировать разные модели, подключиться можно через APIYI apiyi.com, используя интерфейсы, совместимые с форматами OpenAI и Anthropic; способ настройки — в центре документации docs.apiyi.com, а цены на модели и правила тарификации — по фактическим данным на https://docs.apiyi.com/models.
📚 Справочные материалы
- InfoQ — репортаж о проекте Ginux: как Codex строил Linux-совместимое ядро и как проходила приёмка
- Ссылка:
infoq.cn/article/OiyNEtFwV05opvsLTcvK -
Описание: включает разбор двойного цикла HDAE, масштаб проекта и анализ ограничений
-
InfoQ — репортаж о счетах за токены инженера Cursor: интенсивные агентные рабочие процессы и споры о стоимости
- Ссылка:
infoq.cn/article/q9iebpvFozfy4bgCYUyE -
Описание: включает замкнутый цикл проверки, архитектуру Dune и критику со стороны сообщества
-
Технический отчёт Ginux: технический отчёт проекта, опубликованный Gregory Kurtzer
- Ссылка:
zenodo.org/records/23682548 -
Описание: подойдёт для глубокого изучения целей исследования, методики и границ применимости результатов
-
Репозиторий Ginux на GitHub: исходный код проекта
- Ссылка:
github.com/gmkurtzer/ginux -
Описание: можно посмотреть код проекта и информацию об открытой лицензии
-
Документация и страница цен APIYI: настройка интерфейса и описание цен на модели
- Ссылка на документацию:
docs.apiyi.com - Ссылка на цены:
https://docs.apiyi.com/models - Описание: модели, цены и правила тарификации — по фактическим данным на странице
Автор: техническая команда APIYI
Технический обмен опытом: заходите на APIYI apiyi.com — обсудим с вами инженерные практики Agent; больше материалов по интеграции ищите в центре документации docs.apiyi.com.
