Вы видели скриншоты. Пять, десять, пятнадцать агентов Claude Code работают в tmux, каждый занят своей частью одной и той же кодовой базы. Выглядит продуктивно. Выглядит захватывающе. И если вы пробовали это воспроизвести, знаете: на деле всё гораздо сложнее, чем кажется.
Запустить одного агента Claude Code просто. Даете задачу, он пишет код, вы проверяете. Два управляемы, но появляется новая проблема: они могут наступать друг другу на изменения. Пять требуют системы. Десять без системы — это хаос с ежемесячным счётом.
Это руководство о той самой системе. Не теория мультиагентных архитектур. Реальный, практический рабочий процесс для запуска нескольких агентов Claude Code на настоящей кодовой базе, чтобы всё не развалилось.
Почему одного агента недостаточно
Один агент Claude Code способен на удивительно многое. Но он работает последовательно. Пока реализует бэкенд-эндпоинт, фронтенд простаивает. Пока пишет тесты, документация отстает. Пока отлаживает ошибку сборки, три новые фичи ждут в очереди.
Расчёт меняется, когда осознаёшь, что большая часть разработки параллелизуема. Фронтенд-компонент и бэкенд API-эндпоинт не делят файлы. Набор тестов и обновление документации затрагивают разные каталоги. Архитектурный ревью и исправление бага работают на совершенно разных временных масштабах.
Узкое место при работе с одним агентом — не скорость агента. Это глубина конвейера. Один агент — одна задача в работе за раз. Несколько агентов — несколько задач одновременно, и это меняет то, что один разработчик может доставить за день.
Стратегии разделения работы
Прежде чем открыть вторую панель tmux, нужно решить, как делить работу. На практике работают три паттерна.
Разделение по компоненту
Простейший подход. Агент A владеет components/, Агент B — server/, Агент C — lib/. Каждый работает на своей территории и никогда не трогает файлы за её пределами.
Работает, когда кодовая база имеет чёткие архитектурные границы. Next.js-приложение с отдельными фронтенд-компонентами, бэкенд-экшенами и общими библиотеками естественно делится по этим линиям.
Ограничение: сквозная работа. Фича, требующая изменений в UI, API и слое данных, не вписывается аккуратно в территорию одного агента. Решение — разбить фичу на подзадачи по компонентам и выстроить их последовательность.
Разделение по роли
Вместо деления по расположению кода — деление по функции. Один агент пишет код. Другой пишет тесты. Третий занимается документацией. Четвёртый делает код-ревью.
Это отражает работу человеческих команд и даёт более высокое качество, потому что агент тестирования не знает (и не интересуется), насколько легко было написать код. Он тестирует по спецификации, а не по предположениям автора.
Компромисс — больше координационных затрат. Агент тестирования ждёт завершения агента реализации. Агент документации ждёт обоих. Вы управляете конвейером, а не просто параллельными работниками.
Разделение по фазе жизненного цикла
Более продвинутая версия ролевого разделения. Один агент проводит мозговой штурм и планирует. Другой реализует. Третий проверяет. Работа проходит через фазы, и каждый агент специализирован для своей.
Это паттерн, который мы используем в Beadbox. Наш агент-архитектор проектирует, инженерные агенты реализуют, QA-агенты проверяют независимо. Одна задача проходит через нескольких специалистов, и каждый добавляет слой качества, который агенты-универсалы упускают. О полной настройке я написал в Я выпускаю ПО с 13 ИИ-агентами.
Правильная стратегия зависит от проекта. Маленькие проекты с чёткими границами файлов хорошо работают с компонентным делением. Крупные проекты, где важно качество, выигрывают от ролевого или фазового деления. Большинство команд приходят к гибриду.
Паттерн идентичности CLAUDE.md
Здесь теория встречается с реализацией. Каждый агент Claude Code получает свой файл CLAUDE.md, и этот файл — самый важный элемент всей мультиагентной системы.
CLAUDE.md определяет четыре вещи:
- Чем является агент. Его роль, специализация и домен.
- Чем он владеет. Файлы, каталоги или зоны ответственности, которые он контролирует.
- Что ему нельзя трогать. Явные границы, предотвращающие конфликты.
- Как он общается. Протоколы для отчётности и координации с другими агентами.
Реальный пример. Два агента Claude Code с взаимодополняющими областями:
# CLAUDE.md for Agent: frontend-eng
## Identity
Frontend engineer. You implement UI components, pages, and client-side
logic. You own everything under components/, app/, and hooks/.
## File Ownership
- components/** (you own these)
- app/** (you own these)
- hooks/** (you own these)
- lib/utils.ts (shared, read-only for you)
- server/** (DO NOT MODIFY — owned by backend-eng)
## Communication
When you need a backend change, create a task describing what API
you need. Do not implement it yourself.
When done with a task, comment: "DONE: <summary>. Commit: <hash>"
# CLAUDE.md for Agent: backend-eng
## Identity
Backend engineer. You implement server actions, API routes, and
data layer logic. You own everything under server/, actions/, and lib/.
## File Ownership
- server/** (you own these)
- actions/** (you own these)
- lib/** (you own these, except utils.ts is shared)
- components/** (DO NOT MODIFY — owned by frontend-eng)
- app/** (DO NOT MODIFY — owned by frontend-eng)
## Communication
When you change a data type in lib/types.ts, notify frontend-eng
by commenting on the relevant task.
When done with a task, comment: "DONE: <summary>. Commit: <hash>"
Обратите внимание на явные строки "DO NOT MODIFY". Без них агенты дрейфуют. Они видят возможность «помочь», исправив опечатку в чужом файле, и внезапно у вас конфликты слияния. Или хуже — они молча рефакторят код, от которого зависел другой агент.
Секция идентичности — не декорация. Claude Code читает CLAUDE.md в начале каждой сессии и использует его для определения рамок поведения. Агент, которому сказали, что он «фронтенд-инженер», естественно будет сопротивляться изменениям бэкенда. Агент, которому сказали, что он владеет определёнными каталогами, спросит перед модификацией файлов за их пределами.
Предотвращение конфликтов слияния
Владение файлами на уровне файлов, как показано в примерах CLAUDE.md выше, — первая линия обороны. Но не единственная.
Коммитьте и пушьте часто. Агент, работающий 45 минут без коммита, строит бомбу замедленного действия для конфликтов слияния. Инструктируйте агентов (в их CLAUDE.md) коммитить после завершения каждой логической единицы работы.
Пуллите перед началом новой работы. Каждый агент должен выполнять git pull --rebase перед началом новой задачи. Это элементарно обеспечить, добавив в протокол запуска агента в CLAUDE.md.
Используйте фича-флаги для сквозной работы. Когда двум агентам нужно менять один файл, безопаснее часто бывает дать одному агенту создать интерфейс или флаг, закоммитить и запушить, а второму — спуллить и строить поверх. Последовательность побеждает параллелизм, когда альтернатива — кошмар слияния.
Отдельные ветки для рискованной работы. Если агент делает что-то экспериментальное, дайте ему собственную ветку. Особенно полезно для архитектурных спайков или рефакторинга, который может не пойти в прод.
На практике комбинация правил владения файлами и частых коммитов устраняет 90% конфликтов слияния. Оставшиеся 10% происходят в общих файлах вроде types.ts или package.json и обычно тривиально разрешаются.
Коммуникация между агентами
Агенты Claude Code не могут общаться напрямую. Нет общей памяти, нет шины сообщений, нет каналов реального времени между ними. Это на самом деле хорошо. Прямая коммуникация между агентами создаёт связанность, гонки и кошмары отладки.
Вместо этого коммуникация происходит через артефакты. Работают три паттерна:
Комментарии к задачам
Самый надёжный паттерн. Агент A завершает работу и комментирует общую задачу: "DONE: реализован эндпоинт /api/users. Возвращает JSON. Схема в lib/types.ts." Агент B читает комментарий и точно знает, что доступно.
Обновления статуса
У каждой задачи есть статус: open, in_progress, done, blocked. Когда Агент A отмечает предварительное условие как done, Агент B (или вы, или координатор) знает, что зависимая работа может начаться.
Изменения файлов
Простейшая форма. Агент A записывает TypeScript-интерфейс в lib/types.ts и коммитит. Агент B пуллит и видит новые типы. Никакой явной коммуникации не нужно — код сам является сообщением.
Что НЕ работает: попытка построить систему обмена сообщениями в реальном времени между агентами. Если Агенту A нужно ждать вывода Агента B, моделируйте это как зависимость между задачами, а не как синхронный вызов.
Цикл диспетчеризации
Кто-то должен управлять процессом. В мультиагентной конфигурации Claude Code есть два варианта: вы делаете это вручную или назначаете агента-координатора.
Ручная диспетчеризация
Вы ведёте список задач. Назначаете задачи агентам. Проверяете прогресс. Устраняете блокеры. Работает примерно до пяти агентов, потом координационные затраты начинают съедать прирост производительности.
Типичный цикл ручной диспетчеризации:
- Утро: Проверить, что в работе, что заблокировано, что готово к началу
- Назначить: Отправить каждому агенту следующую задачу с контекстом
- Мониторить: Каждые 10-15 минут проверять вывод агентов на признаки зависания
- Разблокировать: Когда агент упирается в проблему, вмешаться или перераспределить
- Итоги: В конце дня проверить, что было доставлено, и спланировать завтра
В tmux это выглядит как переключение между панелями, чтение последнего вывода и принятие решений о том, что нужно каждому агенту. Инструменты вроде gp (подсмотреть последний вывод агента, не прерывая его) помогают, но вы остаётесь узким местом.
Агент-координатор
Выделите одного агента Claude Code для диспетчеризации работы остальным. Этот агент не пишет код. Он читает бэклог задач, назначает работу свободным агентам, проверяет прогресс и ведёт цикл диспетчеризации программно.
Это паттерн, который мы используем. Наш агент "super" выполняет патрульный цикл: каждые несколько минут проверяет каждого активного агента, проверяет статусы задач, выявляет блокеры и диспетчеризирует новую работу, когда агент простаивает. Человек (я) принимает приоритетные решения и разрешает неоднозначные ситуации. Super занимается логистикой.
Агенту-координатору нужен свой CLAUDE.md:
# CLAUDE.md for Agent: super
## Identity
Dispatch coordinator. You assign work to agents, monitor progress,
and ensure the pipeline keeps moving. You do NOT write code.
## Responsibilities
- Maintain awareness of all active tasks and their statuses
- Assign ready tasks to idle agents
- Monitor agent progress every 5-10 minutes
- Escalate blockers to the human when agents can't self-resolve
- Verify agents follow the protocol: plan before code, test before done
## Communication
- To assign work: message the agent with task ID and priority
- To check progress: peek at agent's recent output
- To escalate: message the human with context and options
Паттерн координатора масштабируется гораздо лучше ручной диспетчеризации. При 10+ агентах ручная координация — это работа на полную ставку. Агент-координатор берёт на себя рутинную логистику и эскалирует только решения, требующие человеческого суждения.
Раскладка tmux для мультиагентной работы
Физическая раскладка важнее, чем кажется. Конфигурация tmux для запуска нескольких агентов Claude Code:
# Create a new tmux session
tmux new-session -s agents -n super
# Split into panes for each agent
tmux split-window -h -t agents:super
tmux split-window -v -t agents:super.1
# Or create named windows (easier to manage at scale)
tmux new-window -t agents -n eng1
tmux new-window -t agents -n eng2
tmux new-window -t agents -n qa1
tmux new-window -t agents -n frontend
tmux new-window -t agents -n backend
Именованные окна побеждают разделённые панели после четырёх агентов. Пять панелей на одном экране не прочитать, но быстро переключаться между именованными окнами легко. Соглашение об именовании тоже важно. eng1, eng2, qa1 мгновенно сканируются. agent-1, agent-2, agent-3 ничего не говорят.
Запускайте каждого агента в собственном рабочем каталоге с собственным CLAUDE.md:
# In the eng1 window
cd ~/project
claude --claude-md ./agents/eng1/CLAUDE.md
# In the qa1 window
cd ~/project
claude --claude-md ./agents/qa1/CLAUDE.md
Практический совет: держите окно «dashboard», которое просто шелл. Используйте для запуска git log --oneline -10, проверки статуса задач или наблюдения за агентами без прерывания их работы. Это станет вашим центром управления.
Когда что-то идёт не так
Мультиагентные рабочие процессы ломаются предсказуемыми способами. Знание режимов отказа избавляет от обучения на собственных ошибках.
Два агента редактируют один файл. Обычно потому, что владение файлами в CLAUDE.md было недостаточно конкретным. lib/utils.ts — классический магнит конфликтов. Решение: либо назначить общие утилитарные файлы конкретному агенту, либо сделать их доступными только для чтения для всех и маршрутизировать изменения через единственного владельца.
Агент замолкает. Упёрся в лимит запросов, попал в цикл ошибок или застрял в глубокой цепочке рассуждений. Проверьте вывод. Если он повторяет одну и ту же падающую команду, завершите сессию и перезапустите с более чёткими инструкциями. Периодические проверки здоровья (каждые 10-15 минут) ловят это до того, как потеряете час.
Контекстные окна заполняются. Долго работающие агенты накапливают контекст и начинают работать хуже. CLAUDE.md каждого агента должен включать протокол для этого: «Если работаешь более 90 минут, сохрани состояние и запроси новую сессию.» На практике это означает: агент коммитит работу, записывает, где остановился, и новая сессия Claude Code продолжает с этого коммита.
Работа отклоняется от спецификации. Агент строит что-то технически работающее, но не соответствующее тому, что было запрошено. Решение — паттерн «план перед кодом»: перед написанием кода агент комментирует свой план реализации. Вы просматриваете план за 60 секунд и ловите недопонимания до того, как они станут диффом на 500 строк.
Конвейер застревает. Агент B ждёт Агента A, но Агент A ждёт вашего решения. Тем временем Агент C закончил работу 30 минут назад и простаивает. Это сбой координации, а не технический. Агент-координатор (или вы) должен поддерживать конвейер в движении, отслеживая блокеры и перераспределяя простаивающих агентов.
Как мы решили это с помощью Beads
Всё вышеописанное работает на стикерах и добрых намерениях. Но примерно на пяти агентах неформальный подход начинает трещать. Вы забываете, над чем работал Агент C. Теряете из виду, какие задачи заблокированы. Не помните, был ли API-эндпоинт, нужный Агенту B, завершён или только начат.
Это проблема, которую решает beads. Beads — open-source, локальный трекер задач. Каждая задача — «бусина» (bead) с уникальным ID, статусом, описанием, критериями приёмки, зависимостями и веткой комментариев. Всё доступно через CLI под названием bd, что означает, что ваши агенты Claude Code могут читать и писать, не покидая терминала.
Вот как выглядит цикл диспетчеризации с beads:
# See what's ready for work
bd list --status open
# Assign a task to an agent
bd update bb-a1b2 --claim --actor eng1
# Agent reads its assignment
bd show bb-a1b2
# Agent comments its plan before coding
bd comments add bb-a1b2 --author eng1 "PLAN:
1. Add endpoint at /api/users
2. Define UserResponse type in lib/types.ts
3. Write integration test
Files: server/api/users.ts (new), lib/types.ts (modify)
Test: curl localhost:3000/api/users returns 200 with JSON array"
# Agent finishes and comments what it did
bd comments add bb-a1b2 --author eng1 "DONE: /api/users endpoint live.
Returns paginated JSON. Added UserResponse type.
Verification:
1. curl http://localhost:3000/api/users → 200, JSON array
2. curl http://localhost:3000/api/users?page=2 → 200, second page
3. pnpm test → all passing
Commit: 8f3c2a1"
# Agent marks the task done
bd update bb-a1b2 --status closed
Каждый агент следует этому протоколу: забрать, спланировать, реализовать, прокомментировать DONE, обновить статус. Ветка комментариев каждой бусины становится полным аудит-трейлом: что произошло, почему и как проверить.
Зависимости предотвращают конфликтующую работу:
# Create a task that depends on another
bd create --title "Build user list component" \
--deps bb-a1b2 \
--description "Frontend component that calls /api/users. Blocked until API is live."
Зависимая задача остаётся заблокированной, пока bb-a1b2 не завершена. Ни один агент не возьмёт её преждевременно. Никто не потратит время на создание фронтенда для API, которого ещё не существует.
Команда bd list даёт снимок всего конвейера:
bd list --status in_progress
# Shows what every agent is actively working on
bd blocked
# Показывает задачи, ожидающие незавершённых зависимостей
bd list --status open --priority p1
# Shows the highest-priority work that's ready to start
Это заменяет ментальную модель, которую вы держали в голове. Состояние каждой задачи, текущая работа каждого агента, каждая цепочка зависимостей — всё запрашиваемо из командной строки.
Масштабирование видимости
CLI работает. Но в масштабе есть предел тому, сколько можно усвоить через bd list в терминале. Когда восемь агентов работают над тремя эпиками с семнадцатью открытыми задачами и дюжиной зависимостей, нужно видеть форму работы, а не просто список.
Этот пробел мы закрыли, создав Beadbox. Beadbox — это дашборд реального времени, который располагается поверх beads и показывает:
- Деревья эпиков с прогресс-барами, чтобы видеть прогресс каждой фичи по всем подзадачам
- Графы зависимостей, показывающие заблокированную работу до того, как она остановит конвейер
- Активность агентов — какой агент над чем работает, с их комментариями плана и выполнения в контексте
- Обновления в реальном времени — дашборд следит за базой данных beads и обновляется, когда агенты меняют статусы задач
Beadbox не заменяет CLI. Ваши агенты по-прежнему читают и пишут в beads через bd. Beadbox даёт общую картину, чтобы вы могли принимать решения: какой эпик отстаёт, какому агенту нужна помощь, где формируется узкое место.
Бесплатно во время бета-тестирования. Если вы строите подобные рабочие процессы, поставьте звезду Beadbox на GitHub.
С чего начать
Не нужно тринадцать агентов, чтобы получить пользу. Минимально жизнеспособная конфигурация:
- Два агента Claude Code в отдельных окнах tmux, каждый со своим CLAUDE.md, определяющим границы владения файлами.
- Список задач (даже текстовый файл подойдёт на этом масштабе), чтобы оба агента знали, над чем работают и что дальше.
- Протокол коммитов: оба агента коммитят часто и пуллят перед началом новой работы.
Когда это станет привычным, добавьте третьего агента для тестирования или документации. Затем рассмотрите агента-координатора. Затем внедрите beads для структурированного отслеживания задач. Масштабируйте систему, когда координационная боль нарастает, а не раньше.
Сложное — не инструменты. Сложное — сдвиг мышления: от «я использую ИИ-ассистента» к «я руковожу командой». Файлы CLAUDE.md, протоколы диспетчеризации, границы владения — это управленческие практики, а не конфигурационные файлы. Вы строите организацию, даже если члены команды работают на API-вызовах.
Начните с двух агентов и чётких границ. Всё остальное следует из этого.
