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 运行时」各自该站哪一层。