Cursor 9 月 23 日发布两款新的开发机器人：Rollouts 负责盯着一次改动从合并到生产环境的全过程，发现回归就报警并尝试恢复；Security Reviewer 在每个 PR 上跑一遍安全审查，给出漏洞说明和修复建议。两者都面向 Teams 和 Enterprise 计划，在 Cursor 的 automations 标签页里开启。
Rollouts：合并之前先写好监控计划
按 Cursor 的描述，Rollouts 会 “watches a change from PR to production, flags regressions, and acts to restore a healthy state”，也就是跟踪一次改动从 PR 到上线，标出回归，并把系统拉回健康状态。
它要接入三类系统：代码托管、部署系统，以及 Datadog、Grafana、Honeycomb 这类遥测工具。流程分两段。合并前，它读代码差异、判断风险，据此生成一份监控计划；如果这次改动涉及的指标压根没有埋点，会在合并前提醒。部署后，它拿线上数据和基线对比，能识别只出现在单个接口或单个地区的回归，也会尽量把“预期中的变化”和“真出了问题”分开，避免改了限流阈值就被当成故障。
Cursor 说功能开关（feature flag）集成和对发布排期的感知还在计划中。“恢复健康状态”具体包括自动回滚到什么程度、要不要人工确认，公告写得比较笼统，只能以后续文档为准。
Security Reviewer：顺着代码流去找
Security Reviewer 的定位是 “runs on every PR, reads the change in the context of the whole codebase”。它按代码流追踪数据从哪里进、到哪里出，官方强调这和只靠规则匹配的扫描器有区别。检测范围包括：
- SQL、命令、模板、LDAP 等注入；
- 身份验证与授权缺陷；
- 凭证泄露；
- 不安全的反序列化和重定向；
- 依赖漏洞与基础设施配置问题。
Cursor 给的数据是，平均审查时间从 4.8 分钟降到 3.8 分钟，评论接受率从 45%-50% 升到 60%-70%。公告没交代这组数字的对照对象是它自家的早期版本还是别的方案，样本规模和统计周期也没有披露。“接受率”指开发者采纳了机器人的评论，不等于漏洞检出率，两者不能混看。
放到同类工具里看
AI 代码审查这条赛道这一年挤得很满。Anthropic 在 2025 年给 Claude Code 加了 /security-review 命令和对应的 GitHub Action，每个 PR 自动做一遍安全检查；GitHub Security Lab 本周刚公开一套用大模型驱动的模糊测试流程，从找入口一路跑到写漏洞报告。Cursor 自己的 Bugbot 在 6 月也发过一次更新，称速度提升 3 倍多、成本降 22%、多找出 10% 的 bug。
几家的切入点不同。Claude Code 的安全审查和 Bugbot 都停在“合并之前”；GitHub 那套流程偏安全研究，面向成熟开源项目深挖。Cursor 这次多走了一步，把 Rollouts 伸到了部署之后，碰到的是 SRE 和运维团队的地盘。这块长期有 Datadog 的 Watchdog、各家 APM 的异常检测在做，Cursor 的差异在于它读过这次改动的代码，知道该盯哪几个指标。
对团队来说，打开开关只是第一步。Rollouts 要拿到部署系统和监控平台的权限，所谓“恢复健康状态”，落到操作上可能就是直接触发回滚。大公司的变更管理流程能不能接受一个机器人拿着这类权限，比功能本身更难落地。Cursor 目前没有公布具体的权限模型和审计日志设计。
参考来源：CocoLoop、Cursor 官方博客、GitHub 博客、Anthropic Claude Code 文档；核验 Security Reviewer 审查时长与评论接受率、适用计划及检测范围。