Cloudflare 发布 Worker Previews，为 Agent 的每次改动提供隔离预览环境

传统测试链条有一个长期痛点：代码在 staging 验证通过，上线后行为却不同，因为 staging 和生产在资源配置、数据状态、流量形态上永远无法完全一致。AI Agent 的兴起放大了这个问题——Agent 产出代码的速度和体量远超人类开发者，需要生产级的验证保真度，但又不能为此拖慢迭代，更不能让多个变更在共享 staging 环境里互相干扰。

Cloudflare 给出的解法是 Worker Previews：每个 Git 分支自动获得一个生产级环境，拥有独立的代码、配置、URL、可观测性和状态，但都挂在同一个 Worker 之下。这一设计的目标不是替代 staging，而是把“保真度”和“隔离性”同时收进分支粒度。

Cloudflare Workers 的难点在于有状态绑定。Durable Objects 采用单例模型，一个对象 ID 对应唯一实例并独占其存储；如果 Preview 和生产共享同一个 DO 命名空间，预览分支里的代码——比如一次失败的数据库迁移、一个错误的 schema 变更——会直接修改生产实例的数据。

因此，每次运行 npx wrangler preview（或 Git 连接的 Workers Builds 在 push 时自动触发），Cloudflare 会为该 Preview 自动创建全新的 DO 命名空间和 Container 应用，让破坏性变更被严格限制在分支内。

代码层面是零侵入的：代码里照常写 ctx.exports.Counter.idFromName("demo")，运行时自动解析，在生产中指向生产命名空间，在 Preview 中指向该 Preview 的命名空间。

围绕 Agent 的完整验证闭环被拆成四步：部署（npx wrangler preview 或 push 自动触发）、打开（通过 Browser Run / Playwright MCP 在无头浏览器中访问 Preview URL，点击走完登录等流程，截图或录制可回放的 DOM 事件）、诊断（通过 Workers Observability MCP server 查询该 Preview 作用域内的 traces、errors、metrics、请求瀑布图）、修复验证（patch → redeploy → 再验证，全程限定在分支内）。

失败可以从两个角度交叉定位：浏览器里渲染出了什么，加上运行时实际发生了什么。人类监督通过 Live View（实时观看 Agent 的浏览器会话）和 Human in the Loop（自动化需要判断时人工介入）实现。

自定义域名是保真度的具体落地：Preview 可以跑在自己的域名上，这意味着 OAuth 回调、CORS、Cookie 的行为与生产完全一致，还可以套 Cloudflare Access 做访问控制。

命名上有一处澄清：原来的 "preview URLs" 更名为 Version URLs，它们只指向特定上传版本，不创建隔离环境，且只能访问生产资源——这是为新产品让出命名空间。

与 Wrangler environments 的区别在于：Wrangler environments 本质上是多个独立 Worker，需要分别部署和管理；Previews 把所有隔离性收进同一个 dashboard 视图。

发布时存在几项明确限制：Service bindings 从 Preview 调用目标 Worker 时，仍指向其生产部署，即跨 Worker 调用链尚未隔离；Preview 可以向 Queues 发送消息但不能消费；Workflows 的隔离需要单独配置；暂无长期存活的 staging/QA 环境支持。

这些限制意味着隔离并非全局成立。对于拆了微服务的团队，只要调用下游，仍可能直接打到生产——这是发布时点上的已知缺口，而非可忽略的细节。

需要说明的是，以上信息来自一篇转述 Cloudflare 发布的 X 帖文，其中技术细节与限制描述均属来源方陈述，尚未见第一方原文逐条核对。