Cursor Automations на Cloud Mac: плановые агенты, Webhook и разделение Background Agent

1. Почему в 2026 агенты разделяют «триггер» и «исполнение»

Три параллельные линии: по требованию (Background/Cloud Agent), по событиям (Automations), своя оркестрация (launchd, cron, n8n+MCP). Смешивание ведёт к iOS-сборкам в Linux, ручным кликам Background на каждый PR или десяти cron на Cloud Mac без чтения логов.

Задержки реже от модели, чем от неверной точки входа в workflow: сначала «как включить Automations?» (см. официальную документацию Automations), затем «Archive после merge?» (не только Linux), наконец «Webhook на Cloud Mac?» — цепочка решений этой статьи.

Контекст: полевой тест runtime Background Agent отвечает «на каком Mac»; FAQ launchd по расписанию — «своя macOS-оркестрация». Здесь — границы Cursor Automations и роль Cloud Mac.

2. Cursor Automations: always-on Cloud Agent

По changelog 2026-03-05 и официальному объявлению Cursor Automations — это триггеры + инструкции на естественном языке + опциональные инструменты для постоянно активных агентов.

Создавайте на cursor.com/automations; в июне skill /automate генерирует конфиг из чата (улучшения 06-18).

Типы триггеров (достаточно одного):

• Scheduled: период или cron;
• GitHub/GitLab: PR opened/pushed/merged, push в ветку, CI completed, review comment и др.;
• Slack: сообщения канала, реакции-эмодзи;
• Linear/PagerDuty: Issue, Cycle, Incident;
• Webhook: приватный HTTP + API Key после сохранения.

Каждый триггер поднимает облачную песочницу с комментариями PR, Slack, MCP, memory между запусками. Режимы repo: без repo (только Slack/MCP/Webhook), один repo, несколько — без repo нельзя менять код и открывать PR.

Асимметричный вывод: ценность Automations в экосистеме триггеров, не в macOS-runtime — «кто-то начнёт разбор через 30 с после merge» стоит точки входа, не ещё одного GPT.

3. Background Agent: один долгий забег, который вы запускаете

Background Agent (Cloud Agent) — по требованию: явная задача в IDE, cursor.com/agents, Slack @Cursor или API; работа до PR, логов или ошибки. Нет встроенного «еженедельный скан зависимостей» — unless Automations или cron заменяют клик.

Мнемоника:

• Automations: «когда X → шаблон Y»; повторяемая ops;
• Background Agent: «сделай это сложное сейчас»; исследовательский рефакторинг;
• launchd на Cloud Mac: «на моём macOS по plist»; Keychain, Xcode, локальный MCP.

Кейс PagerDuty: Incident → Automation → Datadog MCP → изменения → Slack + fix PR — Linux достаточно. Нужен xcodebuild archive — нужен отдельный macOS-канал.

4. Где работают Automations: Linux-песочница как у Cloud Agent

По документации: облачная песочница Cursor (Linux + опционально Dockerfile/snapshot). Значит:

• ✅ Node/Python/Go, тесты, PR, облачный MCP;
• ❌ нативный xcodebuild, симулятор iOS, подпись Keychain, macOS-only CLI;
• ⚠️ computer use июня всё ещё внутри песочницы — не замена Apple toolchain.

Same conclusion as our статья о runtime Background Agent: официальное облако Cursor = Linux в первую очередь. Отдельного macOS-trigger runtime нет.

«Настроить Automations на Cloud Mac» — ① конфиг в консоли Cursor; ② macOS-задачи через Webhook/CI completed → выделенный Cloud Mac. Большинство ищут ②.

5. Что Cloud Mac добавляет в стек

Выделенный Cloud Mac (M4 Mac mini) в четырёх ролях:

1. Узел исполнения macOS: xcodebuild, Flutter iOS, notarytool, симулятор — как разбор CI Archive;
2. Приёмник Webhook: HTTP через туннель/интранет;
3. Хост launchd: Claude Code, Codex CLI (FAQ launchd Agent);
4. MCP на той же машине (гайд по размещению MCP).

Команды на Windows: код локально, iOS-сборка на Cloud Mac, Automations для гигиены PR, Webhook после merge для Archive — три слоя стабильнее одной Automation.

6. Сравнение по пяти измерениям

Триггер vs исполнение: Automations — разнообразие триггеров, Background — глубина одной задачи, Cloud Mac — возможности ОС. Гибрид обязателен.

7. Гибрид: Webhook связывает Automations → Cloud Mac

Рекомендуемый стандартный гибридный стек (проверяется на суточной аренде):

[GitHub PR merged]
       ↓
[Cursor Automation: trigger = PR merged, repo = один]
       → Linux-песочница: lint / тест / docs PR (опционально)
       → инструмент: Webhook POST → https://<cloud-mac-tunnel>/hooks/ios-archive
       ↓
[Сервис Cloud Mac: nginx/caddy + auth]
       → launchd или разовый скрипт: git pull → xcodebuild archive → exportArchive
       → при ошибке: алерт Slack / Feishu webhook
       ↓
[TestFlight / внутренняя дистрибуция]

Ключевое:

• Webhook-инструмент добавляет payload в инструкции — или Automation только Webhook без repo для маршрутизации;
• На Cloud Mac — короткоживущие токены, без открытых endpoint;
• Не возвращайте macOS-сборку в Linux Automation — цепочка Archive чувствительна к Keychain/Scheme; plist/Fastlane на Cloud Mac;
• «Понедельник 9:00 аудит зависимостей» в Automations; «Понедельник 9:30 iOS-регрессия» на launchd Cloud Mac.

8. Матрица сценариев

9. Комбинации и красные линии

Комбо A (Web + малый iOS): Automations для PR/зависимостей; merge iOS → Webhook → Archive на Cloud Mac; Background только для крупных миграций.

Комбо B (indie iOS): Cloud Mac 16 ГБ месячно; launchd ночью; Automations только PR comment (изоляция dual-Agent).

Комбо C (платформа/SRE): PagerDuty → Automations → Datadog MCP; iOS-fix завершается Webhook на Cloud Mac — не класть Archive в Linux.

Красные линии: ① не менять код без repo; ② после Team Owned ротация Webhook Key + MCP OAuth; ③ Webhook с auth + rate limit; ④ на 16 ГБ не гонять ферму симуляторов + Background + Archive.

10. Типичные заблуждения

• Миф 1: Automations заменяет Background — только обёртка триггеров.
• Миф 2: Automations заменяет Cloud Mac — только Linux-часть.
• Миф 3: Webhook = готово — приёмник, Keychain, git-автомат — ядро.
• Миф 4: дублирует статью launchd — там своя macOS-оркестрация, здесь связка с Cursor Automations.
• Миф 5: любой расписанный agent = cron — сначала Automations Scheduled.

11. Чеклист из 7 шагов

1. At cursor.com/automations тестовую Automation: Scheduled 6 ч или Webhook, «устаревшие зависимости в Slack».
2. Суточная аренда Cloud Mac, чеклист приёмки для SSH + диска.
3. Минимальный приёмник Webhook (caddy + Bearer), только git pull && ./scripts/smoke-build.sh.
4. Вторая Automation: GitHub «Workflow run completed» или «PR merged» → Webhook → Cloud Mac с SHA.
5. Параллельно вручную Background Agent — сравнить turnaround.
6. macOS-сборка в launchd/Fastlane; длинный shell в Automation запрещён.
7. 48 часов: реальный merge + намеренный сбой; затем месячная аренда, SOP ротации Webhook Key.

12. FAQ

Q: Automations и Background Agent — один продукт?

Да: Automations = триггеры + шаблонный Cloud Agent; Background = ручной запуск. Общий Linux-runtime.

Q: SSH с Automation на Cloud Mac?

Нет официального SSH. Webhook → HTTP на Cloud Mac или self-hosted runner параллельно.

Q: Automation без repo?

Slack, PagerDuty, внешний MCP, маршрутизация Webhook — без правки кода. PR требует repo.

Q: Зачем менять Webhook Key после Team Owned?

Сервисный аккаунт команды; старые ключи недействительны; MCP OAuth на командные учётные данные.

Q: Хватит ли 16 ГБ Cloud Mac?

Один worktree + редкий Archive: 16 ГБ суточно достаточно. Ферма симуляторов + параллель — 24 ГБ месячно.

13. Заключение

Cursor Automations продуктизирует always-on Agent как слой триггеров — внедрять первым в 2026. Делит Linux-песочницу с Background; Xcode/Keychain не решает.

Три слоя: Automations — события и шаблоны; Background — разовые глубокие задачи; Cloud Mac — Webhook/launchd для macOS. Важно совпадение входа и границы исполнения.

На этой неделе: одна Webhook Automation, дымовой Archive на суточной аренде — за 48 часов станет ясно, где какой слой.