---
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="/zh-Hant/docs/cursor/official/04-cloud-agents/58-best-practices" />
  <Card title="Security Review" description="回看安全自動化如何跑在 Automations 上。" href="/zh-Hant/docs/cursor/official/04-cloud-agents/56-security-review" />
</Cards>
