Supervisor Pattern (Hierarchical Multi-Agent)

1. Обзор концепции и системная проблема

При создании систем с несколькими агентами разработчики часто сталкиваются с проблемой координации. Если агенты просто отправляют сообщения друг другу в общую ленту разговора (Group Chat):

• Теряется цель: Агенты начинают комментировать реплики коллег, забывая о первичном запросе пользователя.
• Неконтролируемый рост контекста: Каждый агент видит полный лог сообщений всех других агентов, что приводит к квадратичному сжиганию токенов и деградации внимания.
• Отсутствие детерминизма: Невозможно гарантировать, что задача действительно решена, а не просто замолчана.

Supervisor Pattern внедряет классическую инженерную иерархию: центральный оркестратор (Supervisor) взаимодействует с пользователем, строит план выполнения, разбивает его на изолированные задачи, назначает их целевым агентам (Specialist Workers) и агрегирует финальный результат.

2. Архитектурная таксономия и ментальная модель

                       ┌─────────────────────────┐
                       │       USER PROMPT       │
                       └────────────┬────────────┘
                                    │
                                    ▼
                       ┌─────────────────────────┐
                       │    SUPERVISOR AGENT     │
                       │  (State, Plan & Router) │
                       └───┬────────┬────────┬───┘
                           │        │        │
           ┌───────────────┘        │        └───────────────┐
           │ Task A                 │ Task B                 │ Task C
           ▼                        ▼                        ▼
┌────────────────────┐   ┌────────────────────┐   ┌────────────────────┐
│   RESEARCH AGENT   │   │    CODER AGENT     │   │     QA AGENT       │
│ (Search, Docs, RAG)│   │ (AST, Git, Patch)  │   │(Evals, Tests, Lint)│
└──────────┬─────────┘   └──────────┬─────────┘   └──────────┬─────────┘
           │                        │                        │
           └───────────────┐        │        ┌───────────────┘
                           ▼        ▼        ▼
                       ┌─────────────────────────┐
                       │   AGGREGATED ARTIFACT   │
                       └─────────────────────────┘

1. State Machine / Router: Супервайзер содержит конечный автомат состояния. После каждого шага он оценивает: Завершено? -> Вернуть ответ пользователю, или Нужен следующий шаг? -> Вызвать соответствующего работника.
2. Task Encapsulation: Каждый работник получает только необходимую входную информацию и собственный набор инструментов (Tooling Scope). Например, Coder Agent не имеет доступа к поиску в Google, а Research Agent не имеет доступа к модификации файловой системы.

3. Технический пайплайн и внутренняя механика

Алгоритм работы супервайзера:

1. Анализ входного задания: Модель супервайзера вызывается с системным промптом, который описывает компетенции каждого работника, и схемой возврата решений (Function Calling / Structured Output).
2. Генерация решения маршрутизации:

   {
     "next_worker": "coder_agent",
     "task_description": "Implement authentication middleware in src/auth.ts using Better Auth",
     "expected_artifacts": ["src/auth.ts"]
   }
   

3. Изолированный запуск работника: Оркестратор инициализирует контекст работника, запускает его автономный цикл и ожидает возврата результата.
4. Контроль качества (Evaluation Gate): Получив результат, супервайзер может либо утвердить его, либо перенаправить QA-агенту для тестирования, либо вернуть работнику на исправление (Self-Correction Loop).

4. Практические инженерные сценарии в продакшене

01. Автономное создание сложной функциональности

Пользователь просит: "Добавь в проект экспорт отчетов в PDF с графиками". Супервайзер вызывает:

1. Research Worker — находит подходящую библиотеку, проверяет лицензию.
2. Backend Worker — создает API endpoint и генератор отчета.
3. Frontend Worker — добавляет кнопку в UI и индикатор загрузки.
4. Tester Worker — запускает тесты Playwright.

02. Трипаж и устранение security-инцидентов

Супервайзер реагирует на alert в Sentry, передает стек-трейс агенту диагностики, валидирует предложенный hotfix у агента тестирования и создает pull request.

5. Подводные камни, типовые ошибки и безопасность

• Deadlock Loops (Зацикливание между супервайзером и работником): Супервайзер считает, что задача решена не полностью, и возвращает ее работнику. Работник возвращает тот же код. Решение: устанавливать max_iterations = 5 с выбрасыванием ошибки человеку.
• Context Bleed (Загрязнение памяти супервайзера): Если работник возвращает 10 000 строк кода, контекст супервайзера быстро переполняется. Работники должны сохранять код в файловую систему и возвращать только статус и diff.
• Single Point of Failure: Если модель супервайзера галлюцинирует и выбирает неправильного работника, вся система идет по ложному пути. Необходимо иметь четкие проверки инвариантов перед вызовом.

6. Стратегический вывод для инженера 2026 года

Supervisor Pattern — это фундамент надежной промышленной разработки мультиагентных систем. Вместо надежды на "магическую кооперацию" многих агентов в открытом чате, супервайзер обеспечивает четкую инженерную диспетчеризацию, изоляцию контекстов и контроль затрат.