AI Agent 写代码已经不稀奇了，真正尴尬的是下一步：它写完以后，怎么上线？

很多团队做 Agentic Coding Demo 时都会跳过这个问题。让 Agent 改一个 React 页面、生成一个 API、补一组测试，这些都能在本地仓库里闭环。但只要任务变成“把这个服务部署到云上，给我一个可访问的 URL”，Agent 很快就会撞墙：登录、注册、OAuth、MFA、创建 API Token、复制粘贴密钥、选择账单计划。

这些流程对人类是安全护栏，对后台 Agent 则是硬中断。

Cloudflare 这次在 HN 上火起来的 Temporary Cloudflare Accounts for AI agents 很有意思，不是因为它又发了一个“AI 平台功能”，而是因为它回答了一个非常工程化的问题：能不能让 Agent 先完成部署，再让人类决定是否接管？

我的判断是，这个方向比“给 Agent 一个长期 Root API Key”健康得多。它不完美，但至少把 Agent 部署的权限边界，从“信任一个会写代码的黑盒”改成了“给它一段短命的、可丢弃的执行空间”。

这个功能到底解决了什么

Cloudflare 的方案很直接：Agent 或开发工具可以执行：

wrangler deploy --temporary

然后 Worker 会被部署到一个临时 Cloudflare 账号下，部署结果可以在线访问。官方博客说明，这个临时部署会保持 60 分钟；如果用户觉得结果可用，可以在这段时间内 claim 这个临时账号，把它变成自己的正式资源。

用人话说就是：先让 Agent 把东西跑起来，不要一上来就问我要身份证、银行卡和长期 Token。

这跟传统 PaaS 的匿名预览有点像，但关键差异在于它面向的是 Agent 工作流。Cloudflare 明确把场景放在 AI coding agents 上：Agent 写了 Worker、网站、API，马上就能把产物部署出去，给用户一个可点开的结果，而不是停在“请你登录 Cloudflare Dashboard”的半成品状态。

这件事的价值不在于省了几次点击，而在于它改变了 Agent 任务的闭环方式。

过去一个 Agent 自动化任务常常到这里断掉：

生成代码 → 本地测试 → 需要部署 → 等人登录/授权 → 中断

临时账号把链路改成：

生成代码 → 部署到短命环境 → 人类验收 → 决定接管或丢弃

这个顺序变化很小，但工程意义很大。因为 Agent 的可靠性还没高到可以直接拿生产权限，然而我们又希望它能交付可验证结果。临时账号刚好卡在中间：不让 Agent 持有长期身份，但允许它完成一次低风险的端到端试跑。

为什么“身份”会成为 Agent 工程的瓶颈

做过内部 DevOps 自动化的人都知道，自动部署最麻烦的往往不是 YAML，而是身份。

CI/CD 里我们有 service account、OIDC federation、短期凭证、最小权限角色；人类开发者有 SSO、MFA、审计日志。可是 Agent 夹在两者之间：它既不像传统 CI 那样只执行固定 pipeline，也不像人类那样能理解登录页面、判断授权范围、承担法律责任。

这就导致两种常见但都不太舒服的做法：

第一种，把云平台 API Token 塞给 Agent。

这很爽，也很危险。Agent 一旦被提示注入、依赖投毒、工具输出污染，长期 Token 就可能被滥用。尤其当这个 Token 同时能创建资源、读写存储、改 DNS、访问日志时，风险不是“部署错一个 Worker”，而是整个账号被带跑。

第二种，让 Agent 每次卡住时喊人。

安全是安全了，但自动化价值打折。你得到的不是 Agent，而是一个非常会写代码、但每 10 分钟要你帮它点一次按钮的实习生。

Cloudflare 临时账号真正值得关注的点，是它把“身份”拆成了两段：

  • Agent 阶段：匿名或低摩擦地创建短命资源；
  • 人类阶段：验收后再绑定正式账号和长期身份。

这有点像浏览器里的试用沙箱，也像 CI 里的 ephemeral environment。它承认 Agent 不该一开始就拿正式权限，但也不把登录流程强行塞回给人类。

说白了，它不是在解决“AI 怎么变聪明”，而是在解决“AI 什么时候应该有身份”。

临时账号不是玩具，它背后需要状态运行时

如果只看 wrangler deploy --temporary，很容易把它理解成一个 CLI 小功能。但 Cloudflare 最近这一组 Agent 产品其实是连在一起的。

Cloudflare 的 Agents SDK 文档 把 Agent 描述成一种可持久化的运行时：每个 Agent session 有 durable identity、本地 SQL storage、实时连接、定时任务和可恢复执行。底层则依赖 Durable Objects 这类强一致的状态协调原语。

这点很关键。

很多 Agent 框架的问题是：它们把 Agent 当成一次 LLM 调用加一堆工具。看起来能跑，实际上很难管理状态。一个后台部署 Agent 至少要记住：当前生成了哪些文件、部署命令跑到哪一步、日志里出现过什么错误、是否已经把 URL 返回给用户、临时账号什么时候过期、用户有没有 claim。

如果这些状态只放在 prompt 或本地进程里，系统一重启就失忆。你最后不得不自己补数据库、队列、锁、重试、定时清理。

Cloudflare 的 cloudflare/agents 开源仓库把这套东西往平台层收了一步：Agent 是持久、有状态的执行环境，支持实时通信、调度、AI model calls、MCP、workflows 等。GitHub API 显示这个仓库已有 5000+ stars，最近仍在活跃提交；这至少说明它不是一篇白皮书式的概念发布，而是有可运行代码和开发者关注度的项目。

我不想把它吹成“生产级 Agent 平台的终局”。太早了。

但它暴露了一个趋势：Agent 平台正在从“调用模型的 SDK”变成“有身份、有状态、有权限边界的应用运行时”。临时账号只是这个趋势里最容易被感知的一环。

企业场景里，它适合放在哪里

如果你在公司里做 AI coding agent，我会建议把 Cloudflare 临时账号这类机制放在“预览环境”而不是“生产部署”上。

比较合理的链路是：

Issue / Prompt
  → Agent 生成代码
  → 自动测试
  → 临时部署预览
  → 人类验收
  → PR / 正式 CI
  → 生产发布

临时账号负责的是“让结果可见”。它不应该跳过代码审查，不应该绕过正式 CI，也不应该直接绑定生产域名。尤其在企业环境里，部署不仅是技术动作，还涉及审计、成本、数据边界和合规。

这个边界很重要。

Cloudflare 官方博客里提到临时部署 60 分钟，这个时间窗口本身就是产品设计信号：它更像一次 disposable preview，而不是长期托管。你可以让 Agent 用它来展示“我做出来了”，但不要让它变成“我已经替你上线了”。

这跟我之前写 Claude Code Routines 时的观点类似：让 AI 编程助手定时做事、自动响应事件是有价值的，但工程上必须把触发、权限和验收拆开。Agent 越主动，权限越要短命。

另一个可参考的站内主题是 AgentArmor 的八层安全框架。那篇文章讲的是 Agent 安全的纵深防御：输入、存储、上下文、执行、输出、身份。Cloudflare 这个功能正好落在“执行”和“身份”之间：它没有解决 prompt injection，但它降低了被注入后长期凭证泄露的爆炸半径。

这就是它真正的工程价值。

风险在哪里：临时不等于无害

当然，短命账号不是万能护身符。

第一个风险是滥用。任何“免注册部署”机制都会面对垃圾内容、钓鱼页面、恶意脚本和资源消耗问题。Cloudflare 没有把所有风控细节写出来，但从平台角度看，它必然需要配套速率限制、行为检测、内容治理和资源配额。否则 60 分钟也足够制造麻烦。

第二个风险是数据误放。Agent 生成的代码可能包含测试密钥、内部 API endpoint、甚至用户粘贴进 prompt 的敏感信息。临时部署虽然短命，但只要暴露在公网，就已经产生数据泄露面。企业使用时最好默认禁止 Agent 把真实凭证写进临时环境，必要时用假数据和 mock service。

第三个风险是“临时资源没人管”。人类验收完如果没有 claim，资源过期还好；如果 claim 之后缺少资产归属、成本标签、日志策略，就会变成新的云资源垃圾堆。Agent 自动化最容易制造这种“没人记得是谁创建的东西”。

所以我会把落地建议压得保守一点：

  • 临时部署只用于 preview，不接生产数据；
  • Agent 只拿最小必要权限，不注入长期 Token；
  • claim 之后必须进入正常的 IaC / CI 管理；
  • 对临时 URL 做日志、成本和滥用监控；
  • 让人类审批成为发布生产前的硬门槛。

这些建议听起来老派，但 Agent 工程现在最缺的不是炫技，而是边界感。

对开发者工具的启发

我更关心的是，这个模式会不会变成开发者工具的新默认。

想象一下，以后的 AI IDE 或 coding agent 不再只会说“我已经修改文件”，而是直接给你一个 60 分钟预览链接：后端 API 能访问，前端页面能打开，日志能查看，失败了还能自动读日志修复。你点开确认没问题，再把它升级成正式 PR 或正式部署。

这比纯文本 diff 更接近真实验收。

但前提是平台要给 Agent 提供合适的“短命能力”：短命账号、短命数据库、短命队列、短命对象存储、短命域名。否则 Agent 要么只能在本地玩沙盒，要么一上来就碰生产权限。

Cloudflare 这次先从 Worker 部署切入，路径是合理的。Worker 天然适合短生命周期预览：启动快、资源边界清晰、全球边缘网络托管、和 Wrangler CLI 强绑定。相比让 Agent 去操作一整套 Kubernetes 集群，风险和复杂度低很多。

这也是为什么我觉得它值得写。它不是又一个“AI 生成网站”的噱头，而是在补 Agent 自动化链路里非常现实的一块缺口。

我的结论

Cloudflare 临时账号的价值，不是让所有 Agent 都能无脑上线生产，而是给 Agent 一个更安全的中间态：先部署、可验证、短命、再接管。

这正是 Agent 工程需要的方向。

未来一两年，企业采用 AI Agent 的瓶颈可能不会是模型能不能写代码，而是这些更无聊的问题：谁给它身份？权限多大？状态放哪？出错谁负责？资源什么时候清理？

Temporary Accounts 给出的答案很朴素：不要急着信任 Agent，先给它一个会过期的房间，让它把东西做出来给人看。

我喜欢这个答案。因为它没有假装 Agent 已经成熟到可以接管一切，而是承认现实：Agent 很能干，但还需要笼子。短命账号，就是这个笼子的一个不错形状。