Главная идея не в том, чтобы “добавить больше агентов”, а в разделении ответственности. Один универсальный агент быстро становится перегруженным: в одном prompt смешиваются поддержка, продажи, база знаний, безопасность, стиль ответа, tool calling и проверка качества. Multi-agent подход выносит эти роли в отдельные контуры.
Типичная схема включает router, который классифицирует запрос; specialist agents, которые делают узкие задачи; reviewer, который проверяет результат; supervisor, который управляет workflow; shared state, где хранится общий контекст; handoff, через который задача переходит между ролями.
Multi-agent система полезна, когда роли действительно конфликтуют или требуют разных tools и прав. Например, RAG-агенту нужен доступ к базе знаний, CRM-агенту - к сделкам, security reviewer - к policy, а agent для записи действий должен работать только через approval.
Но multi-agent почти всегда дороже и сложнее одного агента. Появляются ошибки маршрутизации, лишние передачи, потеря контекста, противоречивые инструкции, длинные traces, высокая latency и риск циклов. Если задачу можно решить одним агентом с несколькими tools и четкими guardrails, лучше начать с этого.
Надежная multi-agent система требует явного workflow graph, shared state, лимитов шагов, tool policy, conflict resolution, observability, evals и human-in-the-loop для рискованных действий. Без этого “команда агентов” быстро превращается в хаотичную переписку моделей.
Примеры
- Router определяет, что запрос клиента относится к поддержке, передает его RAG-агенту, а reviewer проверяет, есть ли источник в базе знаний.
- В sales workflow один агент анализирует сделку, второй готовит follow-up, третий проверяет риски, а запись в CRM идет только после approval менеджера.
- В research-сценарии один агент собирает источники, второй делает таблицу фактов, третий проверяет противоречия, четвертый пишет итоговый brief.
- В юридическом сценарии extraction agent извлекает пункты договора, risk reviewer ищет красные флаги, а supervisor отправляет спорные пункты юристу.
- В DevOps-сценарии monitoring agent находит инцидент, diagnostic agent собирает логи, runbook agent предлагает шаги, а человек подтверждает действие.
Где используется
- сложные workflow с разными ролями
- разделение прав доступа между агентами
- RAG + CRM + reviewer в одном процессе
- исследования и аналитические отчеты
- контроль качества ответов
- юридическая и финансовая проверка
- customer support с handoff человеку
- multi-step automation с approval
- agent teams для бизнеса
- эксперименты с supervisor/router архитектурой
Связанные термины
Частые вопросы
Когда multi-agent система лучше одного агента?
Когда задача естественно делится на роли с разными правами, tools, критериями качества и зонами ответственности. Если один агент справляется с понятным prompt и несколькими tools, multi-agent может быть лишним.
Почему multi-agent может работать хуже?
Из-за ошибок маршрутизации, лишних передач, потери контекста, противоречивых инструкций, высокой задержки, роста стоимости и циклов, где агенты бесконечно передают задачу друг другу.
Кто управляет multi-agent системой?
Обычно есть supervisor или workflow graph. Он определяет маршрут, следит за лимитами, решает, когда вызвать reviewer, когда завершить ответ и когда передать задачу человеку.
Что обязательно логировать в multi-agent run?
Нужны run_id, маршрут, роли агентов, входы и выходы каждого шага, tool calls, handoff events, errors, cost, latency, reviewer decision и финальный результат. Без trace такую систему трудно отлаживать.
Какие инструменты подходят для multi-agent систем?
Для code-first сценариев часто используют LangGraph, CrewAI, OpenAI Agents SDK, Google ADK и похожие фреймворки. Для визуальных прототипов можно использовать n8n, Flowise, Dify или Relevance AI, если хватает контроля.
