оркестрация в Cursor: scout и worker

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

когда вы подключаете в чат сильную модель вроде Opus 5 или GPT-5.6 и просите её разобраться в задаче, она первым делом начинает сканировать проект. агент открывает один файл, второй, десятый, ищет зависимости, натыкается на документацию и собирает в историю диалога тонны промежуточного текста. если модель дорогая, такой поиск сжигает квоту быстрых запросов за пару часов. но хуже другое: основное контекстное окно забивается мусором, модель теряет из вида первоначальные требования и начинает галлюцинировать или предлагать лишний рефакторинг.

решение этой проблемы: оркестрация и разделение ролей. мы оставляем дорогую модель в роли архитектора, а исследование проекта и изолированные правки перекладываем на субагентов, работающих на быстрой и дешёвой модели Composer 2.5.

в подписке Cursor Pro за $20 действует понятное разделение квот. у пользователя есть включённый пул собственных моделей Cursor, куда входят Composer 2.5 и модели семейства Grok, а также лимиты на сторонние флагманские модели. когда флагман работает один, он тратит дорогой ресурс на самые простые операции: просмотр структуры каталогов, поиск использования функции через grep и чтение чужих типов.

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

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

пользователь → главная модель (архитектор)
                     │
         ┌───────────┴───────────┐
         ▼                       ▼
    scout (readonly)       worker (правки)
    Composer 2.5           Composer 2.5
    поиск и факты          код и тесты
         │                       │
         └───────────┬───────────┘
                     ▼
             главная модель
         (проверка diff и ответ)

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

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

исполнитель worker вызывается только тогда, когда решение уже принято. главная модель формулирует для него узкую задачу: какой файл открыть, какую функцию изменить и какие проверки запустить. worker не придумывает архитектуру с нуля, а аккуратно реализует указанный шаг и сразу сообщает результаты локальных тестов. базово он работает на Composer 2.5, но под кодовые задачи в его манифесте можно легко переключить модель на Grok 4.6 или другие доступные модели семейства Grok из пула Cursor.

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

.cursor/
├── agents/
│   ├── scout.md
│   └── worker.md
└── rules/
    └── delegation.mdc

файл scout.md определяет разведчика. в нём жёстко зафиксирована модель Composer 2.5, параметр readonly: true и формат ответа: прямой ответ, ссылки на строки и открытые вопросы для архитектора:

---
name: scout
description: Read-only exploration and fact-finding.
model: composer-2.5[fast=false]
readonly: true
---

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

файл worker.md задаёт исполнителя. по умолчанию он настроен на Composer 2.5, но если для кода вы предпочитаете Grok, в поле model можно указать grok-4.6:

---
name: worker
description: Focused implementation on Composer 2.5.
model: composer-2.5[fast=false]
---

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

файл delegation.mdc лежит в папке правил и имеет директиву alwaysApply: true. благодаря этому Cursor автоматически загружает инструкцию по делегированию в каждый новый чат. правило запрещает главной модели бросаться в самостоятельное чтение файлов и обязывает её привлекать scout и worker.

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

установить связку можно за одну минуту прямо через интерфейс чата Cursor, не открывая терминал и не создавая папки вручную.

1. 01откройте нужный проект в Cursor.
2. 02скопируйте ссылку на открытый репозиторий cursor-orchestrate.
3. 03отправьте в чат Cursor следующий запрос:

установи конфиг из этого репозитория в текущий проект:
https://github.com/harnessmachine/cursor-orchestrate

скопируй только файлы:
.cursor/agents/scout.md
.cursor/agents/worker.md
.cursor/rules/delegation.mdc

если файлы с такими именами уже существуют, не перезаписывай их и покажи конфликт. остальные файлы проекта не меняй. после установки покажи diff.

агент скопирует три файла в служебную директорию .cursor. после завершения установки обязательно начните новый диалог, чтобы Cursor применил обновлённые правила, и выберите в меню выбора модель, которую хотите видеть в роли архитектора. отдельно выбирать Composer не требуется: он уже зашит в настройки агентов.

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

для проверки разведчика отправьте в чат исследовательский запрос:

изучи, как устроен этот проект. ничего не меняй. собери факты через субагента scout, затем сам объясни мне архитектуру и назови файлы, с которых лучше начать знакомство.

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

для проверки исполнителя дайте изолированную и безопасную задачу:

сначала сам реши, какую одну строку нужно добавить в README. затем используй /worker только для этой правки. после его работы проверь diff и покажи мне результат.

главная модель составит текст правки, вызовет worker, тот внесёт изменение в файл, а архитектор покажет вам финальный diff и подтвердит корректность.

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

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

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

в-третьих, проверяйте дату актуальности правил и состав моделей. на сентябрь 2026 года связка проверена на Opus 5 и GPT-5.6 в качестве архитектора и Composer 2.5 или моделях Grok в качестве субагентов. если Cursor меняет внутренний формат конфигурации агентов, достаточно обновить файлы из репозитория.

все файлы конфига открыты и доступны в репозитории cursor-orchestrate на GitHub. если вы экспериментируете с собственными ролями субагентов или тестируете другие связки моделей, приходите делиться результатами в чат «Вайбкодим».