Как работает AI-оркестратор изнутри: 5 фаз, 33 агента и автоматические циклы
Техническая архитектура в бизнес-терминах
В первой части я рассказал про главную идею: превратить Claude Code в профессиональный оркестратор с 33 специализированными агентами. Показал главный результат: -80% стоимости, 1-2 недели вместо 2-3 месяцев, 5-7 проектов одновременно.
Сегодня объясню, как это работает изнутри. Но без технического жаргона — на языке бизнеса, через аналогии и конкретные примеры.
Вы узнаете:
- 🔄 Как устроены оркестраторы и воркеры (и зачем это бизнесу)
- ⚡ Как meta-agent создаёт новых специалистов за 2-3 минуты
- 🔧 Как Health workflows автоматически чинят баги до продакшена
- 🎯 Как MCP switcher экономит контекстный бюджет (и ваши деньги)
Погнали.
Паттерн #1: Оркестраторы и Воркеры (как в офисе, только эффективнее)
Аналогия: как работает отдел разработки
Представьте традиционный отдел разработки:
- Руководитель отдела: ставит задачи, проверяет результаты, координирует работу
- Специалисты: фронтенд-разработчик, бэкенд-разработчик, тестировщик, DevOps
В нашей системе точно так же:
- Оркестратор = руководитель отдела (главный Claude Code)
- Воркеры = специалисты (33 AI-агента)
Ключевая разница: руководитель НЕ делает работу за специалистов. Он только координирует.
Как работает оркестратор (на примере проверки багов)
Вы запускаете /health-bugs. Дальше система работает сама:
ШАГ 1: Оркестратор анализирует задачу
- Читает контекст проекта
- Понимает, что нужно: найти баги → исправить → проверить
- Создаёт план-файл для первой фазы (детекция багов)
- Передаёт управление воркеру bug-hunter
ШАГ 2: Воркер выполняет работу
- bug-hunter читает план
- Сканирует весь проект на критические баги, высокоприоритетные, средние, низкие
- Генерирует отчёт с категоризацией
- Возвращает управление оркестратору
ШАГ 3: Оркестратор проверяет результат
- Читает отчёт от bug-hunter
- Проверяет качество (отчёт корректный? категории правильные?)
- Если ОК → переходит к следующей фазе
- Если НЕ ОК → отправляет воркера переделать с замечаниями
ШАГ 4: Оркестратор запускает исправление
- Создаёт новый план-файл для воркера bug-fixer
- Указывает: чинить только критические баги (по приоритету)
- bug-fixer исправляет, запускает проверку типов и тесты
- Возвращает отчёт с изменениями
ШАГ 5: Оркестратор проверяет качество
- Читает изменённые файлы
- Запускает проверку типов (pnpm type-check)
- Запускает тесты (pnpm test)
- Если что-то сломалось → откат изменений, повторная попытка
- Если всё ОК → переходит к следующему приоритету (высокоприоритетные баги)
Результат: цикл повторяется, пока все баги не исправлены или не достигнут лимит итераций (обычно 3).
5 фаз каждого воркера (почему это важно для бизнеса)
Каждый воркер работает по единому паттерну:
Фаза 1: Прочитать план
- Воркер читает файл с задачей (что делать, какие приоритеты, какие файлы трогать)
Фаза 2: Выполнить работу
- Воркер делает свою работу (находит баги, чинит код, обновляет зависимости)
Фаза 3: Проверить себя
- Воркер САМ запускает проверки (типы, сборка, тесты)
- Если что-то сломалось → откатывает изменения, пробует снова
- Не возвращает результат, пока не убедится, что всё работает
Фаза 4: Сгенерировать отчёт
- Воркер создаёт структурированный отчёт (что сделал, какие файлы изменил, какие проверки прошли)
Фаза 5: Вернуть управление
- Воркер возвращает управление оркестратору
- Оркестратор проверяет отчёт и решает, что делать дальше
Зачем это бизнесу?
1. Систематический контроль качества
- Каждый воркер проходит 5 фаз → ничего не забыли, ничего не пропустили
- Проверки автоматические → человеческие ошибки исключены
2. Изоляция контекста
- Каждый воркер работает в отдельном "пространстве" → не тормозит главного оркестратора
- Главный Claude Code остаётся на ~10-15K токенов → можно работать месяцами
3. Прозрачность процесса
- Каждая фаза фиксируется в отчётах → всегда понятно, где сейчас процесс
- Если что-то пошло не так → легко откатить конкретную фазу
4. Масштабируемость
- Нужен новый тип проверки? Создаём нового воркера (2-3 минуты)
- Не нужно переписывать всю систему → просто добавляем специалиста
Реальный эффект: клиент видит не хаос, а управляемый процесс с чёткими этапами и автоматическими проверками на каждом шаге.
Паттерн #2: Meta-Agent — фабрика специалистов за 2-3 минуты
Проблема: не хватает специалиста для новой задачи
Традиционный подход:
- Нужен специалист по GraphQL миграциям? → Нанять человека (недели на поиск, месяцы на онбординг)
- Нужен специалист по Tailwind CSS рефакторингу? → Отвлечь фронтенд-разработчика от основной работы
Результат: либо тормозим проект, либо тратим деньги на найм.
Наш подход: meta-agent создаёт нового специалиста за 2-3 минуты
Что такое meta-agent?
- Это AI-агент, который создаёт других AI-агентов
- Он знает паттерны всей системы (как устроены оркестраторы, как пишутся воркеры)
- Он автоматизирует создание новых специалистов
Как это работает (на примере создания GraphQL migration agent)
Входные данные (вы даёте):
- Имя: graphql-migration-worker
- Домен: database
- Задача: Миграция REST API на GraphQL
- Тип: worker (исполнитель, не координатор)
Процесс (meta-agent делает сам):
- Читает архитектуру системы (ARCHITECTURE.md)
- Читает правила оркестрации (CLAUDE.md)
- Генерирует структуру воркера (5 фаз)
- Добавляет специфику домена (GraphQL best practices, проверка схемы)
- Записывает агента в .claude/agents/database/workers/graphql-migration-worker.md
- Проверяет корректность (YAML frontmatter, структура фаз, инструкции)
Результат: за 2-3 минуты у вас есть новый специалист, готовый к работе.
Зачем это бизнесу?
1. Скорость адаптации
- Новая задача → новый специалист за 2-3 минуты
- Не тратим недели на поиск и найм
- Не отвлекаем существующую команду
2. Стоимость масштабирования
- Создание нового агента: 2-3 минуты (почти бесплатно)
- Найм нового человека: недели поиска + месяцы онбординга + зарплата
3. Специализация без затрат
- Нужен эксперт по Node.js 20 миграции? Создаём агента
- Нужен специалист по AWS Lambda оптимизации? Создаём агента
- Каждый агент — узкий эксперт в своей области
4. Накопление знаний
- Создали агента для GraphQL миграции → теперь он есть навсегда
- На следующем проекте с GraphQL → просто используем существующего агента
- База знаний растёт, стоимость разработки падает
Реальный пример из AI Dev Team:
- Клиент попросил мигрировать Supabase схему на новую версию
- Традиционная команда: найти специалиста (2-3 недели) или отвлечь бэкенд-разработчика (потеря времени)
- Мы: создали supabase-migration-worker за 3 минуты, выполнили миграцию за день
Экономия: 2-3 недели времени + зарплата специалиста.
Паттерн #3: Health Workflows — автоматические циклы "найди → исправь → проверь"
Проблема: баги находят пользователи, а не разработчики
Традиционный процесс:
- Разработчик пишет код
- Код уходит на продакшен
- Пользователь находит баг → пишет в поддержку
- Поддержка передаёт разработчикам
- Разработчики чинят → новая версия → деплой
- Повторяется цикл
Результат: Репутационные потери + затраты на поддержку + срочные исправления.
Наш подход: проактивная диагностика ПЕРЕД продакшеном
Health workflows — это автоматические команды, которые запускаются до деплоя:
/health-bugs: Найти и исправить баги /health-security: Найти и устранить уязвимости безопасности /health-deps: Проверить и обновить зависимости (только безопасные обновления) /health-cleanup: Найти и удалить мёртвый код (который никто не использует)
Как работает цикл "найди → исправь → проверь" (на примере /health-bugs)
ЦИКЛ 1: Детекция
- Запускаете /health-bugs
- Оркестратор вызывает воркера bug-hunter
- bug-hunter сканирует весь проект, находит:5 критических багов12 высокоприоритетных багов23 средних бага47 низкоприоритетных багов
- Возвращает отчёт с категоризацией
ЦИКЛ 2: Исправление критических багов
- Оркестратор создаёт план: "чинить только критические"
- Воркер bug-fixer исправляет 5 критических багов
- Запускает проверки (типы, сборка, тесты) → всё ОК
- Возвращает отчёт с изменениями
ЦИКЛ 3: Проверка (осталось ли что-то?)
- Оркестратор снова вызывает bug-hunter
- bug-hunter сканирует проект → находит:0 критических багов (✅ исправлены)12 высокоприоритетных багов (ещё не тронуты)
- Возвращает отчёт
ЦИКЛ 4: Исправление высокоприоритетных багов
- Оркестратор создаёт план: "чинить высокоприоритетные"
- bug-fixer исправляет 12 багов
- Проверки → всё ОК
- Возвращает отчёт
ЦИКЛ 5: Финальная проверка
- bug-hunter сканирует снова → осталось:23 средних бага47 низкоприоритетных
- Оркестратор решает: критические и высокоприоритетные исправлены → достаточно для деплоя
- Генерирует итоговый отчёт
Результат: критические и высокоприоритетные баги устранены ДО продакшена, средние и низкие остаются в беклоге (не блокируют релиз).
Зачем это бизнесу?
1. Проактивный подход вместо реактивного
- Традиционно: пользователь находит баг → потери репутации → срочное исправление
- С health workflows: система находит баги ДО деплоя → пользователь не видит проблем
2. Приоритизация автоматическая
- Система САМА определяет, что критично, а что можно отложить
- Не тратите время на ручную сортировку багов
3. Автоматический контроль качества
- Каждое исправление проверяется (типы, тесты, сборка)
- Если что-то сломалось → откат и повторная попытка
- Не выходит в продакшен, пока не проверено
4. Экономия на поддержке
- Меньше багов на продакшене → меньше обращений в поддержку
- Меньше срочных исправлений → предсказуемые расходы на разработку
Реальные цифры из AI Dev Team:
- До внедрения health workflows: 15-20 багов в месяц на продакшене
- После внедрения: 2-3 бага в месяц на продакшене
- Сокращение на 85%
Экономия: время поддержки + репутационные потери + стоимость срочных исправлений.
Паттерн #4: MCP Switcher — управление контекстным бюджетом (экономия денег)
Проблема: MCP серверы съедают контекстное окно
Что такое MCP сервера?
- Это интеграции Claude Code с внешними системами
- Примеры: Context7 (документация библиотек), Supabase (база данных), Playwright (автоматизация браузера)
Проблема: каждый MCP сервер занимает 500-1500 токенов из контекстного окна
Аналогия: Представьте, что ваш компьютер одновременно держит открытыми:
- Microsoft Word
- Adobe Photoshop
- Google Chrome с 50 вкладками
- Steam с 3 играми
Результат: компьютер тормозит, память заканчивается.
То же самое с MCP серверами:
- FULL конфигурация: 6 MCP серверов → ~5000 токенов (10% контекстного окна)
- Контекстное окно Claude Code: ~50,000 токенов
- Потеря: 5000 токенов на серверы → остаётся 45,000 для работы
Реальность: вам редко нужны ВСЕ серверы одновременно.
Наш подход: динамическое переключение конфигураций
Скрипт switch-mcp.sh — переключение между конфигурациями одной командой.
Доступные конфигурации:
1. BASE (~600 токенов)
- Context7 (документация) + Sequential Thinking (продвинутое мышление)
- Когда использовать: Повседневная разработка, код-ревью, рефакторинг
- Экономия: 4400 токенов (90%) по сравнению с FULL
2. SUPABASE (~2500 токенов)
- BASE + Supabase MCP (работа с базой данных)
- Когда использовать: Миграции БД, SQL запросы, схемы данных
- Экономия: 2500 токенов (50%) по сравнению с FULL
3. FRONTEND (~2000 токенов)
- BASE + Playwright (браузер) + shadcn (UI компоненты)
- Когда использовать: Вёрстка, UI тесты, компонентная разработка
- Экономия: 3000 токенов (60%) по сравнению с FULL
4. FULL (~5000 токенов)
- Все серверы одновременно
- Когда использовать: Сложные задачи, которые затрагивают всё (редко)
Как это работает в реальной жизни
Сценарий 1: Утро — CODE REVIEW
./switch-mcp.sh
#Выбираете: 1. BASE (~600 токенов)
#Перезапускаете Claude Code
#Работаете: код-ревью, рефакторинг, документирование
Сценарий 2: День — МИГРАЦИЯ БД
./switch-mcp.sh
#Выбираете: 2. SUPABASE (~2500 токенов)
#Перезапускаете Claude Code
#Работаете: миграции Supabase, SQL запросы, схема данных
Сценарий 3: Вечер — UI РАЗРАБОТКА
./switch-mcp.sh
#Выбираете: 3. FRONTEND (~2000 токенов)
#Перезапускаете Claude Code
#Работаете: компоненты, вёрстка, браузерные тесты
Сценарий 4: Сложная задача — ВСЁ СРАЗУ
./switch-mcp.sh
#Выбираете: 4. FULL (~5000 токенов)
#Перезапускаете Claude Code
#Работаете: комплексная фича, требующая всех инструментов
Зачем это бизнесу?
1. Экономия контекстного бюджета (= экономия денег)
- Контекстное окно — это ваш бюджет на разговор с Claude Code
- Меньше токенов на MCP серверы → больше токенов на работу
- BASE вместо FULL → экономия 4400 токенов на каждый разговор
2. Производительность системы
- Меньше серверов → быстрее старт Claude Code
- Меньше интеграций → меньше вероятность ошибок
- Чистый контекст → более точные ответы
3. Фокус на задаче
- Работаете с БД → загружаете только Supabase
- Работаете с UI → загружаете только Playwright + shadcn
- Не отвлекаетесь на неиспользуемые инструменты
4. Масштабируемость
- Нужен новый MCP сервер? Добавляете в конфигурацию
- Не нужен какой-то сервер? Убираете из конфигурации
- Система гибкая, под ваши нужды
Реальные цифры из AI Dev Team:
- Было: FULL конфигурация всегда (~5000 токенов постоянно)
- Стало: BASE большую часть времени (~600 токенов), FULL только для сложных задач
- Средняя экономия: ~3500 токенов на разговор (70% экономии)
Экономия в деньгах:
- Контекстное окно = стоимость API Claude
- 70% меньше токенов → 70% меньше расходы на API
- На масштабе 5-7 проектов → существенная экономия
Реальный пример: клиентский проект от А до Я
Чтобы всё это не звучало абстрактно, покажу реальный кейс из AI Dev Team.
Задача клиента: E-commerce платформа, нужно добавить систему рекомендаций товаров (персонализация).
Традиционная команда (оценка):
- Бэкенд-разработчик: 2 недели (алгоритм рекомендаций, API)
- Фронтенд-разработчик: 1 неделя (виджет рекомендаций, интеграция)
- Тестировщик: 1 неделя (тестирование, баг-репорты)
- DevOps: 2 дня (деплой, настройка инфраструктуры)
- Итого: 4-5 недель, 3-4 человека, ~1.2 млн руб
AI Dev Team (реальное выполнение):
День 1: Планирование + создание агентов
- Запускаю /speckit.specify → создаём спецификацию фичи
- Запускаю /speckit.tasks → генерируем задачи
- Planning Phase: анализируем задачи, определяем, что нужны 2 новых агента:recommendation-engine-builder (построить алгоритм рекомендаций)recommendation-widget-builder (фронтенд-виджет)
- Запускаю meta-agent-v3 2 раза (одновременно в одном сообщении) → 2 агента созданы за 5 минут
- Перезапускаю Claude Code
День 2-3: Реализация бэкенда
- Запускаю /worktree-create feature/recommendations-backend
- Переключаю MCP конфигурацию: ./switch-mcp.sh → SUPABASE (работа с БД)
- Запускаю /speckit.implement → делегирую задачи агенту recommendation-engine-builder
- Агент делает:Алгоритм рекомендаций (collaborative filtering)API эндпоинтыМиграция БД (новые таблицы для истории просмотров)Тесты (unit + integration)
- Запускаю /health-bugs → находит 2 бага → автоматически чинит
- Коммит, push
День 4-5: Реализация фронтенда
- Запускаю /worktree-create feature/recommendations-frontend
- Переключаю MCP: ./switch-mcp.sh → FRONTEND (Playwright + shadcn)
- Запускаю /speckit.implement → делегирую задачи агенту recommendation-widget-builder
- Агент делает:React компонент с рекомендациямиИнтеграция с APIАдаптивная вёрстка (мобилка + десктоп)UI тесты (Playwright)
- Запускаю /health-bugs → баги не найдены
- Коммит, push
День 6: Health checks + деплой
- Переключаю MCP: ./switch-mcp.sh → BASE
- Запускаю /health-security → проверка уязвимостей → всё чисто
- Запускаю /health-deps → обновление зависимостей → 3 обновления безопасности
- Запускаю /health-cleanup → находит мёртвый код (старые компоненты) → удаляет
- Финальная проверка типов + тесты → всё ОК
- Деплой на продакшен
Результат:
- Время: 6 дней (вместо 4-5 недель)
- Команда: 1 человек (я) + 33 агента (включая 2 новых)
- Стоимость: ~150K руб (вместо ~1.2 млн)
- Качество: 0 багов на продакшене (проактивные health checks)
Экономия для клиента:
- Время: -80% (6 дней vs 30 дней)
- Деньги: -87% (150K vs 1200K)
- Качество: +100% (0 багов vs обычно 10-15 багов в первый месяц)
Что дальше? Часть 3: практические кейсы и worktree workflow
В этой статье я показал внутреннее устройство:
- Оркестраторы и воркеры (5 фаз, изоляция контекста, систематический контроль)
- Meta-agent (создание специалистов за 2-3 минуты)
- Health workflows (автоматические циклы "найди → исправь → проверь")
- MCP switcher (управление контекстным бюджетом, экономия денег)
Часть 3 (выйдет через неделю): Практические кейсы и рабочие процессы
- Worktree workflow: как вести 5-7 проектов одновременно
- Стратегии переключения MCP конфигураций для разных типов задач
- Webhook integration: уведомления о завершении задач (работа в фоне)
- Lessons learned: что я узнал за 2 года обкатки на реальных проектах
- Типичные ошибки и как их избежать
Попробовать бесплатно (MIT License)
Система полностью бесплатная и open-source (MIT License). Вы можете использовать её коммерчески без ограничений.
NPM установка:
npm install -g claude-code-orchestrator-kit
Ручная установка:
git clone https://github.com/maslennikov-ig/claude-code-orchestrator-kit.git
cd claude-code-orchestrator-kit
./switch-mcp.sh # Выбрать конфигурацию BASE
#Перезапустить Claude Code
#Запустить /health-bugs для проверки
Обратная связь: супер открыт к диалогу
📱 Telegram
Канал (редкие, но интересные посты): https://t.me/maslennikovigor
Прямой контакт: https://t.me/maslennikovig Нужно обсудить напрямую? Пишите. Всегда открыт к диалогу.
💬 Что буду рад услышать
Критику — Что не так с этим подходом? Где слабые места? Идеи — Какие фичи добавить? Чего не хватает? Предложения — Как улучшить, оптимизировать, рефакторить систему? Вопросы — Что-то неясно? Спрашивайте.
Каналы для обратной связи:
- GitHub Issues: https://github.com/maslennikov-ig/claude-code-orchestrator-kit/issues (для багов, фич-реквестов)
- GitHub Discussions: https://github.com/maslennikov-ig/claude-code-orchestrator-kit/discussions (для идей и вопросов)
- Telegram: https://t.me/maslennikovig (для прямого разговора)
Никакого эго — просто хочу сделать систему лучше.
Продолжение следует. В третьей части — практические кейсы, worktree workflow, webhook integration и lessons learned.
Igor Maslennikov DNA IT / AI Dev Team Telegram: https://t.me/maslennikovig