Что именно изменилось

До этого облачные агенты Cursor выполняли код на серверах самого Cursor. Теперь можно оставить планирование и рассуждения агента в облаке компании, а фактическое выполнение кода перенести на инфраструктуру, которой управляете вы сами - от личного ноутбука до кластера на AWS Lambda или Cloudflare.

Как устроена архитектура

По официальному описанию, воркер (worker) - это процесс, который устанавливает долгоживущее исходящее HTTPS-соединение к облаку Cursor. Никаких входящих подключений в вашу сеть не требуется - не нужно открывать порты, менять настройки фаервола или поднимать VPN-туннели. Когда пользователь запускает сессию агента, движок Cursor занимается планированием и инференсом, а затем отправляет конкретные вызовы инструментов воркеру для выполнения на вашей машине. Результаты возвращаются в Cursor для следующего раунда рассуждений.

My Machines и Pools: два варианта под разные задачи

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

Компьютерное управление и список инфраструктурных партнёров

На воркерах с установленными зависимостями (Chrome или Chromium) агент способен на полноценное компьютерное управление на Linux и Mac: кликать по элементам интерфейса, делать снимки экрана и управлять браузером напрямую. В списке официально поддерживаемых инфраструктурных партнёров для запуска воркеров - AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace и Vercel.

Что на самом деле остаётся локальным

Здесь важна точность формулировок. Многие пересказы этой новости говорят, что «код и секреты остаются полностью локальными» - но сам официальный материал Cursor формулирует это осторожнее: результаты работы инструментов «могут содержать код», а транскрипты работы агента «могут обрабатываться и храниться Cursor». То есть локально теперь именно выполнение кода - оно происходит на вашей машине или в вашей инфраструктуре, - а не вся цепочка обработки данных агента: итоги выполнения и переписка с агентом всё равно возвращаются в облако Cursor для дальнейшей работы. Перед тем как переносить чувствительные проекты на Self-Hosted Machines, стоит явно проверить актуальную политику обработки данных Cursor, а не полагаться на пересказы в духе «теперь всё приватно».

Частые вопросы
Что именно переносится на свою инфраструктуру в Self-Hosted Machines?
Выполнение кода агентом - планирование и рассуждения остаются в облаке Cursor, а конкретные вызовы инструментов выполняются на вашем воркере.
Нужно ли открывать порты или настраивать VPN для подключения воркера?
Нет, воркер сам устанавливает исходящее HTTPS-соединение к облаку Cursor, входящих подключений в вашу сеть не требуется.
В чём разница между My Machines и Pools?
My Machines - это подключение одного личного ноутбука или виртуальной машины, а Pools - именованные очереди воркеров для команд с автоматическим масштабированием.
Может ли агент управлять браузером на воркере?
Да, на Linux и Mac воркерах с установленными зависимостями (Chrome или Chromium) агент может кликать, делать снимки экрана и управлять браузером.
Какие облачные провайдеры официально поддерживаются для воркеров?
AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace и Vercel.
Значит ли это, что код и данные никогда не попадают в облако Cursor?
Нет - сам официальный материал уточняет, что результаты работы инструментов могут содержать код, а транскрипты работы агента могут обрабатываться и храниться Cursor. Локально теперь именно выполнение, а не вся цепочка обработки данных.
Источники (1)
  1. Run cloud agents on machines you manage - Cursor
← Все статьи блога