Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 36)

Потеря при свёртке | снизу вверх | неверная агрегация результатов | проверяемый контракт агрегации, ограничение ветвления

Сиротские поддеревья | отказ внутреннего узла | падение/зависание субдирижёра | восстановление по ветвям, lease на уровне поддерева

Взрыв дерева | разрастание | отсутствие ограничителей | лимиты глубины, ветвления, бюджет поддерева

Дрейф намерения | накопление по швам | мультипликативная потеря смысла | сверка с исходной постановкой, лимит глубины

Локальный SPOF | отказ узла | внутренний узел незаменим для ветви | мелкие широкие деревья, защита корня

Иерархия — мощный, но дорогой инструмент, и его применимость определяется характером задачи, а не модой на «субагентов». Решение строить дерево, а не плоский слой, должно опираться на проверяемые критерии.

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

Иерархия не оправдана и вредна в нескольких типичных случаях. Если задача помещается в один контекст — дерево добавляет налог, не давая выигрыша; достаточно одного агента (см. главу 4 об антипаттерне мультиагентности ради мультиагентности). Если подзадачи независимы и однородны — нужен плоский fan-out (глава 8), а не дерево: глубина здесь только сериализует то, что должно идти параллельно. Если работа линейна и стадии фиксированы — это конвейер (глава 10), а не иерархия. Если требуется глубокое дерево лишь потому, что декомпозиция «красивее» выглядит вложенной, — это искусственная глубина, и она оплачивается дрейфом и латентностью без содержательной причины.

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

Практический способ выбрать глубину — идти от листьев вверх, а не от корня вниз. Сначала определяют, какая подзадача достаточно мала, чтобы один терминальный исполнитель решил её надёжно в пределах своего контекста, — это задаёт размер листа. Затем проверяют, можно ли собрать исходную задачу из таких листьев одним слоем агрегации; если да, дерево вырождается в плоский fan-out и иерархия не нужна. Глубже одного уровня имеет смысл идти лишь тогда, когда промежуточная сборка сама требует содержательного разбора, который не сводится к механическому слиянию. Каждый дополнительный внутренний уровень должен иметь явный ответ на вопрос «что этот уровень разбирает такого, чего не могут сделать ни его дети, ни его родитель». Уровень без такого ответа — это искусственная глубина, и его следует убрать.

Иерархия меняет и форму надзора человека над роем (часть XIII). В плоской топологии человек видит один слой исполнителей и одну точку сборки; контролировать достаточно корень и итог. В дереве промежуточные уровни скрыты: человек, наблюдающий корень, не видит, как декомпозиция дробилась вглубь и где именно сместилось намерение. Поэтому для глубокой иерархии точки человеческого контроля привязывают не только к корню, но и к границам уровней — к контрактам делегирования, где искажение ещё локализуемо. Чем глубже дерево, тем дороже надзор и тем важнее, чтобы каждое ребро было наблюдаемым и проверяемым. Это ещё один довод в пользу мелких деревьев: их проще удержать в поле зрения оператора целиком.

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

— Делегирование следует проектировать как проверяемый контракт (цель, срез контекста, формат результата, инварианты, границы), а не как пересказ задачи своими словами. Контракт — единственное место, где останавливается распространение искажения вниз и неверного результата вверх.

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

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

— Динамическое дерево безопасно лишь при жёстких внешних ограничителях — лимитах глубины и ветвления, бюджете на поддерево, явном условии остановки рекурсии, проверяемых кодом, а не самим агентом. Без них это незавершённая рекурсия с недетерминированным условием выхода.

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

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

Глава 10. Конвейер агентов (pipeline)

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

Это древнейший паттерн разделения труда — от мануфактуры до процессорного конвейера и Unix-pipe. В мультиагентных системах он привлекателен потому, что естественно ложится на задачи, которые человек и так мыслит стадиями: «сначала исследовать, потом спроектировать, потом написать, потом проверить». Соблазн прямой: дать каждой стадии своего узкоспециализированного агента, соединить их и получить надёжную сборочную линию. Соблазн обманчив. Конвейер из агентов наследует не только сильные стороны конвейерной модели, но и две её фундаментальные слабости, многократно усиленные природой агентов: его скорость ограничена самой медленной стадией, а его качество деградирует на каждой передаче контекста. Эта глава разбирает архитектуру конвейера, его узкие места и его failure modes — прежде чем разбирать, когда он вообще оправдан.

Базовый элемент конвейера — стадия (stage). Стадия — это агент или небольшая группа агентов, выполняющая одно преобразование над проходящим через неё артефактом. Стадия имеет контракт агента в строгом смысле главы 18: определённый тип входа, определённый тип выхода и инварианты, которые она обязуется соблюдать. Конвейер из N стадий — это композиция N контрактов, где выходной тип стадии k обязан быть совместим с входным типом стадии k+1. Если контракты не стыкуются, конвейер не работает не потому, что агенты плохи, а потому, что между ними зазор (см. главу 20).

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

исследование → план → черновик → ревью → правка → финал

Каждая стрелка — это передача артефакта (handoff, см. главу 47), и каждая стадия видит только то, что ей передал предшественник, плюс собственный системный промпт и инструменты. Это ключевое архитектурное свойство: в чистом конвейере стадия не имеет доступа ни к исходной постановке задачи (если её явно не протащили через все предыдущие стадии), ни к рассуждениям соседей. Она работает с тем, что лежит на входе.

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