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

Матрицу следует читать сверху вниз как последовательность вопросов, а не как меню равноправных

опций. Первый вопрос — про форму зависимостей: независимы подзадачи, последовательны или

ветвятся. Он отсекает большинство строк. Второй вопрос — про известность декомпозиции и

проверяемость результата: он различает оставшиеся варианты. И только если ответы на первые два

выводят на централизованную форму, встаёт третий вопрос — про цену единой точки отказа, который

может сместить выбор к децентрализации ценой сложности.

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

и известности декомпозиции выбирается строка матрицы: это даёт топологию, архитектурно

соответствующую задаче. Затем профиль рисков проверяет, приемлема ли эта топология: если задача

по форме — конвейер, но жёсткая деградация конвейера недопустима, форму не меняют (задача всё

ещё последовательна), а усиливают — добавляют буферизацию и переподхват стадий (часть X).

Топологию меняют только тогда, когда профиль рисков несовместим с формой принципиально, — например,

когда централизованная по структуре задача обслуживает поток, не терпящий SPOF, и приходится идти

в peer-to-peer вопреки координационному налогу.

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

топологию, но запрещает те, которые команда не вытянет. Если по структуре и рискам напрашивается

blackboard, но у команды нет бюджета на наблюдаемость косвенной координации, честный выбор —

отступить к более простой и наблюдаемой форме, приняв, что она менее изящна, но эксплуатируема.

Простая топология, которую понимают и могут отладить, надёжнее сложной, которую никто не

контролирует. Это не компромисс качества ради удобства — это признание, что необслуживаемая

система ненадёжна по определению.

Отдельно стоит зафиксировать, чего матрица не делает. Она не выбирает число агентов, не назначает

роли, не определяет протоколы — это решения следующих уровней модели, и они принимаются после

того, как форма зафиксирована. Матрица также не заменяет проверку выбора на реальной нагрузке:

она сужает пространство до одного-двух кандидатов и называет ожидаемый отказ каждого, но

окончательная пригодность формы подтверждается только наблюдением за роем под профилем нагрузки,

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

обоснованным: заставить ответить на вопросы трёх входов прежде, чем форма роя закрепится в коде и

станет дорогой для пересмотра.

Матрица описывает доминирующий паттерн, а не всю систему. Production-рой почти никогда не является

чистой реализацией одной строки. Типичная система — оркестратор на верхнем уровне, под которым

часть воркеров сама разворачивается в конвейер, а отдельная ветвь использует состязательную

конфигурацию для шага, где качество субъективно. Гибридизация (глава 14) — норма, а не исключение.

Матрица применяется рекурсивно: к рою целиком — для выбора верхнеуровневой формы, и к каждой

крупной подзадаче — для выбора формы внутри неё. Ошибка — пытаться втиснуть всю систему в одну

строку; задача декомпозируется, и разные её части могут иметь разную внутреннюю топологию.

К трём входам решения примыкает четвёртое соображение, которое не выбирает топологию, но влияет

на то, с какой уверенностью её нужно фиксировать, — обратимость выбора. Топологии различаются не

только своими свойствами в работе, но и тем, насколько дорого с них уйти, если выбор окажется

неверным. Это самостоятельный критерий: при равной пригодности двух форм предпочтительна та, с

которой дешевле сойти.

Переходы между топологиями несимметричны по стоимости. Двигаться от простого к составному

сравнительно дёшево: оркестратор разворачивается в иерархию добавлением промежуточного уровня,

не ломая существующих воркеров; конвейер удлиняется новой стадией. Обратное движение — от

сложного к простому — почти всегда дороже: разобрать peer-to-peer обратно в оркестратор значит

переписать всю координацию, потому что децентрализованная логика согласования размазана по узлам

и не имеет центра, в который её можно собрать. Ещё дороже смена семейства: переход от

централизованной формы к децентрализованной и наоборот меняет роли, коммуникацию и координацию

одновременно (см. предыдущий раздел о топологии как корне модели уровней) и фактически означает

проектирование роя заново.

Отсюда практическое следствие для выбора в условиях неопределённости. Когда структура задачи ещё

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

формы, миграция из которой дешевле, — то есть с простейшей достаточной. Оркестратор, выбранный

как стартовая форма, оставляет открытыми пути роста в иерархию, конвейер и гибрид; peer-to-peer,

выбранный преждевременно, запирает в дорогой децентрализации, выход из которой потребует полной

переделки. Простая форма стоит дешевле не только в эксплуатации, но и в исправлении собственной

ошибки выбора. Это ещё один довод в пользу презумпции простоты: она минимизирует не только

текущий координационный налог, но и цену будущего разворота, если задача окажется не такой, какой

выглядела вначале.

Выбор топологии — не однократное решение, фиксируемое навсегда. Задача, под которую проектировался

рой, эволюционирует: растёт объём, меняется профиль нагрузки, появляются новые требования

безопасности. Топология, оптимальная для прототипа на пяти задачах, перестаёт быть оптимальной на

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

Типичная траектория — от простого к составному. Система начинается оркестратором с горсткой

воркеров, потому что это понятно и быстро. С ростом числа задач оркестратор становится узким