Coding agent, которому больше не нужен программист, чтобы начать работу
Как Subscriptions, /goal и persistent modes превращают Cloud Agent из исполнителя по prompt в event-driven worker.

Prompt больше не обязан запускать каждый цикл

19 августа 2026 года Cursor выпустил обновление Cloud Agents and Cursor Harness Improvements. В нём сразу несколько связанных возможностей: Subscriptions на события, долгоживущие цели через /goal, Skills в роли Custom Modes, subagents на отдельных виртуальных машинах и steering работающего агента без обрыва текущего действия.

По отдельности это похоже на набор улучшений harness. Вместе они меняют способ запуска работы:

Раньше

Developer → prompt → agent → result

Теперь

PR / Slack / timer → agent wakes up
                     ↓
                observe → act → wait
                     ↑             ↓
                     └──── event ──┘

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

Subscriptions превращают событие в продолжение работы

Cloud Agent может следить за pull request, Slack thread или scheduled task. Когда в источнике появляется событие, тот же агент просыпается и продолжает conversation. Cursor отдельно отмечает: Cloud Agents автоматически подписываются на созданные ими PR, исправляют CI и реагируют на bot comments.

Раньше failure после push проходил через человека:

CI failed
   ↓
developer notices
   ↓
opens agent
   ↓
retells context
   ↓
agent continues

Теперь PR может сам вернуть задачу исполнителю. Это не просто более удобная notification. Событие становится частью agent loop, а conversation сохраняет цель и уже выполненную работу.

В актуальном описании Subscriptions Cursor формулирует механику ещё точнее: агент подписывается, завершает текущий turn и просыпается от подходящего event. Это важная граница — он не расходует compute, пока ждёт CI или ответ коллеги.

PR перестаёт быть финальным артефактом

Первые coding agents считали задачу завершённой после записи файлов. Затем нормой стали tests и готовый pull request. Always-on workflow отодвигает границу ещё дальше:

code written       ≠ done
tests passed       ≠ done
PR opened          ≠ done

review-ready state = useful stop condition

После открытия PR остаются checks, review comments, bot findings и merge conflicts. Если agent продолжает следить за этими состояниями, он получает не только автономность, но и ограниченное ownership: ответственность длится дольше одного запуска.

Это хорошо соединяется с Cursor Origin. Repository и PR хранят durable state, Subscription сообщает об изменении, а agent выполняет следующий шаг. Человек подключается не как транспорт между Git hosting и IDE, а в заранее выбранной контрольной точке.

Goal описывает состояние, а не одну команду

Команда /goal задаёт долгоживущий результат. Пример Cursor — исправить все flaky tests и сделать CI зелёным. Это принципиально шире инструкции «запусти TestA».

TASK
Fix TestA
      ↓
one action

GOAL
Make CI green
      ↓
observe → classify → fix → verify → repeat

Goal-driven agent похож на feedback controller: сравнивает текущее состояние с желаемым, выбирает действие, проверяет результат и продолжает, пока расхождение не исчезнет. Он может пережить несколько test runs, ожидание CI и новый комментарий, не превращая каждый переход в отдельный prompt.

Но хороший goal — это не короткий лозунг. Чем дольше работа идёт без человека, тем важнее записать контракт:

SUCCESS
CI green

CONSTRAINTS
do not skip tests
do not lower PHPStan level
preserve public API
avoid unrelated refactoring

STOP / ESCALATE
unknown business rule
unsafe migration
human review required

Без constraints агент способен честно достигнуть неправильного состояния — например, сделать CI зелёным, отключив неудобную проверку.

Умение ждать становится частью инженерной работы

В demo агенты обычно непрерывно ищут код, меняют файлы и запускают terminal. Реальный lifecycle содержит много пауз: CI ещё работает, reviewer не ответил, внешний job не завершился. Always-on agent должен не имитировать занятость, а корректно уйти в ожидание и восстановиться по событию.

work
 ↓
subscribe
 ↓
sleep
 ↓
event
 ↓
restore context
 ↓
continue

Именно здесь coding assistant начинает напоминать stateful service. Его responsibility существует, даже когда конкретная VM не выполняет tool call. Состояние держат goal, conversation, branch и PR; compute включается только на следующем полезном шаге.

Custom Mode закрепляет operating policy

Любой Skill теперь можно использовать как Custom Mode: он остаётся закреплённым в chat и удерживает агента внутри выбранного playbook. В интерактивной задаче отклонение ещё можно быстро исправить сообщением. В long-running session правила лучше сделать постоянной частью режима.

Например, режим для исправления PHP CI может содержать:

PHP CI Fixer

- не отключай tests;
- не меняй assertion без root cause;
- сначала запускай affected suite;
- затем запускай full relevant suite;
- не трогай public API;
- эскалируй неоднозначное business behavior.

/goal в такой паре отвечает за желаемое состояние, а Custom Mode — за допустимый способ его достижения. Skill перестаёт быть справкой, которую агент может случайно забыть среди logs, и становится operating policy session.

Отдельные VM делают параллелизм управляемым

Subagents в этом релизе могут работать на собственных виртуальных машинах. Каждый получает изолированную копию проекта и чистый context. Cursor предлагает использовать их для проверки изменений parent agent в свежей среде или для независимых fixes без collisions.

Для цели «сделать CI зелёным» это даёт естественное разложение:

Coordinator: CI GREEN
        │
        ├── worker A → PHPUnit failures
        ├── worker B → PHPStan errors
        └── worker C → reproduce flaky test
        │
        ▼
integrate → verify → wait for CI

Изоляция убирает конфликт рабочих директорий, но не решает coordination автоматически. Parent всё ещё должен распределить scope, принять совместимые результаты и не позволить двум workers одновременно чинить одну branch разными способами. VM — это безопасная единица исполнения, а не готовая стратегия orchestration.

Здесь особенно полезны заранее подготовленные Cursor Builds: отдельная машина имеет смысл, если worker получает рабочий environment, а не новый двадцатиминутный onboarding.

Steering корректирует траекторию, не ломая действие

Cursor также изменил поведение follow-up: сообщение можно отправить работающему агенту без немедленного interruption. Оно ждёт следующего tool call вместо обрыва текущего действия посередине.

Для long-running work это правильная семантика. Developer может добавить ограничение «legacy admin flow пока не трогай», не останавливая атомарный test run или безопасное чтение файла. На следующей границе действий агент обновит курс.

Так interaction сдвигается от микроменеджмента к supervision:

не: stop → retell → restart

а: observe → steer → agent applies at safe boundary

Это не механизм аварийной остановки. Если агент делает опасное внешнее действие, нужны permissions и отдельный hard stop. Очередь follow-up обеспечивает непрерывность работы, но не безопасность.

Практический сценарий: обновление Symfony и красный CI

После dependency upgrade в большом проекте падают 42 tests и PHPStan показывает 18 ошибок. Вместо шести ручных итераций developer задаёт goal:

Сделай CI зелёным после обновления Symfony.

Не отключай tests.
Не снижай уровень PHPStan.
Сохрани public API.
Не делай unrelated refactoring.
Остановись, если требуется изменить business behavior.

Agent классифицирует failures, делегирует независимые группы, интегрирует fixes, запускает локальные проверки и обновляет PR. Затем подписывается на CI. Новый failure будит ту же conversation; успешный прогон переводит работу в состояние review-ready.

Польза здесь не в том, что AI быстрее вводит PHP. Человек перестаёт вручную обслуживать цикл push → wait → inspect → re-prompt. Его внимание требуется для неизвестного business rule и финального review, а не для каждого технического перехода.

Always-on означает больше policy, а не меньше

Event-driven agent — недетерминированный consumer с правом менять repository. Поэтому знакомые backend-проблемы быстро становятся частью agent infrastructure:

• filtering: какие comments и failures действительно требуют запуска;
• idempotency: не обработан ли тот же event повторно;
• concurrency: не работают ли два agents над одной branch;
• backpressure: не создаёт ли fleet больше PR, чем команда способна проверить;
• permissions: где заканчиваются branch и PR и начинается человеческое approval.

Релиз Cursor даёт primitives, но конкретную policy должна определить команда. Я бы начинал с bounded autonomy:

ALLOW
read repository
run tests
create branch
update own PR
respond to CI

REQUIRE HUMAN
merge protected branch
change production data
relax quality gates
approve architectural trade-off

Так agent может самостоятельно владеть длинным обратимым loop, а необратимые и продуктовые решения остаются у человека.

Новый bottleneck — человеческое внимание

Если один developer запускает десять persistent agents, те могут одновременно принести десять PR, вопросы и review items. Compute масштабируется быстрее, чем ответственность reviewer.

Поэтому полезная метрика — не количество agent runs. Важнее доля целей, дошедших до качественного checkpoint, и стоимость человеческого внимания:

Useful throughput
= review-ready outcomes
- avoidable questions
- duplicate work
- rework after review

Always-on agent ценен, когда уменьшает supervision cost. Если он просто производит больше diff, очередь review становится длиннее, а реальная пропускная способность команды не растёт.

Prompt становится конфигурацией ответственности

Обновление 19 августа не убирает разработчика из процесса. Оно убирает его из роли обязательной кнопки Continue. Subscriptions запускают следующий цикл, /goal удерживает желаемое состояние, Custom Mode задаёт playbook, отдельные VM изолируют workers, а steering позволяет корректировать курс на границе действий.

В результате меняется единица делегирования:

Было
prompt → action

Стало
goal + policy + events
        ↓
persistent engineering responsibility
        ↓
human checkpoint

Главный тест always-on agents будет не в том, могут ли они проснуться от CI. Он будет в другом: сохраняют ли они constraints после нескольких пробуждений, умеют ли игнорировать шум, не создают ли конфликтующую работу и останавливаются ли там, где действительно требуется инженерное решение.

Если эти границы выдерживаются, coding agent перестаёт быть инструментом, который нужно вызывать перед каждым шагом. Он становится участником software lifecycle: получает ограниченную ответственность, ждёт события и самостоятельно возвращается к работе — до следующего содержательного checkpoint, а не до следующего prompt.