18+
реклама
18+
Бургер менюБургер меню

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

18

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

Четвёртая статья — слияние частей в итоговый результат. Сборка редко сводится к

конкатенации: чаще нужно проверить совместимость частей, устранить дубли, привести

к единому стилю, верифицировать целое. Сборщик (см. главу 37) — это агент или

процедура с собственной стоимостью, и его вход — это все результаты исполнителей

сразу, то есть потенциально очень большой контекст. На fan-in налог на контекст

достигает пика: один компонент должен вместить то, что произвёл весь рой.

Пятая статья — постоянные издержки самого механизма координации, не зависящие от

содержания задачи. Сюда входят: системные промпты каждого агента (повторяются при

каждом вызове), служебные поля сообщений, метаданные маршрутизации (см. главу 27),

heartbeat и проверки живости, накладные расходы очередей и шины событий. По

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

и на масштабе роя становятся заметной долей.

Шестая статья — не плановая, а вероятностная: работа, потраченная на исправление

сбоев самой координации. Потерянное сообщение требует повтора; зависший агент

требует переподхвата его задачи (см. главу 72); рассогласованное состояние требует

повторного согласования. Эта статья — налог на ненадёжность стыков, и она тем

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

означает двойную оплату: первая попытка уже потрачена.

Сведём статьи в таблицу как чек-лист для оценки налога конкретной системы.

Статья | Что оплачивает | Чем измеряется | Как растёт

Декомпозиция | Разбиение задачи, постановка подзадач | Токены планировщика | С числом и сложностью подзадач

Handoff | Передача контекста на стыках | Токены контекста, потеря информации | С числом стыков и накоплением контекста (до квадратичной)

Согласование | Разрешение конфликтов, консенсус | Токены раундов, число голосов | С пересечением областей и числом раундов

Сборка (fan-in) | Слияние и верификация частей | Токены сборщика | С числом и объёмом частей

Протокол | Системные промпты, метаданные, heartbeat | Токены на сообщение | С числом агентов и сообщений

Ошибки и повторы | Исправление сбоев координации | Токены повторов | С числом стыков и их ненадёжностью

Источники налога важны качественно; для проектирования важно знать, как он растёт

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

на порядок роста. Все числа ниже иллюстративны и приводятся как порядок величины.

Главная причина, по которой налог опасен, — он часто растёт быстрее, чем число

агентов. Полезная работа в идеале растёт линейно: вдвое больше исполнителей —

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

плотно связанной топологии растёт квадратично. Если каждый агент в принципе может

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

если реально используется лишь часть связей, тенденция сохраняется: добавление

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

Это приводит к характерной кривой. На малом числе агентов полезная работа растёт

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

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

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

точкой — убывающая отдача и затем отрицательная (см. главу 60). Закон Амдала для

роёв (см. главу 56) описывает тот же эффект со стороны последовательной доли:

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

потолок ускорению.

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

для базовых топологий части II.

Топология | Порядок числа стыков | Где налог концентрируется

Оркестратор и воркеры | Линейный (N связей с центром) | На оркестраторе и в сборке

Конвейер | Линейный (N−1 стык) | В накоплении контекста по стадиям

Иерархия | Линейный по дереву, но растёт с глубиной | На handoff между уровнями

Blackboard | Линейный по обращениям к доске | В согласованности общей доски

Peer-to-peer (полная связность) | Квадратичный | В попарном согласовании

Отсюда практический вывод, к которому глава вернётся в выводах: выбор топологии —

это прежде всего выбор закона роста налога. Звёздная топология (оркестратор) держит

налог линейным ценой единой точки отказа в центре (см. главу 75); полносвязный

peer-to-peer избегает SPOF ценой квадратичного согласования (см. главу 13).

Второй механизм роста — накопление контекста. В конвейере, где каждая стадия

добавляет к контексту и передаёт дальше, объём handoff на последней стадии

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

растёт квадратично от её длины. Это объясняет неинтуитивное наблюдение: углубление

цепочки агентов часто дороже, чем расширение веера. Веер из десяти параллельных

воркеров платит handoff один раз на вход и один раз на сборку; цепочка из десяти

последовательных агентов платит нарастающий handoff десять раз.

Третий механизм — итеративность согласования. Если рой требует нескольких раундов,