Loop engineering: почему ИИ-агентами
теперь управляют петли, а не промпты

Промпт. Вы задали модели роль и вопрос, она ответила из того, что уже знает. Оптимизируется формулировка, дисциплина называется промпт-инжиниринг.

Зачем понадобился контекст. В контекстном окне остается свободное место, и логичный шаг это дать агенту право самому вызывать инструменты и наполнять контекст под конкретный запрос: открыть файл, обратиться к базе через MCP, найти свежие данные. Это context engineering, и Anthropic описывает его как продолжение промпт-инжиниринга, где предмет оптимизации расширяется с текста инструкции до всего набора токенов в окне. Сюда же относится RAG: перед ответом система ищет подходящие фрагменты в вашей базе документов и подставляет их в запрос, чтобы модель отвечала по вашим данным, а не по общим знаниям.

Зачем понадобился харнесс. Context engineering плохо тянет задачи, которые идут дольше нескольких минут: они требуют больше контекста, чем агент способен держать. Сжимать его на ходу можно, но такое сжатие протекает, детали теряются на каждом пересказе. Anthropic называет родственный эффект context rot: с ростом числа токенов модель хуже извлекает из окна нужное. Значит нужна система снаружи, которая управляет контекстом и разбивает требование на устойчивую последовательность шагов. Эта обвязка и есть харнесс: инструменты, скиллы, песочница, системные промпты. Формула короткая, агент это модель плюс харнесс.

Зачем понадобилась петля. Петли уже были на каждом слое, просто их не называли: в context engineering агент рекурсивно вызывает инструмент за инструментом, в харнессе итерирует список задач вне контекстного окна. Loop engineering добавляет еще одну петлю, снаружи харнесса, и она направляет харнесс извне: решает, когда запустить прогон заново, по какому расхождению и когда пора остановиться.
Меняется главное: кто задает направление. Раньше это делал человек на каждом шаге, теперь система сама. Борис Черни, руководитель Claude Code в Anthropic, сформулировал сдвиг так: «Я больше не промпчу Claude. У меня работают петли, которые промптят Claude и решают, что делать дальше. Моя работа писать петли».

Про сами системы у нас есть отдельный разбор: что такое ИИ-агенты. Имен у них много: ИИ-агенты, AI-агенты, агенты искусственного интеллекта, в англоязычных материалах AI agents и agentic AI.
Петля проходит четыре стадии, и они повторяются, пока не сработает условие остановки: цель с проверяемым критерием завершения, действие, наблюдение за результатом и корректировка следующего шага. Вся разница между работающей и неработающей петлей сидит в первой стадии, и измеряется она деньгами. Например, «сделай мой сайт быстрее» против «оптимизируй главную страницу, пока время загрузки не станет меньше двух секунд по замеру». Первая формулировка крутится, пока не закончатся деньги. Вторая останавливается сама.

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

Петля собирается из шести частей.

Первые три относятся к харнессу, это все, что нужно для одного прогона. Последние три это уже петля: такт, проверка и память.

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

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

Большинство компаний, которые говорят, что «внедрили ИИ-агентов», стоят на первом уровне. Косвенное подтверждение есть в замерах McKinsey: до масштабирования агентных систем доходят 23 % организаций, остальные остаются в пилотах, то есть на первой ступени.

Обратите внимание, где стоит проверка: сразу за автоматизацией и раньше масштабирования.

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

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

Задача: в трекер упал баг, при определенном условии сервис отдает ошибку. Событийная петля забрала задачу по вебхуку.

Цикл первый. Агент находит место в коде, пишет тест, воспроизводящий баг, вносит правку и запускает прогон. Целевой тест прошел, но упали два смежных. Условие остановки не выполнено.

Цикл второй. На вход агенту приходит не команда «переделай», а имена двух упавших тестов и их вывод. Он работает по ним и правит логику, которую задел на первом шаге.

Цикл третий. Прогон зеленый, сборка проходит, петля останавливается сама и оставляет изменения на проверку человеку.

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

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

Главный вопрос к своему процессу звучит так: что в нем умеет само себя проверить. Не «где мы теряем время», а именно это. Проверка редко бывает готовой, но почти всегда есть в зачаточном виде: ответ внешней системы (контрагент по ИНН найден или нет), арифметика (сумма в документе сошлась с договором), схема данных (выгрузка прошла проверку или отвалилась на поле), сверка двух источников (число записей в одной системе и в другой совпало). Каждый такой ответ машинный и однозначный, то есть годится как условие остановки. Если в процессе нет ни одного и построить его нельзя, петля вырождается в обычного агента: ей нечем понять, что она закончила.

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

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

Задачи из первой строки, где хватает промпта или обычного RAG, мы разбирали отдельно: сценарии применения LLM в бизнесе.

RAG чаще всего противопоставляют агентам неправильно. Разница в природе поиска: RAG извлекает похожие на запрос фрагменты один раз, петля ищет многошагово и подстраивается под находки, поэтому в нормальной архитектуре RAG становится инструментом внутри петли. За пределами петель остаются разовые и творческие задачи и работа без объективной проверки. Отдельно стоит случай, когда подзадачи сильно завязаны друг на друга: Anthropic пишет прямо, что там, где всем агентам нужен общий контекст, разносить работу по нескольким агентам сегодня рано, лучше держать одну петлю с общей памятью.

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

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

Stanford Digital Economy Lab добавляет три цифры для бюджета:

• агентные задачи потребляют примерно в 1000 раз больше токенов, чем режим чата о коде;
• прогоны одной и той же задачи различаются по расходу до 30 раз;
• модели не способны предсказывать собственный расход, корреляция не выше 0,39.

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

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

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

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

Первый и главный. Петля без внешней проверки не работает. Huang и соавторы на ICLR 2024 показали, что модели не корректируют себя без внешней обратной связи, а иногда качество после самокоррекции падает. Без проверки петля становится дорогим генератором уверенности.

Второй. Отказы мультиагентных систем повторяются от системы к системе. UC Berkeley разобрала журналы прогонов по семи открытым мультиагентным фреймворкам и вывела таксономию MAST из 14 режимов отказа: 150 прогонов вручную, более 1600 в полном датасете. Сбои воспроизводятся везде, поэтому мультиагентную схему закладывают под конкретный разрыв в процессе и проектируют сразу против этих четырнадцати сценариев. Собранная «потому что так модно» она прироста не даст.

Третий. Ощущение пользы расходится с измерением. В рандомизированном эксперименте METR 16 опытных разработчиков решали реальные задачи в своих репозиториях. С разрешенным ИИ они работали на 19 % дольше, хотя прогнозировали ускорение на 24 %, а после считали, что ускорились на 20 %. Отзывы «стало быстрее» это не доказательство, нужны замеры до и после.

Четвертый. Деградация контекста. Тот самый context rot, из-за которого понадобился харнесс. Контекст это конечный ресурс, поэтому сжатие, внешние заметки и суб-агенты обязательны.

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

К пяти техническим добавляется организационный. По данным McKinsey, влияние ИИ на прибыль фиксируют только 39 % респондентов. Доклад MIT NANDA в изложении Fortune резче: подавляющее большинство корпоративных пилотов не дают измеримого эффекта, при этом покупка готового решения у вендора успешна примерно в 67 % случаев, а внутренняя разработка втрое реже. Причина обычно не в качестве моделей: инструмент и процесс живут отдельно друг от друга.

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

Три вопроса определяют, с чего начинать именно вам. Есть ли в задаче машинная проверка результата. Понятен ли потолок расходов при разбросе до 30 раз. Есть ли песочница, узкие права и лимит бюджета. Где ответ отрицательный, там и лежит первый этап работ: сначала строится недостающее, потом запускается петля. Безопасность ИИ-агентов при этом не этап после пилота, а условие запуска.
Порядок шагов такой.

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

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

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

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