Проблема масштабирования агентов
Ранние системы с множеством LLM-агентов часто упирались в закон убывающей отдачи: добавление новых участников не улучшало качество кода, а лишь увеличивало задержку. Альтернативный подход, где агенты выступают как пассивные инструменты (subagents), лишал систему преимущества коллективного интеллекта. Авторы Eric S. Qiu и Joyce Gill предложили «золотую середину» — минимальное кооперативное взаимодействие.
Архитектура Adversarial Review (AR)
Метод использует всего три агента, но выстраивает их во взаимодействие, основанное на конструктивном несогласии:
- Main Agent: Пишет код.
- Reviewer: Оценивает написанное.
- Critic: Аудирует сам процесс ревью, выявляя ошибки или предвзятость ревьюера через структурированное несогласие.
Ключевая идея: спор должен быть минимальным, но строго обоснованным фактами, а не просто мнением.
Результаты бенчмарков
Метод показал выдающиеся результаты на трех ключевых наборах данных, обогнав более сложные базовые линии:
| Бенчмарк | Результат AR | Сравнение с базовыми линиями |
|---|---|---|
| LiveCodeBench | Наивысший pass rate | Превзошел 5-агентную базовую линию, используя всего 3 агента |
| SWE-PRBench | Наивысший F1 score | После добавления итерации несогласия устранил проблему «ложного консенсуса» |
| SWE-bench Verified | Улучшение метрик | Превосходство над базовыми методами в задачах уровня репозитория |
Почему это важно
Исследование, принятое к воркшопу DL4C на ICML 2026, меняет парадигму разработки AI-ассистентов. Оказывается, сложность коммуникации между агентами не так важна, как наличие механизма проверки. Метод AR доказывает, что даже простая структура «автор-ревьюер-критик» эффективнее громоздких многоагентных команд, если в ней заложено право на аргументированное несогласие.
Источник: arXiv cs.AI ↗