Система из нескольких ИИ-агентов: когда это оправдано, а когда лишнее

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

Чем мультиагентная архитектура отличается от бота с несколькими функциями

Одна модель с function calling - это не мультиагентная система, даже если у неё пять инструментов: поиск по базе, создание заявки, эскалация на оператора. Это один агент с одним контекстом, который сам решает, какой инструмент вызвать. Весь диалог, вся память, все решения - в одном месте.

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

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

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

Разделение на роли даёт эффект в трёх случаях, которые я вижу на практике регулярно.

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

Второй - когда нужна проверка перед отправкой ответа. Для чат-ботов с базой знаний (RAG) я обычно ставлю вторым шагом агента-модератора, который сверяет черновик ответа с найденными в базе фрагментами и режет всё, чего там не было. Это удваивает стоимость запроса по токенам, зато закрывает основную жалобу на такие боты - выдуманные факты вне базы.

Похожая логика с ботом на aiogram: для сервиса бронирования я развёл распознавание намерения клиента и подготовку ответа на два отдельных вызова модели, потому что в одном промпте бот периодически путал даты бронирования с датами в истории переписки. Разделение стоило одного лишнего запроса к Claude API на каждое сообщение, зато ошибок с датами не стало.

Третий - параллельная обработка независимых шагов. В n8n я собираю workflow, где заявка одновременно уходит в одну ветку на проверку остатков через API, в другую на расчёт логистики, в третью - на формирование текста ответа менеджеру, и три ветки не ждут друг друга. Здесь оркестрация экономит не деньги, а время: последовательный единый агент делал бы то же самое в три раза дольше. Для сравнения: последовательная обработка тех же трёх шагов одним агентом с function calling занимает 12-18 секунд, потому что модель ждёт ответа каждого инструмента по очереди. Три параллельные ветки в n8n укладываются в 4-6 секунд, а клиент получает готовый ответ, пока внутри ещё крутятся две проверки.

Когда хватит одного агента, а оркестрация - лишние деньги

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

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

В цифрах разница такая: один вызов Claude с диалогом на 1500-2000 токенов контекста стоит копейки, а цепочка из трёх-четырёх агентов, где каждый следующий получает результат предыдущего вместе с частью истории, легко утраивает и учетверяет расход токенов на тот же самый запрос. При 300-500 обращениях в день за месяц это ощутимая строка в счёте от Anthropic, а не абстрактная переплата на бумаге.

Я делал для одного интернет-магазина именно такой пересмотр: изначальное ТЗ было на оркестрацию из трёх агентов для поддержки, по факту после разбора задач осталась одна роль с function calling - поиск заказа по номеру, эскалация на оператора при жалобе, ответ по FAQ из базы. Сделал как AI-интеграцию с одним агентом вместо оркестратора, и по деньгам, и по срокам вышло почти вдвое дешевле первоначального плана.

Как устроена оркестрация агентов на практике

n8n для бизнес-логики

Когда правила часто меняются и их должен видеть не только разработчик, я собираю оркестрацию в n8n: workflow с несколькими HTTP-запросами к Claude API, условными ветками и возможностью параллельного выполнения. Плюс в том, что менеджер клиента может сам поправить условие в ноде IF, не трогая код.

Свой оркестратор на Python для Telegram-ботов

Для ботов на aiogram я обычно не тащу готовые фреймворки вроде LangGraph, если ролей две-три. Пишу простой оркестратор: роутер определяет тип сообщения, вызывает нужную функцию-агента, результат уходит в следующий шаг через очередь состояний в БД, а не в памяти процесса. На масштабе одного бота такой подход проще поддерживать и не тянет лишних зависимостей.

Когда нужен полноценный фреймворк

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

Частые ошибки при проектировании агентной системы

• Роли ради ролей - отдельный агент для приветствия, отдельный для прощания, каждый лишний вызов модели без пользы для качества ответа.
• Нет лимита шагов между агентами - если агент А передаёт задачу агенту Б, а тот при определённых условиях возвращает её обратно А, без счётчика итераций легко получить зацикливание и счёт за токены улетает.
• Состояние диалога хранится в памяти процесса, а не в базе - при перезапуске бота или деплое контекст диалога с клиентом теряется целиком.
• Нет логирования каждого шага цепочки - когда агент выдал странный ответ, без пошагового лога невозможно понять, на каком из трёх-четырёх вызовов пошло не так.
• Нет мониторинга стоимости по ролям - без разбивки расходов по каждому агенту невозможно понять, какой шаг цепочки на самом деле съедает бюджет, а какой можно было бы упростить до одного вызова с function calling.
• Персональные данные клиентов уходят в зарубежные таблицы или базы вроде Google Sheets - для интеграции с CRM данные обращений и контакты нужно хранить на серверах в РФ, это требование 152-ФЗ, а не рекомендация для перестраховки.

Как быстро понять, что вам нужно

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

Сколько стоит разработка и сколько это занимает времени

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

На рынке за похожую оркестрацию из трёх-четырёх агентов студии и фрилансеры обычно просят 150 000-400 000 ₽, в основном из-за использования тяжёлых фреймворков там, где хватило бы простого оркестратора. По срокам простой бот с одним агентом делается за 1-2 недели, оркестрация из нескольких ролей с интеграцией во внешние системы - от 3 до 6 недель в зависимости от количества API, с которыми нужно связать бота.

Частые вопросы

Чем система ИИ-агентов отличается от одного бота с несколькими функциями?

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

Сколько стоит разработка системы ИИ-агентов?

У меня AI-интеграция с несколькими агентами на Claude API стоит от 50 000 ₽, оркестрация в n8n - от 25 000 ₽, простой бот на aiogram с одним агентом - от 30 000 ₽. Итоговая цена зависит от числа внешних интеграций и сложности передачи контекста между ролями.

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

Да, и это обычно правильный путь. Запускаю бота с одной ролью и function calling, смотрю на реальную нагрузку и сценарии обращений за первые недели, и только если видно, что один промпт начинает путать логику разных задач, выношу часть в отдельного агента.

Какие инструменты подходят для оркестрации нескольких агентов?

Для бизнес-логики, которую должен видеть и менять сам клиент, беру n8n. Для Telegram-ботов на aiogram пишу собственный оркестратор на Python без лишних зависимостей. LangGraph и похожие фреймворки имеют смысл, только когда агентов больше четырёх-пяти и переходы между ними образуют граф с циклами, а не линейную цепочку.