Привет, Хабр! У всех, кто плотно работает с Claude Code в 2026 году, постоянно возникает одна и та же ситуация: сессия начинается с чистого контекста, разработчик прогружает CLAUDE.md, открывает несколько файлов, обсуждает план рефакторинга, и через час контекст забит на 70%.
Каждый следующий запрос ассистент обрабатывает медленнее, качество ответов падает, потому что модель пытается удерживать в внимании сорок файлов одновременно.
В апреле 2026 Anthropic выпустила механизм subagents, который решает эту проблему через делегирование. Месяц спустя они докрутили его до Dynamic Workflows с fan‑out на сотни параллельных агентов и Performance Outcomes для автоматической оценки результата.
Что такое subagent на уровне реализации
Subagent — это отдельный экземпляр Claude, который запускается из основной сессии и работает независимо. У него собственное контекстное окно, собственный системный промпт, собственный allowlist инструментов, опционально собственная модель. Основной (parent) агент видит только финальный summary, который вернул subagent, и не пускает в свой контекст ни один из промежуточных шагов исследования или рассуждений.
Технически subagent — это markdown‑файл с YAML‑frontmatter, лежащий в .claude/agents/<name>.md для проектного скопа или ~/.claude/agents/<name>.md для пользовательского. Никакого SDK, никакой регистрации, никакого компилируемого артефакта: положили файл в нужную директорию, перезапустили сессию, агент доступен. Claude Code обнаруживает его автоматически при старте.
Минимальный пример выглядит так:
--- name: code-reviewer description: Senior code reviewer. Use immediately after writing or modifying code. tools: Read, Grep, Glob model: sonnet --- You are a senior code reviewer focused on quality, security, and maintainability. When reviewing changes: 1. Read the diff carefully and identify modified files 2. Check for security issues (input validation, secrets, auth) 3. Look for performance problems (N+1 queries, memory leaks) 4. Verify error handling and edge cases 5. Suggest concrete improvements with code examples Return your review as: - Summary (2-3 sentences) - Critical issues (must fix before merge) - Suggestions (nice to have) - LGTM-points (what's done well)
Frontmatter содержит четыре основных поля. name — это идентификатор, по которому агент вызывается. description — текст, по которому parent‑агент решает, делегировать ли задачу этому subagent. tools — allowlist инструментов, к которым у subagent есть доступ. model — конкретная модель для запуска (sonnet, opus, haiku).
Тело файла после frontmatter это полностью системный промпт subagent.
Как parent решает, делегировать или нет
Claude Code использует description каждого зарегистрированного subagent как сигнал для роутинга. Когда parent встречает задачу, он сравнивает её намерение с описаниями всех доступных subagents и выбирает подходящего. Это та же логика, которая определяет, какой tool вызывать: модель читает описания, выбирает наиболее подходящее.
Из этого следует практическое правило: description пишется не для людей, а для модели. Конкретно, в активной форме, с триггерами на использование. «Use immediately after writing or modifying code» лучше работает, чем «Reviews code quality». «Use when the user asks about database performance issues» лучше, чем «Database expert».
Можно и вручную форсировать вызов конкретного subagent через директиву @code-reviewer в чате или через флаг claude --agent code-reviewer в shell. Юзабельно, когда автоматическое делегирование не срабатывает, или когда нужно явно протестировать один subagent изолированно.
В Claude Code есть три встроенных subagent, которые работают по умолчанию без всякой конфигурации.
Explore— это быстрый read‑only агент на Haiku для поиска и анализа кода. Запрещены Write и Edit, чтобы случайно ничего не мутировал.Planиспользуется в plan mode для сбора контекста перед написанием плана.general-purpose— это catch‑all для сложных multi‑step задач, в которые не вписывается ни один специализированный subagent.
Как ограничивать tools и почему это важно
Каждый subagent может получить полный набор инструментов parent‑сессии, но в production это плохая идея. Принцип наименьших привилегий применяется здесь точно так же, как в любой security‑чувствительной системе.
Поле tools — это allowlist: если оно задано, subagent видит только перечисленные инструменты. Поле disallowedTools — denylist, который вычитается из всего, что было бы доступно. Если заданы оба, сначала применяется denylist, потом allowlist резолвится против оставшегося.
Комбинации tools под разные задачи:
# Read-only auditor: только чтение и поиск tools: Read, Grep, Glob # Bug fixer: чтение, правка, выполнение тестов tools: Read, Edit, Bash, Grep, Glob # Documentation generator: добавляем web для цитирования tools: Read, Write, WebFetch, WebSearch # Database query validator: Bash для миграций tools: Read, Edit, Bash # плюс PreToolUse hook, блокирующий деструктивные SQL операции
Как‑то читал о кейсе, где refactor‑architect subagent с полным доступом к Bash решил «протестировать» свой рефакторинг через git reset и пересборку. В результате стёр 40 минут несохранённой работы в parent‑сессии. С тех пор практика: каждый subagent получает явный tools allowlist, без исключений.
Дополнительный уровень защиты дают session‑level permissions в .claude/settings.json. Там можно задавать bash‑pattern allow и deny правила на уровне всей сессии.
Паттерны оркестрации: sequential, parallel, fan‑out
Subagents можно вызывать тремя основными способами, и выбор паттерна напрямую влияет на стоимость и время выполнения.
Sequential (последовательный) — parent ждёт результата от первого subagent, использует его для запуска следующего. Подходит для конвейерных задач. Каждый этап работает с выходом предыдущего, нельзя начать тесты до того, как написан код.
Parallel (параллельный) — parent запускает несколько независимых subagents одновременно, ждёт результаты от всех. Подходит для задач, где работа естественно делится на независимые куски: поиск в кодовой базе по нескольким направлениям одновременно, генерация тестов и документации параллельно с тем, как идёт code review. Время сокращается в несколько раз, токены тратятся пропорционально количеству агентов плюс координационный overhead.
Fan‑out (веерный) — массивный параллельный запуск десятков или сотен subagents для покрытия большого пространства задач. Например, прогон бенчмарка по 80 комбинациям модель‑промпт, проверка кода в 200 микросервисах одним security‑агентом, генерация миграций под каждую таблицу базы данных.
Для повседневной работы оптимум 3–5 параллельных subagents. Дальше parent тратит больше времени на оркестрацию summaries, чем экономит на параллелизме. Dynamic Workflows нужны только когда задача реально fan‑out по природе.
Пример композиции в виде ship‑it pipeline:
--- name: ship-it description: End-to-end feature shipping. Spec → implement → test → review → PR. subagents: - spec-writer - implementer - test-writer - code-reviewer - pr-author parallel: [test-writer, code-reviewer] --- Read the feature brief from $1. Spawn spec-writer to produce a specification. Hand the spec and the codebase to implementer. After implementation, spawn test-writer and code-reviewer in parallel. Pass test results and review comments to pr-author.
Здесь spec‑writer и implementer работают sequential (нельзя писать код без спеки), а test‑writer с code‑reviewer параллельно после implementer (оба анализируют один и тот же диф, не зависят друг от друга), потом pr‑author объединяет результаты.
Когда subagent НЕ нужен
Subagent — это тяжёлый механизм. Каждый запуск — это новый контекст, новый системный промпт, round‑trip overhead. Бездумное использование разоряет бюджет на токены: subagent‑heavy workflow расходует примерно в 7 раз больше токенов, чем одиночная сессия для той же задачи.
Skill уместнее subagent, когда нужно научить агента конкретной технике без изоляции контекста. Skill — это набор инструкций, который загружается в основной контекст по запросу, без отдельного экземпляра модели. «Объясни код с диаграммой» лучше делать через skill, чем через subagent.
Tool call уместнее subagent, когда задача детерминирована и не требует размышлений. Запустить тесты, получить вывод линтера, сделать git status — всё это работа для bash‑tool, а не для отдельного агента.
Hook уместнее subagent, когда нужно enforce правило перед или после действия. SubagentStop hook проверяет, что тесты прошли и в дифе нет секретов, до того как parent примет результат обратно. Hook — это deterministic‑код, который не галлюцинирует.
Anthropic в документации формулирует правило коротко: Skill учит «как», Hook enforces «правило», Subagent изолирует «работу». Если задача про «как сделать X» — skill. Если про «нельзя делать Y» — hook. Если про «эту тяжёлую штуку нужно делать в отдельном контексте, чтобы не загрязнять основной» — subagent.
Стоимость и метрики
Контролировать стоимость можно несколькими способами.
CLAUDE_CODE_SUBAGENT_MODEL environment variable форсирует всех subagents в сессии на одну модель. Полезно для cost ceiling: все агенты ходят на Haiku вместо Sonnet, общая стоимость падает в разы при некотором падении качества. Useful для compliance‑сценариев, где нельзя использовать топовые модели для определённых задач.
Модель в frontmatter конкретного subagent позволяет указать дешёвую модель для read‑only задач. Code reviewer с read‑only‑доступом отлично работает на Haiku и стоит копейки. Implementer с критичной задачей логично запускать на Opus, который стоит дороже, но точнее.
Параллельность всегда удорожает в линейной зависимости от количества агентов: каждый агент перечитывает свой системный промпт и контекст. Sequential pipeline дешевле, чем parallel fan‑out на тех же задачах.
Метрики, которые имеет смысл собирать в команде:
Acceptance rate того, что предложил subagent (сколько процентов попало в commit).
Cost per task для разных типов задач (refactor, review, test generation).
Time savings vs manual: сравнение времени с subagent и без.
Failure rate: сколько subagent‑результатов отвергается parent или человеком.
Хорошие subagents для копирования в свой проект
Несколько subagent‑шаблонов, которые работают на самых разных проектах и стоит сразу положить в .claude/agents/.
code‑reviewer — read‑only ревьюер на Haiku, который проверяет каждый PR на security, performance, style. Tools: Read, Grep, Glob.
security‑auditor — специализированный ревьюер на Sonnet или Opus, который смотрит только на OWASP‑категории уязвимостей. Tools: Read, Grep, WebSearch (для проверки CVE).
test‑writer — генератор unit и integration тестов под изменения. Tools: Read, Write, Bash (для запуска тестов).
migration‑architect — для миграций между фреймворками или версиями. Tools: Read, Edit, Bash, WebFetch (для чтения upgrade guides).
doc‑generator — генератор README, API docs, inline comments. Tools: Read, Write, WebFetch.
explorer‑cheap — кастомная замена встроенному Explore с дополнительными инструкциями под конкретный проект. Tools: Read, Grep, Glob, model: haiku.
Все эти агенты прекрасно расшариваются между проектами через git: положили в .claude/agents/, закоммитили, вся команда работает с одинаковыми subagents. Это превращает agent configuration в part of the codebase.
Что попробовать у себя
Минимальный план внедрения subagents в существующий workflow занимает пару часов.
Установить Claude Code 2026.06 или новее (с поддержкой Dynamic Workflows).
Создать
.claude/agents/директорию в репозитории.Положить один code‑reviewer subagent из примера выше, попробовать пару дней.
Замерить acceptance rate и cost per session за первую неделю.
Добавить второй subagent под другую частую задачу (test‑writer или security‑auditor).
Через две недели использования закоммитить лучшие subagents в репозиторий, расшарить с командой.
Включить SubagentStop hook для enforcement тестов и линтера перед интеграцией результатов.
После этого workflow становится принципиально другим: parent‑сессия используется как orchestrator, который держит общий план, а тяжёлая работа уходит в специализированные subagents. Контекст основной сессии остаётся чистым, разработчик видит понятные summaries вместо потоков raw output, расходы на токены прогнозируемы.
Я бы начинал не с fan‑out на сотню агентов, а с более приземлённой задачи: научиться собирать с ИИ небольшой, но рабочий цифровой продукт — с понятной идеей, логикой, интерфейсом и проверкой гипотезы. Для этого подойдёт курс «Вайб‑кодинг: создание цифровых продуктов с ИИ»: он как раз про практическую сборку продуктов с помощью ИИ‑инструментов.
Если же интересен именно Claude Code, 21 июля в 20:00 пройдет открытый урок «Разработка ИИ‑приложений с Claude Code». На нём разберем, как использовать инструмент в инженерном workflow: дробить задачи, работать с кодом и доводить результат до состояния, с которым можно жить дальше.
А в ваших командах уже применяют subagents в Claude Code или вы пока ограничиваетесь одной сессией? Поделитесь своим опытом в комментариях.
