TL;DR
Global-оркестрация — способ, при котором модель один раз пишет полный сценарий (какие инструменты вызвать, в каком порядке, с какими ветвлениями и циклами). Дальше сценарий выполняется без новых обращений к LLM. Альтернатива — Step-by-Step: модель делает шаг, смотрит результат, думает, делает следующий шаг. Global на порядок дешевле по числу вызовов и токенов. Step-by-Step стабильно точнее.
Главная находка: разрыв в точности сокращается, но не исчезает. От старых моделей к новейшим он уменьшился примерно на 79%, но Step-by-Step всё ещё впереди у всех моделей. Интуитивные «лекарства» не работают. Модель побольше — не обязательно ближе к Step-by-Step. Режим рассуждения (reasoning) примерно у половины моделей ухудшает результат. Если дать модели конкретные входные данные до построения сценария, разрыв тоже не сокращается. При этом Global часто выдаёт сценарий, который просто не запускается.
Что реально помогло: строить сценарий по одному узлу с проверкой каждого (+10 п.п. в среднем) и переписывать готовый сценарий по логам его собственных прогонов (+6 п.п. на всех восьми моделях, включая варианты, которых модель не видела). Третий путь, обучение на готовых воркфлоу, даёт +12 п.п., но он не для читателя без GPU.
Схема метода
ВЫБОР РЕЖИМА
Сценарий стабильный, много однотипных запусков → GLOBAL (дёшево, но слабее)
Сценарий плавающий, ошибка дорогая → STEP-BY-STEP (дороже, точнее)
УЛУЧШЕНИЕ GLOBAL (без обучения моделей):
LOCAL (сборка по узлам):
ШАГ 1: модель предлагает ОДИН узел сценария
ШАГ 2: валидатор принимает узел или возвращает ошибку
ШАГ 3: повтор, пока сценарий не собран (нужен код/автоматизация)
REPLAN (ревизия по логам) — можно вручную в чате:
ШАГ 1: модель пишет полный сценарий (Global)
ШАГ 2: сценарий прогоняют на нескольких реальных вариантах → логи
ШАГ 3: модель получает свой сценарий + логи → переписывает ЦЕЛИКОМ
(эталонный ответ и оценки модели НЕ показывают)
Пример применения
Задача: Вы владелец магазина на Ozon и Wildberries. Нужен сценарий в n8n или Make, который обрабатывает заявки на возврат. Сценарий читает заявку из amoCRM, проверяет заказ в Google Таблице, при сумме больше 5 000 ₽ создаёт задачу в Bitrix24, иначе сразу отправляет клиенту ответ в Telegram. Запусков много, логика стабильная, поэтому нужен Global-сценарий, а не агент, который думает над каждой заявкой. Первую версию вы уже получили от модели и прогнали на 6 реальных заявках. Теперь ревизия по логам (Replan).
Промпт:
Ты исправляешь сценарий автоматизации для обработки возвратов.
<Сценарий_v1>
1. amoCRM.get_lead(lead_id) → lead
2. GoogleSheets.find_row(sheet="Заказы", key=lead.order_id) → order
3. IF order.amount > 5000:
Bitrix24.create_task(title="Возврат", description=lead.reason, assignee="руководитель")
ELSE:
Telegram.send_message(chat_id=lead.client_tg, text="Возврат одобрен")
4. amoCRM.update_lead(lead_id, status="Обработано")
<Логи_прогонов>
Прогон 1 (lead 4412, заказ 3 200 ₽): шаг 2 → ОШИБКА: строка не найдена (order_id = "WB-4412" в заявке, в таблице "4412").
Прогон 2 (lead 4415, заказ 7 800 ₽): шаги 1–4 успешно. Задача создана.
Прогон 3 (lead 4419, заказ 2 100 ₽): шаг 3 → ОШИБКА: у клиента нет client_tg (поле пустое).
Прогон 4 (lead 4420, заказ 5 000 ₽ ровно): ушло в ELSE, Telegram отправлен. Руководитель жалуется: граница должна включаться в Bitrix24.
Прогон 5 (lead 4424, заказ 12 000 ₽): шаги 1–4 успешно.
Прогон 6 (lead 4431): шаг 1 → ОШИБКА: lead удалён, get_lead вернул пустой результат; шаг 4 всё равно выполнился.
Задача: перепиши сценарий ЦЕЛИКОМ. Учти ошибки, пустые поля и граничные значения из логов. Добавь обработку ошибок для каждого шага, где она нужна. Сценарий должен остаться универсальным для любых заявок, а не подогнанным под шесть прогонов выше. После сценария перечисли, какие проблемы из логов ты исправил и какие возможные проблемы, не встретившиеся в логах, ты закрыл.
Результат: Модель выдаст полный переписанный сценарий. В нём будут проверка пустых результатов, нормализация идентификатора заказа, запасной канал при отсутствии Telegram и исправленная граница суммы. Ниже будет список «проблема из лога → что изменено» и список дополнительных рисков, закрытых заранее. Сценарий остаётся общим, а не заточенным под шесть заявок.
Почему это работает
Слабость. Global требует от модели «сыграть партию вслепую»: заранее угадать, как будут выглядеть данные, где поля пустые, какие ветки сработают. Одной попыткой это получается плохо. Статья показывает, что Global-сценарии часто вообще не запускаются из-за ошибок структуры, а точность заметно ниже, чем у Step-by-Step. Больше параметров или режим рассуждения этого не лечат. Дать модели конкретные входные данные до построения сценария тоже не помогает: ей нужны результаты реального исполнения.
Сильная сторона. Модель хорошо исправляет текст, когда видит конкретную ошибку: «шаг 2 упал, потому что идентификатор в другом формате». Она также хорошо собирает структуру кусками, если каждый кусок проверяют сразу.
Как метод обходит слабость. Replan превращает слепое планирование в планирование по обратной связи. Вызовов LLM при работе сценария по-прежнему нет, но сам сценарий уже «видел» реальность. Local проверяет каждый узел сразу, ошибки не накапливаются. Важная деталь: логи нужны разные, поэтому берите разные варианты (короткая сумма, длинная, пустые поля), а не 6 одинаковых успешных запусков.
Рычаги управления: - Что в логах. Статья передавала вызовы инструментов, аргументы, результаты или ошибки, исходы ветвлений и итоговый ответ. Чем полнее логи, тем точнее ревизия. - Число и разнообразие прогонов. Больше разных случаев — меньше подгонки. Усиливайте фразой «сценарий должен остаться универсальным». - Что НЕ показывать. Эталонный правильный сценарий и оценки не передавались. Не подсказывайте модели «правильный ответ», иначе вы проверяете подсказку, а не сценарий. - Число раундов. Один раунд ревизии давал +6 п.п. Следующие раунды статья из доступной части не описывает, проверяйте сами.
Шаблон промпта
Статья не публикует текст промпта в доступной части. Ниже реконструкция по описанию того, что подаётся модели в Replan.
Ты исправляешь сценарий автоматизации.
<Задача>
{описание_задачи_и_ожидаемого_результата}
<Доступные_инструменты>
{список_инструментов_и_их_параметры}
<Сценарий_v1>
{текущий_сценарий_целиком}
<Логи_прогонов>
{для_каждого_прогона: входные_данные, вызовы_инструментов, аргументы, результаты_или_ошибки, какая_ветка_сработала, итоговый_ответ}
Перепиши сценарий ЦЕЛИКОМ, не латками. Исправь ошибки из логов. Сценарий должен остаться универсальным для любых входных данных, а не подогнанным под прогоны выше. В конце: список исправлений «проблема → что изменено».
Что подставлять:
- {описание_задачи...} — что сценарий должен делать и что считается успехом.
- {список_инструментов...} — реальные модули или API вашей платформы (n8n, Make, Bitrix24, amoCRM и т. д.).
- {текущий_сценарий_целиком} — вывод первой версии, полностью.
- {логи...} — 5–10 разных прогонов, включая неудачные и пограничные.
🚀 Быстрый старт — вставь в чат:
Вот шаблон ревизии сценария по логам (Replan). Адаптируй под мою задачу: [твоя задача автоматизации].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие инструменты доступны, как выглядит текущий сценарий и какие у тебя есть логи или примеры прогонов. Без этого метод не работает: Replan держится на реальной обратной связи, а не на догадках.
Ограничения
⚠️ Step-by-Step всё равно точнее: во всех проверенных моделях пошаговый режим выигрывает. Ревизия сокращает разрыв, но не закрывает. Если ошибка стоит дорого (деньги, клиенты, необратимые действия), Global не стоит ставить без проверки.
⚠️ Global часто не запускается: значительная доля Global-сценариев у большинства моделей вообще не даёт исполнимого результата. У слабых моделей это почти все попытки. Ревизия лечит часть проблем, но проверять сценарий на тестовых данных обязательно.
⚠️ Нет гарантии от «умных» настроек: увеличение размера модели, переход на новое поколение и включение reasoning улучшают результат непоследовательно. Что-то одно из этого иногда даже ухудшает Global. Не покупайте «модель побольше» как решение.
⚠️ Доступ к входным данным не спасает: модель, которая видит конкретный ввод, но не видит результатов выполнения, сценарий лучше не строит.
⚠️ Эксперименты в симуляторе: корпоративные задачи (Slack, Jira, Salesforce и подобное) выполнялись в симулированной среде, а не в вашем реальном стеке. Эффект на ваших инструментах может отличаться.
⚠️ Третий путь вам недоступен: обучение моделей на готовых воркфлоу (+12 п.п.) требует GPU и датасета. Для читателя это не вариант.
⚠️ Статья неполная: я видел только часть текста. Детальных таблиц по Local и Replan в доступной части нет, поэтому цифры по ним взяты из аннотации и введения.
Как исследовали
Исследователи собрали бенчмарк AgentOrch из 650 корпоративных регламентов (SOP). У каждого есть эталонный рабочий сценарий и 3 220 вариантов запуска с разными входными данными, ветками и ошибками. Среда одна и та же: 64 инструмента вроде Slack, Jira, Salesforce, Google Sheets. Один и тот же регламент гоняли в двух режимах, Global и Step-by-Step, с одинаковыми инструментами и критериями оценки. Поэтому сравнение честное. Оценивали не «похоже ли на правду», а совпадение вызовов, порядка, аргументов и побочных эффектов с эталоном.
Результаты неочевидные. Разрыв сократился с 40,67 п.п. у GPT-3.5 Turbo до 15,12 п.п. и 8,53 п.п. у двух сильнейших моделей 2026 года (около 79%). Но рост размера модели внутри одного семейства разрыв не сокращал монотонно. Например, у Qwen2.5 Global на 72B даже хуже, чем на 32B. Reasoning помогал примерно половине моделей и вредил другой половине. Эксперимент с передачей реальных входных данных в Global показал, что дело не в «незнании данных»: разрыв остался прежним. Похоже, пошаговый режим выигрывает за счёт обратной связи от выполнения.
Из этого следует практический вывод: улучшать Global нужно сигналом от реальных запусков, а не сменой модели или режима «подумай подольше». Ревизия по логам собственных прогонов работала на всех восьми моделях и держалась на вариантах, которые не использовались в логах. А вот для Local использовался валидатор, и он улучшал результат не у всех моделей, а «у нескольких».
Адаптации и экстраполяции
🔧 Техника: сборка по узлам вручную в чате (облегчённый Local)
В оригинале сценарий собирает append-only редактор с автоматическим валидатором. В чате похожее поведение получается так:
Собирай сценарий по ОДНОМУ узлу за сообщение. После каждого узла
я отвечу «принято» или пришлю ошибку из платформы. Не переходи к
следующему узлу, пока я не подтвердил текущий.
Эффект: ошибки не накапливаются в полном сценарии. Минус: это ваше время вместо автоматического валидатора. Эффект от такой ручной версии в статье не проверялся.
Экстраполяция: гибрид Global + Step-by-Step. Это не из статьи, это моя идея, проверяйте сами. Стабильный «скелет» сценария собирает Global с ревизией. Агент с пошаговым режимом подключается только на ветки, где данные плавающие (например, разбор свободного текста жалобы).
Раздели сценарий на два блока. Блок А: детерминированные шаги, которые можно описать заранее. Блок Б: шаги, где нужно решение по содержанию данных. Для блока А напиши полный сценарий. Для блока Б — отметь точки вызова LLM и опиши, что именно она получает и что должна вернуть.
Ресурсы
- Статья: AgentOrch: How Close Can Global Orchestration Come to Step-by-Step Interaction?
- Авторы: Zijie Liu, Qi Yang Huang, Jinhao Duan, Yueh Che Lee, Thomas A. Joseph, Zayne Turner, Adam Seligman, Tianlong Chen, Zhaozhuo Xu
- Организации: University of North Carolina at Chapel Hill; Workato
- Код: github.com/workato-devs/AgentOrch
- Связанные работы из статьи: ReAct (Yao et al., 2023), Reflexion (Shinn et al., 2023), WorFBench, WorkflowBench, AppWorld, τ-bench