Cloudflare 推出 Temporary Accounts：AI Agent 免注册秒级部署 Worker

Cloudflare 上线 Temporary Accounts，AI Agent 一句 wrangler deploy --temporary 就能拿到 60 分钟有效的临时账户和 Worker 部署，绕过了所有为人类设计的注册和 OAuth 流程。

Cloudflare 又一次替 Agent 拆掉了一堵墙

6 月 19 日，Cloudflare 在 Agents Week 中扔出了一个看起来不大、实则相当激进的功能：Temporary Cloudflare Accounts。一句话概括——AI Agent 现在可以完全跳过注册和登录，直接把一个 Worker 部署到 Cloudflare 的边缘网络上跑起来。

命令简单到几乎不像 2026 年的产品发布：

wrangler deploy --temporary

回车。几秒之后，Agent 手里就握着一个公网可访问的 Worker URL，可以 curl 自己刚刚生成的代码，验证有没有跑通。临时账户会保留 60 分钟，期间人类开发者可以通过 Claim URL 把它「认领」成自己的正式账户；如果没人理，它就会自动过期，干净利落。

这是过去两年我看到的、最直接承认「Agent 是一等公民」的基础设施动作之一。

Cloudflare Wrangler CLI 中提示 --temporary 标志的截图

为什么这事不是花活

先讲清楚问题在哪。

现在写代码这件事，越来越多是 Agent 在干。Claude Code、Cursor Agent、Codex CLI、各种自研 harness，背后跑的全是 LLM。但凡你用过这类工具就知道，写代码这一段是顺畅的，真正卡住的永远是「上线」那一刻。

以前是这样的流程：Agent 写完一个 Worker，准备 wrangler deploy，然后 Wrangler 提示你需要登录。Wrangler 会试图打开浏览器，走 OAuth，跳到 Cloudflare 控制台，让你点同意、可能还要过一道 MFA，然后才把 token 塞回 CLI。

这套流程是 for humans 设计的。你坐在电脑前，确实没什么困难。但 Agent 不是人，它不会切窗口、不会扫二维码、它甚至没办法跟你说「老板帮我登一下账号」——尤其是那些跑在云端、半夜还在干活的后台 Agent。

结果就是 Agent 卡死，要么放弃，要么试图把同一个 Worker 部署到别的家——比如 Vercel、Deno Deploy、Netlify。Cloudflare 这次出手，本质上是承认了一件事：Agent 部署的入口之争已经开打了，谁先把摩擦降到零，谁就能先吃到这一波流量。

这功能到底怎么工作

机制其实挺巧妙。

第一个问题：Agent 怎么知道有 --temporary 这个新标志？Agent 训练数据里没有，文档刚出，LLM 不可能凭空知道。

Cloudflare 的解法是改 Wrangler 自己。当 Agent 在未登录状态下尝试 wrangler deploy，CLI 不再只是提示「请登录」，而是直接在标准输出里塞一段给 Agent 看的消息：嘿，如果你是 AI Agent，没法走浏览器登录，可以加上 --temporary 标志走临时账户路径。

这是典型的 prompt-in-the-loop 设计。CLI 的 stderr/stdout 现在就是 Agent 的 working memory 的一部分，Wrangler 等于在跟 Agent 「对话」。这个设计思路其实和 MCP、Codemode 是一脉相承的——不要假设 Agent 通过文档学会用工具，而是让工具在运行时主动教 Agent。

Agent 看到提示，重新跑一遍带 --temporary 的命令，Cloudflare 后端会做几件事：

起一个临时账户，给它分配资源配额
生成一个临时 API token，喂给 Wrangler
返回一个 Claim URL，Agent 可以把这个 URL 转交给人类
把 Worker 真的部署上去，给一个 workers.dev 子域名

60 分钟之内，Agent 可以在同一个临时账户里反复改代码、反复部署、反复验证。这就是 Cloudflare 自己说的「write → deploy → verify 闭环」——Agent 干活的超能力是「快速试错」，而试错的前提是反馈循环得短。

「便宜的、一次性的部署目标」

Cloudflare 官方博客里有句话值得拎出来：

Agents 需要便宜、一次性的部署目标，这样它们就可以 curl 自己的输出，并判断自己是否做对了。

这句话表面是产品描述，骨子里是一个新的开发范式声明。

传统部署是个仪式：你确认代码没问题，写好 CI/CD，过 review，部署到 staging，再到 prod。每一次部署都很重，因为每一次都默认是「认真的」。

Agent 的部署逻辑完全相反。它压根不知道自己的代码对不对，它需要先扔出去跑跑看，看看输出像不像那么回事。这意味着 Agent 时代的部署得是一次性的、可丢弃的、零摩擦的——和 Docker 容器、和 Vercel Preview 是一个性质，但要更彻底。

临时账户这个抽象其实在变相回答一个问题：当部署本身变得像一次函数调用一样廉价的时候，账户、配额、计费这些「人类协议」该怎么承载？Cloudflare 给出的答案是：先让 Agent 跑，跑通了再让人来认领。把身份和资源的绑定推到最后一步。

这是 Agents Week 的一块拼图

横向看一下 Cloudflare 这一周的动作，临时账户就更有意思了。

Agent Lee：dashboard 里的 AI 助手，用 Codemode 把 MCP 工具转成 TypeScript API，让模型直接写代码调用
Project Think：下一代 Agents SDK 预览
Artifacts：给 Agent 用的 Git 兼容版本化存储
Cloudflare One stack：Agent 驱动的部署
Agent Cloud × OpenAI：企业可在 Agent Cloud 中直接调 GPT-5.4

把这几样东西摆一起，意图就很明显了：Cloudflare 想做的不是「在产品里塞 AI」，而是把整个开发者平台改造成一个 Agent-native 的执行环境。临时账户解决的是「入门那一秒」，Artifacts 解决的是「代码持久化」，Project Think 解决的是 Agent 编排，Agent Cloud 解决的是模型 inference。

上下游基本闭环了。

跟 Vercel、Deno 比怎么样

要客观说一下，Cloudflare 不是第一个想到「让 Agent 直接部署」的。

Vercel 的 v0 已经在做类似的事，但路径更产品化：你在 v0 里聊几句，它生成一个项目，托管在 Vercel 自己的 sandbox 上。Deno Deploy 也支持 Agent 友好的 token 管理。但这些方案多少都还需要绑账号、走 SDK。

Cloudflare 这次的差异在两个点：

零绑定。完全不需要任何前置注册。这是真正的「Agent 第一性原理」——它假设调用方就是一个没有任何凭证的进程。
走 CLI 不走 SDK。Wrangler 是个老牌 CLI，文档遍布全网，所有主流编码 Agent 训练时都见过它。Cloudflare 不需要单独训练 Agent 怎么用一个新 API，只要改 Wrangler 一行行为就够了。

这第二点其实挺关键的。Agent 时代的 SDK 设计，应该优先考虑 LLM 训练数据里的覆盖密度，而不是 API 是否优雅。Cloudflare 显然算清了这笔账。

安全和滥用风险

听到「免注册、免认证、秒级拿到一台跑代码的机器」，做安全的人耳朵立刻就竖起来了。这不就是个完美的滥用工具吗？

Cloudflare 没有在博客里详细展开滥用防护，但从设计上可以推测几个约束：

临时账户有严格的资源配额，60 分钟就过期
Worker 跑在 Cloudflare 自己的 isolate 沙箱里，本身就有很强的隔离
出口流量可以被 Cloudflare 自身的 WAF/Bot Management 监控
API token 是临时的，无法横向扩散

但说实话，这个机制如果不加额外的速率限制和指纹识别，做钓鱼页面、做加密货币挖矿、做开放代理的成本会被压得很低。Cloudflare 在这块的态度估计是「先放出来看市场反应，再补防御」。这倒也符合他们一贯的产品节奏。

对开发者意味着什么

如果你日常用编码 Agent 干活，这个功能立刻能改变两件事：

第一，迭代速度直接提一档。以前你让 Cursor Agent 写个小工具想看看效果，它写完了你还得自己起本地 server。现在你可以让它直接 deploy 到 Cloudflare，拿到一个真实的 URL，curl 一下就能验证。

第二，可以认真考虑「让 Agent 完全自主交付小项目」的工作流。比如你说「帮我写一个把某 RSS 转 Webhook 的服务」，Agent 写代码、部署、验证、把 Claim URL 发给你。你点一下，服务就归你了。中间不需要你切一次窗口。

这件事的隐含含义是，「让 Agent 自己拥有云资源」这件事变得真实了。下一步可能就是临时数据库、临时对象存储、临时队列。Cloudflare 的 D1、R2、Queues 全套服务都可能跟进类似的 ephemeral 模式。

一点延伸的思考

回到一个更宏观的问题：基础设施的「人机交互边界」正在被重画。

过去十年，云厂商比拼的是控制台 UI 多漂亮、文档多详尽、CLI 多顺手——这些都是给人用的指标。AWS、GCP、Azure 的控制台已经复杂到没人能掌握全貌，但他们做了无数 tutorial 让你能慢慢学。

Agent 不需要 tutorial，Agent 需要的是可预测的、可机器读的、能在运行时自我描述的接口。临时账户、CLI 内嵌提示、Codemode 把 MCP 转 TypeScript，这些都是同一种思路的不同切面：把交互的认知负担从「教人类」转移到「教模型」。

Cloudflare 在这件事上跑得比绝大多数老牌云厂快，原因也很简单——他们没有沉重的存量人类用户习惯要守，Workers 平台本身就是开发者驱动、CLI 优先。AWS 想做类似的事，得先解释清楚 IAM 的 50 种 role 怎么临时化，光这一项就够开半年会。

对 OpenAI Hub 的开发者来说，临时账户配合 GPT-5.4、Claude 4.5、Gemini 3 这些模型的 tool use 能力，是一个非常顺手的组合。Agent 通过 OpenAI Hub 调模型生成 Worker 代码，再通过 Wrangler --temporary 直接部署上线——一条端到端的「想法到生产」管道，几乎没有人类干预环节。

至于这套东西最终会不会成为主流，我的判断是会，但路径不一定是 Cloudflare 通吃。**「Agent-native 的零摩擦部署」这个概念一旦被证明可行，每家云厂都会跟。**Cloudflare 的优势是先发和 Workers 这套架构本身适合一次性部署，但 Vercel、Fly.io、Render 跟进的速度不会慢。

这场仗值得盯着看。