Мультиагентные системы
Как строить AI-команды: orchestrator + specialists, параллельные vs последовательные агенты, реальные паттерны из AGINE.
Мультиагентные системы
Агент = Claude с доступом к инструментам и чётко поставленной ролью. Когда задача слишком большая для одного контекста или требует параллельной работы — оркестратор запускает специалистов. Вот как это устроено.
Для кого этот гайд
Это про Claude Code — терминальный инструмент (claude.ai/code). Агенты запускаются через Task tool внутри сессии. Если только начинаешь — сначала фишки Claude Code или 10 шагов настройки.
Что такое агент
Роль + инструменты + изолированный контекст.
Роль Чётко описанная задача: «ты code-reviewer, проверяешь только security и стиль». Не «сделай всё».
Инструменты MCP-серверы, bash, файловая система — то что нужно именно этому агенту. Не весь стек подряд.
Изоляция Агент работает в своём контексте. Не засоряет главный. Возвращает только summary результатов.
# Почему агенты, а не один большой промпт
- → Параллельность — code-architect и code-explorer работают одновременно. Скорость как у одного, глубина как у двух.
- → Специализация — агент с ролью «security reviewer» находит уязвимости лучше, чем «посмотри на код в целом».
- → Контекст под контролем — каждый агент несёт только свой контекст. Главный агент не раздувается от промежуточных результатов.
- → Независимая верификация — разные агенты могут проверить одно решение с разных углов без предвзятости первого ответа.
4 базовых паттерна
Каждая система — комбинация этих четырёх.
Orchestrator + Specialists
``
Orchestrator
├── Specialist A (параллельно)
├── Specialist B (параллельно)
└── Specialist C (параллельно)
↓ summary x3
Orchestrator синтезирует → результат
``
Когда: основной паттерн для большинства задач. Один агент раздаёт работу, собирает результаты.
Пример: /feature-dev: orchestrator запускает code-architect + code-explorer параллельно, потом code-reviewer.
Каждый specialist видит только свою задачу — не знает о других. Orchestrator синтезирует всё.
Pipeline (последовательный)
``
Agent A
↓ output A
Agent B (получает output A)
↓ output B
Agent C (получает output B)
↓ финальный результат
``
Когда: когда каждый шаг зависит от предыдущего. Нельзя параллелить.
Пример: /smm: trend-researcher → content-writer → art-director → publisher. Каждый берёт результат предыдущего.
Pipeline медленнее параллели, но неизбежен когда output A = input B.
Verifier (двойная проверка)
``
Writer Agent
↓ черновик
Reviewer Agent (независимый)
↓ замечания
Writer Agent (финальный pass)
↓ результат
``
Когда: критические задачи где первый черновик нельзя отдать без проверки. Security, финансы, публичный контент.
Пример: Генерация документации → независимый reviewer проверяет точность → writer исправляет.
Reviewer не видит process, только результат. Избегает confirmation bias оркестратора.
Fan-out (массовая обработка)
``
Orchestrator
├── Agent(item_1) ─→ result_1
├── Agent(item_2) ─→ result_2
├── Agent(item_3) ─→ result_3
└── Agent(item_N) ─→ result_N
↓
Orchestrator агрегирует
``
Когда: один и тот же тип задачи применяется ко многим элементам. Перевод, рефакторинг N файлов, генерация контента для N платформ.
Пример: Локализация на 5 языков: 5 агентов параллельно, каждый берёт оригинал и переводит.
Самый большой выигрыш по скорости. N задач за время одной.
Как используем в AGINE
Реальные цепочки, не теория.
/smm — Pipeline
trend-researcher → content-writer → art-director → publisher
Почему так: Контент нельзя параллелить: тема выбирается до написания, визуал — после текста.
/feature-dev — Orchestrator + Specialists
code-architect + code-explorer (параллельно) → code-reviewer
Почему так: Архитектуру и исследование кода можно делать одновременно. Ревью — только после написания кода.
/review — Fan-out
security-agent + performance-agent + style-agent (параллельно)
Почему так: Три угла ревью независимы. Нет смысла ждать результатов security перед style.
Explore agent — Orchestrator + Specialist
main → Explore(поиск по codebase) → main получает summary
Почему так: Поиск по коду изолируется в subagent — не засоряет главный контекст большим grep-output.
Как построить свою систему
Пять вопросов перед стартом.
01. Что повторяется каждый день? Начни с задачи которую делаешь вручную регулярно. Агенты = ROI только на повторяющихся задачах.
02. Шаги зависят друг от друга? Да → Pipeline. Нет → Fan-out или Orchestrator+Specialists. Это определяет архитектуру.
03. Нужна независимая проверка? Критический результат (публикация, деплой, финансы) — добавь Verifier agent. Он не видел процесс и не предвзят.
04. Что каждый агент должен знать? Минимальный контекст. Не давай код всего проекта агенту который проверяет только один файл.
05. Как оркестратор получает результат? Каждый subagent возвращает только summary — не полный контекст. Иначе main-контекст раздувается.