Один бот - это уже прошлое. Почему бизнес собирает команды из ИИ-агентов

Начну с картинки. Представьте, что у вас есть один сотрудник, который должен принимать заявки, квалифицировать лидов, отвечать на вопросы клиентов, искать товар на складе, согласовывать скидки и параллельно писать отчёты. И всё это одновременно. Реально такое потянуть в одиночку? Нет. В жизни мы делим эти задачи между разными людьми с разными ролями.

В мире ИИ-автоматизации та же история. Только до недавнего времени все пытались свалить всё на одного «умного бота». И удивлялись, почему он то путается в контексте, то забывает прайс, то вместо квалификации уходит в философский диалог про смысл жизни.

Сейчас ситуация меняется. И меняется быстро.

Что такое мультиагентная система простыми словами

Мультиагентная система - это когда вместо одного большого бота у вас работает несколько мелких, каждый со своей ролью. Один разбирается с входящими сообщениями. Второй ищет информацию в базе. Третий генерит ответ. Четвёртый проверяет, не сболтнул ли третий лишнего. Пятый отправляет результат клиенту и создаёт задачу в CRM.

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

Звучит сложнее? Сложнее. Работает лучше? В разы.

Аналогия из жизни. Один бот - универсальный солдат, который всё умеет на троечку. Мультиагентка - оркестр, где каждый играет свою партию, а вместе получается музыка. Точнее, продакшн-система, которая не валится при первом нестандартном запросе.

Почему «просто промпт в жпт» больше не катит

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

А потом начинаются приколы. Клиент спрашивает про доставку - бот не знает, сочиняет. Спрашивает про скидку - бот выдаёт скидку, которой нет. Просит конкретную модель из каталога - бот игнорирует. Контекст переполняется через 30 сообщений и бот забывает половину диалога.

Это не баг. Это фундаментальное ограничение архитектуры «один промпт - один ответ». У ллмки есть лимит контекста, есть склонность к галлюцинациям, есть проблема с инструментами. Когда вы пытаетесь упаковать в неё сразу всё - продажи, поддержку, базу знаний, расчёты, интеграции - она ломается. Не потому что «плохая модель», а потому что задача сформулирована неправильно.

Решение нашли не через «более умную модель». Решение нашли через «несколько простых моделей с чёткими ролями».

Как это выглядит на пальцах

Возьмём реальный сценарий. Интернет-магазин получает в Telegram сообщение: «хочу диван, в гостиную 18 квадратов, бюджет 80 тысяч, доставка в Питер».

Вот как это разруливает мультиагентная система:

  1. Агент-приёмщик ловит сообщение, определяет, что это запрос на товар, передаёт дальше
  2. Агент-аналитик парсит текст, вытягивает параметры: тип товара, размер помещения, бюджет, регион
  3. Агент-каталог идёт в базу товаров (или на сайт парсером) и достаёт диваны под параметры
  4. Агент-логист проверяет наличие на складе, считает доставку до Питера, сроки
  5. Агент-продажник формирует ответ: топ-3 варианта с фото, цены, сроки, возможные скидки
  6. Агент-фильтр проверяет, что в ответе нет выдумок, цены реальные, ссылки рабочие
  7. Агент-отправитель красиво форматирует и отправляет клиенту, плюс создаёт лида в CRM

Каждый агент - это 30-100 строк кода и короткий промпт. Каждый делает одну вещь. Если что-то ломается, сразу видно, какой агент налажал, и его можно починить отдельно. Не надо переписывать «большой промпт на всё про всё».

Один бот так не умеет. Точнее, умеет, но через раз и с большим количеством косяков.

Фреймворки, которые это всё запускают

Если копать на уровне технологий, в 2026 году балом правят несколько фреймворков. Кратко по каждому:

  • LangGraph от создателей LangChain. Позволяет описать систему агентов как граф состояний. Сложный, но мощный. На нём собирают серьёзные продакшн-системы.
  • CrewAI - проще LangGraph, заточен под «команды агентов с ролями». Хорош для прототипов и среднего уровня задач.
  • AutoGen от Microsoft - агенты могут общаться между собой и спорить. Подходит для исследовательских задач, где надо «обдумать».
  • OpenAI Assistants и Agents API - простой путь, если уже сидите на жпт. Меньше гибкости, но быстрый старт.
  • Claude Agents от Anthropic. Хорош тем, что у Клода большой контекст и он лучше следует инструкциям. Подходит для агентов, которым надо держать сложное состояние.

Выбор зависит от задачи и стека. Питон везде, ноды интегрируются куда угодно, фреймворки активно развиваются - месяц назад половина из них выглядела по-другому.

Где это реально стреляет

Это не технология ради технологии. Несколько типичных сценариев, где мультиагентка кардинально лучше одного бота.

Сложные продажи с квалификацией. Клиент пишет общий запрос, агенты задают уточняющие вопросы, считают примерный ROI, формируют коммерческое предложение. Один бот тут плывёт, потому что слишком много шагов и инструментов.

Многошаговые исследования. Надо собрать инфу о конкуренте: сайт, отзывы, цены, новости. Один агент гуглит, второй парсит, третий суммаризирует, четвёртый сравнивает с вашими данными. На выходе готовый отчёт за 5 минут вместо 5 часов аналитика.

Документооборот. Один агент читает входящий документ, второй извлекает данные, третий проверяет на корректность по правилам, четвёртый загружает в систему. Юристы, бухгалтерия, кадры - всё это идеальный кейс для мультиагентки.

Контент-конвейер. Один агент пишет черновик, второй проверяет факты, третий редактирует стиль, четвёртый делает SEO-обвязку, пятый публикует. И это не «одна статья», а конвейер на 50 публикаций в неделю.

Управление инфраструктурой. Агент мониторит логи, агент решает что делать при инциденте, агент пишет отчёт, агент уведомляет команду. Это DevOps на стероидах.

Хочется понять, какой из этих сценариев реально подойдёт под ваши процессы и где можно сделать первый шаг - можно получить персональные рекомендации, что у вас можно автоматизировать. 15 минут, бесплатно, без воды.

Подводные камни

Чтобы не было сладко-розового впечатления - давайте про минусы. Их хватает.

Дороже в эксплуатации. Каждый агент - это вызов ллмки. Если в цепочке 7 агентов, и каждый дёргается по 2-3 раза, на одно сообщение клиента уходит 20-30 запросов к жпт или клоду. Это не катастрофа, но в 5-10 раз дороже одного бота. На 100 диалогов в день - копейки. На 100 000 - уже бюджет, который надо считать.

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

Сложнее дебажить. Когда что-то идёт не так, вы должны понять, какой агент сломал цепочку. Без хорошего логирования это пытка. В проде используют tracing-инструменты вроде LangSmith, Helicone, Phoenix - и без них туда лучше не лезть.

Цепная галлюцинация. Если первый агент что-то переврал, второй принимает это как факт и может ещё больше нагородить. Получается испорченный телефон. Защита - агент-проверяльщик, который сверяет факты с базой. Но это ещё один слой сложности.

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

Когда не надо лезть в мультиагентку

Если у вас простая задача - «ответить клиенту на типовой вопрос по базе знаний» - не надо городить агентов. Один нормально настроенный бот с RAG (retrieval augmented generation) справится за 10% бюджета и 20% времени разработки.

Мультиагентка нужна, когда:

  • Цепочка действий длиннее 3-4 шагов
  • Нужны разные инструменты для разных этапов
  • Один промпт не помещает всё в контекст
  • Есть риск ошибок и нужна перепроверка фактов
  • Бизнес-логика реально сложная, со множеством развилок

Если задача проще - не лезьте. Сэкономите кучу денег и нервов.

Что будет дальше

Тренд однозначный. В 2024-2025 годах был хайп вокруг «одного большого ассистента». В 2026 мультиагентка стала мейнстримом. В 2027-2028, по моим ощущениям, мы увидим:

  • Появление готовых «коробочных» мультиагентных решений по отраслям. Уже сейчас стартапы пилят «AI-команда для рекрутинга», «AI-команда для бухгалтерии», «AI-команда для саппорта».
  • Стандартизацию протоколов общения между агентами. Сейчас каждый фреймворк изобретает велосипед, но появляется MCP (Model Context Protocol) от Anthropic, который приучает всех к единому стандарту.
  • Снижение цены инференса в 5-10 раз - и тогда мультиагентка станет дешевле одного бота. И автоматически дефолтной архитектурой.
  • Появление «оркестраторов оркестраторов» - мета-агентов, которые сами решают, какие команды агентов запускать под задачу.

Если сейчас кажется, что мультиагентка - это сложно и далеко, окей, нормально. Но через год это будет так же привычно, как сейчас привычны обычные чат-боты. А через два года тот, кто всё ещё гонит «один промпт под всё», будет выглядеть как человек, который в 2024 гордо рассказывал про свой первый сайт на чистом HTML.

Резюме

Мультиагентные системы - не магия и не серебряная пуля. Это просто более правильная архитектура для сложных задач. Один бот хорош там, где задача простая и линейная. Команда агентов нужна там, где задача требует разных навыков, разных инструментов и проверок.

Если у вас есть процессы, в которых текущие «тупые» автоматизации спотыкаются, стоит присмотреться. Не обязательно сразу строить семь агентов. Можно начать с двух: один принимает заявку, второй проверяет и обогащает данные. И дальше расширять, если зайдёт.

Главное - не путайте. «Сложная архитектура» не значит «лучше». Лучше там, где она реально нужна. Везде остальное - оверкилл и пустая трата денег.