Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 16)
вызов модели, а кворум требует, чтобы проголосовало достаточное число агентов.
Четвёртая статья — слияние частей в итоговый результат. Сборка редко сводится к
конкатенации: чаще нужно проверить совместимость частей, устранить дубли, привести
к единому стилю, верифицировать целое. Сборщик (см. главу 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 десять раз.
Третий механизм — итеративность согласования. Если рой требует нескольких раундов,