推出 Worker Previews：为代理的每次改动提供独立的预览环境
最糟糕的莫过于：某个改动在预发布环境（staging）测试通过，到了生产环境却表现不一样。所以我们希望给你一个尽可能接近生产的环境——让你充分检验改动，确保它们的行为完全符合预期。智能体帮我们提交了前所未有的代码量，而改动越大，发布前需要覆盖的测试范围就越广。理想情况下，这些测试不应该拖慢智能体的速度，反而要给它们工具，让它们承担更多开发流程中的工作。因此，今天我们推出 Worker Previews。每个 Git 分支都有一个类似生产环境的运行空间，拥有自己的代码、配置、URL、可观测性和状态。这样一来，代码库中的每一个改动，你都可以：
- 用
npx wrangler preview部署一个隔离的预览环境，使用独立的变量、密钥和绑定，与生产配置和流量完全隔开。 - 为分支分享一个稳定的预览 URL，每次推送都会更新同一个正在运行的预览，你可以在上面发送请求、点击操作界面、测试运行时响应。
- 按分支隔离 Durable Objects 和 Containers，把状态变更、会话、内存、迁移和并发测试都限定在该预览范围内。
- 查看该预览的日志、错误、指标和链路追踪，确认改动是否正常，发现问题就推送修复，在生产环境感知之前完成验证。
- 从你设定的预览配置出发，每个预览都从你定义的变量、密钥、绑定和设置的一份副本开始——就像代码分支从 main 分支开始一样。我们把它叫做基础配置（base configuration）。
- 需要时覆盖预览的配置，比如让迁移指向自己的数据库或测试 API 密钥——不影响生产、基础配置或其他预览的配置。
- 用自定义域名提供预览 URL，让认证服务商、Cookie、跨域资源共享（CORS）和 OAuth 重定向的行为与生产环境一致。
最终效果是：每个分支都有了预发布反馈闭环。把改动推送到分支，测试行为，检查性能——一切都在合并到生产之前完成。
这样一来，就形成了一套「智能体开发生命周期」（Agent Development Lifecycle，简称 ADLC）：每次改动都是原子的、可独立部署、可观测、可修订。它还给智能体和人类提供了自我改进所需的依据——发现哪里出错、推送修复、在上线前验证下一次部署。
每个 Git 分支都有自己的环境
开发新功能时，第一件事就是从 main 分支切出来。你拿到自己那份代码副本，随便改都不会影响生产环境。
Worker Previews 把这套模式从代码延伸到了环境本身。每个分支都有独立的隔离环境和 URL。你可以同时运行几百个 Preview，彼此互不干扰，也不会影响生产。
生产环境和每个 Preview 各有一套配置，各自跑在自己的 URL 上。执行 npx wrangler preview 时，分支会拿到你定义的那份 Preview 配置副本，运行在独立的 URL 上——全都归属于同一个 Worker。
在控制面板里，这就像切换分支一样。点击 Worker 名字旁边的面包屑（默认显示 Production），就能看到所有 Preview：
控制面板把所有环境汇聚到一个界面。生产环境和你需要的任意数量的 Preview 并列排布，贡献者可以各自推进不同的改动，不用再抢一个共享的预发布站点。
Wrangler environments 要求每个环境单独部署和管理一个 Worker，Previews 则不同：它在同一个控制面板视图里就实现了隔离。
每个 Preview 都运行 Worker 的真实版本
有些改动只能在运行时验证：比如一个 API 接口，必须处理真实请求并返回正确响应。而更偏主观的改动——比如 UI 更新、新增的引导步骤、不同的错误状态——需要先在实际场景里体验过，才能上线。
每个 Preview 都有独立的持久化状态，借助 Durable Objects 和 Containers
要让隔离覆盖整个应用，有状态资源需要特殊处理。原因在于 Durable Objects 采用单例模型：某个对象 ID 只由一个实例负责，存储也归这个实例所有。
如果 Preview 和生产环境共用同一个 Durable Object 命名空间，那你读到的不只是过期数据——你还可能实时改到正在处理线上流量的同一个实例（想想就可怕！）。所以每次运行 npx wrangler preview，Cloudflare 都会自动为该 Preview 创建新的 Durable Object 命名空间和 Container 应用，这样迁移失败或 schema 改错只会局限在那个分支，不会波及其他分支。你只需要导出类、加上迁移、再通过 ctx.exports 访问就行：生产环境里 ctx.exports.Counter 指向生产命名空间，Preview 里则指向该 Preview 自己的命名空间。现在你有了一整块试验田，可以随便折腾。以 Sandboxes 为例，启动时间上几毫秒的提升就可能决定体验好坏。如果你一直在优化冷启动性能，可以同时在多个分支上跑不同配置，把冷启动和热启动的表现放一起对比，更快找到最优方案。
测试、观察、修改每个 Preview（也可以交给你的 agent 来做）
现在每个分支都有自己的 URL，运行在隔离环境、拥有独立状态，你可以进入反馈循环，把每个改动在进入生产前反复实战检验。往 Preview URL 发流量的方式随你——从终端发、在 CI 里探测、让 agent 来、或者自己点着走一遍。流量一旦跑起来，你熟悉的那套 Workers Observability 工具全都能用，而且按各个 Preview 单独划分。每个请求打到 Preview 时，Workers Observability 会用瀑布图追踪它的完整生命周期，包括 fetch 调用、绑定操作、handler 执行。出问题时，你能直接看清发生了什么，不用在生产流量或其他改动的信号里翻找。Preview 的可观测性，和你已经在生产 Workers 上用的那套长得一模一样。
从面包屑导航里选中某个 Preview，打开 Observability 标签页，就能看到它的事件、错误和调用链：
想让 Agent 掌控更多，可以让它在无头浏览器里打开 Preview 的 URL，一步步走完登录流程，然后截图，或者把整个过程录成可回放的 DOM 事件——这要借助 Browser Run。下面的例子中，Agent 打开 Preview、截取渲染结果，并把一次失败的请求关联到该次运行中 Workers Observability 记录的事件。审核者可以用 Live View 实时观看整个过程，或者在自动化需要人来判断时通过 Human in the Loop 介入。
一旦出问题，你能从两个角度看到它：页面渲染成什么样，以及运行时发生了什么。这些证据足够让 Agent 把预生产流程自动跑下去：部署、用 Playwright MCP 打开 URL、逐步点击、通过 Workers Observability MCP server 查询调用链、打补丁、重新部署、再验证。每一轮迭代都限定在这个分支内。
为 Preview 配置一次基础设置，之后按需覆盖
就像你不会每次新建分支都把代码从头写一遍，环境配置也不该重来。
你只需要在 Wrangler 配置文件的 previews 块里，为 Preview 设置一次基础配置。在控制面板的 Worker → Settings 下，这份配置会以内联形式显示为 Production 和 Previews Base。
基础配置设好之后，在任意分支运行 npx wrangler preview 就能创建一个 Preview。如果你的 Worker 通过 Workers Builds 与 Git 打通，那推送代码时会自动创建。
你可以只针对某一个 Preview 覆盖任意设置——不会影响生产环境、基础配置或其他 Preview。
用自有自定义域名提供 Preview URL，并通过 Cloudflare Access 保护
想让整套设置更贴近生产环境，Preview 的 URL 可以直接用你自己的自定义域名。比如你的应用跑在 example.com 上，一个登录功能分支的 Preview 可以跑在 feature-login.previews.example.com。
如果你希望这些 URL 保持私密，可以用 Cloudflare Access 保护 Preview，要求访问者先登录。
在生产环境之前测试整个系统
在 Cloudflare 内部，我们已经开始自用 Worker Previews，最典型的场景就是开发和测试 CloudflareOS——这是我们开源的一个平台，用来让智能体（agent）安全地连接企业内部系统。CloudflareOS 让智能体可以通过 Gatekeepers 使用 Google、GitHub、Slack 等服务，由 Gatekeepers 控制智能体能访问和修改哪些内容。这样一来，Gatekeeper 的任何改动都格外敏感：一个 bug 就可能泄露数据，或者放行本不该被允许的操作。
有些 bug 只有在 OAuth 回调、权限、审批流程和应用状态同时运行时才会冒出来。单独测试每个组件，看不出整个系统会怎么表现。所以每一条待审核的改动，我们都会部署一套隔离的 CloudflareOS 及其 Gatekeepers 预览环境，把整个工作流跑一遍，修掉出问题的地方，再测一次，然后才合并。
我们看到客户使用 Previews 的理由也差不多：有些问题只有等改动真正跑起来才会暴露。
“在 Supermemory，我们大量使用 Cloudflare，Worker Previews 正是我们期待的那种开发体验改进。对于 HTTP 流程，我们可以在改动进入生产环境之前先预览 Worker 的变化，包括由 Durable Objects 支撑的路由，从而更早发现问题，又不拖慢发布节奏。”——Dhravya Shah，Supermemory 创始人
“Previews 对 Inspect（Ramp 的编码智能体）来说非常好用。我用它在手机上审查并测试了一个 Inspect 的 PR，那个 PR 让在手机上用 Inspect 审查和测试 PR 变得响应式……当然，靠的还是 Inspect。”——Dylan Garcia，Ramp 高级主任工程师