从一个被忽略的痛点说起
智能体跑在云端，工作模式与人类会话很不一样：大量又短又尖的突发请求，夹在少数长任务之间。Cloudflare 的 Browser Run 原本建在自己的浏览器隔离产品上，为兼顾人类会话的稳定，难以针对这种尖峰做优化。于是团队把 Browser Run 整个重建到自家的容器平台之上，用区域化的预热浏览器池、D1 加队列做状态管理，并去掉了复杂的 WebSocket 编排。
官方给出的量化是：并发提升约四倍，快速动作响应快约一半，同时支持 WebGL 与 WebMCP。对一个要让智能体「像人一样打开网页、点按钮、读内容」的场景来说，这不是性能边角，而是可用性本身。
六层原语，各自补一块短板
过去两个月，Cloudflare 连续放出一组智能体基础设施原语，合起来覆盖智能体平台需要的每一层。按官方表述，它们构成一套全栈平台。
计算层分两档：Dynamic Workers 基于 V8 隔离做轻量执行；Sandboxes 提供完整的 Linux 容器，用于更复杂的任务，并支持安全的凭证注入。编排层是 Dynamic Workflows，一个轻量库，可按租户、智能体或请求灵活定制工作流。记忆层是 Agent Memory（私有测试），管理来自智能体对话的结构化记忆，让团队能访问共享知识。浏览层就是重建后的 Browser Run，跑在容器上的无头 Chromium，智能体可通过 DevTools 协议或 Agents SDK 与之交互。商务层是一条与 Stripe 共同设计的协议，让智能体自主管理 Cloudflare 的账户、域名、订阅与部署，并设有每月 100 美元的支出上限。
把这几层连起来看，逻辑是清楚的：计算解决「跑得动」，编排解决「排得清」，记忆解决「记得住」，浏览解决「看得到网页」，商务解决「付得出」。垂直整合的卖点在于，开发者不必再分别从五家供应商拼这些能力。
它和另外两家有什么不同
对比之下，AWS 的 Bedrock AgentCore 有 Agent Registry（智能体注册表），但没有同等的受管浏览器或智能体记忆；Google Cloud 的 GKE Agent Sandbox 是 Kubernetes 原生的，更像一套编排能力而非受管平台服务。两者都没有一条类似的商务协议，让智能体直接去管云上账单。
Cloudflare 的差异化，正是这种边缘分布、逐租户对应的垂直整合。它还有一套「Customer Zero」做法：先在自己的产品上跑同一套基础设施，再对外提供。这能减少「文档写得好、实际接不通」的落差，但也意味着它的很多能力是先服务于自家需求，再外溢给开发者。
对构建者意味着什么
对想做长程、会浏览网页、还要能下单的智能体团队，Cloudflare 这套栈把「基础设施」从一堆待选项变成了「一块板」。好处是起步快、边界少；代价是栈越整合，迁移成本越高，锁定也更明显。
另一点值得注意：商务层把「智能体自主付费」变成平台能力，配合每月支出上限，是一个相对克制的默认。对一个能替你花钱的智能体来说，上限本身就是安全设计，而不只是计费功能。这与把支付能力长期交给智能体的做法，是两种不同的风险假设。
几点需要保留的谨慎
其一，Agent Memory 仍在私有测试，记忆的持久性、隔离粒度与跨智能体共享的权限模型尚未充分公开，涉及敏感数据的场景需逐项确认。
其二，Browser Run 的重建带来的行为与兼容性变化，以及与既有浏览器隔离产品的关系，需要实际迁移来验证，不能只看并发与响应数字。
其三，每月 100 美元支出上限是平台默认值，真实业务的预算护栏仍应在应用侧另设，不能依赖平台上限作为仅靠的防线。
其四，「六层全栈」里，官方明确点名的层与开发者侧集成层（Agents SDK）之间仍有职责划分，构建者要分清哪些是平台托管、哪些要自己写。
Agent Memory 的公开可用时间表、各原语在国内的访问与合规情况，以及商务协议支持的范围，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。