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

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

— Топологии комбинируются тремя способами: вложением (одна внутри узла другой), последовательным соединением (выход одной — вход другой) и наложением (две оси над одним роем). У каждого способа своя модель отказов и свои правила проектирования стыка.

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

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

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

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

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

Глава 15. Выбор топологии под задачу

Предыдущие семь глав описали топологии как самостоятельные конструкции: оркестратор и

воркеры (глава 8), иерархии и субагенты (глава 9), конвейер (глава 10), blackboard (глава 11),

рыночные и аукционные модели (глава 12), сети равноправных агентов (глава 13) и гибриды

(глава 14). Каждая глава отвечала на вопрос «как устроен этот паттерн и когда он масштабируется».

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

ошибиться в этом выборе.

Выбор топологии — первое архитектурное решение в проектировании роя и самое дорогое для

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

(сквозная модель уровней: топология → роли → коммуникация → декомпозиция → координация →

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

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

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

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

«возьмём оркестратор, он привычнее».

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

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

зависимости, насколько результат проверяем. Второй — профиль отказов и стоимости: что ломается

чаще, что дороже терять, где допустима деградация. Третий — операционная реальность: кто будет

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

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

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

вообще различаются. Эти оси — не теоретическая классификация, а перечень вопросов, ответы на

которые предопределяют форму роя. Их три группы: структура работы, профиль рисков и стоимости,

операционный контекст.

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

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

распределителем: оркестратор раздаёт независимые куски воркерам и собирает результат (fan-out/

fan-in, глава 8). Если же части образуют цепочку, где выход одной стадии — вход следующей, форма

задачи — конвейер (глава 10), и попытка распараллелить то, что по сути последовательно, лишь

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

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

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

топология ей соответствует.

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

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

работает статическое распределение через оркестратор. Но бывает, что подзадачи рождаются в ходе

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

задачей. Здесь форма задачи — дерево, растущее во время исполнения, и ей соответствует иерархия

с субагентами (глава 9), где родитель порождает потомков по мере раскрытия задачи. Динамическое

порождение работы и управление его взрывом — предмет части V; на уровне топологии достаточно

различать «декомпозиция известна» и «декомпозиция раскрывается».

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

результат подзадачи верен. Если проверка дешева и объективна — компиляция прошла, тесты зелёные,

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

Если же качество результата субъективно или дорого в проверке — например, это оценка

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

состязательным и ансамблевым конфигурациям (дебаты, критик-генератор; глава 12 и часть IX),

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

доверять без внешнего арбитра.

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

границами разбивается заранее и раздаётся; задача с размытыми границами требует разведки прежде

декомпозиции. В первом случае оркестратор знает план с самого начала; во втором плану

предшествует фаза исследования, которую естественнее вести иерархией или через общую доску

(blackboard, глава 11), куда агенты складывают частичные находки до того, как структура задачи

прояснится.

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

возможных — приемлема. Это вторая группа осей, и пренебрежение ею — самая частая причина того,