Что такое loop engineering простыми словами

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

Это важный сдвиг мышления. Обычное общение с LLM — это серия разрозненных промптов. Loop engineering — это проектирование системы, в которой часть твоих ручных решений передаётся агенту: когда продолжать, что считать прогрессом, когда остановиться и как перепроверить результат.

Когда loop действительно нужен, а когда нет

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

Базовая анатомия любого loop’а

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

1. Триггер. Что запускает цикл: твой промпт, метрика, таймер, входящий event, расписание.
2. Действие. Что делает агент: редактирует код, читает PR, гоняет тесты, собирает баги, пишет summary.
3. Верификация. Как система понимает, что есть прогресс: тесты, CI, линтер, скриншот, diff, score.
4. Стоп-условие. Когда цикл должен остановиться: цель достигнута, новых задач нет, лимит шагов исчерпан, цикл отменён вручную.

Четыре типа loops в Claude Code

Anthropic выделяет четыре основных паттерна: turn-based, goal-based, time-based и proactive. Их удобно различать по тому, что именно ты передаёшь агенту: сам шаг, правило остановки, триггер по времени или всю процедуру целиком.

Turn-based loop: обычный агентский цикл

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

Пример хорошего запроса:
«Добавь новый переключатель в настройки, обнови связанные состояния,
прогони тесты, проверь отсутствие ошибок в консоли и напиши,
что именно было изменено и как это проверить вручную.»

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

Goal-based loop: когда нужен /goal

Команда /goal нужна тогда, когда задачу не получится решить одной короткой итерацией, но при этом можно чётко определить признак успеха. В этом случае агенту полезно не просто «пытаться», а повторять попытки, пока не будет достигнут нужный результат или пока не закончится лимит шагов.

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

Почему /goal полезнее обычного «попробуй ещё»

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

Как писать правильную цель

• Используй измеримый критерий, а не расплывчатые формулировки.
• Добавляй лимит шагов или времени.
• Указывай, как подтверждается успех: тестами, score, статусом, diff’ом.
• Лучше одна жёсткая метрика, чем три абстрактных пожелания.

Time-based loops: /loop и /schedule

Когда задача повторяется во времени, агенту уже не нужен постоянный ручной запуск. Здесь и появляются /loop и /schedule. Это циклы для регулярного мониторинга, периодических проверок и сервисных задач, которые возвращаются снова и снова.

/loop 5m проверь мой PR, обработай новые review comments
и почини упавший CI, если это возможно без ручного решения.

/schedule every hour: проверь новые баг-репорты,
сгруппируй дубликаты, проставь приоритет и подготовь ответ.

Для чего подходит time-based loop

• Мониторинг pull request’ов и CI.
• Периодическая проверка внешних каналов обратной связи.
• Дайджесты по issue tracker, Slack, Telegram, GitHub.
• Регулярная чистка backlog или triage новых задач.

Главное правило

Не ставь цикл чаще, чем реально меняется источник. Если обновления появляются раз в час, запускать проверку каждые 30 секунд — это не «оперативность», а бессмысленный расход токенов.

Proactive loops: когда агент работает почти сам

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

/schedule every hour: проверь канал с обратной связью.
/goal: не останавливайся, пока все найденные за этот запуск сообщения
не будут классифицированы, обработаны и не получат статус или ответ.

Такой режим хорош только тогда, когда workflow действительно зрелый. Если процесс сам по себе хаотичен, proactive loop просто автоматизирует хаос и делает его масштабнее.

Самая важная часть: верификация результата

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

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

Как не сливать токены впустую

Loop engineering даёт мощь, но вместе с ней приходит риск бессмысленного расхода. Ниже правила, которые стоит считать обязательными для любого серьёзного использования Claude Code.

1. Выбирай минимально достаточный primitive. Не строй proactive-систему там, где хватит одного обычного turn-based цикла.
2. Ограничивай итерации. У goal-based loop’ов должен быть максимум попыток, у time-based — разумный интервал, у proactive — границы ответственности.
3. Не заставляй модель делать то, что лучше делает скрипт. Если шаг детерминированный, выгоднее вызвать готовый shell/python-скрипт.
4. Пилоть на малом объёме. Один PR, один backlog, один канал, одна папка, а не сразу весь production workflow.
5. Анализируй фейлы и улучшай систему. Если цикл регулярно ошибается в одном месте, это не повод бесконечно перезапускать его вручную — это сигнал изменить skill, проверку или формулировку цели.

Типичные ошибки при проектировании loop’ов

Как выбрать правильный тип loop’а за 30 секунд

Пошаговый план запуска первого нормального loop’а

1. Выбери один повторяющийся bottleneck. Не «автоматизируй всё», а найди одну задачу, где ты реально тратишь время руками.
2. Сформулируй definition of done. Одним-двумя предложениями, без абстракций.
3. Придумай проверку. Тест, CI, score, линтер, статус, diff, скриншот.
4. Выбери минимальный тип loop’а. Обычно это turn-based или goal-based.
5. Добавь ограничения. Максимум шагов, допустимый интервал, условие ручной остановки.
6. Прогони пилот. На маленьком объёме, а не сразу на всей системе.
7. Собери ошибки и улучши процесс. Лучшие loop’ы рождаются не с первого раза, а после нескольких циклов настройки.

Готовые шаблоны для статьи и практики

/goal подними performance score главной страницы до 90+,
остановись максимум через 5 попыток.
Проверка:
- прогони Lighthouse
- убедись, что нет console errors
- не ломай mobile layout
- опиши, какие именно изменения дали прирост

/loop 10m проверь мой PR, найди новые review comments,
попробуй закрыть замечания, перезапусти нужные проверки,
сообщай только о блокерах, где нужен человек

/schedule every hour: собери новые баг-репорты.
/goal: не останавливайся, пока каждый найденный за запуск
репорт не будет классифицирован, объединён с дубликатами,
отмечен по приоритету и не получит ответ или статус

Что важно запомнить

Итог

Loop engineering в Claude Code полезен не потому, что делает агента «магическим», а потому, что заставляет разработчика формализовать собственную рутину: что запускает работу, какие шаги повторяются, как выглядит прогресс, как измеряется качество и в какой момент задача считается завершённой. Как только эти элементы описаны, Claude перестаёт быть просто собеседником и начинает становиться операционным инструментом.

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

Материал подготовлен на основе официального руководства Anthropic по loops и переработан в расширенное русскоязычное пособие для публикации на сайте.