Cloudflare 发布 Worker Previews：每个 Git 分支自动获得隔离的生产级预览环境

Cloudflare 发布 Worker Previews，为 Agent 的每一次改动提供隔离的预览环境 传统测试链条有一个长期痛点：代码在 staging 验证通过，上线后行为却不同；因为 staging 和生产在资源配置、数据状态、流量形态上永远无法完全一致。而 AI Agent 的兴起放大了这个问题：Agent 产出代码的速度和体量远超人类开发者，需要生产级的验证保真度，但又不能为此拖慢迭代，更不能让多个变更在共享 staging 环境里互相干扰。 Worker Previews 的解法：每个 Git 分支自动获得一个生产级环境，拥有独立的代码、配置、URL、可观测性和状态，但都挂在同一个 Worker 之下。 blog.cloudflare.com/worker-preview… 技术架构上最关键的设计：状态隔离 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 的完整验证闭环 1. 部署：npx wrangler preview 或 push 自动触发 2. 打开：通过 Browser Run / Playwright MCP 在无头浏览器中访问 Preview URL，点击走完登录等流程，截图或录制可回放的 DOM 事件 3. 诊断：通过 Workers Observability MCP server 查询该 Preview 作用域内的 traces、errors、metrics、请求瀑布图 4. 修复验证：patch → redeploy → 再验证，全程限定在分支内 失败可以从两个角度交叉定位：浏览器里渲染出了什么 + 运行时实际发生了什么。人类监督通过 Live View（实时观看 Agent 的浏览器会话）和 Human in the Loop（自动化需要判断时人工介入）实现。 几个值得注意的工程细节 · 自定义域名：Preview 可以跑在自己的域名上（如 feature-login.previews.example.com ），这意味着 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 @Cloudflare Today we’re launching Worker Previews. Each Git branch gets a production-like place to run, with its own code, configuration, URL, observability, and state. cfl.re/4hgSuxf 🔗 View Quoted Tweet 💬 1 🔄 0 ❤️ 4 👀 400 📊 2 ⚡