为什么同一个Worker下能同时跑几百个预览环境，彼此互不影响，也不会碰到生产流量？Cloudflare给出的答案是Worker Previews——每个Git分支都能拥有独立、类似生产环境的运行空间。
这项功能已经结束私有测试，正式开放使用。开发者可以用 npx wrangler preview 创建预览，每个环境都有稳定的URL、各自的配置和分支专属状态，可观测性也限定在当前预览环境内。
智能体写代码，测试不能拖后腿
Cloudflare把Previews的推出归因于智能体驱动开发的需求。编码智能体能够以更高频率生成规模更大的变更，测试工作也必须跟上，同时不能成为瓶颈。
在Cloudflare的设想里，Previews是"智能体开发生命周期"中的反馈闭环：每项变更都是原子的，可以独立部署、接受观测并进行修改。
这套循环结合了Browser Run、Playwright MCP和Workers Observability MCP服务器。智能体先在无头浏览器中打开预览，操作登录等流程，捕获屏幕截图或可重放的会话，再把失败的请求与追踪事件进行匹配，最后修改代码、重新部署并完成验证。
最难的一关是状态
Durable Objects采用单例模型，由一个实例拥有给定对象ID的存储。如果预览环境与生产环境共享命名空间，就可能修改线上实例。
Wrangler的做法是为每个预览创建新的Durable Object命名空间和Container应用，从而把失败的迁移和架构变更限制在相应分支内。开发者导出类、添加迁移，并通过 ctx.exports 访问它——在生产环境中解析到生产命名空间，在预览环境中解析到该预览自己的命名空间。
配置方式类似于从main分支创建新分支。团队可以在Wrangler文件的previews配置块中设置基础配置，包括变量、密钥和绑定。比如让某个R2存储桶指向暂存存储，而不是生产存储。每个预览都以这套基础配置为起点，也可以单独修改某些设置，例如为一次迁移指定特定数据库或测试API密钥，而不会影响生产环境、基础配置或其他预览。
通过Workers Builds连接的Worker会在代码推送时自动获得预览，此后每次向同一分支推送代码，都会更新同一个正在运行的预览。
它和旧方案有什么不同
Previews不同于Wrangler environments，后者需要为每个环境分别部署和管理一个Worker。它也不同于现有的Worker预览URL——后者现已更名为Version URLs。Version URLs指向已上传的Worker版本，不会按分支进行隔离，并且只能访问生产资源。
预览可以通过类似 feature-login.previews.example.com 的自定义域名提供服务，使Cookie、CORS和OAuth重定向的行为与生产环境一致，并且可以通过Cloudflare Access设置访问限制。
Cloudflare表示，它已在内部使用Previews构建CloudflareOS。这是一个开源平台，可通过Gatekeepers将智能体连接到Google、GitHub和Slack等服务，并为每项正在审查的变更部署完整的预览环境。文章还引用了Supermemory和Ramp这两家早期用户的评价，但没有提供基准测试或量化结果。
工程师需要注意的限制
预览环境中的服务绑定仍会调用被绑定Worker的生产部署，因此多Worker应用尚未实现完全隔离。预览可以向Queues发送消息，但无法消费消息；如果需要隔离Workflow执行，还必须进行额外配置。
目前也尚未端到端支持用于暂存和质量保证的长期预览环境。Cloudflare表示，参与测试的团队提出了这一需求，该功能已列入路线图。
团队还应检查现有系统是否依赖Version URLs，因为这些URL仍然指向生产绑定。
热门跟贴