Bugbot、Security Agents 与 PR Routing & Approval：Cursor 三类托管代理各管一段
先说一个容易踩的场景：团队开了 Bugbot，也在分支保护里把它的检查设成必需项，结果一个被 Bugbot 挑出问题的 PR 照样合进去了。这不是配置漏了，是三个代理的分工本来就不是「谁都能拦」。
Cursor 官方文档在《Automations》页里写明，Automations 页面包含三个由 Cursor 托管的代理：Bugbot、Security Agents、PR Routing & Approval。它们住在同一个入口下，但插手 PR 的时刻不同，产出的东西也不同——一个产出评论与检查状态，一个产出安全发现，只有第三个能对 PR 做出「批准」这个动作。下面按一个 PR 的时间顺序走一遍。
共同的底座：都跑在 Automations 上
三个代理不是三套独立系统。官方文档《Security Agents》页写明，两类安全代理都运行在 Automations 平台上并且需要 Cloud Agents；《Automations》页也写明，Automations 创建的是后台运行的 cloud agents，可以按计划触发，也可以响应来自 GitHub、GitLab、Slack、webhook、Linear 等来源的事件。
这一层决定了一件事：你在配置里选的「什么时候跑」，本质上就是在选 Automations 的 trigger 类型。三个代理的差别，很大一部分就是它们各自被允许挂在哪种 trigger 上。
第一段：Bugbot 的触发时机与产出
Bugbot 的位置在 PR 有新内容的那一刻。官方文档《Bugbot》页写明，它在每次 PR 更新时自动跑审查，也可以在任意 PR 上评论 cursor review 或 bugbot run 手动触发。
产出分两路。一路是 PR 上的评论——文档写明它会读取已连接的 PR 评论（顶层与行内），把这些当作上下文，以避免重复建议。另一路才是本文开头那个坑的答案：CI 检查状态。文档写明每次审查都会发布一个状态，在 GitHub 上表现为名为 Cursor Bugbot 的 check，在 Bitbucket 上表现为 key 为 cursor-bugbot 的 build status，在 Azure DevOps 上表现为 context 为 cursor-bugbot/review 的状态。
这个状态只有三种结论，逐条抄文档的语义：
| 结论 | 文档写明的含义 |
|---|---|
success | Bugbot 没发现问题，且早先的运行没有留下未解决的 Bugbot 评论 |
neutral | 发现了问题、运行被更新的提交取消、或 Bugbot 遇到内部错误 |
failure | 发现了问题，且该 check 被配置为在存在未解决问题时失败 |
关键在文档的一句限定：发现问题时的默认结论是 neutral。所以文档明说，光把这个状态设为必需项并不会因为「有发现」而拦住合并；如果你的组织能用「未解决问题即失败」这个行为，要单独启用它，才会让未解决的发现产生失败状态。另外文档写明 Bugbot 不会发出 skipped 这个结论——如果你的流水线脚本在判断 skipped 分支，那段逻辑永远不会命中。
还有一个容易混的点：启用 Autofix 后，GitHub 上可能另外出现一个 Cursor Bugbot Autofix 检查，文档写明这个检查只使用 success 或 neutral 两种结论。也就是说它天然不具备拦截能力，别把它当门禁挂。
Bugbot 具体怎么写规则、怎么配 Autofix，我们另有一篇专门讲，这里只落它在分工里的位置：它负责发现并留痕，不负责放行或阻拦。
第二段：Security Agents 的两条时间轴
Security Agents 与 Bugbot 最大的形态差别，是它本身分成两类，挂在两条完全不同的时间轴上。官方文档《Security Agents》页写明，它包含两种 Cursor 托管的代理类型：
- Security Reviewer：在 PR 合并前做检查，支持基于 Git 的 Automations 触发器，包括 pull request 与 merge request 事件；
- Vulnerability Scanner：扫描处于静止状态的代码库，支持 cron 触发器，用来找既有的、长期存在的、以及 PR 评审阶段漏掉的问题。
换句话说，前者和 Bugbot 站在同一个时刻（PR 上有变更），后者根本不看 PR，它按周期扫全库。你如果只配了 Security Reviewer，就默认放弃了「历史遗留问题」这一块；反过来只配 Scanner，PR 阶段就没有安全侧的把关。
配置上有一处硬要求值得单独拎出来：文档写明两类代理都支持 tools 与 MCPs，并且每个代理至少需要一个 tool 或 MCP 才能运行。这和 Bugbot 不一样——Bugbot 的产出通道（PR 评论、检查状态）是内建的，而 Security Agent 的产出通道要你自己接上，文档给的用法是把漏洞送到 Slack 频道、issue tracker 或其它已连接的系统。少配这一步，代理就跑不起来。
产出侧文档给了三个指标：Vulnerabilities found（发现的安全问题数）、Issues fixed（报告后被解决的数量）、Resolution rate（被修复的比例）。判定「是否修好了」的方式是文档自述的：Cursor 使用 LLM 审阅增量 diff、评估被标记的问题是否已解决。这句话我照抄，不替它解释准确率——文档没写。
计费与身份也在文档里写明：Security Agents 按团队用量层级计费，运行在共享的团队服务账号下，因此不影响任何个人用户的用量。另外《PR Routing & Approval》页写明，Security Agents 需要 team 或 enterprise 计划。
第三段：PR Routing & Approval 才是做决定的那个
前两个代理产出发现，第三个消费这些发现。官方文档《PR Routing & Approval》页写明，它在你的 PR 上运行，依据代码归属与提交历史指派评审人，并且可以在满足你设定的条件时批准低风险 PR；文档同时明确一句限定——它不替代完整的代码评审。
触发时机上，文档列出它支持的 PR 事件包括：PR opened（创建 PR 时）、PR pushed / updated（向已有 PR 推新提交时）、PR commented（在已有 PR 上出现匹配正则的评论时）。
要跑起来，文档写明代理必须至少启用一个主动作：Request Reviewers 或 Approve PR。可选集成包括 Slack 通知、Microsoft Teams 通知，以及 MCP 服务器。
它怎么把前两段的产出接进来，是这篇的接缝所在。文档在 Configuration 里给了四个信号开关：Use Bugbot Review Context、Use Security Review Context、Use Risk Score、Maximum Risk for Approval。文档写明，启用这些上下文后，代理会等待相关的 agentic reviewer 检查跑完，再把它们的发现当作批准信号；并且——这一句是三段拼起来的关键——如果 Bugbot 或 Security Agents 报出了需要人工评审的发现，PR Routing & Approval 不会批准该 PR。
风险这一侧，文档写明 Use Risk Score 启用风险分类（可以再用提示词定制），Maximum Risk Threshold 设定代理可以批准的最高风险等级，超过阈值就不批准。文档没有给出等级的取值列表，这里也就不编。
策略文件是怎么被找到的
这部分是文档里写得最细、也最容易配错的地方，值得逐条抄。
目录级策略文件的文件名是精确的：
APPROVAL_POLICY.md
文档写明，对每个被改动的文件，代理会检查该文件所在目录以及每一级祖先目录是否存在这个确切文件名。只有精确的 basename 匹配才被信任——文档点名列出会被忽略的写法：POLICY.md、approval_policy.md、APPROVAL_POLICY.md.bak、team_APPROVAL_POLICY.md。优先级是「最近的那个最高」：离改动文件最近的 APPROVAL_POLICY.md 对该目录下的文件优先级最高，祖先目录的策略仍然适用，除非与更具体的策略冲突。
路由文件是另一个，位置固定在顶层：
.cursor/approval-policies/ROUTING.md
文档写明它是一个 YAML 的产品条目列表，每个条目包含三个字段：product（产品或领域名）、boundary（语义边界，或显式的仓库相对路径与 glob）、policies（策略提示指针，可以是显式文件路径，也可以是语义描述）。同时文档补了一句托底：ROUTING.md 缺失时，基于目录的 APPROVAL_POLICY.md 发现照常运行，缺路由不会削弱策略发现。
优先级链文档也写死了：适用的审批策略提示会覆盖通用审批标准、风险阈值、评审人选择指导、自定义审批说明，以及默认的自动评审姿态。策略冲突时代理遵循最具体的那条；具体程度不明确时，它遵循更严格的一条并避免自动批准。
最后一条我认为是这一页里最该被记住的：文档写明，如果一个 PR 改动了审批策略、路由文件、被路由到的策略文件或评审人专属策略文件，代理不会用改动后的内容来放宽这同一个 PR 的评审要求——它会使用基础分支上的版本，取不到基础分支版本时则要求人工评审。
把三段接起来
按文档写明的口径，一个 PR 上的顺序大致是：PR 打开或推新提交 → Bugbot 按 PR 更新自动跑，留下评论与检查状态；Security Reviewer 若挂了 PR 事件触发器，同样在这一刻跑，把发现送往你接的通道 → PR Routing & Approval 若启用了对应上下文，等这些检查跑完，结合策略文件、风险分与配置决定指派评审人或批准。Vulnerability Scanner 不在这条线上，它按 cron 独立跑。
还有一条本地侧的入口：官方文档写明可以用 /review-bugbot、/review-security 或 /review skills 在推代码之前从 agent 里跑。默认审查的 diff 是分支相对于基础分支的全部改动，含已提交与未提交的部分；比较的基准是默认基础分支，基准不是默认分支时需要你告诉 agent 用哪个分支。边界要照实标出来：文档写明 /review 与 /review-bugbot、/review-security 在 Cursor 3.7+ 与 cursor.com/agents 上可用，CLI 支持文档写的是 coming soon——现在别按能用来设计流程。
平台差异与几处文档没说的
这三个代理都跑在云端与 SCM 侧，官方文档在触发、检查状态、策略文件这几处没有区分 Windows 与 macOS/Linux，所以本地系统不影响它们的行为。Windows 用户真正需要注意的只有仓库内那几个文件名：.cursor/BUGBOT.md、APPROVAL_POLICY.md、.cursor/approval-policies/ROUTING.md。文档对 APPROVAL_POLICY.md 明确要求精确 basename 匹配，而 Windows 与 macOS 的本地文件系统默认对大小写不敏感——这一条是通用常识，不是 Cursor 官方文档的内容——本地改名不一定会被 Git 记录成实际改名，建议以仓库里记录的文件名为准核对。
几处文档没有说明的，如实列出来，别自己补：Bugbot、Security Reviewer 与 PR Routing & Approval 三者之间的等待超时、重试次数与失败降级行为，官方文档没有说明这一点；风险等级的具体取值列表也没有给出。Azure DevOps 侧另有一条限定，文档在 Bugbot 的接入清单里标注为 limited availability。此外 Bugbot 的 MCP 支持，文档写明仅在 Team 与 Enterprise 计划提供。
这三个东西名字都带「review」的味道，但实际分工是：一个找 bug 并留痕，一个找安全问题并送出去，只有第三个握着「批准」这个按钮，而它的判断依赖前两个是否报了需要人看的发现。想让「有发现就合不进去」，要么在 Bugbot 侧启用未解决即失败的行为，要么就把决定权交给 PR Routing & Approval 并把上下文开关打开——只挂一个必需检查是不够的。该产品迭代频繁，以上设置项名称与行为以官方文档最新内容为准。
本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。
该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现；
我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。
该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。
本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。
安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。