От прототипа к продакшену: с какими проблемами сталкиваются мультиагентные системы

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

Авторы работы A Large-Scale Study on the Development and Issues of Multi-Agent AI Systems решили посмотреть на мултиагентные системы как на живые инженерные проекты. Их интересует простая, но болезненная для практики вещь: как эти фреймворки реально развиваются, какие у них частые проблем и насколько быстро сообщество их закрывает.

Что именно изучали и почему это важно

Вместо обсуждения «какая архитектура агентов лучше» исследователи пошли в GitHub и собрали большой срез по восьми популярным open-source системам: LangChain, LlamaIndex, Haystack, Semantic Kernel, AutoGen, CrewAI, Letta, SuperAGI. Это как раз те проекты, вокруг которых строится значительная часть современной LLM-разработки — от RAG и инструментов до оркестрации команд агентов.

Проблема в том, что такие фреймворки зависят сразу от всего: провайдеров моделей, форматов function calling, инструментов выполнения кода, баз данных, векторных хранилищ, облачной инфраструктуры. Любое изменение снаружи быстро превращается в задачи внутри репозитория.

Как добывали факты из репозиториев

Авторы использовали подход mining software repositories: выгрузили историю разработки и сопровождения через GitHub и проанализировали:

• 42 267 уникальных коммитов (после удаления дубликатов),
• 4 731 закрытую задачу (issue), но только те, где закрытие связано с pull request — чтобы речь шла именно о решённых проблемах, а не о «повисших» обсуждениях.

Для понимания характера изменений они автоматически классифицировали коммиты по сообщениям, обучив DistilBERT: что это — исправление (corrective), адаптация (adaptive) или улучшение/развитие (perfective). А чтобы разобраться с темами агентных проблем, применили тематическое моделирование BERTopic и затем вручную проверили кластеры.

Картина развития: три типа «жизни» проектов

Данные показали, что экосистема не развивается ровно. Есть три характерных профиля.

Sustained — долгий, устойчивый рост. Так ведут себя, например, Haystack и AutoGen: без резких провалов и всплесков, с понятным темпом.

Steady — стабильная активность, но без ощущения «взрыва», часто на фоне уже сложившейся архитектуры и процессов.

Burst-driven — проекты, которые резко выстреливают, набирают огромный объём изменений за короткое время, а потом заметно затухают. Показательный случай — SuperAGI: много активности в районе середины 2023 года и затем спад.

2023 год стал точкой резкого ускорения почти для всех: и по коммитам, и по обращениям пользователей. Это похоже на момент, когда LLM-инструменты стали массово «прикручиваться» к реальным продуктам.

Что разработчики делают чаще: чинят или улучшают

Один из самых практичных результатов — распределение типов коммитов. В среднем по экосистеме доминируют улучшения и развитие функциональности: perfective составляют около 40,8%. Исправления ошибок (corrective) — около 27,4%, а адаптационные изменения (adaptive), связанные с подстройкой под окружение и зависимости, — примерно 24,3%.

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

Ещё одна деталь: после 2023 года объёмы удаляемого кода начинают догонять объёмы добавляемого. Это выглядит как переход от простого расширения к переработке архитектуры и рефакторингу, когда старые решения приходится разбирать, чтобы система не развалилась от роста.

Какие проблемы чаще всего прилетают в issues

Если смотреть на метки задач, то на поверхности ожидаемое: баги составляют заметную долю (около 22%). Но рядом с ними почти на равных по боли идут инфраструктурные вопросы (около 14%) и отдельный пласт того, что можно назвать «агентной инженерией» — проблемы координации агентов (около 10%).

Внутри «агентных» issues всплывают темы, которые хорошо знакомы всем, кто строил агентные workflow: групповые чаты и коммуникация, планирование и последовательное выполнение шагов, интеграции с провайдерами AI-сервисов, оценка качества и метрики, function calling и обработка исключений. Иными словами, проблема не только в коде, но и в самой логике того, как агенты договариваются и как система сохраняет управляемость.

Насколько быстро всё чинится

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

Что это говорит об экосистеме в целом

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

Авторы подчёркивают практические направления, куда сообществу стоит вкладываться: более системное тестирование, лучшая документация и зрелые практики сопровождения. Для мира, где LLM, API и инструменты меняются быстрее, чем успевают устояться привычные паттерны разработки, это звучит не как пожелание, а как условие выживания.