Как настроить субагентов Claude Code с worktrees и CI/CD: полное руководство по автономной разработке

Один Claude Code — это круто. Два — уже интересно. А десять, работающих параллельно над одним проектом? Это либо ад, либо магия. Я за магию. Но магия требует правильных заклинаний. И главное заклинание тут — Git worktrees в связке с CI/CD.

В этой статье мы соберем пазл: как заставить толпу AI-агентов не мешать друг другу, не переписывать чужой код и при этом вписываться в CI пайплайн. Без лишней теории. Только команды, конфиги и грабли, на которые я уже наступил.

Проблема: один агент — один файл, а когда их десять?

Классический подход: берем одну директорию проекта, кидаем туда Claude Code, он пишет код. Потом второй агент — он переписывает то же самое, потому что «так лучше». Третий — ломает сборку. Знакомо? Это называется гонка за контекстом. Агенты не видят изменений друг друга, если не передавать им состояние через handoff.

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

Тут и приходят worktrees.

Worktrees: как развести агентов по разным папкам, чтобы они не дрались

Git worktrees — это когда вы можете одновременно иметь несколько рабочих копий одного репозитория, привязанных к разным веткам. Каждая копия — отдельная директория на диске, но общий объектный сторадж. Никакого дублирования .git — только одна папка .git для всех.

Звучит идеально для субагентов: даем каждому свой worktree, свою ветку, и они не пересекаются. Пока не наступает момент мержа — но это уже работа CI/CD.

Создаем worktree для каждого субагента:

# Создаем worktree для агента-бэкенда
cd /path/to/main/repo
git worktree add ../backend-agent feature/backend-auth

# Для агента-фронтенда
git worktree add ../frontend-agent feature/frontend-login

# Для тестового агента
git worktree add ../test-agent feature/tests

Теперь каждый агент живет в своей папке. Запускаем их:

cd ../backend-agent
claude --dangerously-skip-permissions -p "Реализуй JWT-аутентификацию согласно spec в docs/auth-spec.md"

cd ../frontend-agent
claude --dangerously-skip-permissions -p "Создай страницу логина по spec"

Сценарии: когда worktree действительно нужен, а когда нет

Worktrees — не серебряная пуля. Иногда проще запустить агентов последовательно или вообще в разных репозиториях. Давайте разберем на примерах.

Если у вас микросервисная архитектура — worktrees вообще не нужны. Каждый микросервис отдельный репозиторий. Но для монолита или монорепозитория это спасение.

CI/CD Pipeline: GitHub Actions как дирижёр оркестра

Worktrees — это половина дела. Вторую половину делает CI/CD. Без автоматизации запуск десяти агентов вручную — это десять открытых терминалов, десять нервных срывов и один прожженный кофеваркой стол.

Идея: вы пушите изменения в main. CI/CD видит, что изменилось, и запускает соответствующих субагентов. Каждый агент получает свой worktree, выполняет задачу, коммитит результат и создает PR. Человек только проверяет пул-реквесты и нажимает «Merge».

В основе лежит паттерн handoff, но мы его адаптируем под CI: вместо файла на диске — артефакты GitHub Actions. Один агент пишет spec, другой — код, третий — тесты. Каждый шаг в пайплайне получает предыдущий результат.

Для такой схемы критично иметь четкие спецификации. Иначе агент-исполнитель не поймет, что от него хотят. Поэтому перед тем, как пихать агентов в CI, обязательно настройте Spec-Driven Development. Без spec ваши CI-агенты будут делать вид, что работают, а на деле — переписывать Hello World.

Субагенты в CI: пишем workflow, который делегирует задачи

Давайте сразу к делу. Вот реальный .github/workflows/agents.yml, который я использую в pet-проекте. Он запускает двух субагентов параллельно: один оптимизирует код, второй — пишет документацию.

name: Claude Agents Orchestrator

on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  prepare:
    runs-on: ubuntu-latest
    outputs:
      matrix: ${{ steps.detect.outputs.matrix }}
    steps:
      - uses: actions/checkout@v4
      - id: detect
        run: |
          echo "matrix={\"agent\":[\"optimizer\",\"documenter\"]}" >> $GITHUB_OUTPUT

  run-agent:
    needs: prepare
    runs-on: ubuntu-latest
    strategy:
      matrix: ${{ fromJson(needs.prepare.outputs.matrix) }}
    steps:
      - uses: actions/checkout@v4
      - name: Set up Claude Code
        run: |
          npm install -g @anthropic-ai/claude-code@latest
          echo "${{ secrets.ANTHROPIC_API_KEY }}" | claude auth
      - name: Create worktree and run agent
        run: |
          BRANCH="agent/${{ matrix.agent }}/${{ github.sha }}"
          git branch $BRANCH
          git worktree add /tmp/worktree-${{ matrix.agent }} $BRANCH
          cd /tmp/worktree-${{ matrix.agent }}
          echo "Running agent: ${{ matrix.agent }}"
          claude --dangerously-skip-permissions --print -p "Твоя роль: ${{ matrix.agent }}. 
          Оптимизируй код в папке src/ (для optimizer) или напиши документацию в docs/ (для documenter).
          Сохрани изменения, сделай коммит с сообщением 'Agent ${{ matrix.agent }}: completed task' и пуш."
      - name: Push changes
        run: |
          cd /tmp/worktree-${{ matrix.agent }}
          git add -A
          git commit -m "Agent ${{ matrix.agent }}: completed task" || echo "No changes"
          git push origin HEAD
      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v6
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          branch: agent/${{ matrix.agent }}/${{ github.sha }}
          title: "${{ matrix.agent }} agent changes"
          body: "Автоматический PR от субагента ${{ matrix.agent }}."

Этот workflow делает следующее:

• detect — определяет, каких агентов запускать (можно динамически на основе изменений).
• run-agent — параллельно запускает каждого агента в отдельной job с матрицей. Каждый получает свой worktree на свежей ветке.
• Агент выполняет задачу через Claude Code, коммитит и пушит.
• Создается Pull Request.

В реальном проекте у меня три агента: refactor-agent, test-agent и doc-agent. Они берут задачи из специального TASKS.md, который тоже генерируется автоматически при пуше. Это уже ближе к автономной разработке, о которой я расскажу ниже.

Ошибки, которые я видел (и вы тоже увидите)

Набил шишек — делюсь. Если хотите сэкономить дни отладки, прочитайте это внимательно.

1 Race condition при одновременном пуше в одну ветку

Два агента независимо создали worktree на одну и ту же ветку? Последний запушенный перезапишет первого. Решение: каждому агенту — уникальная ветка. Используйте ${{ github.sha }} или случайный UUID.

2 Слишком большой контекст в CI

Claude Code в CI не может загрузить контекст проекта на 1 млн токенов — упадет по таймауту. Решение: используйте .claudeignore, чтобы исключить папки node_modules, .git, build. И передавайте агенту только те файлы, которые нужны для его задачи. Идеально — использовать атомарные коммиты: каждая задача — один коммит, контекст минимален.

3 Проблемы с permissions внутри CI

GitHub Actions runner по умолчанию имеет токен GITHUB_TOKEN с ограниченными правами. Worktree требует права на запись в репозиторий. Решение: дайте токену права на содержимое и пул-реквесты. Или используйте Personal Access Token с правами на репозиторий.

4 Забывчивость агентов

Агент сделал работу, но не запомнил, что делал в прошлом запуске. Каждый раз — с чистого листа. Решение: используйте артефакты или специальный файл .agent-state.json в репозитории, куда агент пишет свой прогресс. Следующий запуск читает этот файл и продолжает. Это концепция управления контекстом, описанная в нашей статье об архитектуре Claude Code.

Автономная разработка: kill -9 и уходим спать

Финальная стадия — когда CI/CD сам решает, кого запустить, когда запустить и зачем. Без человека. Звучит как Sci-Fi, но на май 2026 это уже рабочий кейс.

Вот как выглядит идеальный цикл:

• Вы пушите коммит с изменением в spec-файле (SDD).
• CI детектит изменение и запускает агента-архитектора.
• Архитектор генерирует план изменений и кладет его в .agent-plans/.
• CI парсит план и запускает нескольких агентов-исполнителей, каждый в своем worktree.
• Агенты пишут код, тесты, документацию — каждый в своей ветке.
• CI создает PR с кодом.
• Вы просыпаетесь, смотрите PR, запускаете автотесты (которые тоже написал агент) и мёржите.

Этот подход требует дисциплины: spec должен быть однозначным, CI — надежным, агенты — хорошо промпчеными. Но когда оно работает — вы получаете команду из 10 разработчиков, которые пишут код 24/7 без сна и еды.

Один момент: не давайте агенту права на мёрж в main. Пусть он только создает PR. Человек в петле — это последний рубеж защиты от галлюцинаций. Пока AI не научился понимать разницу между «оптимизировать запрос» и «удалить базу данных», держите его на коротком поводке.

Через год мы будем смотреть на этот гайд и смеяться — потому что агенты будут сами писать такие статьи. Но пока — берите и делайте. Worktrees, CI/CD, субагенты. Соберите свою фабрику кода. Начните с одного агента, добавьте worktree, потом CI. И однажды вы увидите, как GitHub Actions запускает десять Claude Code, которые параллельно переписывают ваш legacy-монолит, пока вы пьете кофе.

Только не забудьте про лимиты API, иначе проснетесь от уведомления «Credit card declined».

Подписаться на канал