Мультиагентные системы: как выстроить команду ИИ-агентов и не потерять деньги

Один предприниматель из нашего клуба полгода назад запустил первого ИИ-агента. Тот разбирал входящие заявки, отвечал клиентам и складывал данные в CRM. Работало хорошо. Тогда он добавил второго — обрабатывать документы. Потом третьего — для видеоаналитики стройки. На четвёртом агенте что-то сломалось.

Агенты начали путаться. Один отправлял клиенту смету, которую ещё не подготовил другой. Третий пытался анализировать документы, которые относились к другому проекту. Не потому что модель плохая. Система без архитектуры — это не система.

Здесь — следующий уровень: когда задач стало больше, чем один агент может нести.

По данным Сбера и Ассоциации ФинТех, мультиагентные системы — главный технологический тренд 2026 года. Но большинство статей на эту тему написаны для разработчиков. Эта — для предпринимателей.

Почему один агент не масштабируется

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

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

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

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

Как устроена команда агентов: оркестратор и субагенты

Решение — разделить задачи между специализированными агентами и добавить одного, который ими управляет.

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

Субагенты — специализированные исполнители. У каждого своя роль, свой набор инструментов и свой контекст. Агент по продажам знает только то, что нужно для продаж. Агент по документам — только про документы.

Один из экспертов нашего клуба, Дмитрий, построил для своего продукта LeadGet команду из четырёх субагентов: Engagement (первый контакт), Qualifier (квалификация лида), Support (поддержка) и Lead Detection (обнаружение новых запросов). Управляющий агент получает входящее сообщение и решает, кому его передать. У каждого субагента — собственный инструментарий: одни ходят во внешнюю базу данных, другие вызывают живого менеджера, третьи отправляют вебхуки в CRM.

Результат: 60% сделок у клиентов LeadGet проходят через агентов. В недвижимости — 2 из 3.

Три паттерна мультиагентных систем для бизнеса

Универсальной архитектуры нет — есть несколько рабочих паттернов, которые закрывают разные задачи.

1. Последовательная цепочка

Агент А делает шаг → передаёт результат агенту Б → тот передаёт агенту В. Каждый видит только то, что сделал предыдущий.

Когда использовать: линейные процессы без развилок. В той же строительной компании это выглядит так: агент получает заявку → квалифицирует её по критериям → ставит задачу в CRM → отправляет клиенту подтверждение с расчётным сроком.

2. Оркестратор + параллельные субагенты

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

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

3. Агент-менеджер с эскалацией

Агент пытается решить задачу сам. Если не справляется — эскалация: передаёт живому человеку с кратким контекстом, что уже сделано и где затык.

Когда использовать: клиентские коммуникации. Стандартные вопросы агент закрывает сам, сложные — передаёт менеджеру с готовым саммари. Менеджер получает не весь диалог, а уже структурированный контекст: кто клиент, что хочет, что агент уже ответил.

Что сломается — и как это предотвратить

Большинство внедрений ломаются на одних и тех же местах.

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

Решение: отлаживай каждого агента отдельно. Запусти первого — проверь на реальных задачах. Только когда он стабилен — добавляй второго.

Зацикливание. Агент встречает препятствие (сайт блокирует запросы, API не отвечает) и начинает делать retry. Без ограничений — уходит в бесконечный цикл и выжигает API-лимит за несколько часов.

Решение: правило в системном промпте. Максимум 3 попытки на одну операцию. Максимум 10 вызовов инструментов подряд. Если не вышло — останавливается и сообщает об ошибке.

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

Решение: AGENTS.md или системный промпт с явным запретом на действия без подтверждения. Базовое правило: «Спроси → подтверди → сделай». Агент не должен ничего отправлять, удалять или платить без явного ОК.

Дорого работает не так. Запустили систему агентов на сложной модели для всех задач — через неделю счёт на несколько сотен долларов за рутинные операции.

Решение: Sonnet или Haiku для простых задач (ответить клиенту по шаблону, записать данные в таблицу). Opus — только для сложного (анализ договора, написание стратегии). Рома из AI Practiq аудировал свою систему и часть задач вообще перевёл обратно на bash-скрипты без AI — лимит стабилизировался.

Кейс из практики: строительная компания, ×8 к производительности ПТО

Роман — участник AI Practiq Club, у него строительная компания. Полгода назад начал внедрять AI поэтапно.

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

Каждый агент работает со своим инструментарием. Агент для видеоаналитики использует Gemini — модель хорошо работает с видео. Агенты для документов — Claude и Perplexity. Роман подбирал модели под конкретную функцию, а не брал одну на всё.

Что сломалось сначала: когда попытался объединить несколько агентов в одну большую систему — пошли стабильные галлюцинации. Агенты путали данные между проектами. Задача, которая казалась простой (подготовка сметы), распалась на двух агентов — слишком много данных на выходе для одного.

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

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

Цифры ПТО-отдела: было 4 сотрудника, стал 1 — при вдвое большем объёме работы. Производительность на человека выросла в 8 раз. У клиентских компаний, где Роман внедрял аналогичные процессы, та же команда закрывает в 2-2.5 раза больше задач.

Как начать: первый шаг к системе из нескольких агентов

Хорошая точка входа — разделить входящую коммуникацию и обработку данных. Первый агент принимает запросы и квалифицирует их. Второй — делает то, что запрошено (пишет КП, ищет информацию, готовит документ). Первый никогда не делает второе.

Из инструментов: n8n хорошо подходит для визуальной оркестрации — видно, как данные идут между агентами, без кода. Claude Code удобен для локальной разработки, когда агентов нужно настраивать под специфику конкретной компании.

Прежде чем добавлять второго агента, пропиши правила явно — например, в файле AGENTS.md:

- Не отправлять письма, сообщения или уведомления без явного подтверждения - При ошибке или неопределённости — остановиться и сообщить, не продолжать - Максимум 3 попытки на одно действие, затем — остановка

По оценке аналитиков Gartner, к 2029 году агентный AI будет автономно решать 80% рутинных клиентских обращений. Компании, которые начнут строить системы сейчас, к тому моменту будут иметь отлаженную инфраструктуру — а не начинать с нуля.

Читайте также: Claude Code для предпринимателей: что делегировать, даже если ты не программист

FAQ

Чем мультиагентная система отличается от одного агента? 

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

С чего начать — с одного агента или сразу с системы? 

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

Почему агент зацикливается и как это остановить? 

Агент встречает препятствие (API не отвечает, сайт блокирует) и уходит в retry без ограничений. Решение: явное правило — максимум 3 попытки, максимум 10 вызовов инструментов подряд, после — остановка с отчётом об ошибке.

Сколько стоит содержать систему агентов? 

Зависит от архитектуры. При правильном распределении: простые задачи на дешёвые модели (Haiku, Sonnet), сложные — на Opus, часть рутины — обратно на скрипты без AI. Стоимость снижается в разы по сравнению с универсальной дорогой моделью на всё.

Можно ли без разработчика запустить мультиагентную систему? 

Можно, если начинать с визуальных инструментов — n8n или Make. Агенты строятся в интерфейсе перетаскиванием блоков без кода. Для сложной архитектуры с кастомными промптами потребуется Claude Code, но порог входа для предпринимателя без технического бэкграунда реальный.

Заключение

Один агент — хорошее начало. Команда агентов — следующий уровень.

Главный урок из кейсов: не строй систему сразу. Запусти первого агента на реальной задаче, добейся стабильной работы, потом добавляй второго. Прописывай правила поведения явно — не надейся, что агент сам разберётся, где остановиться. И подбирай модели под конкретные функции, а не бери одну на всё.

Хочешь разобраться в этом вместе с предпринимателями, которые уже строят такие системы? Присоединяйся к AI Practiq Club.