Облачные агенты Cursor: 2 ограничения после релиза мая 2026

Облачные агенты Cursor 13 мая получили среды для работы с несколькими репозиториями. По данным страницы продукта Cursor, уже более 30% пул-реквестов, которые принимает компания, создают автономные агенты в облачных песочницах.

Что именно получили облачные агенты Cursor 13 мая

Главная новинка — облачные среды агентов для работы сразу с несколькими репозиториями. Теперь агент может обращаться к нескольким репозиториям внутри одной настроенной среды; основой стала поддержка multi-root workspaces, которую Cursor выпустила 24 апреля. Одну и ту же среду можно использовать в разных сессиях, поэтому при каждом новом запуске агента больше не приходится заново настраивать машину разработки.

Конфигурация задается через Dockerfile. Секреты сборки доступны только на этапе сборки и не передаются запущенному агенту. Это устраняет одну из самых частых ошибок в инфраструктуре агентов: случайно встроенный в сборку API-ключ не попадет в рабочий контекст агента. Cursor также умеет настраивать Dockerfile, анализируя инструменты и зависимости в репозиториях. Этот сценарий пока находится в закрытой бета-версии для команд Enterprise.

Наиболее заметно ускорилось кэширование слоев. При попадании в кэш сборка теперь выполняется на 70% быстрее, поскольку пересобираются только изменившиеся слои Dockerfile. Для агентов, которые регулярно запускаются в командах, это буквально разница между ожиданием и работой.

Операционным возможностям конкуренты обычно уделяют недостаточно внимания. У каждой среды есть история версий с откатом, причем запускать откат могут только администраторы. Журнал аудита фиксирует каждое действие участников команды со средами. Списки разрешенных направлений исходящего трафика и области действия секретов настраиваются для каждой среды отдельно: секрет из среды A недоступен среде B. Именно такая скучная инфраструктура нужна, прежде чем разрешать агенту открывать PR к продакшен-коду.

В анонсе Cursor приводит показательный пример Amplitude. Cursor Automations отслеживают публичные каналы Slack, разбирают сообщения о проблемах, определяют затронутые репозитории и открывают PR именно в них. Это не демонстрация, а первичная диагностика силами агента, работающего с несколькими репозиториями в реальной компании под реальной нагрузкой.

Главный аргумент — доля принятых PR внутри Cursor

По данным Cursor, уже более 30% пул-реквестов, которые принимает компания, создают автономные агенты в облачных песочницах. Здесь важен знаменатель: речь идет о принятых пул-реквестах, а не о попытках агентов. Эта цифра показывает, что весь цикл — проверка, исправления и передача результата — может завершаться без человека, вручную отправляющего каждый коммит.

Со 2 сентября 2026 года Self-Hosted Machines позволяет командам перенести редактирование файлов, терминальные команды, инструменты управления компьютером и локальное выполнение MCP на собственные воркеры. При этом цикл агента, инференс и планирование остаются в облаке Cursor. Так Cursor закрыла вопрос с выполнением в приватной инфраструктуре, но не превратилась в программируемую среду для устойчивых процессов.

Теперь различие проходит уже не между состоянием в рамках сессии и сохраняемым состоянием. Cursor хранит состояние диалогов в своем бэкенде, поэтому к запускам можно вернуться и продолжить их, а Self-Hosted Team Pools умеет восстанавливать рабочую среду после гибернации. Точная граница проходит между состоянием агента под управлением вендора и программируемым состоянием приложения. Cloudflare предоставляет отдельную базу SQLite для состояния каждого агента и шаги workflow с сохранением состояния, которыми разработчик управляет из кода.

Что уже умеет мой стек Cloudflare Workers и Agents SDK

У меня в продакшене работают шесть агентов на Cloudflare. Средой выполнения служат Workers, состояние хранится в Durable Objects с отдельной SQLite для каждого экземпляра, а длительной оркестрацией занимаются Cloudflare Workflows. Я собрал этот стек один и в одном аккаунте; подробный разбор опубликован здесь. Весь стек Cloudflare обошелся в $19.14 в апреле 2026 года. Это счет за конкретный месяц работы продакшена, а не тариф платформы. Для Cursor цена Enterprise указана как Custom; Team Pools доступны только на Enterprise, а при использовании Self-Hosted Machines к счету за собственный воркер добавляется стоимость выбранной модели.

Вот три отличия этого стека от нынешнего продукта Cursor.

Несколько репозиториев — через код. Worker может во время выполнения получать ресурсы по HTTP. Browser Run, прежде называвшийся Browser Rendering, способен управлять headless-браузером, если нужный контекст находится на сайте. Cursor оформляет доступ к нескольким репозиториям как конфигурацию многократно используемой среды; в Cloudflare получение данных, аутентификация и логика работы с репозиториями остаются на разработчике. Это не лучше и не хуже — просто другой уровень управления.

Программируемое персистентное состояние. Cloudflare Agent автоматически сохраняет состояние приложения в собственной базе SQLite и загружает его после перезапуска или гибернации. Cursor тоже сохраняет состояние диалога и позволяет продолжать запуски. Разница в контроле: хранилищем диалогов и средой агента управляет Cursor, тогда как Cloudflare дает коду прямой доступ к состоянию приложения и его схеме.

Границы шагов с сохранением прогресса, но не автоматическое выполнение exactly-once. В Workflows для каждого шага можно отдельно настроить повторы и сохранить созданное им состояние, чтобы выполнение продолжилось после сетевого или инфраструктурного сбоя. step.do принимает настройки повторных попыток для конкретного шага, NonRetryableError прекращает повторы при ошибке, не допускающей повторных попыток, а идентификатор каждого экземпляра Workflow уникален. Но один шаг может выполниться несколько раз, и Cloudflare прямо рекомендует делать вызовы с побочными эффектами идемпотентными. Преимущество здесь в задаваемом разработчиком механизме сохранения прогресса и управлении повторами, а не в автоматической защите от повторных пул-реквестов, писем или списаний.

Какие два ограничения Cursor все еще не закрыла

Ограничение 1: программируемое состояние агента под контролем заказчика. Базовую возможность продолжать работу Cursor уже реализовала: состояние диалога по умолчанию хранится бессрочно, а снимки управляемых VM хранятся до конца скользящего 90-дневного периода бездействия. Self-Hosted Machines переносит выполнение инструментов, однако цикл агента по-прежнему работает у Cursor, там же хранится диалог. Cloudflare Agent дает приложению доступ к состоянию в SQLite прямо внутри среды выполнения. Это важно, когда агент следит за инцидентами, координирует миграцию или сохраняет бизнес-состояние в ходе многодневного онбординга.

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

Ограничение 2: задаваемые разработчиком шаги с сохранением состояния. В актуальной документации Cursor по Cloud Agent и Self-Hosted Machine нет прикладного примитива, сопоставимого с шагом Workflow с сохраняемым состоянием и отдельной конфигурацией повторных попыток. У Cloudflare такой примитив есть. Разница становится существенной, когда агент для программирования затрагивает биллинг, электронную почту, развертывание или другой внешний побочный эффект.

Перенос вызовов инструментов на собственную машину этого не меняет: место выполнения становится другим, но контракт оркестрации остается прежним. Cloudflare также не гарантирует выполнение побочных эффектов exactly-once — шаг с повторными попытками все равно должен быть идемпотентным.

Это не критика Cursor, а различие категорий. Cursor — продукт для программирования, в котором выполнение инструментов может быть как управляемым, так и вынесенным на сторону заказчика. Cloudflare — программируемая среда выполнения приложений. Сентябрьский релиз сократил инфраструктурный разрыв, но граница в управлении состоянием и оркестрацией осталась.

Что основателям и CTO стоит сделать на этой неделе

Есть три типа команд — и для каждого нужен свой подход.

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

Если длительные фоновые процессы уже работают на Cloudflare или Vercel, оставьте там персистентное состояние приложения и оркестрацию. Cursor Self-Hosted Machines теперь позволяет использовать инфраструктуру Cloudflare или Vercel для выполнения инструментов, но цикл агента остается у Cursor. Полезная параллель на стороне потребительских продуктов разобрана в этом материале: Anthropic упаковывает сходные примитивы для малого и среднего бизнеса, и сближение платформ вокруг агентов заметно повсюду.

При подготовке корпоративного внедрения начните с управляемых Cloud Agents, если списки разрешений, Tailscale, AWS PrivateLink или Cloudflare Tunnel отвечают требованиям к доступу. Team Pools нужны, когда рабочая копия, выполнение инструментов, специализированное оборудование или образ воркера должны оставаться под вашим контролем. Team Pools доступны только на Enterprise с ценой Custom, а Dockerfile, настраиваемые Cursor, пока остаются в закрытой бета-версии.

Что изменилось после мая

Два важных сигнала.

Во-первых, Cursor теперь документирует состояние диалога отдельно от рабочей среды выполнения. По умолчанию оно хранится бессрочно, чтобы к запуску можно было вернуться и продолжить его; снимки управляемых VM удаляются после 90 дней бездействия, если запуск или возобновление не продлевает это окно. Базовая возможность продолжать работу больше не является пробелом. Вопросы владения и программируемости остаются.

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

Отменяет ли релиз Cursor от 13 мая необходимость в собственной инфраструктуре для агентов?

Нет. Теперь Cursor предлагает собственный путь для выполнения на вашей инфраструктуре: My Machines для личных сценариев и Team Pools для корпоративных парков. Выполнение инструментов переносится в вашу сеть, но цикл агента по-прежнему работает у Cursor, там же хранится состояние диалога. Командам, которым нужна программируемая среда выполнения приложений или шаги workflow с сохранением состояния, все еще потребуется инфраструктура для этих уровней.

Насколько ускорились кэшированные сборки облачных агентов Cursor?

После обновления кэширования слоев от 13 мая сборки с попаданием в кэш выполняются на 70% быстрее. Пересобираются только изменившиеся слои Dockerfile.

Что означает внутренняя доля принятых PR в Cursor?

На актуальной странице самой Cursor указано, что более 30% пул-реквестов, которые принимает компания, создают автономные агенты в облачных песочницах. Это важный показатель использования в продакшене: он учитывает принятые пул-реквесты, а не просто запущенные задачи.

Безопасны ли облачные агенты Cursor для кода с доступом к продакшен-секретам?

Релиз от 13 мая разделяет исходящий трафик и секреты по средам, изолирует секреты сборки от запущенного агента, а также добавляет историю версий, откат и журналы аудита. Self-Hosted Machines позволяет оставить полную рабочую копию и локальные учетные данные на вашем воркере, но необходимые фрагменты файлов, вывод инструментов, диффы, скриншоты и результаты локального MCP все равно могут отправляться в Cursor. При оценке безопасности нужно учитывать обе границы.

Можно ли использовать Cloudflare Workers и облачные агенты Cursor вместе?

Да. Cursor указывает Cloudflare как интеграцию для Self-Hosted Machines, а эталонный шаблон использует Cloudflare Worker в роли контроллера, запускающего по одному Cloudflare Container на каждый принятый запрос. Cursor может вести цикл агента для программирования, а Workers, Durable Objects и Workflows — обеспечивать долговечное состояние приложения и оркестрацию. Теперь продукты пересекаются на уровне выполнения инструментов, но не на границе цикла агента.