Loop Engineering: новый хайп или конец ручного промтинга?

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

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

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

Но сейчас инженеры “придумали” следующий уровень — инженерию циклов, или Loop Engineering.

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

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

Главное здесь — не автономность сама по себе, а проверяемость.

Хороший цикл — это система, у которой есть условие запуска и завершения, тело цикла, среда выполнения и ограничения.

Такие циклы особенно полезны там, где есть повторяющаяся работа и понятная проверка результата.

Простой пример, о котором я писал ранее, — разработка через тесты (Test-Driven Development). Мы заранее описываем, что должно работать, а агент пишет код, запускает проверки, получает ошибки, исправляет, снова проверяет и не завершает задачу, пока система не увидит доказательство, что результат достигнут.

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

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

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

Циклы нужно превращать в переиспользуемые навыки. Так у вас появится библиотека рабочих процессов, которые можно встраивать в более сложные системы.

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

Отдельная проблема — контекст. Цикл пересылает контекст на каждом проходе, поэтому лишняя информация быстро раздувает бюджет на токены и плодит ошибки.

Циклы — это недостающее звено системы, в которой агенты могут действовать самостоятельно. Однако ИИ-агент может быть автономным ровно настолько, насколько система умеет проверять его работу.

Поэтому новый важный навык — умение строить циклы, которым можно доверять.

#технологии