Оркестрация LLM: почему обёртки над моделью не доживают до второй версии

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

Что ломается первым

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

«Иногда нужно сходить в систему за данными». Появляется вызов инструмента. Теперь это не один запрос, а как минимум: понять, что нужен инструмент → вызвать → разобрать результат → ответить. Состояние между этими шагами в обёртке держать негде, кроме как в одном разрастающемся промпте.

«Ответ иногда невалидный». Нужна проверка и повтор. Повтор — это ветвление и условие выхода. В обёртке это превращается в стихийный while с эвристиками, который никто не может объяснить через месяц.

«Иногда надо передать человеку». Нужна точка эскалации с сохранением состояния, чтобы человек видел контекст. Обёртка состояния не сохраняет — приходится прикручивать его сбоку.

«Почему вчера ответило не так?». Нужна трассировка шагов и решений. В обёртке шагов нет — есть один вызов, и сказать, что именно пошло не так, нельзя в принципе.

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

Из чего состоит оркестрация

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

Явные шаги и контракты между ними. У каждого шага типизированный вход и выход. Это то, что делает поведение воспроизводимым и тестируемым: шаг можно прогнать изолированно с известным входом и проверить выход.

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

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

Где проходит граница

• Если на вопрос «на каком шаге и почему система приняла это решение» нельзя ответить из данных процесса — у вас обёртка, даже если внутри несколько вызовов модели. Признак оркестрации не в количестве вызовов, а в наличии явного состояния и трассируемых переходов.
• Декомпозиция на шаги — это компромисс, а не самоцель. Каждый дополнительный шаг добавляет задержку и стоимость координации. Дробить процесс имеет смысл там, где это даёт тестируемость и контроль над риском, а не ради «архитектурности».
• Обёртку дешевле всего переписать в оркестрацию до того, как на ней появились пользователи. После — это миграция живой системы, у которой нет логов, чтобы понять, что в ней вообще происходило.

Вывод

Ценность production-ИИ не в вызове модели, а в управлении состоянием, ветвлениями и отказами вокруг неё. Обёртка справляется ровно до первого реального требования, потому что ей некуда положить сложность, которая этим требованием создаётся. Оркестрация — это не «более сложная обёртка», это другая архитектура: процесс с явным состоянием, контрактами и трассируемыми переходами. Её строят с самого начала, потому что достроить её в обёртку нельзя.