Що таке проєктування циклів для AI-агентів

Що означає проєктування циклів

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

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

Чому цей термін з’явився у 2026 році

Назва формується просто зараз у відкритому середовищі. Репозиторій GitHub cobusgreyling/loop-engineering набрав 9,600 зірок протягом двох місяців після першої появи (станом на July 2026) із гаслом "Stop prompting. Design the loop. Get a score.". У ньому цей підхід поділено на шість будівельних блоків: планування, worktrees, навички, plugins і connectors, sub-agents та довготривала пам’ять, що зберігається поза межами діалогу.

У ньому наведено цитату Boris Cherny, який очолює Claude Code в Anthropic:

I don't prompt Claude anymore. I have loops running that prompt Claude.

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

Жоден із цих репозиторіїв не винайшов цю практику. Той, хто запускав нічну збірку, linter у continuous integration або cron job, що створює ticket, уже знає її структуру. Новим є те, що worker усередині циклу тепер недетермінований. Через це змінюються вимоги до допоміжної інфраструктури.

Чотири складові циклу

Кожен робочий цикл має ці чотири складові. Якщо пропустити одну з них, цикл може працювати непередбачувано.

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

Перетворіть ці чотири складові на запитання — і ви отримаєте перевірку проєктування для будь-якого агента, якого плануєте залишити працювати без нагляду.

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

Таймер — найпростіший тригер. На сервері Linux таймер systemd кращий за 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 minutes повторно читає той самий репозиторій, він оплачує це кожні 30 minutes.

Витрати — причина, чому цикли зазвичай ефективніші за один довгий сеанс. Виконання, яке починається з чистого стану, виконує одне вузьке завдання та завершується, зберігає невеликий контекст. Сеанс, залишений відкритим на вісім годин, містить в історії всі попередні помилки й оплачує весь transcript під час кожного ходу.

Шаблони, формалізовані популярними репозиторіями

У репозиторії loop-engineering перелічено сім робочих шаблонів. Їх варто сприймати як перелік варіантів, а не як маніфест. Щоденний тріаж. Помічник для pull request, який відстежує коментарі під час перевірки та відповідає на них. Засіб безперервної інтеграції, який обробляє збірки зі статусом помилки. Засіб перевірки залежностей. Засіб підготовки changelog. Очищення після злиття змін. Тріаж issues.

Усі вони мають спільну рису: вузьке завдання з очевидною умовою проходження. Умова «виправити збірку, що завершується помилкою» придатна для машинної перевірки. Умова «покращити кодову базу» — ні, тому вона ніколи не стає loop. Натомість вона перетворюється на безлад із розкладом запусків.

Усі вони також мають письмовий запис. Обидва репозиторії виносять стан за межі розмови та зберігають його у файлах репозиторію: що було запущено, що виявлено і яке рішення ухвалено. Цей файл є пам’яттю loop. Саме тому другий loop може продовжити роботу першого, а не повторно шукати вже знайдене. Це також дає змогу перевірити роботу агента постфактум, оскільки контекст моделі зникає одразу після завершення запуску.

Де цикли дають збій

Причини збоїв прості й повторюються в різних командах.

• Немає контролю. Результати накопичуються, ніхто їх не перевіряє, довіра зникає, і цикл вимикають.
• Перекриття. Два запуски працюють в одній гілці або два агенти — в одному робочому дереві. Це спричиняє конфлікти, які агент потім намагається розв’язати.
• Непомітне відхилення. Цикл продовжує проходити, бо перевірка надто слабка, щоб виявити помилку.
• Необмежена область дії. Тригер, який спрацьовує під час кожного коміту в репозиторії з високою активністю, протягом дня перетворюється на проблему з витратами.

Для кожного випадку діє однакова рекомендація: звузьте завдання, зробіть перевірку точнішою та журналюйте запуск. Якщо умову успішного проходження не можна описати одним реченням, завдання ще не готове до автоматизації.

Початок без термінології

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

FAQ

Чи відрізняється розроблення циклів від розроблення промптів?

Розроблення промптів оптимізує одне повідомлення: формулювання, приклади та формат виводу. Розроблення циклів оптимізує процес навколо повідомлення: тригер, який запускає виконання, ізольоване середовище, у якому воно працює, перевірку, що приймає або відхиляє його результат, і бюджет, який його завершує. У циклі все одно потрібен якісний промпт. Але промпт більше не буде основним об’єктом щоденного налаштування, оскільки умова приймання та тригер сильніше впливають на результат.

Чи потрібен мені фреймворк для створення циклу агента?

Ні. Таймер systemd, окреме git worktree для кожного запуску, shell-скрипт, який завершується командою тестування, і ліміт витрат в обліковому записі провайдера охоплюють усі складові цього визначення. Фреймворки додають інтерфейси планування, формати спільної пам’яті та маршрутизацію між агентами. Це корисно, коли ви запускаєте кілька циклів. Але для першого циклу вони не є обов’язковою передумовою.

Що таке harness для кодової бази?

Це набір засобів, які дають агенту змогу працювати в репозиторії без присутності людини: налаштування однією командою, тести, що запускаються без взаємодії з користувачем і явно повідомляють про помилки, linter, а також спосіб розгорнути або переглянути зміни. Цей термін виник у тій самій хвилі репозиторіїв 2026 року, що й розроблення циклів. Практична перевірка проста: якщо новий учасник-людина не може однією командою перейти від клонування до успішного проходження тестів, агент також не зможе цього зробити.

Як запобігти великим витратам через цикл агента?

Встановіть обмеження у трьох місцях. Задайте TimeoutStartSec для модуля systemd, щоб завислий запуск було завершено. Обмежте кількість повторних спроб у скрипті, а не запускайте цикл до досягнення успіху. Встановіть жорсткий ліміт витрат для облікового запису API, оскільки це єдина межа, яку агент не може обійти переконуванням. Потім записуйте витрати для кожного запуску, оскільки подвоєння вартості циклу зазвичай означає, що його область дії непомітно розширилася.

Які завдання варто першими перетворити на цикл?

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