🐝 Мультиагентные системы
Если один агент — это один специалист, то мультиагентная система — это команда: несколько агентов, у каждого своя роль, координируемых общим «менеджером». Это самый мощный, но и самый дорогой и сложный паттерн в LLM-архитектуре. Поэтому золотое правило этой статьи — не применяйте мультиагентность, пока без неё нельзя обойтись.
Зачем вообще несколько агентов
Когда задача слишком разнородна для одного агента: разные роли требуют разного промпта и инструментов, или процесс естественно распадается на стадии, или нужно разделение ответственности (один ищет, другой проверяет, третий пишет). В таких случаях команда работает лучше одного «универсала».
Когда одного агента достаточно
Мультиагентность — не «лучше», а «сложнее»
Прежде чем читать дальше, честно ответьте: нельзя ли это сделать одним агентом с RAG и инструментами? В 80% случаев можно. Мультиагентность добавляют, когда:
- задача естественно делится на роли/стадии с разной логикой;
- нужен взаимоконтроль (один генерирует, другой критикует);
- один промпт/контекст не вмещает всё необходимое;
- разные стадии требуют разных моделей (05-vybor-modeli).
Паттерны организации
flowchart TD subgraph OW["1. Orchestrator-Worker"] O1["🎭 Оркестратор"] --> W1["🐝 Worker A"] O1 --> W2["🐝 Worker B"] O1 --> W3["🐝 Worker C"] end subgraph PL["2. Pipeline (конвейер)"] P1["🔎 Поиск"] --> P2["⚖ Анализ"] --> P3["📝 Документ"] end subgraph DB["3. Debate / критика"] D1["🅰 Генератор"] <--> D2["🅱 Критик"] end
| Паттерн | Как устроен | Когда |
|---|---|---|
| Orchestrator-Worker | «Менеджер» разбивает задачу и раздаёт куски профильным агентам, потом собирает | Разнородная работа, параллелизм |
| Pipeline (конвейер) | Агенты выстроены в цепочку: выход одного — вход другого | Линейный процесс (поиск → анализ → документ) |
| Debate / Critic | Один агент создаёт, другой критикует и улучшает | Высокие требования к качеству (08-gallyutsinatsii-i-nadezhnost) |
| Swarm / координация | Агенты обмениваются сообщениями и сами договариваются | Сложные динамические сценарии (редко нужен в enterprise) |
Pipeline для обработки договора
- Агент-поисковик находит нужный шаблон/норму через RAG.
- Агент-аналитик сравнивает с риск-листом компании, выделяет проблемные пункты.
- Агент-писатель формулирует замечания в заданном формате.
- (Опц.) Агент-критик проверяет, не пропущено ли важное. Каждый этап — свой промпт, свои инструменты, возможно своя модель.
Роль оркестратора
В большинстве enterprise-сценариев система не «самоорганизуется», а управляется оркестратором: он решает, какому агенту передать задачу, отслеживает состояние, собирает результаты, обрабатывает ошибки. Предсказуемость важнее «свободы» агентов.
flowchart LR In["📨 Запрос"] --> Orch["🎭 Оркестратор<br/>(LangGraph-граф)"] Orch --> A["🅰 Агент-поиск"] A --> Orch Orch --> B["🅱 Агент-анализ"] B --> Orch Orch --> C["🅲 Агент-писатель"] C --> Out["✅ Результат"]
Фреймворки
Реальные мультиагентные системы редко пишут «с нуля» — используют фреймворки, которые задают граф переходов, состояние, инструменты и observability:
| Фреймворк | Особенность |
|---|---|
| LangGraph | Явный граф состояний; предсказуемый контроль потока — популярен в production |
| LlamaIndex | Сильная RAG-составляющая + агенты |
| CrewAI | Удобная ролевая модель «команды» |
| AutoGen | Диалоговая мультиагентность от Microsoft |
Для архитектора
Выбор фреймворка — это про предсказуемость и отлаживаемость, а не про «крутизну». В production выигрывает тот, где поток выполнения явный и наблюдаемый: видно, какой агент когда вызывался, что вернул, где упало. См. 14-ocenka-kachestva.
Цена мультиагентности
Чем больше агентов — тем дороже и непредсказуемее
- Каждый агент — это вызовы модели; их число растёт мультипликативно с числом шагов (06-stoimost-i-ekonomika).
- Сложнее отладка: ошибка может прятаться в любом переходе.
- Выше латентность: пользователь ждёт, пока «команда» договорится.
- Риск «эха»: агенты могут подкреплять ошибки друг друга.
Правило сдержанности: начинайте с одного агента, добавляйте второй только когда упрётесь в конкретное ограничение, и каждое усложнение — через eval (14-ocenka-kachestva).
Когда мультиагент себя оправдывает
- Сложный end-to-end процесс с чёткими ролями (обработка претензии: приём → классификация → юр-анализ → ответ).
- Нужен взаимоконтроль / критика для высокого качества (08-gallyutsinatsii-i-nadezhnost).
- Разные стадии требуют разных моделей (дешёвая классификация → дорогой анализ).
- Параллельная обработка независимых подзадач с последующей сборкой.
Практический ориентир
«Цифровой офис»: один оркестратор принимает заявку и маршрутизирует её профильным агентам (договоры, претензии, ответы клиентам), каждый со своим MCP-инструментами (11-tools-mcp). Это типичный обоснованный случай мультиагентности — потому что роли действительно разные.
📌 Что запомнить
- Мультиагентность — мощно, но дорого и сложно; добавлять последним, не первым.
- Сначала проверьте, не хватит ли одного агента + RAG + инструменты.
- Паттерны: Orchestrator-Worker, Pipeline, Debate/Critic, Swarm.
- Оркестратор (часто через LangGraph) даёт предсказуемость — в enterprise это важнее «свободы».
- Каждое усложнение архитектуры — через eval; иначе вы не знаете, стало лучше или хуже.
- Оправдана для чётко ролевых процессов, взаимоконтроля, разных моделей на стадиях, параллелизма.
Дальше: 🏗 Внедрение AI в бизнес-процессы → — от архитектуры к реальным процессам: no-code, RPA vs AI-агенты, управление изменениями.