Рой ИИ-агентов стоит вчетверо дороже одного. При равном бюджете мультиагентная система ему проигрывает

Anthropic отчиталась: их исследовательская система из ведущего агента и подчинённых обошла одиночного агента на 90,2%. Цифра разошлась по презентациям подрядчиков как доказательство, что рой умнее. В том же тексте есть вторая цифра, которую в презентации не переносят: расход токенов сам по себе объясняет 80% разброса результатов. Решает объём потраченных денег, а не архитектура.

Разберём цифру Anthropic целиком: она подрывает ровно тот вывод, который из неё делают.

Система устроена так: ведущий агент на старшей модели получает запрос, разбивает его на подзадачи и раздаёт трём–пяти подчинённым агентам на модели попроще. Каждый подчинённый работает в собственном окне контекста, ходит по источникам, возвращает сжатую выжимку. Ведущий собирает всё вместе. На внутреннем исследовательском тесте такая связка обошла одиночного агента на той же старшей модели на 90,2%.

Дальше — важное. Инженеры Anthropic разложили, чем объясняется разброс результатов на отдельном бенчмарке поиска информации. Три фактора закрывают 95% разброса: расход токенов, число вызовов инструментов и выбор модели. На один только расход токенов приходится 80%.

Читается это так: система выиграла главным образом потому, что ей разрешили потратить больше. Раздача работы по нескольким окнам контекста — способ купить больше вычислений на одну задачу, когда одно окно уже переполнено. В том же тексте Anthropic прямо пишет, что архитектура оправдана для задач, чья ценность покрывает пятнадцатикратный расход, и не подходит там, где агентам нужен общий контекст и тесная координация. Это большинство задач разработки.

Отдельная деталь для тех, кто считает бюджет: переход на более новую модель дал больший прирост, чем удвоение бюджета токенов на старой. Прежде чем строить рой, есть смысл проверить, не решается ли задача сменой модели.

Исследователи Стэнфорда зашли с другой стороны. Они взяли современные модели и задали жёсткий лимит токенов — одинаковый и для одиночного агента, и для мультиагентных конфигураций с планировщиками, критиками и параллельными исполнителями.

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

Причина механическая. Когда один агент ведёт задачу от начала до конца, у него в контексте лежат все промежуточные шаги: почему отбросил первый вариант, что показалось странным в данных, какое ограничение всплыло на третьем шаге. Когда работа передаётся другому агенту, она передаётся текстом. Всё, что не было проговорено явно, остаётся у отправителя.

Вторая причина — команда склонна к избыточному исследованию. Одиночный агент лучше держится изначальных рамок задачи. Группа расходится вширь, набирает материал и теряет верный ответ на этапе финальной сборки.

Обе причины усиливаются на длинных цепочках. В работе Google Research, DeepMind и MIT о масштабировании агентных систем есть цифры пожёстче: конфигурации, где агенты работали параллельно и не переговаривались, усиливали ошибки в 17,2 раза; с центральным координатором — в 4,4 раза. На задачах, требующих строгой последовательности рассуждений, мультиагентные варианты проседали на 39–70% против одиночного: обмен сообщениями дробил рассуждение и съедал бюджет, которого потом не хватало на саму задачу. Там же отмечено, что налог на координацию растёт непропорционально с числом подключённых инструментов. У типового бизнес-агента их сегодня легко за десяток.

В среднем по четырём бенчмаркам одиночный агент решил 46,6% задач, лучшая мультиагентная конфигурация — 47,7%. Один процентный пункт разницы при накладных расходах в 3,6 раза выше.

Три ситуации, в которых разделение на агентов перестаёт быть украшением.

Вход зашумлён. Если на входе поток, где полезное перемешано с мусором, одиночный агент вязнет. Здесь команда работает фильтром: один отсеивает, второй проверяет факты, третий пишет. Из форматов командной работы в экспериментах Стэнфорда лучше всех показала себя схема «дебатов», где агенты критикуют решения друг друга.

Объём не влезает в одно окно. Ровно случай Anthropic. Задача вроде «собрать состав советов директоров по полутысяче компаний» не помещается в одно окно контекста ни при каком бюджете. Разделение по окнам — единственный способ её взять.

Ветки независимы. Проверить безопасность, стиль и тесты в одном пул-реквесте можно параллельно, потому что проверки не зависят друг от друга. Пять параллельных агентов дадут ответ за время одного, а не за время пяти. Здесь у роя самый сильный аргумент: на параллелизуемых задачах вроде финансового анализа централизованная схема в той же работе Google дала +81% к результату.

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

Есть и четвёртый порог, обратный по смыслу. В той же работе Google нашли уровень, после которого добавлять агентов вредно: если одиночный агент уже решает задачу успешнее чем в 45% случаев, координация начинает съедать больше, чем приносит. Чем лучше работает ваш текущий вариант, тем меньше шансов, что рой его улучшит.

У меня самого крутится многошаговая система — ежедневный конвейер статей для Дзен-канала. Он попадает ровно в первое условие: на входе новостной дайджест, то есть шумный поток, из которого надо выбрать одну тему и довести до текста.

Как устроено. Оркестратор — обычный bash-скрипт. Он последовательно вызывает модели и передаёт состояние через файлы на диске. Восемь содержательных шагов: выбор новости, ресёрч через поисковый MCP, черновик, критик, редактор, очистка от машинных оборотов, финальная стилизация, промпт обложки. Дальше генерация картинки и выкладка в черновики Дзена.

Дешёвая модель везде, кроме одного шага. На финальную стилизацию идёт Sonnet — и работает в режиме простой трубы: текст на вход, текст на выход, без инструментов и схем. Этот шаг занимает 17 секунд из двадцати минут прогона.

Тайминги последнего рабочего запуска, 23 июля: старт 13:01, готовая статья с обложкой в черновиках Дзена — 13:21. Из этих двадцати минут почти половина, 9,5 минут, приходится на ресёрч с походами в веб. Остальные шаги укладываются в минуты и секунды.

Шаг «критик» — это тот самый паттерн «генератор-верификатор», который в теории описывают как простейшую мультиагентную схему. У меня он живой: 23-пунктный чеклист, каждое замечание обязано содержать цитату из черновика, формулировку проблемы и предложение правки. Без цитаты замечание не засчитывается. В прогоне 23 июля критик выдал три FAIL: по заголовку, по перегрузу терминами и по опечатке. Редактор их закрыл, статья пошла дальше.

Это конвейер, а не рой. Порядок шагов зашит в скрипт, а не выбирается моделью. Роли фиксированы. Ни один шаг не решает, кого позвать следующим. Именно поэтому его можно отлаживать: у каждого прогона своя папка с промежуточными файлами и логами, и при сбое видно, на каком шаге всё сломалось.

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

Раздел, которого нет в презентациях подрядчиков.

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

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

Потеря цели на длинной дистанции. Разработчики описывают эффект, при котором агент начинает терять исходную задачу примерно после 50 тысяч токенов контекста — при том, что место в окне ещё есть. В мультиагентной схеме этот эффект множится на число участников.

Оговорка. Форумные жалобы — не научные данные, и негативный опыт всегда громче спокойного. Я привожу их как повторяющийся сигнал: одни и те же претензии всплывают у разных людей на разных площадках и совпадают с тем, что показывают измерения.

С самими измерениями тоже нужна аккуратность. Работа Google — препринт, он сейчас проходит рецензирование. В свежей версии авторы уточнили механизм: разницу между архитектурами лучше объясняют накладные расходы и эффективность, а усиление ошибок само по себе значимым предиктором не оказалось. И проверялось всё на четырёх исследовательских бенчмарках, а не на потоке заявок из вашей CRM. Правило выбора архитектуры у авторов вышло рабочим, 87% попаданий на отложенных конфигурациях, но переносить его на свою задачу без прогона не стоит.

Порядок, который я применяю в работе с клиентскими задачами.

Ключевое — сравнивать при равных деньгах. Сравнение «одиночный агент за 30 рублей против роя за 120» ничего не доказывает.

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

Сложность архитектуры не означает зрелости решения. Восьмишаговый конвейер с фиксированным порядком отлаживается; рой из тех же восьми агентов, которые сами решают, кто следующий, — уже нет. При равном результате выигрывает то, что можно чинить.

Грязный вход — главный законный повод разделять роли. Если ваши данные приходят из почты, мессенджеров и сканов, разделение «отфильтровал → проверил → оформил» окупается. Если данные приходят из базы или формы, оно не нужно.

Прежде чем усложнять архитектуру, попробуйте сменить модель. По данным Anthropic это дало больший прирост, чем удвоение бюджета токенов. Это самая дешёвая из возможных правок.

Сколько стоит содержать мультиагентную систему по сравнению с одним агентом?
По данным Anthropic, агент расходует вчетверо больше токенов, чем обычный чат, а мультиагентная система — в 15 раз больше чата. То есть переход от одного агента к рою умножает счёт примерно вчетверо при прочих равных. Плюс растут скрытые расходы: время на отладку, мониторинг и разбор сбоев.

У меня обработка заявок с сайта и из мессенджеров. Мне нужен рой? Скорее конвейер с двумя-тремя фиксированными шагами, чем рой. Заявки из мессенджеров — умеренно шумный вход, там оправдан шаг нормализации перед основной обработкой. Но порядок шагов у вас предсказуем, а значит его стоит зашить жёстко, а не отдавать на усмотрение модели.

Мне предлагают «мультиагентную систему» под ключ. Как понять, что это не переплата?
Спросите три вещи: какой объём данных не влезает в одно окно контекста, какие шаги идут параллельно и почему, и сколько токенов тратит каждая из сравниваемых конфигураций. Если на первые два вопроса нет конкретного ответа, а третий не считали — вам продают архитектуру, а не результат.

Правда, что несколько моделей проверяют друг друга лучше, чем одна?
Перекрёстная проверка разными моделями действительно ловит часть ошибок — здесь разделение работает. Но это уже паттерн «генератор-верификатор» из двух шагов, а не рой из семи агентов. И у него есть предел: если оценить результат так же трудно, как его создать, проверяющий начинает штамповать одобрения.

Наши данные приходят сканами и письмами. Это тот самый «шумный вход»?
Да, это классический случай, когда разделение ролей окупается: один шаг вытаскивает данные, второй проверяет их на полноту, третий раскладывает по системе. Ошибка на входе здесь дорого стоит дальше по цепочке, поэтому отдельный проверяющий шаг оправдан.

Меня интересует опыт с другой стороны. Если у вас мультиагентная схема обошла одиночного агента при сопоставимом бюджете, расскажите, что за задача и как считали. Такие случаи мне нужнее всего: пока их набирается заметно меньше, чем историй про сожжённый бюджет.

Разборы своих пайплайнов, тайминги прогонов и грабли по ходу выкладываю в Telegram — @dmitra_ai.