把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 把它叫最后一公里并给出了两个专门跑这段路的 botRollouts 和 Security Reviewer。这篇就把这两个东西的机制拆开讲清楚最后说说它对我们自己做 Agent 有什么可借鉴的地方。一、先分清两个 bot 各自管什么名称职责生效范围Rollouts跟踪一次变更从 PR 到生产发现回归并动手恢复健康状态PR 打开 → 上线之后Security Reviewer在代码库里找出安全漏洞并给出解释与修复方案每个 PR两者从发布当天起就在 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 的人有三个可迁移的点把我判断不了显式说出来。监控计划专门标出埋点答不上来的地方这个思路可以直接搬到 Agent 的输出契约里——让模型不只给结论还要声明它缺哪些证据。用基线对比代替绝对阈值。判断回归靠的是和部署前基线比而不是拍一个固定阈值。做 Agent 评测时同理同一个任务在不同环境下的绝对分数意义有限成对比较才有信息量。把动作分级把最终决定交给人。通知、暂停、开 PR 三档越往后越需要批准。Agent 处理高风险动作时这套自动到某一步、之后交人的分级方式比全自动更现实。收束Rollouts 和 Security Reviewer 都没有去碰写代码这一段它们啃的是 PR 之后那段又碎又要上下文的活把变更登记成一份可执行的监控计划、用基线对比判断回归、把安全评审放进每个 PR。这段路走通了自主的代码库才有一个能落地的起点。如果要在自己团队试建议从 Security Reviewer 开始它对上下文依赖最低一个 PR 就能看到效果也最容易建立信任。
把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 把它叫最后一公里并给出了两个专门跑这段路的 botRollouts 和 Security Reviewer。这篇就把这两个东西的机制拆开讲清楚最后说说它对我们自己做 Agent 有什么可借鉴的地方。一、先分清两个 bot 各自管什么名称职责生效范围Rollouts跟踪一次变更从 PR 到生产发现回归并动手恢复健康状态PR 打开 → 上线之后Security Reviewer在代码库里找出安全漏洞并给出解释与修复方案每个 PR两者从发布当天起就在 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 的人有三个可迁移的点把我判断不了显式说出来。监控计划专门标出埋点答不上来的地方这个思路可以直接搬到 Agent 的输出契约里——让模型不只给结论还要声明它缺哪些证据。用基线对比代替绝对阈值。判断回归靠的是和部署前基线比而不是拍一个固定阈值。做 Agent 评测时同理同一个任务在不同环境下的绝对分数意义有限成对比较才有信息量。把动作分级把最终决定交给人。通知、暂停、开 PR 三档越往后越需要批准。Agent 处理高风险动作时这套自动到某一步、之后交人的分级方式比全自动更现实。收束Rollouts 和 Security Reviewer 都没有去碰写代码这一段它们啃的是 PR 之后那段又碎又要上下文的活把变更登记成一份可执行的监控计划、用基线对比判断回归、把安全评审放进每个 PR。这段路走通了自主的代码库才有一个能落地的起点。如果要在自己团队试建议从 Security Reviewer 开始它对上下文依赖最低一个 PR 就能看到效果也最容易建立信任。
