Cursor 上线 Rollouts 与 Security Review：把 AI 编程的战线推到「合并之后」

要点

• Cursor 于 2026-09-23 上线两个 bot：Rollouts 与 Security Review，官方定位是「shipping code 的最后一公里」。两者今日上线，Teams 与 Enterprise 计划可用。
• Rollouts 给每个 PR 挂一个监控器，按环境报告变更健康度三态：verified healthy（已验证健康）/ regression detected（检测到回归）/ inconclusive（证据不足）。它是 Firetiger Change Monitors 的 Cursor 版本，用 Bot Development Kit 重写。
• 监控计划是 PR 评论，且可编辑：PR 打开时 Rollouts 读 diff 与所触及的系统，写出一份监控计划——识别出的风险、该变更本应产生的效果、要检查的信号、以及会让变更难以验证的埋点缺口。你在 PR 里改这份计划，Rollouts 就按你的版本执行。
• 部署跟踪按环境分开：对变更 commit 的 deploy 事件唤醒，拿日志 / 指标 / 链路跑计划。同一个变更可以在 staging 被验证健康、同时在 production 被标记异常。它同时检查「预期效果」与错误 / 延迟信号，得出结论后回写到 PR。
• 回归处理：Rollouts 会点名它怀疑的变更并通知作者；按配置可开一个 revert PR 供review，或把发现交给云 agent 去修。官方明确：Rollouts 今天不会自己合并或回滚。
• Security Review 每个 PR 输出一条审查评论，只报可利用的漏洞；风格与质量问题留给 Bugbot。启用按仓库配置，draft PR 会跳过。
• 检测范围（官方列举）：SQL / 命令 / 模板三类注入；认证与授权绕过（包括「重构后某处校验不再执行」这类）；提交进仓库的密钥与凭证；SSRF 与未校验的重定向；不安全的反序列化；引入已知漏洞的依赖变更。做法是从用户输入进入点一路追踪它经过了什么。
• 每条发现带严重性、攻击路径与修复建议；带理由 dismiss 后，该 PR 上不再重复提出。支持团队自定义规则（例如「外部调用必须走哪个 client」「哪些表绝不能在请求处理器里查」），并在每个 PR 上强制执行。
• 集成面：源码管理接 Origin 或 GitHub，部署事件接你的 CD 系统，信号接 Datadog 等 telemetry provider；feature flag 集成即将支持。
• 试用额度：官方给出未来 10 天的赠送额度，Teams 约 50 个变更、Enterprise 约 500 个变更。

背景与分析

从「写对代码」到「上线后证明没写错」

2026 年 AI 编程工具的竞争，前两年集中在生成侧：谁补得准、谁能改多个文件、谁能跑长任务。Cursor 自己在 8-19 那版把 cloud agents 做到了「订阅 PR / Slack 事件、hold 住 /goal、subagent 各自跑独立 VM」，9-2 上了 Self-Hosted Machines（工具执行留在客户网络），9-10 上了 Projects（协调 agent 派发 subagents、维护跨月共享上下文）。

Rollouts 是这条线的自然延伸，但方向变了——它管的不是「代码怎么生成」，而是「合并之后到底有没有把线上搞坏」。

这件事过去由 Datadog / Sentry 一类可观测性产品在管，但它们的工作方式是「告警 → 人来归因」。Rollouts 做的是把归因这一步自动化：PR 打开时就先写好「这个变更该怎么验证」的计划，部署后按计划跑，得出「健康 / 回归 / 证据不足」的结论再回写到 PR。

「证据不足」这一态，比「健康」更重要

官方三态里最值得注意的不是 verified healthy，而是 inconclusive。

Rollouts 写的监控计划里有一项专门列出埋点缺口（gaps in instrumentation）——哪些地方没埋点，会让这个变更无法被验证。也就是说，它把「不知道」显式化成一个结论，而不是像传统告警那样「没报警 = 没问题」。

对 AI 生成代码的场景，这一态尤其关键：AI 写的变更往往跨文件、跨系统，人肉 review 很难判断「它到底动了哪些外部依赖」。把「我没法验证这个变更」当成一条正式结论回写到 PR，比给个绿色对勾诚实得多。

Security Review 与既有 PR 审查机器人的分工

本站已收录多款 PR 审查类工具（CodeRabbit、Greptile、Qodo 等）。Cursor 这次的差异化在两点：

1. 职责切得很干净——Security Review 只报可利用的漏洞，明确「style and quality stay with Bugbot」。这与多数 PR 审查 bot 把「代码风格 + 潜在 bug + 安全」混在一条评论里的做法不同，目的是降低噪音、提高每条发现的信噪比。
2. 团队规则可强制执行——「外部调用必须走哪个 client」「哪些表绝不能在请求处理器里查」这类只有你们团队知道的约定，可以写成规则在每个 PR 上强制检查。这类规则是通用 SAST 工具做不到的，因为它不在 CVE 库里，只在你们的架构约定里。

需要提醒的是：官方没有披露检测引擎的实现方式（是静态分析、LLM 审查还是混合），也没有给出误报率 / 检出率的任何量化数据。本站未做一手实测，建议按「辅助层」而非「门禁层」引入，先并行跑一段时间再考虑是否能替代既有 SAST。

与 Bugbot 的关系：不是替代，是分工

Cursor 原有 Bugbot 负责 PR 自动审查与自动 fix 提交。官方这次的表述是「Style and quality stay with Bugbot」——风格与质量留在 Bugbot，可利用漏洞交给 Security Review。

两者是否会自动去重、同一处问题会不会被报两次，官方 changelog 未说明，属待确认项。

对开发者的影响

1. Teams / Enterprise 用户今天就能开。 从 dashboard 的 automations 标签启用，接好源码管理、CD 系统与 telemetry provider，下一个 PR 就开始被监控。
2. 先把监控计划当文档读一遍。 计划里那节「埋点缺口」其实是免费的可观测性体检报告——它会告诉你哪些系统改了却没人看着。
3. 别把 Rollouts 当自动回滚。 官方写死了「does not merge or roll back on its own today」：它只开 revert PR 供人 review。权限仍然是你的。
4. Security Review 应按「辅助层」引入。 没有官方量化指标、没有误报率数据；建议与既有 SAST / PR 审查并行跑，而不是立即替换。draft PR 会被跳过，可在 draft 阶段先自查。
5. 团队规则值得先投入。 「哪些表不能在请求处理器里查」这类约定写进规则后能被强制执行，这是通用工具补不上的部分，也是这套功能里最容易被忽略的价值点。
6. 成本要盯。 赠送额度只覆盖未来 10 天（Teams ~50 / Enterprise ~500 个变更），后续计费方式官方 changelog 未说明；按 PR 量估算的话，高频仓库的增量成本不可忽略。
7. 国内团队注意接入链路。 Rollouts 依赖 GitHub / Origin、CD 系统与 Datadog 一类 telemetry provider；若你的 CD 与监控都在内网自建，能否接入官方未说明，属待确认项（同类问题在 Cursor Self-Hosted Machines 上已有先例——执行环境可下沉，但控制面仍在云端）。

AI 之家 观点

其一，AI 编程工具的战场正在从「生成」移到「验证」。 当生成侧的能力趋同（各家都能改多文件、都能跑长任务），差异化只能往下游走。Rollouts 的价值不在于它比 Datadog 更懂监控，而在于它知道这个 PR 改了什么——生成工具天然握有 diff 与意图，这是可观测性产品拿不到的上下文。这个结构性优势，是纯监控厂商很难复制的。

其二，「inconclusive」这一态值得所有做 AI 辅助工具的团队抄。 AI 生成的代码最大的风险不是错，是**「没人知道它对不对」**。把「无法验证」做成一等结论而不是静默通过，是诚实的工程设计，也直接降低了「AI 写的代码没人敢碰」的组织性风险。

其三，Security Review 现在还不该被当门禁。 官方给了详尽的检测清单（注入 / 越权 / 密钥 / SSRF / 反序列化 / 依赖漏洞），但没给引擎实现、没给误报率、没给检出率。清单漂亮不等于效果好。在拿到量化数据前，把它当「第二双眼睛」而不是「守门员」，是正确的姿势。

其四，团队规则是被低估的那一项。 行业里谈 AI 代码安全，谈的几乎全是 CVE 与已知漏洞模式；但真实事故里最常见的成因是「违反了我们自己的架构约定」。这类规则通用工具永远学不会，只有你们自己写得出来，而它是这套功能里唯一能承载这层东西的入口。先写规则，再看检测清单。

相关阅读

• 工具：Cursor · CodeRabbit · Greptile · Qodo · Bito
• 概念：Agent 沙箱 · Agent 编排 · AI 代码编辑器 · Vibe Coding
• 对比：Cursor vs Windsurf vs Trae 横评 · Cursor vs v0
• 方案：Cursor Rules 最佳实践

来源

• Rollouts and Security Review（Cursor 官方 Changelog，2026-09-23） — 一手来源，本文全部事实以此为准
• Cursor Projects（Cursor 官方 Changelog，2026-09-10）
• Self-hosted machines（Cursor 官方 Changelog，2026-09-02）
• Cloud Agents and Cursor Harness Improvements（Cursor 官方 Changelog，2026-08-19）
• Cursor 完整 Changelog

本条由 AI 之家 编辑部根据 Cursor 官方 changelog 原文整理，未做一手实测。官方未披露 Security Review 的检测引擎实现方式与误报率 / 检出率数据，亦未说明 Rollouts 后续计费方式；两者均已在正文标注为待确认。生产环境引入前建议先并行试跑。