Agent写代码的速度，已经快过人类验证代码的速度。一个下午能产出几十个改动，但staging环境只有一个。多个变更挤在同一个共享环境里，互相覆盖、互相干扰，最后谁也说不清是哪个改动出了问题。

Cloudflare发布的Worker Previews，试图回答一个问题：能不能让每个Git分支都拿到一个生产级环境，彼此隔离，又不拖慢迭代？

旧测试链条的裂缝在哪

传统做法是staging加生产两套环境。问题在于，staging在资源配置、数据状态、流量形态上，永远无法和生产完全一致。测试通过不等于上线没事，这个落差一直存在。

Agent的出现把这道裂缝放大了。产出代码的速度和体量远超人类开发者，需要生产级的验证保真度，但又不能因此拖慢迭代节奏。共享staging在这种压力下彻底不够用——多个变更同时验证，互相污染。

Worker Previews的解法是：每个Git分支自动获得一个生产级环境，拥有独立的代码、配置、URL、可观测性和状态，但都挂在同一个Worker之下。

状态隔离才是技术关键

环境隔离听起来简单，难的是状态。Durable Objects采用单例模型，如果Preview和生产共享同一个DO命名空间，预览分支里的代码——比如一次失败的数据库迁移、一个错误的schema变更——会直接修改生产实例的数据。

所以每次运行npx wrangler preview，系统都会自动创建全新的DO命名空间和Container应用。代码层面零侵入，运行时自动解析命名空间。这一步是整个架构里最关键的设计，也是Preview能被称为"生产级"的前提。

面向Agent的验证闭环分四步走：

  1. 部署到独立的Preview环境
  2. 用Browser Run或Playwright MCP打开页面，走完整个流程
  3. 用Workers Observability MCP查询该Preview作用域内的traces与errors
  4. patch之后重新验证

失败可以从两个角度交叉定位：浏览器里渲染出了什么，加上运行时实际发生了什么。人类监督则通过Live View和Human in the Loop实现。

发布时仍有限制

这套方案并非没有边界。Service bindings从Preview调用目标Worker时，仍然指向生产部署，跨Worker的调用链尚未隔离。Preview可以向Queues发送消息，但不能消费。Workflows的隔离需要单独配置。目前也还没有长期存活的staging或QA环境支持。

工程细节上，自定义域名保证了OAuth、CORS、Cookie行为的一致性，preview URLs更名为Version URLs，与Wrangler environments存在区别。

对Agent驱动的开发流程来说，这套机制的价值在于把"验证"变成了每次改动都能自动走一遍的标准动作。隔离的不只是代码，还有状态、可观测性和失败的影响范围。