1. Начните с single-agent baseline
Сначала решите workflow одним agent. Измерьте quality, latency, cost и failure modes. Multi-agent имеет смысл, если single agent упирается в context, parallelism, specialization или permission separation.
2. Определите причину разделения
- Независимые параллельные задачи.
- Разные knowledge domains.
- Разные permissions.
- Разные evaluation rubrics.
- Большой context, который полезно разделить.
- Необходимость независимой проверки.
3. Не создавайте агента на каждый шаг
Research → summarize → format не требует трёх agents, если шаги простые и зависимые. Используйте deterministic code и обычные functions для predictable transformations.
4. Разделите planner и specialists
Главный agent формулирует sub-tasks, выбирает specialists, собирает results и решает, завершён ли workflow. Specialist имеет узкий context, tools и output contract.
5. Используйте параллельность только для независимых работ
Review разных documents, independent market scans, несколько candidate analyses. Зависимые steps должны оставаться sequential, иначе agents работают на устаревшем state.
6. Создайте contracts между агентами
Каждый subagent получает task, inputs, constraints, expected schema и completion criteria. Свободный текст между agents увеличивает ambiguity.
7. Используйте structured outputs
8. Создайте shared state осторожно
Не позволяйте всем agents хаотично редактировать один документ или CRM object. Используйте orchestrator-controlled state, versioning и conflict resolution.
9. Разделите read и write agents
Research agents могут иметь broad read access, action agents — narrow write permissions. Это уменьшает blast radius и упрощает security review.
10. Используйте least privilege
Каждый agent получает только tools, необходимые его job. Multi-agent система с одинаковыми admin permissions у всех компонентов теряет смысл разделения.
11. Введите approval boundaries
Orchestrator не должен «проголосовать» сам за high-risk action. Payment, deletion, large spend, customer-impacting changes требуют human approval независимо от числа agents.
12. Определите retry policy
Max retries, backoff, alternative tool, escalate. Бесконечный retry создаёт cost и потенциально повторяет опасное действие.
13. Обеспечьте idempotency
Каждое external action должно иметь request ID/idempotency key, где возможно. Если orchestrator повторит step после timeout, действие не должно дублироваться.
14. Обрабатывайте partial failure
Если три subagents завершились, а один blocked, orchestrator должен решить: продолжить с caveat, retry, заменить agent или передать человеку. Не скрывайте incomplete result.
15. Создайте timeout и budget
Ограничьте runtime, tool calls и token/cost budget каждого subtask. Complex orchestration без лимитов может быть экономически непредсказуемой.
16. Используйте deterministic code для агрегации
Filtering, sorting, deduplication, arithmetic и merging structured results часто лучше делать программно. Model оставляйте judgement и synthesis.
17. Создайте trace end-to-end
Parent run → subagent runs → tool calls → outputs → merge → action. Без distributed trace невозможно понять, где появилась ошибка.
18. Оценивайте отдельные agents
Research specialist, classifier, action agent и orchestrator должны иметь свои evals. Общий end-to-end score не показывает, какой component деградировал.
19. Добавьте end-to-end eval
Помимо component evals, нужны real workflows с expected outcome. Multi-agent system может иметь сильные parts и слабую orchestration.
20. Проверяйте coordination failures
- Duplicated work.
- Conflicting conclusions.
- Lost context.
- Wrong task delegation.
- Premature completion.
- Write conflict.
- Unbounded recursion.
21. Используйте independent reviewer при high impact
Для важных research/decision задач второй agent может критически проверить evidence и assumptions. Но reviewer должен иметь independent instructions, иначе он просто подтверждает first answer.
22. Не используйте voting как магию
Три одинаковых agents могут повторить одну ошибку. Diversity полезна только при разных methods/data или independent reasoning.
23. Управляйте context
Передавайте subagent только нужную часть task и data. После завершения возвращайте compact structured result. Это снижает context pollution.
24. Версионируйте topology
Изменение number of agents, routing rule или tool permissions — production change. Храните version и regression eval.
25. Выбирайте topology по задаче
26. Измеряйте orchestration overhead
Multi-agent может повысить quality, но увеличить latency/cost. Сравнивайте с single-agent baseline на том же eval set.
27. Используйте human-in-the-loop как часть topology
Человек может быть explicit node: approval, expert judgement, exception resolution. Не считайте human step архитектурной неудачей.
28. Создайте production monitoring
Completion rate, fallback, retries, cost, latency, high-severity failures, manual interventions. Alert на recursion/loop и tool error spikes.
29. 30-дневный запуск
- Неделя 1: single-agent baseline и failure analysis.
- Неделя 2: выделить 1–2 independent specialists.
- Неделя 3: structured contracts, traces, component evals.
- Неделя 4: end-to-end eval and controlled production.
30. Правила принятия решений (Decision Rules)
- Не переходить в multi-agent без измеримой причины.
- Не использовать LLM для deterministic merge/calculation.
- Не давать всем agents одинаковые широкие права.
- Не выполнять high-risk action без approval.
- Не scale topology без end-to-end eval.
31. Практический пример
Маркетинговая команда строит monthly market review. Single agent не справляется с объёмом: нужно одновременно анализировать конкурентов, customer signals и performance data. Orchestrator делегирует три независимых research tasks, получает structured outputs и объединяет их. Financial recommendation остаётся human-approved. Latency падает, а quality сравнивается с single-agent baseline, чтобы оправдать дополнительную сложность.
32. Как выбирать между handoff и subagent
Handoff передаёт владение task другому agent; subagent выполняет ограниченный кусок и возвращает result orchestratorу. Для customer workflow handoff может быть естественным, а для research decomposition удобнее subagents. Выбор зависит от ownership и shared state.
33. Как управлять fan-out и fan-in
Fan-out запускает несколько независимых workers; fan-in объединяет результаты. Задайте максимум parallel workers, deduplication и merge rule. Unlimited fan-out быстро увеличивает cost и noise.
34. Как предотвращать recursion
Agent A не должен бесконечно делегировать B, который снова делегирует A. Храните depth limit, task lineage и запрещайте повторную delegation того же unresolved task.
35. Как управлять conflicting outputs
Orchestrator не должен просто выбирать самый уверенный ответ. Используйте evidence, deterministic checks или reviewer agent. При irreconcilable conflict возвращайте uncertainty человеку.
36. Как версионировать shared schemas
Если specialist возвращает JSON schema v2, orchestrator должен понимать version. Breaking change в output contract требует coordinated deployment и regression tests.
37. Как использовать multi-agent для marketing
- Research: parallel competitor/customer/market workstreams.
- Campaign: analyst + QA specialist + operations agent.
- Content: research + draft + fact-check reviewer.
- Executive review: finance, pipeline и customer signal specialists.
38. Как оценивать marginal value сложности
Сравните quality gain и latency reduction с additional token/tool cost, operational complexity и new failure modes. Если multi-agent улучшает score на 1%, но удваивает cost и incident surface, single-agent может быть рациональнее.
39. Как проводить chaos tests
Сымитируйте timeout subagent, stale tool result, conflicting data, unavailable service и malformed output. Orchestrator должен сохранять controlled behavior и корректно эскалировать.
Связанные руководства
- AI Research Agent
- AI Analytics Agent
- Campaign Operations Agent
- Почему AI не даёт измеримого эффекта
- Как внедрить ИИ-агента клиентского сервиса (AI Customer Service Agent)
- 25 экспериментов с ИИ-агентами в маркетинге (AI Agent Experiments)
- Как отслеживать протоколы агентной коммерции (Agentic Commerce Protocols)