AI 代理能把 Worker 临时部署到 Cloudflare 后，真正要管的是 60 分钟内怎么验收、怎么 claim、怎么回滚，不是把预览链接发出去就结束。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
AI 代理现在可以在没有正式 Cloudflare 凭据的情况下把 Worker 部署到临时预览账号。对独立开发者来说，这很方便；对真实项目来说，关键不是“能部署”，而是 60 分钟内能否验证清楚、拿到 claim URL、记录回滚边界。
更新日期与来源依据
更新日期：2026-06-28。Cloudflare 在 2026-06-19 的 changelog 里说明，AI agent 可以通过 `wrangler deploy –temporary` 部署到临时预览账号，临时部署保留 60 分钟，期间可以验证、重新部署，并返回 live Worker URL 和 claim URL。Cloudflare 的 Claim deployments 文档继续说明 claim、限制和支持资源。
公开来源控制在三条：Cloudflare temporary accounts changelog、Cloudflare claim deployments docs、Cloudflare Workers Wrangler commands。这篇教程只讨论预览和验收，不建议把临时账号当生产环境，也不把 claim 链接交给不可信的人。
适用场景
- 你让 AI 代理写了一个 Workers API、静态小工具、webhook 接收器或演示页，想先看线上 URL 再决定是否接入正式账号。
- 你没有准备 Cloudflare API token，或不希望把正式账号权限交给一次性实验。
- 你需要让代理完成“构建、部署、访问、修复、再部署”的短循环，但最终是否认领账号由人决定。
- 你在给客户、同事或自己做原型，需要一个有时限、可撤回、不会直接污染正式账号的预览路径。
不适用场景
- 生产站点、收费服务、用户数据入口、长期 webhook 或需要稳定域名的工具，不应依赖 60 分钟临时部署。
- 需要完整 Cloudflare 产品组合、复杂权限、正式日志留存或合规审计的项目，应使用正式账号、最小权限 token 和常规部署流水线。
- 涉及付款、登录、隐私数据、删除远端资源或绕过组织审批的任务，不应由代理自动 claim 或替人登录。
准备材料
- 本地项目：至少有 `wrangler.toml` 或能被 Wrangler 识别的 Worker 项目结构。
- Wrangler 版本：Cloudflare changelog 提到需要 Wrangler 4.102.0 或更高版本才能按临时部署路线操作。
- 验收表：列出要检查的路径、HTTP 状态、环境变量是否缺失、静态资源是否加载、错误日志怎么查看。
- 临时部署记录表：保存 live Worker URL、claim URL、部署时间、到期时间、代理变更摘要和是否认领。
- 回滚边界：临时部署一般不需要“回滚生产”，但需要清楚哪些代码没有进入正式仓库、哪些配置没有迁到正式账号。
操作步骤
- 第 1 步，确认这只是预览。把需求写成“部署一个可验证原型”，不要让代理添加真实密钥、客户数据或长期队列消费者。
- 第 2 步，检查 Wrangler。运行 `wrangler –version`，版本不够时先升级；运行 `wrangler logout`，让路径走临时账号，而不是误用当前登录态。
- 第 3 步，让代理执行部署。核心命令是 `wrangler deploy –temporary`。如果 Wrangler 输出建议改用临时部署，让代理按输出修复并重新执行。
- 第 4 步，拿到两个 URL。live Worker URL 用于访问验证，claim URL 只给真正负责账号的人。不要把 claim URL 放进公开 issue、文章、截图或聊天记录。
- 第 5 步，做 60 分钟内验收。访问首页、API 路径、错误路径、静态资源路径；如果是表单或 webhook，只用假数据测试；如果用 KV、D1、Queues 等支持资源，要确认临时限制是否满足演示。
- 第 6 步，决定 claim 或放弃。通过验收且项目要保留时，由人打开 claim URL 登录或创建 Cloudflare 账号。没有通过时，记录失败原因和代码改动，不要为了保留链接而仓促认领。
验收清单
- live Worker URL 返回 200，核心路径至少抽检 3 个，错误路径能返回预期状态。
- 静态资源、字体、图片、CSS、JS 没有 404；移动端宽度没有横向溢出。
- 没有把 `.env`、API key、私有端点、内部域名或个人账号信息写进 Worker 响应。
- 日志里没有连续 5xx、无限重定向、跨域错误或绑定缺失。
- claim URL 保存到私密记录；如果不认领，记录到期时间和后续处理。
实际例子：一个内容站工具页
假设你让代理做一个“标题长度检查器”，输入标题后返回字数、移动端显示建议和 slug 提醒。这个工具不需要数据库，也不处理用户隐私，适合临时部署。验收时检查 `/`、`/api/check?title=test`、不存在路径、手机宽度、资源加载和响应时间。通过后再决定是否 claim 到正式账号。
wrangler --version
wrangler logout
wrangler deploy --temporary
curl -I https:///
curl -s "https:///api/check?title=test" 常见坑
- 把临时 URL 当正式产品链接发给用户。60 分钟到期后链接失效，适合验收，不适合长期传播。
- 让代理自动 claim。claim 涉及账号归属，应由人打开链接确认，不要让代理接管登录。
- 没有测试错误路径。Worker 首页能打开不代表 API、静态资源、CORS、404 都正常。
- 把正式密钥复制进临时项目。临时部署降低账号门槛，不等于降低密钥管理要求。
排错路径
- 命令提示版本不支持：升级 Wrangler，再重新运行部署。
- 部署成功但访问 404：检查入口文件、路由、静态资产目录和 build 输出。
- 绑定资源不可用：核对临时账号支持的产品和限制，必要时把功能降级成纯演示。
- claim 后配置丢失：把部署输出、`wrangler.toml`、绑定说明和验收结果一起保存，重新用正式账号部署并比对 URL。
可复制记录模板
项目名称：
临时部署时间：
到期时间：
live Worker URL：
claim URL 保存位置：
验收路径：
发现的问题：
是否认领：
正式部署前还要补的配置：
负责人：维护建议：把临时部署当成“代理交付预览”，不是生产上线。每次 claim 前都要补一次正式账号的权限、域名、日志、回滚和账单边界检查。