Cloudflare 推出了 Worker Previews。借助这项功能，每个 Git 分支都可以拥有独立且类似生产环境的 Worker 运行环境。每个环境都有稳定的 URL，以及各自的配置和分支专属状态，同时还提供限定在当前预览环境内的可观测性。开发者可以使用 npx wrangler preview 创建预览，同一个 Worker 下可同时运行数百个预览，彼此互不影响，也不会触及生产流量。

这项功能的推出源于智能体驱动开发的需求。编码智能体能够以更高频率生成规模更大的变更，测试工作也必须跟上，同时不能成为瓶颈。Cloudflare 将 Previews 视为其“智能体开发生命周期”中的反馈闭环。在这一过程中，每项变更都是原子的，可以独立部署、接受观测并进行修改。

其中最主要的技术难题是状态。Durable Objects 采用单例模型，由一个实例拥有给定对象 ID 的存储，因此，如果预览环境与生产环境共享命名空间，就可能修改线上实例。Wrangler 会为每个预览创建新的 Durable Object 命名空间和 Container 应用，从而将失败的迁移和架构变更限制在相应分支内。开发者导出类、添加迁移，并通过 ctx.exports 访问它。在生产环境中，它会解析到生产命名空间；在预览环境中，则会解析到该预览自己的命名空间。

配置方式类似于从 main 分支创建新分支。团队可以在 Wrangler 文件的 previews 配置块中设置基础配置，其中包括变量、密钥和绑定。例如，可以让某个 R2 存储桶指向暂存存储，而不是生产存储。每个预览都以这套基础配置为起点，也可以单独修改某些设置，例如为一次迁移指定特定数据库或测试 API 密钥，而不会影响生产环境、基础配置或其他预览。通过 Workers Builds 连接的 Worker 会在代码推送时自动获得预览，此后每次向同一分支推送代码，都会更新同一个正在运行的预览。

Workers Observability 的范围限定在每个预览环境内，因此开发者无需从生产流量中筛选，就能查看日志、错误、指标和请求追踪。Cloudflare 还描述了一套结合 Browser Run、Playwright MCP 和 Workers Observability MCP 服务器的智能体循环。智能体首先在无头浏览器中打开预览，然后操作登录等流程，捕获屏幕截图或可重放的会话，接着将失败的请求与追踪事件进行匹配，最后修改代码、重新部署并完成验证。预览可以通过 feature-login.previews.example.com 这样的自定义域名提供服务，使 Cookie、CORS 和 OAuth 重定向的行为与生产环境一致，并且可以通过 Cloudflare Access 设置访问限制。

Cloudflare 表示，它已在内部使用 Previews 构建 CloudflareOS。这是一个开源平台，可通过 Gatekeepers 将智能体连接到 Google、GitHub 和 Slack 等服务，并为每项正在审查的变更部署完整的预览环境。文章还引用了 Supermemory 和 Ramp 这两家早期用户的评价，但没有提供基准测试或量化结果。

Previews 不同于 Wrangler environments，后者需要为每个环境分别部署和管理一个 Worker；它也不同于现有的 Worker 预览 URL，后者现已更名为 Version URLs。Version URLs 指向已上传的 Worker 版本，不会按分支进行隔离，并且只能访问生产资源。Worker Previews 在结束私有测试后现已正式开放使用。

工程师需要注意这项功能目前存在的若干限制。预览环境中的服务绑定仍会调用被绑定 Worker 的生产部署，因此，多 Worker 应用尚未实现完全隔离。预览可以向 Queues 发送消息，但无法消费消息；如果需要隔离 Workflow 执行，还必须进行额外配置。目前也尚未端到端支持用于暂存和质量保证的长期预览环境，不过 Cloudflare 表示，参与测试的团队提出了这一需求，并且该功能已列入路线图。团队还应检查现有系统是否依赖 Version URLs，因为这些 URL 仍然指向生产绑定。

原文链接：https://www.infoq.com/news/2026/09/cloudflare-worker-agent/