AI Agent 终于能自己部署代码了：Cloudflare 临时账户上手体验

昨天刷 Hacker News 的时候看到一条消息，Cloudflare 发布了一个叫"临时账户"的功能，专门给 AI Agent 用的。点进去一看，好家伙，这东西解决了我一直觉得特别烦的一个问题——AI Agent 写完代码之后，没法自己部署。

说白了就是：你让 Claude Code 帮你写了个网站，写完了，然后呢？它没法帮你部署到线上。因为它需要一个 Cloudflare 账号，需要 OAuth 认证，需要 API Token，这些全都要人来操作。Agent 就卡在那了，像个写了作业但交不了的学生。

现在 Cloudflare 说：不用了，Agent 直接部署，不需要账号。

一条命令搞定：wrangler deploy --temporary。

我第一反应是：这也太方便了吧。第二反应是：等等，安全吗？

问题到底出在哪

用过 AI 编程工具的人应该都遇到过这个场景：你让 Agent 帮你写个项目，写得挺好的，但它没法帮你跑起来。不是代码有问题，是它没法帮你"发布"。

传统的部署流程是这样的：

1. 注册账号
2. 验证邮箱
3. 登录 Dashboard
4. 创建 API Token
5. 复制 Token 到终端
6. 配置项目
7. 部署

这些步骤对人来说不难，但对 AI Agent 来说，每一步都是坑。它没法打开浏览器点 OAuth 按钮，没法收验证码，没法复制粘贴 Token。就算你告诉它 Token，它也不知道怎么处理多因素认证。

背景 Agent（比如你让它在后台跑任务的那种）就更惨了——根本没有人在旁边帮它操作。它写完代码，部署不了，整个任务就卡住了。

我之前用 Claude Code 的时候就遇到过这种情况。让它帮我写了个简单的 API，写完了让它部署到 Cloudflare Workers，它直接告诉我："我需要你先登录 Cloudflare 并获取 API Token。" 我心想，我要是能坐在电脑前操作，还用你帮我写代码？

wrangler deploy --temporary 做了什么

Cloudflare 的解决方案简单粗暴但很有效：让 Agent 不需要账号就能部署。

流程是这样的：

1. Agent 运行 wrangler deploy
2. Wrangler 检测到没有登录，提示 Agent 可以用 --temporary 参数
3. Agent 加上 --temporary 重新运行
4. Cloudflare 自动创建一个临时账户，分配 API Token，部署代码
5. 部署成功，Agent 拿到一个预览链接
6. Agent 可以 curl 这个链接验证部署结果

整个过程不需要任何人工干预。Agent 自己搞定了。

临时账户有 60 分钟的有效期。在这 60 分钟内，Agent 可以反复部署、修改、再部署——就像正常开发一样。如果 60 分钟内你没有"认领"这个账户，它就自动删除了。

如果你觉得这个项目值得保留，可以点击认领链接，把临时账户变成你自己的永久账户。Workers、数据库、域名绑定，全部继承过来。

实际跑一下

我试了一下，体验确实很丝滑。先确保 Wrangler 是最新版本：

npm install -g wrangler@latest

然后给 Claude Code 一个简单的 prompt：

帮我写一个 Cloudflare Worker，返回当前时间，用 wrangler 部署，不要问我问题，你自己搞定。

Claude Code 的执行过程大概是这样的：

# 1. 创建项目

mkdir time-worker && cd time-worker

wrangler init time-worker

# 2. 写代码（Agent 自己生成的）

cat > src/index.ts << 'EOF'

export default {

  async fetch(request: Request): Promise<Response> {

    const now = new Date().toISOString();

    return new Response(JSON.stringify({ time: now }), {

      headers: { 'Content-Type': 'application/json' },

    });

  },

};

EOF

# 3. 部署（第一次会提示 --temporary）

wrangler deploy

# 输出：Error: Not logged in. Try `wrangler deploy --temporary` to deploy without an account.

# 4. Agent 自动加上 --temporary 重新部署

wrangler deploy --temporary

# 输出：✓ Deployed to https://time-worker.xxx.workers.dev

#       Temporary account expires in 60 minutes.

#       Claim URL: https://dash.cloudflare.com/temporary/claim/xxx

然后 Agent 自己 curl 了一下预览链接，确认返回了正确的时间。整个过程大概 30 秒，没有任何人工介入。

我之前用其他平台部署的时候，光是获取 API Token 就要花好几分钟——登录、找 Token 页面、创建 Token、设置权限、复制。现在这一步直接省了。

技术细节：临时账户背后发生了什么

我扒了一下 Cloudflare 的文档和 Wrangler 的源码，大概搞清楚了临时账户的工作原理。

当你运行 wrangler deploy --temporary 的时候，Cloudflare 做了这么几件事：

1. 创建一个临时的 Cloudflare 账户。这个账户没有绑定邮箱，没有付费信息，纯粹是为了让 Worker 能跑起来。
2. 生成一个临时的 API Token。这个 Token 的权限被严格限制——只能部署 Workers 和访问绑定的存储资源，不能访问你的真实账户数据。
3. 分配一个随机的 workers.dev 子域名。你的 Worker 会部署到类似 time-worker-abc123.xxx.workers.dev 的地址。
4. 返回一个认领 URL。如果你想保留这个部署，可以点击这个 URL 把临时账户绑定到你的真实账户。
5. 启动 60 分钟倒计时。到期后，临时账户和所有相关资源都会被自动删除。

这个流程的关键在于，它把"注册账号"这一步从部署流程中完全移除了。传统的流程是：注册、认证、获取 Token、部署。现在是：部署，然后可选认领。

从 API 的角度看，临时账户本质上是一个没有所有者的占位账户。它有完整的 Workers 运行环境，但没有关联到任何真实用户。这就像你在酒店开了个钟点房——能用，但不是你的。

Wrangler 的 API Token 是一次性的，绑定了这次部署会话。Agent 可以用这个 Token 做多次部署（在 60 分钟内），但不能用它访问其他 API。这个设计限制了滥用的可能性。

有意思的是，Cloudflare 在 Wrangler 的错误信息里嵌入了 --temporary 的提示。这意味着他们假设 Agent 会读错误输出并据此调整行为。这个假设在大多数情况下是成立的——主流的编程 Agent（Claude Code、Cursor、Copilot）都会读取命令输出并尝试修复错误。但如果 Agent 的 prompt 里明确说了"不要自动重试"，它可能就不会尝试 --temporary。

一个完整的实战案例

光说不练假把式。我来演示一个完整的场景：让 Agent 从零开始写一个简单的 URL 缩短服务，然后部署到 Cloudflare Workers。

我给 Claude Code 的 prompt：

帮我写一个 URL 缩短服务，要求：

1. POST /shorten 接收长 URL，返回短链接

2. GET /:id 重定向到原始 URL

3. 用 Cloudflare Workers KV 存储映射关系

4. 用 wrangler 部署，不要问我问题

Agent 的执行过程（简化版）：

# 创建项目

mkdir url-shortener && cd url-shortener

npm init -y

npm install wrangler

# 部署（第一次，没有登录）

wrangler deploy

# Error: Not logged in. Try `wrangler deploy --temporary` to deploy without an account.

# Agent 自动重试

wrangler deploy --temporary

# Successfully created temporary account

# Created KV namespace "URL_STORE"

# Deployed url-shortener to https://url-shortener-abc123.xxx.workers.dev

# Temporary account expires in 60 minutes.

# Claim URL: https://dash.cloudflare.com/temporary/claim/xxx

# Agent 验证部署

curl -X POST https://url-shortener-abc123.xxx.workers.dev/shorten   -H "Content-Type: application/json"   -d '{"longUrl": "https://example.com/very/long/url"}'

# {"shortUrl":"https://url-shortener-abc123.xxx.workers.dev/abc123","id":"abc123"}

curl -I https://url-shortener-abc123.xxx.workers.dev/abc123

# HTTP/2 302

# location: https://example.com/very/long/url

整个过程大概 45 秒。Agent 从写代码到部署到验证，全自动完成。如果用传统方式，光是创建 KV namespace 和获取 API Token 就要好几分钟。

不过有个坑：临时账户创建的 KV namespace 是临时的，60 分钟后数据就没了。如果你想要持久化存储，还是需要认领账户。但对于测试和验证来说，临时账户完全够用。

安全性分析：这样做真的没问题吗？

我知道很多人看到"不需要账号就能部署"的第一反应是：这不是安全噩梦吗？

我也这么想过。但仔细分析了一下，Cloudflare 的设计其实考虑得挺周全的。

资源隔离：每个临时账户都是独立的。Agent A 的临时账户和 Agent B 的临时账户互不影响。你不能通过一个临时账户访问另一个临时账户的资源。

时间限制：60 分钟的窗口期很短。恶意代码即使被部署了，也只能存在一个小时。这比永久托管的安全风险小得多。

域名限制：临时部署只能用 workers.dev 的子域名，不能绑定自定义域名。这意味着恶意代码不能伪装成你的网站。

权限限制：临时账户的 API Token 只能做部署相关的操作，不能访问 Cloudflare 的其他服务（比如 DNS 管理、防火墙规则等）。

但还是有风险：

1. 60 分钟足够做很多坏事。钓鱼页面、恶意重定向、挖矿脚本，60 分钟够用了。
2. workers.dev 域名有信任度。很多人看到 .dev 域名会默认信任，这可能被利用。
3. 没有速率限制的文档。如果一个 Agent 可以创建无限个临时账户，那就是 DDoS 的好工具。

Cloudflare 说"有一些限制"，但具体是什么限制没有公开。我猜测他们有 IP 级别的速率限制和内容审核机制，但没有证据。

我觉得这个功能的安全性还算可以接受，但需要持续关注。如果 Cloudflare 能公开更多的安全机制细节，会让人更放心。

这对 AI Agent 生态意味着什么

我觉得 Cloudflare 临时账户的意义不只是"方便部署"这么简单。它代表了一种趋势：基础设施在向 Agent 友好的方向演进。

传统的基础设施是为人设计的。注册账号、OAuth 认证、Dashboard 操作，这些都假设有一个"人"在浏览器前操作。但 AI Agent 没有浏览器，没有鼠标，没有键盘。它们只能通过 API 和命令行跟世界交互。

这就产生了一个错位：Agent 的能力越来越强（能写代码、能调试、能做架构设计），但基础设施的交互方式还是为人类设计的。Agent 在最后一步"部署"上卡住，就像一个会开车的人找不到加油站。

Cloudflare 的临时账户解决了这个错位。它把"注册账号"这个人类行为从部署流程中移除了，让 Agent 可以直接部署。

我猜接下来会有更多类似的服务出现：

• Vercel 可能会推出类似的"临时部署"功能
• 数据库服务（PlanetScale、Supabase）可能会提供临时数据库实例
• 域名注册商可能会提供临时域名
• 支付服务可能会提供沙盒环境，让 Agent 测试支付流程

这些变化加在一起，会让 AI Agent 的能力边界大幅扩展。不只是写代码，而是从写代码到部署到运营，全流程自动化。

Cloudflare 最近还做了几件事来推进这个方向。他们和 Stripe 合作搞了一个协议，让 Agent 可以自动帮用户创建 Cloudflare 账户、注册域名、开始订阅，整个过程不需要复制粘贴 Token 或者输入信用卡信息。他们还和 WorkOS 合作推出了 auth.md，这是一个开放标准，让 Agent 可以用现有的 OAuth 流程来创建账户。

另外 Cloudflare 还搞了个网站 isitagentready.com，检查你的服务对 Agent 是否"友好"——有没有提供无摩擦的认证方式、能不能被程序化调用。看得出来他们是真的很认真在做这件事。

我的实际体验和一些建议

跑了一整天的测试，总结一些经验：

Wrangler 版本很重要。我一开始用的是 Wrangler 3.x，没有 --temporary 参数。更新到 4.x 之后就好了。如果你的 Agent 报错说"unknown flag --temporary"，先检查 Wrangler 版本。

# 检查版本

wrangler --version

# 需要 4.x 以上

# 更新

npm install -g wrangler@latest

KV namespace 的坑。临时账户可以创建 KV namespace，但 wrangler.toml 里的 id 要写成 "temporary" 而不是真实的 namespace ID。Wrangler 会自动处理。如果你写了一个真实的 ID，会报错。

环境变量和 secrets。临时账户支持 wrangler secret put，但这些 secret 只在临时账户内有效。如果你认领了账户，secret 会保留。

自定义域名不行。临时部署只能用 workers.dev 子域名。如果你想绑定自己的域名，需要先认领账户，然后在 Cloudflare Dashboard 里配置。

Agent 的 prompt 要明确。我发现如果 prompt 里写了"部署到 Cloudflare"但没有说"不要问我问题"，Agent 可能会停下来问你要 API Token。所以 prompt 里要明确说"自己搞定，不要问我"。

认领流程。点击认领链接后，需要登录或注册 Cloudflare 账号，然后临时账户里的所有资源就变成你的了。Workers 的 URL、环境变量、绑定的存储，全部保留。

跟其他平台的对比

既然聊到了部署，顺便说说我用过的几个平台。

Vercel：前端部署的王者，Next.js 的最佳拍档。但部署需要 GitHub 连接或者 Vercel CLI 登录，没有临时账户机制。如果你只是想快速验证一个前端项目，Vercel 的体验还是最好的，但 Agent 没法自己搞定。

Netlify：跟 Vercel 类似，需要账号和 Token。不过 Netlify 有 Deploy API，可以用 API Token 部署，但获取 Token 本身还是需要人工操作。

Fly.io：全栈部署的好选择，支持 Docker 容器。但 fly auth login 是浏览器 OAuth 流程，Agent 搞不定。

Railway：界面友好，部署简单。但同样需要 GitHub 登录，没有无账号部署的选项。

Cloudflare Workers：现在有了临时账户，成了唯一一个 Agent 可以自己部署的平台。Workers 本身是 serverless 的，不需要管服务器，适合轻量级的 API 和网站。

如果你的项目是前端为主，Vercel 还是首选。如果你需要 Agent 自动部署，Cloudflare Workers 是目前唯一的选择。如果你需要全栈能力（数据库、消息队列等），可能要等其他平台跟进。

一些我不确定的事情

写到这里，有几个问题我还没搞清楚：

临时账户的资源限制。Cloudflare 说"有一些限制"，但具体是多少？每小时能创建多少个临时账户？每个临时账户能用多少 CPU 时间？能处理多少请求？文档里没说清楚。

计费问题。临时账户是免费的吗？如果 Agent 部署了一个高流量的服务，在 60 分钟内产生了大量请求，Cloudflare 会收费吗？还是说临时账户本身就是免费的？

数据保留。60 分钟后，临时账户的数据会被完全删除吗？还是说 Cloudflare 会保留一段时间？从隐私的角度，完全删除是最好的。

与其他 Cloudflare 服务的集成。临时账户能用 D1（数据库）、R2（对象存储）、Queues（消息队列）吗？我测试了 KV，能用，但其他的没试过。

这些问题的答案可能会影响这个功能的实际使用场景。等 Cloudflare 的文档更新了，或者我有时间再深入测试一下，再补充。

后面的计划

我打算把这个功能集成到我的日常开发工作流里。具体来说：

1. 快速原型验证：让 Agent 写完代码后直接部署到临时账户，验证效果。如果好用，再认领并绑定自定义域名。
2. CI/CD 集成：在 GitHub Actions 里用临时账户部署预览环境，PR 合并后自动部署到正式环境。
3. Agent 工作流：结合 Claude Code 或 Hermes Agent，实现"一句话从想法到上线"的全流程自动化。

后面搞定了再写一篇实战记录。有啥问题评论区聊。

• 本文写于 2026 年 6 月 21 日，基于 Cloudflare 官方博客和 Hacker News 讨论整理。*

这里有个挺聪明的设计：Cloudflare 不是假设 Agent 已经知道 --temporary 参数存在，而是在 Wrangler 的错误信息里告诉 Agent。

当 Agent 运行 wrangler deploy 但没有登录时，Wrangler 会返回一条错误信息，里面包含 --temporary 的提示。LLM 看到这条提示后，就知道可以加这个参数重新试一次。

这个设计思路挺值得借鉴的——不是让 Agent 事先知道所有 API 的所有参数，而是在运行时通过错误信息引导 Agent 发现正确的用法。有点像人类开发者看文档的过程，只不过 Agent 看的是错误输出。

不过这也意味着，如果 Wrangler 的错误信息格式变了，或者 LLM 对这条提示的理解有偏差，这个流程就可能出问题。Cloudflare 显然考虑到了这点，所以他们在文档里强调了这个设计。

不只是部署：Cloudflare 在 Agent 基础设施上的布局

临时账户只是 Cloudflare 在 AI Agent 方向的一个小动作。他们最近还做了几件事：

和 Stripe 合作：Agent 可以自动帮用户创建 Cloudflare 账户、注册域名、开始订阅，整个过程不需要复制粘贴 Token 或者输入信用卡信息。协议是 Cloudflare 和 Stripe 一起设计的。

和 WorkOS 合作搞了 auth.md：这是一个开放标准，让 Agent 可以用现有的 OAuth 流程来创建账户。任何服务都可以采用，不只是 Cloudflare。

isitagentready.com：Cloudflare 还搞了个网站，检查你的服务对 Agent 是否"友好"——有没有提供无摩擦的认证方式、能不能被程序化调用。

看得出来，Cloudflare 是真的在押注 AI Agent 这个方向。他们不只是在说"我们的产品支持 Agent"，而是在从基础设施层面改造整个部署和认证流程。

对我们开发者意味着什么

说实话，我觉得这个功能的影响比表面上看起来要大。

第一，Agent 的能力边界又扩展了。之前 Agent 能帮你写代码、跑测试、做 Code Review，但到了部署这一步就卡住了。现在这一步也打通了。从写代码到上线，Agent 可以全程搞定。

第二，"试错成本"大幅降低。Agent 最擅长的就是快速迭代——写一版、看看效果、改一下、再看。之前每次迭代都需要人来手动部署，现在 Agent 可以自己循环。60 分钟的临时账户刚好够用。

第三，这对 Vibe Coding 是个大利好。用 v0、Bolt、Lovable 这类工具的时候，它们帮你写完了前端代码，但部署到自己的域名上还是要手动操作。现在 Cloudflare 提供了一个标准化的部署方式，这些工具可以直接集成。

不过我也有一些担忧。

安全问题。临时账户意味着任何 Agent 都可以在 Cloudflare 上部署代码，不需要验证身份。虽然 60 分钟后会自动清理，但在这 60 分钟内，部署的代码是公开可访问的。如果有人让 Agent 部署恶意代码呢？

滥用风险。免费的临时部署，听起来就像免费的计算资源。虽然 Cloudflare 说"有一些限制"，但具体是什么限制，文档里没说太清楚。

供应商锁定。这个功能目前只有 Cloudflare 提供。如果所有 Agent 都默认用 Cloudflare 部署，其他平台（Vercel、Netlify、Fly.io）就被边缘化了。不过这可能也是 Cloudflare 的商业目的。

跟其他平台的对比

目前来看，其他平台在 Agent 部署方面还没跟上：

• Vercel：部署需要 GitHub 连接或者 Vercel CLI 登录，没有临时账户机制
• Netlify：类似，需要账号和 Token
• Fly.io：需要 fly auth login，也是浏览器 OAuth 流程
• Railway：需要 GitHub 登录

Cloudflare 在这方面确实是第一个吃螃蟹的。不过我猜其他平台很快也会跟进——Agent 部署是个刚需，谁先解决这个问题谁就占先机。

实际使用的一些细节

跑了一圈下来，踩了几个坑，也发现了一些细节：

临时账户的限制。文档说"capabilities may change over time"，但没具体说现在有哪些限制。我测试的时候，Workers 部署、KV 存储、R2 对象存储都能用，但没试过 D1 数据库和自定义域名。

认领流程。点击认领链接后，需要登录或注册 Cloudflare 账号，然后临时账户里的所有资源就变成你的了。Workers 的 URL、环境变量、绑定的存储，全部保留。

Wrangler 版本。必须用最新版的 Wrangler。旧版本没有 --temporary 参数，也不会在错误信息里提示这个选项。我一开始用的是旧版，折腾了半天才发现。

# 检查版本

wrangler --version

# 需要 4.x 以上

# 更新

npm install -g wrangler@latest

和现有项目的区别。如果你已经有 Cloudflare 账号并且登录了，wrangler deploy 会用你的账号部署，不会触发临时账户流程。--temporary 只在没有登录的情况下生效。

写在后面

Cloudflare 这个临时账户功能，说大不大说小不小。它不是什么颠覆性的技术突破，但它解决了一个实际痛点——Agent 没法自己部署代码。

我觉得这才是基础设施该有的样子：不是让开发者去适应机器的限制，而是让基础设施去适应开发者（和 Agent）的工作方式。

后面打算试试把这个功能集成到我的 AI Agent 工作流里——让 Agent 不只是帮我写代码，还能帮我部署和验证。到时候再写一篇实战记录。

有啥问题评论区聊。

• 本文写于 2026 年 6 月 21 日，基于 Cloudflare 官方博客和 Hacker News 讨论整理。*