Почему большие мультиагентные команды буксуют
Когда LLM-агенты начали массово использовать в разработке, многие команды пошли по логичному, но не всегда рабочему пути: набрать как можно больше алгоритмических «специалистов» и раздать им роли. Один пишет код, второй ищет уязвимости, третий проверяет сценарии. Проблема в том, что каждый новый агент даёт всё меньше пользы: на задачах уровня целого репозитория расходы на координацию быстро перевешивают выигрыш от «дополнительных рук».
Реакцией на это стало движение в противоположную сторону: агентов превратили в субагентов — послушные инструменты, которые вызываются по запросу и не вступают в диалог. Такой подход избавляет от хаоса, но заодно уничтожает главный ресурс коллективной работы: никто больше не оспаривает чужие решения, а значит, ошибки проскальзывают незамеченными.
Точка равновесия: минимум кооперации
Поиском золотой середины занялись Eric S. Qiu и Joyce Gill в работе «Adversarial Review: Structured Disagreement for Grounded Agentic Code Review» (arXiv:2608.18167, категории cs.AI и cs.SE; подана 16 августа 2026 года, принята на ICML 2026 Workshop on DL4C). Их гипотеза проста: можно сохранить простоту субагентной архитектуры, но добавить в неё минимальную кооперацию — один узел, где мнения агентов намеренно сталкиваются.
Получился протокол Adversarial Review (AR). Авторы намеренно не строят сложную иерархию и не плодят множество ролей. Вместо этого работают три участника:
- кодирующий агент готовит изменения в коде;
- ревьюер оценивает, насколько эти изменения корректны;
- критик аудитирует не код, а само ревью и находит в нём слабые места.
Критик не просто говорит «я не согласен» — он выдвигает структурированное разногласие: указывает на конкретные фрагменты кода, которые не подтверждают выводы ревьюера. И только когда этот цикл пройден, основной агент получает разрешение вносить правки.
Что показали испытания
Эффект разногласия хорошо виден на результатах бенчмарков.
На LiveCodeBench AR показал самый высокий процент успешных прохождений среди всех протестированных методов. Важная деталь: для этого хватило трёх агентов, тогда как базовый вариант, который AR превзошёл, использовал пять.
На SWE-PRBench всё оказалось интереснее. Наивная версия протокола неожиданно вскрыла режим отказа, который авторы назвали ложным консенсусом: агенты сходились к общему мнению, не имея для этого достаточно доказательств. То есть даже специально выстроенное разногласие может выродиться в формальное «согласен со всеми». Лечится это одной итерацией промпта, где требование спорить и обосновывать несогласие прописано явно, — после такой доработки метод занял первое место по F1.
Наконец, на SWE-bench Verified AR снова улучшил результаты базовых подходов. Это важно, потому что задачи уровня репозитория — совсем другой масштаб сложности, чем изолированные функции: изменения в одном модуле могут ломать десятки соседних.
Вывод: силу даёт не число голосов, а право возражать
Авторы приходят к контринтуитивному, но подтверждённому экспериментом выводу: эффективное код-ревью не требует ни большой команды, ни сложных коммуникационных схем. Достаточно, чтобы разногласие было:
- минимальным — одна точка конфликта, а не бесконечный чат;
- структурированным — у каждого участника своя чёткая функция;
- доказательным — возражение опирается на факты в коде, а не на вкусовые предпочтения.
Практический урок для всех, кто строит агентные пайплайны: не пытайтесь решить проблему добавлением ролей. Лучше встроить в процесс обязательную стадию сомнения — и позволить одному агенту официально оспаривать выводы другого. Ценность ревью определяется не количеством голосов, а наличием того, кто способен возразить по существу.
