Почему облачным агентам для кода нужна собственная инфраструктура
Cursor описала облачных агентов как следующий этап развития AI-кодинга: они работают в отдельных виртуальных машинах, получают собственные зависимости, доступ к сети и могут выполнять задачи параллельно без постоянного присутствия пользователя. Такой агент уже ближе к удалённому инженерному процессу, чем к привычному ассистенту в редакторе кода. Он должен не просто предложить патч, а собрать окружение, запустить проверки, пережить сбой и вернуться с результатом.
Последние два года продукты для программирования часто объясняли через качество модели: лучше пишет функции, точнее понимает репозиторий, быстрее предлагает правки. Опыт Cursor показывает другое узкое место. Даже сильная модель теряет ценность, если у неё нет рабочей среды, нужных секретов, доступа к зависимостям и способа убедиться, что код действительно запускается.
Среда разработки стала частью продукта
Ключевой вывод Cursor: качество облачного агента сильно зависит от того, насколько полно воссоздана среда разработки. Локальный агент получает многое «бесплатно» с ноутбука разработчика: уже настроенные инструменты, зависимости, доступы, переменные окружения, привычную структуру проекта. В облаке всё это приходится собирать заново, и ошибка в настройке часто проявляется не как явный сбой, а как ухудшение результата. Агент вроде бы работает, но не может проверить код, запустить тесты или достучаться до нужного сервиса.
Поэтому Cursor всё больше строит вокруг агента полноценную рабочую среду. В майском обновлении компания отдельно описывала поддержку нескольких репозиториев, настройку окружения через Dockerfile, безопасную работу с секретами, версионирование окружений, журналы аудита и правила исходящего сетевого доступа. Там же заявлено, что пересборка образов с попаданием в кэш стала быстрее на 70%.
Эта деталь важнее, чем кажется. Для небольшого проекта агенту часто хватает одного репозитория и простых команд. В корпоративной разработке изменение может проходить через несколько сервисов, внутренние пакеты, закрытые API, тестовые базы и сборочные системы. Если облачный агент не видит эту инфраструктуру, он превращается в генератор патчей без обратной связи.
Долгие задачи ломают привычную надёжность
Облачный агент полезен там, где задача занимает часы, а не минуты: миграция кода, исправление тестов, расследование ошибки, подготовка pull request после изменения в нескольких местах. Локальный ассистент ограничен сессией пользователя и ресурсами компьютера. Облачный агент запускается в изолированной виртуальной машине и может продолжать работу, пока ноутбук закрыт.
Но длительная работа создаёт другой класс проблем. Cursor пишет, что ранняя архитектура с рабочими узлами, которые подхватывали задачи и доводили агентский цикл до конца, оказалась хрупкой: бета облачных агентов держалась примерно на уровне одного «9» надёжности. После перехода на Temporal компания превысила два «9» и получила агентские запуски, которые могут переживать сбои провайдеров моделей, остановку и возобновление контейнеров, а также задачи длиной в дни или недели.
Temporal здесь нужен как слой устойчивого выполнения: система сохраняет состояние процесса и позволяет продолжить работу после сбоя инфраструктуры, сетевой ошибки или перезапуска. В документации Temporal такой подход описан как выполнение, которое восстанавливается с последнего состояния даже через секунды, дни или годы после отказа.
Для пользователя разница видна не в терминах, а в результате. Агент, который три часа переписывал тесты и упал на последнем шаге, не должен начинать всё заново. Он должен понять, где остановился, восстановить контекст и продолжить работу без потери уже сделанных изменений.
Агент, машина и диалог больше не одно целое
У локального ассистента всё обычно связано в один поток: диалог, состояние редактора, контекст проекта и агентский цикл живут рядом. В облаке эта схема быстро перестаёт работать. Один агент может стартовать локально, передать часть работы в облако, запустить подагентов на других машинах и получить результаты позже. Некоторые подагенты могут жить дольше исходной задачи или работать на другом типе вычислительного узла.
Cursor решает это разделением трёх сущностей: цикла агента, состояния машины и состояния диалога. Агентский цикл живёт в Temporal, виртуальные машины можно останавливать, возобновлять или заменять, а история общения хранится отдельным слоем. Для пользователя это выглядит как один разговор, хотя внутри система может перемещать выполнение между разными машинами и заново проигрывать часть потока после повторной попытки.
Такой подход показывает, куда движутся профессиональные AI-агенты. Они перестают быть «окном чата с инструментами» и становятся распределённой системой. У неё есть состояние, журналы событий, права, очереди, восстановление и отдельная логика отображения результата пользователю.
Жёсткая обвязка уступает место инструментам агента
В ранних версиях Cursor больше не доверяла агенту: система сама перепроверяла действия после каждой задачи, принудительно делала коммит и отправляла изменения. По мере роста возможностей моделей часть этой логики переехала из жёсткой обвязки в инструменты, которыми управляет сам агент. Например, вместо заранее зашитой поддержки нескольких репозиториев агенту можно дать описание структуры проекта, инструменты для веток и pull request, а способ выполнения оставить за ним.
Этот переход выглядит здраво, но у него есть граница. В задачах, где агент управляет браузером или экраном, Cursor всё ещё использует отдельный тип подагента, маршрутизацию моделей, специальные промпты и запись экрана. Компания прямо признаёт: модели пока не готовы полностью брать такие действия на себя, хотя агент уже может решать, когда вызвать этот режим.
Здесь хорошо видна разница между маркетингом и рабочей системой. Обещание «агент всё сделает сам» звучит эффектно, но зрелый продукт часто устроен наоборот: агенту дают больше свободы там, где модель уже справляется, и оставляют направляющие конструкции там, где ошибка слишком дорогая или плохо наблюдаемая.
Автономность требует другой культуры промптов
Облачным агентам нужны более автономные инструкции, чем локальным. Если локальный ассистент остановился и ждёт разрешения, пользователь быстро это заметит. В облаке агент может простоять без движения несколько часов, пока человек вернётся к задаче. Поэтому Cursor поощряет поведение, при котором агент меньше блокируется на уточнениях и активнее продвигает задачу сам.
Это меняет роль промпта. Для обычного чат-ассистента хорошая инструкция часто описывает желаемый ответ. Для облачного агента она должна задавать рабочие границы: какие действия разрешены, когда открывать pull request, какие проверки считать обязательными, где останавливаться и как отчитываться о неудаче. В противном случае агент может выглядеть «осторожным», но фактически будет простаивать.
Самовосстановление станет проверкой зрелости
Следующий шаг Cursor формулирует как самовосстанавливающиеся окружения. Агент должен уметь сообщать, что ему не хватает секрета, что сеть заблокирована или что среда мешает выполнить задачу, а затем пытаться исправить ситуацию доступными способами. В связанном исследовательском посте компания описывала autoinstall: систему, где модели помогают автоматически настраивать рабочие окружения для репозиториев и проверять, что команды запускаются.
Это одна из самых важных линий развития. Пока агент просто падает при отсутствии зависимости, команда вынуждена чинить окружение вручную. Когда агент умеет диагностировать причину и предложить корректировку, облачный AI-кодинг становится ближе к производственному процессу, а не к эксперименту в отдельной вкладке.
Командам стоит оценивать не демо, а операционный контур
Главный вывод из материала Cursor простой для практики: облачный агент для кода стоит оценивать по операционным признакам. Умеет ли он работать с настоящей средой разработки? Может ли запускать тесты? Есть ли журнал действий? Можно ли ограничить доступ к сети и секретам? Что произойдёт при сбое модели, контейнера или облачного узла? Поддерживает ли система несколько репозиториев и долгие задачи?
Для одиночного разработчика часть этих вопросов может казаться лишней. Для команды они быстро становятся основными. Агент, который пишет хороший код в демо, ещё не готов к работе с внутренними сервисами, секретами, сборками, проверками безопасности и долгими цепочками исправлений. Cursor фактически показывает, что следующий этап конкуренции в AI-кодинге будет идти вокруг инфраструктуры: кто лучше встроит агента в реальный инженерный процесс, тот получит больше доверия от команд.
