我在本地重放了 8 条模拟 PR 事件，其中 7 条唯一。无状态程序被唤醒 7 次；加上控制逻辑后，Agent 只醒了 3 次。同一条失败通知没有触发第二次修改，涉及生产密钥的评论也被交给人工。对于准备把 Agent 接进研发流程的团队，这三个结果比“能否自动修复代码”更值得先验证：它们决定了系统能否在无人看守时不重复执行、不越过权限边界。
如果系统只有 webhook、提示词和自动执行，它离无人值守还差一套可恢复、可核销的运行状态。
持续订阅扩大了自动执行的边界
Cursor 在 2026 年 8 月 19 日的更新中称，Cloud Agents 可以订阅 PR、Slack 线程和定时任务，在事件到达时自动唤醒；它还会自动订阅自己创建的 PR，继续处理 CI 失败和机器人评论。Subscriptions 目前仅适用于 Cloud Agents。官方说明：https://cursor.com/changelog/08-19-26
这类能力让 Agent 不必守在一次对话里等待下一条指令，但也让一次任务跨过了更长的时间和更多外部状态。上午发出的修复，下午可能收到重复通知；进程重启后，它还要判断上午那次 git push 到底有没有成功。
这里的数字来自本地模拟，不是 Cursor 产品实测，也没有连接真实 GitHub PR。实验只验证控制结构，不能说明 Cursor 的成功率、延迟、成本或生产可靠性。无状态基线的“唤醒”也只表示程序收到事件，未记录的后续结果不作推断。
| 事件 | 无状态基线 | 受控循环 |
|---|---|---|
| PR 创建 | 不执行 | 建立目标状态 |
| 单测失败 | 触发 | 首次修复成功 |
| 同事件重投 | 再次触发并重复动作 | 忽略 |
| 变量改名评论 | 触发 | 处理成功 |
| 生产密钥轮换 | 触发并尝试处理 | 转交人工 |
| 集成测试失败 | 触发 | 首次失败，第二次成功 |
| CI 通过 | 触发 | 更新为绿色，目标未完成 |
| 人工解除阻塞 | 触发 | 清除待办并完成目标 |
真正进入自动动作的是单测失败、变量改名评论和集成测试失败，因此 Agent 被唤醒 3 次；集成测试多尝试一次，所以共执行 4 次动作。三次成功动作各留下一条动作回执，共 3 条。
事件重放暴露状态缺口
重放开始后，单元测试失败事件先触发了一次修复。紧接着，同一个事件再次投递。无状态程序又醒了一次，并重复执行动作；受控版本根据稳定的事件 ID 认出重复投递，直接忽略。如果上游每次重试都会生成新 ID，仅靠投递 ID 仍不够，还要结合 PR、Commit SHA 和当前任务状态生成业务幂等键，确认“是不是同一次修复”。
随后，集成测试失败。第一次修复没有成功，第二次在限定次数内通过。因此，受控版本虽然只唤醒 Agent 3 次，却产生了 4 次动作尝试。每次成功都留下可查询的动作回执，最终共 3 条。回执可以是 commit hash，也可以是评论 ID；进程恢复时，它用来判断外部写操作已经落地、明确失败，还是结果未知。
**结果未知时再次执行，往往比执行失败更危险。**失败可以进入有限重试，未知状态则应先查询外部系统，不能靠模型猜测。
随后收到一条要求轮换生产密钥的评论。无状态基线会尝试处理这项高风险操作；受控版本没有把它交给 Agent，而是登记为人工待办。稍后 CI 已经变绿，任务仍未结束；直到人工解除这项阻塞，目标状态才转为完成。绿色构建只是一个条件，不代表所有风险事项已经清空。
无人值守取决于系统能否恢复判断
把这套控制逻辑放进设计评审，可以沿着一次中断来检查：服务重启后，系统能否还原当前 PR 的目标状态；能否识别已经处理过的事件；能否查询上一次外部写操作的回执；遇到敏感权限、重试耗尽或结果未知时，是否会停下并留下明确的人工入口。
这些信息若只存在于模型上下文或进程内存中，重启后就会消失。此时 Agent 看似会等待消息，实际只是一个会被反复触发的执行器。**当系统答不出“是否处理过、写操作是否成功、何时交给人”时，就不应开启无人值守。**这条判断同样适用于 Slack 工单和定时任务。
