Я столкнулся с этим впервые, когда агент исследовал кодовую базу размером около 200 файлов в поисках всех мест, где обрабатывались токены. Он читал файл за файлом, делал заметки, возвращался, уточнял - и весь этот промежуточный мусор оседал в основном контекстном окне. К тому моменту, когда он добрался до ответа, контекст был забит до предела ненужными артефактами поиска. Субагенты решают эту проблему радикально: они получают собственное, полностью изолированное context window, выполняют работу в чистоте и возвращают только финальный результат в основной контекст.
Что такое субагент и почему это важно
Subagent - это изолированный экземпляр Claude Code с собственным контекстным окном. Когда основная сессия запускает субагента, тот получает чистый контекст, набор инструментов и конкретную задачу. Всё, что происходит внутри - запросы к файловой системе, поисковые итерации, промежуточные ошибки - остаётся внутри. В родительский контекст возвращается только структурированный вывод.
Это фундаментально отличается от Agent Teams - модели peer-to-peer координации, где несколько агентов работают в общем пространстве и видят контекст друг друга. Субагент полностью непрозрачен для parent-сессии в процессе работы.
Ключевое преимущество - контекстная экономия. В рамках context engineering изоляция промежуточных вычислений - один из столпов Six Pillars Framework. Субагенты реализуют этот принцип на уровне архитектуры: вместо того чтобы загрязнять основное context window исследовательским процессом, ты делегируешь его в изолированный экземпляр.
В моей практике оптимальный порог такой: если задача требует чтения больше десяти файлов или итеративного поиска по кодовой базе - делегируй субагенту. Parent-сессия сохранит контекст чистым и получит только то, что реально нужно.
Типология субагентов и когда их использовать
Claude Code предоставляет четыре встроенных типа субагентов, каждый со своим набором инструментов и назначением:
| Тип | Инструменты | Назначение |
|---|---|---|
| Bash | Только shell-команды | Скрипты, системные операции, CI-задачи |
| Explore | Файловая система + поиск | Исследование кодовой базы, ревью |
| Plan | Мышление + структурирование | Декомпозиция задач, архитектурные решения |
| General-purpose | Полный набор инструментов | Комплексные задачи без ограничений |
Помимо встроенных типов, skills позволяют определять специализированных субагентов через SKILL.md-файлы с параметром invocation: agent. Это on-demand context injection в форме агента: например, субагент “Senior Engineer” с набором правил code review или субагент “Product Manager” для оценки задач с точки зрения бизнес-требований.
Я использовал этот паттерн при работе над переносом монолита на микросервисы: одновременно запускал трёх специализированных субагентов - Product Manager оценивал, какие сервисы выделить в первую очередь по бизнес-приоритету, Senior Engineer анализировал зависимости и технический долг в существующем коде, второй инженер проверял покрытие тестами перед разделением. Каждый работал в своём чистом контексте, я получал три структурированных отчёта и принимал решение с полной картиной.
Когда НЕ использовать субагентов:
- Простые одношаговые задачи, где overhead запуска превысит выигрыш
- Задачи с плотной связанностью с текущим контекстом parent-сессии
- Ситуации, где результат требует немедленной итерации с parent
Routing rules в CLAUDE.md позволяют автоматизировать выбор типа субагента. Можно прописать правила вида “если запрос касается исследования архитектуры - использовать Explore”, и агент будет следовать им при каждой задаче.
Субагенты vs Agent Teams:
| Характеристика | Субагент | Agent Teams |
|---|---|---|
| Контекст | Полностью изолированный | Общее пространство |
| Координация | Parent - Child | Peer-to-peer |
| Прозрачность | Чёрный ящик в процессе | Взаимная видимость |
| Оптимально для | Параллельных независимых задач | Итеративной совместной работы |
Три архитектурных паттерна использования
Параллельные задачи
Несколько субагентов запускаются одновременно, каждый с собственным чистым контекстом. Реальный пример из моей работы: коммит затронул около 40 файлов в трёх модулях. Я запустил три субагента параллельно - один делал code review на паттерны и потенциальные баги, второй обновлял документацию по изменившимся интерфейсам, третий запускал интеграционные тесты. Все три отработали пока я пил кофе; parent-сессия получила три результата и я принял финальное решение без засорения контекста.
Выигрыш двойной: wall-clock time сокращается за счёт параллельности, context window parent не засоряется промежуточными шагами каждого субагента.
Последовательные задачи
Паттерн Explore - Plan - Implement - классический пример цепочки субагентов, где output одного становится input следующего. Explore-субагент исследует кодовую базу и возвращает структурированный отчёт об архитектуре. Plan-субагент получает этот отчёт, строит декомпозицию задачи. General-purpose субагент реализует конкретный план.
Каждый этап расширяет контекст локально - все артефакты исследования, все промежуточные размышления остаются изолированными. Parent-сессия видит только финальные outputs каждого этапа.
Этот паттерн естественно встраивается в систему compaction: субагент выполняет локальную микрокомпакцию своего контекста, затем инжектирует результат в parent через структурированный summary, соответствующий Compaction Contract.
Фоновые задачи
Ctrl+B переводит субагента в background, позволяя parent-сессии продолжать работу. TaskOutput tool используется для получения результатов позже, когда субагент завершит задачу.
Я регулярно так запускаю полную тестовую сюиту или статический анализ - параллельно с активной разработкой. Пока тесты идут в фоне, основная сессия пишет следующий кусок кода. Результат прилетает когда нужен.
Развёрнутый кейс: Code Review через Explore-субагент
Задача: проверить pull request на 60 файлов в сервисе авторизации. Если делать это в основном контексте, все прочитанные файлы, все промежуточные выводы, все поисковые запросы к кодовой базе остаются в context window. После ревью этот контекст засоряет дальнейшую работу или требует compaction.
Я запустил Explore-субагент с задачей “изучи изменения, верни структурированный отчёт с конкретными проблемами”. Субагент прочитал все нужные файлы, нашёл три потенциальных race condition в логике сессий - баги, которые я бы точно пропустил при беглом взгляде на 60-файловый диф - и применил MCP-инструменты только для этой конкретной задачи (tool search работает независимо в каждом субагенте). В parent вернулся только финальный отчёт. Весь исследовательский контекст был изолирован и исчез вместе с субагентом.
Ограничения, мифы и производительность
Ключевые ограничения и workarounds
| Ограничение | Причина | Workaround |
|---|---|---|
| Output limit 8192 токенов | Стандартный лимит генерации | Запись в файл, возврат пути + summary |
| Конкурентное редактирование | Конфликты при одновременном доступе | Разные файлы или последовательная обработка |
| Overhead запуска | Инициализация нового контекста | Батчить задачи, избегать создания сотен параллельных субагентов |
Лимит в 8192 токена вынуждает субагент структурировать результат: выбирать главное, отбрасывать промежуточное, возвращать только то, что нужно parent-сессии.
Миф: “Субагенты медленнее”
Интуиция подсказывает, что запуск отдельного экземпляра добавляет задержку. На практике всё наоборот.
Параллельные субагенты работают одновременно, поэтому wall-clock time для группы из трёх задач сопоставим со временем выполнения одной. Мой кейс с 40-файловым коммитом: три субагента закончили code review, обновление документации и тесты быстрее, чем занял бы один последовательный проход. Zach Wills в серии статей за август-сентябрь 2025 года подробно разбирает паттерны параллельного выполнения субагентов и подтверждает: параллельная специализированная архитектура заметно выигрывает у единственного агента с раздутым контекстом.
Дефолтные паттерны для быстрого старта
Routing Rule. Если размер входного контекста для задачи превышает условный порог (ориентируйся на 50KB входных данных) - используй Explore-субагент вместо прямого выполнения.
Parallel Pattern. Группы из 3-5 независимых задач естественно ложатся в параллельных субагентов. Главный критерий независимости: задачи не должны изменять одни и те же файлы.
Handoff Pattern. Последовательные этапы Explore - Plan - Implement - оптимальный паттерн для сложных задач с неизвестной архитектурой. Каждый субагент получает обогащённый контекст от предыдущего, но без его внутренних артефактов.
Как устроен контекст внутри каждого субагента - та же четырёхслойная структура окна, что и в основной сессии. Принципиальное отличие: субагент не страдает от compression-проблем parent. Если родительская сессия уже прошла через несколько циклов compaction и несёт груз сжатых summaries, субагент начинает с чистого листа.
Заключение
Субагенты - не просто техника параллелизма. Это стратегический инструмент управления контекстом, который меняет базовую архитектуру агентных систем.
Традиционная модель - один агент с большим контекстом, который постепенно заполняется, сжимается и деградирует. Субагентная модель - специализированная команда изолированных экземпляров, каждый из которых работает в чистом пространстве и передаёт только результат.
Если твой агент потребляет контекст неэффективно - много исследований, много итераций, мало реального кода в output - это сигнал перейти на субагентную архитектуру. Выдели исследовательские задачи в Explore-субагенты, декомпозиционные задачи в Plan-субагенты, долгие фоновые операции запускай через Ctrl+B.
Субагенты закрывают ту часть Six Pillars, которую невозможно решить ни через CLAUDE.md, ни через compaction, ни через MCP tool search: изоляцию самого процесса мышления от его результата.
Agent Teams, выпущенные в Opus 4.6 в феврале 2026 года, дают возможность координации напрямую между субагентами через peer-to-peer архитектуру - без hub-and-spoke через parent-сессию. Это отдельный паттерн для задач, где субагентам нужно обмениваться промежуточными результатами.