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

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

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

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

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

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

В репозитории цитируется Boris Cherny, руководитель Claude Code в Anthropic:

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

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

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

Четыре части цикла

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

• Триггер. Событие, которое запускает выполнение: таймер, 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 применяется к любой длительной задаче на сервере, независимо от того, использует ли она агент.

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

Агент, изменяющий вашу рабочую директорию, может потерять незакоммиченные изменения. 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 очищает записи, для которых директория больше не существует. Параллельные циклы становятся безопасными, поскольку два агента в двух ветках и двух директориях не могут перезаписать изменения друг друга.

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

Проверка: условие, обеспечивающее безопасность цикла

Именно это отличает цикл от 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, учит цикл считать успехом отсутствие изменений. В репозиториях со слабыми тестами получаются слабые циклы. Поэтому популярные репозитории сначала ставят задачу «сделать кодовую базу готовой для агента», а уже затем — «написать цикл».

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

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

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

Модели, формализованные в популярных репозиториях

В репозитории loop-engineering перечислены семь производственных моделей. Их стоит рассматривать как набор вариантов, а не как манифест. Ежедневная сортировка задач. Помощник для pull request, который отслеживает комментарии к проверке и отвечает на них. Средство для непрерывной интеграции, которое обрабатывает сборки с ошибками. Проверка зависимостей. Подготовка черновика журнала изменений. Очистка после слияния. Сортировка задач.

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

У них также есть письменная фиксация результатов. Оба репозитория выносят состояние из диалога в файлы репозитория: что выполнялось, что было обнаружено и какое решение принято. Этот файл служит памяти цикла. Благодаря ему второй цикл может продолжить работу первого, а не обнаруживать те же сведения заново. Это также позволяет провести последующий аудит агента, поскольку контекст модели исчезает сразу после завершения запуска.

Где циклы завершаются с ошибкой

Причины сбоев просты и повторяются в разных командах.

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

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

Начало работы без специальной терминологии

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

FAQ

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

Prompt engineering оптимизирует одно сообщение: формулировки, примеры и формат вывода. Loop engineering оптимизирует цикл вокруг сообщения: триггер, запускающий выполнение, изолированную среду, в которой оно выполняется, проверку, принимающую или отклоняющую результат, и бюджет, который завершает цикл. Внутри цикла по-прежнему нужен хороший prompt. Но prompt перестает быть главным объектом ежедневной настройки, поскольку gate и trigger сильнее влияют на результат.

Нужен ли framework для создания agent loop?

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

Что такое codebase harness?

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

Как не допустить больших расходов из-за agent loop?

Ограничьте его в трех местах. Установите TimeoutStartSec для systemd unit, чтобы зависший запуск был принудительно завершен. Ограничьте число повторных попыток внутри script, а не запускайте цикл до успешного результата. Установите жесткий лимит расходов для API account, поскольку это единственный предел, который агент не сможет обойти аргументами. Затем записывайте стоимость каждого запуска, поскольку удвоение стоимости цикла обычно означает незаметное расширение его области действия.

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

Выберите задачу с машиночитаемым условием успешного выполнения и небольшим радиусом воздействия. Исправление failed build, обновление зависимости и повторная генерация changelog подходят, поскольку test suite или diff могут подтвердить результат. Открытые задачи, такие как рефакторинг или проектирование, пока не подходят: gate не может проверить их результат. Цикл без gate — это дорогой способ накопить работу для code review.