Ваш проект перевалил за 100 тысяч строк. Вы просите агента внедрить новую фичу - скажем, добавить OAuth-авторизацию с тремя провайдерами. Агент бодро берётся за работу, пишет первые файлы... а на середине начинает путать имена middleware, дублировать уже существующие хелперы и предлагать структуру, которая противоречит всему, что было до этого. Вы поправляете, он соглашается, делает ещё пару шагов и снова забывает, о чём вы договорились три сообщения назад.
Знакомо? Это не баг конкретной модели. Это фундаментальная проблема архитектуры, при которой один агент с одним контекстом пытается держать в голове всё: и вашу архитектуру, и текущую задачу, и результаты поиска, и логи тестов, и историю обсуждения.
И Cursor, и Claude Code пришли к одному ответу это субагенты. Но реализовали его по-разному
Чтобы понять, зачем нужны субагенты, нужно сначала разобраться, почему единственный агент перестаёт справляться.
Формальный контекст vs реальный
Современные модели формально поддерживают огромные контексты например Claude - 200k. Gemini - до миллиона.
Звучит впечатляюще, пока не столкнёшься с реальностью: стабильная точная работа модели ограничена примерно 100-200 тысячами токенов. Дальше начинается деградация внимания мод��ль "видит" текст, но всё хуже его учитывает.
Это не теоретическая проблема. Исследования (например, "Lost in the Middle" от Stanford) показывают, что информация в середине длинного контекста обрабатывается значительно хуже, чем в начале и конце. На практике это означает: ваши важные архитектурные решения, зафиксированные в середине долгого диалога, модель может просто проигнорировать.
Два вектора деградации
При работе с большим проектом контекст забивается по двум направлениям одновременно.
Входные токены растут - агент отправляет модели всю историю переписки, ваши промпты, его ответы, результаты поиска по кодовой базе, содержимое прочитанных файлов, вывод команд. В длинной сессии это легко набирает 50-80k токенов ещё до того, как агент начинает думать о текущем шаге.
Точность падает нелинейно - среди растущего шума модель теряет именно то, что важно для текущего шага. Вы обсуждали именования переменных 20 сообщений назад? Агент уже забыл. Договорились использовать конкретный паттерн для обработки ошибок? В пятой итерации он предложит другой.
Планирование - частичное решение
Режим планирования в Cursor частично помогает, агент сначала составляет план действий, потом выполняет шаги.
Это структурирует работу и снижает хаотичность. Но фундаментальная проблема остаётся - планирование и выполнение происходят в одном контексте. Результаты каждого шага (прочитанные файлы, выполненные команды, промежуточные решения) продолжают накапливаться.
Длительные сессии заканчиваются предсказуемо: либо глубокий ручной рефакторинг того, что наделал агент, либо "всё выкинуть и начать заново". Второй вариант с AI-разработкой часто оправдан, но хочется иметь возможность и поддерживать существующий проект, а не только пересоздавать его с нуля.
Нужен другой подход. И он называется "субагенты".
Что такое субагенты: определение и механика
Субагент - это отдельный экземпляр агента с собственным контекстным окном, который получает конкретное задание от главного агента (оркестратора), выполняет его автономно и возвращает итоговый результат.
Разберём это определение по частям.
"Отдельный контекст" - главное свойство
Субагент стартует с чистого листа. У него нет вашей истории переписки с оркестратором. Нет результатов предыдущих поисков. Нет промежуточных решений, которые вы обсуждали час назад.
Вместо этого субагент получает:
Системный промпт - фиксированные инструкции, определяющие его роль и поведение
Задание от оркестратора - конкретную задачу на текущий шаг
Доступ к инструментам - файловая система, поиск, терминал и т.д.
Всё, что субагент делает в процессе работы (читает файлы, выполняет команды, перебирает варианты), остаётся в его контексте. Оркестратор получает только итоговое резюме это обычно одно-два сообщения с результатом.
Это как разница между двумя подходами к управлению: микроменеджмент (оркестратор делает всё сам и видит каждый промежуточный шаг) и делегирование (оркестратор даёт задачу, получает результат).
Три столпа субагентов
Изоляция контекста - каждый субагент работает в чистом окне. Длинные исследования кодовой базы, объёмные логи выполнения команд, промежуточные поиски - всё остаётся внутри субагента. Оркестратор видит только итоговое резюме.
Параллелизм - несколько субагентов могут работать одновременно. Один ищет по кодовой базе, другой запускает тесты, третий анализирует документацию. Оркестратор координирует, а не делает всё последовательно.
Специализация - у каждого субагента может быть свой промпт (роль и инструкции), своя модель (быстрая для поиска, мощная для анализа) и свой набор инструментов (read-only для аналитиков, полный доступ для разработчиков).
Если кратко, субагенты это переход от фрилансера-одиночки к команде с ролями. Аналитик, архитектор, разработчик, тестировщик, каждый сфокусирован на своём куске и не держит в голове чужие проблемы.
Как выглядит работа "под капотом"
Рассмотрим типичный сценарий. Вы просите агента: "Добавь кэширование для API-эндпоинтов в модуле users."
Без субагентов - агент в одном контексте читает 15 файлов, ищет существующие паттерны кэширования, анализирует структуру модуля, пишет код, запускает тесты, правит ошибки. К концу сессии контекст забит промежуточными данными, и агент начинает забывать ранние решения.
С субагентами - оркестратор разбивает задачу. Субагент-исследователь анализирует кодовую базу и возвращает резюме: "В проекте используется Redis-кэш через CacheService, паттерн decorator в src/cache/, тесты в tests/cache/".
Субагент-разработчик получает это резюме + конкретное задание и пишет код. Субагент-тестировщик запускает тесты и сообщает результат. Контекст оркестратора содержит только три резюме, а не сотни строк промежуточного вывода.
Claude Code: от Task к Sub-Agents
В Claude Code (CC) субагенты появились не сразу. Их история это эволюция от простого инструмента до мощного механизма кастомизации.
Начало: инструмент Task
С первых публичных версий CC существовал инструмент Task (в коде - AgentTool). Логика работы была простой: оркестратор мог запустить "задачу" в отдельном контексте. Task получал промпт от оркестратора, работал автономно с доступом к тем же инструментам, и возвращал итоговое сообщение.
Даже в таком базовом виде Task давал ощутимую пользу. Длинные сессии стали возможны: тяжёлая работа выносилась в отдельные контексты, оркестратор оставался "чистым" и мог координировать десятки шагов. В удачных случаях сессии длились часами вместо привычных минут.
CC регулярно использовал Task по собственной инициативе обычно для поиска по кодовой базе или анализа большой группы файлов. Чтобы "намекнуть" CC использовать Task для ваших задач, нужно было явно сказать в промпте: "используй инструмент agentTool для выполнения задачи".
Несколько Task могли работать параллельно. Для этого нужна была "магическая фраза" в промпте: "ВАЖНО: обязательно запусти эти задачи параллельно, сделав вызов нескольких инструментов agentTool В ОДНОМ СВОЕМ СООБЩЕНИИ". Оркестратор запускал 5-7 одновременных экземпляров -> например, для поиска по разным подсистемам проекта.
Проблемы базового Task
При всей пользе у Task были серьёзные ограничения:
Нет собственного системного промпта - задача получала только то, что передал оркестратор. А оркестратор, как выяснилось, не лучший "менеджер": при накоплении контекста он начинал писать задания кратко и без нужных деталей.
Нет выбора модели - Task работал на той же модели, что и оркестратор. Хотите opus для анализа и haiku для простых задач? Не получится.
Нет настройки инструментов - Task наследовал всё от родителя. Аналитическая задача получала доступ к менеджеру БД, хотя он ей не нужен. Поисковая задача могла случайно что-то модифицировать, хотя должна была только читать.
Оркестратор "творил всякое" например мог добавить в промпт что-то "от себя" в зависимости от текущего контекста. Задача поиска информации могла неожиданно начать обновлять файлы, если оркестратору показалось, что это "актуально".
Настоящие субагенты
В версии 1.0.60 CC получил полноценные Sub-Agents с тремя принципиальными дополнениями, которые превратили простой Task в мощный инструмент.
Свой системный промпт - каждый тип субагента получает фиксированные инструкции, которые зашиты в его определение. Больше не нужно надеяться, что оркестратор "не забудет" передать детали. Хотите, чтобы агент-аналитик знал структуру вашего проекта? Впишите её в промпт агента)
Своя модель - можно указать конкретную модель для каждого типа субагента:
Opus - для задач планирования, анализа и архитектурных решений (для тех, у кого доступен на тарифе)
Sonnet - дефолт для написания кода
Haiku - для простых задач: документация, теги, форматирование, поиск по коду
Это одновременно повышает качество (нужная модель для нужной задачи) и оптимизирует стоимость (haiku в разы дешевле opus).
Свой набор инструментов - можно отключить ненужные инструменты или подключить специфические MCP. Аналитическому агенту например только чтение или разработчику полный набор. Тестировщику условно терминал и файловую систему.
Как определить субагента в Claude Code
Определение субагента - markdown-файл с YAML frontmatter. Файлы размещаются в папке agents внутри проекта (.claude/agents/) или на уровне пользователя (~/.claude/agents/).
--- name: research-code description: 'Агент для поиска по коду и тестам проекта (Code/test search/research agent)' model: haiku color: blue --- Твоя основная задача: проводить эффективный поиск по файлам проекта. Ты должен внимательно изучить предоставленные сведения о структуре проекта и использовать их для выполнения задания. Структура проекта: * src/ - папка исходного кода * src/api/ - API-эндпоинты * src/services/ - бизнес-логика * src/models/ - модели данных * tests/ - папка со всеми тестами * tests/unit/ - юнит-тесты * tests/e2e/ - сквозные тесты * logs/ - служебные данные, здесь не ищем Дополнительно к формированию резюме по выполненной работе ты должен сформировать файл markdown с подробным отчётом в папке .tasks/ в корне проекта.
Обратите внимание на несколько важных моментов:
Описание (description) - это поле CC использует для автоматического выбора субагента. Когда оркестратору нужно запустить субагента, система смотрит список доступных агентов и по семантическому сходству описания с текущей задачей выбирает подходящий. Имя агента тоже влияет.
Структура проекта в промпте - один из самых эффективных приёмов. Вместо того чтобы агент каждый раз "исследовал" проект заново, вы сразу даёте ему карту.
Файловый вывод - субагент пишет результат в markdown-файл. Это механизм передачи данных между агентами (подробнее в разделе про workflow).
Ограничения Claude Code
Глубина всего один уровень - схема "оркестратор -> субагент" работает. "Оркестратор -> субагент -> субагент" - нет. У субагента нет инструмента agentTool для запуска других субагентов.
Vendor lock - только модели Anthropic: opus, sonnet, haiku. Opus 4.5 доступен только на дорогих тарифах (Max). Если вы хотите использовать GPT-4o или Gemini для определённых задач = Claude Code не позволит.
Описания загружаются при старте - если вы добавили нового субагента или обновили описание - нужно перезапустить CC. Это мелочь, но стоит помнить.
Cursor: встроенные и пользовательские субагенты
Cursor пошёл другим путём. Здесь субагенты появились как встроенная часть системы с тремя предустановленными агентами "из коробки", плюс возможность создавать свои.
Три встроенных субагента зачем они?
Cursor автоматически использует три субагента, не требующих настройки. Их выбор не случаен, они закрывают три самые "тяжёлые" операции с точки зрения контекста.
Explore - субагент для поиска и анализа кодовой базы. Исследование проекта генерирует огромный объём промежуточных данных: содержимое файлов, результаты grep-запросов, структура директорий. Если бы всё это попадало в контекст оркестратора, он бы быстро "переполнился". Explore использует более быструю модель, что позволяет запускать 10 параллельных поисков за то время, которое основной агент потратил бы на один.
Bash - субагент для выполнения shell-команд. Вывод команд бывает на сотни строк: логи сборки, результаты тестов, диагностика. Оркестратору нужна суть ("тесты прошли", "сборка упала на строке X"), а не полный лог. Bash фильтрует вывод и возвращает только релевантное.
Browser - субагент для работы с браузером через MCP. Взаимодействие с веб-страницами создаёт шумные DOM-снимки и тяжёлые скриншоты. Субагент обрабатывает их, оставляя только то, что нужно оркестратору для принятия решений.
У этих трёх операций общая черта - шумный промежуточный результат.
Вынос в субагенты одновременно экономит контекст оркестратора, снижает стоимость (быстрые модели дешевле) и повышает точность (специализированный промпт для каждого типа задач).
Вам не нужно настраивать эти субагенты так как Agent использует их автоматически, когда это уместно.
Пользовательские субагенты: формат и конфигурация
Cursor, как и Claude Code, позволяет создавать пользовательских субагентов. Формат практически идентичен, markdown-файл с YAML frontmatter:
--- name: verifier description: Validates completed work. Use after tasks are marked done to confirm implementations are functional. model: fast --- Вы — скептически настроенный валидатор. Ваша задача — убедиться, что работа, заявленная как завершённая, действительно работает. При вызове: 1. Определите, что было заявлено как завершённое 2. Убедитесь, что реализация существует и работает 3. Запустите соответствующие тесты или шаги проверки 4. Ищите граничные случаи, которые могли быть упущены Будьте тщательны и скептичны. Сообщите: - Что было проверено и прошло проверку - Что было заявлено, но осталось незавершённым или неработающим - Конкретные проблемы, которые необходимо устранить Не принимайте заявления на веру. Тестируйте всё.
Расположение файлов
Тип | Путь | Область |
Проект |
| Только текущий проект |
Глобальный |
| Все проекты пользователя |
Совместимость Claude |
| Cursor читает и эти файлы |
Совместимость Codex |
| Cursor читает и эти файлы |
При совпадении имён приоритет у .cursor/ перед .claude/ и .codex/.
Поля конфигурации
Поле | Обязательное | Описание |
| Нет | Уникальный идентификатор. Строчные буквы, дефисы. По умолчанию - имя файла. |
| Нет | Когда использовать субагента. Agent ориентируется на это поле при автоматической делегации. |
| Нет |
|
| Нет | Если |
| Нет | Если |
Три способа вызова субагентов
Agent сам решает, когда делегировать, ориентируясь на описание субагента, текущий контекст и сложность задачи. Фразы вроде "use proactively" или "always use for authentication tasks" в description усиливают автоделегацию.
Явный вызов через слеш:
> /verifier confirm the auth flow is complete > /debugger investigate this error > /security-auditor review the payment module
Естественным языком:
> Используй субагент verifier для проверки авторизации
> Have the debugger subagent investigate this error
> Run the security-auditor on the payment module
Режимы работы: foreground vs background
Foreground это когда оркестратор ждёт завершения субагента и получает результат сразу. Для последовательных задач, где результат предыдущего шага нужен для следующего.
Background это когда субагент запускается и работает независимо. Оркестратор продолжает свою работу, не дожидаясь. Вывод пишется в ~/.cursor/subagents/. Подходит для длительных или параллельных задач.
Субагенты можно возобновлять по ID, продолжая предыдущий диалог с сохранённым контекстом. Это полезно для длительных задач, которые охватывают несколько вызовов.
Сравнение в лоб: Cursor vs Claude Code
Пора свести всё в одну таблицу и разобрать, что за ней стоит.
Параметр | Cursor | Claude Code |
Модели | Любые (GPT, Claude, Gemini, open-source) | Только Anthropic (opus/sonnet/haiku) |
Встроенные субагенты | Explore, Bash, Browser (автоматические) | Нет предустановленных (Task работает из коробки) |
Пользовательские |
|
|
Формат определения | YAML frontmatter + markdown | YAML frontmatter + markdown |
Совместимость | Читает | Только свой формат |
Вложенность | Один уровень | Один уровень |
Параллельный запуск | Да, агент сам решает | Да (нужна явная инструкция оркестратору) |
Foreground/Background | Оба режима, явное управление | Foreground по умолчанию |
Автономность | Интерактивная (IDE) + CLI | Полностью автономная (терминал) |
Настройка инструментов | Наследуются от родителя | Явная конфигурация per-agent |
readonly режим | Да ( | Да, через набор инструментов |
Возобновление сессии | По agent ID | Через сессии | |
Vendor lock | Нет | Anthropic |
Когда что выбирать?
Cursor - если вы работаете интерактивно, хотите гибкость в выборе моделей, цените IDE-интеграцию и переключаетесь между несколькими AI-инструментами.
Claude Code - если вам нужна полная автономность ("поставил задачу на ночь"), вы уже в экосистеме Anthropic и хотите максимальную настройку инструментов per-agent.
В обоих случаях субагенты работают по одному принципу: изоляция контекста + специализация + параллелизм.
Сила мультиагентных workflow
Сами по себе субагенты это просто механизм. Реальная сила раскрывается при выстраивании workflow с ролями. Здесь начинается самое интересное.
Паттерн "команда разработки"
Для крупных доработок одного агента-разработчика недостаточно. Нужна полноценная команда с разделением ответственности:
Аналитик - например разбирает требования, проверяет, как фича вписывается в существующую архитектуру. Модель: opus (нужен глубокий анализ). Режим: read-only.
Архитектор - проектирует решение, определяет интерфейсы, выбирает паттерны. Модель: opus. Режим: read-only. Результат: документ с архитектурным решением.
Планировщик - декомпозирует решение архитектора на маленькие, атомарные задачи. Это ключевая роль во всей цепочке. Без хорошей декомпозиции разработчики получат расплывчатые задания и начнут "творить". Модель: opus или sonnet.
Разработчик - реализует по чётким инструкциям из плана. Не нужен весь контекст проекта, только спецификация конкретной задачи. Модель: sonnet. Режим: полный доступ.
Ревьюер - проверяет код, запускает тесты, ищет проблемы. Модель: sonnet. Режим: read-only (кроме запуска тестов).
Рецензенты - для критичных этапов (аналитика, архитектура) отдельный агент проверяет результат коллеги. Это снижает вероятность ошибки, которая "протечёт" дальше.
Каждый агент в этой цепочке получает только то, что ему нужно. Разработчику не важна глобальная постановка задачи - ему нужна спецификация конкретной задачи из плана. А то, что эта задача согласуется с архитектурой, уже проверили на предыдущих шагах.
Обмен между агентами через файловую систему
Промпты по сути ненадёжный канал передачи данных между агентами. Двойной "пересказ" (агент A -> оркестратор -> агент B) неизбежно теряет детали. Плюс оркестратор может "забыть" передать что-то важное на поздних шагах, когда его контекст уже забит.
Рабочий паттерн: агенты пишут результаты в markdown-файлы, следующий агент читает их напрямую.
.tasks/ 2026-03-04_analysis.md # Результат работы аналитика 2026-03-04_architecture.md # Решение архитектора 2026-03-04_plan.md # План от планировщика 2026-03-04_review.md # Отчёт ревьюера
Каждый файл это полный, самодостаточный артефакт. Разработчик читает plan.md и получает полную спецификацию задачи, без потерь на "пересказе" через оркестратора.
Антипаттерны: чего избегать
50 размытых агентов - описание "помогает с кодом" не даёт системе понять, когда делегировать. Agent видит десятки одинаково релевантных кандидатов и выбирает случайно (или не выбирает вообще). Начните с 2-3 узкоспециализированных субагентов. Добавляйте только при чётком use case.
Промпт на 2000 слов - это не делает субагента умнее. Он делает его медленнее (больше токенов на вход) и сложнее в обслуживании. Промпт должен быть точным, а не длинным.
Простые задачи через субагенты - для "сгенерируй changelog" или "отформатируй импорты" субагент тупо overkill. Каждый ��убагент это отдельный контекст с накладными расходами на старт. Для простых задач используйте навыки (skills) или слеш-команды.
Надежда на мокирование тестов - если тесты падают, модели инстинктивно мокают зависимости, чтобы тесты "прошли". В результате вы получаете зелёные тесты, которые ничего не тестируют.
Выводы
Наверное вы поняли что Субагенты это практическое решение конкретной проблемы так как один агент с одним контекстом не масштабируется на реальные проекты.
Вот что стоит запомнить:
- Начинайте с малого (например 2 или 3 субагента дают ощутимый результат)
- Ценность в изоляции контекста, а не в его расширении (не "больше токенов", а "правильные токены в правильном окне")
- Cursor гибче в выборе моделей, Claude Code сильнее в автономности (формат субагентов почти идентичен, различия просто в обёртке)
- Планировщик самая важная роль (без хорошей декомпозиции задач даже идеальные субагенты будут делать не то)
- Файловая система best канал связи между агентами (промпты теряют детали при пересказе, а markdown-файлы нет)
Какой из инструментов использовать? Зависит от стиля работы. Cursor если предпочитаете интерактивную работу в IDE с гибкостью моделей. Claude Code если хотите полной автономности и готовы к привязке к Anthropic. В идеале стоит попробовать оба и выбрать под конкретный тип задач.
А вы уже используете субагентов в своих проектах? Какие паттерны workflow сработали, а какие нет? Буду рад обсудить в комментариях или в личных сообщениях.
Готовы шаблоны для AI Субагентов можно взять - https://www.aitmpl.com/agents
Если вам понравилась эта статья, буду благодарен за вашу поддержку.
Email: akzhankalimatov@gmail.com
