Cursor раскрыл уроки года разработки облачных AI-агентов

Когда Cursor запустил облачные агенты год назад, они казались прямым расширением локальных агентов. Теперь стало ясно: облачные агенты работают в другой парадигме — запускаются на собственных виртуальных машинах, работают параллельно и решают задачи, растянутые на часы и дни. Это требует совсем другого подхода к инфраструктуре.

Окружение — это продукт

Главное открытие года: качество окружения разработки — главный фактор продуктивности облачного агента. На локальной машине агент наследует ваше окружение бесплатно — вся история установок, конфиги, переменные. В облаке нужно воссоздавать всё с нуля.

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

Год назад этого не замечали — модели не могли эффективно использовать окружение. Теперь, когда GPT-семейство стало умнее, окружение стало определяющим фактором для полной производительности агента. Полное облачное окружение требует неожиданно много инфраструктуры: Инструменты для сборки и настройки agent-окружения Механизмы гибернации и быстрого возобновления VM между сообщениями Pipelines для reliable checkpoint, restore и fork образов VM Тесная интеграция с harness и клиентом — чтобы агент и человек одинаково читали и действовали в среде Плюс облачные агенты нуждаются в контролируемом сетевом доступе: открывать PR, pull зависимости, делать research.

Получилось целое направление — что-то вроде enterprise IT для агентов, с redaction секретов, network policies и управлением credentials.

От одной девятки к двум Облачные агенты открыли новый класс проблем надёжности.

Каждый агент работает на собственной изолированной VM, что позволяет запускать их параллельно и делегировать многочасовые задачи. Но это создаёт уязвимость перед outages провайдера инфера, заменой подов и отказом узлов. Изначально Cursor строили cloud agents с work-stealing архитектурой: рабочие ноды подбирали задачи и проводили их до завершения.

Эта модель сработала локально, но в облаке оказалась хрупкой — ранняя beta обеспечивала около одной девятки надёжности (90% времени работает). Когда агенты созревали, команда заметила, что переизобретает примитивы durable execution, которые уже красиво решает Temporal: retry механизмы, scheduling работы между машинами, durability при падении нод. Решили мигрировать весь agent-loop на Temporal.

Результат: надёжность выросла до двух девяток (99% uptime). Теперь Temporal обрабатывает свыше 50 миллионов действий в день на 7 миллионах рабочих потоков. Изнутри, более 40% всех PR в Cursor генерируются облачными агентами — это сам по себе показатель того, что система работает.

Что это значит Год работы облачных агентов показал: это не просто porting локального кода в облако.

Это построение целого операционного слоя вокруг агента — с полным окружением разработчика, надёжной доставкой задач и контролируемым доступом к сети. По мере того как агенты берут на себя всё больше работы, инженерная задача становится всё ясней: предоставить машине ровно то же, что есть у разработчика, и гарантировать, что она это не сломает.