企业官网建设流程全解析

把Agent代码送进生产：Rollouts与Security Reviewer拆解

原文：Cursor Blog - 《Bots for the last mile: Rollouts, Security Review》（https://cursor.com/blog/rollouts-and-security-reviewer）

写代码这件事这两年提速得很快，但 Cursor 这篇官方博客开头就点出了一件反常识的事：真正卡住团队的，往往不是写代码，而是 PR 之后的一长串动作。

安全评审、盯着部署、判断某个延迟抖动到底是不是回归、以及在十一次改动里找出是谁把结算流程搞崩了——这些活儿很碎、重复度极高、又特别依赖上下文。Cursor 把它叫"最后一公里"，并给出了两个专门跑这段路的 bot：Rollouts 和 Security Reviewer。这篇就把这两个东西的机制拆开讲清楚，最后说说它对我们自己做 Agent 有什么可借鉴的地方。

一、先分清两个 bot 各自管什么

两者从发布当天起就在 Teams 和 Enterprise 计划开放，在 automations 面板里开启即可。下面分开讲。

二、Rollouts：把"这次改动有没有出事"变成可执行的跟踪

2.1 先接入三类系统

Rollouts 需要你接上三种数据源：源代码管理、部署系统，以及可观测性平台（官方举例是 Datadog、Grafana、Honeycomb 这类放着指标和 trace 的地方）。

为什么必须是三类？因为要回答"这次改动有没有出事"，光有代码不够——你还得知道它什么时候真正生效、生效之后哪些指标本该发生变化。缺了部署系统，它不知道时间轴；缺了遥测，它没有判断依据。

2.2 合并前先写一份监控计划

这是我觉得最值得学的一步。在代码合并之前，Rollouts 会读这次的 diff，然后产出一份监控计划，里面包含三部分内容：

• 它识别出的风险点；
• 这次改动预期会产生什么效果；
• 你的埋点在哪些地方答不上来这次改动到底成没成。

第三点是精髓。多数人写监控计划只会列"我要盯哪些指标"，而它反过来标出"哪些地方我根本没法判断"，并且允许你手工补充。官方提到，缺失埋点是坏改动被放过的最常见原因——这句话本身就是一条很有分量的工程经验。

2.3 部署后和基线对比

上线之后，Rollouts 把监控计划里的信号和部署前的基线做对比。发现异常时，它会告诉你怀疑是哪次变更导致的，以及它打算怎么做。具体动作取决于你的配置，一共三档：

• 通知作者；
• 暂停渐进式发布；
• 开一个 revert PR，等你批准。

2.4 官方自认做得好的三件事

官方列了三条，我按自己的理解转述：能抓到只发生在某个 region、某个 endpoint 上的回归，抢在全局告警之前报警；能区分"预期内的变化"和"真回归"，避免有意的流量高峰乱报；能在合并前就点出缺失埋点。

另外官方说明后续会补两个能力：feature flag 集成（让 Rollouts 直接放量和回退流量），以及感知 release train 和部署冻结窗口。

三、Security Reviewer：用读代码的方式做安全评审

3.1 静态分析为什么不够

官方给了一个很具体的例子：静态分析是模式匹配，它会对每一次靠近 SQL 调用的字符串拼接报警，却漏掉"某次重构之后授权检查不再执行"这种问题。原因是静态分析看的是代码形状，不是数据怎么流动。

Security Reviewer 换了个角度：它像安全工程师一样读代码，追问三件事——用户输入从哪里进来、最后落到哪里、中间经过了什么。而且它是在整个代码库的上下文里读这次改动，不是只看 diff。

3.2 开箱覆盖的范围

• SQL、命令、模板、LDAP 各层的注入；
• 新增和变更路由上缺失或失效的认证与授权；
• 被提交进源码的密钥与凭据；
• 不安全的反序列化与未校验的跳转；
• 引入已知漏洞的依赖变更；
• 基础设施与配置里的不安全默认值。

3.3 一条发现长什么样

每条发现都带三件东西：严重级别、攻击路径、一键修复。个人经验是"攻击路径"比严重级别更有用——严重级别告诉你要不要马上动手，攻击路径告诉你为什么它是真的，这两件事经常被混在一起谈。

四、接进来大致长什么样

官方给出的接入路径很直接：在 automations 面板开启，运行在 Teams / Enterprise 计划上。下面这段是用来理解它依赖哪些外部上下文的，不是官方配置格式，请以官方文档为准。

# 自拟示意：Rollouts 需要的外部上下文rollouts:sources:scm:github# 源码管理：拿到 PR 和 diffdeploy:argocd# 部署系统：知道变更何时真正生效telemetry:# 可观测性：指标与 trace 的来源-datadog-grafanaplan:before_merge:true# 合并前生成监控计划，并允许人工补充on_regression:revert_pr# 可选：notify_author / pause_rollout / revert_pr

看懂这段就够理解它的设计取向：它不是一个"帮你写代码"的 bot，而是一个把发布流程里的判断动作自动化的 bot。

五、对做 Agent 的人，有三个可迁移的点

1. 把"我判断不了"显式说出来。监控计划专门标出埋点答不上来的地方，这个思路可以直接搬到 Agent 的输出契约里——让模型不只给结论，还要声明它缺哪些证据。
2. 用基线对比代替绝对阈值。判断回归靠的是和部署前基线比，而不是拍一个固定阈值。做 Agent 评测时同理：同一个任务在不同环境下的绝对分数意义有限，成对比较才有信息量。
3. 把动作分级，把最终决定交给人。通知、暂停、开 PR 三档，越往后越需要批准。Agent 处理高风险动作时，这套"自动到某一步、之后交人"的分级方式比"全自动"更现实。

收束

Rollouts 和 Security Reviewer 都没有去碰"写代码"这一段，它们啃的是 PR 之后那段又碎又要上下文的活：把变更登记成一份可执行的监控计划、用基线对比判断回归、把安全评审放进每个 PR。这段路走通了，"自主的代码库"才有一个能落地的起点。

如果要在自己团队试，建议从 Security Reviewer 开始：它对上下文依赖最低，一个 PR 就能看到效果，也最容易建立信任。