5 паттернов мульти-агентной разработки: какой когда использовать

Запускаешь AI-агента, он пишет код, ты проверяешь – и снова по кругу. Это работает. Но есть подход, при котором агенты работают параллельно, проверяют друг друга и итеративно улучшают результат без твоего участия.

Разница – в архитектурном паттерне. Я перепробовал все пять и расскажу, когда какой заходит.

Паттерн 1: Orchestrator-Workers

Суть

Один управляющий агент (оркестратор) планирует работу и спавнит специализированных воркеров. Воркеры работают параллельно и изолированно – между собой не общаются. Результаты сводятся оркестратором через git.

                    ┌─────────────────────────────────────────┐
                    │           Manager Agent (Opus)          │
                    │  Планирует → Спавнит → Мёрджит → Верифицирует │
                    └───────┬─────────────┬──────────┬────────┘
                            │             │          │
               spawn        │    spawn    │  spawn   │
                            ▼             ▼          ▼
              ┌─────────────────┐  ┌──────────┐  ┌─────────────┐
              │  Frontend Agent │  │  Backend │  │Content Agent│
              │  worktree-1     │  │  Agent   │  │  worktree-3 │
              │  branch: feat/  │  │worktree-2│  │  branch:    │
              │  s1.1-ui        │  │branch:   │  │  s1.3-docs  │
              └────────┬────────┘  │feat/s1.2 │  └──────┬──────┘
                       │           └────┬─────┘         │
                       └────────────────┴───────────────┘
                                        │
                               ┌────────▼────────┐
                               │   Merge Gate    │
                               │ merge → test →  │
                               │  next wave      │
                               └─────────────────┘

Когда применять

  • Задачи делятся на независимые домены (frontend, backend, content)
  • Нужен максимальный параллелизм
  • Есть чёткое file ownership между агентами
  • Задачи хорошо декомпозируются в атомарные единицы

Как это работает у меня

Это мой основной паттерн. Менеджер-агент делает так:

  1. Читает ROLES.md – кто какими файлами владеет
  2. Разбивает цель на атомарные задачи (не более 5-7 файлов на задачу)
  3. Строит файловую карту и обнаруживает зависимости
  4. Распределяет задачи по волнам (zero file overlap внутри волны)
  5. Спавнит воркеров с isolation: "worktree" и run_in_background: true
  6. После завершения волны: мёрдж, тесты, следующая волна

Ключевое правило: менеджер никогда не пишет код. Только планирует и координирует. Когда я впервые это нарушил – менеджер «быстренько поправил» один файл – два воркера из следующей волны получили несогласованное состояние. Час отладки.

Плюсы и минусы

✅ 3-5x ускорение за счёт параллелизма ✅ Изоляция: ошибка одного воркера не затрагивает других ✅ Масштабируемость: до 20 воркеров в одном спринте

❌ Оверхед на планирование и декомпозицию ❌ Требует зрелой файловой структуры (ROLES.md, task specs) ❌ Стоимость: параллельные агенты = параллельный расход токенов

Паттерн 2: Chain (Последовательная цепочка)

Суть

Агенты выстроены в цепочку: каждый получает результат предыдущего и добавляет свой вклад. Выход агента N становится входом агента N+1.

┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│   Discovery  │───▶│  Exploration │───▶│  Architecture│───▶│Implementation│
│  (1 агент)   │    │ (2-3 агента) │    │ (2-3 агента) │    │  (воркеры)   │
└──────────────┘    └──────────────┘    └──────────────┘    └──────┬───────┘
                                                                    │
                                              ┌──────────────┐      │
                                              │  Review      │◀─────┘
                                              │  (reviewer)  │
                                              └──────┬───────┘
                                                     │
                                              ┌──────▼───────┐
                                              │Documentation │
                                              │  (content)   │
                                              └──────────────┘

Когда применять

  • Каждая фаза зависит от результата предыдущей
  • Нужна специализация на каждом этапе пайплайна
  • Процесс имеет чёткую последовательность стадий
  • Качество важнее скорости

Реальный пример: feature-dev плагин

Плагин feature-dev реализует 7-фазный цепочечный workflow:

Discovery -> понять требования и контекст Codebase Exploration -> 2-3 параллельных code-explorer агента исследуют кодовую базу Clarifying Questions -> уточнить неясности до начала реализации Architecture Design -> 2-3 параллельных code-architect агента проектируют решение Implementation -> воркеры реализуют по архитектурному плану Review -> code-reviewer проверяет реализацию Documentation -> content-агент документирует изменения

Обрати внимание: внутри каждой фазы может работать несколько параллельных агентов. Это гибрид Chain + Fan-out. На практике чистые паттерны встречаются редко.

Плюсы и минусы

✅ Качество выше: каждая фаза строится на осмысленном фундаменте ✅ Специализация на каждом этапе ✅ Прозрачность: легко найти, на каком шаге возникла проблема

❌ Медленнее параллельных подходов ❌ Ошибка на раннем этапе распространяется по всей цепочке ❌ Оверхед на передачу контекста между фазами

Паттерн 3: Fan-out + Aggregation

Суть

Задача распараллеливается на N специализированных агентов, которые работают одновременно. Результаты агрегируются с фильтрацией и scoring’ом.

                    ┌──────────────────────────────┐
                    │     Задача на ревью           │
                    └──────┬───────────────────────┘
                           │
           fan-out (параллельный запуск)
          ┌────────┬───────┼───────┬────────┐
          ▼        ▼       ▼       ▼        ▼
    ┌──────────┐ ┌───────┐ ┌─────┐ ┌─────────┐ ┌──────────┐
    │Bug       │ │Test   │ │Type │ │Silent   │ │CLAUDE.md │
    │Scanner   │ │Cov.   │ │Ana- │ │Failure  │ │Compliance│
    │          │ │Analyst│ │lyzer│ │Hunter   │ │Checker   │
    └────┬─────┘ └───┬───┘ └──┬──┘ └────┬────┘ └────┬─────┘
         │           │        │          │           │
         └───────────┴────────┴──────────┴───────────┘
                                    │
                    ┌───────────────▼───────────────────┐
                    │        Aggregator Agent           │
                    │  confidence scoring (порог 80/100)│
                    │  → финальный отчёт               │
                    └───────────────────────────────────┘

Когда применять

  • Задача выигрывает от рассмотрения с разных перспектив
  • Нужна фильтрация шума (не каждое замечание важно)
  • Есть чёткие критерии ранжирования
  • Полнота покрытия важнее скорости

Реальный пример: code-review плагин

Это эталонная реализация Fan-out + Aggregation. Работает так:

  • 4-6 ревью-агентов запускаются параллельно
  • Каждый фокусируется на своей перспективе:
    • bug-scanner – поиск багов
    • test-coverage-analyzer – покрытие тестами
    • type-design-analyzer – качество типизации
    • silent-failure-hunter – ошибки без исключений
    • comment-accuracy-reviewer – корректность комментариев
    • claude-md-compliance-checker – соответствие проектным конвенциям

Confidence scoring: каждый агент оценивает свои находки по шкале 0-100. Агрегатор публикует только замечания с confidence >= 80. Это отсекает ложные срабатывания.

Бонус: плагин автоматически пропускает draft PR, закрытые PR и тривиальные изменения (документация, конфиги) – не тратит ресурсы зря. Мелочь, но за месяц экономия ощутимая.

Плюсы и минусы

✅ Полное покрытие: каждая перспектива замечает своё ✅ Параллелизм даёт скорость при широком охвате ✅ Confidence scoring снижает шум

❌ Стоимость: N агентов = N x стоимость токенов ❌ Агрегация – нетривиальна при противоречивых результатах ❌ Требует хорошо определённых перспектив

Паттерн 4: Self-referential Loop (Ralph-loop)

Суть

Один агент работает итеративно в цикле: выполняет задачу, проверяет результат, если недостаточно хорошо – улучшает. И так пока не достигнет критерия завершения.

                    ┌────────────────────────┐
                    │     Начальная задача    │
                    └────────────┬───────────┘
                                 │
                    ┌────────────▼───────────┐
                    │   Agent выполняет      │◀─────────────────┐
                    │   задачу               │                  │
                    └────────────┬───────────┘                  │
                                 │                              │
                    ┌────────────▼───────────┐                  │
                    │   Agent проверяет      │                  │
                    │   completion criteria  │                  │
                    └────────────┬───────────┘                  │
                                 │                              │
                            ┌────▼────┐                         │
                            │ Done?   │──── Нет ────────────────┘
                            └────┬────┘       Stop hook перезапускает
                                 │                 агента с результатами
                              Да │
                    ┌────────────▼───────────┐
                    │   Финальный результат  │
                    └────────────────────────┘

Как это работает

Stop hook – специальный хук Claude Code, который перехватывает выход агента. Если completion criteria не достигнуты, хук перезапускает агента с тем же промптом плюс результаты предыдущей итерации.

Типичный сценарий: агент пишет функцию -> запускает тесты -> 3 теста упали -> видит ошибки -> исправляет -> запускает снова -> 1 тест упал -> исправляет -> все зелёные -> Stop hook видит criteria met -> завершает.

Без Ralph-loop я вручную запускал цикл: «попробуй ещё раз», «теперь вот этот тест чини». С Ralph-loop это происходит автоматически. Экономит кучу времени на рутинных задачах.

Когда применять

  • Задача требует нескольких итераций для достижения качества
  • Есть объективные критерии завершения (тесты проходят, lint clean, coverage > 80%)
  • Задача хорошо определена, но путь к решению непредсказуем
  • Оверхед параллелизма не оправдан (нет независимых подзадач)

Плюсы и минусы

✅ Автономность: агент сам достигает качества без ручного вмешательства ✅ Простота: один агент, один промпт, один Stop hook ✅ Хорошо работает с объективными критериями (тесты, линтер)

❌ Риск бесконечного цикла без правильных completion criteria ❌ Нет параллелизма – медленнее Fan-out для параллелизуемых задач ❌ Стоимость растёт с каждой итерацией

Паттерн 5: Evaluator-Optimizer

Суть

Два агента в связке: генератор создаёт результат, оценщик проверяет и возвращает фидбек. Цикл повторяется до достижения качества.

                    ┌──────────────────────┐
                    │   Начальная задача    │
                    └──────────┬───────────┘
                               │
                    ┌──────────▼───────────┐
                    │   Generator Agent    │◀────────────────────────┐
                    │   Sonnet             │                         │
                    │   Создаёт результат  │                         │
                    └──────────┬───────────┘                         │
                               │ output                              │
                    ┌──────────▼───────────┐                         │
                    │   Evaluator Agent    │                         │
                    │   Opus               │                         │
                    │   Оценивает качество │                         │
                    └──────────┬───────────┘                         │
                               │                                     │
                          ┌────▼────┐                                │
                          │  Good?  │──── Нет: feedback ─────────────┘
                          └────┬────┘
                               │ Да
                    ┌──────────▼───────────┐
                    │   Финальный результат │
                    └──────────────────────┘

Отличие от Ralph-loop

В Ralph-loop один агент сам себя оценивает. Тут оценщик – отдельный агент с независимой перспективой. Это важно: сложно объективно критиковать то, что сам только что создал. Знакомо? Как с code review – свой код всегда кажется идеальным.

Когда применять

  • Задачи с субъективными критериями качества (дизайн, контент, UX-копирайтинг)
  • Нужна независимая оценка
  • Генерация и оценка требуют разных моделей (Sonnet генерирует, Opus оценивает)
  • Высокие требования к качеству

Реальный пример: контент-пайплайн

Я использую этот паттерн для производства контента:

  • content-agent (Sonnet) пишет черновик статьи
  • marketing-agent (Opus) оценивает: SEO, читаемость, engagement, точность
  • Если оценка < порога – возвращает конкретный фидбек
  • content-agent дорабатывает
  • Цикл до достижения quality threshold

Из Anthropic Cookbook: Evaluator-Optimizer показывает лучшие результаты, чем одиночный агент с длинным промптом, для задач генерации текста и кода. Но только при условии, что оценщик имеет чёткие рубрики оценки. Без рубрик – пустая трата токенов.

Плюсы и минусы

✅ Независимая оценка устраняет «слепые пятна» генератора ✅ Разные модели: дешевле генерировать Sonnet, дороже оценивать Opus ✅ Хорошо масштабируется для субъективных задач

❌ Два агента вместо одного – стоимость ❌ Риск цикла при нечётких критериях оценки ❌ Evaluator должен давать конкретный, actionable фидбек

Как выбрать: дерево решений

┌─ Задача делится на независимые подзадачи? ─────────────────────────┐
│                                                                      │
│  Да → разные домены/файлы?                                          │
│       ├── Да → ORCHESTRATOR-WORKERS (параллельные воркеры)          │
│       └── Нет → FAN-OUT + AGGREGATION (разные перспективы)         │
│                                                                      │
└─ Нет → задача последовательна?                                      │
         │                                                             │
         ├── Строгая последовательность фаз?                          │
         │   └── Да → CHAIN                                           │
         │                                                             │
         ├── Нужна независимая оценка?                                │
         │   └── Да → EVALUATOR-OPTIMIZER                             │
         │                                                             │
         └── Объективные критерии завершения?                         │
             └── Да → SELF-REFERENTIAL LOOP (Ralph)                   │

Матрица выбора

КритерийOrchestratorChainFan-outRalph-loopEvaluator
СкоростьВысокаяНизкаяВысокаяСредняяСредняя
КачествоСреднееВысокоеВысокоеВысокоеВысокое
СтоимостьВысокаяСредняяВысокаяСредняяСредняя
Сложность настройкиВысокаяСредняяСредняяНизкаяНизкая
ПараллелизмДаНетДаНетНет

Комбинирование паттернов

Реальные системы редко используют один паттерн в чистом виде. Feature-dev плагин – хороший пример:

  • Внешний уровень: Chain (7 фаз последовательно)
  • Внутри Exploration и Architecture: Fan-out (2-3 параллельных агента)
  • На фазе Implementation: Orchestrator-Workers (менеджер спавнит воркеров)
  • Для итеративного исправления: элементы Ralph-loop

Мой совет: начинай с простейшего паттерна, который решает задачу. Усложняй только когда натолкнулся на конкретное ограничение. Я поначалу пытался сразу городить Evaluator-Optimizer для задач, где хватило бы обычного Ralph-loop. Потратил время на настройку рубрик оценки, а задача-то была с объективными критериями – тесты зелёные или нет.

Итого

Пять паттернов покрывают большинство сценариев:

  1. Orchestrator-Workers – максимальный параллелизм, независимые домены
  2. Chain – последовательные фазы, акцент на качество
  3. Fan-out + Aggregation – широкое покрытие с разных перспектив
  4. Self-referential Loop – итеративное достижение качества с объективными критериями
  5. Evaluator-Optimizer – независимая оценка для субъективных задач

Возьми одну из своих регулярных задач и примерь паттерн. Orchestrator-Workers для разнородных задач, Ralph-loop для итеративной работы с тестами – это два самых простых входа.

Если хочешь обсудить, какой паттерн подходит для твоего проекта – пиши мне в Telegram: @sergey_akhantev_it_mentor или в группу @gigaexp