Что такое проектирование циклов в AI-агентах

Что означает проектирование циклов

Проектирование циклов — это практика разработки повторяющегося процесса, в котором работает AI-агент: что его активирует, к каким ресурсам он получает доступ, как проверяется его вывод и что служит условием остановки. Prompt engineering формирует одно сообщение для модели. Проектирование циклов формирует процесс, который отправляет тысячи сообщений, пока вы спите. Единица работы смещается от промпта к циклу.

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

Почему этот термин появился в 2026 году

Название закрепляется в публичном поле прямо сейчас. Репозиторий GitHub cobusgreyling/loop-engineering набрал 9,600 звезд за два месяца с момента появления (по состоянию на июль 2026 года) под лозунгом "Хватит писать промпты. Проектируй цикл. Получай результат". Он объединяет этот сдвиг в шесть базовых блоков: планирование, рабочие деревья (worktrees), навыки, плагины и коннекторы, субагенты и долговременная память, хранимая вне контекста диалога.

В нем приводится цитата Бориса Черного, руководителя направления Claude Code в Anthropic:

Я больше не пишу промпты для Claude. У меня запущены циклы, которые сами пишут промпты для Claude.

Второй репозиторий, AI-Builder-Club/skills, имеет около 1,100 звезд (по состоянию на июль 2026 года) и прямо называет две роли: "обвязка кодовой базы" (codebase harness), которая подготавливает репозиторий для безопасного запуска тестов и развертывания агентом, и "инженер циклов" (loop engineer), который создает рабочие процессы, запускающиеся по триггеру, выполняющие работу и записывающие полученные данные в общий файл, чтобы следующий цикл мог их прочитать.

Ни один из этих репозиториев не изобрел данную практику. Любой, кто запускал ночную сборку, линтер в системе непрерывной интеграции или cron-задачу, открывающую тикет, уже знаком с этой структурой. Новизна заключается в том, что исполнитель внутри цикла теперь недетерминирован, что меняет требования к окружающей его инфраструктуре.

Четыре компонента цикла

Любой рабочий цикл состоит из этих четырех компонентов. Если в цикле отсутствует хотя бы один из них, он станет причиной вашего пробуждения в 3 часа ночи.

• Триггер. Событие, запускающее выполнение: таймер, webhook, новый pull request или оповещение.
• Границы. Файлы, учетные данные и сетевые ресурсы, к которым агент может обращаться во время выполнения.
• Верификация. Проверка с кодом завершения, которая определяет, следует ли сохранить результат выполнения или отбросить его.
• Бюджет. Ограничение по токенам, времени или деньгам, которое завершает выполнение независимо от того, было ли оно успешным.

Сформулируйте эти четыре компонента в виде вопросов, и вы получите план проверки дизайна для любого агента, который собираетесь оставить в рабочем состоянии.

Триггер: что запускает агент

Таймер — это самый простой способ запуска, и на сервере под управлением Linux systemd timer лучше подходит для этой задачи, чем cron. Он ведет логи, позволяет настроить повторные попытки по вашим правилам и не запускает вторую копию юнита, если предыдущая еще выполняется. Последнее свойство устраняет самую частую ошибку наложения в циклах агента: когда два процесса одновременно вносят изменения в одну и ту же ветку.

Создайте юнит в /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

И таймер в /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers должен отобразить столбец NEXT с временем в будущем и столбец LEFT с обратным отсчетом. Пустой результат означает, что таймер не включен, так как enable без --now планирует запуск только при следующей загрузке системы. TimeoutStartSec=1800 важнее, чем кажется: агент, зависший в ожидании ввода, будет удерживать юнит в активном состоянии бесконечно, и таймер больше никогда не сработает. Просматривайте выполнение с помощью journalctl -u agent-loop.service -n 50.

Если вы все же запускаете цикл через cron, добавьте собственную защиту от наложения, так как cron без проблем запустит вторую копию:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n немедленно завершается со статусом 1, если блокировка уже удерживается, поэтому второй процесс тихо исчезает, не создавая конкуренции первому. Тот же подход настройки systemd service и timer применим к любой длительной задаче на сервере, будь то агент или что-то другое.

Граница: отдельная копия для каждого запуска

Агент, работающий с вашим рабочим деревом, может привести к потере незакоммиченных изменений. Git worktrees решают эту проблему с минимальными затратами: каждый запуск получает собственный каталог и собственную ветку, используя общее хранилище объектов.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list выводит по одной строке для каждого дерева с указанием пути, коммита и ветки. По завершении работы git worktree remove /srv/agent/work/triage-01 удаляет каталог, а git worktree prune очищает записи, чьи каталоги исчезли. Параллельные циклы становятся безопасными, так как два агента в двух ветках и двух каталогах не могут перезаписать данные друг друга.

Граница также касается учетных данных. Цикл, работающий без присмотра, использует долгоживущие токены, и каждый запуск — это риск утечки токена в лог, коммит или контекст модели. Ограничьте область действия токена одним репозиторием, с которым работает цикл, по возможности исключите его из окружения, доступного оболочке агента, и прочитайте как защитить секреты от AI-агентов, прежде чем предоставлять циклу доступ к production. Для более надежной изоляции запускайте весь цикл на одноразовой виртуальной машине, которую можно уничтожить после каждого запуска. Выбор инструмента также определяет часть границы еще до начала написания кода, поэтому стоит ознакомиться с тем, как управляемая песочница Cowork соотносится с Claude Code на вашей локальной машине, прежде чем решать, какой уровень изоляции вам необходимо реализовать самостоятельно.

Верификация: шлюз, обеспечивающий безопасность цикла

Это та часть, которая отличает цикл от cron-задачи, которая просто выполняет действия. Вывод агента — это предложение. Шлюз принимает решение.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail выполняет реальную работу в этом скрипте. Без -e сбой git fetch игнорируется, и выполнение продолжается с использованием устаревших origin/main. Без -u опечатка в имени переменной превращается в пустую строку, и очистка выполняется по неверному пути, вместо того чтобы завершиться с ошибкой.

Блок if ! npm test — это суть всей концепции. Код завершения проверки, которой вы уже доверяете (вашего набора тестов или статического анализатора типов), определяет, будет ли ветка отправлена в репозиторий или удалена. Цикл без шлюза создает работу, на проверку которой ни у кого нет времени, что хуже, чем отсутствие работы вообще. Цикл со шлюзом создает ветку, которая уже прошла ту же проверку, что и ветка обычного разработчика. Успешное прохождение шлюза не говорит о том, какой объем кода затронул агент, поэтому стоит дополнить проверку инструкцией правило, заставляющее агента вносить минимально возможные изменения, что позволяет сохранять размер diff достаточно малым для быстрой проверки.

Выберите шлюз, который работает честно. Набор тестов, который проходит при пустом diff, «учит» цикл тому, что бездействие — это успех. Репозитории со слабыми тестами получают слабые циклы, поэтому популярные проекты сначала делают «кодовую базу готовой к работе агентов», а уже потом «пишут цикл». Если вы хотите узнать, действительно ли ваш набор тестов обнаружит регрессию, а не просто выполнит строки кода, используйте мутационное тестирование. А агент, который предоставляет отчет с доказательствами, пригодный для повторного запуска, вместо того чтобы заставлять вас читать diff превращает этот ответ в то, что вы можете подтвердить самостоятельно.

Бюджет: что останавливает выполнение

Агент, который повторяет попытки бесконечно, — это агент с неограниченным счетом. Установите для каждого цикла временной лимит, который обеспечивается с помощью TimeoutStartSec, указанного выше; ограничьте количество повторных попыток внутри скрипта; и настройте лимит расходов в учетной записи провайдера. Затем фиксируйте стоимость каждого запуска в логах, чтобы заметить отклонение в работе цикла до того, как придет счет. Контроль расходов для постоянно работающего VPS с агентом описывает финансовую сторону, а управление контекстом, который агент переносит между итерациями затрагивает самый значимый рычаг влияния на стоимость одного запуска, поскольку цикл, который перечитывает один и тот же репозиторий каждые 30 минут, оплачивает это каждые 30 минут.

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

Шаблоны, которые кодифицируют популярные репозитории

Репозиторий loop-engineering перечисляет семь производственных шаблонов, и их стоит рассматривать скорее как меню, чем как манифест. Ежедневная сортировка задач. «Нянька» для pull-request, которая отслеживает комментарии к ревью и отвечает на них. «Чистильщик» для continuous-integration, который берет на себя упавшие сборки. «Чистильщик» зависимостей. Составитель changelog. Очистка после merge. Сортировка issue.

Их объединяет узкая специализация с очевидным критерием завершения. У задачи «исправить упавшую сборку» есть условие успеха, которое может считать машина. У задачи «улучшить кодовую базу» такого условия нет, поэтому она никогда не превращается в цикл. Она превращается в беспорядок по расписанию.

Их также объединяет наличие письменных записей. Оба репозитория выносят состояние из обсуждения в файлы внутри самого репозитория: что было запущено, что было найдено, какое решение принято. Этот файл — память цикла, и именно благодаря ему второй цикл может опираться на работу первого, а не выполнять её заново. Это также способ провести аудит агента постфактум, так как контекст модели исчезает в момент завершения работы. Оперативная координация — это отдельный канал, и одна сессия Claude Code может передать работу другой на той же машине, пока обе они запущены, но ничто в этом обмене не переживет сессию. Поэтому файл остается тем, что вы будете изучать позже.

Почему циклы терпят неудачу

Ошибки однообразны и повторяются в разных командах.

• Отсутствие контроля. Вывод накапливается, никто его не проверяет, доверие падает, и цикл отключается.
• Перекрытие. Два запуска в одной ветке или два агента в одном рабочем дереве создают конфликты, которые агент затем пытается разрешить.
• Скрытое отклонение. Цикл продолжает проходить успешно, так как проверка слишком слаба, чтобы выявить ошибку.
• Неограниченная область действия. Триггер, срабатывающий на каждый коммит в активном репозитории, за день превращается в проблему перерасхода ресурсов.

Для каждого случая есть одно решение: сократить задачу, ужесточить проверку и логировать запуск. Если вы не можете описать условие успешного выполнения одним предложением, задача не готова к автоматизации.

Начало работы без использования фреймворков

Вам не обязательно использовать фреймворк. Небольшой постоянно работающий Linux-сервер, git-репозиторий с набором тестов, которые корректно завершаются ошибкой при необходимости, один systemd-таймер и один shell-скрипт с if внутри образуют полноценный цикл. Именно с этого стоит начать большинству пользователей, так как ответы на вопросы проектирования приходят в процессе эксплуатации, а не при выборе инструмента. Как только первый цикл становится стабильным, запуск второго сводится к созданию еще одного таймера и еще одного worktree. См. как запустить AI-агента для программирования на VPS для базовой настройки и текущие варианты self-hosted AI-агентов, если вы хотите, чтобы сам агент работал на оборудовании под вашим контролем.

FAQ

Отличается ли loop engineering от prompt engineering?

Prompt engineering оптимизирует одно сообщение: формулировки, примеры, формат вывода. Loop engineering оптимизирует цикл вокруг сообщения: триггер, запускающий выполнение, изолированную среду (sandbox), проверку, которая принимает или отклоняет результат, и бюджет, ограничивающий работу. Хороший промпт внутри цикла всё равно необходим. Промпт перестаёт быть тем, что вы настраиваете ежедневно, так как шлюз (gate) и триггер сильнее влияют на результат.

Нужен ли фреймворк для создания цикла агента?

Нет. Таймер systemd, отдельное дерево git worktree для каждого запуска, shell-скрипт, завершающийся командой тестирования, и лимит расходов на аккаунте провайдера покрывают все части этого определения. Фреймворки добавляют интерфейсы планирования, форматы общей памяти и маршрутизацию между несколькими агентами, что полезно при запуске множества циклов. Это не является обязательным условием для запуска первого цикла.

Что такое codebase harness?

Это набор инструментов, позволяющих агенту работать в репозитории без участия человека: настройка одной командой, тесты, которые запускаются в неинтерактивном режиме и выдают явные ошибки, линтер, а также способ развертывания или предварительного просмотра изменений. Термин появился в той же волне репозиториев 2026 года, что и loop engineering. Практический тест прост: если новый участник не может пройти путь от клонирования до успешного прохождения тестов одной командой, агент тоже не сможет.

Как предотвратить большие счета при работе цикла агента?

Установите ограничения в трёх местах. Настройте TimeoutStartSec для юнита systemd, чтобы зависший процесс был завершён. Ограничьте количество повторных попыток внутри скрипта вместо бесконечного цикла до успеха. Установите жесткий лимит расходов на API-аккаунте, так как это единственный потолок, который агент не сможет обойти. Ведите логи стоимости каждого запуска, так как цикл, стоимость которого удваивается, обычно означает, что область его задач незаметно расширилась.

Какие задачи стоит переводить в цикл в первую очередь?

Выберите задачу с машиночитаемым условием успешного выполнения и минимальной зоной поражения. Исправление неработающей сборки, обновление зависимости и перегенерация списка изменений подходят для этого, так как набор тестов или diff могут подтвердить результат. Задачи с открытым финалом, такие как рефакторинг или проектирование, пока не подходят, так как шлюзу нечего проверять, а цикл без шлюза — это дорогой способ накопить технический долг, требующий проверки человеком.