Cursor 公布 Rollouts 回归处理流程：定位引入问题的 PR、创建 issue、一键启动 cloud agent 修复

北京时间 10 月 3 日凌晨，Cursor 的官方 X 账号，说明 Rollouts 捕获回归（regression）之后的处理方式：它会找出引入问题的 PR，创建一个 issue；用户一次点击就能启动一个 cloud agent 来完成修复。帖文还注明，Rollouts 的用量额度（usage credits）包含至 10 月 3 日。

这是 Cursor 对自家产品行为的描述。配套的写明了这条链路的操作细节与限制。

图为 Cursor 官方 Rollouts 演示视频画面：Rollouts 的监控计划以评论形式出现在一个 PR 上。

issue 页面上的操作，以及 Rollouts 不会做的事

按 Cursor 文档，检测到回归时，Rollouts 会指出它怀疑的那项变更、创建 issue 并通知作者。如果一项变更没有引发回归，但新代码路径跑了之后效果缺失、报错或行为不对，Rollouts 同样会创建 issue。在 issue 页面上，用户可以选择「Fix issue」启动 cloud agent，也可以填写理由后关闭；修复开始后，按钮会变成「View fix」，用来重新打开那个 agent。

文档同时写明，Rollouts 不会自行合并、revert 或回滚变更。

每个 PR 先拿到一份监控计划

要在部署之后判断有没有回归，先得有判断标准。按文档，每当一个 PR 打开，Rollouts 会阅读 diff 和它触及的系统，写出一份监控计划（rollout plan）：列出它发现的风险、这项变更应该产生的效果、将要检查的信号，以及埋点中会让变更难以验证的缺口。计划会以评论形式发到 PR 上，支持 GitHub、GitLab.com 和 Bitbucket Cloud；在 Cursor 的 Origin 平台上，计划显示在 PR 页面里。要修改计划，就在 PR 评论里提及计划评论中列出的 handle，说明该盯什么、该忽略什么；Rollouts 会修改计划并回复，只有拥有仓库写权限的人才能改动它。

从部署当下到三天后：五个检查节点

部署事件到达时，Rollouts 会醒来，对着日志、指标和链路追踪跑一遍计划，并在得出判断后回报 PR。它按环境分别跟踪：一次变更可以在 staging 环境验证通过，同时在 production 被标出问题。检查发生在部署的当下，以及之后的 20 分钟、1 小时、1 天和 3 天。

这套判断依赖遥测。文档要求至少接入一个可观测性工具，例如 Datadog；没有接入的话，变更会一直停在 pending 状态，Rollouts 也就无法检测出问题。Cursor 的则称，它能抓住局限在单一地区、单一端点的回归，赶在全局告警触发之前；也能把有意的效果变化与回归区分开，不为预期内的波动触发告警。

图为 Cursor 官方 Rollouts 演示视频中的监控视图：变更在 production 部署后进入检查。

9 月 23 日上线，用量额度为期十天

Rollouts 与安全审查 bot Security Reviewer 一起在 9 月 23 日上线。当天的把两者描述为覆盖代码交付「最后一公里」的 bot，面向 Teams 和 Enterprise 套餐，从 automations 标签页启用。changelog 称 Rollouts 是 Firetiger Change Monitors 的 Cursor 版本，用 Bot Development Kit 重建。

上线公告说，接下来 10 天会包含用量额度供团队试用：Teams 客户获得大约 50 次变更的额度，Enterprise 客户大约 500 次。帖文给出的截止日与公告所说的「接下来 10 天」对得上。

回复里的追问：个人版、二次回归与复现

帖文下面，用户追问的内容大致分三类。

套餐范围是其中一类。@aladicf ：「Rollouts 是否向付费的个人版用户开放测试？用量是单独在套餐之外计费吗？」

修复质量是另一类。@aiartgallerie 这条从回归到问题 PR 再到一键 agent 修复的链路是自己一直想要的，但他会盯住一点：「第一次修复正确的频率有多高，还是说它会再带出第二个回归。」@sebastianbennis 更具体：「我希望 agent 在动这个修复之前先写一个会失败的测试。交接的内容能不能带上复现步骤，而不只是那个问题 PR？」

第三类追问指向额度到期后的计费。@MLaurusevicius ：「额度只到 10 月 3 日，这个窗口很短。之后 Rollouts 的用量是走正常套餐，还是单独计费？」