Эскалируйте узлы, а не задачи: шестиступенчатая лестница для контроля затрат в рабочих процессах больших языковых моделей

Многие команды, создающие пайплайны на основе больших языковых моделей, начинают с одного архитектурного вопроса по каждой новой функции: следует ли её реализовать в виде фиксированной структуры DAG или как автономного агента? Это кажется разумным этапом проверки дизайна, но ответ на этот вопрос на уровне всей задачи тайно определяет затраты на самый неопределённый этап для всех остальных. В этой статье объясняется, как это происходит, а затем представлена шестиступенчатая иерархия управления, при которой каждый узел начинается с самого дешёвого возможного уровня и переходит на следующий только в случае сбоя явно оговорённого контракта. К концу вы сможете разложить свои собственные задачи «агента» на составляющие, понять, какая часть из них действительно детерминирована, и установить строгие ограничения на затраты на оставшуюся часть.

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

Начальная точка: классификация каждой задачи заранее

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

Задачи с открытыми параметрами передавались агенту

Задачи, которые считались по-настоящему открытыми, реализовывались с использованием единого агента ReAct в LangGraph. Ориентиром служил процесс поиска работы на основе резюме: пользователь загружает свое резюме, и система должна найти подходящие вакансии и составить для каждой из них индивидуальное резюме. Это включает в себя резюме, написанные на нескольких языках, сопоставление кандидатов с вакансиями по критериям, которые невозможно определить только на основе ключевых слов (время в пути от дома, состав команды, ежедневные обязанности, диапазон зарплаты), а также создание персонализированного документа. Никто не может заранее сказать, сколько шагов потребуется, поэтому это казалось идеальным примером для агента.

Задачи с предсказуемым ходом обрабатывались с помощью статической DAG

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

Структура казалась логичной, и проект был реализован. Проблема заключалась в том, что затраты так и не снизились.

Почему налог на агентов никогда не исчезает

Механизм, лежащий в основе плоской кривой затрат, довольно прост, и именно поэтому его легко упускать из виду.

Когда задача помечена как «агент», каждый шаг внутри неё выполняется в рамках цикла агента и сопряжён с определёнными затратами. Цикл ReAct может выбрать действие только в том случае, если схемы его инструментов находятся в окне контекста. Можно сжимать разговор, подводить итоги промежуточных состояний и удалять извлечённые документы, и команда делала всё это, но минимальная стоимость за ход остаётся прежней, поскольку этот минимум определяется набором схем инструментов, который передаётся заново при каждом ходе. Также нельзя просто дать агенту меньше инструментов, если хочется сохранить его гибкость: причина, по которой он считается агентом, заключается в том, что никто заранее не может знать, какие инструменты понадобятся в конкретной ситуации.

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

Повторное изучение литературы вместе с месяцами записей из производственных систем привело к почти до смешного простому выводу:

Неопределенность связана с отдельными узлами, а не со всеми задачами.

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

Если разобрать процесс поиска работы, структура становится очевидной:

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

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

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

Лестница эскалации

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

• L0: только вызовы инструментов, без использования LLM. Если запрос можно полностью обработать с помощью детерминированных операций, никакие модели не запускаются. В продукте это существующий быстрый путь, который остается отдельной составляющей. Стоимость равна просто количеству вызовов инструментов.
• L1: статическая сеть DAG из механических узлов. Настоящая графическая структура с ветвлениями и расширениями, но каждый узел представляет собой обычный код. При этом также не происходит вызовов моделей.
• L2: статическая DAG с узлами LLM однократного использования. Форма графа остается неизменной, но теперь некоторые узлы вызывают модель один раз в условиях узко определенного контекста. На практике узел получает только свои прямые входные данные: никакой истории разговора, никакого глобального состояния и, что критически важно, никаких схем инструментов. На этом уровне модель ведет себя как чистая функция, а не как агент. Затраты составляют O(n) вызовов, причем значение n известно до начала выполнения.
• L3: циклы уточнения с ограничением. Узел L2 может пытаться выполнить задачу согласно контракту до фиксированного максимума N попыток. Решение о том, является ли результат приемлемым, принимает контракт, а не модель. Затраты составляют O(n·N), причем это значение также известно до начала выполнения.
• L4: непрозрачный узел превращается в подагента. Узел, который нельзя определить заранее, получает настоящий цикл ReAct, но его инструменты ограничены этим узлом, и у него есть жесткий лимит шагов. Никто не может предсказать, сколько ресурсов он потратит, и именно эта непредсказуемость является причиной необходимости наличия четкого верхнего предела.
• L5: полная перепланировка. Сам план был неверным, поэтому граф перестраивается заново. Это самый дорогостоящий вариант и должен использоваться редко.

Контракты, объем работы и бюджеты

Сама таксономия была бы лишь более красивым словарем терминов. Три механизма делают эту систему действительно эффективной:

• Контракты запускают процедуру повышения уровня. Каждый узел указывает форму приемлемого результата, и только неудачная проверка этого условия оправдывает переход на следующий уровень.
• Область применения делает уровни L4 доступными с точки зрения затрат. Схемы инструментов подагента находятся внутри контекста этого узла и не появляются нигде ещё в процессе выполнения, поэтому расходы на их обработку покрываются локально.
• Бюджеты устанавливают верхний предел действий. На каждом уровне выше L2 существует максимальное количество попыток или шагов; после их исчерпания узел либо сдается, либо переходит на более высокий уровень.

Практический способ понимания: контракт отвечает на вопрос «достаточно ли этого?», область применения — на вопрос «что может видеть и вызывать этот узел?», а бюджет — на вопрос «сколько он может потратить на попытки?». Если отсутствует хотя бы один из этих элементов, соответствующий уровень теряет предсказуемость. Чтобы узнать больше о контроле за циклами типа L3 и L4 в коде, ознакомьтесь с ограниченными агентскими циклами в TypeScript.

Прохождение пути обработки субтитров по ступеням

Большинство заданий так и не покидают уровень L1. В этой процедуре извлекается аудио, выполняется распознавание речи, происходит сегментация по временным меткам и формируется файл SRT, причем при этом не используется никаких моделей. Затем результат проверяется согласно установленным требованиям: сигналы не должны перекрываться, длина строки не должна превышать установленный лимит, а скорость чтения — оставаться ниже определенного порога. Типичное видео с голосом и чистым аудио проходит проверку, причем на обработку уходит не более времени, чем на выполнение команды ffmpeg плюс один проход распознавания.

Когда тот или иной сигнал нарушает правила длины строки или читаемости, только этот сигнал переходит на уровень L2. Для его обработки выполняется один вызов модели, контекстом которого являются сам сигнал и его непосредственные соседи. Полный текст, метаданные видео и все схемы инструментов не включаются в запрос, а остальная часть структуры остается незатронутой.

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

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

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

Пошаговый поиск работы

Именно этот пример изменил подход команды, поскольку он явно напоминал структуру агента.

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

L2 отвечает за сопоставление. Для каждой подходящей вакансии производится один вызов модели, который возвращает структурированный балл по соответствующим критериям, причем единственными элементами контекста являются краткое описание резюме и само описание вакансии. Это соответствует O(n) вызовам недорогой модели без использования каких-либо схем инструментов; такой подход заменил агента, который рассматривал тот же список, загружая полный набор инструментов при каждом шаге.

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

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

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

Основной результат заключается в том, что задача, ранее отнесенная к категории агента, на деле состоит примерно на 80% из работ типа L1 и L2. Это не вопрос настройки запроса; это полностью меняет кривую затрат процесса работы.

Что обеспечивает продукт типа «файл-в-файл»

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

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

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

Когда Ladder не оправдан

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

Сначала выпускаем самый простой компонент

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

Он был выпущен как open-source Python SDK, опубликованный на PyPI под лицензией Apache-2.0 и доступный в качестве сервера MCP внутри Claude Code. Установка осуществляется одной командой с использованием uv или pip.

uv add convilyn          # or: pip install convilyn

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

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

Текущий статус движка рабочих процессов

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

Существующие решения и связанная работа

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

Начните с простого и добавляйте сложность только тогда, когда это необходимо

• Создание эффективных агентов, опубликованное компанией Anthropic в декабре 2024 года, различает рабочие процессы и агентов, рекомендуя самое простое работоспособное решение и добавляя сложность только тогда, когда это необходимо. Модель «лестницы» отличается тем, что применяет этот принцип во время выполнения задачи, шаг за шагом, а не один раз при проектировании.

Усиливать только ту часть, которая не сработала

• Статья ADaPT, название которой означает декомпозицию и планирование по мере необходимости (научная конференция NAACL 2024), начинается с общего плана и далее рекурсивно разбивает подзадачи только после того, как их выполнение проваливается, оставляя успешно выполненные части без изменений. Это самое подробное опубликованное описание механизма запуска уровня L4, хотя в нем не учитываются факторы затрат.

Контракты, ограничения на восстановление и правила эскалации

• Теоретическая модель планировщика для выполнения агентов LLM в виде структурированных графов, опубликованная в arXiv в апреле 2026 года, использует статическую DAG с контрактами вывода для каждого узла и трехэтапный протокол восстановления, включающий повторную попытку, локальное исправление и полное перепланирование, с четко определенными инвариантами эскалации. Согласно этой модели, узлы, основанные на моделях, должны проверяться согласно контрактам, поскольку типовые проверки недостаточны, а повторные попытки для неидемпотентных операций требуют ограниченного бюджета. В ней намеренно не учитывается рекурсивное расширение подграфов, что является основой для L4.

Метод планирования с разделением задач (TDP), рассмотренный в той же статье, разделяет работу на граф подзадач, каждая из которых имеет собственный узкий контекст, и ограничивает повторное планирование той подзадачей, которая в данный момент активна. Было зафиксировано сокращение объема данных до 82%, что является наиболее близким к нам из опубликованных показателей, подтверждающих аргумент о ограничении функционала на уровне L2.

Объем инструментов как основной фактор затрат

• Skillflow определяет структуру в формате DAG в YAML, по которой перемещается движок, а не сама модель. Ввод-вывод контролируется в зависимости от возможностей: каждый шаг получает только тот контекст, который он запрашивает, а любой инструмент, не предусмотренный его спецификацией, просто отсутствует в соответствующей схеме. Сделанный авторами вывод о том, что небольшой объем контекста, специфичного для конкретной роли, позволяет использовать более дешевые модели, соответствует аргументу уровня L2.

Этапные структуры уже используются в производстве

• PraisonAI включает в свой SDK агентов функцию эскалации, которая определяет четыре последовательных этапа: прямой ответ без использования инструментов или планирования, использование эвристических инструментов без дополнительных вызовов модели, один ограниченный вызов модели и, наконец, полностью автономный цикл с использованием инструментов, подагентов и проверки. Это в общих чертах соответствует уровням от L0 до L4, сведенным к четырем шагам.
• маршрутизатор эскалации NVIDIA NeMo Switchyard применяет аналогичную структуру при выборе модели вместо архитектуры: сначала используется более слабая модель, а при обнаружении постоянных проблем переходят на более мощную.

Аналогичная структура в других случаях

• Агентные шаблоны проектирования (systemdesign.one, апрель 2026 г.) использует термин «лестница эскалации» для обозначения выбора между рабочим процессом и агентом и рекомендует использовать наименее сложную схему, способную выполнить задачу.
• Руководство Vercel по фреймворкам оценки ИИ-агентов для производственных целей (июль 2026 г.) предусматривает принцип «сначала самое дешевое» при оценке: сначала выполняется наименее дорогой тест, способный выявить определённую ошибку, и эскалация происходит только тогда, когда этот тест по своей структуре не может обнаружить проблему.

Основные выводы

• Решение вопроса «DAG или агент» для каждой задачи позволяет сделать каждый шаг эффективным, учитывая наиболее неопределённый этап.

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

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

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

Ожидайте, что большинство задач «агентов» после разбиения на составные части будут в значительной степени детерминированными; в случае поиска работы около 80% задач относились к уровням L1 и L2.

Связанная литература

• Проектирование многопроцессорных систем на узлах A2A: узлы, память и управление — справочная архитектура многопроцессорных систем, построенных на протоколе A2A, включающая модули агентов, типы памяти, механизмы оркестрации, риски безопасности и чек-лист для проектирования.
• LangGraph на практике: состояния, узлы, рёбра и пять шаблонов работы агентов — Узнайте, как определять состояния LangGraph с использованием аннотаций и редюсеров, соединять узлы рёбрами и реализовывать все пять основных шаблонов рабочего процесса агентов на JavaScript.