本地重放 8 条模拟 PR 事件后，无状态基线被唤醒 7 次；加入控制层后，Agent 只被唤醒 3 次。重复投递被拦截，高风险的生产密钥操作转交人工，4 次动作尝试留下 3 张成功回执，目标最终完成。
这组数字揭示了事件驱动 Agent 的真正难点。消息到达并不等于应该立即执行，CI 变绿也不等于任务已经结束。系统还要知道同一件事是否处理过、外部动作是否成功，以及什么情况必须停止。
**这不是 Cursor 产品实测，也没有接入真实 GitHub PR。**本地实验只验证控制结构，不代表 Cursor 的成功率、延迟、成本或生产可靠性。
事件订阅改变了 Agent 的故障模型
Cursor 在 2026 年 8 月 19 日的官方更新中宣布，Cloud Agents 可以订阅 PR、Slack 线程和定时任务，并在事件到达时自动唤醒。它还会自动订阅自己创建的 PR，继续修复 CI 失败并处理机器人评论。目前，这项能力仅适用于 Cloud Agents。官方页面：https://cursor.com/changelog/08-19-26
一次代码修改由此不再是任务终点。Agent 会持续等待与目标相关的新事件，再决定是否继续执行。长期监听并不天然带来高可靠性；没有确定性控制层，后续通知会继续放大错误动作。
八条事件重放呈现的控制差异
“无状态基线”只记录事件是否触发程序；未被实验记录的执行结果不作推断。
| 事件 | 无状态基线 | 受控循环 | 工程含义 |
|---|---|---|---|
| PR 创建 | 不执行 | 建立目标状态 | 先记录目标，再等待动作事件 |
| 单测失败 | 触发 | 首次修复成功 | 成功结果写入回执 |
| 同事件重投 | 再次触发并重复动作 | 忽略 | 投递 ID 去重 |
| 变量改名评论 | 触发 | 处理成功 | 低风险动作可自动执行 |
| 生产密钥轮换 | 触发并尝试处理 | 转交人工 | 高风险动作越过自动化边界 |
| 集成测试失败 | 触发 | 首次失败，第二次成功 | 只在有限预算内重试 |
| CI 通过 | 触发 | 更新为绿色 | 人工待办未清零，目标仍未完成 |
| 人工解除阻塞 | 触发 | 清除待办并完成目标 | 完成条件必须显式判定 |
无状态基线包含 1 次重复动作和 1 次高风险动作尝试。受控循环忽略 1 条重复事件，将 1 次高风险操作转交人工；3 次 Agent 唤醒之所以产生 4 次动作尝试，是因为集成测试修复在有限预算内重试了一次。
去重、目标状态与动作回执的职责边界
事件 ID 只识别一次投递。本次重放以稳定的 evt-2 判断重复；如果上游重试会生成新的事件 ID，还要根据目标对象、Commit SHA 和业务状态计算幂等键，防止同一修复再次执行。
动作回执记录外部执行结果，例如 git push 的 commit hash 或工单评论 ID。它要与业务幂等键关联并持久化，进程恢复后才能判断上一次动作究竟成功、失败，还是仍然未知。
**事件 ID 负责投递去重，业务幂等键负责防止重复执行，动作回执负责核销外部结果，三者不能混用。**目标状态则持续记录 CI 状态、人工待办和完成条件，不能只存在于模型上下文或进程内存中。
控制循环可以收敛为几条明确规则：重复事件不唤醒模型；高风险动作登记人工待办；外部写操作绑定幂等键与回执；失败只在次数或时间预算内重试；CI 全绿且人工待办清零后，目标才算完成。
无人值守执行的准入与否决条件
进入真实研发流程前，系统至少应具备可持久化的投递去重、目标状态、动作回执、重试预算和人工边界。进程重启后，它必须能够恢复“当前 PR 停在哪一步、哪次写操作已经成功、还在等待谁处理”。
否决条件同样明确。无法稳定计算幂等键、无法查询外部动作回执、触及敏感凭据仍会自动执行，或者重试没有次数和时间上限，任一项成立，都不应开启无人值守执行。
事件订阅解决的是“何时醒来”，控制层解决的才是“醒来后能否安全地继续”。
