小岛AI
| ONLINE |

posts/cursor-agent-subscription-runtime.md

Cursor Agent 一直干到完成,不一定是好消息

小岛AI 2026 / 08 / 21

@cursor check back in an hour and keep going until that feedback is in

Cursor 在 8 月 19 日的官方更新里,拿这句话演示新的订阅能力。你可以让 Cloud Agent 盯着一条 Slack 讨论,等反馈出现再继续,也可以让它订阅自己创建的 PR,CI 红了就修,bot 留了评论就处理。

人可以先走。

Agent 留在那儿等事件。

好家伙,这次最值得看的不是 Cursor 又多了几个斜杠命令,而是聊天框外面终于长出了一套长期运行机制。订阅负责叫醒,/goal 负责守住目标,自定义模式把技能固定下来,子智能体各自拿一台隔离虚拟机,后续消息还能等到下一次工具调用再送进去,不用从动作中间把它掐断。

把这五块拼起来,Cursor Agent 已经不太像「你问一句,它做一轮」的代码助手了。它更像一个事件驱动的 worker,平时休眠,收到 PR、Slack、定时器或系统事件后启动,带着一份操作手册干活,必要时分出几个隔离 worker,直到它认为目标完成。

Cursor 8 月 19 日更新覆盖订阅、自定义模式、子智能体隔离、长期目标与转向

Cursor 官方更新卡片,五项能力指向同一件事,让 Agent 跨越一轮对话继续工作。

这一步有点子牛逼。

也正因为如此,我觉得「一直干到完成」不该被当成一句纯粹的好消息。一次对话跑偏,关掉窗口就完了。一个会自己醒来、自己重试、自己开子任务的 Agent 跑偏,消耗的是云端机器、模型额度、外部 API 配额,以及真人第二天才发现的时间。

模型能力只是其中一半。

另一半叫运行时纪律。

从一轮对话,变成一台状态机

过去很多代码 Agent 的生命周期很短。人发一条需求,模型读仓库、改文件、跑测试,收尾交一个 diff。过程再复杂,也被包在同一轮会话里。

订阅把这条线剪开了。

PR 新增一条 review comment,CI 从 running 变成 failed,Slack 线程里终于有人补了复现步骤,定时任务到了下一个小时,这些都可能让 Agent 再次运行。Cursor Automations 文档列出的触发源已经覆盖 GitHub、GitLab、Bitbucket、Slack、Webhook、Linear、Sentry 和 PagerDuty。它不只是在等人发 prompt,而是在消费一个事件流。

只要系统开始消费事件,就绕不开状态。

idle -> triggered -> running -> verifying -> completed
                    |             |
                    v             v
                 retrying       blocked
                    |
                    v
                  failed

这张图不一定是 Cursor 内部的实现,它是团队接入长期 Agent 时至少该写在白板上的合同。每个任务现在走到哪一步,谁触发了它,处理的是哪次提交,已经重试几次,下一次唤醒还该不该继续,都得有确定答案。

最容易踩的坑是重复事件。

同一条 CI 失败通知可能重发,PR 评论可能被编辑后再次进入队列,Webhook 调用方超时后也可能重试。如果 Agent 每次都当成新工作,它会在同一分支重复改同一个 bug,连续发几条相似评论,或者创建两张内容几乎一样的 PR。

传统后端早就给这类问题准备了一个不太性感的词,幂等。为事件生成稳定的去重键,把仓库、PR、提交 SHA、事件类型和版本绑在一起。相同键已经进入 running 或 completed,就别再开一台机器。新的提交进来,再生成新的工作项。

不是哥们,Agent 换了个名字,也没有自动逃离分布式系统的老坑。

官方文档里有个很小但很诚实的边界。来自 fork 的 PR 默认不会触发这些自动化,因为外部代码分支不在主仓库里,拿着仓库权限去执行不受信代码并不安全。这个限制看着扫兴,其实比一张「全自动修 PR」海报靠谱多了。

/goal 给了耐力,没给完成定义

这轮更新里最容易让人兴奋的是 /goal。官方给的例子很直接,让 Agent 修掉所有不稳定测试,并把 CI 变绿。它会持续朝这个目标工作,不在完成一小步后就宣布收工。

长任务最烦的确实是半途而废。模型改完第一个报错,看到测试还红着,却用一句「剩余问题建议后续处理」优雅离场。给它一个必须守住的目标,能砍掉不少这种假完成。

可这里有个词必须掰开。

谁定义「完成」?

如果答案还是「让模型自己看着办」,那 /goal 只是把不确定性拉长了。测试变绿可能是代码修好了,也可能是 Agent 删掉了失败用例,放宽了断言,把 integration test 从 CI 配置里移走,或者给报错路径加了一句粗暴的 except

目标不能只有自然语言,还要有机器能判定的验收器。

「修复 flaky tests」至少要绑定固定测试集、允许修改的目录、不能下降的覆盖率、最长运行时间和最大重试次数。「处理 PR 反馈」要区分修复建议、解释性评论和必须交给真人的架构争议。「把 CI 变绿」更不能自动等价于「允许合并」。

Cloud Agent 能力文档强调它能在完整环境里构建、测试并产出演示材料,这很好。工程团队真正要做的,是把这些材料变成验收证据,而不是让 Agent 自己给自己的作业盖章。

我自己的判断是,长期目标最好拆成两个出口。

一个叫 completed,确定性检查全部通过,可以交给下一环。另一个叫 blocked,预算耗尽、权限不足、目标冲突或连续失败时,带着日志、diff 和最近一次尝试交还给人。

没有 blocked 的 Agent,只有两种结局,假装完成,或者一直烧钱。

独立虚拟机解决了文件冲突,没解决外部世界

Cursor 还让子智能体跑在各自的虚拟机里。每个 worker 拿到隔离的项目副本和干净上下文,可以并行测试父任务的更改,也可以同时找不同类型的 bug。

这个设计很实在。多个 Agent 共用一个 worktree 时,一个刚切分支,另一个正好在写文件,第三个顺手跑了格式化,到头来谁改了谁已经说不清。隔离虚拟机至少把文件系统、进程和上下文碰撞拆开了。Cloud Agents 总览也写得很清楚,每个 Agent 都有完整开发环境,可以构建、测试、操作浏览器和连接工具。

但隔离机器不等于隔离业务资源。

三个子智能体仍可能连到同一个测试数据库,抢同一条队列消息,反复创建同名云资源,撞同一个第三方 API 限额,或者同时给同一位 reviewer 发通知。代码目录干净了,外部副作用还挤在一条窄门里。

三个隔离的 Agent 工作区仍然争用同一组外部资源

虚拟机隔开了文件系统,数据库、云存储与外部 API 仍然共享。

所以并行 Agent 不能只给「各自一台机器」,还要给各自一份租约。测试数据库按任务建命名空间,云资源带 run id,写操作有额度,生产凭证默认不给,外部消息先走草稿。任务结束后,租约到期,临时权限和资源一起回收。

Secrets 与网络文档提供了 secret 管理、出站域名限制和私网连接等控制面。Builds 文档则把依赖准备成带版本的环境构建,坏构建不会替换上一个可用版本。平台给了护栏材料,团队仍得决定哪把钥匙能开哪扇门。

尤其是 MCP。Cursor 的自动化文档提醒,连接一个 MCP server 会让 Agent 获得那个 server 暴露的全部工具。一个看起来只用于查工单的连接器,如果同时暴露删除、审批或发消息能力,长期 Agent 就会把这份宽权限带进每次事件唤醒。

这块真得克制。

能只读就别给写,能按任务授权就别发长期 token,能先生成草稿就别让它直接提交。权限不是 Agent 能力的奖励,它是每次运行都要偿还的风险额度。

自动醒来之后,账单也会自动醒来

手动启动 Agent 时,人至少知道自己按下了按钮。事件驱动之后,很多运行发生在你没看屏幕的时候。

Cursor 的计费说明写明,Cloud Agents 按所选模型的 API 价格计费。自动化文档还补了一条,它们会使用模型支持的最大上下文窗口,没有单独的上下文开关。

这两句放在一起,挺有分量。

一个监听公共 Slack 频道的触发器,如果没有关键词或正则过滤,每条顶层消息都可能创建一次运行。一个订阅 PR 的 Agent,如果没把自己发出的评论排除掉,理论上还可能形成「我回应我自己」的回声。再加上持久记忆、MCP 查询和电脑操作,一次误触发不一定贵,几百次就很有存在感了。

厉害了,过去是人忘了关云服务器,现在轮到 Agent 忘了停止自己。

上线前至少要把四个数字钉死,单次最大 token、单次最长时间、同一事件最大重试次数、每天总预算。任何一个触顶,都进入 blocked,不再靠 prompt 里一句「请节约成本」维持秩序。

观察面也得跟上。每次运行要能回到触发事件、使用的提交、环境构建、工具调用、费用和最终证据。没有这些东西,Agent 半夜改坏一条流水线,第二天你看到的只会是一段非常礼貌的总结。

礼貌解决不了事故。

如果团队今天就想试这套能力,我会从「PR 牧羊犬」开始。

让 Agent 订阅自己创建的 PR。CI 失败时,它可以读取日志、提出修复、跑固定测试,再推一个新提交。bot 留下格式或静态检查评论,它可以处理。遇到架构意见、权限变更、数据库迁移或连续两次失败,立即 blocked,交给真人。

它可以一直追到证据齐全。

它不能自己决定合并。

这条边界看着保守,却刚好能测出事件订阅、长期目标、环境构建、幂等、预算和人工接管是不是都真能工作。跑稳以后,再把范围从一个仓库扩到更多触发器。别一上来就让 PagerDuty、生产凭证和自动合并在同一张配置页里胜利会师。

Cursor 这次发布,真正往前走的一步,是把 Agent 的时间拉长了。它不再只能活在一轮对话里,可以等,可以醒,可以继续,可以分工。

时间变长之后,工程责任也跟着变长。让它坚持到完成之前,先认真定义什么叫完成,什么时候必须停,以及停下时该把什么交还给人。

长期运行最珍贵的能力,从来不是永不放弃。

是知道何时交棒。