Loop engineering начинается не там, где агент просто повторяет prompt. Он начинается там, где вокруг повтора появляется система управления: запуск работы, проверка результата, лимиты, повторная попытка и эскалация.
Главная ошибка — считать уверенность модели доказательством. Модель может сказать «готово». Harness должен проверить, правда ли работа закончена.
Шум вокруг loop engineering полезен только в одном месте: он сдвигает внимание с промпта на систему вокруг агента. Серьёзный агент — не улучшенный prompt. Серьёзный агент — это цикл с harness вокруг него.
Цикл сам по себе может жечь деньги, повторять плохие предположения и полировать неверный ответ. Harness может сказать «нет».
Цикл — не продукт
У loop engineering есть простая интуиция: человек перестаёт вручную писать каждый следующий prompt и вместо этого проектирует систему, которая сама подаёт агенту следующий контекст, смотрит на результат и решает, продолжать ли работу. У Addy Osmani эта рамка описана именно как замена человека, который prompt’ит агента шаг за шагом, системой, которая делает это вместо него.
Мне нравится эта рамка, потому что она снимает с промпта статус магического заклинания. Prompt становится не центром архитектуры, а частью операционной процедуры.
Prompt engineering спрашивал: «Что написать модели?»
Context engineering спрашивал: «Что модель должна увидеть?»
Harness engineering спрашивал: «В какой среде модель может действовать?»
Loop engineering задаёт более холодный вопрос: «Что повторяется, что измеряется и кто имеет право объявить работу законченной?»
Базовый agent loop не новый. В документации Anthropic он описан как цикл: модель запрашивает действие инструмента, приложение выполняет это действие, возвращает результат модели, и процесс повторяется до завершения задачи или до лимита итераций.
Новая часть не в самом цикле. Новая часть — во внешнем контуре управления.
Четыре слова, которые не стоит смешивать
Я бы разделял четыре вещи.
Loop — повторяемый агентный цикл: модель получает состояние, действует, читает результат и решает, нужен ли следующий шаг.
Harness — среда вокруг цикла: инструменты, состояние, тесты, права доступа, лимиты, журнал, правила остановки и путь эскалации.
Verifier — часть harness, которая говорит, можно ли считать работу законченной: тест, dry run, валидатор, evaluator model, проверка бизнес-правил или человек.
Scheduler — только способ запустить цикл: по времени, событию, webhook, cron или вручную.
Проблемы начинаются, когда scheduler выдают за harness. Cron может разбудить агента каждый час. Сам по себе он не знает, что такое успех, не ограничивает расходы, не ловит дрейф и не решает, когда задачу надо отдать человеку.
Повтор слабого процесса по расписанию даёт не архитектуру, а больше слабых попыток.
Harness решает, когда «готово» значит готово
Loop engineering начинается там, где модель перестаёт проверять саму себя.
Для кода разница видна сразу. Модель может сказать, что патч корректен. Тестовый набор может завершиться с кодом 0. Модель может заявить, что миграция безопасна. Dry run может её отклонить.
Продакшен-правило простое: внешний сигнал говорит, что произошло, а агент пересказывает этот результат. Агент не заменяет проверку своей самооценкой.
LangChain описывает verification loop как отдельный слой: grader проверяет output агента по rubric, тестам или другим правилам и возвращает feedback обратно в цикл, если результат не проходит. В примере с docs writer проверяются ссылки, CI и границы diff; LangChain прямо отмечает tradeoff: verification повышает latency и cost, но оправдан там, где качество важнее скорости.
Claude Code hooks решают похожую задачу с другой стороны: это shell-команды, которые выполняются в конкретных точках lifecycle и дают детерминированный контроль вместо надежды, что LLM сама вспомнит сделать нужное действие.
Та же форма работает вне разработки. Агент для sales research не должен решать, что аккаунт квалифицирован, потому что сгенерированная записка выглядит правдоподобно. Harness должен проверить обязательные поля, свежесть источников, правила исключения и бюджет.
Аналитический агент не должен отмечать анализ готовым, потому что график выглядит аккуратно. Harness должен сверить число строк, определения метрик, временные окна и то, ответил ли результат на исходный вопрос.
Модель может объяснить. Harness должен проверить.
/loop и /goal сделали паттерн видимым
Anthropic сдвинула разговор не потому, что изобрела цикл, а потому что сделала его видимой функцией продукта.
В Claude Code /goal задаёт условие завершения: Claude продолжает работу across turns, а после каждого turn отдельная быстрая модель проверяет, выполнено ли условие. Если нет, Claude начинает следующий turn вместо того, чтобы вернуть управление пользователю. Документация также сравнивает /goal, /loop и Stop hook: /goal стартует следующий turn после завершения предыдущего, /loop запускается по интервалу, а Stop hook может решать через ваш script или prompt.
Это важное различие.
/loop — повтор.
/goal — повтор с условием завершения.
Stop hook — внешний способ решить, что делать после turn.
Ни одна из этих функций сама по себе не является архитектурой. Но они делают ручной паттерн видимым: больше не нужно притворяться, что агент всегда должен закончить работу одним ответом на один prompt.
Функция продукта — не harness. Она даёт повод построить harness.
Больше итераций — не стратегия
Плохая версия loop engineering выглядит так: держать агента в движении и верить, что достаточное число итераций само сойдётся к хорошему ответу.
Иногда это работает. На задачах с чёткой проверкой цикл может быть полезным: портирование кода, performance experiments, security scanning, поиск регрессий, преобразование данных. Armin Ronacher отдельно пишет, что loops особенно естественно ложатся на механические трансформации, эксперименты и задачи, где есть полезный сигнал для следующей итерации.
Но «сделай лучше» — не критерий успеха.
«Улучши лендинг», «найди больше alpha», «почисти отчёт», «сделай стратегию сильнее» — всё это приглашения тратить деньги, если harness не переводит цель в измеримые ворота.
Перед тем как запускать цикл без присмотра, я бы требовал минимум:
- лимит итераций;
- лимит времени;
- лимит стоимости;
- область, где агент имеет право действовать;
- функцию успеха, которую можно проверить;
- функцию провала, после которой цикл должен остановиться;
- путь эскалации;
- журнал решений и результатов.
Уберите любой пункт — и у цикла останется меньше причин остановиться.
Бюджетный лимит — не только финансовая гигиена. Он задаёт семантику продукта. Ответ за $0.20 и ответ за $200 — разные продукты, даже если финальный текст похож.
Хороший loop engineering делает провал дешёвым и видимым.
Минимальный production loop
Минимальный production loop я бы описывал не через prompt, а через контракт:
- Trigger: что запускает цикл.
- Scope: где агент имеет право работать.
- State: что сохраняется между итерациями.
- Tools: какие действия разрешены.
- Verifier: что считается доказательством.
- Budget: лимит turn’ов, времени и денег.
- Stop condition: когда работа считается законченной.
- Failure condition: когда цикл признаёт, что не справился.
- Escalation: кому и что он передаёт.
- Log: где остаётся след решений.
Это скучный список. В этом и смысл. Agent loop без такого списка — это просто модель, которой разрешили дольше продолжать.
Изменения harness должны иметь прогноз
Самая полезная исследовательская опора здесь — не очередной пост про loop engineering, а paper про Agentic Harness Engineering.
В нём harness меняется не «по ощущению», а через observability: компоненты harness представлены как редактируемые файлы, траектории превращаются в evidence corpus, а каждое изменение сопровождается self-declared prediction, который потом проверяется на следующем наборе результатов.
Это правильная дисциплина для loop engineering: изменение harness должно быть не rationale, а проверяемым контрактом.
Например:
Этот валидатор должен уменьшить ложный успех на падающих тестах.
Этот лимит бюджета может увеличить число эскалаций на длинных рефакторингах.
Этот шаг извлечения памяти должен улучшить повторяющееся исследование аккаунтов, но может добавить сбои из-за устаревших источников.
Такая запись не делает систему научной лабораторией. Она просто делает следующую раскатку читаемой.
Без прогнозов команды настраивают циклы по ощущению. Добавили повтор. Расширили контекст. Сменили модель. Открыли доступ к новому инструменту. Последний demo run прошёл — значит, изменение кажется правильным. Потом регрессирует другая задача. Никто не знает, улучшился ли loop или ошибка просто переехала в менее заметное место.
AHE интересен именно тем, что ищет улучшения не только в system prompt. В arXiv-версии paper десять итераций AHE подняли pass@1 на Terminal-Bench 2 с 69.7% до 77.0%, а ablations локализуют gain в tools, middleware и long-term memory, тогда как system prompt alone регрессирует.
Это важная подсказка: часто проблема не в том, что модель «плохо поняла инструкцию». Часто проблема в harness: инструментах, памяти, middleware, формате проверки, лимитах и состоянии.
Но AHE нельзя читать как доказательство, что self-improving harness уже решён. Авторы сами называют setting высокодисперсным, ограничивают выводы benchmark-средой и предупреждают, что такие gains сами по себе не доказывают broad generalization на другие coding-agent окружения, языки и deployment settings.
Правильный вывод скромнее: прогноз, rollout, проверка и откат — это хорошая дисциплина для любого harness, даже если вы никогда не будете автоматически эволюционировать его агентом.
Циклы прячут причинность
Loop engineering нуждается в такой дисциплине, потому что циклы прячут причинность.
У одного ответа есть одна видимая точка провала. У цикла есть prompt, контекст, модель, инструменты, память, состояние, скрипты, политика повторов, условие остановки, verifier и путь эскалации.
Когда результат улучшается, причиной может быть любой элемент. Когда результат ломается, виноватым тоже может быть любой элемент.
Поэтому журнал harness становится местом, где видно, почему агентная система изменилась.
Не «мы усилили prompt», а «мы добавили проверку X, потому что она должна исправить failure mode Y, и ожидаем побочный эффект Z».
Не «мы дали больше контекста», а «мы добавили источник A в retrieval hierarchy, потому что он должен сократить ложные уточнения на задачах B, но может увеличить cost на маршрутах C».
Не «мы увеличили budget», а «мы подняли лимит до 12 turn’ов для migration route, потому что p90 успешных задач заканчивается на turn 10, а после turn 14 success rate падает».
Так loop engineering перестаёт быть красивым словом и становится обычной инженерией.
Полезная версия нарочно скучная
Полезная версия loop engineering выглядит менее глянцево, чем сам термин.
Она выглядит как shell scripts, тестовые наборы, budget counters, очереди задач, status files, rollback notes и правило, что модель не проверяет собственную домашнюю работу.
Это не обесценивает подход. Это и есть подход.
Лучшие агентные системы, которым я бы доверял в 2026 году, — не бесконечные мыслители. Это ограниченные исполнители внутри явных циклов.
Внутренний агент предлагает и действует. Внешний harness наблюдает и судит. Verifier говорит, достаточно ли доказательств. Бюджет показывает, когда амбиция превратилась в расточительство. Эскалация признаёт, где автоматизация дошла до края.
Loop engineering заслуживает хайпа только тогда, когда делает эту границу острее.
Иначе новый ярлык выглядит как prompt engineering с таймером.