Как я собираю команду агентов в Claude Code за 7 шагов
Я раньше работал с Claude Code как с одним умным чатом. Сначала просил написать код, потом сам переключался на ревью, потом на тесты, потом на pull request, потом на документацию. Все задачи шли по очереди, хотя часть из них не зависит друг от друга.
Сейчас я собираю под задачу небольшую команду агентов. Один агент делает backend, второй - frontend, третий пишет тесты, четвертый проверяет безопасность и качество. Я не отдаю им контроль над проектом целиком. Я задаю цель, границы, бюджет и правила, а потом собираю результат.
Вот как я настраиваю такую схему в 7 шагов.
Шаг 1. Разобраться с тремя уровнями агентов
Перед тем как запускать команду, я сначала выбираю правильный уровень параллельной работы. В Claude Code есть три разных подхода, и они решают разные задачи.
Уровень 1: Subagents
- Запускаются внутри текущей сессии.
- Возвращают результат обратно в основной контекст.
- Не общаются друг с другом напрямую.
- Лучше всего подходят для повторяемых задач: ревью, тесты, документация, поиск по коду.
- Я отношусь к ним как к исполнителям, которым выдаю короткое техническое задание.
Уровень 2: Agent View
- Показывает все агентные сессии на одном экране.
- Позволяет запускать задачи, смотреть прогресс и подключаться к нужной сессии.
- Фоновые сессии продолжают жить даже после закрытия терминала.
- Хорошо подходит для 3-10 независимых задач.
- Для меня это панель управления живыми рабочими сессиями.
Уровень 3: Agent Teams
- Один lead-агент координирует участников.
- Участники могут обмениваться сообщениями друг с другом.
- У команды есть общий список задач.
- Лучше всего подходит для фич с несколькими файлами, слоями и зависимостями.
- Это уже не набор отдельных чатов, а маленькая рабочая группа.
Большинство останавливается на первом уровне. Я использую третий уровень, когда задача действительно выигрывает от параллельной работы.
Шаг 2. Включить Agent Teams
Agent Teams пока экспериментальная возможность, поэтому я включаю ее явно. Сначала проверяю версию Claude Code:
claude --version
Нужна версия Claude Code 2.1.32 или новее. Затем включаю режим команд:
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Чтобы не включать это каждый раз вручную, добавляю переменную в ~/.zshrc на macOS или в ~/.bashrc на Linux:
# Добавьте в ~/.zshrc или ~/.bashrc export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Другой вариант - прописать переменную через настройки Claude Code:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
Шаг 3. Написать первый запрос для команды
Главное отличие от обычного запроса к модели: я описываю весь проект и позволяю lead-агенту разложить работу на части. Не надо микроменеджить каждый шаг, но нужно явно задать роли и результат.
Мне нужно собрать систему аутентификации пользователей. Запусти отдельных агентов для следующих частей: 1. Серверная часть: создай маршруты Express.js для входа, регистрации и обновления токена 2. Клиентская часть: собери формы входа и регистрации на React с валидацией 3. Тесты: напиши интеграционные тесты для всех точек доступа аутентификации 4. Ревью: проверь весь код, созданный другими агентами, на проблемы безопасности
После этого lead-агент разбивает задачу, назначает роли и запускает участников. Каждый участник работает в своем контекстном окне. Я вижу, какие агенты активны и над чем каждый сейчас работает.
Если я пишу такой запрос для реального репозитория, я добавляю больше конкретики: файлы, модули, ограничения по стеку, критерии готовности и список проверок, которые должны пройти перед финальным отчетом.
Шаг 4. Развести модели, чтобы не сжечь бюджет
Параллельная команда легко начинает тратить токены в несколько раз быстрее. Если запустить пять тяжелых агентов одновременно, стоимость растет почти линейно.
Моя схема такая: lead-агент работает на сильной модели, потому что ему нужно держать архитектуру, зависимости и итоговую сборку. Участники получают более дешевую модель для сфокусированного исполнения.
# Ведущий агент: Opus, потому что он отвечает за архитектуру # Участники: Sonnet, потому что они выполняют узкие задачи export CLAUDE_CODE_SUBAGENT_MODEL="claude-sonnet-4-5-20250929"
Для Agent Teams я также прямо указываю модель участников в запросе или проверяю Default teammate model в /config. Идея не в том, чтобы ухудшить качество, а в том, чтобы не использовать самую дорогую модель там, где задача уже хорошо ограничена.
Шаг 5. Управлять всем через Agent View
Когда команда запущена, я открываю панель:
claude agents
Она показывает все сессии и их состояние. Это особенно полезно, когда backend уже почти готов, frontend в процессе, тесты ждут зависимости, а ревью не должно стартовать слишком рано.
┌─────────────────────────────────────────────┐ │ Agent View │ ├──────────┬──────────┬───────────────────────┤ │ Сервер │ Клиент │ Тесты │ Ревью │ │ ██████░░ │ ████░░░░ │ ░░░░░░░░░ │ ждет │ │ 72% │ 48% │ в очереди │ зависим. │ ├──────────┴──────────┴───────────────────────┤ │ > отправить новую задачу │ └─────────────────────────────────────────────┘
- отправить новую задачу команде;
- посмотреть прогресс любого агента, не прерывая его работу;
- подключиться к агенту, если ему нужен ввод;
- закрыть ноутбук и вернуться позже, потому что фоновые сессии продолжают жить.
Для меня это меняет саму механику работы: я не сижу в одном чате и не жду очередного ответа. Я слежу за несколькими рабочими потоками и вмешиваюсь только там, где нужно мое решение.
Шаг 6. Решить, когда команда не нужна
Не каждая задача заслуживает команды агентов. Если использовать тяжелую оркестрацию для мелочей, я просто трачу время и токены.
Один запрос, правка одного файла -> Обычная сессия Claude Code. Агенты не нужны. 3 независимые задачи без зависимостей -> Agent View. Запустить все 3, проверить результат после завершения. Повторяемый процесс: ревью, тесты, документация -> Subagents с YAML-конфигурацией. Один и тот же подход каждый раз. Функция на несколько файлов с зависимостями -> Agent Teams. Lead-агент координирует, участники работают вместе. Ночная разборка накопившихся задач -> Headless mode с лимитом --max-budget-usd.
Неправильный режим оркестрации вреден в обе стороны. Независимым задачам не нужна координация Agent Teams. А задачи с зависимостями не стоит запускать как изолированные сессии в Agent View, если потом их придется вручную склеивать.
Шаг 7. Поставить ограничения до запуска
Когда несколько агентов работают параллельно, несколько вещей могут пойти не так одновременно. Поэтому я заранее ограничиваю разрешения.
{
"permissions": {
"allow": [
"Read", "Glob", "Grep", "LS", "Edit",
"Write(src/**)", "Write(tests/**)",
"Bash(npm test *)", "Bash(npx tsc *)",
"Bash(git add *)", "Bash(git commit *)"
],
"deny": [
"Read(**/.env*)", "Read(**/.ssh/**)",
"Bash(rm -rf *)", "Bash(sudo *)",
"Bash(git push *)", "Bash(npm publish *)"
],
"defaultMode": "acceptEdits"
}
}
Я разрешаю чтение проекта, правки в src/** и tests/**, запуск тестов и проверку TypeScript. Я запрещаю чтение секретов, доступ к .ssh, опасное удаление, sudo, git push и npm publish.
Отдельно я ставлю бюджетный лимит для командных запусков:
claude -p "собери систему аутентификации" --max-budget-usd 15.00
Если представить 5 агентов примерно по 3 доллара, получается общий потолок 15 долларов. Это не дает одному runaway-запуску незаметно съесть весь бюджет.
Полная настройка, которую можно скопировать
Переменные окружения
# Добавьте в ~/.zshrc или ~/.bashrc export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 export CLAUDE_CODE_SUBAGENT_MODEL="claude-sonnet-4-5-20250929" export CLAUDE_CODE_DEFAULT_EFFORT=high export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1
Шаблон запроса для команды
Мне нужно [опишите всю функцию]. Запусти отдельных агентов: 1. [Роль 1]: [конкретная задача с файлами/модулями] 2. [Роль 2]: [конкретная задача с файлами/модулями] 3. [Роль 3]: [конкретная задача с файлами/модулями] 4. Ревью: проверь весь код на [ошибки/безопасность/стиль] Каждый агент работает в своем контексте. Координируй работу через общий список задач. Отмечай зависимости до запуска задач, которые от них зависят.
Ограничения в settings.json
{
"permissions": {
"allow": ["Read", "Glob", "Grep", "Edit", "Write(src/**)", "Write(tests/**)"],
"deny": ["Read(**/.env*)", "Bash(rm -rf *)", "Bash(git push *)"],
"defaultMode": "acceptEdits"
}
}
Как выглядит разница до и после
ДО (один агент): - По одной задаче за раз - Вы пишете, проверяете, тестируете и коммитите все последовательно - Функция из 4 частей занимает целый день - Контекст раздувается, пока вы переключаетесь между задачами ПОСЛЕ (команда агентов): - 4 агента работают параллельно - Серверная часть, клиентская часть, тесты и ревью идут одновременно - Та же функция готова за 2 часа - У каждого агента чистый сфокусированный контекст - Вы проверяете и объединяете результаты
Инструмент тот же. Подписка та же. Разница в том, что я включаю командный режим и формулирую задачу как работу для нескольких агентов, а не как один длинный запрос к одному чату.
Я все равно остаюсь финальным ревьюером. Я читаю diff, прогоняю тесты, смотрю крайние случаи и решаю, что попадет в main. Но черновая параллельная работа больше не стоит в одной очереди.
Короткий вывод
Я использую Agent Teams только там, где работа действительно делится на части. Сначала выбираю правильный уровень, затем задаю роли, модель, бюджет, ограничения и критерии готовности. После этого команда агентов может делать backend, frontend, тесты и ревью одновременно, а я управляю результатом.