---
title: "Automations"
description: "基于 Cursor 官方 Automations 文档解释触发器、工具、权限范围、身份、计费、环境和提示词写法。"
verifiedAt: "2026-05-09"
---

Automations 让 Cloud Agents 在后台按计划或事件运行，不需要每次手动发起任务。

> [!NOTE]
> **阅读目标**：读完本章，你应该能判断一个任务是否适合自动化，并能配置 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](https://cursor.com/automations) 新建，或从 marketplace template 开始。

1. 选择 trigger，例如每小时运行、PR opened、Slack message。
2. 写 prompt，说明 agent 要做什么。
3. 选择 tools，例如 Open pull request、Comment on Pull Request、Send to Slack、MCP。
4. 设置 model、environment、permission scope。
5. 创建并观察第一批 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 或个人额度解释。

<details>
<summary>深读：自动化的核心风险是“重复错误”</summary>

一次 Cloud Agent 任务做错，影响通常有限。Automation 如果 prompt、trigger 或 tool 权限配置错，会稳定重复同一类错误。上线策略应该是小范围、可观测、可禁用、可回滚。
</details>

## 本章自检

1. 这个任务是否重复、低歧义、能异步验收？
2. trigger 是否可能误触发？
3. tools 是否给多了权限？
4. Team Owned 后，OAuth、webhook key 和计费是否重新确认？
5. prompt 是否明确“不开 PR / 不评论 / 不行动”的条件？

通过标准：你能创建一个低风险 automation，并用 dashboard run history 证明它只在该运行时运行、使用了必要工具、输出可验收。

## 官方来源

- [Cursor Automations](https://cursor.com/docs/cloud-agent/automations.md) —— 官方 triggers、tools、settings、permissions、identity、billing 和 prompt tips。
- [Cursor Help: Automations](https://cursor.com/help/ai-features/automations.md) —— 官方帮助页中的创建步骤和触发器清单。
- [Cursor Cloud Agent Setup](https://cursor.com/docs/cloud-agent/setup.md) —— 官方 Cloud Agent 环境配置。
- [Cursor Models and Pricing](https://cursor.com/docs/models-and-pricing.md#model-pricing) —— 官方计费入口。

## 接下来去哪

<Cards>
  <Card title="Cloud Agent Best Practices" description="继续把自动化和 Cloud Agent 使用收敛成上线检查清单。" href="/docs/cursor/official/04-cloud-agents/58-best-practices" />
  <Card title="Security Review" description="回看安全自动化如何跑在 Automations 上。" href="/docs/cursor/official/04-cloud-agents/56-security-review" />
</Cards>
