---
title: "Субагенты — изолированные контекстные окна"
description: "Как субагенты в Claude Code защищают основной контекст от загрязнения, три архитектурных паттерна использования и практические кейсы"
url: "https://ifonin.ru/blog/subagenty-izolirovannye-kontekstnye-okna/"
date: 2026-03-18
tags: ["claude-code","context-engineering","subagents","ai-tools"]
---

# Субагенты — изолированные контекстные окна

Я столкнулся с этим впервые, когда агент исследовал кодовую базу размером около 200 файлов в поисках всех мест, где обрабатывались токены. Он читал файл за файлом, делал заметки, возвращался, уточнял - и весь этот промежуточный мусор оседал в основном контекстном окне. К тому моменту, когда он добрался до ответа, контекст был забит до предела ненужными артефактами поиска. Субагенты решают эту проблему радикально: они получают собственное, полностью изолированное context window, выполняют работу в чистоте и возвращают только финальный результат в основной контекст.

## Что такое субагент и почему это важно

Subagent - это изолированный экземпляр Claude Code с собственным контекстным окном. Когда основная сессия запускает субагента, тот получает чистый контекст, набор инструментов и конкретную задачу. Всё, что происходит внутри - запросы к файловой системе, поисковые итерации, промежуточные ошибки - остаётся внутри. В родительский контекст возвращается только структурированный вывод.

Это фундаментально отличается от Agent Teams - модели peer-to-peer координации, где несколько агентов работают в общем пространстве и видят контекст друг друга. Субагент полностью непрозрачен для parent-сессии в процессе работы.

Ключевое преимущество - [контекстная экономия](/blog/context-engineering-novaya-paradigma/). В рамках [context engineering](/blog/context-engineering-novaya-paradigma/) изоляция промежуточных вычислений - один из столпов Six Pillars Framework. Субагенты реализуют этот принцип на уровне архитектуры: вместо того чтобы загрязнять основное context window исследовательским процессом, ты делегируешь его в изолированный экземпляр.

В моей практике оптимальный порог такой: если задача требует чтения больше десяти файлов или итеративного поиска по кодовой базе - делегируй субагенту. Parent-сессия сохранит контекст чистым и получит только то, что реально нужно.

## Типология субагентов и когда их использовать

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

| Тип | Инструменты | Назначение |
|-----|-------------|------------|
| **Bash** | Только shell-команды | Скрипты, системные операции, CI-задачи |
| **Explore** | Файловая система + поиск | Исследование кодовой базы, ревью |
| **Plan** | Мышление + структурирование | Декомпозиция задач, архитектурные решения |
| **General-purpose** | Полный набор инструментов | Комплексные задачи без ограничений |

Помимо встроенных типов, [skills](/blog/claudemd-persistentnaya-pamyat-proekta/) позволяют определять специализированных субагентов через 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](/blog/claudemd-persistentnaya-pamyat-proekta/) позволяют автоматизировать выбор типа субагента. Можно прописать правила вида "если запрос касается исследования архитектуры - использовать 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](/blog/compaction-tryokhsloynaya-sistema-szhati/): субагент выполняет локальную микрокомпакцию своего контекста, затем инжектирует результат в parent через структурированный summary, соответствующий Compaction Contract.

### Фоновые задачи

Ctrl+B переводит субагента в background, позволяя parent-сессии продолжать работу. TaskOutput tool используется для получения результатов позже, когда субагент завершит задачу.

Я регулярно так запускаю полную тестовую сюиту или статический анализ - параллельно с активной разработкой. Пока тесты идут в фоне, основная сессия пишет следующий кусок кода. Результат прилетает когда нужен.

**Развёрнутый кейс: Code Review через Explore-субагент**

Задача: проверить pull request на 60 файлов в сервисе авторизации. Если делать это в основном контексте, все прочитанные файлы, все промежуточные выводы, все поисковые запросы к кодовой базе остаются в context window. После ревью этот контекст засоряет дальнейшую работу или требует compaction.

Я запустил Explore-субагент с задачей "изучи изменения, верни структурированный отчёт с конкретными проблемами". Субагент прочитал все нужные файлы, нашёл три потенциальных race condition в логике сессий - баги, которые я бы точно пропустил при беглом взгляде на 60-файловый диф - и применил [MCP-инструменты](/blog/mcp-skrytyy-token-nalog-serverov/) только для этой конкретной задачи (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 - оптимальный паттерн для сложных задач с неизвестной архитектурой. Каждый субагент получает обогащённый контекст от предыдущего, но без его внутренних артефактов.

Как устроен контекст [внутри каждого субагента](/blog/kak-ustroen-kontekst-vnutri/) - та же четырёхслойная структура окна, что и в основной сессии. Принципиальное отличие: субагент не страдает от compression-проблем parent. Если родительская сессия уже прошла через несколько циклов compaction и несёт груз сжатых summaries, субагент начинает с чистого листа.

## Заключение

Субагенты - не просто техника параллелизма. Это стратегический инструмент управления контекстом, который меняет базовую архитектуру агентных систем.

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

Если твой агент потребляет контекст неэффективно - много исследований, много итераций, мало реального кода в output - это сигнал перейти на субагентную архитектуру. Выдели исследовательские задачи в Explore-субагенты, декомпозиционные задачи в Plan-субагенты, долгие фоновые операции запускай через Ctrl+B.

Субагенты закрывают ту часть Six Pillars, которую невозможно решить ни через [CLAUDE.md](/blog/claudemd-persistentnaya-pamyat-proekta/), ни через [compaction](/blog/compaction-tryokhsloynaya-sistema-szhati/), ни через [MCP tool search](/blog/mcp-skrytyy-token-nalog-serverov/): изоляцию самого процесса мышления от его результата.

Agent Teams, выпущенные в Opus 4.6 в феврале 2026 года, дают возможность координации напрямую между субагентами через peer-to-peer архитектуру - без hub-and-spoke через parent-сессию. Это отдельный паттерн для задач, где субагентам нужно обмениваться промежуточными результатами.