8.0
热点
AI SCORE
编程提效2026-09-22 21:00
Cloudflare Worker Previews：为 Agent 每次变更提供隔离预览环境
Cloudflare Blog#Cloudflare Workers#开发者工具#DevOps
Editor brief · 编辑速览
Cloudflare Workers 新增 Previews 功能，每个分支获得独立 URL、配置、状态和可观测性，支持并行测试而无需影响生产环境，Agent 修改后可立即验证效果。
没有什么比在预发布环境测试好好的改动，一到生产环境就表现异常更让人沮丧的了。正因如此，我们希望为你提供一个尽可能接近生产环境的环境——让你能够对改动进行实战检验，确保它们的表现完全符合预期。
Agent 正在帮助我们产出比以前更多的代码，而更大的改动意味着发布前需要测试的范围更广。理想情况下，这种测试不会拖慢 Agent 的速度，同时赋予它们承担更多开发生命周期工作的能力。
所以今天我们正式发布 Worker Previews。每个 Git 分支都会获得一个类生产环境的运行空间，拥有自己的代码、配置、URL、可观测性和状态。
因此，对于代码库中的每一次改动，你都可以：
使用 npx wrangler preview 部署一个隔离的 Preview，拥有自己的变量、密钥和绑定，与生产环境配置和流量完全分开。
为该分支分享一个稳定的 Preview URL，每次推送都会更新同一个运行中的 Preview，你可以在其中发送请求、点击遍历 UI、测试运行时响应。
为该分支隔离 Durable Objects 和 Containers，保持状态变更、会话、内存、迁移和并发测试都在该 Preview 范围内。
检查该 Preview 的日志、错误、指标和调用链，确认改动生效、捕获失败、推送修复，并在生产环境看到之前完成验证。
从 Preview 配置开始，这样每个 Preview 都会以你定义的变量、密钥、绑定和设置的副本作为起点——就像代码分支从 main 分支衍生一样。我们称之为基础配置。
在需要时覆盖某个 Preview 的配置，比如指向它自己的数据库或测试 API 密钥用于迁移——而不影响生产环境、基础配置或其他 Preview 的配置。
在自定义域名上提供 Preview URL，使身份提供商、Cookie、跨域资源共享（CORS）和 OAuth 跳转与生产环境中的行为一致。
最终结果是为每个分支提供一套发布前的反馈循环。将改动推送到分支、测试行为、检查性能——然后再合并到生产环境。
这实现了 Agent 开发生命周期（ADLC），其中每次改动都是原子的、可独立部署的、可观测的、可修订的。这为 Agent 和人类提供了自我改进所需的证据：捕获失败的内容、推送修复、在下一次部署到达生产环境之前完成验证。
当你开始一个新功能的开发时，第一件事就是从 main 分支分叉。你获得自己的一份代码副本，在不影响生产环境任何内容的情况下进行修改。
Worker Previews 将这种模式延伸到代码之外。每个分支都有自己隔离的环境和 URL。你可以同时运行数百个 Preview——每个都独立运作，互不影响，也不会影响其他 Preview 或生产环境。
生产环境和各个 Preview 各自拥有自己的配置——通过各自的 URL 提供服务。
当你运行 npx wrangler preview 时，分支会获得你已定义的 Preview 配置的副本，运行在自己的 URL 下——全部在同一个 Worker 之下。
在 Dashboard 中，这就像切换分支一样。点击 Worker 名称旁边的面包屑（默认为 Production），即可查看所有 Preview：
Dashboard 将所有环境汇聚到一个视图中。Production 与你所需要的多个 Preview 并列显示，贡献者可以在各自独立的改动上工作，而无需争夺共享的预发布环境。与 Wrangler 环境不同——每个环境都需要部署和管理一个独立的 Worker——Previews 在一个 Dashboard 视图中保持这种隔离。
每个 Preview 都作为你的 Worker 的真实版本运行。有些改动只能在运行时验证：API 端点必须处理真实的请求并返回正确的响应。而更主观的改动，比如 UI 更新、新的引导步骤或不同的错误状态，需要在上下文中体验后才能到达生产环境。
为了让隔离延伸到整个应用，有状态的资源需要特殊处理。这是因为 Durable Objects 运行在单例模型上。一个实例负责给定的对象 ID，并且该实例拥有其存储。
如果一个 Preview 与生产环境共享同一个 DO 命名空间，你不仅会读到过时数据——你还可能实时修改正在服务生产流量的同一个实例（细思极恐！）。
因此，每次你运行 npx wrangler preview 时，Cloudflare 会自动为该 Preview 创建一个新的 Durable Object 命名空间和 Container 应用——这样，失败的迁移或糟糕的 schema 变更只会被限制在该分支。
你只需要导出类、添加迁移并通过 ctx.exports 访问它：
export class Counter extends DurableObject {}
export default {
async fetch(request, env, ctx) {
const id = ctx.exports.Counter.idFromName("demo");
const counter = ctx.exports.Counter.get(id);
return counter.fetch(request);
},
};
在生产环境中，ctx.exports.Counter 解析到生产命名空间，而在 Preview 中，它解析到该 Preview 的命名空间。
你现在拥有了完整的实验场。以 Sandboxes 为例，其启动时间的毫秒级改进可以决定体验的成败。如果你一直在尝试改善冷启动性能，你可以同时在不同分支上运行不同配置，并排比较它们的冷启动和热启动性能，更快地找到最佳配置。
既然每个分支都在隔离环境中拥有自己的 URL 和状态，你就可以进入反馈循环，在改动到达生产环境之前开始对每次改动进行实战测试。
你可以用通常的方式向 Preview URL 发送流量——从终端、CI 探针、Agent，或者自己点击浏览。一旦流量开始流动，你已经熟悉的每一个 Workers 可观测性工具都可以使用，作用域限定到每个独立的 Preview。
当每个请求到达 Preview 时，Workers 可观测性会在瀑布图中追踪其完整生命周期，包括 fetch 调用、绑定操作和处理器调用。因此，当出现问题时，你可以准确追踪发生了什么，而无需在生产流量或其他改动的信号中筛选。
Preview 的可观测性与你已经熟悉的生产 Workers 完全一致。从面包屑中选择你的 Preview，打开 Observability 标签页，查看其事件、错误和调用链：
为了让你的 Agent 拥有更多控制权，你可以让它们在无头浏览器中打开 Preview URL，逐步点击遍历登录流程，并截取截图或将整个会话记录为可回放的 DOM 事件——通过 Browser Use。
以下是 Agent 打开 Preview、捕获渲染内容并将失败请求连接到同一运行中 Workers 可观测性事件的示例。
审查者可以通过 Live View 实时观看会话，或在自动化需要判断时通过 Human in the Loop 介入。
如果出现问题，你会从两个角度看到：渲染的结果和运行时发生的事。
这为 Agent 提供了足够的证据来自主维持发布前的循环：部署、用 Playwright MCP 打开 URL、点击遍历、通过 Workers 可观测性 MCP 服务器查询调用链、打补丁、重新部署并验证。每次迭代都保持在分支范围内。
就像你不会在每次分叉时都从头重新配置代码一样，你也不应该被迫重新配置环境。
你在 Wrangler 配置文件中的 previews 块里一次性设置 Preview 的基础配置。
{
"vars": {
"ENVIRONMENT": "production"
},
"r2_buckets": [
{
"binding": "UPLOADS",
"bucket_name": "prod-uploads"
}
],
"previews": {
"vars": {
"ENVIRONMENT": "preview"
},
"r2_buckets": [
{
"binding": "UPLOADS",
"bucket_name": "r2-staging"
}
]
}
}
在 Dashboard 的 Worker → Settings 下，你会看到这被内联为 Production 和 Previews Base。基础配置设置好后，从任何分支运行 npx wrangler preview 即可创建 Preview。如果你的 Worker 通过 Workers Builds 连接到 Git，它会在推送时自动完成。
你可以只为某一个 Preview 覆盖任何设置——而不影响生产环境、基础配置或其他 Preview。
为了让整个设置更接近生产环境，你的 Preview URL 可以从你自己的自定义域名提供服务。如果你的应用运行在 example.com 上，那么 login 分支的 Preview 可以运行在 feature-login.previews.example.com。
如果你想保持这些 URL 的私密性，可以使用 Cloudflare Access 保护你的 Preview，要求访问者先登录。
我们已经在 Cloudflare 内部对 Worker Previews 进行了充分的内部测试，最显著的是用于构建和测试 CloudflareOS——我们用于安全地将 Agent 连接到公司系统的开源平台。
CloudflareOS 让 Agent 能够通过 Gatekeepers 与 Google、GitHub 和 Slack 等服务交互，Gatekeepers 控制着这些 Agent 可以访问和修改的内容。这使得 Gatekeeper 的改动特别敏感，因为一个 bug 可能导致数据泄露或允许本不该被允许的操作。
其中一些 bug 只在 OAuth 回调、权限、审批流程和应用状态一起运行时才会出现。因为分别测试每个组件无法展示完整系统的行为，我们会为每个正在审查的改动部署一个隔离的 CloudflareOS 及其 Gatekeepers 的 Preview。然后我们运行完整的工作流，修复失败的内容，并在合并之前再次测试。
我们看到客户出于同样的根本原因使用 Preview：有些问题只有在改动实际运行时才会暴露出来。
"Previews 使我们能够在边缘更早地进行迭代。对于 IKEA.com 来说，自定义域名支持帮助我们避免了 Content Security Policy 和 Cookie 问题。我们特别期待 Service Binding 支持，这将实现 Preview 之间的通信，成为跨我们的 Worker 链进行端到端测试的 game changer。"——Santosh Kumar Dwivedi，IKEA 高级软件工程师
"在 Supermemory，我们大量使用 Cloudflare，Worker Previews 正是我们希望看到的开发者体验改进。对于 HTTP 流程，我们可以在 Worker 改动到达生产环境之前进行预览，包括由 Durable Objects 支持的路由，更早地捕获问题，而不会减缓发布速度。"——Dhravya Shah，Supermemory 创始人
"Previews 对 Inspect [Ramp 的编码 Agent] 来说非常棒。我用它在我的手机上审查和测试一个 Inspect PR，让在手机上用 Inspect 响应式地审查和测试 PR 成为可能……用 Inspect。"——Dylan Garcia，Ramp 高级工程师
你可能在想：Workers 之前不是已经有 Preview URL 了吗？确实有过。我们现在将其称为 Version URLs，因为它们指向特定上传的 Worker 版本。与 Worker Previews 不同，它们不会为每个分支创建隔离环境，只能指向生产资源。了解更多并比较不同工作流，请查阅我们的文档。
Worker Previews 相比我们之前提供的版本是一次重大改进，但仍有更多功能即将推出。以下是我们正在开发的内容：
Preview 多 Worker 应用。 今天，从 Preview 发起的 service binding 仍然会调用被绑定 Worker 的生产部署。我们正在努力让整个请求路径保持在匹配的 Preview 内部。
在每个 Preview 中运行 Queue 消费者和 Workflows。 今天，Preview 可以向 Queue 发送消息但无法消费消息，而隔离 Workflow 执行需要单独配置。我们希望整个异步流自动被限定在分支范围内。
支持用于预发布和 QA 的长期 Preview。 我们从私有测试版的团队那里了解到，并非每个分支都是短寿命的——有些维护着跨越多个 sprint 存在的预发布、QA 或每个开发者专属的环境。我们希望端到端地支持这些场景，并且希望听到你们的使用方式，以便做得更好。
Worker Previews 现已可用。开始阅读文档，如果，你有功能请求或遇到问题，请在 GitHub 上提交 issue 或加入 Discord 上的 Cloudflare Developers 社区。
致谢：此项目的实现离不开 Greg Brimble、Patrick O'Donnell、Matt Price、Korinne Alpers、Max Peterson、Cina Saffary、Josh Wheeler、Thomas Ankcorn、Matt Rothenberg 和 Brandon Strittmatter 的设计和实现工作，以及 Brendan Irvine-Broque 和 Dan Carter 的领导。