С чего начать loops в Claude Code

Вокруг loops для кодинговых агентов быстро появился шум, хотя сама идея простая: агент повторяет работу до заранее понятной остановки. Полезно смотреть на loop как на маленькую систему с запуском, проверкой результата, лимитом попыток и правилом остановки.

В Claude Code такие системы собираются из нескольких примитивов: обычного запроса, /goal, /loop, /schedule, навыков проверки, ревью вторым агентом и автоматического режима. Разница между ними в том, кто запускает работу, как она останавливается и насколько безопасно отдавать ей самостоятельность.

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

Что считать loop

Loop - это повторяемый рабочий процесс агента. На каждом проходе агент собирает контекст, действует, проверяет результат и решает, продолжать или завершить работу. Снаружи это может выглядеть как один запрос, команда /goal, периодическая проверка PR или полностью автономная рутина.

При проектировании удобно отвечать на четыре вопроса:

Что запускает работу: человек, таймер, событие или расписание.
Что считается завершением: тесты, метрика, пустая очередь, смерженный PR, ручная остановка.
Какая команда или возможность Claude Code используется.
Для какого типа задач этот loop действительно подходит.

1. Turn-based loop: обычный запрос

Запуск: пользовательский запрос.
Остановка: Claude считает задачу выполненной или просит контекст.
Подходит для: коротких разовых задач и исследования кода.
Контроль расхода: конкретный запрос и сильная проверка результата.

Каждый запрос к агенту уже запускает ручной loop. Например, вы просите добавить кнопку лайка. Claude читает код, вносит изменение, запускает проверки и возвращает результат, который считает готовым. Дальше человек смотрит работу и пишет следующий запрос.

Главное улучшение для такого формата - вынести ручную проверку в SKILL.md. Чем больше проверок можно выполнить инструментами, тем меньше зависимость от ощущения модели, что задача готова.

---
name: verify-frontend-change
description: Проверять любое изменение UI сквозным способом перед статусом готово.
---

# Проверка frontend-изменений
Не сообщай о готовности UI-изменения после одной успешной правки.
Проверяй результат так, как это сделал бы ревьюер:

1. Запусти dev server и открой измененную страницу в браузере.
2. Взаимодействуй с изменением напрямую. Для новой кнопки, поля ввода или переключателя нажми элемент, проверь ожидаемое состояние и сделай скриншоты до и после.
3. Проверь консоль браузера: новых ошибок и предупреждений быть не должно.
4. Через Chrome DevTools MCP запусти performance trace и проверь Core Web Vitals.

Если шаг не прошел, исправь проблему и запусти проверку с первого пункта.

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

2. Goal-based loop: /goal

Запуск: ручная команда в текущей сессии.
Остановка: цель достигнута или исчерпан лимит ходов.
Подходит для: задач с проверяемым критерием готовности.
Контроль расхода: точное условие успеха и ограничение числа попыток.

Один проход часто слишком короткий для сложной задачи. Команда /goal продлевает работу агента до выполнения заданного критерия. Когда Claude пытается остановиться, модель-оценщик проверяет условие и возвращает его к работе, если цель еще не достигнута.

Лучше всего работают детерминированные критерии: число прошедших тестов, отсутствие ошибок линтера, порог Lighthouse, покрытие, успешный билд. Чем меньше размытости в фразе "готово", тем меньше лишних ходов.

/goal доведи оценку Lighthouse на главной странице до 90 или выше, остановись после 5 попыток.

У /goal должно быть два явных ограничения: что считать успехом и когда прекращать попытки. Иначе стоп-условием легко становится лимит сессии, бюджет токенов или усталость человека, который наблюдает за процессом.

3. Time-based loop: /loop и /schedule

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

Иногда сама задача постоянная, меняются только входные данные. Утренний дайджест Slack, проверка очереди задач, наблюдение за CI, реакция на новые комментарии в PR - все это естественные кандидаты для временного loop.

Команда /loop повторяет запрос через интервал на вашей машине:

/loop 5m проверь мой PR, обработай замечания ревью и исправь падающий CI

Если компьютер выключится, локальный /loop остановится. Для облачного запуска нужен /schedule, который переносит регулярную работу в рутину.

Интервал должен соответствовать скорости изменения среды. Проверять CI каждые 30 секунд обычно дороже, чем полезнее. Для многих задач достаточно запускаться реже или реагировать на событие через webhook.

4. Proactive loops: рутина без человека в моменте

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

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

Такой сценарий может использовать /schedule для запуска, /goal для критерия готовности, навыки для проверки, параллельных агентов для исследования вариантов и ревью вторым агентом перед финальным действием.

/schedule every hour: проверь канал project-feedback на новые баг-репорты. /goal: остановись только после того, как каждый найденный за этот запуск отчет классифицирован, обработан и получил ответ. Если нужно чинить баг, запусти три решения в параллельных worktrees и передай результат отдельному агенту на строгую проверку.

Чем дальше loop от человека, тем важнее границы: список разрешенных действий, права на запись, лимит расходов, журнал решений, откат изменений и независимая проверка перед внешними побочными эффектами.

Качество держится на системе вокруг агента

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

Минимальный набор для надежной работы:

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

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

Как управлять расходом токенов

Loops легко создают скрытый расход, потому что каждый новый проход читает контекст, вызывает инструменты и генерирует рассуждения. Управлять этим можно до запуска.

Выбирайте самый простой примитив. Короткая задача может остаться обычным запросом.
Задавайте проверяемый критерий готовности и лимит попыток.
Перед большим запуском прогоняйте малый срез, особенно если динамические рабочие процессы могут поднять десятки или сотни агентов.
Детерминированную работу переносите в скрипты. Скрипт дешевле, чем повторное рассуждение модели по тем же шагам.
Интервалы делайте настолько редкими, насколько позволяет задача.
Смотрите статистику: /usage показывает расход по навыкам, подагентам и MCP, /goal без аргументов показывает ходы и токены текущей цели, /workflows показывает расход каждого агента.

Как выбрать первый loop

Начните с работы, где вы регулярно становитесь узким местом. Затем решите, какую часть можно передать системе.

Turn-based: вы отдаете агенту выполнение, но проверку держите у себя. Подходит для исследования и разовых правок. Главный инструмент - навык проверки.
Goal-based: вы отдаете условие остановки. Подходит, когда известно, как выглядит готовый результат. Главный инструмент - /goal.
Time-based: вы отдаете запуск по времени. Подходит, когда работа живет снаружи проекта и меняется по расписанию. Главные инструменты - /loop и /schedule.
Proactive: вы отдаете целый повторяемый процесс. Подходит для регулярной, хорошо ограниченной работы. Нужны расписание, цель, навыки, ревью и контроль прав.

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

Хороший loop не делает агента магическим. Он просто превращает повторяемую работу в управляемую систему: понятный запуск, проверяемый результат, видимый расход и безопасная остановка.

Источник: https://x.com/ClaudeDevs/status/2074208949205881033

Сообщество энтузиастов - https://t.me/agents_lab