Остановить каскад субагентов и рекурсивное делегирование
Обновлено September 19, 2026 · впервые опубликовано September 19, 2026
Каскады разрастания субагентов возникают, когда автономный оркестратор разбивает высокоуровневую задачу на параллельные подзадачи и даёт рабочим агентам право порождать новых специализированных исполнителей. Без жёстких ограничений параллелизма и глубины один неоднозначный пользовательский запрос может вызвать экспоненциальный взрыв: 1 корневой супервайзер порождает 6 доменных планировщиков, каждый запускает 4 исследовательских агента, которые в свою очередь вызывают дальнейших субисполнителей. В продуктовых архитектурах неограниченное рекурсивное делегирование регулярно сжигает от 2,000,000 до 8,000,000 токенов за 5 минут, что даёт неожиданные всплески API-счёта в $15–80 за одну транзакцию.
Математика рекурсивного делегирования агентов
В стандартной древовидной схеме агентов делегирование растёт по формуле: коэффициент ветвления B в степени глубины выполнения D. Если оркестратор ветвится с B = 4 и позволяет субагентам рекурсию до глубины D = 3, система запускает 64 независимых цикла агентов. Каждый листовой агент ведёт собственный контекст диалога, выполняет итеративные вызовы инструментов и передаёт промежуточные результаты вверх по иерархии. Поскольку родительские агенты агрегируют и суммируют выходы потомков, накопление контекста квадратично растёт по всему дереву выполнения.
Что такое каскад разрастания субагентов в автономном ИИ?
Каскад разрастания субагентов — это режим отказа, при котором агент-оркестратор рекурсивно порождает дочерних и внучатых агентов без глобальных бюджетных ограничений, экспоненциально умножая потребление токенов в параллельных потоках выполнения.
Четыре продуктовых ограничения для мультиагентных систем
Платформенные команды, управляющие корпоративными агентными системами, предотвращают неконтролируемые каскады, задавая жёсткие границы времени выполнения:
- Максимальная глубина рекурсии (Depth Caps): установите строгий потолок иерархии выполнения. В 95% корпоративных сценариев ограничения
max_depth: 2(корневой супервайзер → рабочий агент) достаточно для полного решения задачи. Запретите рабочим агентам порождать субагентов третьего уровня, если это не разрешено политикой. - Общие пулы токенов на поток: не выдавайте субагентам независимые бюджеты. Выделите общий лимит токенов (например, 250,000 токенов) корневому контексту выполнения и передавайте остаток баланса через заголовки контекста трассировки. Когда дочерние агенты тратят токены, уменьшайте глобальный пул; если он исчерпан, все параллельные ветви немедленно завершаются.
- Автоматические выключатели параллелизма (Concurrency Circuit Breakers): ограничьте число одновременно активных дочерних агентов 3–5 процессами. Если супервайзер пытается запустить больше параллельных рабочих агентов, чем позволяет очередь, ставьте задачи в очередь последовательно или отклоняйте разбиение.
- Распределённая трассировка и передача стоимости по OTLP: внедряйте идентификаторы трассировки OpenTelemetry и baggage-заголовки во все шины сообщений между агентами. Когда OpenLIT или ClickHouse агрегируют расходы, каждый дочерний span должен входить в идентификатор родительской сессии, что даёт мгновенную видимость аномалий стоимости на уровне ветвей.
Как ограничения параллелизма предотвращают исчерпание токенов в мультиагентных системах?
Ограничения параллелизма регулируют число одновременно выполняющихся рабочих циклов, предотвращая параллельный наплыв API-запросов и позволяя выключателям прерывать сбоящие циклы агентов до исчерпания бюджета токенов.
Какая глубина рекурсии рекомендуется для делегирования агентов?
Рекомендуемая глубина рекурсии — 2 уровня (корневой оркестратор → специализированный рабочий агент). Более глубокие иерархии дают убывающую отдачу в рассуждениях, одновременно резко увеличивая накладные расходы на контекст и усиление ошибок.
По теме
Хотите применить это к своему стеку? Принесите счета провайдеров, логи шлюза и ключевые рабочие процессы — мы определим драйверы затрат и пути экономии. Заказать бесплатный аудит →