Loop engineering: простое объяснение

Источник: https://x.com/akshay_pachaar/status/2069118430582866051

Автор: Akshay 🚀

Половина вашей ленты внезапно говорит одно и то же: перестаньте промптить своих агентов — начните проектировать циклы.

Борис Черный, человек, который построил Claude Code, сказал это прямо: «Я больше не промпчу Claude. У меня работают циклы. Моя работа — писать циклы».

Человек, который строит одного из самых популярных coding agents на Земле, не промптит его. Так что же он делает вместо этого?

В этом и заключается идея loop engineering. Теперь разберём, почему это сложнее, чем кажется.

Сначала сам цикл

Агент — не магическая коробка. В основе это обычный цикл:

while True:
    response = model(context)
    if response.has_tool_calls():
        results = run_tools(response.tool_calls)
        context += results
    else:
        break

Модель читает контекст. Просит вызвать инструмент. Вы запускаете инструмент и возвращаете результат обратно. Модель снова читает — и это повторяется, пока она не перестанет просить инструменты.

Модель → инструменты → контекст → повтор.

Вот что удивляет людей: сам этот цикл уже решён. Каждый серьёзный agent framework приходит примерно к этим шести строкам. Никто не конкурирует на уровне оператора while.

Если цикл тривиален, что тогда все на самом деле инженерят?

Работа сместилась за пределы модели

Центр тяжести в AI всё дальше уходит от самой модели.

• Prompt engineering — слова, которые вы отправляете.
• Context engineering — всё, что видит модель, а не только ваши инструкции.
• Harness engineering — код вокруг модели, который запускает инструменты, отслеживает состояние и обрабатывает ошибки.
• Loop engineering — автономный цикл, который ведёт всю систему к цели.

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

LangChain формулирует это просто: Agent = Model + Harness. Если вы не модель, значит вы — harness.

И вот наблюдение, которое должно перестроить приоритеты: harness теперь важнее модели. Команды оставляли модель неизменной, меняли только код вокруг неё — и прыгали из середины бенчмарка в топ-5. Тот же мозг, другой цикл.

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

Сложная часть 1: понять, когда остановиться

Это проблема, о которой никто не предупреждает.

Когда агент перестаёт просить инструменты, его ход закончился. Это не то же самое, что закончена задача.

Представьте coding agent. Он пишет код, осматривается, видит, что прогресс есть, и объявляет: готово. Тесты всё ещё падают. Но он уже объявил победу.

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

Хорошие циклы останавливаются по правильным причинам, поэтому вы добавляете несколько тормозов:

• Max iterations — жёсткий лимит, чтобы застрявший агент не работал бесконечно.
• Budget and time limits — потолок по токенам, деньгам и секундам.
• No-progress detection — если он повторяет тот же вызов с теми же аргументами, значит крутится на месте.
• Real completion check — автоматическое условие, доказывающее, что работа сделана.

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

Сложная часть 2: держать контекст чистым

Длинные циклы гниют изнутри.

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

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

С этим борются, относясь к контексту как к бюджету, а не как к ведру:

• Compaction — суммаризировать разговор, когда он становится длинным, и продолжать из summary.
• Offloading — выносить огромные выводы в файл и оставлять в контексте только нужный фрагмент.
• Sub-agents — отдавать грязную подзадачу отдельному агенту и возвращать только его чистый результат.

Инстинкт говорит: хранить всё, на всякий случай. Навык — знать, что выбросить.

Сложная часть 3: инструменты, которыми агент реально может пользоваться

Цикл хорош ровно настолько, насколько хороши инструменты внутри него.

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

Две вещи важнее, чем кажется:

• Сделайте записи безопасными для повторения. Циклы ретраят, и если повторный вызов «создать клиента» создаёт второго клиента, вы проснётесь с дублями записей и двойными списаниями. Всё, что меняет состояние, должно быть безопасно вызвать дважды.
• Пишите ошибки для агента, а не для человека. Хорошая ошибка говорит агенту, что делать дальше. Перед выпуском инструмента спросите себя: поймёт ли LLM, читающая эту ошибку, следующий шаг?

В цикле ошибка — не тупик. Это следующая инструкция.

Сложная часть 4: что-то, что умеет сказать «нет»

У автономных циклов есть тихий failure mode: агент, оставленный один, склонен соглашаться сам с собой.

Самый точный комментарий во всей дискуссии был таким: спроектировать цикл — половина работы, а вторая половина — встроить в цикл что-то, что может сказать «нет»: тест, type check или настоящую ошибку.

Цикл без критика — это просто агент, кивающий собственным решениям.

Исправление — отделить maker от checker. Одна модель делает работу. Другая проверка — часто отдельная модель или жёсткий тест — оценивает её. Исполнитель не проверяет собственную домашку.

Настоящий сдвиг

Теперь цитата Черного становится понятной.

Prompting — это когда вы ведёте агента ход за ходом. Loop engineering — это когда вы строите систему, которая ведёт его, а затем отходите назад.

Ваша работа меняется: вместо инструкций вы проектируете три вещи:

1. Цель, записанную как success criteria, с которыми агент может себя сверить.
2. Цикл с нормальными тормозами, чтобы он правильно останавливался.
3. Verifier, чтобы «готово» было доказано, а не заявлено.

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

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

С чего начать

В первый день вам не нужен полностью автономный агент, работающий всю ночь. К этому можно прийти постепенно:

1. Начните с базового цикла и сразу добавьте лимит итераций, timeout и cost ceiling.
2. Определите «готово» как автоматическую проверку до начала работы, а не как ощущение после.
3. Защищайте контекст: compact длинные runs, выносите большие outputs, изолируйте грязные subtasks.
4. Проаудируйте инструменты: держите их немного и сфокусированными, сделайте writes safe to repeat, перепишите ошибки так, чтобы агент мог действовать по ним.
5. Вставьте критика в цикл. Переходите к fully hands-off только когда доверяете тому, что говорит «нет».

Главный вывод

Loop engineering — это не framework и не инструмент, который можно установить. Это сдвиг в том, куда вы направляете усилия.

Модель становится commodity. Реальная инженерия теперь живёт в цикле вокруг неё.

Лучшие разработчики перестали спрашивать: «Что мне сказать агенту сделать?» Они начали спрашивать: «Какая система сделала бы это без меня?»

Хорошо ответьте на этот вопрос — и вы тоже перестанете промптить.

Вот краткое изложение:

Спасибо за чтение!

Cheers :) Akshay.