Как собрать multi-agent систему: router, supervisor и handoff

Multi-agent система нужна не потому, что “много агентов звучит круто”, а потому что один агент часто перегружается: он должен отвечать по базе знаний, работать с CRM, проверять безопасность, писать summary, запускать tools и еще выбирать правильный тон. В какой-то момент лучше разделить роли: router принимает запрос, supervisor управляет процессом, а специализированные агенты делают свои узкие задачи.

Короткая версия: не начинайте с десятка автономных агентов. Сделайте router, 2-3 специализированных агента, общий state, строгие handoff-правила, разные tools для разных ролей и evals на маршрутизацию.

Что мы собираем

Соберем понятную multi-agent схему для прикладного проекта: поддержки, CRM, RAG-чата или внутреннего AI-ассистента.

• Router определяет тип запроса.
• Supervisor решает, кому передать задачу.
• RAG-агент отвечает по базе знаний.
• CRM-агент работает с лидами и сделками.
• QA-агент проверяет финальный ответ.
• Общий state хранит контекст задачи.
• Handoff передает управление между агентами по правилам.

Шаг 1. Убедитесь, что multi-agent действительно нужен

Multi-agent архитектура добавляет сложность: больше промптов, больше ошибок маршрутизации, больше latency и дороже трассировка. Если задачу можно решить одним агентом с несколькими tools, начните с одного агента.

Multi-agent нужен, если:

• есть разные роли с разными правилами;
• agents должны использовать разные tools и права;
• нужен reviewer или safety-checker;
• один prompt стал слишком большим и противоречивым;
• разные типы запросов должны идти по разным сценариям;
• нужно разделить ответственность между RAG, CRM, кодом, поддержкой и проверкой.

Если причина только “хочу автономную команду агентов”, лучше притормозить. Архитектура должна упрощать контроль, а не умножать хаос.

Шаг 2. Начните с router

Router - это самый простой агент или классификатор, который решает, куда направить запрос. Он не должен решать всю задачу. Его работа - выбрать маршрут.

{
  "route": "support",
  "confidence": 0.86,
  "reason": "Пользователь спрашивает, как исправить ошибку настройки",
  "needs_human": false
}

Для router лучше использовать structured output и ограниченный список route: support, sales, technical, billing, unsafe, human. Не позволяйте модели придумывать новые маршруты на лету.

Шаг 3. Опишите специализированных агентов

У каждого агента должна быть узкая роль и свой набор tools. Это главный смысл multi-agent системы.

• Support Agent: отвечает по базе знаний, создает тикеты, делает handoff оператору.
• Sales Agent: квалифицирует заявку, собирает контакт, создает лид.
• RAG Agent: ищет документы и возвращает grounded ответ с источниками.
• CRM Agent: работает только с CRM tools и не пишет длинные тексты клиенту.
• QA Agent: проверяет ответ на источники, тон, запреты и отсутствие выдумок.

Не давайте всем агентам все tools. Иначе разделение ролей будет декоративным.

Шаг 4. Выберите схему orchestration

Есть несколько рабочих паттернов. Для production чаще всего лучше простая управляемая схема, а не свободный чат агентов между собой.

• Router: один шаг маршрутизации в нужный сценарий.
• Supervisor: центральный агент решает, какой specialist нужен дальше.
• Handoff: один агент передает диалог другому агенту.
• Pipeline: фиксированная цепочка шагов, например RAG -> answer -> QA.
• Hierarchy: верхний supervisor делегирует подзадачи нижним агентам.

Для первого запуска выберите router или pipeline. Supervisor добавляйте, когда маршрутов и условий станет больше.

Шаг 5. Сделайте общий state

Агенты должны обмениваться не “простыней переписки”, а структурированным state. Это снижает потерю контекста и упрощает отладку.

{
  "user_message": "Хочу подключить агента к CRM",
  "route": "sales",
  "customer": {
    "name": null,
    "phone": null
  },
  "retrieved_sources": [],
  "tool_results": [],
  "handoff_reason": null,
  "final_answer": null
}

Каждый агент читает только нужную часть state и записывает свои поля. Не заставляйте каждого агента перечитывать всю историю с нуля.

Шаг 6. Настройте handoff-правила

Handoff - это управляемая передача задачи другому агенту. Она должна иметь причину, данные и границы.

Support Agent передает Sales Agent, если:
- пользователь явно хочет оставить заявку;
- вопрос связан с внедрением, ценой или консультацией;
- есть согласие передать контакт менеджеру.

Support Agent не передает Sales Agent, если:
- пользователь просто спрашивает инструкцию;
- нет явного интереса к покупке;
- вопрос конфликтный и нужен оператор поддержки.

Передавайте не весь хаотичный чат, а summary, нужные поля и причину handoff.

Шаг 7. Ограничьте tools по ролям

Multi-agent система безопаснее, если каждый агент имеет минимальный набор tools.

RAG Agent:
- search_knowledge_base

CRM Agent:
- create_crm_lead
- add_crm_note

Support Agent:
- create_ticket
- add_ticket_comment

QA Agent:
- no external tools

Если QA Agent может менять CRM, это уже не проверяющий, а еще один исполнитель с риском.

Шаг 8. Добавьте reviewer

Reviewer или QA Agent полезен перед финальным ответом, особенно если есть RAG, CRM, юридические ограничения или support-сценарии.

QA Agent проверяет:

• ответ основан на источниках;
• нет неподтвержденных обещаний;
• tone подходит для пользователя;
• tools вызваны по правилам;
• нет утечек внутренней информации;
• если уверенности мало, нужен handoff человеку.

Reviewer не должен бесконечно спорить с основным агентом. Лучше сделать один проход проверки и четкий результат: pass, revise, human.

Шаг 9. Не делайте бесконечные циклы

Multi-agent системы любят зацикливаться: один агент передал другому, второй вернул первому, supervisor снова решил подумать. Поставьте жесткие лимиты.

• Максимум 3-5 agent steps на обычный запрос.
• Максимум 1 QA-проверка.
• Максимум 1 повтор после ошибки tool.
• Таймаут на весь run.
• Явное завершение: final_answer, human_handoff или failed.

Если агенту нужно 20 шагов для типового вопроса поддержки, скорее всего архитектура слишком сложная.

Шаг 10. Логируйте маршрутизацию

Для multi-agent системы важно видеть не только финальный ответ, но и путь: кто выбрал маршрут, какой агент работал, какие tools вызывались, почему был handoff.

• run_id;
• router decision;
• confidence;
• selected agent;
• handoff reason;
• tool calls;
• reviewer verdict;
• final status;
• latency и стоимость по каждому шагу.

Без tracing такая система быстро превращается в черный ящик.

Шаг 11. Тестируйте маршрутизацию отдельно

У multi-agent системы есть отдельный класс ошибок: неверный маршрут. Пользователь спрашивал поддержку, а его отправили в продажи. Или вопрос про возврат попал к RAG-агенту без handoff оператору.

{
  "input": "У меня списались деньги дважды, верните оплату",
  "expected_route": "billing",
  "expected_handoff": true,
  "must_not_route": ["sales"]
}

Добавьте evals на routing, handoff, tool permissions и reviewer verdict. Не ограничивайтесь качеством финального текста.

Шаг 12. Выберите стек

Для разных задач подходят разные инструменты.

• LangGraph: хорошо, если нужна управляемая state machine, supervisor, циклы и явный graph.
• OpenAI Agents SDK: удобно для agents, handoffs, tools, guardrails и tracing.
• CrewAI: удобно для crew-подхода, ролей, задач и multi-agent automation.
• n8n: хорошо для визуальных workflow и интеграций.
• Flowise: удобно для визуальных LLM/agent flows и быстрых прототипов.

Выбор стека не отменяет архитектурные правила: роли, state, tools, handoff, logs и evals нужны в любом варианте.

Мини-чеклист

• Multi-agent выбран из-за реальной сложности, а не ради моды.
• Есть router или supervisor с ограниченным списком маршрутов.
• У каждого агента узкая роль.
• Tools ограничены по ролям.
• Общий state структурирован.
• Handoff имеет причину и передает summary, а не весь шум.
• Есть лимит шагов и таймаут.
• QA/reviewer не выполняет внешние действия.
• Tracing показывает путь между агентами.
• Evals проверяют routing, tools, handoff и финальный ответ.

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

Когда нужен multi-agent, а когда достаточно одного агента?

Один агент подходит, если задача простая и tools немного. Multi-agent нужен, когда роли, права, сценарии и проверки начинают конфликтовать внутри одного промпта.

Supervisor и router - это одно и то же?

Нет. Router обычно делает одно решение: выбрать маршрут. Supervisor управляет процессом шире: выбирает следующего агента, оценивает результаты, может повторить шаг или завершить run.

Можно ли дать агентам общую память?

Можно, но осторожно. Лучше использовать общий state для текущей задачи и отдельную долгосрочную память с правами доступа. Не все агенты должны видеть все данные.

Почему multi-agent система может работать хуже одного агента?

Из-за ошибок маршрутизации, лишних передач, потери контекста, противоречивых промптов, высокой задержки и плохих logs. Multi-agent не улучшает качество автоматически.

Что тестировать в первую очередь?

Routing, handoff, tool permissions, RAG groundedness, reviewer verdict и критичные safety-сценарии. Финальный красивый ответ - только часть качества.