Automations
基于 Cursor 官方 Automations 文档解释触发器、工具、权限范围、身份、计费、环境和提示词写法。
Automations 让 Cloud Agents 在后台按计划或事件运行，不需要每次手动发起任务。
阅读目标：读完本章，你应该能判断一个任务是否适合自动化，并能配置 trigger、tools、permissions、environment 和 prompt。
1. 适合做什么
Automations 适合“重复发生、规则清晰、能异步验收”的工程任务。
| 场景 | 典型触发 |
|---|---|
| PR 深度 review | PR opened、PR pushed、CI completed |
| 安全扫描 | schedule、PR merged、cron |
| feature flag 清理 | schedule |
| Slack bug triage | Slack new message |
| Sentry issue investigation | Sentry issue event |
| 事故初筛 | PagerDuty incident event |
| 内部系统触发任务 | webhook POST |
不适合自动化的任务：目标不清、权限边界不清、输出无法验证、需要实时人工判断、会直接触碰生产数据或敏感资产。
2. 创建流程
从 cursor.com/automations 新建，或从 marketplace template 开始。
- 选择 trigger，例如每小时运行、PR opened、Slack message。
- 写 prompt，说明 agent 要做什么。
- 选择 tools，例如 Open pull request、Comment on Pull Request、Send to Slack、MCP。
- 设置 model、environment、permission scope。
- 创建并观察第一批 runs。
第一版不要直接覆盖全团队。先在一个低风险 repo 或 channel 做样板，确认噪音、成本、权限和输出质量。
3. Triggers
一个 automation 可以有多个 triggers；任意 trigger 触发都会启动 run。某些 trigger，例如 schedule 或 Slack，需要额外选择 repository 和 branch，因为 Cursor 不能从 PR 自动推断。
| Trigger | 说明 |
|---|---|
| Scheduled | preset schedule 或 cron expression（cron 表达式，定时任务的时间格式如 0 9 * * 1-5 表示每周一到五 9 点）；可能延迟运行，但不会早于指定时间 |
| GitHub: Draft opened | draft PR 创建 |
| GitHub: PR opened | 非 draft PR 创建，或 draft 标记 ready |
| GitHub: PR pushed | 现有 PR 推入新 commit |
| GitHub: Label changed | PR label 新增或移除 |
| GitHub: PR merged | PR 合并 |
| GitHub: PR commented | PR 有新评论 |
| GitHub: Push to branch | 指定 branch 收到非 PR commit |
| GitHub: CI completed | GitHub Check 在 PR 或 branch 上完成 |
| Slack: New message | connected public channel 有新消息 |
| Slack: Channel created | workspace 中创建 public channel |
| Webhook | 向私有 HTTP endpoint 发送 POST（webhook = 外部系统通过 HTTP 回调主动通知 Cursor 的事件入口） |
| Linear | issue created、status changed、end of cycle |
| Sentry | issue created、issue updated、any issue event |
| PagerDuty | incident triggered、acknowledged、resolved、any incident event |
Slack trigger 当前只看到 public channels。无 filter 时，新消息 trigger 只处理 top-level channel messages；如果要处理 threaded replies，需要加 keyword 或 regex filter。
Webhook trigger 必须先保存 automation，Cursor 才会生成 webhook URL 和 API key。
4. Tools
Tools 决定 agent 能对外做什么。启用前要先问：这个 automation 是否真的需要写代码、评论、发 Slack、读 Slack、请求 reviewer 或调用 MCP。
| Tool | 用途 | 边界 |
|---|---|---|
| Open pull request | agent 写代码、建 branch、开 PR | 适合真实 code change |
| Comment on pull request | 在触发 PR 上发 top-level 或 inline comments | 需要 PR trigger；approval 需要额外启用 |
| Request reviewers | 根据 git、memory 和工具请求 reviewer | 需要 PR trigger |
| Send to Slack | 发送消息到指定或动态选择的 channel | 允许 any channel 时也会授予 public channel discovery/read |
| Read Slack channels | 只读 public channel messages | 用于回复或建 PR 前补上下文 |
| MCP server | 连接外部工具和数据源 | 会暴露 MCP server 的所有 tools |
| Memories | 跨 run 读写持久 notes | 默认开启；处理不可信输入时要谨慎 |
Memories 以 named entry 存在，默认是 MEMORIES.md，不在 agent 的工作目录里。它能让 automation 逐步改善，也可能被恶意输入污染，影响未来 runs。
5. Environment
Automations 继承 Cloud Agents dashboard 和 Cloud agent setup 中的环境配置。
| 选项 | 行为 | 适合 |
|---|---|---|
| Environment enabled | agent 先安装依赖再运行 | 需要 build、test、执行代码 |
| Environment disabled | 跳过 dependency installation | 只读 review、轻量分析 |
如果 automation 要打开 PR 或修代码，环境通常要开启。只读 triage 或评论型 automation 可以关闭，减少耗时和失败面。
secrets 和 repo 级环境仍到 Cloud Agents dashboard 配置。自动化不要把 token、账号或私有 URL 写进 prompt。
6. Permissions、billing 和身份
权限范围同时决定谁能管理 automation、用谁的身份执行、费用记到哪里。
| Scope | 管理权限 | 计费 | 执行身份 |
|---|---|---|---|
| Private | 只有创建者管理；team admin 可查看和禁用 | 创建者 | 创建者 auth |
| Team Visible | team 可见；创建者管理；team admin 可禁用 | 创建者 | 创建者 auth |
| Team Owned | team 可见；只有 team admin 管理 | team usage pool | shared team automations service account |
从 Private / Team Visible 提升到 Team Owned 会改变执行身份：不再用你的 auth，而是用团队 shared automations service account。
提升后要检查：
- webhook API key 是否重新生成。
- MCP 或 OAuth integration 是否已经给团队 service account 配好。
- GitHub / Slack / Linear 的外部身份是否符合团队预期。
外部服务身份：
| 行为 | 身份 |
|---|---|
| GitHub comments / approvals / reviewer requests | cursor |
| Team-scoped automation open PR | cursor |
| Private automation open PR | 你的 GitHub account |
| Slack messages | Cursor bot |
Automations 创建 Cloud Agent runs，按 Cloud Agent usage 计费。实际费用和 model pricing 相关，采购前要回到当前 pricing 页面确认。
7. Prompt 写法
Automation prompt 要比一次性 Cloud Agent prompt 更严格，因为它会重复运行。
至少写清：
- 触发后先检查什么。
- 什么时候应该开 PR。
- 什么时候只评论。
- 什么时候什么都不做。
- 允许修改的路径和禁止触碰的路径。
- 输出格式。
- 失败时如何报告。
- 需要使用哪些 enabled tools。
一个可上线的自动化 prompt 应该像 runbook，不像一句愿望。
8. 上线验收
上线前检查：
- trigger 是否只覆盖目标 repo、branch、channel 或事件。
- tools 是否最小授权。
- permission scope 是否和执行身份、计费主体一致。
- environment enabled / disabled 是否符合任务性质。
- secrets 是否只走 dashboard，不进 prompt。
- memory 是否适合该任务，处理不可信输入时是否关闭或约束。
- 首批 runs 是否有 dashboard 记录、输出证据和可复盘日志。
- 成本是否能通过 usage pool 或个人额度解释。
深读：自动化的核心风险是“重复错误”
一次 Cloud Agent 任务做错，影响通常有限。Automation 如果 prompt、trigger 或 tool 权限配置错，会稳定重复同一类错误。上线策略应该是小范围、可观测、可禁用、可回滚。
本章自检
- 这个任务是否重复、低歧义、能异步验收？
- trigger 是否可能误触发？
- tools 是否给多了权限？
- Team Owned 后，OAuth、webhook key 和计费是否重新确认？
- prompt 是否明确“不开 PR / 不评论 / 不行动”的条件？
通过标准：你能创建一个低风险 automation，并用 dashboard run history 证明它只在该运行时运行、使用了必要工具、输出可验收。
官方来源
- Cursor Automations —— 官方 triggers、tools、settings、permissions、identity、billing 和 prompt tips。
- Cursor Help: Automations —— 官方帮助页中的创建步骤和触发器清单。
- Cursor Cloud Agent Setup —— 官方 Cloud Agent 环境配置。
- Cursor Models and Pricing —— 官方计费入口。