Cursor Long-running Agents: что происходит, когда задача длится не пять минут
Почему многочасовой автономной работе нужны границы, stop conditions, checkpoints и проверяемый контракт.

Что Cursor выпустил 12 февраля

12 февраля 2026 года Cursor открыл research preview Long-running Agents для тарифов Ultra, Teams и Enterprise. Новый режим рассчитан на задачи, которые занимают часы или дни: агент сначала предлагает план, ждёт approval и только затем начинает реализацию.

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

В research preview были запуски на 25, 30 и 36 часов. Cursor также сообщает о более крупных PR с merge rate, сопоставимым с другими агентами. Это данные самой компании, а не независимый benchmark, но масштаб хорошо показывает новую проблему: через сутки уже поздно уточнять то, что нужно было написать в задаче до старта.

Пять минут и пять часов — разные режимы работы

Запрос «добавь правило email в UserRequest» почти не требует управления. Агент откроет один класс, изменит validation и запустит узкий тест. Ошибка будет дешёвой: маленький diff легко прочитать и переделать.

Перевод уведомлений с синхронной отправки на очередь проходит через controllers, services, jobs, Redis, retry policy, failed_jobs и тесты. Появляется десяток промежуточных решений. Каждое может быть локально разумным и при этом уводить работу от исходной цели.

ошибка в research
      ↓
неточный план
      ↓
неподходящая архитектура
      ↓
20 согласованных между собой файлов
      ↓
тесты подтверждают неправильное поведение

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

Почему planning-first здесь обязателен

Cursor заставляет long-running agent показать план и дождаться подтверждения. Для короткого фикса это задержка. Для изменения нескольких подсистем — самый дешёвый checkpoint во всём процессе.

Допустим, агент предлагает добавить soft delete пользователям через deleted_at, глобальный scope и новый restore endpoint. На ревью плана выясняется, что проект уже моделирует удаление статусом, а восстановление не входит в продукт. Исправить три пункта плана занимает минуты. Удалять migration, endpoint и переписанные тесты через несколько часов намного дороже.

Вместо prompt нужен контракт задачи

Фраза «переведи уведомления на очередь» не объясняет, какие сообщения входят в работу, можно ли менять API и когда агент должен остановиться. Я собираю постановку из пяти блоков:

GOAL               зачем меняем систему
IN SCOPE           что агент обязан затронуть
OUT OF SCOPE       куда расширяться нельзя
CONSTRAINTS        каким способом решать допустимо
DEFINITION OF DONE как доказать завершение

GOAL и DEFINITION OF DONE не дублируют друг друга. Первый задаёт направление: письма должны уходить асинхронно. Второй фиксирует наблюдаемый результат: jobs попадают в существующую Redis-очередь, retries настроены, публичный API не изменился, нужные тесты проходят.

OUT OF SCOPE часто полезнее длинного списка пожеланий. Без него агент найдёт deprecated transport, старый NotificationService и неудобную конфигурацию, после чего превратит миграцию одной группы писем в рефакторинг всего модуля.

Сначала поведение, затем тесты

Тесты хорошо удерживают длинную работу в границах, если ожидаемое поведение записано до реализации. Для ограничения API-токенов это четыре сценария: создание при нуле и четырёх активных токенах, отказ при пяти, разрешение при пяти записях, если одна отозвана.

Иначе появляется drift: исходная цель «исправить бизнес-правило» незаметно превращается в «сделать текущий тест зелёным». Самый опасный короткий путь — изменить assertion под получившееся поведение. Suite проходит, ошибка остаётся.

С очередями есть ещё одна ловушка. Queue::fake() доказывает dispatch job, но не проверяет сериализацию payload, работу handle() и взаимодействие с реальным transport. Для длинного рефакторинга я потребую и feature-тест отправки, и проверку самого handler. Иначе агент завершит задачу на половине маршрута.

Stop conditions защищают от уверенного гадания

Команда «работай, пока не решишь» звучит автономно, но плохо работает с задачами без достаточных данных. Причину случайного production slowdown нельзя гарантированно найти по локальному коду, если нет нужных метрик и логов.

До запуска я перечисляю ситуации, в которых агент обязан остановиться:

• нужно менять публичный API или схему данных за пределами согласованного плана;
• требуется новая инфраструктурная зависимость либо доступ к production;
• ошибку невозможно воспроизвести после оговорённых диагностических шагов;
• решение выходит за scope или противоречит правилам проекта.

Хороший результат в такой точке — не случайный patch, а отчёт BLOCKED: что проверено, какие гипотезы исключены, каких данных не хватает и какое решение требуется от человека. Способность вовремя остановиться для автономного агента не менее важна, чем способность продолжать.

Checkpoints без микроменеджмента

Если человек подтверждает каждый shell command, long-running режим теряет смысл. Но и маршрут START → DONE на сутки слишком непрозрачен. Работу лучше разделить на checkpoints разных типов.

HUMAN
research + architecture plan → approval

AUTOMATIC
implementation → focused tests → static analysis

SELF-CHECK
git diff → original plan → Definition of Done

HUMAN
final report + risks → review

Человек принимает решение там, где меняется архитектура или граница продукта. Тесты автоматически проверяют механические инварианты. Перед завершением агент снова сравнивает работу с исходным планом, а не только с последним упавшим тестом.

Изоляция и разрешения нужно задать заранее

Многочасовая задача способна оставить migration, конфигурацию и десятки файлов. Поэтому агент должен работать в отдельной ветке или worktree. Неудачный результат тогда удаляется вместе с изолированной рабочей областью, а не вычищается из общей ветки вручную.

Права тоже являются частью постановки. Чтение репозитория, редактирование и локальные тесты обычно можно разрешить автоматически. Установка dependencies, сетевой доступ и миграции требуют отдельной политики. Production database и deploy для такого эксперимента я бы запретил полностью.

READ / EDIT / TEST      ✓
COMPOSER INSTALL        approval
NETWORK                 allowlist
LOCAL MIGRATION         по плану
DEPLOY / PRODUCTION DB  ✗

Рассчитывать на кнопку Stop рискованно: смысл режима как раз в том, что разработчик закрывает ноутбук и возвращается позже.

Mini-spec для Laravel-задачи

Так я бы поставил задачу по переводу транзакционных писем на очередь в Laravel 13:

GOAL
Отправлять письма заказов и платежей асинхронно.

IN SCOPE
- существующая Redis queue
- jobs, retries, backoff, failed jobs
- тесты dispatch и handler

OUT OF SCOPE
- newsletter и push
- redesign NotificationService
- admin UI и monitoring dashboard

CONSTRAINTS
- новые dependencies не добавлять
- публичный API не менять
- dispatch выполнять after commit
- повторная доставка не должна дублировать эффект

DONE WHEN
- синхронная отправка для указанных писем удалена
- failure и retry сценарии покрыты
- existing suite и PHPStan проходят

STOP IF
- нужна новая queue topology
- требуется production configuration
- idempotency нельзя обеспечить в текущей модели данных

BEFORE CODE
Восстановить текущий flow и предложить план.

Здесь остаётся пространство для инженерного решения, но нет свободы тихо перепроектировать весь notification module. Особо я выделил after commit: worker не должен получить job раньше, чем транзакция с заказом станет видна другой connection.

Большому diff нужен отчёт, а не стенограмма

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

Финальный отчёт должен быть коротким и проверяемым:

• какой flow исследован и какое решение выбрано;
• какие файлы и публичные контракты изменены;
• какие команды прошли и какие failures агент исправил;
• как закрыт каждый пункт Definition of Done;
• какие риски и вопросы остались человеку.

Размер PR не является достоинством сам по себе. Cursor приводит пример собственного десяти-тысячестрочного изменения и сообщает о крупных merged PR, но для команды цель прежняя: полностью решить задачу, удержать scope и оставить diff, который можно проверить.

От prompt engineering к task engineering

Для первого эксперимента я бы не отдавал агенту весь legacy-монолит. Лучше выбрать изменение на несколько часов: аудит одной сущности, перенос группы jobs или рефакторинг одного application module. После результата оценивать нужно не объём кода, а места, где работа отклонилась от цели: где не хватило ограничения, какой checkpoint обнаружил бы ошибку раньше, что следовало добавить в stop conditions.

Long-running Agents интересны тем, что делают цену постановки задачи видимой. Чем реже человек вмешивается в выполнение, тем точнее до старта должны быть цель, границы, проверки, разрешения и условия остановки.

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