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

прошли свои доли параллельно, и время сократилось с T примерно до T/5 плюс

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

кратное ускорение — для задачи, где важна скорость, это оправдано.

Тот же расчёт разоблачает плохую архитектуру. Возьмём вместо веера длинный

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

каждая стадия ещё и сверяется с предыдущей. Полезная работа та же, порядка B,

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

раунды согласования. Налог легко превышает B, overhead уходит за половину, и

при этом латентность не улучшается — конвейер последователен. Сравнение с baseline

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

baseline она выглядела бы «рабочей мультиагентной системой» и осталась бы в

production. Метод учёта — а не интуиция — показывает, что её надо упразднить.

Этот пример демонстрирует общее правило: налог считается как разность между

полной стоимостью роя и стоимостью baseline на ту же задачу, разнесённая по

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

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

Налог опасен не только величиной, но и характерными режимами отказа, в которых он

выходит из-под контроля. Эти режимы надо знать заранее, потому что все они

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

Самый частый и самый коварный failure mode — не авария, а тихая неэффективность.

Рой работает, выдаёт приемлемые результаты, проходит проверки. И только сравнение

с baseline (которого обычно нет) показало бы, что один агент справился бы дешевле и

не хуже. Система платит постоянный неоправданный налог годами, потому что её никто

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

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

дешевеют и усиливаются — вчерашний оправданный рой сегодня может проигрывать

одному агенту на новой модели.

Второй режим — неконтролируемый рост handoff и контекста сборщика. Он развивается

постепенно: каждая стадия добавляет к передаваемому контексту чуть больше «на

всякий случай», накопление по цепочке делает последние стадии и сборку всё

дороже, пока контекст не упирается в предел окна модели. Симптом — токенная

стоимость растёт быстрее объёма задачи. Защита — явные бюджеты контекста на стык,

компрессия и дистилляция на handoff (см. главу 52), отказ от передачи нарастающего

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

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

в раунды пересмотра, каждый раунд платный, число раундов растёт. В пределе это

livelock роя (см. главу 74): система занята, но не продвигается, а налог

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

пересекающимися областями, из-за которой конфликты неизбежны и многочисленны.

Защита — жёсткий потолок раундов согласования, после которого включается

детерминированное разрешение или эскалация к человеку (см. часть XIII), и

улучшение декомпозиции, снижающее пересечения в источнике.

Четвёртый режим — лавинообразное нарастание статьи повторов. Один ненадёжный стык

порождает повтор; повтор нагружает соседние компоненты; те начинают

тайм-аутиться и тоже повторяться. Налог на ошибки растёт нелинейно и может

доминировать над всей остальной работой. Это та же динамика, что retry storm в

распределённых системах. Защита — паттерны устойчивости из главы 70: тайм-ауты,

ограниченные повторы с backoff, circuit breaker, чтобы один больной стык не

заставлял весь рой переплачивать.

Пятый режим — не про токены, а про доступность. Каждый стык между агентами имеет

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

произведение доступностей звеньев и потому ниже доступности любого из них. Рой из

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

один агент, просто потому, что у него больше стыков, на каждом из которых что-то

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

падением доли успешных запусков. Защита — изоляция отказов (bulkhead, см.

главу 71) и проектирование на частичный результат (см. главу 73), чтобы отказ

одного стыка не обнулял работу всего роя.

Шестой режим — рост стоимости понимания и сопровождения системы. Чем больше

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

сессии (см. главу 81), тем больше кода в протоколах и тем выше когнитивная нагрузка

на оператора. Этот налог не отражается в токенах исполнения, но он реален и часто

оказывается решающим: система, которую невозможно отладить, дорога вне зависимости

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

после первого ночного инцидента.