Возможности
Использование компьютера
Каждый облачный агент запускается в собственной изолированной виртуальной машине с полноценной графической средой рабочего стола. Агенты могут использовать мышь и клавиатуру для управления рабочим столом и браузером, что позволяет им взаимодействовать с создаваемым ими ПО как обычный разработчик.
Это означает, что агенты могут запускать dev‑серверы, открывать приложение в браузере, проходить пользовательские сценарии в интерфейсе и проверять, что их изменения работают, прежде чем отправить PR. Подробнее читайте в анонсирующем посте в блоге.
На самостоятельно размещаемых машинах запускайте воркер с флагом --computer-use, чтобы агент мог управлять рабочим столом этой машины. Воркеры macOS используют вспомогательное приложение Cursor Computer Use, а воркеры Linux — дисплей X11. См. Использование компьютера и демонстрация рабочего стола.
Демо и артефакты
Агенты создают артефакты, такие как скриншоты, видео и ссылки на логи, для демонстрации результатов своей работы. Эти артефакты прикрепляются к PR, чтобы вы могли быстро проверить изменения, не переключаясь локально на соответствующую ветку.
Артефакты в GitHub
Вы можете включить встраивание артефактов облачного агента прямо в описания pull request на GitHub, включив параметр Разрешить публикацию артефактов в GitHub в дашборде облачного агента.
GitHub проксифицирует изображения только по публичным URL-адресам, поэтому для артефактов в описаниях PR используются длинные, трудноугадываемые URL-адреса, доступные без аутентификации. Для справки: до мая 2023 года GitHub использовал публичные URL-адреса для всех вложений в issue и PR.
Управление удалённым рабочим столом
Вы можете перехватить управление удалённым рабочим столом агента, чтобы взаимодействовать с ПО, которое он разрабатывает. В любой момент верните управление агенту, чтобы он продолжил работу.
Облачные агенты работают в удалённой виртуальной машине, которую можно полностью подготовить с вашим репозиторием, зависимостями, инструментами и скриптами настройки. Это позволяет тестировать изменения прямо в виртуальной машине агента, не переключая ветку на локальном компьютере.
Инструменты MCP
Облачные агенты могут использовать серверы MCP (Model Context Protocol), настроенные для вашей команды. Это даёт им доступ к внешним инструментам и источникам данных, таким как базы данных, API и сторонние сервисы, во время выполнения.
Добавляйте и включайте персональные MCP‑серверы через выпадающий список MCP на cursor.com/agents. Администраторы команды настраивают общие серверы в разделе Dashboard -> Integrations & MCP.
Администраторы могут привязывать общие серверы Team MCP к маркетплейсу команды по умолчанию. Привязка сохраняет доступность серверов для Cloud Agents, а также делает их доступными для установки и настройки участниками команды в Agent Window, IDE и CLI.
Облачные агенты поддерживают OAuth для MCP‑серверов, которым он необходим. OAuth действует на уровне пользователя, включая MCP‑серверы, общие для всей команды.
Пользовательские серверы MCP
Вы можете добавлять пользовательские серверы MCP, используя транспорт HTTP или stdio. SSE и mcp-remote не поддерживаются.
Конфигурации MCP шифруются при хранении. Конфиденциальные поля маскируются и не могут быть прочитаны ни одним пользователем после сохранения:
env— переменные окружения для серверов stdioheaders— заголовки запросов для HTTP-серверовCLIENT_SECRET— секрет клиента OAuth для HTTP-серверов
HTTP vs stdio
- HTTP (рекомендуется) — конфигурации серверов никогда не присутствуют в среде виртуальной машины облачного агента. Агент не имеет доступа к токенам обновления, заголовкам или другим учетным данным. Вызовы инструментов проксируются через бэкенд.
- Stdio — серверы запускаются внутри виртуальной машины облачного агента, поэтому агент имеет доступ к конфигурации сервера и переменным окружения. Это похоже на то, как stdio MCP работают в Cursor IDE.
Stdio-серверы зависят от среды виртуальной машины для выполнения. Мы не можем проверить, что stdio-сервер успешно запустится, пока не будет запущен облачный агент. Мы рекомендуем по возможности использовать HTTP MCP и правильно настраивать окружение , если вы используете stdio-серверы.
Cursor Cloud MCP
Cursor Cloud MCP — это встроенный сервер диагностики, доступный во время запусков облачного агента. Агент может проверять текущий запуск, просматривать связанные запуски в той же инфраструктуре, а также получать транскрипты, метаданные диффа, сведения об инфраструктуре, события запуска и логи настройки без необходимости вручную собирать ссылки и файлы.
Администраторы команды могут отключить Cursor Cloud MCP для своей команды в разделе Конфигурация MCP в настройках команды. Подробнее об административных настройках MCP см. в разделе панель управления командой.
Доступ и разрешения
Диалоги облачного агента могут включать промпты, код, выходные данные инструментов и секреты. Все инструменты проверяют права доступа для каждого запроса.
| Роль | Что вам доступно |
|---|---|
| Администратор команды | Просмотр списка и подробной информации (включая транскрипты) по запускам облачного агента во всей команде для репозиториев и инфраструктур, к которым у них уже есть доступ |
| Не администратор | Только ваши собственные запуски и транскрипты. Вы не можете просматривать чаты других участников команды через этот MCP |
Даже при просмотре списка запусков в общей инфраструктуре пользователи без прав администратора видят только агентов, которых сами запустили или которыми владеют. Сервисные аккаунты подчиняются тем же правилам, что и пользователь или командный контекст, от имени которых они выполняются.
Что можно посмотреть
| Категория | Примеры |
|---|---|
| Текущий запуск | Run ID, URL, repo, branch, модель, владелец, статус жизненного цикла и источник запуска (Cursor, Slack, GitHub, API и другие источники) |
| События | Результаты настройки, pull request, артефактов и аутентификации MCP, отображаемые на дашборде запуска. Используйте get-events для текущего запуска или batch-fetch-details с include_events для других запусков. Типы событий см. в разделе «Инструменты». |
| Связанные запуски | Другие облачные агенты в той же инфраструктуре или в том же репозитории, если не прикреплена сохранённая конфигурация инфраструктуры |
| Инфраструктура | Версия инфраструктуры, полная конфигурация инфраструктуры, URL дашборда и действующая политика исходящего трафика |
| Транскрипт | Полный диалог пользователя и агента, включая вызовы инструментов, если они доступны |
| Метаданные диффа | Изменял ли агент код, насколько большими были изменения и открыл ли он PR |
| Логи настройки | Сырые логи этапов настройки инфраструктуры и сборки образа |
Инструменты
В зависимости от MCP-клиента имена инструментов могут включать префикс сервера (например, cursor-cloud-run-info). Доступны следующие инструменты:
| Инструмент | Назначение |
|---|---|
run-info | Получить идентификатор, метаданные и URL текущего запуска. Начните с этого. |
environment-info | Получить версию инфраструктуры текущего запуска, конфигурацию, URL дашборда и применяемую политику исходящего трафика. |
get-events | Получить список событий дашборда текущего запуска в хронологическом порядке, начиная с самых ранних. |
list-cloud-agents | Просматривать запуски облачного агента, доступные вам в этой инфраструктуре. Можно фильтровать по источнику, статусу, дате, изменениям кода, созданию PR и состоянию архивации. |
batch-fetch-details | Получить сведения по указанным ID запусков (bcId). При необходимости можно включить транскрипты, метаданные диффа, логи настройки, сведения об инфраструктуре и события запуска через include_events (для каждого запуска создаётся events.json; до 50 запусков в пакете). |
get-automation | Получить сведения об автоматизации, например имя и владельца, по её ID. |
list-environment-builds | Получить список недавних сборок для текущей инфраструктуры и проверить их статус. |
environment-build-logs | Скачать логи установки и настройки для сборки. |
trigger-environment-build | Запустить тестовую сборку с текущей конфигурацией или предложенными командами установки и запуска. |
propose-environment-json | Предложить команды установки и запуска для проверки перед сохранением инфраструктуры. |
take-environment-snapshot | Создать снимок машины после того, как агент проверит настройку её инфраструктуры. |
check-environment-snapshot | Проверить, готов ли снимок инфраструктуры. |
request-environment-setup-actions | Запросить действия пользователя, блокирующие настройку инфраструктуры, например добавление секрета. |
Значения kind событий дашборда из get-events и из batch-fetch-details с include_events:
kind | Значение |
|---|---|
setup_started | Началась настройка инфраструктуры. |
setup_completed | Настройка инфраструктуры завершена. |
setup_failed | Не удалось выполнить настройку инфраструктуры. |
pr_created | Pull request открыт. |
pr_creation_failed | Не удалось создать pull request. |
artifact_created | Загружен артефакт пошагового обзора. |
mcp_auth_error | Аутентификация сервера MCP не удалась; его инструменты были пропущены, а запуск продолжился. |
Типичный процесс диагностики: run-info → get-events → environment-info → list-cloud-agents → batch-fetch-details (задайте include_events, если нужны события дашборда других запусков).
Подписки
Задачи агента редко заканчиваются последним коммитом. Нужно дождаться успешного прохождения CI. Ревьюеры оставляют комментарии. Коллеге нужно ответить на вопрос в Slack. Подписки позволяют облачному агенту ждать этих событий и продолжать работу, когда они происходят, без необходимости снова отправлять промпт.
Агент подписывается на источник событий, завершает текущий шаг и активируется при поступлении подходящего события. События появляются как дополнительные сообщения в том же диалоге, поэтому агент продолжает работу с полным контекстом:
- Откройте PR, затем отвечайте на комментарии ревью и устраняйте сбои CI
- Задайте вопрос в Slack и продолжите работу, когда кто-то ответит
- Проверьте статус длительной задачи с помощью таймера
Чтобы подписаться, опишите, чего нужно дождаться, в промпте. Например: «открой PR и поддерживай CI в зелёном состоянии» или «спроси в #releases и дождись одобрения». Можно также вызвать встроенный навык /subscribe, который работает так же: укажите, за чем следить, и агент выберет подходящую подписку.
Агенты могут подписываться на события из следующих интеграций:
| Интеграция | События |
|---|---|
| GitHub | Активность pull request (комментарии, ревью и изменения статуса) для одного PR, всего репозитория или PR одного автора, а также результаты CI в ветке. Использует интеграцию с GitHub. |
| Slack | Ответы в треде, сообщения в канале и вновь созданные публичные каналы. Использует интеграцию со Slack. |
| Linear | Создание задач, изменение их статуса и новые комментарии к задачам. Использует интеграцию с Linear. |
| Таймеры | Определённый момент времени: разовое напоминание с задержкой или регулярное расписание cron. Регулярные циклы также доступны как встроенный навык /loop. |
Как работают подписки
- Подписки привязаны к одному диалогу с агентом. События активируют этого агента, отправляя ему follow-up сообщения.
- Близко следующие друг за другом события объединяются. Несколько таких событий могут активировать агента один раз, после чего перед выполнением действий он повторно считывает источник (PR, тред или issue).
- Подписка действует не более 180 дней. Когда ожидание заканчивается, агенты также сами отменяют подписку.
Исправление сбоев CI
Облачные агенты автоматически пытаются исправлять сбои CI в PR, которые они создают. В настоящее время поддерживается только GitHub Actions.
Облачные агенты пропускают автоматические follow-up по CI, если:
- Вы отправили новый коммит в ветку; облачные агенты не исправляют автоматически сбои CI в коммитах, сделанных человеком.
- Вы отправили агенту follow-up сообщение.
- Та же самая проверка уже не проходит в базовом коммите PR.
- В PR уже было 10 follow-up по сбоям CI.
Чтобы отключить эту функцию для всех ваших личных облачных агентов, перейдите в Cursor Dashboard → Cloud Agents → My Settings и отключите опцию "Automatically fix CI Failures".
Чтобы отключить эту функцию для конкретного PR, созданного облачным агентом, вы можете оставить комментарий @cursor autofix off в PR. Чтобы снова включить её, оставьте комментарий @cursor autofix on.
Если вы хотите, чтобы облачные агенты исправляли сбои CI в ваших собственных PR, вы можете просто попросить их об этом, как обычно упомянув Cursor в комментарии. Например, @cursor please fix the CI failures или @cursor fix the CI lint check failure.
Автоматическое исправление сбоев CI в настоящее время доступно только в Teams; поддержка для аккаунтов вне Teams появится уже скоро. Пока что, если вам нужно похожее поведение, вы можете явно попросить облачного агента отслеживать и исправлять сбои CI в PR.
Токены идентификации OIDC
ВМ облачного агента под управлением Cursor могут получать краткосрочные JWT OIDC через локальный сокет. Агенты используют их, чтобы получать облачные роли или вызывать внутренние API без хранения долгосрочных ключей. См. Токены OIDC.
Метаданные Agent
Тот же сокет также предоставляет метаданные Agent. Агенты, хуки и скрипты могут получать идентификатор Agent, владельца, текущий этап и рабочую область в виде обычного текста.
