Agent Teams в Claude Code: ваш собственный отдел разработки из ИИ-агентов

Представьте: вы сидите перед терминалом, и у вас есть задача которую один человек делал бы неделю. Ревью огромного PR, параллельный рефакторинг нескольких модулей, расследование бага с пятью возможными причинами. А что если бы можно было просто сказать: «Эй, создай мне команду из пяти агентов, пусть разберутся»? Anthropic сделали именно это.

Agent Teams — экспериментальная фича Claude Code, которая позволяет запустить несколько независимых экземпляров Claude Code работающих как одна команда. С лидером, общим списком задач, системой сообщений между агентами и полноценной координацией. Давайте разбираться что это, как работает и зачем оно нам.

Источник: официальная документация Claude Code

Если вы уже работали с Claude Code, то знаете про субагентов (subagents). Это помощники которые запускаются внутри вашей сессии, делают работу и возвращают результат обратно. Классическая схема «начальник-подчинённый»: один агент раздает задачи, получает ответы, склеивает картину.

Но у субагентов есть фундаментальное ограничение — они не могут общаться друг с другом. Каждый субагент отчитывается только перед главным агентом. Если субагент A нашёл что-то критически важное для субагента B — информация должна пройти через «начальника». Это как если бы разработчики в офисе могли общаться только через тимлида. Без прямых чатов, без кулерных разговоров, ничего.

Agent Teams решают эту проблему. Каждый «тиммейт» (teammate) — это полностью независимый экземпляр Claude Code со своим контекстным окном, и они могут:

По сути субагенты — это «подай-принеси», а Agent Teams — полноценная распределённая команда с горизонтальной коммуникацией.

Сравнительная таблица из документации, но с нашими коментариями:

Начинайте с субагентов. Если чувствуете что задача требует «обсуждения» между исполнителями или параллельного исследования с разных сторон — переходите на Agent Teams. Как по мне, этот переход обычно становится очевиден когда вы ловите себя на мысли что хотите чтобы один агент «подсказал» другому.

Фича экспериментальная и по умолчанию выключена. Включаем через переменную окружения:

// settings.json { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }

Или просто в шелле:

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

После включения вы просто описываете задачу и команду на естественном языке. Никаких конфигов, YAML-файлов, деклараций ролей. Говорите Claude что вам нужно:

Я проектирую CLI-инструмент для трекинга TODO-комментариев в кодовой базе. Создай agent team, чтобы исследовать это с разных сторон: один тиммейт отвечает за UX, один за техническую архитектуру, один играет роль devil's advocate.

Дальше происходит вот что:

Терминал лида показывает всех тиммейтов и то над чем они работают. Переключение между ними через Shift+Up/Down.

Claude не создаст команду без вашего подтверждения. Даже если он сам считает что задача подходит для параллельной работы — сначала предложит и дождётся согласия.

Под капотом Agent Team — четыре компонента:

КомпонентРольTeam LeadОсновная сессия Claude Code. Создаёт команду, спавнит тиммейтов, координируетTeammatesОтдельные экземпляры Claude Code, каждый работает над своими задачамиTask ListОбщий список задач который видят все. Тиммейты берут и завершают задачиMailboxСистема сообщений для коммуникации между агентами

Данные команды хранятся локально:

Конфиг содержит массив members с именем, ID и типом каждого тиммейта. Тиммейты могут читать этот файл чтобы знать кто ещё в команде.

Зависимости между задачами разруливаются автоматически — когда тиммейт завершает задачу от которой зависят другие, заблокированные задачи разблокируются сами. Никакого ручного вмешательства.

Два варианта визуализации работы команды:

In-process — все тиммейты работают внутри вашего основного терминала. Переключение через Shift+Up/Down. Работает в любом терминале, без дополнительной настройки.

Split panes — каждый тиммейт получает свою панель. Видно всех одновремено, можно кликнуть в панель и взаимодействовать напрямую. Требует tmux или iTerm2.

По умолчанию стоит "auto" — если вы уже в tmux-сессии, будут сплит-панели, иначе in-process.

// settings.json { "teammateMode": "in-process" }

Или для одной сессии:

claude --teammate-mode in-process

Сплит-панели не работают в интегрированном терминале VS Code, Windows Terminal и Ghostty. Только tmux или iTerm2 с it2 CLI.

Ну а теперь самое интересное — как рулить этим оркестром.

Claude сам решает сколько тиммейтов спавнить, но можно указать явно:

Создай команду из 4 тиммейтов для параллельного рефакторинга этих модулей. Используй Sonnet для каждого тиммейта.

Для сложных или рискованных задач можно заставить тиммейта сначала составить план и дождаться одобрения от лида прежде чем начинать реализацию:

Создай тиммейта-архитектора для рефакторинга модуля аутентификации. Требуй утверждения плана перед любыми изменениями.

Как это работает:

Можно влиять на решения лида задавая критерии в промпте: «одобряй только планы с покрытием тестами» или «отклоняй планы которые модифицируют схему БД».

Бывает лид начинает сам реализовывать задачи вместо того чтобы ждать тиммейтов. Ну знакомо же — тимлид который сам пишет код вместо делегирования. Delegate Mode ограничивает лида только инструментами координации: спавн, отправка сообщений, управление задачами, шатдаун тиммейтов.

Включается через Shift+Tab после создания команды.

Каждый тиммейт — полноценная сессия Claude Code. Можно писать любому напрямую:

Общий таск-лист координирует работу. Задачи имеют три состояния: pending, in progress, completed. Задачи могут зависеть друг от друга — заблокированная задача не может быть взята пока зависимости не завершены.

Два способа распределения:

Захват задач использует файловую блокировку (file locking) чтобы избежать гонок когда несколько тиммейтов одновременно пытаются взять одну задачу. Честно говоря я сначала думал что тут будут проблемы, но нет — работает.

Тут начинается самое вкусное. Документация выделяет четыре сильных сценария.

Один ревьюер обычно «залипает» на одном типе проблем. Разделение по доменам гарантирует что безопасность, производительность и покрытие тестами получают одновременное внимание:

Создай agent team для ревью PR #142. Три ревьюера: - Один фокусируется на безопасности - Один проверяет влияние на производительность - Один валидирует покрытие тестами Пусть каждый проведёт ревью и отчитается.

Когда корневая причина неясна, один агент находит первое правдоподобное объяснение и останавливается. А что если сделать тиммейтов явно состязательными чтобы каждый не только исследовал свою теорию но и оспаривал чужие?

Пользователи жалуются, что приложение закрывается после одного сообщения вместо поддержания соединения. Создай 5 тиммейтов для исследования разных гипотез. Пусть они общаются друг с другом и пытаются опровергнуть теории друг друга, как в научной дискуссии. Обнови документ с выводами тем консенсусом, который сформируется.

Это на мой взгляд ключевой механизм. Последовательное расследование страдает от эффекта якоря (anchoring) — как только одна теория исследована, дальнейший анализ предвзят в её сторону. Несколько независимых исследователей которые активно пытаются опровергнуть друг друга, с гораздо большей вероятностью найдут реальную причину.

Каждый тиммейт владеет отдельным куском, не наступая друг другу на ноги. Тут всё просто.

Изменения которые затрагивают фронтенд, бэкенд и тесты одновременно — каждый слой за отдельным тиммейтом.

Тиммейты автоматически подгружают контекст проекта (CLAUDE.md, MCP-серверы, навыки), но не наследуют историю разговора лида. Поэтому включайте детали прямо в промпт при создании:

Создай тиммейта-ревьюера безопасности с промптом: "Проведи ревью модуля аутентификации в src/auth/ на предмет уязвимостей. Фокус на обработке токенов, управлении сессиями и валидации ввода. Приложение использует JWT в httpOnly cookies. Сообщи о проблемах с рейтингом серьёзности."

Слишком мелкие задачи — накладные расходы на координацию перевешивают пользу. Слишком крупные — тиммейты работают долго без контрольных точек и растёт риск впустую потраченых усилий. Нормальный размер — самодостаточные единицы с чётким результатом. Функция, тестовый файл, ревью.

Два тиммейта редактирующих один файл приводят к перезаписям. Разбивайте работу так чтобы каждый тиммейт владел отдельным набором файлов.

Проверяйте прогресс тиммейтов, перенаправляйте подходы которые не работают и синтезируйте результаты по мере поступления. Оставлять команду без присмотра надолго — риск потери усилий.

Если лид начинает сам делать задачи вместо ожидания тиммейтов, просто скажите: «Подожди пока тиммейты завершат свои задачи прежде чем продолжать».

Давайте без иллюзий. Agent Teams потребляют значительно больше токенов чем одна сессия. Каждый тиммейт — это отдельное контекстное окно и расход масштабируется с числом активных тиммейтов.

Для задач исследования, ревью и разработки новых фич дополнительные токены обычно окупаются. Для рутины — одна сессия будет экономичнее. Тут нужно прикидывать по ситуации.

Что нужно иметь в виду:

Agent Teams — это реально свежий подход к работе с ИИ-агентами. Вместо одного «суперагента» или дерева «начальник-подчинённые» мы получаем горизонтальную команду, которая может обсуждать, спорить и координироваться самостоятельно.

Основное:

Фича экспериментальная, есть шероховатости, но направление крайне интересное. По сути Anthropic дали нам возможность развернуть мини-отдел разработки прямо в терминале. Окей, пока он глючит и иногда забывает закрыть за собой tmux-сессии но концепт мощный.

Если хотите попробовать — полная документация здесь. А для сравнения с другими подходами к параллельной работе стоит глянуть документацию по субагентам и Git worktrees.