Субагенты: изолированный контекст подзадач

Аналогия из разработки: субагент — это как вызов функции с собственным стеком вызовов. Функция работает в своём пространстве имён, получает аргументы, возвращает результат и очищает стек. Внешний код не видит, какие локальные переменные были внутри функции, — он получает только return value. Субагент делает то же самое для контекста.

В разных harness субагенты называются по-разному: sub‑agent, research‑agent, nested session, question‑tool. Но суть одна: изолированный контекст для подзадачи с возвратом результата.

Подход без субагента: вы просите агента поискать валидацию в кодовой базе. Агент запускает grep, читает 3-4 файла, находит нужные фрагменты, кладёт их в контекст, анализирует и пишет ответ. В контекст попали: весь вывод grep, содержимое прочитанных файлов, внутренние рассуждения агента о найденном. После ответа вся эта информация остаётся в контексте сессии, хотя для текущей задачи нужны только выводы, а не сырые данные.

Подход с субагентом: вы запускаете субагента с задачей «найди, как в проекте реализована валидация сумм, и верни краткое описание паттерна». Субагент в своём контексте делает grep, читает файлы, рассуждает — весь его «мусор» остаётся в его контексте. В основную сессию возвращается только результат: 2-3 предложения с описанием найденного паттерна. Контекст основной сессии не изменился — добавился лишь компактный вывод.

Разница в расходе токенов принципиальная: в первом случае контекст растёт на тысячи токенов, во втором — на десятки или сотни. На одной задаче это незаметно, но за день работы разница в объёме потреблённых токенов и в количестве раз, когда агент оказывается в Dumb Zone, становится огромной.

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

1. Исследование кодовой базы. Самый частый сценарий. Агент работает над фичей и ему нужно понять структуру существующего кода. Вместо того чтобы загружать в контекст все исследуемые файлы, запускается субагент-исследователь, который изучает код и возвращает короткую сводку: «в модуле X есть функция Y, которая делает Z, вызывается из A и B».
2. Поиск по документации или API. Когда для решения задачи нужно изучить внешнюю документацию, спецификацию или примеры кода. Субагент читает документацию в своём контексте, а возвращает только применимые правила и примеры — без полного текста страниц.
3. Анализ логов или больших выводов. Запуск команд, которые генерируют много вывода — тесты, логи, diff. Вместо того чтобы загружать 500 строк лога в основную сессию, субагент анализирует их и возвращает краткий вердикт: «упали 3 теста, причина в moduleA.test.ts строка 42 — ожидалось true, получено false».
4. Разбор ошибок и stack trace. Длинные stack trace занимают много токенов, но нужны для диагностики лишь несколько ключевых строк. Субагент получает полный trace, находит корневую причину и возвращает короткое описание проблемы.
5. Генерация плана. Перед тем как начать реализацию, субагент может продумать шаги, оценить сложность и вернуть структурированный план. План занимает мало токенов, а процесс его создания — сколько угодно много — остаётся в контексте субагента.
6. Многовариантный анализ. Когда нужно сравнить несколько подходов: субагент анализирует каждый вариант в изолированном контексте и возвращает только выводы и рекомендации.

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

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

Субагенты — не универсальное средство. Есть ситуации, где они не только бесполезны, но и вредны.

1. Простая подзадача на 1-2 запроса. Если вопрос можно задать и получить ответ без заметного расширения контекста — не запускайте субагента. Накладные расходы на запуск (передача инструкций, инициализация контекста) превысят выгоду от изоляции.
2. Задача, результат которой нужен для немедленного продолжения. Если вы прямо сейчас будете использовать найденную информацию — пусть она остаётся в контексте. Субагент имеет смысл, когда его вывод — это справка, а не код, который вы тут же редактируете.
3. Задача, которая сама по себе сложная и требует полного контекста основной сессии. Субагент не видит историю основной сессии. Если подзадача опирается на ранее обсуждённые детали, она провалится в изоляции.
4. Чрезмерное дробление. Если каждую мелочь запускать через субагента, вы получите не экономию контекста, а бесконечные переключения и потерю темпа. Субагенты — скальпель, а не лопата.

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

Важно: не все harness поддерживают субагентов одинаково. В одних это встроенная команда, в других — skill, в третьих — просто prompt-шаблон «запусти исследователя». Главное — понимать принцип, а реализация подстроится под ваш инструмент.

Запомните трёхшаговый паттерн работы с субагентом:

1. Оцени — прикинь, сколько токенов добавит в контекст решение подзадачи напрямую (много логов, много файлов, много рассуждений).
2. Реши — если прирост контекста значительный (>20-30%), запусти субагента.
3. Примени — получи краткий результат от субагента и продолжай работу в основной сессии.

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

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

1. Субагент (subagent) — изолированный экземпляр агента, запускаемый внутри текущей сессии для выполнения вспомогательной подзадачи с собственным контекстом и возвратом результата.
2. Загрязнение контекста — ситуация, когда в контекст основной сессии попадают вспомогательные данные (логи, промежуточные результаты поиска), не нужные для финального ответа, что приводит к ускоренному заполнению окна и смещению в Dumb Zone.
3. Изоляция контекста — принцип, при котором подзадача выполняется в отдельном контекстном окне, а основная сессия получает только финальный результат.
4. Дочерняя сессия — альтернативное название субагента в некоторых harness: отдельная сессия, запущенная из родительской с автоматической передачей результата.
5. Исследователь кодовой базы — типовой сценарий субагента: изучает структуру и реализацию модулей проекта и возвращает краткое описание.
6. Трёхшаговый паттерн — рабочий процесс с субагентом: оцени прирост контекста → реши запускать ли субагента → примени результат.
7. Handoff — механизм явной передачи состояния между сессиями (в отличие от субагента, где передача автоматическая).