# Claude Code для команды: как настроить субагентов и общий ИИ-суперагент

> AI Release · @ai_release1 · https://ai-release.net/guides/claude-code-dlya-komandy-kak-nastroit-subagentov-i-obsc.html

Claude Code становится командным инструментом, когда у проекта появляются общие настройки и роли. Субагенты и общий ИИ-суперагент помогают распределить задачи так, чтобы каждый участник команды работал по одним правилам.

## TL;DR

- Субагент — это отдельный «специалист» с собственным контекстом, набором инструментов и инструкций, которому главный агент делегирует задачу.
- Общий ИИ-суперагент в команде строится на единых правилах проекта: где хранить стандарты, как называть роли и что считается «готово».
- Настройка субагентов — это обычные текстовые файлы в репозитории, поэтому они проходят через код-ревью как любая другая правка.
- Главная выгода — предсказуемость: один и тот же запрос даёт одинаковый результат у всех разработчиков.
- Главный риск — расползание инструкций, поэтому за изменениями в конфигурации агентов стоит следить так же строго, как за кодом.

## Что такое субагенты в Claude Code

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

Смысл в разделении труда. Главный агент держит общую картину задачи, а субагент занимается одним делом: ревью диффа, разбор логов, генерация тестов, миграции. Контекст субагента не засоряет основной диалог.

Для команды это важно по простой причине: роль описывается один раз и лежит в репозитории. Новый разработчик не изобретает промпты заново, а подключается к уже готовому набору.

## Как выглядит общий ИИ-суперагент

«Супер-агент» — это не отдельная модель, а сборка из правил проекта и набора ролей. Он отвечает на вопрос: что агент знает о нашем проекте и к кому он обращается за каждым типом задач.

Обычно такая сборка состоит из трёх слоёв:

- общие правила проекта — стиль кода, стек, запреты, определение «готово»;
- роли-субагенты — каждая со своей зоной ответственности;
- внешние подключения — доступ к документации, трекеру, внутренним сервисам.

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

Кому какую модель отдавать под конкретную роль — отдельный вопрос. Полезно заранее свериться со [сравнением ИИ-ассистентов](https://ai-release.net/guides/sravnenie-ii-assistentov.html?utm_source=tg&utm_medium=channel&utm_campaign=guide_inline&utm_content=guide_to_guide), чтобы не переплачивать за тяжёлую модель там, где хватает лёгкой.

## Настройка: структура и пример конфига

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

Пример фрагмента настроек роли:

```yaml
name: code-reviewer
description: Проверяет дифф перед мержем и ищет регрессии
tools: Read, Grep, Glob
model: inherit
```

Разбор полей:

- `name` — короткое имя роли, по нему её вызывает главный агент;
- `description` — когда именно эту роль нужно подключать;
- `tools` — что роли разрешено делать; лишние права лучше не выдавать;
- `model` — какая модель используется, если команда хочет управлять стоимостью.

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

## Чек-лист внедрения в команду

- [ ] Завести общий файл правил проекта и договориться, что в него попадает.
- [ ] Описать первые 3–5 ролей под самые частые задачи команды.
- [ ] Ограничить каждой роли список инструментов по принципу минимальной необходимости.
- [ ] Добавить файлы агентов в код-ревью наравне с обычным кодом.
- [ ] Зафиксировать, какие действия агент делает сам, а какие согласует с человеком.
- [ ] Прогнать один и тот же сценарий у двух разработчиков и сравнить результат.

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

## Общие стандарты и безопасность

Главный источник проблем в командной настройке — расхождение версий инструкций. У одного разработчика роль обновлена, у другого нет, и агенты ведут себя по-разному.

Лечится это дисциплиной: изменения в правилах и ролях идут через те же ветки и ревью, что и код. Тогда история изменений видна, а откат занимает минуты.

Отдельно стоит проговорить границы. Агент не должен получать доступ к секретам, продакшен-данным и внешним сервисам, если это не согласовано с командой. Права выдаются роли, а не «на всякий случай».

И третье — единый способ оценивать результат. Если у команды нет общего определения «задача сделана», субагенты будут закрывать задачи по-разному. Помогает короткий чек-лист приёмки, который лежит рядом с правилами проекта.

Если команда только выбирает инструменты под такие сценарии, пригодится [подробное сравнение ассистентов](https://ai-release.net/guides/sravnenie-ii-assistentov.html?utm_source=tg&utm_medium=channel&utm_campaign=guide_inline&utm_content=guide_to_guide) — там видно, чем отличаются подходы разных моделей.

## FAQ

**Что такое субагент в Claude Code?**
Это отдельная роль с собственным контекстом, инструментами и инструкциями, которой главный агент делегирует задачу. Роль описывается текстовым файлом в проекте.

**Чем субагент отличается от обычного запроса к агенту?**
Субагент работает в изолированном контексте и с ограниченным набором инструментов, а обычный запрос выполняется в основном диалоге. За счёт этого субагента проще переиспользовать и контролировать.

**Как выбрать роли для команды?**
Начните с самых частых задач: ревью, тесты, разбор логов, работа с документацией. Опишите 3–5 ролей, а дальше расширяйте набор по мере необходимости.

**Нужно ли хранить настройки агентов в репозитории?**
Да, это основной способ сделать поведение агентов одинаковым для всей команды. Тогда настройки проходят код-ревью, а изменения можно откатить.
