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

местом на сборке (fan-in перегружается), и под ним вырастает иерархия: воркеры-агрегаторы берут

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

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

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

что разные масштабы требуют разных форм.

Опасность здесь — эволюция топологии без явного решения. Когда форма роя меняется наслоением

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

вызовом, — система превращается в незапланированный гибрид, в котором никто не может назвать

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

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

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

под новую форму.

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

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

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

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

по которым это распознаётся (координационные издержки, загрузка центра, доля времени на

согласование), — предмет наблюдаемости роя (часть XI); здесь важно лишь, что смена топологии

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

Ошибки выбора топологии отличаются от ошибок внутри топологии тем, что проявляются не сразу.

Неправильно настроенный таймаут виден на первом прогоне; неправильно выбранная топология работает

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

месяцы эксплуатации, когда переделка стоит на порядок дороже. Ниже — типовые провалы именно

процесса выбора, а не реализации.

Самый распространённый отказ — выбор не делается вовсе. Берётся топология, привычная команде или

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

оркестратор с воркерами — он концептуально прост и хорошо поддержан инструментами. В результате

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

ценой лишних handoff; а задача с размытой постановкой загоняется в жёсткий план, который

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

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

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

библиотеки, и структура задачи в решении не участвует вовсе. Симптом — топология одинакова во всех

проектах команды независимо от задачи. Лекарство — обязательная явная фиксация трёх входов решения

(структура, риски, контекст) до выбора формы, даже когда выбор кажется очевидным; форма по

умолчанию принимается, только если она прошла те же три вопроса, а не потому, что её проще

запустить.

Зеркальный отказ — выбор сложной топологии там, где хватило бы простой. Команда, наслышанная о

хрупкости централизации, сразу строит peer-to-peer или blackboard, чтобы «не иметь SPOF» и «быть

масштабируемой». Для задачи на десяток агентов это означает оплату полного координационного

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

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

случай антипаттерна «мультиагентность ради мультиагентности» (см. главу 4) на уровне топологии.

Симптом — сложность топологии не обоснована ни одним измеримым требованием. Лекарство —

презумпция простейшей достаточной формы: децентрализация принимается только под доказанное

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

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

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

раздел о стоимости смены решения выше). Поэтому при сомнении выбор смещают в сторону недостройки,

а не запаса.

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

Архитектурно безупречный blackboard или peer-to-peer передаётся команде, у которой нет ни

инфраструктуры наблюдаемости под косвенную координацию, ни опыта отладки эмерджентных сбоев. Рой

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

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

его удаётся только в инциденте. Симптом — на этапе проектирования не задан вопрос «как мы будем

это отлаживать и останавливать». Лекарство — наблюдаемость и управляемость как обязательный

критерий выбора, равноправный со структурой и рисками, а не как то, что «добавим потом».

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

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

подходит. Последовательный этап исполняется через оркестратор с лишними handoff; шаг,

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

Симптом — попытки описать всю систему одной строкой матрицы, натянутость объяснений «почему здесь

тоже оркестратор». Лекарство — рекурсивное применение матрицы: верхний уровень и каждая крупная

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