Мультиагентные системы могут быть мощным инструментом, но без дисциплины они превращаются в бесконечный хаос. В этой статье мы расскажем, как мы собрали команду AI-сотрудников и получили бесконечное совещание ни о чем, и какие уроки мы вывели из этого опыта.

Мы разбили процесс на несколько узлов: Planner, Workers, Judge и условия перехода. Каждый Worker получает только свой кусок состояния, без истории переписки. Мы использовали LangGraph, который изначально построен вокруг концепции направленного графа состояний.

Мы вывели три правила выживания: не доверяй чат-интерфейсу, ограничивай контекст и всегда ставь стоп-кран. AI-агенты не должны решать, кто говорит следующим, а контекст должен быть ограничен. Стоп-кран необходим для предотвращения бесконечных созвонов.

Мультиагентные системы могут быть полезны в определенных случаях, таких как параллельные подпроцессы с разными «личностями» или симуляция множества точек зрения. Однако в линейных пайплайнах обработки данных или простых RAG-системах мультиагентность может быть overengineering.

Введение. Ложное обещание мультиагентности

В 2026 году каждый второй стартап обещает заменить команду разработчиков роем AI-агентов. Звучит как мечта уставшего тимлида: один агент пишет код, второй ревьюит, третий деплоит, четвертый отвечает на вопросы в Slack, а пятый, наверное, уже сам заказывает пиццу в офис. Никаких больничных, никаких «я не успеваю», только железная продуктивность 24/7.

Я тоже купился. Взял CrewAI, собрал команду из трёх агентов для анализа конкурентов и генерации отчётов. Демо отработало идеально: агенты обменялись парой сообщений, выдали связный Markdown-файл и даже отправили его в Telegram. «Ну всё, — подумал я, — теперь можно увольнять аналитиков и копирайтеров. Будущее наступило».

Ровно через четыре часа после запуска на реальной задаче я наблюдал картину, достойную сюрреалистического полотна: пять AI-агентов устроили бесконечный митинг в духе худших корпоративных созвонов. Они перебивали друг друга, уточняли уже уточнённое, ходили по кругу и, кажется, начали обсуждать погоду. Один агент назначил себя лидом и раздавал указания, которые остальные игнорировали. Другой пытался писать в файл, который в этот момент читал третий. Спустя 127 вызовов LLM и сожжённые $4.30 на API-ключах я остановил этот цирк вручную.

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

Глава 1. Тестовый полигон: как я собрал свою первую команду за вечер

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

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

Запустил — и магия случилась. В консоли замелькали разноцветные логи: агенты обмениваются сообщениями, исследователь что-то гуглит, аналитик читает файл, писатель формирует Markdown. Через пару минут в Telegram упало сообщение с красиво оформленным отчётом. Я был счастлив. Ровно 15 минут.

Потому что следующий запуск был уже на реальной задаче с нечёткими критериями и требованием параллельной работы. И вот тут началось.

Глава 2. Симптомы болезни: когда команда AI начинает жить своей жизнью

Реальная задача отличалась от демо тремя критическими аспектами:

1. Неопределённость входных данных.Пользователь мог запросить анализ по произвольному списку конкурентов, иногда с дополнительными требованиями («сравни только enterprise-тарифы», «учти последние новости за март»).
2. Параллельная работа.Нужно было одновременно анализировать трёх конкурентов, а не последовательно, чтобы уложиться в разумное время.
3. Валидация результата.Перед отправкой в Telegram отчёт должен был пройти проверку на соответствие формату и отсутствие галлюцинаций.

Я перевёл процесс наProcess.hierarchicalв CrewAI (в надежде, что менеджер-агент всё разрулит) и добавил четвёртого агента-валидатора. И вот какие симптомы проявились практически сразу.

Симптом 1. Бесконечный цикл уточнений

Агент-исследователь находил информацию, но аналитик начинал переспрашивать: «А точно ли эти цены актуальны? А где данные по фиче X?» Исследователь снова шёл в поиск, находил чуть больше, аналитик снова уточнял... Цикл повторялся, пока я не прервал выполнение на 37-й итерации. В логах это выглядело как диалог двух стажёров, которые боятся взять на себя ответственность:

[Researcher] -> [Analyst]: Я нашёл цены Notion: $8, $15, enterprise custom.[Analyst] -> [Researcher]: Спасибо. А можешь уточнить, что входит в enterprise?[Researcher] -> [Analyst]: Информации в открытых источниках нет.[Analyst] -> [Researcher]: Может, поищешь на форумах?[Researcher] -> [Analyst]: Нашёл упоминание, что enterprise включает SSO. Это добавить?[Analyst] -> [Researcher]: Да, и ещё проверь, есть ли аудит логов. …

Проблема здесь в том, что агенты не имели чёткого критерия завершённости задачи. Они просто «общались», пока не упирались в лимит токенов или моё терпение.

Симптом 2. Самозваный лид и игнорирование команд

В иерархическом режиме CrewAI назначает одного агента менеджером. В моём случае менеджером стал аналитик, который начал раздавать указания в стиле «Исследователь, срочно найди данные по Coda! Писатель, не пиши пока, жди!». Исследователь отвечал «Понял, выполняю», но продолжал гуглить Notion. Писатель и вовсе проигнорировал менеджера и начал генерировать отчёт на основе неполных данных.

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

Симптом 3. Конфликт доступа к инструментам (гонка за файл)

Я добавил файловый инструмент, чтобы агенты могли сохранять промежуточные результаты. И тут же получил классическую гонку за файл:

1. Исследователь записывает данные вresearch_data.txt.
2. Аналитик начинает читать файл.
3. В этот момент писатель (который не должен был запускаться, но запустился из-за бага в оркестрации) пытается записать в тот же файл черновик отчёта.
4. Результат: файл повреждён, аналитик падает с ошибкой парсинга.

В многопоточном программировании эту проблему решили ещё в 70-х семафорами и мьютексами. В мире AI-агентов про это, кажется, забыли.

Симптом 4. Потеря контекста при масштабировании

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

Визуализация хаоса

В документации CrewAI коммуникация агентов рисуется как аккуратная звезда или последовательная цепочка. В реальности мой граф сообщений выглядел перекати поле.

А с учётом того, что каждый агент мог отправить сообщение любому другому в любой момент, это превращалось в полносвязный граф, где количество рёбер растёт квадратично.Комбинаторный взрыв сообщений— вот что убивает производительность и бюджет.

Главный вывод этой главы: проблема не в LLM. GPT-4 отлично справляется с ролью отдельного агента. Проблема в архитектуре оркестрации, которая предполагает, что агенты сами договорятся.

Глава 3. Разбор полётов: почему готовые фреймворки тонут в сложности

Давайте честно разберём, почему CrewAI и AutoGen, прекрасно работающие на демо, ломаются на реальных задачах.

CrewAI: Sequential — это прекрасно, но жизнь не линейна

CrewAI предлагает два режима:Process.sequentialиProcess.hierarchical. Первый просто выполняет задачи одну за другой. Это надёжно, но не решает задачи с параллелизмом или условной логикой. Как только вам нужно сказать «если анализ показал, что данных недостаточно, вернись к исследователю», вы выпадаете из парадигмы.

Разработчики предлагают использоватьToolsдля реализации условных переходов. То есть агент должен сам вызвать инструмент, который изменит состояние системы. На практике это приводит к монструозным промптам и костылям вроде такого:

Это не архитектура, это заклинания. И они нестабильны.

AutoGen: GroupChat — свобода, которая убивает

AutoGen от Microsoft предлагает более гибкую модель черезGroupChat. Вы можете определить произвольный граф переходов между агентами с помощьюspeaker_selection_method. Звучит мощно. Но на практике:

1. По умолчанию используетсяauto— LLM решает, кто говорит следующим. Это порождает те самые бесконечные дебаты.
2. Жёсткие правила (round_robin,manual) требуют написания кастомной логики на Python, что возвращает нас к вопросу: «А зачем тогда фреймворк?»
3. Контекст опять же передаётся всем участникам, раздувая стоимость каждого вызова.

Ключевая архитектурная проблема обоих фреймворков — отсутствие явного контроллера состояния.Агенты работают по принципу «поговорим и решим», в то время как надёжная система требует «перейди из состояния А в состояние Б только при условии В, иначе в состояние С».

В традиционном программировании мы бы никогда не доверили бизнес-логику чату. Мы пишем конечные автоматы, workflow-движки, Sagas. Но в мире AI-агентов многие решили, что LLM сама разберётся. Не разберётся. LLM галлюцинирует, забывает, уходит в сторону. Это нормально для генерации текста, но катастрофично для оркестрации.

Глава 4. Наводим порядок: строим собственный оркестратор на LangGraph

После нескольких недель боли и сожжённых API-ключей мы переписали систему на LangGraph. Почему он? Потому что LangGraph изначально построен вокруг концепции направленного графа состояний, а не чата. Он заставляет думать в терминах узлов, рёбер и условий перехода — ровно то, что нужно для детерминированной оркестрации недетерминированных LLM-компонентов.

Агентный воркфлоу — это не чат, это конечный автомат

Перестаньте думать об агентах как о людях в Slack. Думайте о них как о микросервисах, которые вызываются по расписанию, получают строго ограниченный контекст и возвращают результат. А управляет всеморкестратор— граф, написанный на Python.

Архитектура решения

Мы разбили процесс на следующие узлы:

1. Planner— один раз анализирует входной запрос и формирует план работ (список шагов). Не участвует в дальнейшей дискуссии.
2. Workers— агенты, выполняющие конкретные задачи. Каждый worker получаеттолько свойкусок состояния: описание задачи и результаты предыдущего шага. Никакой истории переписки.
3. Judge— проверяет результат worker'а. Принимает решение: перейти к следующему шагу, отправить на доработку или завершить с ошибкой.
4. Условия перехода— чистые Python-функции, проверяющие состояние.

Вот как это выглядит в коде на LangGraph:

Ключевые отличия от CrewAI/AutoGen

1. Контекст строго ограничен.Worker видит только результаты предыдущих шагов, а не всю историю переписки. Это решает проблему раздувания промпта и потери фокуса.
2. Детерминированные переходы.Решения принимает Python-код, а не LLM.route_after_judge— чистая функция, которая не галлюцинирует.
3. Встроенный стоп-кран.Счётчикretry_countгарантирует, что агент не уйдёт в бесконечный цикл уточнений.
4. Параллелизм легко добавить.LangGraph поддерживает параллельные ветки. Можно запустить трёх исследователей конкурентов одновременно и дождаться всех результатов перед анализом.

Параллельный анализ конкурентов на LangGraph

Вот как добавить параллельное выполнение для трёх конкурентов:

Это чистая, предсказуемая параллельная обработка без гонок за файлы.

Глава 5. Результаты до и после: цифры и метрики

Мы прогнали одну и ту же задачу (анализ трёх конкурентов с формированием отчёта) через CrewAI (иерархический режим) и через наш LangGraph-оркестратор. Вот что получилось:

CrewAI (hierarchical)

LangGraph (наш оркестратор)

Время выполнения

∞ (прервано вручную через 6 минут)

Количество вызовов LLM

127 (остановлено)

14 (включая Planner и Judge)

Стоимость (GPT-4-turbo)

~$4.30 (и росло)

Успешное завершение

0% (из 5 запусков — 0)

100% (из 10 запусков — 10)

Качество отчёта (субъективно)

Случайное: от полного бреда до хорошего

Стабильно приемлемое

Гонки за ресурсы

Отсутствуют (синхронный граф)

Параллелизм

Заявлен, но не работает как ожидалось

Реальный параллелизм через Send API

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

Глава 6. Философский вопрос: а нужны ли нам вообще мультиагентные системы?

После всего пережитого я обязан задать этот вопрос. Потому что, возможно, мы все стали жертвами хайпа.

Когда мультиагентные системы ОПРАВДАНЫ

1. Параллельные подпроцессы с разными «личностями».Классический пример: один агент генерирует идеи (креативщик с высокой температурой), второй их критикует (скептик с низкой температурой). Такой «внутренний диалог» действительно улучшает качество.
2. Симуляция множества точек зрения.Если нужно промоделировать, как разные персоны отреагируют на продукт.
3. Сложные workflow с ветвлениями.Когда логика процесса нелинейна и зависит от промежуточных результатов, оркестратор на графе — правильное решение.

Когда мультиагентность — overengineering

1. Линейные пайплайны обработки данных.ETL, последовательная генерация текста с шаблонными шагами. Один агент с хорошо составленным промптом и цепочкой вызовов функций справится быстрее, дешевле и надёжнее.
2. Простые RAG-системы.Зачем вам агент-ридер и агент-генератор, если можно одним промптом сказать: «Ответь на вопрос, используя эти документы»?
3. Задачи, где важна скорость и предсказуемость.Каждый дополнительный агент — это дополнительный вызов LLM и точка потенциального отказа.

Совет, который я даю себе полугодовой давности:прежде чем городить рой агентов, напиши цепочку промптов в одном скрипте. Если она решает задачу на 80% — остановись. Добавь пару условных переходов на Python. Если и этого мало — только тогда думай о LangGraph или, прости господи, CrewAI.

Заключение. Как подружить AI-агентов и не сойти с ума

Мультиагентные системы — мощный, но опасный инструмент. Без дисциплины они превращаются в бесконечный митинг в Zoom, где каждый участник — это LLM с включённым verbose=True. Дисциплину должны задавать вы, а не языковая модель.

Три правила выживания, которые я вывел из этого опыта:

1. Не доверяй чат-интерфейсу.Проектируй систему как конвейер с чёткими переходами состояний. Используй LangGraph или любой другой оркестратор, основанный на конечных автоматах. LLM не должна решать, кто говорит следующим — это ваша работа как инженера.
2. Ограничивай контекст.Не давай агенту читать всю переписку. Передавай только релевантные данные: описание его задачи и результат предыдущего шага. Это сэкономит деньги, токены и убережёт от галлюцинаций.
3. Всегда ставь стоп-кран.Таймауты, лимиты итераций, максимальное количество вызовов LLM. Ваш бюджет и нервная система скажут вам спасибо. Помните: агенты не устают, они могут «совещаться» вечно. Ваша задача — вовремя сказать «хватит».

А продакт-менеджерам, которые прочитали эту статью и уже представляют, как заменят всю команду одним графом в LangGraph, я скажу так: AI-агенты — это не замена разработчикам. Это просто ещё один слой абстракции, который требует ещё более тщательного проектирования. И да, бесконечные созвоны в зуме никуда не денутся — просто теперь на них будут ходить ваши AI-агенты, пока вы пытаетесь понять, почему они обсуждают цены на AWS вместо фич конкурентов.

Удачи в оркестрации. Держите графы детерминированными, а промпты — короткими.