Loop-контроллеры vs линейные пайплайны: эксперимент по изоляции ошибок без LLM в цикле

Loop-контроллеры против линейных пайплайнов это противопоставление из нового эксперимента по изоляции ошибок без LLM в цикле, и оно многое меняет для ИИ-архитектур. Инженер Эммимал П. Александер убрала нейросеть из цикла управления агентом и на 300 случайных сидах измерила, что даёт целенаправленный контроллер против обычного линейного пайплайна. Результат: контроллер в среднем доводил до конца 3.3 независимых ветки из 10.3, линейный исполнитель, всего 0.4. Ноль вызовов LLM, ноль внешних зависимостей. Материал вышел 17 июля 2026 года в Towards Data Science и посвящён одному узкому, но проверяемому вопросу: изоляция сбоев это заслуга «умной» модели или свойство самой архитектуры?

Пайплайн, который встал на шаге 3 из 40

История знакома любому, кто собирал автоматизацию поверх LLM. Несколько месяцев назад task-пайплайн автора умер на третьем шаге из сорока, из-за одного незаданного значения в конфиге. Вместе с ним встали больше тридцати последующих шагов, которые никак не были связаны с пропущенным конфигом.

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

Эксперимент по изоляции ошибок: зачем убирать LLM из цикла

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

Сравнивались две схемы. Линейный one-shot пайплайн выполняет шаги подряд и полностью останавливается на первом же нерешённом препятствии. Целенаправленный контроллер наблюдает состояние, видит граф независимых веток и, наткнувшись на сбой, локализует его внутри конкретной ветки, а остальные продолжает выполнять. Это и есть изоляция ошибок без LLM в цикле: решение о продолжении принимает поток управления, а не нейросеть.

3.3 против 0.4 на 300 сидах

Прежде чем поверить хотя бы одному числу, автор прогнала бенчмарк на 300 случайных сидах. Контроллер стабильно добирался до веток, до которых линейный исполнитель не доходил вовсе. Разница не косметическая: в среднем 3.3 завершённые независимые ветки против 0.4.

Здесь стоит быть честным вслед за автором. Выигрыш возникает там, где задачи независимы. Если работа: жёсткая цепочка, где каждый шаг зависит от предыдущего, изолировать нечего, и преимущество контроллера растворяется. Александер прямо оговаривает: это узкое свойство. Но там, где ветки не связаны, разница между «встало всё» и «встала одна ветка» принципиальная.

Честность как метод: баг в собственном бенчмарке

Ценность материала: в том, как он получен. Александер нашла и исправила реальную ошибку в логике собственного бенчмарка, которая поначалу обесценивала её же выводы. И вместо того чтобы спрятать это, она подробно разбирает баг в тексте и открывает весь код: github.com/Emmimal/loop-engine. Любой может воспроизвести эксперимент и проверить числа сам.

Именно этого не хватает большинству «маркетинговых» бенчмарков вокруг ИИ: сначала скепсис к собственным цифрам и отлов своих ошибок, потом доверие к результату.

Loop engineering: паттерн, а не фреймворк

Термин «loop engineering» (инжиниринг циклов) назвал и структурировал инженер Google Эдди Османи (Addy Osmani) в эссе, опубликованном в июне 2026 года. Суть: заменить один гигантский промпт итеративной системой, которая наблюдает состояние и действует к цели. Это паттерн потока управления, не продукт и не библиотека.

Османи опирался на мысль разработчика Питера Штайнбергера (Peter Steinberger): перестать напрямую промптить кодинг-агентов и вместо этого проектировать циклы, которые их промптят. Примерно тогда же лид Claude Code в Anthropic Борис Черный (Boris Cherny) описал схожий сдвиг в своей работе, от «писать промпты» к «писать циклы, которые пишут промпты».

Прямой технический предшественник появился раньше. В июле 2025 года инженер Джеффри Хантли (Geoffrey Huntley) описал запуск кодинг-агента в обычном while-цикле: скармливать агенту одну и ту же цель снова и снова, пока он не удовлетворит письменную спецификацию. Подход стал известен как «Ralph technique».

Стек слоёв: где живёт loop engineering

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

Что это значит для ИИ-архитектур за пределами кодинг-агентов

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

Та же логика знакома всем, кто имел дело с отказоустойчивой инфраструктурой. Устойчивая система, будь то агент или сеть доступа, должна уметь обойти сломанный узел и идти дальше, а не валиться целиком из-за одной недоступной ветки. Разница между «встало всё» и «встала одна ветка» и отделяет хрупкую автоматизацию от рабочей.

Что делать с этим прямо сейчас

Если вы проектируете что-то поверх LLM, перестаньте объяснять падения «плохим промптом» по умолчанию, сначала посмотрите на поток управления. Самый прямой шаг: откройте репозиторий Александер, прогоните бенчмарк на своих сидах и проверьте, повторяются ли 3.3 против 0.4 на вашей машине.

Частые вопросы

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

Это проектирование цикла, который управляет ИИ-агентом: наблюдает состояние, выбирает следующее действие и ведёт систему к цели, вместо одного большого промпта. Термин ввёл инженер Google Эдди Османи в июне 2026 года.

Почему из эксперимента убрали нейросеть?

Чтобы отделить эффект архитектуры от «ума» модели. Если преимущество loop-контроллера видно даже на простых правилах без LLM, значит, изоляция ошибок заложена в потоке управления, а не в рассуждениях нейросети.

Означает ли это, что контроллер всегда лучше линейного пайплайна?

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

Источники

Towards Data Science, эксперимент по loop-инжинирингу без LLM в цикле

GitHub, открытый код бенчмарка и разбор бага