Агент создает агентов -- делегация и оркестрация

Зачем нужна мультиагентность

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

Решение: один агент-оркестратор раздает задачи специализированным субагентам.

Три модели делегации

Модель 1: Оркестратор — Рабочие

flowchart TD
    O["Оркестратор<br/>(планирует)"] --> K["Кодер"]
    O --> T["Тестер"]
    O --> R["Ревьюер"]

    style O fill:#e0e7ff,stroke:#4f46e5
    style K fill:#d1fae5,stroke:#059669
    style T fill:#d1fae5,stroke:#059669
    style R fill:#d1fae5,stroke:#059669

Оркестратор получает задачу, разбивает на подзадачи, раздает специалистам, собирает результат.

Реализация в Claude Code:

# AGENTS.md (в корне проекта)

## coder
Описание: Пишет код по спецификации
Разрешено: Создание и редактирование файлов в src/
Запрещено: Изменение конфигов, удаление файлов

## tester
Описание: Пишет и запускает тесты
Разрешено: Файлы в tests/, запуск pytest
Запрещено: Изменение src/

## reviewer
Описание: Ревьюит код на баги и стиль
Разрешено: Только чтение
Запрещено: Любые изменения файлов

В Claude Code субагенты описываются декларативно — через markdown. Секции Разрешено / Запрещено — это не рекомендации, а жесткие ограничения: агент-ревьюер физически не сможет изменить файл.

Реализация в LangChain/CrewAI:

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

Модель 2: Pipeline (конвейер)

flowchart LR
    Z["Задача"] --> A["Анализ"] --> K["Кодирование"] --> T["Тестирование"] --> R["Ревью"] --> Res["Результат"]

    style Z fill:#f1f5f9,stroke:#64748b
    style A fill:#dbeafe,stroke:#2563eb
    style K fill:#dbeafe,stroke:#2563eb
    style T fill:#dbeafe,stroke:#2563eb
    style R fill:#dbeafe,stroke:#2563eb
    style Res fill:#d1fae5,stroke:#059669

Каждый агент получает результат предыдущего и передает следующему. Последовательное выполнение.

Когда использовать: Задачи с четкими этапами, где каждый следующий шаг зависит от предыдущего.

Модель 3: Swarm (рой)

flowchart TD
    Z["Задача"] --> A["Агент A"]
    Z --> B["Агент B"]
    Z --> C["Агент C"]
    Z --> D["Агент D"]
    A --> Res["Результат"]
    B --> Res
    C --> Res
    D --> Res

    style Z fill:#f1f5f9,stroke:#64748b
    style A fill:#fef3c7,stroke:#d97706
    style B fill:#fef3c7,stroke:#d97706
    style C fill:#fef3c7,stroke:#d97706
    style D fill:#fef3c7,stroke:#d97706
    style Res fill:#d1fae5,stroke:#059669

Несколько агентов работают параллельно и независимо. Результаты объединяются.

Когда использовать: Задачи, которые можно декомпозировать на независимые части. Например, анализ 10 файлов — каждый агент берет свой файл.

Главная проблема параллельных агентов — конфликты в файлах. Если два агента одновременно правят один файл, результат непредсказуем. Инструмент ccswarm решает это через git worktree — каждый агент получает изолированную копию репозитория:

Реализация в ccswarm (Claude Code + git worktree):

# ccswarm -- каждый агент работает в своем git worktree
# Изоляция: агенты не мешают друг другу

# Запуск пула специализированных агентов
ccswarm run --agents frontend,backend,devops,qa \
            --task "Добавить авторизацию через OAuth2"

# Каждый агент:
# - Получает свою копию репо (git worktree)
# - Работает параллельно
# - Создает PR со своими изменениями
# - Результаты мержатся координатором

Практическая делегация: примеры

Пример 1: Агент-оркестратор в Claude Code

Вы: "Добавь endpoint GET /api/v1/reports/{id}/pdf
     который генерирует PDF-отчет"

Оркестратор (Claude Code):
1. Анализирует задачу -- разбивает на подзадачи
2. [Субагент: кодер] -- пишет endpoint в src/routes/reports.py
3. [Субагент: кодер] -- пишет сервис генерации PDF в src/services/pdf.py
4. [Субагент: тестер] -- пишет тесты в tests/test_reports.py
5. Запускает тесты -- зеленые
6. [Субагент: ревьюер] -- проверяет код
7. Коммитит и создает PR

Пример 2: Мультимодельная команда

Разные задачи — разные модели. Не нужно платить за Opus для форматирования, и не стоит использовать мини-модель для архитектурных решений. Конфигурация ниже показывает типичное распределение моделей по ролям — дорогие модели на критический путь, дешевые на рутину:

# Роутинг моделей по сложности задачи
agent_config = {
    'planning': {
        'model': 'claude-opus',      # Лучшее мышление для планирования
        'max_tokens': 4096
    },
    'coding': {
        'model': 'claude-sonnet',    # Быстрый и точный для кода
        'max_tokens': 8192
    },
    'review': {
        'model': 'gpt-4o',          # Хорош для нахождения багов
        'max_tokens': 4096
    },
    'formatting': {
        'model': 'gemini-flash',    # Дешевый для рутины
        'max_tokens': 2048
    },
    'local_sensitive': {
        'model': 'llama-3.1-70b',   # Локальная модель для конфиденциальных данных
        'endpoint': 'http://localhost:11434'
    }
}

Обратите внимание на local_sensitive — для работы с конфиденциальными данными (ПД, финансы) можно направлять запросы к локальной модели, данные не покидают сервер.

Пример 3: Делегация через MCP

MCP (Model Context Protocol) позволяет агенту подключать внешние инструменты на лету. Конфигурация MCP-серверов — это JSON-файл, где каждый сервер описывается как отдельный процесс:

{
  "servers": {
    "database": {
      "command": "mcp-server-postgres",
      "args": ["postgresql://localhost/mydb"]
    },
    "browser": {
      "command": "mcp-server-puppeteer"
    },
    "slack": {
      "command": "mcp-server-slack",
      "env": { "SLACK_TOKEN": "..." }
    }
  }
}

Агент сам решает, какой MCP-сервер использовать для задачи:

• Нужны данные из БД? — подключает database
• Нужно проверить UI? — подключает browser
• Нужно уведомить команду? — подключает slack

Протокол делегации: trust и boundaries

Принцип: каждый агент имеет scope

Оркестратор (полный доступ к проекту)
  |
  |-- Кодер (scope: src/** -- только код)
  |     НЕ может: менять конфиги, удалять, деплоить
  |
  |-- Тестер (scope: tests/** + read src/**)
  |     НЕ может: менять production-код
  |
  |-- Деплоер (scope: deploy/** + read-only все)
        НЕ может: менять код, только деплоить

Верификация результатов

Оркестратор не слепо принимает результат субагента. Это критически важно: субагент может «галлюцинировать» успешное выполнение или выйти за рамки задачи. Автоматические проверки ловят это до того, как изменения попадут в кодовую базу:

# Паттерн: verify after delegate
result = await coder_agent.execute(task)

# Проверки:
assert result.files_changed <= max_files_allowed
assert not any(f.startswith('config/') for f in result.files_changed)
assert result.tests_passed  # Тесты должны проходить

# Только после проверки -- принять результат
orchestrator.accept(result)

Паттерн verify after delegate — основа надежной мультиагентной архитектуры. Проверка files_changed предотвращает ситуацию, когда кодер-агент решил «заодно» отрефакторить полпроекта.

Антипаттерны мультиагентности

Что дальше

В следующем модуле — границы автономности: обнаружение новых возможностей, безопасность и полная практика настройки автономной среды.