Supervisor Agent и Agent Registry для корпоративной мультиагентной ИИ-платформы

Написать одного ИИ-агента — самое простое. Сложно построить платформу, где множество агентов работают вместе, выполняют многошаговые процессы, меняются каждый в своём темпе и при этом выдерживают нагрузку. В корпоративной мультиагентной платформе это возможно благодаря Supervisor Agent — единой точке, через которую работа попадает в систему.

Пользователи никогда не общаются с отдельными агентами. Запрос уходит к Supervisor, а тот собирает все возможности, которые нужны для задачи.

От отдельных агентов к оркестрации

Возьмём схему без Supervisor. Вызывающая сторона напрямую видит каждого агента:

User
 ├── Planning Agent
 ├── Retrieval Agent
 ├── Research Agent
 ├── Analysis Agent
 └── Report Agent

Кто бы ни обращался к системе, человек или другое приложение, он должен знать, какого агента вызвать и в каком порядке. Это знание расползается повсюду и привязывает вызывающих к внутренностям системы.

Единая точка входа снимает проблему:

User Request
      │
      ▼
Supervisor Agent
      │
      ▼
Planning Agent
      │
      ▼
Structured Execution Plan

Здесь Planning Agent превращает высокоуровневый бизнес-запрос в структурированный план, а Supervisor управляет этим процессом. Сам Supervisor не выполняет каждый шаг. Он ни в коем случае не должен разрастись в одного гигантского агента, который делает всё. Его работа — оркестрация, и ничего больше.

Это настоящий архитектурный перелом. Куча ИИ-скриптов начинает превращаться в спроектированную мультиагентную платформу.

Supervisor координирует и делегирует

Представьте такой запрос:

Проанализируй квартальные финансовые отчёты, сравни их с результатами прошлого года, выдели основные риски и подготовь резюме для руководства.

Planning Agent может разбить его на шаги поменьше:

Business Request
       │
       ▼
Planning Agent
       │
       ▼
Execution Plan
       │
       ├── Retrieval Agent
       ├── Research Agent
       ├── Analysis Agent
       ├── Report Agent
       └── Quality Review Agent

Supervisor проводит этот процесс от начала до конца. Структурно это выглядит так:

User
 │
 ▼
Supervisor
 │
 ▼
Execution Plan
 │
 ▼
Agent Resolution
 │
 ├── Retrieval Agent
 ├── Research Agent
 ├── Analysis Agent
 ├── Report Agent
 └── Quality Review Agent
 │
 ▼
Final Result

Supervisor играет роль control plane. Специализированные агенты — исполнительные возможности, которыми он управляет.

Сначала архитектура, потом фичи

На этом этапе напрашивается просто добавлять агентов. Лучше сначала укрепить фундамент.

Причина простая. Если Supervisor сам создаёт каждого специализированного агента, он постепенно намертво срастается со всеми реализациями. В псевдокоде это выглядело бы так:

Supervisor
 ├── Create PlanningAgent
 ├── Create RetrievalAgent
 ├── Create ResearchAgent
 ├── Create AnalysisAgent
 ├── Create ReportAgent
 └── Create QualityReviewAgent

При пяти агентах это нормально. При 25 становится неудобно, а при 100 — уже настоящая проблема:

• Каждая новая возможность требует правок в Supervisor.
• Замена реализации требует правок в Supervisor.
• Тесты всё сложнее писать и всё меньше им веришь.
• Слой оркестрации обрастает обязанностями, которые никогда не должны были быть его.

Именно такой связанности хороший дизайн и избегает.

Agent Registry

Решение — Agent Registry. Supervisor больше не создаёт агентов. Он запрашивает у реестра нужную ему возможность:

Supervisor Agent
                           │
                           ▼
                      Agent Registry
                           │
       ┌───────────────────┼───────────────────┐
       ▼                   ▼                   ▼
 Planning Agent      Retrieval Agent     Research Agent
       │                   │                   │
       ▼                   ▼                   ▼
 Analysis Agent       Report Agent      Quality Review Agent

Теперь Supervisor не обязан знать, как создаётся тот или иной агент. Он может просто сказать, что ему нужно:

"Give me the retrieval-agent."

Реестр сам определяет, какая реализация отвечает на этот запрос. Это дизайн в стиле «фабрика плюс реестр», и он проводит чёткую границу между решением, что должно произойти, и знанием, как это происходит.

Почему это важно на практике

Допустим, одного агента меняют на более удачного:

ResearchAgent

превращается в

DeepResearchAgent

Без слоя абстракции код оркестрации, скорее всего, пришлось бы менять. С реестром вы меняете регистрацию, и больше ничего. Интерфейс Supervisor остаётся ровно таким же.

Supervisor
    │
    ▼
"research-agent"
    │
    ▼
Agent Registry
    │
    ├── Today  → ResearchAgent
    │
    └── Future → DeepResearchAgent

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

Зависьте от возможностей и контрактов, а не от конкретных реализаций.

Фреймворк оркестрации должен быть заменяемым

Та же логика работает и уровнем выше. Навсегда привязать платформу к одному фреймворку оркестрации было бы ошибкой. Тонкий слой абстракции оставляет место для таких инструментов, как:

• LangGraph
• OpenAI Agents SDK
• Semantic Kernel
• CrewAI

Грубо говоря, платформа находится над этим слоем:

Enterprise AI Platform
                          │
                          ▼
               Orchestration Abstraction
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
    LangGraph      OpenAI Agents SDK   Semantic Kernel
                                             │
                                             ▼
                                           CrewAI

Реализовывать их все заранее не нужно. Смысл в том, чтобы провести границы в правильных местах, и фреймворк, выбранный сегодня, не затвердел в ограничение, с которым потом придётся жить.

Думайте как инженер платформы

Главная перемена в мышлении — перестать видеть в системе набор агентов. Относитесь к ней как к среде выполнения ИИ-работы, к полноценной платформе. Агенты — это специализированные плагины поверх большой платформы, а платформа даёт общую механику, на которую опираются все:

• оценку и наблюдаемость
• логирование и безопасность
• конфигурацию и память
• выполнение инструментов
• оркестрацию и управление процессами

Это меняет форму системы. Типичный ранний дизайн впихивает инфраструктуру в каждого агента:

Agent + Infrastructure
Agent + Infrastructure
Agent + Infrastructure
Agent + Infrastructure

Целевой дизайн выносит эту инфраструктуру наружу и делает общей:

Shared Platform Infrastructure
                           │
      ┌────────────────────┼────────────────────┐
      ▼                    ▼                    ▼
 Configuration         Memory             Observability
      │                    │                    │
      ├────────────── Orchestration ────────────┤
      │                    │                    │
      ▼                    ▼                    ▼
  Security             Evaluation          Tool Layer
                           │
                           ▼
                      Agent Registry
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
       Agent A          Agent B          Agent C

Общие возможности живут в платформе. Предметная бизнес-логика живёт в агентах.

От пяти агентов к сотне

Масштабирование — это не про голое число агентов. Сотня жёстко связанных агентов не лучше с инженерной точки зрения, чем пять чистых. Вопрос, который действительно проверяет дизайн, такой:

Что происходит с архитектурой, когда добавляется агент номер 101?

Если новичок заставляет менять Supervisor, дублировать инфраструктуру, переписывать логирование, заводить новую конфигурацию и перетасовывать процессы, дизайн чисто не масштабируется. Новый агент должен подключаться через уже существующие контракты:

Implement Capability
        ↓
Use Shared Agent Framework
        ↓
Register Agent
        ↓
Expose Through Orchestration
        ↓
Test
        ↓
Deploy

Архитектура должна принимать новые возможности без крупного редизайна.

Supervisor начинает историю, но он не весь мозг

Называть Supervisor мозгом платформы удобно как образ, но ответственность намеренно распределена между несколькими частями:

• Planning Agent решает, какую работу нужно сделать.
• Supervisor координирует, как она выполняется.
• Agent Registry определяет, какая возможность её делает.
• Специализированные агенты решают предметные задачи.
• Сервисы платформы дают общую инфраструктуру.
• Наблюдаемость и оценка фиксируют и оценивают, что на самом деле произошло.

Вместе эти части дают платформе и интеллект, и операционную структуру.

User
                          │
                          ▼
                    Supervisor
                          │
                          ▼
                    Planning Agent
                          │
                          ▼
                   Execution Plan
                          │
                          ▼
                    Agent Registry
                          │
       ┌──────────────────┼──────────────────┐
       ▼                  ▼                  ▼
   Retrieval          Research           Analysis
       │                  │                  │
       └──────────────────┼──────────────────┘
                          ▼
                     Reporting
                          │
                          ▼
                   Quality Review
                          │
                          ▼
                     Final Result

             ───── Shared Platform Layer ───── Configuration • Memory • Security • Logging
 Observability • Evaluation • Tools • Workflows

Главный урок

Главный вывод из работы над Supervisor: корпоративная ИИ-архитектура — это не соревнование, кто выставит больше агентов. Это инфраструктура, которая позволяет находить, координировать, заменять, тестировать, наблюдать и масштабировать специализированные возможности, не переделывая всю систему.

Траекторию легко увидеть:

Переиспользуемый фреймворк → специализированные агенты → Supervisor → Agent Registry → динамическая оркестрация → распределённое выполнение

Каждый шаг снижает связанность и даёт платформе больше места для роста. Будет ли в системе 5 агентов или 100, цель не меняется:

Оркестрация отделена от реализации. Общая инфраструктура отделена от предметной бизнес-логики.

Это и есть переход от создания отдельных ИИ-агентов к инженерии мультиагентной платформы. Не просто стройте больше агентов. Стройте архитектуру, в которую каждый будущий агент подключается, масштабируется и меняется с минимумом усилий.