Loop engineering: проектируем цикл, который сам ставит задачи AI-агенту
Почему узкое место агентных циклов — верификатор, как складываются четыре вложенных цикла и какие ограничители и точки проверки человеком делают автономного агента для кода безопасным.
Хватит скармливать агенту инструкции по одной. Постройте цикл, который будет делать это за вас. У этого сдвига в мышлении уже есть название — loop engineering, и он меняет то, на что вы тратите часы, работая с AI-агентами.
Проблема двух часов ночи
Представьте поздний вечер с агентом для кода. Он пишет патч. Вы запускаете тесты, и три падают. Вы вставляете красный вывод в чат и пишете «почини». Агент пробует снова, и вы снова вставляете. К пятому кругу до вас доходит: каждое ваше сообщение механическое. Запусти тесты. Прочитай ошибку. Укажи на вероятную причину. Попробуй ещё раз. Остановись, когда всё зелёное.
Вы — самый способный компонент этой системы, а вас используют как буфер обмена.
Тысячи инженеров упёрлись в ту же стену примерно в середине 2026 года, и вывод из этого получился прямолинейным: перестаньте писать промпты агенту и спроектируйте цикл, который будет писать их за вас.
От промптов к циклам
Loop engineering — последняя ступень лестницы, по которой отрасль поднимается уже несколько лет. Каждая ступень оборачивает предыдущую, а не заменяет её. Сначала настраивали слова, потом данные, потом окружение. Теперь проектировать предстоит сам цикл.
- Prompt engineering (примерно 2022–2024) спрашивает, какие слова использовать. Его предел очевиден: никакая формулировка не даст модели факт, которого она не получила.
- Context engineering (2025) спрашивает, какие данные модель видит в момент инференса.
- Harness engineering (начало 2026) спрашивает, что окружает модель: инструменты, песочница, валидаторы.
- Loop engineering (2026) спрашивает, какой цикл должен работать и когда он заканчивается.
Вместе с этим меняется и ваша роль. Вы начинаете оператором, набирающим промпты, становитесь менеджером, присматривающим за несколькими агентами параллельно, и в итоге превращаетесь в проектировщика систем. На этом этапе вы формулируете, что значит «хорошо» и «готово», а потом позволяете машине добиваться этих целей.
Рабочее определение такое. Loop engineering — это осознанное проектирование цикла, в котором работает агент, включая его триггер, цель, проверки, память и правила остановки, вместо того чтобы вручную писать каждую следующую инструкцию.
Любой агент уже работает в цикле
Подвох в том, что агентов без цикла не бывает. Почти у всех он есть, и мало кто формирует его намеренно. Именно этот разрыв отделяет агента, который спокойно доводит работу до конца, от того, который за ночь сжигает бюджет, будучи уверенным, что продвигается.
В основе лежит паттерн ReAct из 2022 года: подумать, действовать через вызов инструмента, посмотреть на результат, повторять до готовности. Ничего нового. Изменилось в 2026 году то, что этот цикл стали считать главным объектом инженерии и относиться к нему с той же тщательностью, что и к API. Когда агенты для кода различаются по качеству, причина редко в базовой модели. Обычно — в устройстве цикла.
Узкое место — верификатор
Если запомнить одну мысль, пусть будет эта. В любом цикле результат ограничивает верификатор, а не модель.
Цикл — это просто генератор, подключённый к верификатору. Генератор, то есть модель, дёшев и никогда не устаёт, так что тысяча попыток почти ничего не стоит. А вот верификатор решает, превратится вся эта активность во что-то полезное или в кучу мусора.
Циклы вообще окупаются благодаря асимметрии, которую иногда называют законом верификатора: во многих задачах проверить ответ гораздо проще, чем его получить. Вот и вся экономика. Сгенерировал, проверил, сгенерировал заново — и всё равно в плюсе, потому что проверка стоит так мало.
Верификаторы бывают двух видов, и выбор между ними — большая часть мастерства:
- Детерминированные проверки запускают тесты, валидируют схему или сверяют оценку. Они дешёвые, надёжные и их трудно обмануть, так что предпочитайте их везде, где возможно.
- Схемы LLM-as-judge поручают второй модели оценить результат по рубрике. Они подходят для размытых целей, но их можно обыграть, а искажения, связанные с позицией, многословностью и предпочтением собственных ответов, хорошо задокументированы.
Риск легко не заметить. Слабый верификатор не падает с грохотом. Он уверенно выдаёт мусор, сотни раз подряд. Поэтому написание верификатора и стало новым prompt engineering.
Складывайте циклы вокруг циклов
Ремеслом это делает вложенность. Представьте четыре концентрических цикла, каждый со своими, всё более медленными часами. Внутренний выполняет работу, а каждое внешнее кольцо делает систему надёжнее, автономнее и в итоге способной улучшать саму себя.
- Агентный цикл. Модель вызывает инструменты, пока задача не решена.
- Цикл верификации. Оценщик сравнивает результат с рубрикой и возвращает его с замечаниями, если тот не дотягивает.
- Событийный цикл. Запуски стартуют по вебхукам, cron-задачам или входящим сообщениям, так что агент работает, пока вы спите, а человек может одобрить результат до того, как что-то уйдёт в релиз.
- Цикл hill climbing. Отдельный агент-аналитик читает продакшен-трейсы и переписывает сам harness: промпты, инструменты и рубрику. Система улучшает систему.
Обычно советуют двигаться наружу, к третьему и четвёртому циклам, где выигрыш накапливается. Это разумно, с одной оговоркой. Четвёртый цикл вокруг слабого верификатора просто автоматизирует уверенный мусор в промышленных масштабах. Так что наращивайте внешние слои ради охвата, но только когда самый внутренний верификатор надёжен.
Пишите контракт, а не промпт
Вот как этот сдвиг выглядит на практике. Вы перестаёте писать инструкции и вместо этого пишете определение «готово» — функцию награды плюс правило остановки — и позволяете циклу к нему стремиться:
Goal: get the test suite passing.
Done when: all tests green - and no test was skipped or deleted to fake it.
Loop: run tests -> read failures -> fix the likely cause -> run again.
Stop when: done, or after 6 rounds (then summarize what's left).
Модель не получила ни одной инструкции — это и есть loop engineering в самом минимальном виде.
Ограничьте цикл, иначе он ограничит ваш бюджет
Цикл умножает ваши усилия, и это работает в обе стороны. Дайте каждому циклу три выхода: успех, когда верификатор проходит; капитуляция, когда исчерпан лимит или бюджет; передача, когда дело эскалируется человеку. Главное правило: завершение цикла должен гарантировать harness, а не агент.
У каждого типичного сбоя есть свой ограничитель:
- Бесконечное кружение лечится жёстким лимитом итераций и обнаружением прогонов без прогресса.
- Неконтролируемые расходы лечатся проверкой бюджета перед каждым вызовом и дешёвой сортировкой перед дорогой работой.
- Выдуманное «готово» лечится отдельным детерминированным верификатором. Никогда не позволяйте агенту оценивать собственную работу.
- Взлом награды лечится ужесточёнными критериями и обязательным одобрением человека для чувствительных действий.
Прежде чем запускать цикл без присмотра, проверьте верификатор на заведомо хороших и заведомо плохих примерах. Убедитесь, что он отвергает плохой результат, а не только принимает хороший. Непроверенный верификатор — это всего лишь мнение.
Держите руки на руле
Автоматизация не означает выход из процесса. Ставьте контрольную точку для человека там, где это важно: одобрение рискованных вызовов инструментов, оценка критичных результатов, согласование перед тем, как изменение harness пойдёт в работу. Есть и более тихая цена. Когда цикл выпускает исправление, вы выпускаете то, что, возможно, не до конца понимаете. Этот разрыв назвали долгом понимания, и он вполне может стать следующей формой технического долга.
Вся этика умещается в одно предложение: стройте цикл, но стройте его как человек, который собирается оставаться инженером, а не просто тем, кто нажимает «старт».
И снова два часа ночи
Снова два часа ночи, и на этот раз вы спите. Несколько часов назад сработал вебхук. К утру вас ждёт черновой pull request. Цикл остановился перед мержем, потому что это решение ему не разрешено принимать в одиночку, и оставил аккуратное описание того, что изменилось и почему.
Вы больше не буфер обмена. Вы тот, кто спроектировал механизм, и каждая его деталь восходит к вашему решению: цель, верификатор, лимиты и места, где он обязан остановиться и спросить.
Это и есть loop engineering. Постройте свой цикл — и постройте его так, чтобы остаться инженером.