Мультиагентные системы: оркестратор + субагенты на практике

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

• Оркестратор - план, маршрутизация, контроль лимитов и сбор результата
• Субагенты - узкие роли: исследование, код, проверка, написание, CRM
• Контекст - каждому агенту только то, что нужно для его шага
• Контроль - human-in-the-loop на критичных действиях
• Старт - 2-4 роли и один измеримый сценарий, не «парк агентов»
• Риск - бесконечные циклы, гонка инструментов и размытая ответственность

Что такое мультиагентная система

Мультиагентная система (multi-agent system) - это архитектура, в которой несколько ИИ-агентов совместно решают задачу под управлением координатора. В отличие от одного агента с «толстым» промптом на все случаи, роли разделены:

Та же идея уже знакома из workflow-автоматизации: есть диспетчер и исполнители. Разница в том, что шаги и ветвления частично выбирает LLM, а не только жёсткий if-then.

Зачем разделять оркестратор и субагентов

Один агент с доступом ко всем API выглядит удобно - и быстро становится проблемой:

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

Разделение ролей даёт:

1. Узкий системный промпт у каждого субагента - меньше галлюцинаций «не по роли».
2. Отдельный набор tools - исследователь не может случайно удалить сделку в CRM.
3. Параллель - несколько субагентов могут работать одновременно (поиск + черновик + проверка фактов).
4. Наблюдаемость - в логах видно: кто вызван, с каким входом, с каким выходом.

Базовая схема: оркестратор + пул субагентов

Практичный минимальный каркас:

Пользователь / триггер
        │
        ▼
   Оркестратор
   (план, маршруты, лимиты)
        │
   ┌────┼────┬────────┐
   ▼    ▼    ▼        ▼
 Research  Coder  Reviewer  Writer
   │    │    │        │
   └────┴────┴────────┘
        │
        ▼
   Сводка + артефакты
   (+ human approval при риске)

Что делает оркестратор

• принимает цель и ограничения (время, бюджет токенов, запреты);
• выбирает, каких субагентов вызвать и в каком порядке;
• передаёт каждому сжатый бриф, а не весь сырой чат;
• следит за лимитом шагов и останавливает циклы;
• собирает итог в формате, нужном бизнесу (отчёт, diff, карточка сделки).

Оркестратор может быть «тонким» (только маршрутизация) или «толстым» (сам планирует и перепланирует). Для бизнеса чаще выгоднее тонкий оркестратор + сильные узкие субагенты: проще тестировать и дешевле держать под контролем.

Типичные субагенты в бизнес- и dev-сценариях

Не нужно заводить все роли сразу. На пилоте хватает оркестратор + 2-3 субагента.

Где схема реально окупается

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

• задача составная (несколько навыков: поиск + синтез + действие);
• нужны разные права доступа к системам;
• объём контекста большой - один агент «не влезает» без потери качества;
• важна проверка чужим агентом (reviewer), а не самопроверка автора;
• сценарий повторяется и его можно описать как pipeline с ролями.

Примеры из практики

1. Поддержка: оркестратор → Research (база знаний/RAG) → Writer (ответ) → человек утверждает отправку.
2. Лиды и CRM: квалификация → enrichment → запись в CRM → задача менеджеру; критичные поля проверяет человек или правило.
3. Разработка: оркестратор в Cursor / agent-runtime → explore-субагент → coder → reviewer; деплой только после approve.
4. Контент и GEO: research по теме → writer → fact-check субагент → публикация по чек-листу.
5. Операционка: парсинг входящих писем → классификация → действия в n8n/API → эскалация исключений человеку.

Если задача - однотипный if-then («форма пришла → создать сделку»), мультиагенты избыточны: лучше штатная автоматизация или n8n.

Как спроектировать роли за один день

Короткий pragmatic-чеклист:

1. Опишите happy path на бумаге: вход → 3-6 шагов → артефакт на выходе.
2. Назовите роли глаголами дел: «найти», «проверить», «написать», «записать в CRM» - не «умный агент №3».
3. Для каждой роли зафиксируйте: вход, выход (схема/JSON), tools, запреты.
4. Решите, кто оркестрирует: LLM-планировщик или детерминированный граф (часто гибрид: граф + LLM внутри узлов).
5. Вставьте human-in-the-loop там, где цена ошибки высока.
6. Задайте stop-условия: max шагов, max стоимости, таймаут, «не уверен - эскалация».

Контракт субагента важнее «красивого промпта»

Хороший контракт:

• вход: { task, constraints, sources[] }
• выход: { status, summary, artifacts[], confidence, needs_human }
• запрет: «не выдумывай URL», «не меняй прод», «не пиши клиенту напрямую»

Тогда оркестратор может надёжно склеивать ответы и решать, кого вызывать дальше.

Оркестрация: паттерны, которые работают

Для SMB чаще хватает pipeline + диспетчер. «Дебаты агентов» красиво смотрятся в демо и дорого стоят в проде без жёсткого бюджета токенов.

Контроль, безопасность и стоимость

Мультиагентная система без guardrails быстро превращается в дорогого хаотичного бота.

Обязательный минимум:

• Отдельные API-ключи и права на роль (principle of least privilege).
• Лимиты: шаги, токены, параллельность, таймауты.
• Идемпотентность действий (повторный вызов не создаёт 5 сделок).
• Аудит-лог: кто → с каким входом → какой tool → какой выход.
• Секреты вне промпта: vault, env, не «вставь токен в system message».
• Human approval на irreversible: платежи, удаление, рассылки, прод-деплой.

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

Частые ошибки внедрения

• Завести 10 субагентов «на вырост» без одного рабочего сценария.
• Дать всем один и тот же доступ ко всем tools.
• Передавать субагенту весь лог оркестратора вместо краткого брифа.
• Не ограничить циклы - оркестратор и reviewer бесконечно спорят.
• Считать мультиагентность заменой процессу: без clear Definition of Done система имитирует бурную деятельность.
• Путать с вайб-кодингом: «пусть агенты сами разберутся» без ролей и контрактов - путь к техдолгу.

С чего начать пилот на 2-3 недели

1. Выберите один сценарий с измеримым KPI (время ответа, доля ошибок, минуты менеджера).
2. Соберите оркестратор + два субагента (например research + writer или coder + reviewer).
3. Зафиксируйте контракты входа/выхода и чек-лист эскалации человеку.
4. Прогоните 20-50 реальных кейсов, разметьте сбои по типам.
5. Только потом добавляйте третью роль или параллель.

Инструментально это может быть agent-framework (LangGraph, Crew-подобные схемы, runtime в IDE), связка с n8n для детерминированных краёв или кастом на Python. Архитектура ролей важнее выбора логотипа фреймворка.

Итог

Оркестратор + субагенты - рабочий паттерн, когда задача сложнее одного навыка и нужны разные права, контексты и проверка качества. Сила схемы не в количестве агентов, а в ясных ролях, узких tools и жёстких стопах. Начинайте с малого контура и измеримого сценария: так мультиагентная система становится рычагом скорости, а не дорогим театром автономии.

Часто задаваемые вопросы

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

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

Всегда ли нужен LLM-оркестратор?

Нет. Часто лучше детерминированный граф (state machine / workflow), а LLM живёт внутри узлов. LLM-оркестратор оправдан, когда вход неструктурированный и маршрут нельзя заранее жёстко прописать. Гибрид - самый частый рабочий вариант в проде.

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

Обычно 2-4. Один оркестратор плюс research и writer - уже рабочий контур для контента и поддержки; coder и reviewer - для разработки. Больше ролей имеет смысл только после того, как пилот стабильно бьёт KPI и логи читаемы.

Как не разориться на токенах?

Сжимайте брифы, запрещайте «пересказывать весь диалог», кэшируйте неизменный system prompt, ограничивайте max steps, параллельте только там, где это сокращает wall-time, а не ради эффектности. Считайте стоимость энд-ту-энд сценария, а не одного красивого ответа в демо.

Нужен ли человек в контуре, если агенты «умные»?

Да, на рисках. Модель не снимает ответственность за деньги, персональные данные, юридические формулировки и прод. Human-in-the-loop - не слабость архитектуры, а условие, при котором бизнес вообще согласен пустить агентов к реальным системам.