Cloudflare Workers AI 与 Cursor Cloud Agents 对比：2026 年 5 月更新后的两处关键差距

在 Cloudflare Workers AI 与 Cursor Cloud Agents 的对比中，Cursor 刚补上了一块重要拼图。5 月 13 日，Cursor 发布了支持多仓库的云端智能体环境。Cursor 自己的产品页面显示，如今它合并的 Pull Request 中，超过 30% 由运行在云端沙箱中的自主智能体创建。

Cursor 在 5 月 13 日究竟发布了什么：Cloudflare Workers AI 对比的起点

此次更新的主角是多仓库云端智能体环境。在 4 月 24 日推出多根工作区后，Cursor 现在允许智能体在同一个已配置环境里跨多个仓库工作。环境还能跨会话复用，这才是真正实用的地方——每次智能体启动时，不必再重新配一遍相同的开发环境。

配置入口就是 Dockerfile。构建密钥只在构建阶段有效，不会传给正在运行的智能体。这堵住了智能体基础设施里最常见的安全漏洞：构建时意外写入的 API key，最后进入智能体的工作记忆。Cursor 还可以检查仓库中的工具和依赖，自动配置 Dockerfile。这套流程仍面向 Enterprise 团队进行私有测试。

分层缓存带来的性能提升最大。缓存命中时，只会重建有变化的 Dockerfile 层，因此构建速度现在提升了 70%。对一支需要反复启动智能体的团队来说，这决定了时间是花在等待上，还是真正用来工作。

真正被竞品反复低估的，是运维和治理能力。每个环境都有版本历史，并且可以回滚；回滚权限仅开放给管理员。审计日志会记录团队成员对环境执行的每一项操作。出站允许列表和密钥作用域均按环境隔离，所以环境 A 能用的密钥，环境 B 无法访问。这些基础设施听起来并不新奇，却是放手让智能体向生产代码提交 PR 之前必须具备的底座。

Cursor 在公告中给出的实证来自 Amplitude。他们的 Cursor Automations 会监控公开 Slack 频道，调查已上报的问题，找出受影响的仓库，再在正确的仓库中提交 PR。这是多仓库智能体在真实企业和真实规模下承担第一轮问题排查，不是一场演示。

Cursor 自己的已合并 PR 数据，才是最有力的证明

Cursor 表示，它合并的 Pull Request 中，超过 30% 由运行在云端沙箱中的自主智能体创建。这里的分母很重要：统计的是已合并的 Pull Request，而不是智能体尝试了多少次任务。这项数据说明，整个闭环可以走过审查、修改和交付，无须人工推送每一次提交。

自 2026 年 9 月 2 日起，Cursor 的 Self-Hosted Machines 允许团队将文件编辑、终端命令、computer-use 工具以及本地 MCP 执行移到客户自管的 worker 上，而智能体循环、推理和规划仍由 Cursor 云端承担。这补上了私有执行位置的缺口，但并没有让 Cursor 变成可编程的持久化运行时。

如今的选择已经不是“会话级”还是“持久化”。Cursor 会在后端持久化保存对话状态，因此可以重新打开并恢复一次运行；Self-Hosted Team Pools 也能恢复休眠中的工作区。更准确的分界是：厂商管理的智能体状态，与可编程的应用状态。Cloudflare 把每个 Agent 的 SQLite 状态和持久化工作流步骤都暴露给代码，由开发者自行控制。

我的 Cloudflare Workers 与 Cloudflare Agents SDK 技术栈已经能做到什么

我在 Cloudflare 上运行着 6 个生产智能体。运行时是 Workers；状态保存在为每个实例配备 SQLite 的 Durable Objects中；长时间运行的编排交给 Cloudflare Workflows。这套系统由我一人搭建，只用一个账户，详细拆解在这里。整套 Cloudflare 技术栈在 2026 年 4 月的费用是 $19.14。这是有明确日期的生产账单，不是平台报价。Cursor 将 Enterprise 价格标为 Custom；Team Pools 要求 Enterprise，而使用 Self-Hosted Machines 仍需支付所选模型费用和自己的 worker 账单。

与 Cursor 当前产品相比，这套技术栈有 3 处不同。

多仓库能力，由代码实现。 Worker 可以在运行时通过 HTTP 获取资源。如果所需上下文藏在网站后面，前身为 Browser Rendering 的 Browser Run 可以操作无头浏览器。Cursor 将多仓库访问封装成可复用的环境配置；Cloudflare 则把资源获取、身份验证和仓库逻辑留给开发者。谈不上谁优谁劣，只是控制界面不同。

可编程的持久状态。 Cloudflare Agent 会自动将应用状态保存到自己的 SQLite 数据库，并在重启或休眠后重新加载。Cursor 也会保留对话状态，并支持恢复运行。差异在于控制权：Cursor 控制对话存储和智能体运行时，Cloudflare 则将应用状态及其 schema 交给代码。

持久化的步骤边界，不等于自动保证恰好执行一次。 在 Workflows 中，每个步骤都可单独重试，也可以输出状态，让执行在网络或基础设施故障后继续。step.do 支持按步骤设置重试策略，NonRetryableError 可在遇到终止性故障时停止重试，而每个 Workflow 的实例 ID 都是唯一的。但同一个步骤可能不止执行一次，Cloudflare 也明确要求对会产生副作用的调用做幂等设计。它的优势是由开发者定义持久化边界和重试控制，而不是自动防止重复提交 Pull Request、重复发送邮件或重复扣费。

Cursor 至今仍未补上的两处差距

差距 1：由客户控制的可编程智能体状态。 Cursor 已经解决了基础恢复能力：默认无限期保留对话状态，托管 VM 快照则按滚动的 90 天不活跃窗口保留。Self-Hosted Machines 改变了工具的执行位置，但智能体循环仍由 Cursor 运行，对话也仍由 Cursor 存储。Cloudflare Agent 则在应用运行时内暴露以 SQLite 为后端的状态。当智能体需要监控事故、协调迁移，或在持续数日的客户导入流程中携带业务状态时，这一点尤为重要。

相比 5 月时的判断，这个差距的范围已经缩小。Cursor 可以恢复自家产品中的智能体运行，但它没有提供客户所有的状态机，让应用在 Cursor 对话之外独立查询、扩展和协调。

差距 2：由开发者定义的持久化步骤界面。 Cursor 当前的 Cloud Agent 和 Self-Hosted Machine 文档中，没有与 Workflow 步骤对等的应用层原语，也就是带持久化状态和分步重试配置的能力。Cloudflare 提供了这个能力。当编程智能体开始触及计费、邮件、部署或其他外部副作用时，这种差异就会变得关键。

把工具调用移到自己的机器上，也无法补齐这一差距，因为它改变的是执行位置，而不是编排契约。Cloudflare 同样不会让副作用自动实现恰好一次；会重试的步骤仍需由开发者保证幂等性。

这些并不是在否定 Cursor，而是要说清它们所处的产品类别。Cursor 是一款编程产品，同时提供托管和客户自运行的工具执行方式；Cloudflare 是可编程的应用运行时。9 月的发布缩小了基础设施差距，但状态与编排的边界依然把两者分开。

创业者和 CTO 这周应该怎么做

3 类团队，对应 3 种选择。

如果是正在交付产品功能的小型产品团队，只要 Cursor 的环境和网络控制能复现你们的构建，就可以使用 Cursor 托管的 Cloud Agents。5 月 13 日的环境更新已经覆盖多仓库配置、构建密钥、缓存和审计；Cursor 披露的“已合并 PR 中超过 30%”则是公开可见的事实依据。如果没有明确的策略理由，不要自己运维一整套 worker 集群。

如果已经在 Cloudflare 或 Vercel 上运行长期后台进程，继续将持久化应用状态和编排留在原平台。Cursor Self-Hosted Machines 现在可以利用 Cloudflare 或 Vercel 基础设施执行工具，但智能体循环仍归 Cursor 控制。这里还有一个值得阅读的消费端对照，它讲述了 Anthropic 如何为中小企业封装类似的原语——各类平台向智能体靠拢的趋势，正在各处出现。

如果正在规划企业级推广，当允许列表、Tailscale、AWS PrivateLink 或 Cloudflare Tunnel 能满足访问要求时，优先从托管型 Cloud Agents 开始。如果代码检出、工具执行、定制硬件或 worker 镜像必须保持在自己的控制下，则使用 Team Pools。Team Pools 需要 Enterprise，价格为 Custom；Cursor 自动配置 Dockerfile 的功能仍处于私有测试。

5 月之后，哪些情况变了

有 2 个信号值得注意。

第一，Cursor 现在会把对话状态与运行时工作区分开说明。默认无限期保留对话状态，因此可以重新打开并恢复运行；托管 VM 快照在不活跃 90 天后到期，除非通过启动或恢复来延长该窗口。基础恢复能力已不再是缺口，所有权和可编程性才是。

第二，私有执行位置也已不再是缺口。Self-Hosted Machines 解决了这一问题，同时仍将智能体循环、推理和规划留在 Cursor 云端。由客户控制的智能体状态，以及由开发者定义的持久化步骤界面，才是仍然存在的两项实质差异。

Cursor 5 月 13 日的发布是否意味着不再需要自托管智能体基础设施？

不是。Cursor 现在已提供自己的自托管路径：个人工作流使用 My Machines，Enterprise 集群使用 Team Pools。工具执行因此能够进入企业自己的网络，但智能体循环仍由 Cursor 运行，对话状态也仍由 Cursor 存储。需要可编程应用运行时或持久化工作流步骤的团队，仍然需要为这些层级配备基础设施。

Cursor 云端智能体的缓存构建现在有多快？

5 月 13 日完成分层缓存升级后，缓存命中时的构建速度提升了 70%。在缓存命中的情况下，只会重建已变更的 Dockerfile 层。

Cursor 内部的已合并 PR 数据意味着什么？

Cursor 当前的官方页面表示，它合并的 Pull Request 中，超过 30% 由运行在云端沙箱中的自主智能体创建。这是一项有参考价值的生产环境采用指标，因为它统计的是已合并的 Pull Request，而不是尝试过的任务。

Cursor 云端智能体用于会接触生产密钥的代码时安全吗？

5 月 13 日的发布会按环境限定出站访问和密钥作用域，将构建密钥与运行中的智能体隔离，并提供版本历史、回滚和审计日志。Self-Hosted Machines 能将完整的代码检出和机器本地凭据留在自己的 worker 上，但任务所需的文件内容、工具输出、diff、截图和本地 MCP 结果仍可能传给 Cursor。是否安全，取决于是否对这两道边界都做了充分审核。

Cloudflare Workers 和 Cursor 云端智能体可以同时使用吗？

可以。Cursor 将 Cloudflare 列为 Self-Hosted Machines 的集成方案，其参考模板使用 Cloudflare Worker 作为控制器，每接收一个已认领的请求，就启动一个 Cloudflare Container。Cursor 可以处理编程智能体循环，Workers、Durable Objects 和 Workflows 则负责持久化应用状态与编排。两款产品现在在工具执行层面存在重叠，但并未在智能体循环的边界上重合。