Vals AI сравнила одиночных ИИ-агентов и команды субагентов при разработке веб-приложений на бенчмарке Vibe Code Bench. Командная схема заметно увеличивала расходы, но её преимущество по качеству подтвердилось лишь в одном из четырёх сопоставлений. Для команд разработки это не запрет на мультиагентные системы, а сигнал: архитектуру с несколькими агентами нельзя считать улучшением по умолчанию, её нужно проверять на собственных задачах, ограничениях по времени и бюджете.

Что именно проверяли.

В исследовании Vals AI участвовали GPT-6 Sol и Claude Opus 5.5 в режимах medium и max reasoning effort. Для каждой модели и каждого уровня рассуждений сравнивали одного агента с командой, в которой ведущий агент распределял работу между помощниками, а затем собирал итоговое приложение. Всего тест охватил 50 приложений. Команды обходились в 1,8–5,1 раза дороже, а статистически значимое улучшение получил только GPT-6 Sol при среднем уровне усилий: результат вырос с 77,6% до 84,9%, или на 7,3 процентного пункта, при p = 0,005.

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

Интерпретацию ограничивает дизайн эксперимента. Как указывает описание теста на Habr, каждую из восьми конфигураций запускали один раз, а набор состоял только из задач по созданию веб-приложений. Такой бенчмарк не отвечает автоматически на вопрос о работе с крупными репозиториями, исследовательскими задачами, поддержкой кода или многошаговыми бизнес-процессами. Он также не измеряет последствия ошибок после внедрения и стоимость человеческого контроля.

Цена, качество и время расходятся.

Наиболее наглядны результаты GPT-6 Sol. В режиме medium одиночный агент в среднем стоил 1,22 доллара на приложение, а команда — 3,07 доллара. При max reasoning effort одиночный Sol достиг 89% при стоимости 4,82 доллара, тогда как команда получила 90,4% за 8,54 доллара. Иными словами, увеличение вычислительного усилия одиночного агента в этом случае дало больший прирост качества, чем переход к команде на среднем уровне усилий.

При этом стоимость и задержка не совпадают в одной метрике. По данным о сравнении, более крупные команды могли быстрее достигать заданного уровня качества, но расходовали больше токенов. Для Sol параллельное делегирование сократило медианное время работы в max-режиме с 38 до 28 минут. Если приложение нужно получить к конкретному сроку, сокращение времени выполнения может иметь самостоятельную ценность, даже когда качество меняется слабо.

У Claude Opus 5.5 картина оказалась другой. Ведущий агент обычно сначала формировал общий контракт между компонентами, а затем запускал последовательные волны разработчиков и тестировщиков. Команды Opus в тесте могли работать до 2,3 раза дольше одиночных агентов. В публикации Vals AI в X приведён показательный эпизод: max-команда Opus после первого развёртывания потратила медианные 68 агент-минут на тестирование против 10 у одиночного агента, но значимого преимущества по баллу это не принесло. Агент-минуты здесь важны как показатель суммарно оплачиваемой работы, а не календарной задержки для пользователя.

Почему мультиагентность быстро увеличивает счёт.

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

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

Как принимать решение о внедрении.

Переплачивать за команду агентов разумно не ради самого числа агентов, а ради измеримого результата. До масштабирования стоит сравнить одиночный агент, более высокий уровень reasoning effort и командный режим на одинаковом наборе реальных задач. Полезно отдельно фиксировать долю принятых результатов, стоимость завершённой задачи, время до готового изменения, число итераций проверки и объём ручных исправлений. Если команда сокращает критичную задержку или уверенно улучшает качество на задачах с разделяемыми частями, её дополнительные расходы могут быть оправданы. Если же выигрыш укладывается в статистический шум, базовым вариантом остаётся одиночный агент с контролируемым ростом вычислительных усилий.