Cursor 的自动化任务怎么写：automations 的触发与产物

2026-08-18

依据 Cursor 官方文档 2026-08-18 的公开内容整理。该产品迭代频繁，文中涉及的设置项与触发器随版本变动，请以官方文档最新内容为准。

配自动化任务最常见的翻车方式不是提示词写得不好，而是触发条件和产物去向没对上：你以为它会在 PR 打开时跑，结果那个 PR 来自 fork，压根没触发；或者它确实跑了，但你选的是”不挂仓库”，于是它没法开 PR，跑完的结论也就无处可去。所以先把这两头搞清楚，比先琢磨提示词划算。

Cursor Automations 干的事，按 cursor.com/docs/cloud-agent/automations 的说法很直白：在后台跑 Cloud Agent，要么按计划跑，要么被 GitHub、GitLab、Slack、webhook、Linear 之类的事件叫醒。按文档的这句定义，跑起来的东西仍然是 Cloud Agent，自动化这一层负责的是「什么时候叫醒它」和「跑完能用哪些工具把结果送出去」——它内部怎么实现的，文档没有说，我们也不推断。

一、先看前置条件，这一段别跳

入口有四个。 文档写明可以在 Agents Window 里新建、在 cursor.com/automations 上新建、在本地 agent 会话里用 /automate skill 描述你想要的流程（文档说这种方式下 Cursor 会替你配好触发器、指令和工具），或者从 Cursor Marketplace 的模板起步。

触发器各自有依赖。 源码控制类触发器要求已连接 Git 供应商，文档列出的是 GitHub、GitLab 和 Bitbucket Cloud；Slack 类触发器依赖 Cursor 的 Slack 集成；Linear 类触发器依赖 Linear 集成。webhook 触发器有个顺序坑：必须先保存自动化，系统才会生成可调用的 webhook URL 和用于认证的 API key——没保存就去找地址是找不到的。

权限档位有硬门槛。 权限分 Private、Team Visible、Team Owned 三档。文档写明只有团队管理员能把一个自动化提升到 Team Owned。这三档同时决定了两件看起来不相干的事：谁能管理它，以及用量算在谁头上（Team Owned 走团队共享的 automations 服务账号，Private 和 Team Visible 都算在创建者头上）。具体的计费口径与金额本文不涉及，以官方定价与用量说明页为准。

顺带提一句执行环境：文档写明自动化是在后台跑 Cloud Agent，唯一沾到本机的是 /automate 这条从本地 agent 会话发起的路径，而官方文档没有为本地操作系统（Windows / macOS / Linux）列出任何差异说明。想知道自己这一端有没有额外前提，只能以官方文档最新内容为准。webhook 那一端也一样——文档没有给出调用示例请求，所以本文不编一条命令给你，Windows 上用 PowerShell 还是别的 HTTP 客户端都行，地址和 key 一律以保存后生成的那一份为准。

二、五步流程，每一步在改什么

官方文档给的建立流程是五步，无论从哪个入口进都一样：

选触发器（例如每小时一次，或者有 PR 被打开时）——决定它什么时候醒
写提示词——决定它醒了干什么
选可选工具（Send to Slack、Comment on Pull Request、MCP 提供的工具等）——决定产物往哪去
选它需要一个仓库、多个仓库，还是不需要仓库——决定它有没有代码上下文
保存并激活

第 3 步和第 4 步是新手最容易随手过掉的两步，偏偏产物去向就卡在这里。

三、触发这一头：分档和供应商差异

一个自动化可以挂多个触发器，文档写明任意一个触发器触发它就会跑（any，不是 all）。

定时触发可以选预设，也可以填 cron 表达式。有一条要记住：文档明说定时触发可能延迟执行，但不会早于指定时间开始。也就是说它给的是”不早于”的保证，不是”准点”的保证。

源码控制触发分核心集与供应商增量。文档列出的核心触发共六项，三家供应商都支持：draft PR 创建、非 draft PR 创建（或 draft 被标记为 ready）、已有 PR 收到新提交、PR 被合并、提交推到指定分支（文档写的是 PR 之外的推送）、有人在 PR 上留顶层评论。

在核心集之上，GitHub 是文档所说的参考供应商，额外多出八项：PR 标签变化、非 PR issue 的标签变化、CI 检查完成、非 PR issue 的评论、PR diff 上的行内评论、review 被提交（approved / changes requested / commented）、review thread 被标记 resolved 或 unresolved、GitHub Actions 的 workflow run 完成。GitLab 在核心集之外多两项：合并请求的标签变化、合并请求被批准。Bitbucket Cloud 只多一项：PR 被批准。

Slack 触发文档列了三项：连接频道里有新消息、有人用指定 emoji 做出反应、工作区里新建了公开频道。其中新消息那一项有个容易踩的细节——不加消息过滤器时，它只在顶层频道消息上触发；想让线程内的回复也能触发，得加关键词或正则过滤器。

webhook 触发会给这个自动化生成一个私有 HTTP 端点，向它 POST 即可发起一次运行。Linear 触发三项：issue 创建、状态变化、cycle 结束。Sentry 触发三项：issue 创建、issue 更新、匹配全部 issue 事件。PagerDuty 触发四项：incident 触发、被认领、被解决，以及匹配全部 incident 事件。

四、产物这一头：工具、仓库档位与身份

产物去向由第 3 步的工具决定。文档里两个”默认开启”值得单独记一下：开 PR 这个工具对每个自动化都默认启用（仅限挂了仓库的自动化），computer use 也默认包含——文档说它让自动化能操作浏览器、产出截图或录屏。Memories 同样默认开启，允许关掉，它以命名条目形式跨运行持久化（默认是 MEMORIES.md），存放在 agent 工作文件系统之外。

其余工具都得你自己勾：在 PR 上评论（支持顶层评论和行内评论；只有开了 approvals，agent 才能批准、请求修改、撤销 review，否则只能发评论）、请求 reviewer、发消息到 Slack（可以指定频道，也可以让 agent 自己挑；文档提示允许任意频道时会一并给出发现公开频道所需的读权限）、只读地列出与读取公开 Slack 频道、以及接 MCP server。

MCP 这一条文档给了明确警告：接上一个 MCP server 就等于把该 server 暴露的每一个工具都给了 agent，只接你信得过的。

仓库设置三档，直接决定产物能走到哪一步：不挂仓库（不克隆代码，不能改代码也不能开 PR，适合只走 Slack、MCP、webhook、Linear、PagerDuty 的流程）、单仓库（一个仓库一个分支）、多仓环境（跨多个代码库）。文档特别写明：Slack 和 cron 这类触发器下 Cursor 默认不挂仓库，想让它改代码就得自己指定；而源码控制触发器必须指定仓库。源码控制触发下的仓库由 PR 推断，其它触发器则在设置里选仓库和分支。

身份这一块文档也写死了：GitHub 上的评论、review 批准和 reviewer 请求都以 cursor 的身份发出；团队作用域的自动化以 cursor 开 PR，Private 的自动化则以你自己的 GitHub 账号开 PR；Slack 消息由 Cursor bot 发出。查产物是谁留下的时候，这张对应关系比猜要快。

五、边界：文档明说不支持的那几处

fork 上开的 PR 不会触发。文档写得很直接：PR 类触发器不会在来自 fork 的 PR 上运行，这类运行会以 Fork pull requests not supported 报错失败，理由是分支只存在于 fork 上，用仓库的权限跑外部代码不安全（文档自述）。唯一的例外是 Pull request merged 触发器，因为它从 merge commit 开始，所以仍会运行。变通办法文档也给了：把分支推到仓库本身，从那里开 PR。
Bitbucket 只覆盖 Bitbucket Cloud（bitbucket.org），Bitbucket Server 与 Data Center 明确不支持；Bitbucket Cloud 也没有 PR 标签触发和行内 review 评论触发。
Slack 触发目前只能看见公开频道，文档用的措辞是 “at this time”，属于当下状态而非承诺。
上下文窗口没有开关。文档写明自动化因为以 cloud agent 形式运行，会使用所选模型支持的最大上下文窗口，没有上下文窗口的切换项（文档自述）。具体数值不在本文范围内。
Memories 对不可信输入有风险。文档明说记忆跨运行持久化，若自动化处理不可信输入需谨慎，输入可能写入误导性甚至恶意的记忆，进而影响后续运行。agent 在运行中也可能删除过期的记忆文件。
权限档提升会换身份。从 Private 或 Team Visible 提升到 Team Owned 后，它不再用你的 auth 而改用团队共享的 automations 服务账号。文档要求：若用了 webhook 触发器，提升后要重新生成 webhook API key；若用了依赖个人 OAuth 凭据的 MCP 或其它集成，得改配到团队服务账号上。
关于 beta：这两页官方文档里没有对上述任何一项标注 beta / preview / experimental。真正被写死的限制就是上面这几条”不支持”和”当前只支持”，别把两者混为一谈。

自动化页面上还有三个 Cursor 托管的 agent：Bugbot（审 PR 的 bug 与代码质量问题）、Security Agents（审 PR 并扫描代码库漏洞）、PR Routing & Approval（把 PR 路由给 reviewer，并可批准低风险改动）。它们各有自己的文档页，本文不展开。

六、配完怎么验证

文档没有给出一条”验证命令”，所以验证只能靠让触发端和产物端各自留下可见痕迹：

先验触发。定时触发器记住”不早于指定时间”这个口径，别把晚几分钟当成没触发。源码控制触发器如果迟迟没动静，第一件事是确认那个 PR 是不是来自 fork——按文档，这种情况会以 Fork pull requests not supported 失败，而不是安静地什么都不做。webhook 则先确认自动化已保存、URL 与 API key 已生成，再从你的系统 POST 过去。
再验产物。挑一个不改代码的组合来试最省事：不挂仓库 + Send to Slack，只要频道里出现由 Cursor bot 发出的消息，说明触发到产物这条链是通的。要验开 PR，就看 PR 作者身份——Private 的自动化开出来的 PR 挂在你自己的 GitHub 账号下，团队作用域的挂在 cursor 名下，对不上就说明权限档不是你以为的那一档。
验供应商差异。同一个自动化换到 GitLab 或 Bitbucket Cloud 上不触发时，先回去对照上面那份增量清单：标签变化、CI 完成、行内 review 评论这类触发器，文档只在 GitHub 一侧列了。
验记忆。文档写明记忆条目可以从工具配置处查看和编辑，也可以删除。跨运行行为异常时，这是先该看的地方。

提示词那一头，文档给的建议是：说清 agent 该检查/修改/产出什么，明确提到你已启用的动作，写清不同情况下的判断规则，给出”什么程度才值得开 PR 或评论、什么时候什么都不做”的质量线，并描述你想要的输出格式。这几条本质上都是在补触发与产物之间那段空白——触发条件由平台判定，产物出口由工具决定，中间那段只能靠提示词写死。

本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。