Мультиагентный AI в бизнесе: координация важнее мощности модели
Команда из четырёх AI-агентов, оснащённых протоколом асинхронной координации AgentRadio, решила 62,1% задач на корпоративных кодовых базах — против 57,2% у одного агента на более продвинутой модели Claude Opus 4.8. Этот результат был получен исследователями из Coral AI Labs и ряда университетов при тестировании на 124 задачах из бенчмарка SWE-Atlas QnA.
Для руководителей, внедряющих AI в инженерные и аналитические процессы, это означает смену приоритета: архитектура взаимодействия агентов может давать больший прирост результативности, чем переход на следующую версию модели.
Почему одиночный агент перестаёт справляться
Работа с большими корпоративными репозиториями — один из наиболее сложных сценариев для AI-агентов. Агент должен не просто читать код, но и запускать программу, отслеживать пути выполнения через множество файлов и удерживать в памяти противоречивые данные на протяжении длительной сессии.
По данным исследователей, одиночный агент на Claude Opus 4.6 справляется лишь с 32,3% задач из бенчмарка. Переход на Opus 4.8 поднимает показатель до 57,2%. Ограничение здесь не в вычислительной мощности: проблема в том, что по мере роста контекста начальный план становится всё сложнее пересматривать, а поздние открытия уже не успевают скорректировать ранние решения.
Разделение задачи между несколькими агентами выглядит очевидным решением. Однако большинство существующих мультиагентных систем страдают от одного структурного изъяна: агенты либо работают полностью изолированно, либо обмениваются данными только в заранее заданных контрольных точках. В обоих случаях открытие, сделанное одним агентом в середине выполнения задачи, не попадает к другим вовремя.
Исследователи описывают типичный сценарий провала: агент, анализирующий поведение API, обнаруживает данные, которые опровергают гипотезу агента, работающего со слоем хранения. Если эта информация поступит только на финальном этапе синхронизации, второй агент завершит анализ по ошибочному пути. Исправить ошибку будет дороже, чем если бы агенты скоординировались немедленно.
Что меняет AgentRadio и как это влияет на бизнес
AgentRadio — это слой асинхронной передачи сообщений, который встраивается поверх существующих агентных сред, таких как Claude Code или Codex CLI, без изменения самих моделей. Агенты получают три операции: открыть тред, отправить сообщение не прерывая работу, и принять уведомление в фоновом режиме.
Ключевое свойство архитектуры — пассивная осведомлённость: агент продолжает выполнять свою задачу и одновременно получает обновления от коллег. Как только один агент транслирует важное открытие в общий лог, остальные немедленно учитывают его в следующем шаге работы.
На практике это выражается в следующем: при тестировании на задаче с системой MinIO два агента без асинхронной коммуникации независимо пришли к одному выводу о необходимости серверных логов, но не смогли передать эту информацию друг другу. В результате команда единогласно выдала неверный ответ. С AgentRadio один агент мгновенно опубликовал находку, остальные скорректировали свой анализ — итоговый результат по задаче вырос с провального до максимального.
Важно также учитывать стоимость координации. Средние расходы на API выросли с 2,96 доллара за задачу при одном агенте до 19,45 доллара при полной конфигурации AgentRadio. Однако когда исследователи потратили сопоставимую сумму — 17,76 доллара — на шесть независимых запусков одного агента, результат составил лишь 37,9% против 62,1% у AgentRadio. Это означает, что рост затрат при правильной архитектуре обеспечивает качественно иной результат, а не просто линейный прирост.
Для бизнеса критически важно понимать, когда мультиагентная схема оправдана. Исследователи формулируют критерий через понятие «точек смены ответственности»: это моменты, когда компетентный инженер привлёк бы другого специалиста — потому что задача пересекает границу владения, требует независимой гипотезы или несёт риск, требующий отдельной верификации.
Сценарии, где мультиагентная координация даёт прирост:
- архитектурные вопросы уровня всего репозитория;
- расследование инцидентов, затрагивающих несколько сервисов;
- анализ безопасности и миграции зависимостей;
- работа с незнакомыми унаследованными системами;
- рефакторинг, охватывающий несколько модулей.
Для локальных, ограниченных и обратимых задач — правки одного файла, генерации шаблонного кода — одиночный агент остаётся более экономичным и предсказуемым выбором.
Исследователи также фиксируют нерешённую проблему: пассивная осведомлённость распределяет уже существующие идеи между агентами, но не порождает гипотезы, которые никто из них не сформировал. В тестах с платформой Grafana четыре из девяти проверочных критериев требовали отрицательных выводов — например, зафиксировать, что определённое поведение не произошло. Ни один агент этого не сделал, и AgentRadio не помог. Это ограничение важно учитывать при проектировании AI-процессов.
Параллельно исследователи разрабатывают коммерческий продукт Coral Code, основанный на тех же принципах. В отличие от исследовательской реализации с фиксированной командой из четырёх агентов, Coral Code предполагает динамическое масштабирование: инженер начинает с привычного инструмента, а дополнительные агенты подключаются только тогда, когда сложность задачи этого требует.
Практический вывод: если ваша команда использует AI-агентов для анализа кода, расследования инцидентов или работы с крупными системами, оцените не только качество модели, но и архитектуру взаимодействия агентов — именно она определяет, будут ли поздние открытия одного агента влиять на работу остальных до завершения задачи, а не после.