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

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

Failure modes эмерджентного роя: несходимость (нет решения); коллективный livelock; нежелательная эмерджентность без точки локализации; невозможность вмешаться адресно (нет центра, через который остановить или скорректировать).

Свойство | Ансамбль | Оркестрация (топология) | Рой (узкий, эмерджентный)

Распределение работы | репликация (одна задача всем) | партиционирование (разные части) | партиционирование, динамическое

Локус решений | агрегатор на выходе | выделенный оркестратор | отсутствует (распределён)

Взаимодействие участников | нет (изолированы) | через оркестратор | косвенное (среда, события, соседи)

Что даёт | устойчивость и качество итога | пропускная способность, управляемость | устойчивость к потере узла, гибкость

Главная цена | избыточная стоимость (×N) | SPOF и узкое место оркестратора | непредсказуемость, несходимость

Параллелизм | высокий (мало связей) | высокий, но ограничен оркестратором | высокий, но координация скрыта

Управляемость | высокая (просто) | высокая (центр) | низкая (нет центра)

Наблюдаемость | простая | средняя (через центр) | трудная (причинность размазана)

Характерный отказ | коррелированные ошибки | падение оркестратора | livelock, несходимость

Таблица иллюстративна: она огрубляет спектр до трёх колонок. Реальные системы располагаются между ними и смешивают строки. Но именно эти три области задают рамку, в которой ведётся остальное обсуждение.

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

Говоря «централизованное», нужно уточнять, что́ централизовано, потому что централизация — не одно свойство, а несколько независимых.

Можно централизовать принятие решений (кто решает, что делать дальше), состояние (где живёт истина о системе), коммуникацию (всё идёт через хаб против прямых связей) и контроль изменений (кто имеет право писать). Эти оси ортогональны. Система может иметь централизованное принятие решений, но распределённое состояние; или общую централизованную память, но равноправных участников без дирижёра. Фраза «система централизована» без уточнения оси малоинформативна.

Наиболее частая и важная для надёжности — централизация контроля изменений. Принцип single-writer (один писатель на единицу состояния) резко упрощает координацию и устраняет целый класс гонок, независимо от того, централизованы ли решения (см. главу 41). Можно строить систему с распределёнными решениями, но строго централизованным правом записи на каждый ресурс — и это часто лучший компромисс.

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

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

Строгая оркестрация. Оркестратор задаёт каждый шаг, воркеры не имеют свободы. Максимум предсказуемости и наблюдаемости, минимум гибкости. Оркестратор — явный SPOF.

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

Координация через общую доску (blackboard). Нет команд сверху; участники читают и пишут общее пространство, реагируя на его состояние (см. главу 11). Решения распределены, но состояние централизовано — доска становится и точкой согласования, и точкой отравления.

Рыночная и аукционная координация. Задачи распределяются через торги между агентами (см. главу 12). Локус решений распределён, но протокол торгов играет роль слабого центра.

Сеть равноправных агентов (peer-to-peer). Прямые связи без хаба, согласование через переговоры или консенсус между равными (см. главы 13 и 39). Ни центра решений, ни центра коммуникации.

Эмерджентный рой. Локальные правила, косвенное взаимодействие, глобальное поведение возникает само. Предел децентрализации.

Режим | Локус решений | Связь | SPOF | Предсказуемость | Гибкость

Строгая оркестрация | один центр | через хаб | да (оркестратор) | высокая | низкая

Иерархия | центры по уровням | через дерево | частичный (по узлам) | средняя | средняя

Blackboard | распределён | через общее состояние | да (доска) | средняя | средняя

Рынок/аукцион | распределён | через протокол торгов | слабый (протокол) | средняя | высокая

Peer-to-peer | распределён | прямые связи | нет | низкая | высокая

Эмерджентный рой | отсутствует | косвенная | нет | низкая | высокая

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

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

Ошибки на оси централизации дают узнаваемые отказы.

Чрезмерная централизация: оркестратор насыщается и становится узким местом; его падение останавливает всё; недетерминированный оркестратор-модель сам вносит ошибки, которые некому проверить, потому что он — вершина.

Чрезмерная децентрализация: система не сходится; возникает коллективный livelock; нежелательное эмерджентное поведение нельзя локализовать и адресно погасить; нет точки для человеческого вмешательства, и единственный доступный контроль — грубая остановка всего.

Скрытая централизация: систему объявили децентрализованной, но на деле все участники зависят от одного общего ресурса (одна доска, одна очередь, одна база) — он и есть необъявленный SPOF, защита которого не заложена, потому что его существование не признано. Это частый и опасный случай: риск есть, а его никто не моделировал.

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

Гомогенный рой — участники одинаковы (одна модель, один промпт, одна роль). Гетерогенный — участники различаются (разные модели, специализации, права). Это ось разнообразия, ортогональная топологии: гомогенным или гетерогенным может быть и ансамбль, и оркестрация, и эмерджентный рой. Различие важно для качества (ансамблевый эффект требует разнообразия — глава 63) и для безопасности (гомогенный рой имеет общую уязвимость: одна инъекция работает против всех — глава 86). Но это не тип топологии, а свойство состава.

Статическая конфигурация фиксирована до запуска: известно, сколько агентов, какие роли, какие связи. Динамическая меняется в ходе работы: агенты порождаются и завершаются, роли назначаются на лету (см. главу 21), работа рождает новую работу (см. главу 34). Это ось изменчивости структуры во времени, ортогональная и топологии, и составу. Динамическая конфигурация мощнее, но добавляет риск неконтролируемого роста (взрыв числа агентов и подзадач) и усложняет наблюдаемость: топология, которую отлаживают, отличается от той, что была вчера.