摘要：Cloudflare 临时账户让 Agent 可以无登录部署 Worker，HTTP QUERY 成为正式 RFC 则补上了复杂查询的协议语义。它们看似是两条小新闻，本质上都指向同一件事：Agent 时代真正稀缺的不是“会说话的模型”，而是能让代理安全、临时、可验证地调用和交付的基础设施。
AI Agent 这件事，很多讨论还停留在“模型能不能理解任务”“能不能规划步骤”“能不能调用工具”。但越往真实工程里走，越会发现另一个更朴素的问题：
Agent 想把事情办成，基础设施允许它办吗？
2026 年 6 月有两条看似不相干的技术新闻，放在一起很有意思。
一条是 Cloudflare Workers 推出面向 AI Agent 的临时账户。Agent 可以运行 wrangler deploy --temporary，不用先注册账号、打开浏览器、走 OAuth、复制 API token，就能把 Worker 部署到一个 60 分钟有效的临时预览账户里[^1][^2]。
另一条是 IETF 的 HTTP QUERY 方法已经成为 RFC 10008。它允许客户端把复杂查询放在请求体里，同时保留类似 GET 的安全性和幂等性语义，解决了“GET 查询串太短、POST 又语义不准确”的老问题[^3]。
这两件事的共同点是：它们都在给 Agent 补“行动语义”。
一、Agent 的瓶颈不是会不会写代码，而是能不能交付
今天的代码 Agent 已经能写出一个小网站、一个 API、一个数据处理脚本，甚至能自动修 bug、跑测试、改配置。但写完代码之后，真实世界会立刻出现一堆过去只有人类开发者处理的摩擦：
- 没有云账户；
- 没有 API token；
- OAuth 要打开浏览器；
- MFA 要人点确认；
- 预览环境要手动配置；
- 部署失败后要看日志、改配置、重试；
- 部署出来的链接要回传给用户验证。
这些步骤对人类来说只是日常麻烦，对 Agent 来说就是硬阻断。只要流程中间卡一个“请在浏览器中登录”，后台自主任务就会停住。
Cloudflare 临时账户的意义就在这里。它不是简单多了一个部署参数，而是承认一个事实：AI Agent 需要自己的临时、受限、可回收执行环境。
这种环境有几个关键特征。
第一，进入成本低。Agent 不需要先拿到用户长期凭证，就能做出可访问的预览结果。
第二，生命周期短。60 分钟后自动过期，降低资源滥用和长期暴露风险。
第三，可转正。用户确认有价值后，可以认领临时账户，把原型迁移成正式项目。
这是一种很适合 Agent 的基础设施形态：先让它把东西跑起来，再由人决定是否接管。
二、临时部署会成为 Agent 产品的基本能力
如果把 Agent 看成“会写代码的助手”，临时部署只是方便功能；但如果把 Agent 看成“可委托的数字工人”，临时部署就会变成基础能力。
原因很简单：交付物必须可验证。
一个 Agent 说“我已经写好了页面”，价值不大；它给你一个临时链接，让你点开、测试、反馈、继续迭代，价值就完全不同。过去软件开发里 CI/CD、Preview Environment、PR Preview 解决的是团队协作问题；Agent 时代，它们解决的是“人如何验收代理工作”的问题。
这也解释了为什么临时基础设施需要很克制。它不能一上来就给 Agent 完整云账户权限，也不能让 Agent 依赖一次性的人类登录。更合理的模式是：
低权限、短生命周期、可审计、可认领。
未来类似机制不会只出现在 Cloudflare。数据库、消息队列、对象存储、向量库、浏览器沙箱、机器人仿真环境，都可能需要“Agent 可临时创建、用户可确认接管”的资源模型。
三、HTTP QUERY 解决的是另一类基础设施摩擦
Cloudflare 解决的是“Agent 如何部署”。HTTP QUERY 解决的是“系统如何表达复杂查询”。
传统 Web 里，GET 很适合查询，因为它安全、幂等、可缓存、可重试。但 GET 把参数放在 URI 里，复杂查询会遇到长度、编码、日志泄露和缓存建模问题。POST 可以把内容放进请求体，但 POST 在语义上不一定安全幂等，缓存、重试、中间件处理都会变得含糊。
RFC 10008 定义的 QUERY 方法就是在 GET 和 POST 之间补一个缺口：请求内容放在 body 里，但语义上仍是安全、幂等的查询。它还定义了 Accept-Query 响应头，让服务端声明自己支持哪些查询格式[^3]。
这对 Agent 很重要。
Agent 调用 API 时，查询往往不是一个简单关键词，而是一组结构化约束：时间范围、过滤条件、排序规则、权限边界、上下文片段、向量检索条件、分页策略。把这些塞进 URL 很难看，也不稳；全部用 POST 又会让“查询”和“写入”的边界模糊。
QUERY 的价值不是立刻改变所有 API，而是给未来更复杂的机器到机器交互提供更清晰的协议语义。
四、Agent 时代，基础设施要从“人能用”改成“代理也能安全用”
过去很多基础设施默认使用者是人。人可以看网页、输验证码、复制 token、判断风险、点确认按钮。Agent 不擅长这些，也不应该绕过这些。
所以真正的方向不是让 Agent 模仿人去点击仪表盘，而是让基础设施提供新的操作平面：
- 有明确权限边界；
- 有机器可读反馈；
- 有临时资源模型；
- 有可验证输出；
- 有标准化语义；
- 有人类接管点。
这也是我认为这两条新闻值得写的原因。它们不耀眼，不像新模型发布那样容易刷屏，但它们更接近 Agent 真正落地时会遇到的“管道问题”。
没有这些管道，再强的模型也只能停在聊天框里；有了这些管道，Agent 才能从“回答问题”走向“交付结果”。
结语：卖铲子的人正在改造铲子
AI Agent 的下一阶段，不会只由模型公司决定。
云平台、协议标准、开发者工具、身份系统、部署平台、日志系统、权限模型都会参与塑造它。因为 Agent 最终不是一个会聊天的页面，而是一套能读取上下文、调用工具、创建资源、验证结果、交还控制权的工作系统。
Cloudflare 临时账户和 HTTP QUERY 的共同信号是：基础设施正在开始适配代理，而不是只适配人。
这才是 Agent 从演示走向生产的关键一步。
[^1]: Cloudflare Blog：Temporary Cloudflare Accounts for AI agents，https://blog.cloudflare.com/temporary-accounts/
[^2]: Cloudflare Developers Changelog：Temporary accounts for AI agent deployments，https://developers.cloudflare.com/changelog/post/2026-06-19-temporary-accounts-for-agents/
[^3]: IETF RFC 10008：The HTTP QUERY Method，https://datatracker.ietf.org/doc/rfc10008/