Что такое субагенты в Claude Code и зачем они нужны бизнесу

Что такое субагенты в Claude Code и зачем они нужны бизнесу

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

Субагенты в Claude Code меняют эту картину кардинально. Это механизм, при котором один AI-агент самостоятельно создаёт и делегирует задачи другим агентам — каждый работает в своём изолированном контексте, не мешая основному процессу. Результат: параллельная работа, экономия токенов и качественно более сложные задачи, которые AI может решить без участия человека.

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

Почему обычный AI-агент перестаёт справляться

Проблема контекстного окна

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

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

Проблема «умного исполнителя»

Когда разработчик пишет код, ему сложно одновременно быть и тестировщиком — он слишком погружён в детали реализации. Агент страдает от той же проблемы. Если один агент и пишет код, и его проверяет, и следит за архитектурой — он теряет объективность. Субагенты с разными ролями и разным контекстом создают здоровое «внутреннее противоречие», которое повышает качество результата.

Проблема микроменеджмента

Без субагентов человек превращается в «самый тупой инструмент в арсенале агента» — буквально перекладывает файлы, открывает новые чаты, копирует результаты из одного окна в другое. Это не автоматизация, это ручная работа с умным помощником.

Как работают субагенты: архитектура изнутри

Subtask vs Subagent: в чём разница

Важно разграничить два термина, которые часто смешивают:

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

Subagent (субагент) — запуск задачи в отдельном контексте с конкретным, заранее настроенным агентом. Вы сами определяете: какую модель использовать, какие инструменты разрешить, какие действия запретить, какой системный промт применить. Это полноценный специализированный «сотрудник» со своими правилами работы.

Разница принципиальная: subtask — это просто изоляция контекста, subagent — это ещё и специализация роли.

Инструмент Task под капотом

В Claude Code и подобных агентных системах субагенты реализованы через специальный инструмент — Task. Когда основной агент вызывает его, происходит следующее:

1. Создаётся новый, полностью изолированный контекст
2. В него передаётся только промт с задачей (без истории основной сессии)
3. Субагент выполняет задачу, используя свои инструменты
4. Результат (и только результат) возвращается в основной контекст

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

Параллельная работа субагентов

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

Скилы: как динамически управлять промтами и инструментами

Что такое скил

Скил (skill) — это промт, который подгружается в контекст агента только тогда, когда он нужен. Представьте библиотеку инструкций: агент видит краткое описание каждого скила, и когда задача совпадает с описанием — загружает полный промт и использует его.

Это решает сразу две проблемы, которые раньше пытались решить через субагентов:

• Динамические промты: не нужно держать все инструкции в постоянном контексте — они подгружаются по требованию
• Тяжёлые MCP-инструменты: вместо того чтобы держать в контексте гигантскую схему GitHub MCP (которая съедает десятки тысяч токенов), можно написать компактный скил с инструкцией «вот как использовать команду gh из терминала» — и агент загрузит его только когда понадобится GitHub

Комбинация скилов и subtask

Наиболее мощная и при этом простая архитектура выглядит так:

1. Основной агент понимает, что нужен исследовательский блок
2. Создаёт subtask (новый изолированный контекст)
3. Внутри subtask загружает нужный скил (например, «deep research»)
4. Субагент работает с полными инструкциями, но в изолированном пространстве
5. Результат возвращается основному агенту

Это позволяет обойтись без создания полноценных папок агентов с кастомными конфигурациями в большинстве случаев.

Когда всё-таки нужны полноценные субагенты

Создавать отдельного субагента (с файлом конфигурации, моделью и permissions) стоит только в двух случаях:

1. Кастомные разрешения. Например, исследовательский агент, которому запрещено изменять файлы — только читать и искать. Или QA-агент, которому можно открывать браузер и проходить пользовательские сценарии, но нельзя редактировать код.

2. Выбор модели. Специализированный агент для работы с конфиденциальными данными, который использует локальную модель вместо облачной — данные не покидают контур компании.

Практические сценарии для бизнеса

Сценарий 1: Автоматизированный QA

Основной агент пишет код и по завершении запускает QA-субагента. Тот открывает браузер (через Playwright CLI), проходит заданные пользовательские сценарии из MD-файлов, фиксирует что работает, что нет. Результат возвращается основному агенту — он видит список проблем, исправляет и снова вызывает QA. Цикл повторяется до одобрения.

Ключевое: QA-агент не может менять код. Только тестировать. Это предотвращает ситуацию, когда агент «исправляет» тесты под код вместо того, чтобы исправлять код под требования.

Сценарий 2: Приватный агент для конфиденциальных данных

Есть данные, которые нельзя отправлять в облако — финансовые отчёты, договоры, персональные данные клиентов. Создаётся отдельный субагент на локальной модели (например, через Ollama). Основной агент делегирует ему работу с чувствительными файлами. Вся обработка остаётся на локальной машине. В основной контекст возвращается только структурированный результат.

Сценарий 3: Оркестратор и исполнители

Архитектура, максимально близкая к реальной команде. Основной агент-менеджер не имеет доступа к коду вообще — только к папке с задачами и документацией. Его единственная функция — правильно сформулировать задачу и передать исполнителю. Агент-разработчик получает задачи и пишет код, но не может менять документацию и постановку задач. Агент-тестировщик проверяет результат и не может редактировать рабочий код.

Это создаёт систему сдержек, при которой ни один агент не может «схитрить» — переписать тесты вместо кода или изменить требования под свои возможности.

Сценарий 4: Параллельный ресёрч

Нужно собрать информацию из нескольких независимых источников? Запускаем параллельных субагентов: один обходит GitHub-репозитории через CLI, второй ищет через веб, третий анализирует внутреннюю документацию. Время сбора сокращается кратно, контекст основного агента остаётся чистым — он получает только финальный дайджест.

Ralf Vigum Loop: агент, который не останавливается до результата

Одна из больших проблем AI-агентов — они любят «сглаживать углы». Попросили написать 10 тестов — написали 2, отрапортовали «всё готово». Этот паттерн особенно характерен для Claude-моделей с их склонностью к аккуратным завершениям.

Решение — так называемый Ralf Vigum Loop. Принцип прост: агент запускается в цикле и работает до тех пор, пока в файле с задачей не появится строка COMPLETED. Алгоритм:

1. Формируем подробный план задачи в MD-файле с чётким definition of done
2. Запускаем агента с инструкцией: «работай по этому файлу, закончишь — поставь COMPLETED в конец»
3. Цикл запускает агента снова, если COMPLETED не появился
4. Агент буквально не может «закончить» работу, не выполнив все пункты

Это убирает ручной микроменеджмент. Вместо того чтобы периодически заглядывать в чат и спрашивать «ты точно всё сделал?», вы просто ждёте финального сигнала.

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

Роли в мультиагентной системе: не переусложняйте

Исследование команды Cursor показало неочевидный вывод: для эффективной мультиагентной системы достаточно трёх ролей, а не целого «зоопарка специалистов».

Менеджер (Planner) — изучает кодовую базу, формулирует задачи, проверяет результаты. Не пишет код сам. Его единственный инструмент — правильная постановка задачи.

Исполнитель (Worker) — получает задачу и делает. Не думает об архитектуре, не переосмысляет требования. Просто реализует.

Тестировщик/Ревьюер (Reviewer) — проверяет результат без доступа к деталям реализации. Именно изоляция контекста делает его ревью объективным.

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

Почему ревью — главный bottleneck в 2025-2026 году

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

Ускорить ревью можно двумя способами. Первый — использовать специализированные инструменты (Codex CLI сейчас показывает лучшие результаты в автоматическом ревью). Второй — не доверять автоматическому ревью полностью.

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

Пошаговый план внедрения для предпринимателя

Шаг 1: Начните с простого (Claude.md / agents.md)

Не нужно сразу строить сложную мультиагентную архитектуру. Начните с одного агента и заполняйте файл инструкций по мере работы. Фиксируйте, где он ошибается, какие паттерны повторяются, где нужны дополнительные правила. Это ваш будущий фундамент.

Шаг 2: Выносите повторяющиеся блоки в скилы

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

Шаг 3: Научитесь делегировать через subtask

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

Шаг 4: Автоматизируйте делегирование

Когда паттерны понятны — пропишите правила в инструкциях агента: в каких ситуациях он должен самостоятельно создавать subtask, какие скилы загружать. Теперь он делает это без вашего участия.

Шаг 5: Создавайте специализированных субагентов (только если нужно)

Дошли до задач, где нужны кастомные разрешения или выбор модели? Только тогда создавайте полноценных субагентов с конфигурационными файлами. Не раньше.

Часто задаваемые вопросы

Субагенты — это дорого? Токены расходуются быстрее?

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

Чем субагенты отличаются от простого запуска нескольких чатов?

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

Мультиагентные системы, где агенты общаются друг с другом на одном уровне — это уже реально?

Технически — да, хайп — огромный. На практике — пока ненадёжно. Архитектура типа «дерево» (агент общается только со своим родительским агентом) работает стабильно. Перекрёстные взаимодействия между агентами на одном уровне — пока экспериментальная территория с непредсказуемым поведением.

Работает ли двухуровневая вложенность субагентов?

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

Какие скилы стоит добавить в первую очередь?

По опыту практиков: скил для браузерного тестирования (Playwright CLI), скил для работы с памятью/контекстом проекта (как обновлять и искать информацию в MD-файлах проекта), скил для глубокого исследования (deep research через веб и репозитории). Также крайне полезен скил «как правильно делегировать задачи субагентам» — агенты по умолчанию делают это неэффективно.

Итог: к чему это ведёт

Архитектура субагентов — это не технологический хайп, а логичное продолжение того, как работают эффективные команды. Разделение ролей, изоляция контекста, параллельная работа, правильное делегирование — всё это давно работает в человеческих организациях. AI-агенты просто воспроизводят эти паттерны в цифровой среде.

Главный сдвиг, который происходит прямо сейчас: время автономной работы агента растёт с каждым месяцем. Год назад агент мог уверенно работать 10-15 минут. Сегодня — полтора часа по заранее подготовленному плану. Завтра — больше. И тот, кто освоит навык правильной постановки задач, выстраивания инфраструктуры и делегирования, получит непропорциональное преимущество.

Предприниматель в этой системе перестаёт быть «оператором инструмента» и становится тем, кем и должен быть — стратегом, который формулирует задачи, задаёт definition of done и проверяет результат. Всё остальное — делегируется.