Оркестрация нескольких AI-агентов без хаоса: роли, очереди, память

Несколько AI-агентов работают без хаоса только когда у каждого жёсткая роль, общий контракт сообщений, очередь с retry/DLQ и разделённая память (что помнить / что забывать) — иначе multi-agent дороже и хуже одного хорошо заземлённого агента.

Я подключаю второго и третьего агента не «потому что тренд», а когда один упирается в конфликтующие skills, длинный контекст или разные SLA. Ниже — роли, очереди, память и развилка 1 vs N.

---

Когда хватит одного агента (и когда multi-agent оправдан)

Ситуация	1 агент	Multi-agent	Почему
FAQ + квалификация лида в одном канале	✅	избыточно	один tool-set, одна KB
Поддержка L1 + редкий handoff	✅	избыточно	проще протокол HITL
Лид → CRM → КП → follow-up с разными политиками	риск	✅	разные guardrails и tonality
Параллельный research + написание + проверка фактов	риск	✅	разделение write/verify
Высокий RPS, разные приоритеты	частично	✅	очереди и worker-роли
Compliance: «не смешивать» данные контуров	—	✅	изоляция памяти и tools

Правило большого пальца: если вы не можете нарисовать 3–5 ролей на салфетке и назвать, кто не имеет права писать в CRM — вам нужен один агент, а не оркестр.

---

Роли: оркестратор, воркеры, сторож

Минимальный каркас, который я ставлю в production:

Роль	Делает	Не делает	Память
Router / Orchestrator	классифицирует intent, выбирает worker, следит за SLA	длинные ответы клиенту	session state, routing log
Specialist worker	узкий skill (оплата, доставка, demo-book)	чужие интенты	skill KB + task scratch
Critic / QA	проверяет факты, PII, stop-list	финальный send без policy	policy rules, sample log
HITL bridge	готовит handoff человеку	«договаривается» сам	handoff package
Scribe	пишет в CRM/тикет	меняет решение	audit trail

Контракт сообщения (обязательные поля):

• trace_id, parent_id, role, intent
• input_ref / output_ref (не простыня текста в каждый hop)
• confidence, needs_human, tools_used
• ttl и budget_tokens

Без контракта «агенты болтают» и сжигают бюджет на пересказах.

---

Очереди, retry и DLQ — скелет без драмы

Multi-agent без очереди = гонки, двойные списания и два ответа клиенту.

Механика	Зачем	Практика для МСП
Inbox queue	буфер пиков	Redis / n8n / брокер, visibility timeout
Claim / lock	один владелец диалога	lock 2–5 мин, heartbeat
Retry + backoff	временные сбои LLM/API	3 попытки, jitter
DLQ	ядовитые задачи	алерт человеку, не бесконечный loop
Idempotency key	защита от double-send	key = dialog_id + step
Priority lanes	VIP / P1 отдельно	2–3 очереди максимум
Poison limit	агент зациклился	max hops 4–6 на сессию

Связанный разбор по заявкам: очереди, retry, DLQ в автоматизации.

Чеклист anti-chaos:

• Один writer в канал клиента в момент времени
• Max hops и max tokens на сессию
• DLQ с человеческим разбором раз в день
• Метрики: queue lag, hop count, DLQ rate, cost/session

---

Память и контекст: что хранить, что резать

Хаос multi-agent чаще всего = «все видят всё» или «никто ничего не помнит».

Тип памяти	Содержимое	TTL	Кто пишет	Кто читает
Working (scratch)	черновик шага	минуты	worker	worker + critic
Session	intent, сущности, stage	часы–дни	router	все по allow-list
Episodic	ключевые факты диалога	дни–недели	scribe	router, HITL
Knowledge (KB)	FAQ, политики	версии	человек	specialists
Audit	traces, tool I/O	месяцы	система	QA, security

Антипаттерны памяти:

1. Пихать весь transcript в каждый hop (дорого и шумно).
2. Общий writable vector store без ACL — утечки между клиентами.
3. «Память = chat history only» — нет структурированных сущностей (заказ, ИНН, слот).
4. Бессрочное хранение PII в логах агентов.

Практичный минимум: session state (JSON) + KB с версиями + audit trace. RAG — только если FAQ реально большой.

Observability-каркас: логи, трейсы, HITL, SLA.

---

Схема «1 агент → multi-agent» без переписывания всего

1. Сначала один агент + tools + handoff до стабильных KPI.
2. Выделите 1 skill, который портит качество (длинный research, жёсткий compliance, тяжёлый CRM-write).
3. Вынесите его в worker с тем же контрактом сообщений.
4. Поставьте critic только на рискованные выходы (цены, юр., деньги).
5. Включите hop-limit и cost cap; сравните cost/session и CSAT 2 недели.
6. Если hop count растёт, а KPI нет — склеивайте обратно.

Метрика	Здоровый multi-agent	Признак хаоса
Hops / session	2–4	7+
DLQ rate	ниже 2%	выше 5%
Double replies	≈ 0	еженедельно
Cost / resolved	≤ 1.3× single	2–5× без uplift
Time-to-resolve	лучше или =	хуже single

---

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

CrewAI / LangGraph / n8n — что брать МСП?

Для МСП я чаще собираю оркестрацию на workflow (n8n и аналоги) + LLM с tool-calling: проще ops и аудит. Фреймворки multi-agent имеют смысл, когда есть своя dev-команда и сложный граф. Выбор инструмента вторичен относительно ролей и очередей.

Сколько агентов — потолок «ещё нормально»?

В клиентских контурах МСП рабочие 2–4 роли (router + 1–2 specialists + HITL). Больше 5 без выделенного владельца платформы почти всегда деградирует в комитет ботов.

Нужен ли отдельный critic на каждый ответ?

Нет. Critic на 100% трафика дорог. Ставьте на деньги, юридические формулировки, PII и случайную выборку 5–10% для QA.

Чем multi-agent отличается от «просто нескольких ботов»?

Общий trace, единый lock диалога, контракт сообщений и политика памяти. Несколько ботов без этого — это несколько точек хаоса.

---

Читайте также

• Очереди, retry и DLQ в автоматизации заявок
• Observability AI-пайплайнов: логи, трейсы, HITL, SLA
• Оркестрация tool-calling, SOP и audit AI-агента

---

Соберу оркестрацию под ваш контур (CRM, очередь, handoff) без лишних агентов «для галочки»: https://raisovich.ru

Когда multi-agent дороже и хуже одного агента?

Если роли не нарисованы на салфетке, нет контракта сообщений и единого lock диалога — hop count растёт, cost/session уходит в 2–5×, а CSAT и time-to-resolve не лучше single-agent.

Зачем очереди, claim/lock и DLQ в оркестрации агентов?

Без них появляются гонки, двойные ответы клиенту и бесконечные retry; visibility timeout, idempotency key и DLQ с человеческим разбором — скелет production multi-agent для МСП.

Какую память разделять между агентами, а какую резать?

Session state и audit trace — общие по allow-list; scratch worker’а — короткий TTL; весь transcript в каждый hop и общий writable vector store без ACL — антипаттерны, которые жгут бюджет и дают утечки.