Локальные ИИ-агенты Cursor: запуск инструментов внутри сети

Обновление Cursor от 2 сентября 2026 года одновременно сдвигает границу безопасности и переносит расходы на инфраструктуру: локальные ИИ-агенты позволяют команде оставить запуск инструментов на подконтрольных ей машинах, но теперь за эти воркеры отвечает сама команда. Модель, планирование и цикл агента по-прежнему работают в облаке Cursor.

Как устроены локальные ИИ-агенты Cursor

Cursor Cloud Agent состоит из двух частей. Цикл агента определяет следующий шаг и обращается к модели. Выполнение инструментов — это редактирование файлов, запуск команд в терминале, работа с браузером, обращение к локальному MCP-серверу и внутренним сервисам.

Функция Cursor Self-Hosted Machines разделяет эти части. Цикл агента, инференс, планирование, интерфейс и управление сессией остаются на стороне Cursor. Инструменты выполняет воркер под вашим управлением.

В роли такого воркера может выступать ноутбук, виртуальная машина, Mac, pod в Kubernetes или песочница интеграционного партнёра. Воркер устанавливает исходящее HTTPS-соединение с Cursor, получает вызовы инструментов, выполняет их локально и возвращает результаты. Открывать входящий порт или назначать воркеру публичный IP-адрес не требуется.

Распределение ответственности выглядит так.

Cursor предлагает два варианта воркеров. My Machines привязывает машину к аккаунту одного пользователя и подходит для devbox или узкого персонального сценария. Team Pools — именованные очереди для команд на тарифе Enterprise. Запрос ждёт в пуле, пока его не заберёт свободный воркер; каждый воркер пула обслуживает одну сессию Cloud Agent за раз.

Это не on-premise-версия Cursor, а разделённая среда выполнения, где исполняющая часть принадлежит заказчику. Именно это различие определяет, соответствует ли функция требованиям вашей политики безопасности.

Что остаётся внутри сети, а что по-прежнему уходит наружу

Полная рабочая копия репозитория, кеш сборки и локальные учётные данные остаются на вашем воркере. Там же выполняются команды, операции с репозиторием, сборки и обращения к внутренним сервисам. Благодаря этому больше не обязательно копировать весь репозиторий в VM для выполнения задач под управлением поставщика.

Но для принятия решений агенту всё равно нужен контекст. Во время сессии воркер отправляет Cursor содержимое нужных агенту файлов, вывод терминала, диффы, снимки экрана, результаты локального MCP и метаданные маршрутизации. Снимки экрана, видео и ссылки на логи также могут загружаться в хранилище артефактов под управлением Cursor, чтобы отображаться в pull request и на панели управления.

Хост артефактов можно заблокировать, не останавливая агента, однако тогда артефакты исчезнут из pull request и панели управления. Действует и Privacy Mode: ни Cursor, ни её поставщики моделей не используют отправленный с воркера код для обучения. Но офлайн-сессию этот режим не создаёт.

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

Кому это подходит и что для них изменится

Корпоративная backend-команда с внутренними сервисами

Backend-команде могут понадобиться приватный реестр пакетов, staging-база данных и эндпоинты сервисов, недоступные из управляемой VM. Team Pool можно разместить в той же контролируемой сети и запускать сборку, не открывая входящий маршрут со стороны Cursor.

Главное преимущество здесь — контроль доступа, а не автоматическая приватность. Платформенная команда сможет использовать действующие сетевые политики и хранилище секретов, а служба безопасности — точно проверить, какие результаты уходят через исходящее соединение.

iOS-команда, которой нужны Mac

Cloud Agents под управлением Cursor работают на VM с Ubuntu. Команда, которой для iOS-разработки требуется оборудование Mac, может зарегистрировать Mac как воркеры, выдать необходимые права на управление компьютером и позволить агенту нажимать элементы интерфейса, вводить текст, делать снимки экрана или работать с браузером на этой машине.

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

Платформенная команда с неравномерной нагрузкой от агентов

Платформенная команда может подключить Cloudflare Containers к Team Pool. Эталонный шаблон запускает отдельный изолированный контейнер для каждой полученной сессии, использует Durable Object для управления этим контейнером и умеет кешировать снимки репозитория в R2.

Пул продолжает существовать, даже когда к нему не подключён ни один воркер, поэтому ресурсы можно масштабировать до нуля. Когда появляется новая работа, контроллер забирает запрос и запускает контейнер. В результате вычислительные расходы следуют за фактической нагрузкой, а постоянно прогретый парк машин не нужен.

Самостоятельный разработчик с devbox и локальным состоянием

My Machines подходит разработчику, чей проект зависит от локальных инструментов или состояния, которое пришлось бы долго воссоздавать. Одну машину могут совместно использовать несколько агентов: для личного компьютера это удобно, а для задач с чувствительными данными — повод насторожиться.

Преимущество — быстрый запуск. Риск — остаточные данные между сессиями, поскольку Cursor не стирает и не пересобирает ваш ноутбук после каждого запуска. За рабочую директорию, учётные данные, остановку процессов и состояние машины отвечаете вы.

Рабочая конфигурация Cloudflare

Вариант с Cloudflare полезен тем, что наглядно показывает новую границу ответственности. Для него нужны Cursor Enterprise, ключ сервисного аккаунта команды с правами агента, аккаунт Cloudflare на платном тарифе Workers Paid с доступом к Containers и R2, Node.js 20 или новее, а также Docker.

1. 1

   Зарегистрируйте Team Pool

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

   curl https://cursor.com/install -fsS | bash
   agent --version
   export CURSOR_API_KEY="<team service-account API key>"
   CURSOR_API_KEY="$CURSOR_API_KEY" agent worker --pool cloudflare-test start

   Когда пул появится, остановите воркер сочетанием Ctrl+C, а затем выполните unset CURSOR_API_KEY. На время тестирования Cloudflare не запускайте локальный воркер снова, иначе он может первым забрать запрос.

2. 2

   Разверните эталонный шаблон Cursor

   Клонируйте шаблон, установите зависимости, войдите в Cloudflare и создайте необязательный бакет для снимков.

   git clone https://github.com/anysphere/cloudflare-workers.git
   cd cloudflare-workers
   npm install
   npx wrangler login
   npx wrangler r2 bucket create cursor-pool-worker-snapshots

3. 3

   Сохраните учётные данные

   Поместите ключ сервисного аккаунта Cursor в секреты Worker. Добавляйте учётные данные Git, только если контейнерам нужен доступ к приватным репозиториям.

   npx wrangler secret put CURSOR_API_KEY
   npx wrangler secret put GIT_USERNAME
   npx wrangler secret put GIT_TOKEN

   Личный API-ключ Cursor не подходит для Team Pool. Это та ошибка настройки, которую проще всего принять за сбой инфраструктуры: контроллер возвращает 401.

4. 4

   Настройте пул и его ёмкость

   В wrangler.jsonc измените значение CURSOR_POOL на cloudflare-test. Для containers[].max_instances укажите максимальное число параллельных сессий, которое вы готовы обслуживать, а не количество разработчиков в команде.

   По умолчанию в эталонном файле для max_instances задано 10, а контейнер standard-1 получает 0.5 vCPU, 4 GiB памяти и 8 GB диска. Для реальных сборок может потребоваться более мощная конфигурация.

5. 5

   Разверните систему и проследите за первым запуском

   Выполните развёртывание, затем держите открытыми панели контроллера и контейнеров, пока запускаете Cloud Agent и выбираете self-hosted-пул.

   npx wrangler deploy
   npx wrangler tail
   npx wrangler containers list

   Первый запланированный запуск контроллера может начаться только через пять минут. Если сессия, которую контроллер забрал из очереди, не запускается, обычно причину следует искать в ёмкости контейнеров, клонировании репозитория или учётных данных Git.

Расходы переместились, а не исчезли

Инфраструктура выполнения включена в управляемые Cloud Agents от Cursor. При использовании Self-Hosted Machines выбранная модель по-прежнему оплачивается по тарифам Cursor, а к этой сумме добавляется стоимость ваших воркеров. Для Team Pools также нужен контракт Enterprise с индивидуальной ценой.

На примере Cloudflare видно, как формируется эта дополнительная статья расходов. Продукт Containers доступен в рамках тарифа Workers Paid за $5 в месяц. В него включены 25 GiB-часов памяти, 375 vCPU-минут и 200 GB-часов диска. Сверх лимита память стоит $0.0000025 за GiB-секунду, активный CPU — $0.000020 за vCPU-секунду, а выделенный диск — $0.00000007 за GB-секунду.

Возьмём конфигурацию standard-1 из эталонного шаблона и смоделируем 100 сессий: каждая работает один час, полностью использует доступный CPU во время активности, а затем проходит пятиминутное окно простоя из шаблона. После вычета включённых ресурсов контейнеры обойдутся примерно в $12 за месяц:

$5 plan + $3.15 CPU + $3.675 memory + $0.168 disk = $11.993

Это лишь пример расчёта инфраструктуры, а не полный счёт от Cursor. Сюда не входят расходы на Worker и Durable Object, логи, исходящий трафик, R2, контракт Enterprise, модель и работа специалистов, обслуживающих парк. Расчёт также предполагает, что минимальной конфигурации из шаблона достаточно. Для репозитория с ресурсоёмкой компиляцией может понадобиться более крупный контейнер.

Самым дорогим решением нередко оказывается не посекундный тариф, а политика поддержания прогретых ресурсов. Стандартный воркер пула Cursor использует окно переподключения длительностью 3,600 секунд, тогда как шаблон Cloudflare сокращает его до 300 секунд. При длинном окне повторные промпты обрабатываются быстрее, но выделенные память и диск дольше тарифицируются. Короткое окно экономит на простое, однако приводит к большему числу холодных запусков.

За ёмкость тоже отвечаете вы. В шаблоне предусмотрено до 10 одновременно работающих контейнеров. Следующий запрос будет ждать или не запустится, если исчерпана заданная ёмкость или лимит аккаунта либо недоступен базовый хост. Cursor умеет направлять работу в пул, но не может создать ресурсы, которые вы не выделили.

С изоляцией действует тот же принцип. В шаблоне Cloudflare каждая сессия получает собственный контейнер. На персональной машине несколько агентов могут работать на одном хосте. Если политика требует новую VM, очищенный диск, разделение арендаторов или чистую границу секретов после каждого запуска, реализовать и проверить это придётся вам.

Обновления превращаются в отдельный операционный календарь. Команда отвечает за базовый образ, Cursor CLI, инструменты сборки, сертификаты, зависимости и развёртывание новых версий. В Cloudflare публикация нового образа контейнера останавливает работающие контейнеры, поэтому обновление придётся отложить до завершения активных сессий либо согласиться на их прерывание.

Что делать сейчас

Действуйте уже на этой неделе, если Cloud Agent нужны нестандартное оборудование, собственный образ или доступ к инструментам, который не может обеспечить управляемая сеть. Начните с небольшого пула и репозитория с низким уровнем риска. Не исключайте из проверки безопасности обработку данных моделью и результаты работы инструментов, возвращаемые в Cursor: перенос исполнения не устраняет ни то ни другое.

Подождите, если единственное требование — доступ к приватному репозиторию или внутреннему сервису. Прежде чем брать на себя парк воркеров, Cursor рекомендует попробовать управляемые среды, сетевые средства контроля, Tailscale, AWS PrivateLink или Cloudflare Tunnel. В этих вариантах жизненный цикл хоста и изоляция остаются на стороне Cursor.

Если управляемые Cloud Agents уже соответствуют политике и воспроизводят вашу сборку, для вас ничего не меняется. Self-hosting не добавляет модели новых возможностей — он меняет место выполнения и владельца операционной ответственности.

Практическая задача на понедельник: выберите один репрезентативный репозиторий, зафиксируйте, какие фрагменты кода, секреты, результаты инструментов и артефакты могут пересекать границу, а затем запустите одну и ту же сборку в управляемом агенте и в self-hosted-пуле с жёстким лимитом. Запишите время ожидания в очереди, контейнеро-часы, принятые изменения, ошибки очистки и время на поддержку образа. Одобряйте парк только в том случае, если дополнительный контроль оправдывает второй счёт.

Получайте следующие практические разборы рабочих процессов с ИИ в рассылке.