Cloud Agents в Cursor: как задача превращается в pull request

Идея звучит фантастически: вы формулируете задачу, закрываете ноутбук — а через полчаса в репозитории вас ждёт готовый pull request. Это и есть Cloud Agents в Cursor: агент работает не на вашей машине, а в облаке, сам пишет код в отдельной ветке и открывает PR, который остаётся только проверить и смержить. Можно запустить несколько таких агентов разом на разные независимые задачи, не занимая свою машину.

Но у этой автономности две обратные стороны, о которых маркетинговые обзоры молчат: облачный агент выполняет команды без вашего подтверждения, а платите вы за него по совсем другому счётчику, чем за обычный чат. Разберём всё по порядку: чем Cloud Agents отличаются от локального агента, как их настроить, что вы получаете на выходе, сколько это реально стоит и как не открыть агенту лишнего. Сверено с документацией Cursor и независимыми разборами на июль 2026.

Background или Cloud Agents — это одно и то же

Первое, что путает даже авторов статей: Background Agents и Cloud Agents — это одна и та же функция. Её просто переименовали в конце октября 2025 года вместе с выходом Cursor 2.0 (блог датирован 30 октября, changelog версии — 29-м). Поэтому в поиске вы встретите оба названия — и оба про одно и то же. Если гайд говорит «Background Agent», мысленно читайте «Cloud Agent». В русскоязычных материалах эту функцию по старой памяти иногда называют «фоновый агент» Cursor — это прямой перевод прежнего названия Background Agent, и речь всё о той же облачной фиче.

Второе, что важно не спутать: локальный Agent Mode и облачный агент — разные вещи. Локальные параллельные агенты используют git worktree прямо на вашей машине, а облачные крутятся в изолированных виртуалках Cursor, не привязанных к вашему компьютеру, — можно закрыть ноутбук, и работа продолжится. И третье: Cloud Agent — не то же самое, что Bugbot. Bugbot — отдельный продукт, который ревьюит чужие PR; Cloud Agent — агент, который сам эти PR создаёт.

Bybit · Rewards Hubдо $30,100Внеси депозит, торгуй 14 дней — и забери награды в Rewards HubЗабрать бонус →

Как запустить: точки входа и подключение репозитория

Запустить облачного агента можно из множества мест: iOS-приложение, веб-версия cursor.com/agents (и Android как PWA), сам десктопный Cursor (пункт Cloud в дропдауне), Slack по упоминанию @cursor, комментарий @cursor под issue или PR на GitHub и Bitbucket, Linear и API. Идея в том, чтобы поставить задачу оттуда, где вы её увидели, — хоть с телефона.

Bugbot в Cursor: сколько теперь стоит ИИ-ревьюер pull request и что он реально ловит

Cursor на монорепо: порог 50 000 файлов и как его обойти

MCP в Cursor: как подключить базу данных, Figma и свои инструменты

LFM2.5-2.6B: модель на 2,6 млрд параметров держит агента в 2,5 ГБ памяти

Один продукт на Codex: как довести идею до живого URL, не утонув в коде

Но перед первым запуском есть обязательный шаг: администратор аккаунта Cursor должен подключить систему контроля версий на уровне организации — GitHub (Cloud или Enterprise Server), GitLab, Bitbucket Cloud или Azure DevOps. Без этого агенту некуда открывать PR. Хорошая новость по деньгам за доступ: Cloud Agents включены во все индивидуальные тарифы — Pro за $20/мес, Pro Plus за $60/мес и Ultra за $200/мес, — отдельно докупать функцию не нужно (но за сами прогоны платить придётся, об этом ниже).

Если вы ещё не пользуетесь Cursor и хотите попробовать всё это на своём проекте, поставить редактор можно по этой ссылке — а дальше настроим окружение, без которого облачный агент не соберёт ваш проект.

Настройка окружения: environment.json

Чтобы агент в облаке смог установить зависимости и запустить ваш код, ему нужно окружение. Настроить его можно двумя путями:

1. Агент сам настраивает среду через дашборд Cloud Agents — вы отвечаете на его вопросы, а готовую конфигурацию можно сохранить как снапшот и переиспользовать.
2. Вручную через Dockerfile, указанный в файле .cursor/environment.json в репозитории.

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

{
  "snapshot": "snapshot-xxxx",
  "install": "npm install"
}

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

Задача → pull request: что вы получаете

Когда агент закончил, задача превращается в готовый к слиянию pull request. К нему можно приложить артефакты — скриншоты, видео, логи — и опционально встроить их прямо в описание PR на GitHub. Каждый коммит при этом автоматически подписывается ключом Ed25519 на базе HSM и получает бейдж Verified — это снимает головную боль с branch protection, где правила требуют подписанные коммиты.

BYBIT COPY TRADINGКопитрейдинг на BybitОткрытая статистика трейдеров, старт с $10, отключение в один клик.Выбрать трейдера

Три возможности, которые делают облачных агентов по-настоящему мощными:

• Параллельность. По официальному changelog Cursor 2.0 можно запустить до восьми агентов одновременно по одному промпту (часть сторонних агрегаторов называет 10–20 — но опираться стоит на официальную цифру 8).
• Multi-repo. Один агент может работать сразу с несколькими репозиториями — например, менять фронтенд, бэкенд и инфраструктуру — и открыть PR в каждом изменённом репо.
• Автопочинка CI. Агент сам пытается починить упавшие проверки в созданных им PR — правда, только для GitHub Actions, не больше 10 попыток на один PR и только на тарифе Teams.

На практике полный цикл выглядит так: вы пишете задачу («добавь пагинацию в список заказов и покрой тестами»), выбираете репозиторий и ветку, запускаете агента и уходите. Агент поднимает облачную виртуалку из вашего снапшота окружения, ставит зависимости, пишет код, гоняет тесты, при необходимости чинит упавший CI и открывает pull request с описанием и артефактами. Вам приходит уведомление — остаётся открыть PR, прочитать дифф, оставить комментарии (на них агент тоже может ответить правкой) и смержить. Ключевое отличие от локальной работы: всё это происходит без вашего участия и с закрытым ноутбуком, а несколько таких задач могут выполняться параллельно.

Как эта механика вписывается в остальной Cursor и его тарифы — разбирали в обзоре Cursor и его тарифов. А если вы только знакомитесь с самим подходом «поставил задачу — получил код», начните с вайб-кодинга на простом проекте, прежде чем доверять агенту целые PR.

Когда облачный агент оправдан, а когда нет

Cloud Agents — не замена локальной работе, а инструмент под конкретный класс задач. Они хорошо заходят там, где задача понятна и хорошо формулируется словами: рутинный рефакторинг, покрытие тестами, обновление зависимостей, однотипные правки в нескольких репозиториях, багфиксы с чётким воспроизведением. Их сильная сторона — параллельность: пока вы заняты одним, три-четыре агента разгребают бэклог мелких задач и приносят готовые PR.

А вот где облачный агент проигрывает локальному: исследовательская работа, где нужно «пощупать» код и часто менять направление; задачи с неясными требованиями, которые проще доуточнять в диалоге; и всё, что требует запусков с секретами продакшена, — здесь автономность и авто-запуск команд становятся риском, а не удобством. Простое правило: чем чётче ТЗ и чем безопаснее последствия, тем лучше подходит облачный агент. Для тонкой работы с непредсказуемым ходом оставайтесь в локальном Agent Mode, где каждый шаг под вашим контролем.

Цена Cloud Agents: всегда Max Mode и оплата по API-тарифу

Здесь кроется главный сюрприз. Cloud Agents всегда работают в Max Mode — расширенном режиме контекста, — и переключателя, чтобы его выключить, для них нет. А оплата идёт не из обычного лимита подписки, а по API-тарифу выбранной модели. При первом запуске Cursor заставляет установить лимит трат (spend limit) — и это не формальность, а защита от неожиданного счёта.

Почему это важно понимать заранее: в 2025 году Cursor перешёл с пакетной модели «по числу запросов» на метраж по API-тарифам провайдера. Для части пользователей это обернулось непредсказуемыми расходами: по независимым отчётам переплаты сверх подписки у тяжёлых пользователей доходили до 15–30%, а в задокументированных случаях годовая подписка сгорала за один день. С тех пор ситуация стабилизировалась, но принцип остался: облачный агент по определению дороже обычного чата, потому что всегда в Max Mode. Ставьте spend limit и следите за расходом, особенно первое время.

Локальный агент против облачного: в чём разница

Ключевое отличие — не «где крутится», а кто подтверждает команды. Свёл в таблицу:

Именно строка про подтверждение команд — то, что стоит осознать до первого запуска. Локальный агент спросит разрешение перед тем, как что-то запустить в терминале. Облачный — не спросит.

Безопасность и риски

Автономность облачного агента — это и его сила, и его главный риск. Слабые места:

• Авто-запуск всех команд без подтверждения. В отличие от локального агента, облачный выполняет любые терминальные команды сам. Cursor прямо предупреждает в документации: это создаёт риск утечки данных через prompt injection — агента можно обманом заставить отправить код на посторонний сайт. Отсюда — режимы сетевого доступа: разрешить весь исходящий трафик, дефолтные домены плюс свой список, или только явный allowlist. Для чувствительных репозиториев выбирайте последний.
• Только обычный Privacy Mode. Cloud Agents работают лишь в стандартном Privacy Mode; устаревший Legacy Privacy Mode не поддерживается, потому что агенту нужно временно хранить код и окружение в облаке. Нюанс: если выключить Privacy Mode на старте, а потом включить в процессе — агент доработает текущий запуск с выключенным режимом.
• Секреты трёх типов. Cursor различает Environment Variable (виден агенту), Runtime Secret (подставлен в окружение, но замаскирован в логах как [REDACTED]) и Build Secret (доступен только на этапе Docker-сборки). Пароли и токены имеет смысл заводить как Runtime или Build, а не как обычную переменную.
• Пробелы в enterprise-контроле. У Cloud Agents нет неизменяемого аудит-лога, ролей уровня проекта (только workspace-уровень admin/member), а секреты хранятся простыми парами ключ-значение без интеграции с HashiCorp Vault или AWS Secrets Manager. Для строгого governance это стоит учитывать.
• Нет полного «своего облака». Даже self-hosted-варианты (личная машина или управляемый флот воркеров) оставляют «мозг» агента в облаке Cursor — на своё железо переносится только выполнение инструментов. По оценке самого Cursor, управляемого облака хватает более чем 80% клиентов, но если у вас требования к периметру — полного BYOC здесь нет.
• Настройка бывает мучительной. На бумаге всё просто, на практике — не всегда: в одном независимом разборе на Docker-in-Docker ушло 15 часов за три выходных, а на форуме Cursor жалуются, что секреты не подтягиваются в не-Docker сценариях, а install-команда из environment.json иногда молча не срабатывает. Один пользователь из-за этого ушёл на Windsurf. Закладывайте время на первую настройку.

Для баланса — что сделано хорошо: подписанные коммиты с бейджем Verified из коробки, переиспользуемые снапшоты окружения (не нужно каждый раз пересобирать зависимости) и multi-repo-координация, которой нет у локального агента.

Частые вопросы

Чем Cloud Agent отличается от обычного агента в Cursor?

Локальный (foreground) Agent Mode работает на вашей машине и по умолчанию спрашивает подтверждение перед каждой командой в терминале. Облачный агент крутится в изолированной виртуалке Cursor, работает даже с закрытым ноутбуком и выполняет все команды сам, без подтверждений, а результат отдаёт готовым pull request. Платите за облачного по API-тарифу (всегда Max Mode), а не из обычного лимита подписки.

Сколько стоит запуск облачного агента?

Доступ к функции включён в Pro ($20/мес), Pro Plus ($60/мес) и Ultra ($200/мес), но сами прогоны тарифицируются отдельно — по API-тарифу выбранной модели, и всегда в Max Mode, то есть дороже обычного чата. При первом запуске Cursor попросит установить лимит трат — не пропускайте этот шаг: после перехода на usage-биллинг в 2025 году были случаи, когда за день сгорало намного больше, чем ожидали. Следите за расходом, особенно на длинных агентных задачах.

Как настроить окружение для облачного агента?

Два пути. Первый — дать агенту настроить среду самому через дашборд Cloud Agents и сохранить результат снапшотом. Второй — прописать Dockerfile в файле .cursor/environment.json в репозитории. Cursor применяет конфигурацию в порядке «репозиторий → персональное окружение → командное». Помните, что снапшот удаляется после 90 дней без использования, так что заброшенное окружение придётся собирать заново.

Сколько облачных агентов можно запустить одновременно?

По официальному changelog Cursor 2.0 — до восьми агентов параллельно по одному промпту (часть сторонних обзоров называет 10–20, но это не подтверждённая цифра, ориентируйтесь на восемь). Плюс вы можете запускать независимых агентов на разные задачи из разных мест — из десктопного Cursor, веба, iOS-приложения, Slack, комментария @cursor под PR на GitHub, из Linear или через API. Именно параллельность — главное практическое преимущество: несколько рутинных задач разгребаются одновременно, пока вы заняты чем-то одним.

Безопасно ли пускать облачного агента в рабочий репозиторий?

С оговорками. Агент выполняет команды без подтверждения, поэтому Cursor сам предупреждает о риске утечки через prompt injection. Минимизируйте его: включите строгий режим сетевого доступа (allowlist), заводите пароли как Runtime или Build Secret, а не обычной переменной, и не давайте агенту доступ к репозиториям и ключам, без которых задача не решается. Для проектов со строгим комплаенсом учтите: неизменяемого аудит-лога и полного «своего облака» у функции пока нет, а роли доступа заданы только на уровне всего рабочего пространства, без гранулярности по отдельным репозиториям.