Cursor Automations: coding agent запускается сам

У агента появился собственный момент старта

5 марта 2026 года Cursor представил Automations — always-on cloud agents, которые запускаются по расписанию или после внешнего события. Триггером могут быть Slack, Linear, GitHub, PagerDuty и webhook. После срабатывания Cursor поднимает cloud sandbox, подключает выбранные модели и MCP-инструменты, передаёт инструкции и даёт агенту доступ к memory предыдущих запусков.

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

раньше
developer → prompt → agent → work

теперь
event → automation → agent → work → human checkpoint

Человек не исчезает из процесса. Он перемещается из точки запуска к точке контроля результата.

Даже автономный агент оставался реактивным

Coding agent уже умеет исследовать repository, строить план, менять несколько файлов и исправлять тесты. Long-running Agents могут удерживать такую работу часами. Но почти всегда первый шаг делал разработчик: выбирал проблему и нажимал условную кнопку Start.

Это ограничивало место агента в software development lifecycle. CI мог падать два часа, bug report — лежать до утра, PagerDuty — будить дежурного. Агент обладал автономностью внутри задачи, но не был связан с моментом её появления.

Automations добавляют отсутствующий слой:

WHEN event matches conditions
START agent with instructions
GIVE environment and tools
STOP at defined boundary

Так coding agent превращается из инструмента по запросу в участника pipeline.

Событие ещё не является хорошей задачей

Здесь легко переоценить automation. Новый Linear issue действительно может запустить агента, но сам факт создания issue не объясняет архитектурные ограничения, цену ошибки и Definition of Done. Плохой ticket автоматически превращается в плохо поставленную автономную работу.

Между trigger и agent нужен явный контракт:

какие события подходят, а какие нужно игнорировать;
из каких полей собрать контекст задачи;
какой repository и base branch использовать;
что разрешено изменить и чем проверить результат;
в какой ситуации вернуть отчёт вместо patch.

Например, automation для любого нового issue слишком широк. Фильтр «label = agent-ready, есть reproduction steps и acceptance criteria» превращает тот же механизм в управляемую очередь.

Пять источников создают разные классы работы

GitHub, Linear, Slack, PagerDuty и расписание нельзя свести к одному prompt template. Каждый источник несёт свой уровень сигнала и риска.

GitHub и Linear: подготовленная очередь

Issue со стабильным воспроизведением может пройти полный маршрут: research → fix → tests → pull request. Для расплывчатого feature request безопаснее ограничить результат картой текущего flow, вопросами и планом. Один trigger, но разные stop conditions.

CI webhook: узкая диагностика

После failed pipeline агенту можно передать commit SHA, failing job, base branch и logs. Его задача — определить, связано ли падение с текущим diff, воспроизвести ошибку и подготовить минимальный patch. Если тот же check падает на base branch, automation не должна чинить чужую поломку.

PagerDuty: сначала triage

Incident — самый опасный вход. Здесь я бы не разрешал агенту сразу менять production. Полезный первый результат: связать alert с недавними deploy, найти вероятный участок кода, собрать логи через read-only MCP и предложить проверяемые гипотезы. Patch возможен позже, deploy — только после человека.

Schedule: постоянная инженерная функция

Ночной поиск flaky tests, еженедельный dependency report или review security-sensitive PR — естественные recurring jobs. У них нет одного автора и одного issue: важны стабильный формат отчёта, бюджет и правило, что считать новым результатом.

Главная техническая ловушка — повторные события

Webhook редко приходит в идеальной форме ровно один раз. GitHub может отправить несколько близких событий на один PR, Linear — изменение label сразу после создания issue, CI — повторный failure после rerun. Если каждое событие поднимает нового агента, команда получает три ветки с конкурирующими исправлениями.

Для production automation нужны знакомые backend-механизмы:

idempotency key из source, event type и entity ID;
debounce, чтобы собрать короткую серию изменений;
concurrency limit на repository или issue;
deduplication уже созданных run и PR;
budget по времени, токенам и числу повторных попыток.

Это обычная событийная архитектура, только consumer теперь дорогой и недетерминированный. Проектировать её как «cron плюс prompt» слишком наивно.

Воспроизводимый sandbox важнее красивой инструкции

Каждый run стартует в отдельной cloud-среде. Если она не умеет собрать проект, подключиться к тестовой PostgreSQL или запустить worker, агент не замкнёт feedback loop. Cursor отдельно описывает cloud agents как изолированные VM с cloned repositories, dependencies, secrets, startup commands и network access.

Для Laravel-проекта automation должна получить ту же инженерную опору, что и разработчик:

repository + pinned dependencies
PostgreSQL + Redis
test environment
safe secrets
startup commands
PHPUnit + Pint + PHPStan
logs and artifacts

Если локальная сборка существует только в памяти команды, always-on agent быстро это обнаружит. Automations заодно проверяют воспроизводимость development environment.

Memory — опыт, а не источник истины

Memory между запусками полезна для повторяемой работы. Агент может помнить, где обычно лежат диагностические логи, какой тест подтверждает конкретный failure и какие гипотезы уже не сработали. Ночной triage становится менее похож на запуск с чистого листа.

Но память нельзя превращать в скрытую policy. Архитектурные правила, разрешения и Definition of Done должны оставаться version-controlled в repository или automation config. Иначе вчерашнее удачное исключение незаметно станет сегодняшним постоянным решением.

Я бы разделял данные так:

Rules / config → обязательная истина
Memory         → полезный опыт
Current event  → факты этого запуска

Memory помогает начинать быстрее. Проверять её выводы всё равно нужно по текущему коду и данным.

Always-on агенту нужна матрица разрешений

При ручном запуске разработчик хотя бы присутствует рядом. Automation может сработать ночью, поэтому неявные permissions становятся опаснее.

READ repository / issue / logs       AUTO
RUN tests in isolated sandbox        AUTO
CREATE branch and draft PR           AUTO
COMMENT diagnostic summary           AUTO

WRITE external issue status          LIMITED
CHANGE infrastructure dependency     APPROVAL
MERGE                                HUMAN
PRODUCTION write / deploy             DENY

Точный набор зависит от риска. Для дайджеста документации можно разрешить больше. Для billing, authentication или migration — меньше. Принцип простой: автономность исполнения не требует автономного решения о production.

MCP и Hooks расширяют возможности агента, но каждый connector должен иметь минимальные scopes. Read Sentry events и delete events — разные инструменты, даже если ведут в один сервис.

Практичная automation для PHP-проекта

Я бы не начинал с PagerDuty и автоматического bugfix. Первый полезный сценарий для Laravel 13 проще: каждый будний вечер разбирать новые flaky failures в test suite.

TRIGGER
weekdays at 20:00

SCOPE
tests failed at least twice in the last 7 days

AGENT
group failures, reproduce in sandbox,
find shared root cause, prepare draft PR only

CHECKS
targeted test × 10, full PHPUnit, Pint

STOP IF
failure cannot be reproduced,
production data is required,
public API or DB schema must change

OUTPUT
report + evidence + optional draft PR

Такой workflow имеет узкий scope, наблюдаемый вход и безопасный выход. После нескольких недель можно измерить precision: сколько run нашли реальную проблему, сколько PR приняли, сколько стоили ложные срабатывания. Только после этого имеет смысл расширять ответственность.

От prompt engineering к workflow engineering

Automations заставляют проектировать уже не текст запроса, а всю цепочку принятия решений:

WHEN      какое событие достаточно надёжно
FILTER    какой шум отбросить
CONTEXT   какие факты передать
TOOLS     что разрешить читать и вызывать
WORK      какой результат подготовить
VERIFY    чем доказать корректность
STOP      где нужен человек

Хороший prompt остаётся частью системы. Но он не спасёт от дублирующих webhook, пустого sandbox, слишком широкого token budget или MCP с production write access.

Это и есть workflow engineering: сделать автономную работу повторяемой, наблюдаемой и ограниченной.

От coding agent к software engineering agent

Coding agent обычно получает задачу от разработчика и возвращает изменение в repository. Automation связывает его с issue tracker, CI, incident management, Slack и расписанием. Агент начинает реагировать на состояние инженерной системы.

EVENT
  ↓
UNDERSTAND → INVESTIGATE → CHANGE
  ↓                         ↓
REPORT ← VERIFY ← TEST ←───┘

Код в таком маршруте может оказаться восемью строками. Основная работа — отличить симптом от причины, собрать evidence, не выйти за scope и правильно остановиться.

Поэтому термин software engineering agent точнее описывает направление. Это уже не «AI в редакторе», а постоянно доступный исполнитель с местом в development pipeline.

Автоматизировать стоит ответственность, а не запуск

Cursor Automations убрали разработчика из обязательной точки старта. GitHub issue, Linear ticket, CI failure, PagerDuty incident или расписание теперь способны сами поднять cloud agent с заданными моделями, MCP и memory.

Но ценность создаёт не автоматический запуск. Её создаёт правильно очерченная инженерная ответственность: какой сигнал считать задачей, что агент может делать, как проверить результат и где передать решение человеку.

Я бы начинал с узкой recurring-функции и draft PR, измерял ложные срабатывания и лишь затем расширял permissions. Always-on агент полезен не тогда, когда он постоянно занят. А когда команда может предсказать, почему он включился, что сделал и почему остановился именно здесь.