В последнее время в X (бывшем Твиттере) модно говорить про «дизайн лупов» вместо простого прописывания промптов для кодового агента. Проблема в том, что если попытаться выяснить, что именно люди имеют в виду под словом «луп», ответы будут разными у каждого второго. Команда Claude Code решила зафиксировать понятие: луп — это когда агент повторяет циклы работы, пока не выполнится условие остановки. Дальше всё зависит от деталей: что запускает цикл, что его останавливает и какой инструмент Claude Code для этого используется.
В этом посте разберём четыре типа лупов по нарастающей сложности — от обычного диалога до полностью автономных циклов — и когда какой имеет смысл включать. Важная оговорка сразу: не каждой задаче нужен сложный луп. Начинать стоит с самого простого варианта и подключать эти паттерны только тогда, когда они реально решают проблему.
Turn-based: тот самый обычный диалог
Самый базовый вид лупа — это то, чем ты, скорее всего, уже пользуешься каждый день. Ты пишешь промпт, Claude собирает контекст, что-то делает, проверяет результат, при необходимости повторяет попытку и отвечает тебе. Этот цикл запускается твоим сообщением и заканчивается, когда Claude решает, что задача выполнена или ему нужно больше информации от тебя.
Классический пример: ты просишь Claude сделать кнопку «лайк». Он читает код, вносит правку, гоняет тесты и возвращает то, что считает рабочим решением. А дальше ты сам проверяешь результат руками и пишешь следующий промпт, если что-то не так.
Улучшить этот шаг проверки можно, оформив свои привычные ручные шаги в файл SKILL.md — так Claude сможет сам проверять больше своей работы, от начала до конца. Чем более измеримыми будут проверки, тем легче агенту самому оценить, справился он или нет. Вот как может выглядеть такой skill для проверки фронтенд-изменений:
---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---
## Verifying frontend changes
Never report a UI change as complete based on a successful edit alone.
1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly: click it, confirm the expected state change, screenshot before/after.
3. Check the browser console: zero new errors or warnings.
4. Use Chrome DevTools MCP to run a performance trace and audit Core Web Vitals.
Начни с малого
Если ты только начинаешь — не спешь строить сложные автономные пайплайны. Обычный turn-based цикл с хорошо описанным skill для проверки закрывает 80% повседневных задач.
Goal-based: команда /goal задаёт финиш заранее
Для более сложных задач одного «прохода» часто не хватает — агенту нужно несколько попыток. Команда /goal позволяет заранее описать, как выглядит «готово», и Claude будет итерироваться, пока цель не достигнута или не закончится лимит попыток.
Фокус в том, что как только ты явно формулируешь критерий успеха, Claude больше не решает сам, «достаточно ли хорошо» получилось — это делает отдельная модель-оценщик, которая сверяет результат с твоим условием. Если условие не выполнено, работа отправляется на новый круг. Именно поэтому лучше всего работают измеримые критерии: количество пройденных тестов, конкретный порог метрики. Пример команды:
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
Такой луп запускается вручную и в реальном времени — то есть ты сам его инициируешь, но дальше не обязан следить за каждым шагом. Он хорошо подходит для задач, у которых есть проверяемый результат: балл производительности, число прошедших тестов, конкретная метрика качества.
Time-based: /loop и /schedule работают по расписанию
Часть агентной работы повторяется регулярно: сама задача одна и та же, меняются только входные данные. Например, каждое утро суммировать сообщения в Slack. Другой сценарий — когда работа зависит от внешней системы, и проще всего периодически проверять её и реагировать на изменения. Классика — пул-реквест, который может получить код-ревью или упасть по CI.
Для этого есть команда /loop, которая перезапускает промпт с заданным интервалом:
/loop 5m check my PR, address review comments, and fix failing CI
/loop работает у тебя на компьютере — если выключишь машину, цикл остановится. Чтобы перенести такую работу в облако и не зависеть от твоего ноутбука, можно оформить её в постоянную рутину командой /schedule. Останавливается такой луп либо когда ты его отменяешь сам, либо когда работа фактически завершена — PR смёржен, очередь задач опустела.
Заметка
Разница между /loop и /schedule простая: первый живёт локально и умирает с закрытием терминала, второй — постоянная облачная рутина, которая продолжает работать без тебя.
Проактивные лупы: агент действует без человека в моменте
Самый продвинутый уровень — когда всё запускается по событию или расписанию без участия человека в реальном времени. Каждая отдельная задача внутри такого лупа завершается, когда достигнута её цель, а сама рутина работает до тех пор, пока ты её не выключишь. Такие лупы отлично подходят для повторяющихся потоков хорошо описанной работы: обработка багрепортов, триаж issue, миграции, обновления зависимостей.
Строятся такие циклы из уже знакомых кирпичиков: /schedule запускает рутину, которая проверяет появление новых репортов; /goal описывает, что считать «готово», а skills документируют, как это проверить; динамические воркфлоу (сейчас в режиме research preview) оркестрируют агентов, которые разбирают каждый репорт, чинят его и проверяют исправление; авто-режим позволяет рутине работать без постоянных запросов разрешения. Собранный вместе, такой промпт может выглядеть так:
/schedule every hour: check #project-feedback for bug reports.
/goal: don't stop until every report found this run is triaged, actioned, and responded to.
When fixing a bug, use a workflow to explore three solutions in parallel
worktrees and have a judge adversarially review them.
Как не потерять качество кода в цикле
Качество результата лупа напрямую зависит от системы вокруг него, а не только от промпта. Есть несколько принципов, которые стоит соблюдать при проектировании:
- Держи сам код чистым — Claude следует паттернам и конвенциям, которые уже есть в проекте.
- Дай Claude способ самостоятельно проверять свою работу — зафиксируй в skills, как выглядит «хорошо» именно для твоей команды.
- Держи документацию под рукой — актуальные best practices фреймворков и библиотек экономят циклы на угадывание.
- Используй второго агента для код-ревью — рецензент со свежим контекстом менее предвзят и не подвержен логике основного агента. Подойдёт встроенный skill
/code-reviewили Code Review для GitHub.
Если результат не дотягивает до стандарта, не останавливайся на точечном фиксе — постарайся закодировать урок в систему, чтобы улучшить все будущие итерации, а не только эту.
Как контролировать расход токенов
У лупов должны быть чёткие границы, иначе они легко съедают бюджет токенов. Вот на что стоит обращать внимание:
- Выбирай подходящий примитив и модель под задачу — маленьким задачам не нужны множественные агенты и сложные лупы, а часть работы вообще можно отдать более дешёвой и быстрой модели.
- Формулируй чёткие критерии успеха и остановки — конкретика помогает Claude добраться до решения быстрее (но не слишком быстро, в ущерб качеству).
- Тестируй на малом объёме перед большим запуском — динамические воркфлоу могут порождать сотни агентов, поэтому сначала оцени расход на небольшом куске работы.
- Для детерминированной работы используй скрипты — запустить скрипт дешевле, чем каждый раз заново рассуждать над шагами. Например, skill для заполнения PDF-форм может поставляться со скриптом, который Claude просто запускает, а не выводит код с нуля.
- Не запускай рутины чаще, чем нужно — интервал должен соответствовать тому, как часто реально меняется то, что ты отслеживаешь.
- Проверяй расход через
/usage— команда показывает разбивку по skills, субагентам и MCP;/goalбез аргументов покажет число попыток и потраченные токены;/workflowsпокажет расход каждого агента, и любого можно остановить в любой момент.
Важно
Прежде чем запускать динамические воркфлоу на весь проект, прогони их на небольшом кусочке работы и посмотри на реальный расход токенов — сотни параллельных агентов способны быстро исчерпать бюджет.
Как выбрать подходящий тип лупа
Если свести всё в одну таблицу, получится удобная шпаргалка для старта:
| Тип лупа | Что ты передаёшь Claude | Когда использовать | Инструмент |
|---|---|---|---|
| Turn-based | Проверку результата | Ты исследуешь задачу или принимаешь решения по ходу | Кастомные skills для верификации |
| Goal-based | Условие остановки | Ты точно знаешь, как выглядит «готово» | /goal |
| Time-based | Момент запуска | Работа происходит вне проекта, по расписанию | /loop, /schedule |
| Проактивный | Сам промпт | Работа повторяющаяся и хорошо описана | Всё вышеперечисленное + динамические воркфлоу |
Чтобы начать пользоваться лупами на практике, посмотри на работу, которую уже делаешь регулярно, и найди в ней задачу, где ты сам являешься узким местом. Спроси себя: можно ли написать проверку для результата? Насколько чётко сформулирована цель? Приходит ли эта работа по расписанию? Как только появится ответ хотя бы на один из этих вопросов — запускай луп, наблюдай, где он застревает или, наоборот, делает слишком много, и не бойся его донастраивать.
Частые вопросы
Что вообще такое agentic loop в Claude Code?
Это цикл, в котором агент повторяет работу — собирает контекст, действует, проверяет результат — до тех пор, пока не выполнится условие остановки. Даже обычный диалог с Claude технически является простейшим таким циклом: ты пишешь промпт, Claude отрабатывает один проход и отдаёт результат тебе на проверку.
В чём разница между /goal и /loop?
/goal определяет, когда луп должен остановиться — по достигнутой цели или по лимиту попыток, и подходит для задач с проверяемым результатом (например, определённый балл производительности). /loop определяет, когда луп должен запуститься — по интервалу времени, и больше подходит для повторяющейся работы или для наблюдения за внешними системами вроде пул-реквестов.
Нужны ли мне сложные лупы, если я только начал пользоваться Claude Code?
Нет, необязательно. Команда Claude Code прямо советует начинать с самого простого решения — обычного диалога с хорошо описанным skill для проверки результата — и подключать более сложные типы лупов только тогда, когда конкретная задача правда повторяется или требует нескольких итераций.
Как понять, что луп сжигает слишком много токенов?
Для этого есть встроенные команды мониторинга: /usage показывает расход по skills, субагентам и MCP-подключениям, /goal без аргументов — число сделанных попыток и токены, потраченные на текущую цель, а /workflows — расход каждого отдельного агента, причём любого из них можно остановить вручную в любой момент.
Можно ли комбинировать разные типы лупов между собой?
Да, и именно так строятся проактивные лупы — самый продвинутый вариант. Они собираются из /schedule (запуск по расписанию), /goal (критерий готовности), skills (как проверить результат) и динамических воркфлоу (оркестрация нескольких агентов), плюс авто-режима, чтобы рутина не останавливалась и не спрашивала разрешения на каждом шаге.
Главный вывод простой: не все задачи нужно превращать в сложный автономный конвейер. Лупы — это лестница, а не обязательный маршрут: обычный диалог с хорошей проверкой закрывает большинство рутины, /goal включается, когда у задачи есть измеримый финиш, /loop и /schedule — когда работа привязана к расписанию или внешней системе, а проактивные циклы стоит собирать только под по-настоящему повторяющиеся и хорошо описанные потоки задач.
Источник
По мотивам статьи Anthropic Getting started with loops. Пересказали по-русски для новичков.