Четыре тысячи токенов на входе, восемьсот на выходе и сорок пять секунд задержки в девяносто девятом перцентиле. Все это для того, чтобы сгенерировать банальный SQL-запрос, сходить в локальную базу данных и отформатировать ответ в JSON. Именно так выглядит типичный прототип современной ИИ-архитектуры за неделю до того, как система ложится под реальной нагрузкой, а заказчик начинает задавать неудобные вопросы про утилизацию серверного оборудования. Моя позиция здесь железобетонная: большинство так называемых продвинутых архитектур — это откровенный оверинжиниринг. Тема нашего жесткого аудита — оркестрация мульти-агентных систем: когда один агент не тянет и нужны планировщик и верификатор, и вы обязаны понимать, что это сценарий исключительно для тяжелых инцидентов. Восемьдесят процентов индустриальных задач блестяще закрываются одной единственной моделью, к которой прикручен конечный автомат и грамотно настроенная генерация по схеме. Если вы начинаете плодить автономные сущности сразу после того, как базовая модель пару раз перепутала столбцы в базе, вы строите распределенный монолит на текстовых промптах.
Кстати, о конечных автоматах и логике управления. Половина рынка упорно пытается заставить веса нейросети заниматься маршрутизацией потока выполнения. Разработчики пишут гигантские системные промпты, умоляя модель решить, какой из двадцати скриптов ей нужно запустить следующим. Перестаньте заставлять языковую модель быть вашим Python-интерпретатором. Пусть жесткий предсказуемый код управляет логикой и переходами состояний, а модель занимается исключительно тем, для чего создана — семантической трансформацией и извлечением данных. Как только вы переносите control flow в зону ответственности нейросети, вы получаете плавающую точку отказа.
Если вы все-таки решили усложнить систему, особенно в жестких условиях on-premise развертывания или RAG на изолированных серверах, необходимо точно знать границу применимости. Первый реальный симптом того, что моно-агентная архитектура исчерпала себя — это деградация внимания модели на кросс-доменных задачах. Когда контекстное окно забивается противоречивыми инструкциями от юриста, дата-инженера и специалиста по безопасности одновременно, генератор начинает терять фокус. Он может написать отличный код для парсинга контракта, но к моменту вывода напрочь забудет о политике маскирования персональных данных, потому что эта инструкция находилась в слепой зоне. Второй симптом — цена ошибки такова, что пайплайн требует независимой циклической проверки. Генерация кода, запуск в песочнице, чтение трейсов ошибок и повторная попытка — это классический случай, где одиночный исполнитель неизбежно запутается в собственной истории чата и начнет циклично повторять одну и ту же неверную строчку.
В этот момент возникает потребность в разделении труда. Чтобы гарантированно похоронить производительность, достаточно дать всем участникам процесса права на чтение и запись в одну гигантскую текстовую переменную и назвать это разделяемым состоянием. В действительно работающей оркестрации роли изолированы с параноидальной жестокостью. Сначала вступает планировщик — тяжелая, умная модель, чья единственная задача заключается в декомпозиции запроса в направленный ациклический граф минимальных подзадач. Планировщик не пишет код и не ищет данные. Затем роутер, который в идеале вообще не должен быть нейросетью, а скорее быстрым классификатором на эмбеддингах, раскидывает задачи по специализированным воркерам.
Самый критичный блок этой цепочки — связка верификатора и критика. Исполнитель делает свою работу, например, пишет регулярное выражение. Верификатор — это жесткий программный блок, который пытается скомпилировать или провалидировать результат по строгой схеме. Он не использует токены, он использует ресурсы процессора. А вот если результат требует оценки стиля или соответствия бизнес-правилам, которые нельзя описать кодом, подключается критик. Это отдельная LLM, которой на вход подается только изначальная цель и текущий результат. Разделяемое состояние между узлами обязано быть строгим графом объектов, идеально описанным через типизированные структуры данных. В контекст следующего шага передается только чистая дельта выполнения, а не простыня взаимных рассуждений предыдущих шагов.
Оркестрация мульти-агентных систем: когда один агент не тянет из-за координации
Выбор способа координации — место, где ломается большинство пет-проектов, выходящих в продакшен. Самый популярный способ выстрелить себе в ногу — реализовать произвольный граф, где любой узел обращается к любому другому. На доске в переговорке такие схемы выглядят инновационно, но под реальной нагрузкой они деградируют в бесконечные циклы взаимных уточнений. Если исполнитель имеет право запросить дополнительные данные у планировщика, а тот делегирует уточнение роутеру, лимиты контекста исчерпаются раньше формирования полезного ответа.
Гораздо более предсказуемо работает жесткая иерархия. Это строгий паттерн, где управляющий узел ставит задачу, рабочие узлы возвращают результат, и на этом их коммуникация заканчивается. Существует также архитектурный подход blackboard, при котором агенты непрерывно наблюдают за общим информационным пространством и берут в работу те фрагменты данных, которые соответствуют их компетенции. С математической точки зрения это изящно. С инженерной точки зрения на edge-вычислениях — это сущий кошмар. Когда в стойке стоит сервер с четырьмя видеокартами, физически невозможно держать в видеопамяти пять различных нейросетей, ожидающих появления задачи на доске. Приходится постоянно выгружать и загружать веса моделей, что добавляет катастрофические задержки на каждое движение в системе.
Математика отказа: скрытая стоимость и физика токенов
Самое страшное — полное игнорирование физики инференса. Многие инженеры воспринимают добавление нового агента так же, как развертывание еще одного микросервиса в кластере. Это фундаментальное непонимание процесса. Каждый добавленный узел — это жесткий мультипликатор задержки. Если базовая модель генерирует ответ за две секунды, простая цепочка из планировщика, пары исполнителей и критика отработает не за восемь секунд, а за все шестнадцать.
Деградация происходит из-за чудовищных накладных расходов на перенос контекста. В микросервисах передается легковесный пакет байтов. В мульти-агентной среде текстовый вывод одной модели вставляется в промпт другой. Для нейросети это означает, что фаза обработки входных данных начинается с чистого листа. Время до первого токена пересчитывается заново. Если нет низкоуровневых механизмов разделения кэша внимания между моделями на уровне видеопамяти, железо пережевывает одни и те же базовые инструкции на каждом шаге оркестрации. При пяти звеньях в цепочке задержка легко пробивает потолок в тридцать секунд, делая систему непригодной для синхронного взаимодействия.
Помимо задержек, существует суровая математика стоимости. Рост расходов масштабируется линейно только в идеальном мире, где критик всегда соглашается с исполнителем. В реальности критик бракует работу и отправляет ее на переработку. Исходный запрос на две тысячи токенов превращается в лавину. Планировщик читает эти две тысячи. Исполнитель читает исходник и план — это уже три тысячи. Критик читает исходник, план и результат работы — это четыре тысячи токенов контекста. В сумме аппаратура обрабатывает девять тысяч токенов входных данных для обслуживания одного пользовательского вызова. При каждой итерации ошибки этот ком нарастает.
Именно поэтому проектирование взаимодействия должно начинаться с безжалостного аудита задачи. Если разные доменные контексты можно упаковать в один системный промпт без ощутимой просадки бенчмарков качества — пакуйте и используйте одиночную генерацию. Внедрение сложной маршрутизации, критиков и разделенных состояний имеет смысл ровно в одной ситуации: когда физического объема весов и окна внимания одиночной сети фундаментально не хватает для удержания взаимоисключающих требований, а алгоритмическая декомпозиция становится вопросом выживания продукта. Все остальное — это попытка решить проблемы грязных данных за счет сжигания вычислительных мощностей.