2026 年 6 月 19 日，Cloudflare 发布了一项面向 AI coding agent 的功能：临时账户（Temporary Accounts）。任何 agent 在未登录状态下执行 wrangler deploy --temporary，即可在 60 分钟内获得一个可用的 Workers 部署环境，无需人工完成 OAuth 认证、MFA 验证、API token 复制粘贴或 Dashboard 点击。60 分钟后未主动 claim 的账户自动销毁。
这个功能在 HN 上收获了 209 分和 110 条评论，社区的关注点迅速从功能本身转向一个更根本的问题：当基础设施面向非人类使用者开放时，信任模型和金融护栏应该是什么样的。
功能设计：让 agent 自己找到入口
Temporary Accounts 的设计有一个细节值得展开：Cloudflare 没有假设 agent 在第一天就知道 --temporary 这个 flag。
实际流程是：agent 先执行 wrangler deploy，因为未认证而失败；Wrangler CLI 在错误输出中主动提示 “rerun this command with --temporary”；agent 读取输出后自我修正，在第二次尝试中带上 flag 并成功部署。这个模式与 agent harness 处理工具失败的标准路径一致——解析错误输出，用修正后的参数重试。Cloudflare 把重试提示嵌进了 CLI 本身，而不是依赖 prompt engineering 或文档训练数据。
部署成功后，agent 获得一个形如 https://<worker>.<account>.workers.dev 的预览 URL，可以在 60 分钟内反复 curl 验证输出、修改代码、重新部署。Wrangler 会缓存临时账户凭证并在有效期内复用。用户通过输出中的 claim URL 登录 Cloudflare 即可将临时账户永久化，转移所有已创建资源（Workers、D1 数据库、KV 命名空间、Queues 等）的所有权。
为什么这件事有意义
Cloudflare 在博客中给出了三个理由，每一个都指向 agent 基础设施的现实需求。
后台 agent 没有人类在回路中。 夜间运行的 agent、CI 沙箱中的子 agent、编排框架中的子任务——这些场景下，任何需要「60 秒内点击」或「从 Dashboard 复制 token」的步骤都意味着 agent 卡死。对交互式 copilot 而言只是摩擦，对后台 agent 而言是硬中断。
试错是 agent 的核心能力。 Agent 在 tight loop（编写 → 部署 → 验证）中表现最佳。它们需要廉价、可抛弃的部署目标，以便 curl 自己的输出并判断结果是否符合意图。60 分钟即抛型账户正是这种需求的精准匹配。
Agent 平台期望部署「开箱即用」。 用户越来越不希望在 agent 工作流中被迫跳转到从未听说过的第三方服务完成注册。Cloudflare 选择 Wrangler 作为入口，因为它的用法已被大量文档覆盖，agent 训练数据中已经包含——它缺的只是一个未认证就能走的入口。
社区反应：热情与不安并存
Simon Willison 在 HN 上留下了两条高赞评论，恰好构成了社区情绪的两极。
第一条：「Hot damn……Cloudflare 刚刚为所有人提供了免费的 scratch deployment。」他的兴奋点在一个更朴素的价值——任何人都能获得 60 分钟的免费 Workers 部署，用于 PR 预览、代码 review、快速原型验证。npx wrangler deploy --temporary 的零配置体验让他当场跑了一个 demo，并在评论中贴出了完整输出和部署 URL。“我希望它不会被滥用到 Cloudflare 关闭这个功能。”
第二条评论则转向了另一个方向，且点赞数更高：「Cloudflare 仍然没有推出 Workers 最有价值的功能：硬账单上限。我希望设置每月 $100 的 cap，并确信如果出了问题，应用会停止服务，而不是我收到数千美元的账单。Workers 最安全的使用方式仍然是免费层——它会在每天 10 万次请求后自动切断。」
这是一个已经发酵多年的批评。Willison 在此刻重新提出，与临时账户功能形成了紧张关系：Cloudflare 正在降低 agent 调用基础设施的门槛，但 agent 一旦获得部署能力后能造成的财务影响，并没有一个硬性的上限机制来托底。
账单上限问题的技术论辩
评论线程中展开了对账单上限可行性的讨论。
jedberg（前 Netflix、AWS 工程师）给出了技术视角的解释：基于金额的 cap 意味着把一个离线批处理系统（计费）拉进在线路径。每个请求都需要实时计算账单消耗，这在分布式环境下比基于请求数量的 cap 难得多——100K 次请求是一个可以分布式递增的单一计数器，而美元金额涉及多种资源的复杂计价模型。AWS 花了极长时间才提供账单预算功能，且至今标注为”尽力而为”，不保证超限不收费。
nlitened 用思想实验反驳了这一技术论述：如果 CEO 宣布「超出用户设定 cap 的费用由 Cloudflare 承担」，所有技术障碍会在三周内消失，服务会在超限后三秒内切断。如果超限金额从相关产品部门的员工奖金中扣除，所有问题将在 48 小时内解决。这暗示账单上限缺失的本质是组织激励问题，而非分布式系统难题。
这个观点并非孤例。评论区还有用户指出，可以让用户在平台中预存金额，超限即暂停服务——这是预付费体系的标准做法，不存在技术上的不可行。另有用户提到，Cloudflare 的企业计划中确实有预协商和预付费的上限机制，“只是不给你用信用卡的自助用户提供”。
客观而言，两方论点各有依据。计费系统确实比请求计数器复杂，但预付费、预算告警、超限自动暂停等模式在行业中并非无先例。账单上限长期缺失，与其说是纯技术问题，不如说是优先级和业务模型选择的结果。
代理基础设施的信任缺口
将临时账户和账单上限放在一起看，一个更宏观的模式浮现出来。
Cloudflare 的临时账户设计解决的是 agent 基础设施的第一个问题：接入。如何让非人类使用者获得程序化的资源创建入口，而不经过为人类设计的前端认证流程。这是 agent 部署链路的 cold start 问题。
账单上限解决的是 agent 基础设施的第二个问题：控制。当 agent 拥有部署能力后，如何在资源消耗维度施加硬性约束。这不是一个理论上的焦虑——agent 行为的非确定性意味着同一个 prompt 可能产生截然不同的资源消耗模式。一个被要求「优化性能」的 agent 可能产生大量子请求；一个编程错误的 loop 可能在几分钟内烧掉大量配额。
两个问题指向同一个方向，但 Cloudflare 当前只补了第一个缺口。Auth 墙拆掉后，下一个暴露的就是计费墙——或者说，计费墙的缺席本身变成了一个新的风险敞口。
这不是 Cloudflare 一家面对的挑战。整个 agent 基础设施领域都在探索非人类使用者的信任模型：AWS Bedrock AgentCore 在 2025 年底推出了策略边界功能；Stripe 和 Cloudflare 在 2026 年合作设计了 agent 代理开户的协议；WorkOS 和 Cloudflare 联合发布了 auth.md 标准，让任何平台都能通过现有 OAuth 流程为 agent 创建账户。但这些努力主要集中在「让 agent 能够使用服务」，而不是「限制 agent 能造成多大影响」。
从事件看趋势
Temporary Accounts 的真正信号价值在于它明确了 Cloudflare 的产品方向：基础设施的 API 面正在从面向人类开发者转向同时面向 agent。Wrangler 的设计已经体现了这种双重面向——对人类的错误提示变成了对 agent 的指令发现机制。
与临时账户同期的另一个动作是 Cloudflare 的 Agents SDK 开放给第三方框架（从 Flue 开始），以及 Cloudflare One stack 以 agent skill 库的形式发布。这些动作连在一起，勾勒出一幅将 Cloudflare 全线产品转化为 agent 可编程资源的路线图。
但 HN 讨论中反复出现的账单焦虑提醒了一个事实：agent 基础设施的成熟度不仅取决于接入层的自动化程度，也取决于控制层的粒度。在没有硬账单上限的前提下，每降低一步 agent 的接入门槛，同时也在放大财务风险。免费层（每天 10 万次请求后硬切断）反而成了最安全的选项——免费层是 Workers 平台上唯一真正硬性的资源约束。
对开发者而言的实践含义很明确：在使用 agent 驱动的 Cloudflare 部署时，要么主动管理免费层的硬上限作为安全网，要么通过预付费架构（如果可用）或独立的计费监控管道来弥补平台侧缺失的护栏。技术演进的方向是对的，但在基础设施对非人类使用者敞开的过渡期，控制机制同样需要跟上接入机制的速度。