Hierarchical Decomposition

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

Суть

Топология: Root Planner → Worker 1..N → Synthesizer. Планировщик не выполняет работу, а декомпозирует задачу; воркеры не знают об общей цели, каждый видит свой кусок; синтезатор превращает разрозненные результаты в связный ответ.

От fan-out из Multi Agent Patterns отличается рекурсивностью: воркер, столкнувшись со слишком крупной подзадачей, может сам стать планировщиком и породить следующий уровень. Именно это и делает паттерн опасным.

Где оправдан

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

Правило D_max ≤ 3

Уязвимость паттерна — экстремальная латентность и стоимость: один запуск способен породить 20–30 внутренних вызовов модели. Считается это легко: каждый уровень умножает число веток, и арифметический предел третьего уровня с ветвлением по 5 — уже 125 листьев.

Отсюда правило: оркестратор ограничивает глубину дерева декомпозиции в коде — не больше 3. Не промптом («не углубляйся слишком сильно»), а счётчиком в коде, потому что модель не умеет надёжно оценивать собственную глубину рекурсии.

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

Чего не хватает на практике

Отдельное наблюдение: стандартов обмена промежуточными статусами между планировщиками сегодня нет. Есть Agent2Agent Protocol, но, по оценке того же разбора, он сырой (подробнее — спор о зрелости в самой заметке). То есть внутри одной системы иерархию собрать можно, а между системами разных вендоров — уже на своих договорённостях.

Глубина и противоречия воркеров

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

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

Связано с

  • Multi Agent Patterns — fan-out как плоский, нерекурсивный родственник
  • Agent CostControl — 20–30 вызовов за запуск — это прямая статья расходов
  • Hybrid Orchestration — способ удержать иерархию под контролем детерминированного слоя
  • Agent2Agent Protocol — чего не хватает для иерархии между разными системами
  • Multi Agent Systems — общая картина MAS