Подагенты в Claude Code: когда делить работу

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

Подагент и вторая сессия — это разные вещи

Слово «агент» в Claude Code означает два разных сценария, и их постоянно путают. Вторая сессия — это ещё один запущенный claude в соседнем окне: отдельный процесс, отдельная история, отдельная папка, и связывать их результаты приходится вам руками. Подагент живёт внутри одной сессии и подчиняется ей.

Три отличия, из которых следует всё остальное:

• Свой контекст. Обычный подагент стартует с чистого листа: он не видит вашей переписки, ранее прочитанных файлов и вызванных навыков. В его контекст попадают системный промпт из описания, ваш текст задания, файлы CLAUDE.md и снимок состояния git.
• Свой набор инструментов и прав. Подагенту можно оставить только чтение и поиск, и тогда он физически не сможет ничего изменить, даже если решит, что так будет лучше.
• Возврат результата внутрь сессии. Итог приходит прямо в основную беседу, а не в чужое окно, из которого его надо копировать.

Часть подагентов уже встроена. Explore ищет по коду, Plan собирает материал для плана — оба работают только на чтение и намеренно пропускают CLAUDE.md и git-статус, чтобы разведка была быстрой. General-purpose — универсальный исполнитель с полным набором инструментов. Эти трое запускаются сами, когда задача под них подходит, и большинство людей пользуются подагентами именно так, ни разу не заведя собственного.

Отдельный случай — форк: подагент, который наследует всю текущую беседу, системный промпт и инструменты основной сессии. Он вызывается командой /subtask и нужен ровно тогда, когда передавать контекст заново дороже, чем взять его целиком.

Независимые агенты на одном проекте — другая тема со своими проблемами: конкуренция за файлы, ваше внимание как узкое место, отдельные рабочие копии. Она разобрана в статье про несколько ИИ-агентов одновременно. Здесь речь только про деление работы внутри одной сессии. (Держать несколько таких сессий рядом удобнее в рабочем пространстве вроде VibeeCode, где терминалы с агентами лежат в одном окне, — но к подагентам это отношения не имеет.)

Как завести подагента

Подагент — это markdown-файл с YAML-заголовком. Заголовок описывает, кто это и что ему можно, тело файла становится его системным промптом.

---
name: security-reviewer
description: Проверяет изменения на уязвимости в безопасности
tools: Read, Grep, Glob, Bash
model: opus
---

Вы — инженер по безопасности. Проверьте код на инъекции (SQL, XSS,
командные), ошибки аутентификации и авторизации, секреты в коде,
небезопасную работу с данными. Указывайте конкретные строки и
предлагайте исправление.

Обязательных полей два: name — идентификатор строчными буквами через дефис, и description — описание того, когда именно к этому подагенту стоит обращаться. Второе важнее, чем кажется: по нему модель решает, делегировать ли задачу вообще. Расплывчатое описание означает, что подагент никогда не запустится сам.

Где лежит файл — тем и определяется область действия:

При совпадении имён побеждает определение из строки выше. Проектные подагенты кладут в .claude/agents/ и коммитят в репозиторий — тогда они есть у всей команды; личные живут в ~/.claude/agents/ и доступны везде.

Вызвать подагента можно тремя способами. Назвать его в обычном тексте («используй подагента code-reviewer для изменений в авторизации») — тогда решение делегировать остаётся за моделью. Выбрать через @ из подсказки — тогда запуск гарантирован. Или сделать его режимом всей сессии:

claude --agent code-reviewer

Тот же выбор фиксируется в .claude/settings.json для всего проекта:

{
  "agent": "code-reviewer"
}

Инструменты, модель и режим прав

Три необязательных поля определяют, во что обходится подагент и насколько он опасен.

tools — белый список. Если поле не указано, подагент наследует все доступные инструменты. Если указано tools: Read, Grep, Glob, Bash — он не сможет писать и править файлы. Есть и обратное поле disallowedTools — чёрный список, который применяется до белого. Ограничение набора инструментов — самый надёжный способ задать роль: подагенту-исследователю незачем уметь редактировать код, и запрет работает лучше просьбы в промпте.

model принимает псевдоним (sonnet, opus, haiku, fable), полный идентификатор модели или значение inherit, которое стоит по умолчанию и означает «та же модель, что в основной беседе». Порядок разрешения — переменная окружения CLAUDE_CODE_SUBAGENT_MODEL, затем параметр конкретного вызова, затем поле в описании, затем модель основной сессии. Документация прямо советует ставить model: haiku простым подагентам: механическая работа вроде выборки строк из лога не требует старшей модели.

permissionMode задаёт, как подагент обходится с разрешениями: default (спрашивать), acceptEdits, auto, dontAsk, bypassPermissions, plan. Здесь есть неочевидное правило: если родительская сессия работает в bypassPermissions или acceptEdits, её режим имеет приоритет, а в автоматическом режиме поле в описании подагента вообще игнорируется. То есть permissionMode — не способ сделать подагента строже, чем сессия, которая его запустила.

Есть и другие поля — maxTurns (потолок числа шагов), skills (навыки, загруженные в контекст сразу при старте), isolation: worktree (работа в отдельной рабочей копии git), background. Последнее стоит понимать: по умолчанию подагенты запускаются в фоне и не блокируют беседу, но фоновому подагенту достаётся урезанный набор встроенных инструментов. Если результат нужен немедленно, запуск будет на переднем плане.

Три роли, которые окупаются

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

Исследование по коду

Самый частый и самый выгодный случай. Вопрос «как у нас устроено обновление токена и есть ли готовые утилиты для OAuth» требует прочитать десятки файлов. В основной сессии эти файлы осядут в контексте целиком и будут отправляться с каждым следующим запросом; в подагенте они останутся в его контексте, а к вам вернётся ответ на вопрос. Формулировка простая: «используй подагентов, чтобы разобраться, как…». Несколько независимых вопросов можно раздать параллельно.

Ревью в отдельном контексте

Проверяющий, который видит только дифф и критерии, а не ход рассуждений автора. Про это — следующий раздел.

Проверка безопасности

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

Общее у трёх ролей — они самодостаточны. Задание формулируется один раз, результат помещается в короткий отчёт, уточнять по ходу ничего не нужно. Как только роль перестаёт обладать этими свойствами, подагент перестаёт быть удачной формой.

Почему ревью подагентом лучше, чем той же сессией

Просьба «перепроверь себя» почти не работает. Агент, написавший код, видел ход собственных рассуждений и уже объяснил себе, почему решение верное; та же цепочка приведёт его к тому же выводу. Подагент на ревью стартует с чистого контекста: ему достаются дифф и критерии, но не история, которая этот дифф породила. Он оценивает результат по собственным основаниям — и это единственная причина, по которой схема даёт что-то новое.

Ревьюеру нужно давать конкретику, а не «посмотри, всё ли хорошо»: что проверять, против чего сверять, что считать находкой.

Используй подагента: проверь дифф ограничителя запросов против PLAN.md.
Каждое ли требование реализовано, есть ли тесты на перечисленные крайние
случаи, не изменилось ли что-то за рамками задачи. Сообщай пробелы,
а не стилистические предпочтения.

В поставке для этого есть готовый инструмент: команда /code-review проверяет текущий дифф на ошибки в отдельном подагенте и возвращает находки прямо в сессию, а /security-review делает отдельный проход по безопасности. Ключевое преимущество перед ручным переносом замечаний между окнами — реализующая сессия получает пробелы сразу и может их закрыть и перепроверить без вашего участия в роли курьера.

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

Чем за это платят

У подагентов есть цена, и она не нулевая.

Расход. Подагент — это отдельное контекстное окно со своими входными и выходными токенами. Экономит он ваш основной контекст, а не общий расход: разведка по сорока файлам стоит примерно столько же, где бы она ни происходила, просто её стоимость не размазывается по всем последующим запросам основной беседы. Три параллельных подагента — это три полноценных потребителя лимита одновременно. Команда /usage на платных планах показывает разбивку недавнего расхода по навыкам, подагентам, плагинам и MCP-серверам — это самый быстрый способ увидеть, что именно съедает окно. Как устроены сами лимиты, разобрано в статье про лимиты Claude Code.

Время. Обычный подагент стартует с нуля и тратит первые шаги на то, чтобы сориентироваться — прочитать файлы, найти нужное место. Для короткой задачи этот разогрев дороже самой задачи.

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

Приёмка. Результат подагента приходит в виде уверенного отчёта, и это самая опасная его особенность. Вы не видели, как он работал: какие файлы прочитал, что запустил, на чём основан вывод. Отчёт «проверил, проблем нет» — не проверка, а утверждение. Требуйте того же, что от любого чужого результата: вывод команды, конкретные строки, дифф. Правило простое — код и выводы от подагента принимаются ровно так же строго, как код от постороннего человека, и ровно по тому же чек-листу.

Когда подагенты не нужны

Документация перечисляет случаи, в которых делегирование только мешает, и список честный:

• Задача требует диалога. Вы уточняете гипотезу каждые пару минут, смотрите на промежуточный вывод, меняете направление. Подагент этого не умеет по устройству.
• Фазы работы делят один контекст. Планирование, реализация и тесты опираются на одни и те же наблюдения. Пересказывать их в задании дороже, чем сделать всё на месте.
• Правка маленькая и точечная. Переименование, одна строка, добавление лога — запуск обходится дороже результата.
• Важна задержка. Когда ответ нужен сейчас, разогрев чистого контекста работает против вас.

Есть и подмена задачи. Если вы хотите не изоляции контекста, а повторяемой инструкции — «деплой по нашему чек-листу», «правила оформления API» — это навык, а не подагент: навык добавляет знание в текущий контекст, подагент выносит работу из него. Разница разобрана в статье про навыки Claude Code. А если нужна длинная независимая ветка работы со своим рабочим каталогом — это отдельная сессия, а не подагент.

Практическое правило: подагента заводят не тогда, когда задача сложная, а тогда, когда её промежуточный вывод вам не понадобится.

Итог: делить или нет

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