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

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

Первая ось рисков — цена единой точки отказа. Любая топология с центральным узлом

(оркестратор, корень иерархии, аукционист рынка) делает этот узел single point of failure: его

отказ останавливает весь рой. Надёжность оркестратора как SPOF — отдельная большая тема (часть X),

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

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

централизации в пользу peer-to-peer (глава 13), где нет узла, чья гибель фатальна. За это платят

многократно возросшей сложностью согласования — децентрализация устраняет SPOF, но вводит

проблему распределённого консенсуса (часть VI).

Вторая ось рисков — стоимость координационного налога относительно размера задачи. Координация

всегда стоит — это сквозной тезис книги (см. главу 5). Топологии различаются величиной этого

налога. Конвейер дёшев в координации: каждая стадия общается только со следующей. Оркестратор

дороже: центр должен раздать, отследить и собрать. Blackboard дороже ещё: все агенты читают и

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

Peer-to-peer дороже всех: число потенциальных связей растёт квадратично числу агентов. Для

небольшой задачи накладные расходы децентрализации съедают весь выигрыш; топология, оправданная

на сотне агентов, разорительна на пяти.

Третья ось рисков — допустимость частичного результата. Можно ли отдать пользователю

неполный, но полезный итог, если часть роя отказала. Топологии с независимыми воркерами

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

собирается (graceful degradation, часть X). Конвейер деградирует жёстко: отказ любой стадии

останавливает поток целиком, потому что следующая стадия не получит вход. Если задача допускает

«девять результатов из десяти» — это аргумент за параллельные независимые топологии; если нужен

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

Четвёртая ось рисков — поверхность атаки и границы доверия. Каждый канал между агентами — это

путь распространения компрометации (часть XII). Топологии с богатой связностью (blackboard,

peer-to-peer) имеют большую поверхность: испорченное состояние или инъекция, попавшие в общую

доску, видны всем (отравление общей памяти, см. часть VII; распространение инъекции, см. часть

XII). Топологии со строгой направленной коммуникацией (конвейер, иерархия) локализуют

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

проще перехватить на стыке. Если рой работает с недоверенными входами или повышенными

требованиями безопасности, это смещает выбор в сторону топологий с узкими, проверяемыми каналами.

Третья группа осей — про тех, кто будет с роем жить после запуска. Эта группа систематически

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

демонстрации, а через недели эксплуатации.

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

насколько их поведение поддаётся восстановлению постфактум. Конвейер и оркестратор наблюдаемы

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

(трассировка через несколько агентов, см. часть XI). Blackboard наблюдаем хуже: координация

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

Peer-to-peer наблюдаем хуже всех: нет центра, через который проходят события, и сборка картины

сессии требует отдельной инфраструктуры (реконструкция сессии роя, см. часть XI). Команда без

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

невозможно отладить, когда он сломается, — а он сломается.

Вторая ось контекста — возможность надзора и вмешательства. Где человек встанет в контур и

как он остановит рой при сбое (часть XIII). Централизованные топологии дают естественную точку

надзора и аварийной остановки: оркестратор — это и пульт, и kill-switch. Децентрализованные

топологии такой точки не имеют — остановить peer-to-peer-рой сложнее, потому что нет узла, через

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

гарантированной аварийной остановки, это требование почти диктует наличие центрального узла.

Третья ось контекста — зрелость команды и стоимость сопровождения. Простые топологии

(оркестратор, конвейер) понятны, предсказуемы, обучают новых инженеров за часы. Сложные

(blackboard, рынок, peer-to-peer) требуют, чтобы команда понимала распределённый консенсус, гонки

за ресурсы и эмерджентное поведение. Топология, которую некому правильно эксплуатировать, — это

технический долг с первого дня, какой бы изящной она ни была.

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

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

порождает множество архитектурно допустимых форм — обычно одну-две. Профиль рисков сужает это

множество до приемлемых. Операционный контекст отсекает из приемлемых те, что неисполнимы

данной командой. Решение — это пересечение трёх множеств, и если пересечение пусто, значит,

задача в текущей постановке не имеет хорошей топологии и нужно менять не форму роя, а саму

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

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

конфликтовать с одним из входов всегда; вопрос лишь, какой ценой и когда конфликт проявится.

Из этой иерархии следует практическое правило приоритета при конфликте. Операционный вход имеет