Cloudflare 为自主 AI Agent 引入了临时账户：Agent 无需预先创建永久账户或完成常规身份认证，就能立即部署 Cloudflare Workers。临时账户如果没有被用户认领，会在 60 分钟后自动过期，其部署也随之失效。这项变化降低了“生成代码之后立刻运行”的门槛，同时把未认领资源的生命周期限制在一个明确的时间窗口内。
从生成代码到生成可访问的服务
传统的代码 Agent 可以创建项目、修改文件和执行测试，但到了云端部署阶段，通常会遇到账号注册、登录授权、API Token 配置和权限确认。对一个只想验证十几分钟的 Worker 来说，这些步骤比代码本身还重。
临时账户改变的是部署链路，而不是 Worker 的编程模型。Agent 可以先获得一个短期环境，再把生成的 Worker 发布出去，返回一个可访问的部署结果。用户可以在 60 分钟内检查行为、调用接口，并决定是否认领账户；如果不认领，账户和部署自动过期。
这类机制尤其适合以下任务：
- 验证 AI 生成的边缘函数是否能运行；
- 为一次性演示创建临时 HTTP API；
- 在代码审查前提供可访问的原型；
- 让 Agent 完成“生成、部署、探测、汇报”的闭环。
它并不适合承载需要长期可用、稳定域名或持久数据的生产服务。60 分钟自动过期是隔离边界，也是必须纳入设计的约束。
可以这样实践：部署一个最小 Worker
下面是一个可直接改造的最小项目。示例使用常见的 Workers 项目结构；临时账户的获取和认领方式应以 Agent 所在平台提供的 Cloudflare 集成为准，不假设额外的私有 API。
创建 package.json：
{
"name": "temporary-worker-demo",
"private": true,
"scripts": {
"dev": "wrangler dev",
"deploy": "wrangler deploy"
},
"devDependencies": {
"wrangler": "^4.0.0"
}
}
创建 wrangler.jsonc：
{
"name": "temporary-worker-demo",
"main": "src/index.js",
"compatibility_date": "2025-01-01"
}
创建 src/index.js：
export default {
async fetch(request) {
const url = new URL(request.url);
return Response.json({
ok: true,
message: "Hello from a temporary Worker deployment",
path: url.pathname,
deployedAt: new Date().toISOString()
});
}
};
安装依赖并先在本地验证：
npm install
npm run dev
另开一个终端执行：
curl --fail-with-body http://localhost:8787/health
在 Agent 已通过 Cloudflare 提供的临时账户流程取得部署环境后，可以执行标准部署命令：
npm run deploy
部署命令返回访问地址后，可进行一次最小验收。把变量替换为实际地址：
export WORKER_URL="https://your-deployment.example.workers.dev"
curl --fail-with-body "$WORKER_URL/health"
对于自主 Agent，建议把验收条件写进任务，而不是只要求“部署成功”。例如：
生成并部署一个 Cloudflare Worker。
要求：
1. GET /health 返回 HTTP 200；
2. JSON 响应必须包含 ok=true；
3. 部署后使用 curl 验证；
4. 汇报部署地址、验证结果和临时账户的剩余有效时间；
5. 不写入生产密钥，不连接生产数据库。
这段提示词让 Agent 对运行结果负责，也明确限制了它能够接触的数据。
60 分钟有效期会改变应用设计
临时部署不能假设长期可用。若 Agent 生成的服务需要保存状态，可以优先使用内存中的演示数据或模拟适配器，避免把短期部署错误地接入生产存储。
可以在响应中主动暴露临时属性，减少测试人员把预览地址当成正式服务的风险：
const expiresAt = new Date(Date.now() + 60 * 60 * 1000).toISOString();
export default {
async fetch() {
return Response.json(
{
environment: "temporary-preview",
expiresAt,
warning: "This deployment is not a production endpoint."
},
{
headers: {
"Cache-Control": "no-store",
"X-Deployment-Lifecycle": "temporary"
}
}
);
}
};
这里的 expiresAt 只是应用启动时计算的演示值，不代表 Cloudflare 临时账户的权威到期时间。实际系统应使用平台返回的生命周期信息；如果集成没有提供该字段，就不要自行伪造精确倒计时。
Agent 部署仍然需要权限边界
免去永久账户认证并不等于可以放松安全要求。Agent 生成的代码可能包含意外的外部请求、日志泄露、无限循环或不受约束的代理接口。临时资源会自动消失，但在有效期内仍可能被访问和滥用。
落地时应设置几条硬规则：
- 临时部署不得注入生产 API Token、数据库口令或用户数据；
- 部署前运行静态检查和最小测试；
- 部署后验证状态码、响应结构与外部依赖；
- 记录部署地址、创建时间、认领状态和责任人；
- 只有通过审查的代码才能迁移到永久账户；
- 不要把临时 URL 写入正式客户端、DNS 或长期配置。
临时账户最有价值的定位不是替代正式 Cloudflare 账户，而是成为 Agent 的短期执行沙箱。把它放在代码生成与正式发布之间，可以更快获得真实运行结果，同时让未认领的实验在 60 分钟后自动收敛。