Claude Code на ночь: циклы автоматизации и Ralph Loop в 2026 году

Справочная документация Ailoot: ailoot.ai/docs/.

Что такое loop engineering и зачем он нужен#

По сути, подход сводится к новой инженерной роли: вы проектируете рабочие циклы и условия их остановки.

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

Если вы открываете Claude Code, отправляете запрос, проверяете ответ и снова пишете запрос, циклический режим позволяет автоматизировать повторяющиеся части этой работы. Для автономного запуска особенно важны понятные критерии результата и ограничители.

Чем Ralph Loop отличается от обычного запроса в Claude Code#

В основе техники — простая bash-петля вокруг агента:

while :; do cat PROMPT.md | claude-code ; done

В файле хранится один запрос, а оболочка повторяет его в цикле. Anthropic предлагает плагин ralph-loop, а в Claude Code доступны команды /loop, /goal и /batch для разных видов автоматизации.

Три встроенные команды Claude Code: /loop, /goal, /batch#

/goal ближе всего к Ralph Loop. На каждом шаге evaluator-модель проверяет, достигнута ли цель. Если нет, следующая итерация получает подсказку о том, что исправить; если условие выполнено, цикл прекращается. Условие может содержать до 4000 символов.

/batch подходит для массового однотипного изменения, например миграции API, замены компонента или переименования во множестве файлов. Каждый файл обрабатывается субагентом в отдельном git worktree, поэтому рабочие копии изолированы друг от друга.

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

Учитывайте ограничения /loop и /goal:

• Задача работает, пока открыт Claude Code. После закрытия терминала цикл прекращается. Для длительного ночного запуска используйте удалённый сервер или собственную shell-обёртку.
• Максимальный срок жизни повторяющейся задачи — 7 дней. После этого она удаляется автоматически, чтобы забытые циклы не продолжали выполняться.
• В одной сессии может быть до 50 одновременных задач.

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

Как запустить первый автономный цикл за 5 минут#

Порядок действий:

1. Откройте проект в Claude Code

   Перейдите в корень проекта в терминале и запустите claude. Дождитесь, пока Claude прочитает CLAUDE.md и проиндексирует репозиторий.

2. Определите цель и условие остановки

   Цель описывает желаемый результат. Условие остановки объясняет, как проверить завершение. Удобный вариант — команда, возвращающая код 0 или 1. Например: «Цель — пройти все 23 теста из tests/api/*.test.ts. Остановиться, когда команда pnpm test вернёт код 0».

3. Запустите /goal

   Команда:

   /goal Все тесты в tests/api/*.test.ts должны быть зелёные. Запускай pnpm test, читай ошибки, чини, прогоняй снова. Останавливайся, когда exit code = 0. Максимум 20 итераций.
   

   Claude начинает цикл: запускает тесты, изучает сбои, открывает нужный файл, исправляет проблему и повторяет запуск.

4. Задайте предел бюджета

   Следите за расходами командой /usage. Установите дневной предел токенов или денег, чтобы одна петля не израсходовала весь доступный бюджет. Используйте только тот синтаксис ограничения, который поддерживает ваша версия Claude Code.

5. Проверьте результат

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

Verifier-pattern: как Claude проверяет себя в цикле#

Есть три распространённых вида verifier:

1. Техническая проверка по коду выхода. Это самый прямой способ проверить результат. Можно запускать pnpm test, npm run lint, tsc --noEmit или playwright test: команда возвращает код успеха или ошибки. /goal также проверяет заданное условие на каждом шаге; длина условия ограничена 4000 символами.

2. Evaluator-модель. Вторая модель оценивает результат первой по заданным критериям. Такой вариант подходит там, где нельзя задать простой формальный тест, например для проверки стиля текста или соответствия дизайна бренду. В Anthropic режим ревью кода описан как способ анализировать pull request и выявлять потенциальные ошибки.

3. Собственная проверка. Это shell-скрипт с критериями, заданными вами. Например: считать задачу выполненной, если в логах нет слова ERROR, если файл output.json существует и корректно разбирается либо если страница /pricing возвращает код 200.

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

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

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

Как ограничить расходы за ночь: предел бюджета и условия остановки#

Для ночного цикла нужны три ограничителя:

1. Максимум итераций. Установите, например, --max-iterations 20. Тогда цикл не выполнит больше заданного числа шагов, даже если verifier не сработал. Если цель не достигнута, потребуется проверить задачу и вмешаться вручную.

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

3. Проверка прогресса с явным условием. Сравнение HEAD ниже замечает новые коммиты, а не все изменения кода. Используйте его только в изолированном worktree, где каждая итерация с правкой сохраняет локальный контрольный коммит до сравнения. Полезные незакоммиченные правки не меняют HEAD, поэтому без этого условия получится ложный застой. Сохраняйте результат verifier: новый коммит доказывает запись изменений, а не улучшение или успех.

Ниже — иллюстративная структура оболочки с тремя проверками. Команды запуска агента и получения стоимости зависят от runner и не являются проверенным рецептом установки CLI. До адаптации подтвердите эти интерфейсы установленной версии. Для проверки по коммитам требуйте локальный контрольный коммит каждой меняющей код итерации. Если runner оставляет незакоммиченную работу, остановитесь для просмотра, а не объявляйте отсутствие прогресса:

#!/bin/bash
PROMPT="$1"
MAX_ITER=20
MAX_COST_USD=50
COMPLETION="ГОТОВО"
PREV_HASH=""
STAGNATION=0

for i in $(seq 1 $MAX_ITER); do
  # Проверка расхода
  CURRENT_COST=$(claude usage --json | jq '.cost_usd')
  if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
    echo "STOP: budget cap $MAX_COST_USD достигнут"
    break
  fi

  # Выполнение шага
  OUTPUT=$(claude code -p "$PROMPT" --auto-accept)

  # Проверка сигнала завершения
  if echo "$OUTPUT" | grep -q "$COMPLETION"; then
    echo "STOP: completion signal"
    break
  fi

  # Прогресс коммитов: каждая итерация с правками должна сохранить коммит.
  # HEAD не замечает полезные незакоммиченные изменения.
  CURRENT_HASH=$(git rev-parse HEAD 2>/dev/null)
  if [ "$CURRENT_HASH" = "$PREV_HASH" ]; then
    STAGNATION=$((STAGNATION + 1))
    if [ "$STAGNATION" -ge 3 ]; then
      echo "STOP: stagnation 3 итерации"
      break
    fi
  else
    STAGNATION=0
  fi
  PREV_HASH="$CURRENT_HASH"
done

До расширения каркаса испытайте проверку прогресса: правка без коммита — незаписанная работа; контрольный коммит меняет HEAD; успех устанавливает отдельный verifier. Три одинаковых хеша означают отсутствие записанных изменений при этом условии, а не доказательство неизменности всех рабочих файлов. Затем можно добавить уведомления и предупреждение о бюджете. Главное — проверяемые условия остановки.

5 сценариев автономного цикла на ночь#

Сценарий 1: исправить падающие тесты

/goal В директории tests/ есть 47 падающих тестов. Цель — добиться успешного прохождения всех тестов.
Запускай pnpm test, изучай stderr, открывай файл с ошибкой, исправляй проблему и снова запускай pnpm test.
Остановись, когда команда вернёт код 0. Максимум 30 итераций.

Сценарий 2: провести крупный рефакторинг в 200 файлах

/batch Заменить старый API-клиент apiV1 на новый apiV2 во всех файлах src/**/*.ts.
Обрабатывать файлы в отдельных worktree. После замены запустить tsc --noEmit и исправить обнаруженные ошибки.
В конце объединить worktree.

Сценарий 3: ночной мониторинг сервиса

/loop 30m Каждые 30 минут проверять https://your-app.example.com/api/health.
Если ответ не 200, изучить логи и определить причину. Исправления и повторный деплой выполнять только при наличии соответствующих полномочий и проверенной процедуры.
Записывать каждую итерацию в /tmp/night-monitor.log.

Сценарий 4: импортировать большой набор данных с дедупликацией

/goal Импортировать csv-файл /tmp/import.csv (12 000 строк) в таблицу clients.
Для каждой строки проверить наличие записи с таким email: если записи нет — вставить строку, если есть — обновить её.
Записывать конфликты в /tmp/conflicts.log. Остановиться после обработки последней строки и проверить результат импорта.

Сценарий 5: конвейер подготовки статей

Для сервиса или агентства, которому нужны SEO-статьи по расписанию, цикл можно описать так:

/loop 8h Каждые 8 часов: открыть файл backlog и найти темы со статусом 'queued'.
Если есть свободная тема — запустить навык подготовки руководства.
Опубликовать в dev, изменить статус на 'review' и уведомить ответственного в Telegram.

Что передавать каждой итерации: CLAUDE.md и папка знаний#

Три слоя контекста помогают превратить разовый запрос в управляемый цикл:

1. CLAUDE.md — инструкции проекта: назначение продукта, используемый стек, правила и действия, которых следует избегать. Claude читает файл при старте сессии. Актуальные правила помогают сократить повторное изучение проекта и удерживать контекст между запусками.

2. Папка знаний — материалы о продукте, аудитории, целях, экономике и маркетинге. Это не исходный код, а сведения, которые нужны для принятия решений. Если цикл готовит статью или ответ для поддержки, он может опираться на контекст проекта из этой папки.

3. Управление контекстом — подбор материалов, которые нужны конкретной итерации. Не обязательно передавать весь репозиторий или всю папку знаний: задайте агенту релевантные файлы и инструкции. Plan Mode может помочь определить, какие материалы потребуются для задачи.

Организуйте работу так, чтобы одна сессия решала одну задачу. Если контекст чата постоянно растёт, разделение задач на отдельные сессии помогает не загружать туда лишнюю информацию.

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

Четыре типичных сбоя автономного цикла#

Сбой 1: цикл продолжается на основании ошибочного результата

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

Решение: задайте строгий verifier, например команду, которая возвращает exit code.

Сбой 2: расходы выходят за пределы

Если цикл работает без лимита, его стоимость может вырасти, пока никто не проверяет состояние.

Решение: используйте доступный механизм ограничения расходов или внешний скрипт, который проверяет значение claude usage --json и останавливает цикл при достижении заданного порога.

Сбой 3: цикл теряет контекст

Claude может принять одно архитектурное решение в первой итерации, а позднее забыть его и выбрать противоположный вариант. Это приводит к несогласованным изменениям.

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

Сбой 4: условие остановки не позволяет понять, что считать готовым

Запрос /goal "Сделать страницу красивой" не задаёт однозначного критерия. Без измеримого условия цикл может продолжаться до исчерпания лимита итераций или бюджета.

Решение: формулируйте критерий через проверяемые значения. Например, задайте пороги Lighthouse Performance и Accessibility либо укажите конкретные тесты, которые должны завершиться успешно.

Когда loop engineering не нужен#

Автономный цикл может оказаться неуместным в следующих случаях:

• Разовая творческая задача. Создание сайта для нового продукта, разработка логотипа или подготовка стратегической записки могут потребовать индивидуальных решений, а не повторения одного алгоритма.
• Нет verifier. Если нельзя задать однозначный код выхода или другой чёткий сигнал завершения, агенту будет трудно понять, когда остановиться.
• Результат оценивается субъективно. Для просьб вроде «улучши звучание текста» или «сделай интерфейс приятнее» может потребоваться решение человека.
• Новая незнакомая область. Если вы сами не знаете, по каким признакам определить готовность, сначала изучите задачу и критерии, а затем автоматизируйте повторяющиеся шаги.

Перед запуском цикла проверьте, что контекст, навыки и инструкции достаточно ясны для получения нужного результата. Иначе повторение задачи само по себе не сделает работу надёжнее.

Главный вопрос перед запуском: можно ли одной строкой описать, как определить, что Claude закончил? Если да, цикл может помочь. Если нет, сперва сформулируйте проверяемое условие.

Loop engineering добавляет автоматизацию поверх возможностей Claude Code. Для стабильной работы заранее задайте правила проекта, передайте релевантные знания и подготовьте проверяемые условия остановки. Подробнее о продуктах и документации Ailoot: ailoot.ai.