Субагенты в Cursor — это специализированные ИИ-ассистенты, которым основной агент может делегировать задачи. Каждый субагент работает в своём контекстном окне, обрабатывает определённые типы задач и возвращает результат родителю. В этом материале — как устроены субагенты, зачем они нужны разработчикам и как создавать своих.
Cursor — редактор кода с встроенным ИИ-агентом. Агент получает задачу от пользователя, анализирует кодовую базу, запускает команды и вносит изменения. Когда задача сложная или объёмная, агент может не справиться в одном контексте: окно переполняется, качество падает. Субагенты решают эту проблему: родительский агент делегирует часть работы специализированному «помощнику», который работает в отдельном контексте и возвращает только итог.
У субагентов четыре главных преимущества: изоляция контекста (долгие исследования не засоряют основной диалог), параллельное выполнение (несколько субагентов работают одновременно), специализированная экспертиза (свои промпты и модели под задачу) и повторное использование (пользовательских субагентов можно подключать в разных проектах).
💡 На тарифах с оплатой за запросы для субагентов нужно включить Max Mode. В планах с оплатой по использованию субагенты доступны по умолчанию.
Когда агент получает сложную задачу, он может автоматически запустить субагента. Субагент получает запрос со всем необходимым контекстом (родитель передаёт нужную информацию), работает автономно и возвращает итоговое сообщение с результатами. Субагенты запускаются с чистым контекстом — у них нет доступа к предыдущей истории диалога, поэтому родительский агент сам решает, что включить в запрос.
Субагенты работают в одном из двух режимов. В режиме переднего плана выполнение блокируется до завершения субагента — результат возвращается сразу; такой режим подходит для последовательных задач, где важен итог. В фоновом режиме управление возвращается сразу, субагент работает независимо — удобно для длительных или параллельных потоков. Фоновые субагенты пишут вывод в ~/.cursor/subagents/, родитель может читать эти файлы и отслеживать прогресс.
В Cursor есть три встроенных субагента, которые автоматически обрабатывают операции, требовательные к контексту. Их спроектировали на основе анализа диалогов, в которых агент упирался в предел окна контекста.
Настраивать эти субагенты не нужно — агент подключает их автоматически, когда это уместно.
У операций Explore, Bash и Browser общие черты: они создают шумный промежуточный результат, выигрывают от специализированных промптов и инструментов и могут съедать много контекста. Запуск их как субагентов даёт изоляцию контекста (промежуточный результат остаётся в субагенте, родитель видит только итог), гибкость по модели (например, Explore по умолчанию использует более быструю модель — можно запускать много параллельных поисков за то же время), специализированную конфигурацию (свои промпты и доступ к инструментам) и снижение затрат (быстрые модели дешевле; вынос «тяжёлых» задач в субагенты уменьшает общую стоимость).
Субагенты стоит использовать, когда нужна изоляция контекста для долгих исследовательских задач, когда вы запускаете несколько рабочих потоков параллельно, когда задача требует специализированной экспертизы на многих шагах или когда нужна независимая проверка выполненной работы. Навыки (skills) лучше подходят для узких, одноцелевых задач: сгенерировать changelog, отформатировать код, быстрое повторяемое действие без отдельного контекстного окна. Если субагент задуман для простой задачи вроде «сгенерировать changelog» или «отформатировать импорты», разумнее оформить это как skill.
Создавать пользовательских субагентов можно для формализации экспертизы, соблюдения стандартов команды или автоматизации повторяющихся процессов. Файлы субагентов — markdown с YAML-фронтматтером.
Субагенты проекта имеют приоритет при совпадении имён. Рекомендуется добавлять .cursor/agents/ в репозиторий, чтобы вся команда могла пользоваться одними и теми же агентами.
В начале файла — YAML-блок между ---. Поле name — уникальный идентификатор (строчные буквы и дефисы); по умолчанию берётся имя файла без расширения. Поле description — когда использовать этого субагента; по нему агент решает, делегировать ли задачу. Важно формулировать description конкретно: фразы вроде «use proactively» или «always use for» способствуют автоматическому делегированию. Поле model — fast, inherit или идентификатор модели; по умолчанию inherit. Поле readonly — если true, субагент запускается с ограниченными правами на запись. Поле is_background — если true, субагент работает в фоне и не блокирует выполнение.
После YAML идёт текст промпта: чёткие инструкции, что делать при вызове. Промпты лучше держать лаконичными — длинные размывают фокус и замедляют работу.
Агент проактивно делегирует задачи по сложности и масштабу, по описаниям субагентов в проекте и по контексту. Явно вызвать субагента можно через синтаксис /name в запросе: например, «/verifier confirm the auth flow is complete» или «/security-auditor review the payment module». Можно просто упомянуть субагента естественно: «Используй субагент verifier для подтверждения завершения аутентификации».
Параллельный запуск: в одном сообщении попросите, например, «Review the API changes and update the documentation in parallel» — агент отправит несколько вызовов субагентов одновременно. Субагентов можно возобновлять: каждый запуск возвращает идентификатор агента; передайте его в запросе («Resume agent abc123 and analyze the remaining test failures»), чтобы продолжить диалог с сохранённым контекстом.
Верификатор самостоятельно проверяет, что заявленная работа выполнена. Это снимает проблему, когда ИИ помечает задачи выполненными, а реализация неполная или нерабочая. Такой субагент определяет, что было заявлено как завершённое, убеждается, что реализация существует и работает, запускает тесты или шаги проверки и ищет граничные случаи. Полезно для проверки функциональности end-to-end перед закрытием тикетов и для выявления частично реализованного кода.
Для сложных процессов родитель по очереди координирует специализированных субагентов: Planner анализирует требования и составляет технический план, Implementer реализует функциональность по плану, Verifier проверяет соответствие требованиям. На каждом шаге передаётся структурированный результат.
Отладчик (debugger) фиксирует сообщение об ошибке и стек, определяет шаги воспроизведения, изолирует сбой, вносит минимальное исправление и проверяет решение. Тест-раннер (test-runner) проактивно запускает тесты при изменениях в коде, анализирует сбои, исправляет проблемы с сохранением замысла тестов и отчитывается о результатах. Аудитор безопасности (security-auditor) проверяет код на инъекции, XSS, захардкоженные секреты и валидацию входных данных, сообщает о находках по степени критичности.
Создавайте узкоспециализированных субагентов с одной чёткой зоной ответственности; избегайте универсальных «helper»-агентов. Уделяйте внимание полю description — от него зависит автоматическое делегирование. Промпты держите лаконичными и конкретными. Добавляйте .cursor/agents/ в систему контроля версий. Начинайте с конфигурации, сгенерированной агентом, и дорабатывайте под себя.
Не создавайте десятки размытых субагентов — Agent не поймёт, когда их вызывать. Избегайте размытых описаний вроде «для общих задач»; формулируйте конкретно. Не пишите промпты на тысячи слов — это замедляет и усложняет поддержку. Не дублируйте slash-команды субагентами для простых одношаговых задач. Не размножайте субагентов без явной необходимости — начните с 2–3 узконаправленных.
Субагенты потребляют токены независимо: у каждого своё контекстное окно. Параллельный запуск нескольких субагентов использует примерно во столько раз больше токенов, сколько субагентов. Для быстрых и простых задач основной агент часто эффективнее; субагенты особенно полезны для сложной, длительной или параллельной работы. Субагенты могут быть медленнее на простых задачах — их плюс в изоляции контекста, а не в скорости.
Три встроенных: Explore (поиск по кодовой базе), Bash (выполнение shell-команд), Browser (управление браузером через MCP). Они подключаются автоматически, настраивать их не нужно.
Нет. Субагенты работают как одноуровневые помощники; вложенные субагенты пока не поддерживаются.
Да. Субагенты наследуют инструменты родителя, в том числе MCP с настроенных серверов.
На старых планах с оплатой за запросы нужно включить Max Mode в выборе модели. В планах с оплатой по использованию субагенты доступны по умолчанию.
Субагенты в Cursor позволяют разбивать сложные задачи, выполнять работу параллельно и сохранять контекст в основном диалоге. Встроенные Explore, Bash и Browser разгружают агента от объёмных операций; пользовательские субагенты в .cursor/agents/ помогают формализовать экспертизу и рабочие процессы. Начните с 2–3 узконаправленных агентов, делайте описания конкретными и используйте субагентов там, где нужна изоляция контекста или параллельное выполнение.