Cloud Subagents в Cursor: зачем агенту ещё один агент
Как context isolation, отдельные VM и branch превращают subagent в самостоятельного engineering worker.

Что появилось в Cursor 3.7

17 июня 2026 года Cursor выпустил версию 3.7 с Cloud Subagents в Agents Window. Команда /in-cloud отправляет следующую задачу отдельному агенту: Cursor поднимает для него собственную VM и branch, а исходная session продолжает работать локально или в cloud.

Одновременно Cursor упростил подготовку cloud development environment. Агент может установить dependencies в общей terminal session, проверить setup и сохранить reusable snapshot. Конфигурация .cursor/environment.json закрепляет среду для всего repository, чтобы новые workers получали одинаковые runtime, команду установки и зависимости.

Снаружи это похоже на удобный background task. Архитектурный смысл глубже: subagent получает отдельную ответственность, отдельное состояние и чёткую точку возврата результата.

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

Subagent — не ещё одна вкладка чата

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

В модели Cursor parent agent сам делегирует ограниченную задачу, subagent работает в собственном context window и возвращает финальный результат в исходную conversation:

Developer
    ↓
Parent Agent
    ↓ task + constraints
Subagent
    ↓ findings / diff / test report
Parent Agent

Человек управляет целью верхнего уровня. Parent отвечает за декомпозицию и synthesis, worker — за конкретный кусок работы. Это уже небольшой orchestration loop, а не параллельная переписка.

Первый выигрыш — изоляция шумного context

Расследование bug быстро заполняет conversation промежуточными данными: десятками поисков, shell output, неудачными hypotheses и stack traces. Основному агенту всё это нужно лишь до момента, когда найдено объяснение.

Допустим, после смены роли пользователь ещё 15 минут сохраняет старые permissions. Parent может отдать отдельному researcher только cache layer:

INPUT
- symptom возникает после RoleChangedEvent;
- User записывается корректно;
- публичный API менять нельзя.

RETURN
- cache locations;
- invalidation flow;
- root-cause hypothesis;
- files and evidence;
- remaining unknowns.

Researcher прочитает listeners, Redis keys, security tests и историю изменений. В основной context вернётся не триста строк grep, а сжатый вывод: permission result кешируется, но событие смены роли не инвалидирует ключ.

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

Хорошее делегирование требует интерфейса

Чистый context создаёт и риск: worker не знает историю parent автоматически. Если забыть передать backward compatibility constraint, subagent честно предложит решение, которое меняет API.

Поэтому задача для subagent должна напоминать interface функции:

GOAL        что выяснить или изменить
CONTEXT     подтверждённые исходные данные
CONSTRAINTS что нельзя менять
SCOPE       файлы, подсистема или сценарий
OUTPUT      findings, artifacts и evidence
DONE        проверяемый критерий завершения

Фраза «разберись там» почти гарантирует лишнюю работу. «Найди все пути cache invalidation, код не меняй, верни evidence и неизвестное» даёт parent результат, который можно использовать в следующем решении.

Orchestration ломается чаще на границе между агентами, чем внутри одного tool call. Чем больше workers, тем важнее качество task packaging.

Cloud Subagent добавляет изоляцию выполнения

Обычные subagents разделяют context, но могут работать с одним checkout. Если два исполнителя одновременно редактируют OrderService.php, обновляют Composer dependencies или меняют test database, возникает collision.

/in-cloud добавляет второй boundary:

Cognitive isolation
own context window

Execution isolation
own VM + own clone + own branch

Теперь один worker может часами воспроизводить flaky test, второй — исследовать legacy integration, а локальный agent — продолжать feature. Их процессы, dependencies и незакоммиченные изменения не смешиваются.

Branch здесь не мелкая Git-деталь. Это единица handoff: результат можно просмотреть, попросить доработать, забрать локально, merge или выбросить целиком. Worker возвращает не обещание, а изолированный artifact.

VM полезна только с воспроизводимой средой

Чистая машина без PHP, PostgreSQL и private dependencies не делает агента автономным. Он сможет читать код, но не замкнёт цикл change → run → observe → fix.

Cloud Environment Setup решает именно эту часть. Для PHP-проекта готовая среда может включать:

PHP 8.4 + Composer
PostgreSQL + Redis
Node.js build tools
private package access
install command
startup command
test fixtures

Cursor сохраняет проверенный setup как reusable snapshot, а .cursor/environment.json фиксирует его в repository. Следующий agent стартует не с вопроса «как поднять проект», а с работающей машины.

Я бы относился к этому файлу как к onboarding contract. Если команда меняет PHP или способ установки зависимостей, environment должен пройти тот же review, что Dockerfile и CI. Иначе локальный developer и cloud worker будут проверять разные системы.

Самый сильный pattern — независимый verifier

Основной agent может написать feature и запустить tests в собственной среде. Но эта среда уже содержит изменённые dependencies, cache, generated files и тестовые данные. Green result не всегда доказывает, что branch воспроизводится с нуля.

Cloud Subagent можно использовать как отдельного skeptical verifier:

Parent branch
    ↓
fresh Cloud VM
    ↓ install + migrate + build
targeted tests
    ↓
related suite
    ↓
diff review + report

Другой context тоже полезен: verifier не участвовал в исходном reasoning и меньше привязан к тем же assumptions. Одинаковая модель не даёт полной независимости, но fresh instructions, environment и evidence заметно сильнее самопроверки в той же session.

Для migration я бы сформулировал DONE жёстко: база поднимается с нуля, rollback проверен, старый API test проходит, schema diff пуст после повторной migration. Тогда cloud worker проверяет факты, а не впечатление от кода.

Параллельность нужна только независимым workstreams

Хороший случай — пять flaky tests. Parent распределяет их по трём cloud workers, каждый получает отдельную branch и собственный reproduction loop. Через двадцать минут можно получить три диагностических отчёта вместо последовательного часа.

Другой практичный сценарий — /babysit. Cloud agent следит за PR, читает CI failures, исправляет проблему и повторяет проверки, пока локальная session занимается следующей задачей.

Но дробить небольшую правку на Planner, Researcher, Implementer, Tester и Reviewer бессмысленно. Каждый subagent имеет startup overhead, отдельный context budget и точку координации. Пять workers — это пять мест, где можно потерять constraint или получить несовместимые решения.

Skills, Subagents и Environment отвечают на разные вопросы

В предыдущей статье о Codex Plugins и Skills я разбирал повторяемый способ работы. Cloud Subagents добавляют к нему ещё два слоя:

Skill              HOW
Subagent           WHO
Cloud Environment  WHERE
Task contract      WHAT + DONE

Например, PHP Review Skill задаёт checklist, Reviewer Subagent получает responsibility и read-only tools, а cloud VM даёт чистую среду для запуска приложения. Только вместе они образуют специализированного worker.

Именно поэтому релиз 17 июня интереснее команды /in-cloud. Cursor превращает agent session в coordinator, который раздаёт ограниченные задачи независимым исполнителям и получает обратно branches, reports и verification evidence.

Разработчик при этом поднимается ещё на уровень: вместо управления каждым grep он проектирует границы работы. Главный навык здесь не запуск как можно большего числа агентов, а хорошая декомпозиция — дать каждому worker только нужный context, изолировать опасное выполнение и заранее определить форму результата.