# Claude Code Projects: как один ИИ координирует команду автономных агентов > Глубокий разбор Claude Code Projects: архитектура Coordinator и Threads, параллельные ветки, общая память MEMORY.md и управление облачными агентами. С выходом **Claude Code Projects** разработка с помощью искусственного интеллекта переходит от парадигмы *«один разработчик — один чат»* к полноценной **мультиагентной оркестрации**. Раньше для решения крупной комплексной задачи инженеру приходилось вручную открывать несколько терминальных сессий, копировать между ними контекст, следить за ветками в Git и самостоятельно склеивать результаты. В новой модели всю диспетчеризацию берет на себя ведущий ИИ. Вы формулируете одну общую стратегическую цель, а Claude берет управление на себя: - **Декомпозирует работу:** разбивает масштабную цель на изолированные подзадачи. - **Оркестрирует потоки:** запускает параллельные облачные сессии (**Threads**). - **Контролирует контекст:** синхронизирует решения через общую память проекта (`MEMORY.md`). - **Верифицирует результат:** прогоняет тесты, проверяет статус сборки в CI и готовит финальные Pull Requests. > [!NOTE] > **Автономность без привязки к локальной машине:** рабочие потоки (Threads) функционируют в изолированных облачных контейнерах Anthropic. Они продолжают выполнять тесты и писать код даже при закрытой крышке вашего ноутбука, а статус работы можно проверять со смартфона. --- ## Архитектура системы: Координатор и Рабочие Потоки (Threads) В основе мультиагентной системы Claude Code Projects лежит двухуровневая модель разделения обязанностей: ``` ┌──────────────────────────────┐ │ ПОЛЬЗОВАТЕЛЬ / ТЕХЛИД │ └──────────────┬───────────────┘ │ Постановка общей цели ▼ ┌──────────────────────────────┐ │ КООРДИНАТОР (COORDINATOR) │ │ Основной диалог Project │ └──────────────┬───────────────┘ │ ┌───────────────────────┼───────────────────────┐ │ Делегирование │ Делегирование │ Делегирование ▼ ▼ ▼ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ THREAD 1 │ │ THREAD 2 │ │ THREAD 3 │ │ Облачная сессия │ │ Облачная сессия │ │ Облачная сессия │ │ Ветка: `feat/p75`│ │ Ветка: `ref/api` │ │ Ветка: `fix/db` │ │ Тесты ➔ PR #101 │ │ Тесты ➔ PR #102 │ │ Тесты ➔ PR #103 │ └────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘ │ │ │ └───────────────────────┴───────────────────────┘ │ Общая память: `MEMORY.md` / `CLAUDE.md` ``` ### Сравнительная таблица уровней системы: | Компонент | Роль в системе | Среда выполнения | Контекст и Память | Главный результат | | :--- | :--- | :--- | :--- | :--- | | **Coordinator** | Управляющий центр, диспетчер | Главный диалог проекта | Видит отчёты всех потоков | Декомпозиция, сводный статус | | **Thread** | Автономный рабочий агент | Облачная сессия (Cloud VM) | Собственная копия Git-ветки | Готовый Pull Request, тесты | | **Subagent** | Узкоспециализированный помощник | Внутри конкретного Thread | Локальный цикл обработки | Выполнение микро-скрипта | --- ## 1. Координатор (Coordinator): управляющий центр Главный разговор внутри Project выступает в качестве диспетчерского узла. Именно сюда вы направляете высокоуровневые требования, технические спецификации и корректировки. Координатор выполняет следующие задачи: - **Прием требований:** анализирует сложный запрос и определяет границы задачи. - **Маршрутизация:** решает, запустить ли новый поток или передать задачу в уже существующий контекст. - **Агрегация отчетов:** получает краткие резюме от агентов без засорения главного чата гигабайтами промежуточных логов. - **Синтез:** соединяет результаты разрозненных потоков в единый финальный продукт. > [!IMPORTANT] > Координатор не выполняет низкоуровневую работу самостоятельно. Он выступает в роли технического лида: распределяет роли, валидирует архитектурную совместимость и контролирует статус выполнения. --- ## 2. Рабочие потоки (Threads): облачные разработчики Каждый **Thread** — это полноценная независимая сессия Claude Code, развернутая в облачной инфраструктуре. При работе с кодовой базой каждый поток: - **Изолирует окружение:** клонирует свежую копию репозитория в отдельный контейнер. - **Работает в своей ветке:** создает ветку Git под конкретную фичу, исключая прямые конфликты с соседними агентами. - **Валидирует код:** запускает локальные линтеры, юнит-тесты и интеграционные сценарии. - **Оформляет результат:** самостоятельно открывает Pull Request на GitHub и отправляет краткую выжимку координатору. Вы можете продолжать ставить координатору новые задачи, пока несколько потоков одновременно рефакторят разные модули системы. --- ## 3. Как Claude декомпозирует задачи Вам не требуется вручную нарезать задачи и создавать агентов через кнопки интерфейса. Вы отправляете в чат глобальное требование, а координатор выбирает одну из трех стратегий: ### Стратегия А: Новая задача ➔ Новый Thread Если задача независима и требует значительного объема изменений, координатор создает под нее чистую облачную сессию. Например, если в одном промпте попросить: - *«Оптимизируй скорость холодного старта API и обнови документацию в OpenAPI-спецификации»* — Claude параллельно запустит два изолированных потока. ### Стратегия Б: Развитие темы ➔ Существующий Thread Если новая вводная дополняет задачу, над которой поток уже работает, Claude не плодит дубликаты. Он направляет запрос в уже прогретый контекст, где агент помнит предыдущие правки и структуру затронутых файлов. ### Стратегия В: Простой вопрос ➔ Ответ в основном чате Короткие справочные запросы (*«Какая версия Node.js указана в корневом package.json?»*) координатор обрабатывает мгновенно в основном окне, не тратя время на инициализацию облачного контейнера. > [!TIP] > **Управление логикой координатора:** если вам не нравится автоматическое распределение, задайте строгое правило в чате: > `«Перед созданием любых новых threads всегда покажи мне план декомпозиции и дождись моего подтверждения».` --- ## 4. Панель Overview: прозрачный контроль статусов Когда в проекте одновременно работают 5–10 агентов, мониторить их через отдельные терминалы невозможно. Вся активность консолидируется в дашборде **Overview**. ### Матрица жизненного цикла потоков: | Статус потока | Что происходит под капотом | Действие со стороны пользователя | | :--- | :--- | :--- | | **`Working`** | Агент пишет код, запускает сборку или тесты | Вмешательство не требуется, задача в процессе | | **`Waiting on you`** | Агент заблокирован: требуется подтверждение действия или API-ключ | Открыть поток и дать ответ / подтверждение | | **`Ready for review`** | Код написан, тесты пройдены, Pull Request открыт | Провести код-ревью в GitHub | | **`Landing`** | Pull Request одобрен и ожидает мерджа в основную ветку | Подтвердить слияние (Merge) | | **`Idle`** | Агент завершил работу и находится в режиме ожидания | Поток готов принять следующую подзадачу | | **`Resolved`** | Ветка слита, задача полностью закрыта | Поток архивируется | ### Специализированные вкладки проекта: - **Library:** база знаний проекта, куда сохраняются созданные агентами спецификации, отчеты и файлы данных. - **Pull Requests:** единый список всех открытых агентами PR с отметками о статусе прохождения CI. - **Routines:** запланированные регулярные процедуры (например, ежедневный аудит безопасности зависимостей). --- ## 5. Общая память проекта: синхронизация без потерь Все потоки внутри одного проекта работают не изолированно — они подключены к единой системе **Project Memory**. ``` Project Root/ ├── MEMORY.md # Главный индекс решений, архитектурных правил и ограничений ├── CLAUDE.md # Локальные инструкции для конкретного репозитория └── docs/ # Спецификации и документация, доступные всем агентам ``` ### Что запоминает Claude: - **Архитектурные договоренности:** например, отказ от библиотеки X в пользу легковесного решения Y. - **Операционные рамки:** перенос даты релиза, особый регламент согласования правок в модуле биллинга. - **Предпочтения автора:** соглашения по стилю кода, запрещенные паттерны, выбор пакетного менеджера (`pnpm` вместо `npm`). Каждый новый поток при старте первым делом считывает файл `MEMORY.md`. Поэтому вам не приходится повторять одним и тем же агентам базовые требования проекта. --- ## 6. Как вмешиваться в работу отдельного агента Несмотря на высокий уровень автономности координатора, разработчик сохраняет полный контроль над каждым звеном. Вы в любой момент можете «провалиться» внутрь любого потока: - **Просмотр полного Transcript:** поминутный лог выполненных shell-команд, прочитанных файлов и выводов линтера. - **Точечная корректировка курса:** отправка прямого указания конкретному агенту (*«Сконцентрируйся только на endpoint /checkout, остальные пока не трогай»*). - **Экстренная остановка (Stop):** прерывание зациклившегося потока в один клик. > [!WARNING] > **Критическое правило маршрутизации:** > Если агент остановился и запрашивает разрешение на выполнение опасного действия (например, удаление файлов или деплой), подтверждать команду необходимо **строго внутри самого Thread**. Команда «Продолжай», отправленная в общий чат координатора, до заблокированного потока не дойдет! --- ## 7. Практические сценарии применения Мультиагентный подход особенно эффективен в четырех инженерных сценариях: ### Сценарий 1: Оптимизация производительности (Latency Profiling) **Задача:** Снизить задержку ответа сервиса оформления заказа (Checkout p75 latency) с 800 мс до 200 мс. - *Thread 1:* Профилирует SQL-запросы к базе данных и создает миграцию для недостающих индексов. - *Thread 2:* Настраивает Redis-кэширование тяжелых ответов каталога. - *Thread 3:* Оптимизирует размер клиентского бандла и убирает неиспользуемые импорты. Каждый поток готовит отдельный PR с изолированными бенчмарками. ### Сценарий 2: Кросс-репозиторная миграция API **Задача:** Вывести из эксплуатации устаревший v1 API во всех смежных сервисах компании. - В Project подключаются репозитории Backend API, Web App и Mobile App. - Координатор запускает 3 потока: каждый поток переводит вызовы на v2 API в своем репозитории, прогоняет локальные тесты и оформляет PR с указанием порядка их слияния. ### Сценарий 3: Сквозной рефакторинг по технической спецификации **Задача:** Реализовать сложный модуль авторизации по файлу `docs/auth-spec.md`. - Координатор дробит спецификацию на логические фазы: генерация моделей данных ➔ реализация middleware ➔ интеграция OAuth ➔ написание e2e-тестов. Знания передаются от фазы к фазе через `MEMORY.md`. ### Сценарий 4: Пакетный аудит документации и контрактов **Задача:** Проверить сотни договоров или тикетов техподдержки. - Threads распределяют между собой пачки документов, извлекают ключевые риски и складывают структурированные JSON/Markdown сводки в общее хранилище `Library`. --- ## 8. Ограничения и подводные камни архитектуры Параллельная работа существенно сокращает время разработки, однако требует понимания технической специфики: 1. **Расход токенов и лимитов тарифа:** каждый активный Thread расходует квоту модели независимо. Кроме того, координатор тратит токены на чтение длинных отчетов. В системе установлен лимит — до **200 новых потоков в день** на проект. 2. **Merge Conflicts:** хотя потоки работают в разных ветках, одновременное редактирование общих модулей или конфигурационных файлов неизбежно приведет к конфликтам при слиянии, разрешать которые придется вручную. 3. **Изоляция облачного окружения:** Threads выполняются в виртуальных контейнерах Anthropic. Они не имеют прямого доступа к вашим локальным базам данных, эмуляторам устройств или внутренним сервисам за корпоративным VPN. Для таких задач по-прежнему требуется локальная сессия Claude Code. 4. **Контекстные окна:** несмотря на автоматическое сжатие контекста (*compaction*), поток при затяжной отладке может исчерпать доступное окно. В таком случае координатор создает чистый поток-преемник. --- ## Резюме: новый уровень разделения труда Claude Code Projects кардинально меняет роль инженера в процессе разработки: ``` БЫЛО: Человек пишет код ➔ Человек запускает тесты ➔ Человек склеивает ветки СТАЛО: Человек ставит цель ➔ ИИ-координатор оркестрирует ➔ Агенты пишут код ``` Вместо ручного набора команд в десятке терминальных окон разработчик превращается в **архитектора и технического директора собственной команды автономных AI-агентов**, оставляя за собой финальное ревью архитектуры и одобрение Pull Requests.