Cursor Automations 在雲 Mac 上怎麼配？定時 Agent、Webhook 與 Background Agent 分工實測

1. 為什麼 2026 年 Agent 要分「觸發」與「執行」

過去一年，開發者手裡的 AI 工具從「聊天補全」進化到三條並行產品線：按需派活（Background / Cloud Agent）、事件驅動（Automations）、自建編排（launchd、cron、n8n + MCP）。很多人把三者混為一談——「不都是 Agent 自動跑嗎？」——結果要麼在 Linux 沙箱裡硬跑 iOS 建置，要麼給每個 PR 手動點一次 Background Agent，要麼在雲 Mac 上堆了十個 cron 卻沒人看日誌。

真正拖慢交付的往往不是模型智商，而是工作流入口沒對齊：該用定時觸發的用了手動派活，該用 macOS 執行環境的扔進了 Cursor 雲沙箱。典型演進是先問「Automations 怎麼開」（見 官方 Automations 文件），再問「PR merged 後能不能自動 Archive」（不能單靠 Linux 沙箱），最後才落到「Webhook 打到雲 Mac 行不行」——正是本文要拆的決策鏈。

站內上下文：上週 Background Agent 執行環境實測 回答「跑在哪台 Mac」；launchd 定時 Agent FAQ 回答「自建 macOS 編排」；本篇補上中間層——Cursor 官方 Automations 的能力邊界與雲 Mac 補位方式。

2. Cursor Automations 是什麼：always-on 的 Cloud Agent

根據 2026-03-05 更新日誌 與 官方公告，Cursor Automations 讓你用觸發器 + 自然語言指令 + 可選工具 配置「一直線上」的 Agent。

在 cursor.com/automations 建立，也可用 6 月新增的 /automate 技能在本地會話裡描述任務、由 Cursor 產生配置（見 06-18 改進說明）。

觸發器類型（任一命中即運行）包括：

• Scheduled：預設週期或 cron 表達式；
• GitHub / GitLab：PR opened/pushed/merged、push to branch、CI completed、review comment 等（6 月新增多條 GitHub 事件）；
• Slack：頻道新訊息、表情回覆觸發；
• Linear / PagerDuty：Issue、Cycle、Incident；
• Webhook：儲存後獲得私有 HTTP 端點 + API Key，POST 即可觸發。

每次觸發，Cursor 會拉起一個雲沙箱，Agent 按你的指令執行，可選用「評論 PR」「發 Slack」「調 MCP」等工具，並可用 memory 工具跨次運行累積經驗。倉庫模式分三種：無倉庫（只做 Slack/MCP/Webhook 類編排）、單倉庫、多倉庫環境——無倉庫模式不能改程式碼、不能開 PR，適合純通知與外部系統聯動。

非對稱結論：Automations 的價值在觸發器生態，不在 macOS 執行環境——模型會繼續降價，但「PR merged 後 30 秒內有人開始查」貴的是響應入口，不是多跑一輪 GPT。

3. Background Agent 又是什麼：你親手派的一次長跑

Background Agent（現多稱 Cloud Agent）是按需啟動的：你在 IDE、cursor.com/agents、Slack @Cursor 或 API 裡明確派一個任務，Agent 在雲端 VM 裡跑到開 PR、交日誌或失敗為止。它沒有內建「每週一掃描依賴漏洞」或「CI 紅了就自動修」——除非你自己用 Automations 或外部 cron 去代替手指點那一下。

對比記憶口訣：

• Automations：「當 X 發生 → 按模板 Y 做事」；適合重複、可規則化的運維與程式碼衛生；
• Background Agent：「我現在要你做這件複雜事」；適合探索性重構、跨模組大改、一次性難題；
• 雲 Mac launchd：「在我的 macOS 上按我的 plist 跑」；適合必須碰鑰匙串、Xcode、本地 MCP 的路徑。

官方部落格裡的 PagerDuty 案例很典型：Incident 觸發 Automation → Agent 用 Datadog MCP 查日誌 → 在倉庫裡找近期變更 → Slack 通知 on-call 並開修復 PR——這是Automations + MCP + 單倉庫 的閉環，全程可在 Linux 沙箱完成。但若最後一步要跑 xcodebuild archive 驗證 iOS 包，就必須另開 macOS 執行通道。

4. Automations 跑在哪：Linux 雲沙箱，與 Cloud Agent 同源

官方文件寫明：Automations 與 Cloud Agent 一樣，運行在 Cursor 託管的雲端沙箱（Linux 環境 + 可選 Dockerfile / snapshot）。這意味著：

• ✅ 改 Node/Python/Go 倉庫、跑單元測試、開 PR、調雲端 MCP（Datadog、Linear 等）；
• ❌ 原生 xcodebuild、iOS 模擬器、macOS Keychain 簽名、僅 macOS 的 CLI；
• ⚠️ 6 月 changelog 提到 Automations 支援 computer use，但仍是在沙箱內的螢幕操作，不能替代真實 Apple 工具鏈。

這和我們在 Background Agent 執行環境 一文中的結論一致：Cursor 官方雲 = Linux 優先。Automations 沒有單獨提供「macOS 觸發器執行環境」——它只是在觸發側更強大。

因此「在雲 Mac 上配 Automations」在工程上其實是兩層含義：① 在 Cursor 控制台配好 Automations（邏輯在 Cursor 雲）；② 對 macOS 任務，用 Webhook / CI completed 觸發器 → 轉發到獨占雲 Mac 執行。很多人搜「Cursor Automations 雲 Mac」想找的是②，而不是把 Automations 進程搬進 Mac mini——後者目前並非官方路徑。

5. 雲 Mac 在自動化棧裡補哪一塊

獨占雲 Mac（M4 Mac mini 託管）在自動化棧裡通常承擔四種角色：

1. macOS 執行節點：xcodebuild、Flutter iOS、notarytool、模擬器；與 Archive CI 排障 同一戰場；
2. Webhook 接收端：內網或 Tunnel 暴露的 HTTP 服務，接收 Automations / GitHub Actions / 監控系統的 POST；
3. launchd 常駐宿主：按日曆或 KeepAlive 跑 Claude Code、Codex CLI、自訂腳本（詳見 launchd Agent FAQ）；
4. MCP 同機部署：Agent 與 MCP Server 共享路徑，避免「配置寫本機、倉庫在雲」的路徑分裂（見 MCP 部署選址）。

Windows 主力機團隊尤其需要這條鏈：本地 Windows 寫程式碼，iOS 建置在雲 Mac，Automations 在 Cursor 雲做 PR 衛生與依賴掃描，Webhook 在合併後觸發雲 Mac Archive——三層各幹各的，比「全塞進一個 Automation」穩定得多。

6. 三種形態五維對比表

同一張表再補「觸發 vs 執行」維度：Automations 強在觸發多樣性；Background 強在單次任務深度；雲 Mac 強在 OS 能力。沒有一行能占滿三列——這就是必須混合的原因。

7. 混合架構：Webhook 串聯 Automations → 雲 Mac

我們推薦的標準混合棧（實測可在一台日租雲 Mac 上跑通）：

[GitHub PR merged]
       ↓
[Cursor Automation: trigger = PR merged, repo = 單倉庫]
       → Linux 沙箱：lint / 測試 / 開 docs PR（可選）
       → 工具：Webhook POST → https://<cloud-mac-tunnel>/hooks/ios-archive
       ↓
[雲 Mac 本地服務：nginx/caddy + 鑑權]
       → launchd 或一次性腳本：git pull → xcodebuild archive → exportArchive
       → 失敗：Slack / 飛書 webhook 告警
       ↓
[TestFlight / 內部分發]

要點：

• Automation 的 Webhook 工具把原始 payload 追加進 Agent 指令——也可專設一條「僅 Webhook、無倉庫」 的 Automation，只做路由與鑑權檢查，不碰程式碼；
• 雲 Mac 側用短時令牌校驗 POST，禁止裸奔端點（Tunnel 安全可參考 OpenClaw 專欄的 Webhook 思路，但本篇主線非 OpenClaw）；
• macOS 建置不要塞回 Linux Automation——Archive 鏈路 對 Keychain 與 Scheme 極敏感，應在雲 Mac 用已驗證的 plist / Fastlane 腳本跑；
• 定時類任務（如「每週一 9:00 依賴審計」）可完全放在 Automations；「每週一 9:30 iOS 回歸包」放 雲 Mac launchd，兩者用 Slack 匯總結果即可。

8. 場景矩陣：該用哪種方案

9. 推薦組合與紅線

組合 A（全棧 Web + 小 iOS 模組）：Automations 管 PR 衛生與依賴 bot；iOS 子目錄 merge 後 Webhook → 雲 Mac Archive；Background Agent 僅用於「大版本遷移」類一次性任務。

組合 B（Indie iOS）：一台 16GB 雲 Mac 月租；launchd 管夜間測試；Cursor Automations 只綁 GitHub「PR comment」做 Code Review 助手（無 macOS 建置）；CLI Agent 與 Cursor 共享 worktree（見 雙 Agent 隔離）。

組合 C（平台 / SRE）：PagerDuty → Automations → Datadog MCP + 修復 PR；若修復涉及 iOS 客戶端，Automation 末尾 Webhook 觸發雲 Mac 驗證建置，不把 Archive 放進 Linux 沙箱。

紅線：① 不要用「無倉庫 Automation」去改程式碼——官方明確不能開 PR；② Team Owned Automation 升級後要輪換 Webhook API Key 並重配 MCP OAuth；③ 雲 Mac Webhook 必須鑑權 + 限流；④ 16GB 實例不要同時「launchd 模擬器農場 + Background 並行 + Archive」——記憶體治理見 Runner 專文。

10. 常見誤區

• 誤區 1：「上了 Automations 就不用 Background Agent」——Automations 是觸發器包裝，複雜探索性任務仍要手動派 Background。
• 誤區 2：「Automations 能替代雲 Mac」——只能替代 Linux 可閉環的部分；iOS/macOS 一介入就要 Mac 執行環境。
• 誤區 3：「Webhook 等於自動化完成」——Webhook 只是導線；雲 Mac 上的接收腳本、Keychain、git 狀態機才是執行核心。
• 誤區 4：「和 launchd 文章重複」——launchd 篇講自建 macOS 編排；本篇講Cursor 官方 Automations 與它的銜接，觸發源不同。
• 誤區 5：「定時 Agent 都要寫 cron」——能用 Automations Scheduled 的優先用官方（省維護）；只有 macOS 任務才堅持 launchd。

11. 7 步落地清單

1. 在 cursor.com/automations 建一條測試 Automation：Scheduled 每 6 小時或 Webhook，指令「列出倉庫過時依賴並評論到 Slack」（無 macOS）。
2. 日租一台雲 Mac，按 開通驗收清單 完成 SSH + 磁碟基線。
3. 在雲 Mac 部署最小 Webhook 接收器（caddy 反代 + Bearer token），本地腳本只做 git pull && ./scripts/smoke-build.sh。
4. 新建第二條 Automation：GitHub「Workflow run completed」或「PR merged」→ 工具選 Webhook → 指向雲 Mac 端點；payload 帶上 commit SHA。
5. 並行驗證：同事件手動派一次 Background Agent，對比 turnaround 與可復現性——Automations 應更「模板化」，Background 更「靈活」。
6. 把 macOS 建置腳本固化進 launchd plist 或 Fastlane lane，禁止在 Automation 指令裡寫超長 shell（難審計）；Automation 只負責「調用 Webhook」。
7. 跑滿 48 小時：至少 1 次真實 merge 觸發 + 1 次故意失敗（測告警）；滿意後升月租，並記錄 Webhook Key 輪換 SOP。

12. FAQ

Q：Cursor Automations 和 Background Agent 能不能合併成一個產品理解？

可以記成：Automations = 觸發器 + 模板化 Cloud Agent；Background Agent = 手動觸發的 Cloud Agent。共享 Linux 執行環境，不共享「何時跑」的配置層。

Q：Automation 能直接 SSH 到我的雲 Mac 嗎？

官方不提供「SSH 到租戶 Mac」工具。實踐路徑是：Webhook 打到雲 Mac 上的 HTTP 服務，或用 GitHub Actions self-hosted runner 在雲 Mac 上跑（與 Automations 並行，非替代）。

Q：無倉庫 Automation 適合什麼？

純 Slack 匯總、PagerDuty 通知、調外部 MCP、Webhook 路由——不能改程式碼。要開 PR 必須綁定倉庫。

Q：Team Owned 後為什麼要換 Webhook Key？

官方說明：提升為團隊歸屬後，身份從個人變為團隊服務帳號，舊 Key 失效；MCP OAuth 也需改為團隊憑證。

Q：16GB 雲 Mac 夠跑這套混合棧嗎？

單 worktree + 偶發 Archive + 輕量 Webhook 服務：16GB 日租可驗證。若 launchd 常駐模擬器 + 並行 Agent，建議 24GB 月租。

13. 結論

Cursor Automations 把「always-on Agent」做成了產品化觸發器——定時、GitHub、Slack、Webhook 一應俱全，是 2026 年最值得先上的編排層。但它與 Background Agent 共享 Linux 雲沙箱，解決不了 Xcode 與鑰匙串。

正確姿勢是三層分工：Automations 管事件與模板化改碼；Background 管一次性深水任務；雲 Mac 通過 Webhook / launchd 管 macOS 執行。問題不在「哪個 Agent 更聰明」，而在觸發入口與執行邊界是否對齊。

建議本週動作：在 Cursor 控制台建一條 Webhook Automation，在日租雲 Mac 上接一條 Archive 煙測鏈路——48 小時內你就能看清「官方自動化」與「Mac 執行環境」各自該站哪一層。