从互联网支点到 AI Infra 急先锋重新认识 Cloudflare

先看一次访问，再看这家公司

理解 Cloudflare，可以从打开一个网站开始。浏览器先查询域名对应的地址，再建立连接，向服务器索取页面。网站可能在另一片大陆，原始服务器可能繁忙，请求也可能来自攻击程序。让这次访问顺利完成，已经包含了地址、传输、性能和安全好几类工作。

Cloudflare 把自己的网络放在访问者与网站之间。对于启用了代理的网站，访问者先连接 Cloudflare，由它返回缓存内容、检查请求，或把请求转交给原始服务器。这个“原始服务器”通常称为源站，它完全可以继续留在 AWS、Azure、其他云或企业自己的机房。Cloudflare 因而不必先替换客户现有的云，就能参与应用的运行。

开发者熟悉的橙色云朵，代表 DNS 记录开启了代理。这里只托管 DNS 和把网站流量接入代理，是两件不同的事：DNS-only 记录仍可以直接指向源站，不能因为域名用了 Cloudflare，就认定它的所有访问都经过 Cloudflare 防护。这个小区别，也说明它的产品是按接入方式组合使用的。代理与 DNS-only ↗

在这个位置上，产品很自然地向两边延伸。既然请求已经经过网络节点，就可以在那里识别攻击、检查身份、选择路线；既然已经在判断如何处理请求，也可以让开发者放一段代码进去，直接生成响应。CDN、安全产品和 Workers 的关系，由此就比一张并购清单更容易理解。

网络覆盖越广，共同依赖也越明显

梗图虽然夸张，却有现实依据。按照 Cloudflare 的官方说法，它的网络服务着约 20% 的互联网流量。互联网当然不全靠 Cloudflare，但如此规模已经足以解释：为什么这家很少被普通用户直接接触、却藏在大量网站背后的公司，会成为人们共同依赖的基础设施。官方流量表述 ↗Mesh 官方说明 ↗

2025 年末，两场相隔仅 17 天的重大故障，让人看见了这套互联网基础设施的“阿喀琉斯之踵”。

2025 年 11 月 18 日晚，北京时间七点多，这场故障出现在普通用户眼前：许多网站无法正常打开，页面只剩下服务器错误。部分用户进不了 ChatGPT 网页版，Sora 网页版和 OpenAI 开发者网站也受到影响。按 OpenAI 的复盘，这段网页访问故障持续约三小时十分钟，用户看到的主要是 403 或 504 错误；同一时期，手机 App、API 和后端服务仍保持正常。同一款产品，仅仅换一个入口，结果就完全不同。OpenAI：哪些用户受了影响 ↗Cloudflare：页面报错与事故起点 ↗

受影响的公司和机构横跨了几乎所有常见的互联网场景。社交平台有 X，音乐服务有 Spotify，设计工具有 Canva，约会应用有 Grindr，游戏有《英雄联盟》；电商、文件协作和金融领域则包括 Shopify、Dropbox、Coinbase 与 Moody’s。它甚至越过了纯互联网公司的边界：新泽西交通局表示，其网站等部分数字服务一度无法访问或加载缓慢；纽约市应急管理部门也收到市政服务受影响的报告。也就是说，当晚受到干扰的不只是聊天和娱乐，还包括购物、金融信息、公共交通和城市服务。美联社：受影响的公司与公共服务 ↗路透社：Canva、X、Grindr 与 ChatGPT ↗Axios：ChatGPT、Spotify 与 X ↗

Ookla 在年末回顾中统计，这场 11 月 18 日事故在全球触发了约 330 万条故障报告；《华盛顿邮报》在事故当天也观察到，多个热门应用已经累计数万条报告。

还有一个与开篇截图直接相关的影响：连那句“验证你是人类”也可能加载不出来。于是，一些原本仍在运行的网站，会因为验证环节失效而挡住用户；站长想登录 Cloudflare 后台排查问题，也可能被同一个验证页面拦在门外。Cloudflare 后来将其称为 2019 年以来最严重的一次故障，并承认事发期间多数核心流量一度无法正常通过其网络。验证、后台与核心流量影响 ↗

17 天后的 12 月 5 日，类似的一幕再次发生。公开报道点名的服务包括 LinkedIn、Zoom、Shopify 和《堡垒之夜》，连专门用来查看“谁又宕机了”的 Downdetector 本身也一度打不开。Downdetector 恢复后，仅 Cloudflare 这一项就记录到超过 4,500 条用户报告。Brevo 的情况更能说明对单家公司的实际影响：它面向客户的网页和 API 一度全部不可用，在故障窗口内尝试访问平台的用户无一例外都会遇到问题。12 月 5 日受影响公司与报告量 ↗Shopify 与《堡垒之夜》 ↗Brevo：全部访问用户受到影响 ↗

这与传统云平台的进入方式有些不同。企业使用通用云时，往往先选区域、服务器、数据库，再搭建应用；Cloudflare 常常先出现在已经存在的访问路径上，随后才接手更多工作。当然，一张统一网络不代表每个节点都有相同的 GPU、数据库和容器资源，也不代表数据在全球各处都能同时保持一致。产品越接近计算与数据，开发者越需要理解它的放置方式和限制。

成本优势从哪里来：一套基础设施，承载更多场景

复用已有边缘机器、在上面不断增加场景，确实是理解 Cloudflare 的一条重要线索。它并不是先为 CDN 铺一张网，再为防火墙、Workers 和 Agent 各建一张网。网络接入、服务器平台，以及软件部署和运维体系，都可以为多种服务共同使用。流量已经来到这里，增加一项检查或运行一段应用代码，就有机会沿用已经建立的访问路径。统一平台的安全架构 ↗

这不是只停留在产品宣传里的概念。2026 年的 Gen 13 服务器设计说明，同一代硬件需要兼顾 CDN 缓存、Durable Objects、Containers 和内部配置系统等负载；更高的计算密度，也意味着同样的处理能力可以由更少的节点承担，减少部署、打补丁与监控的对象。新产品是在共同平台上增加需求，硬件也随着这些需求持续升级。2026 年 Gen 13 硬件设计 ↗

Workers 则把复用推进到一台机器内部。不同客户的程序运行在相互隔离的 V8 isolates 中，可以共享运行时进程，不必每个小程序都启动一套虚拟机和完整进程环境。对于短小、间歇运行的 Web 逻辑，这有利于减少固定开销，让同一批机器承接更多请求。它不是没有隔离，而是隔离的粒度更轻。Workers 与 V8 isolates ↗

从经济上看，这意味着新增产品不必从零承担一整套全球网络的固定投入，共同成本可以由更多业务分摊。统一资源池也有机会减少按产品分别预留容量造成的闲置。这是基于架构的成本推论：它解释了 Cloudflare 为什么有条件把某些服务定得较低，却不能证明每个产品都更便宜。零售价格还包含产品策略、套餐、服务承诺和利润安排，不能直接当成底层成本。

复用也不是无限的。Gen 13 工程说明提到，增加请求处理进程会挤占同机其他生产服务的资源；GPU 推理则需要专门的硬件、供电与散热投入。离用户近的网络入口，也不意味着数据库或有状态任务都在同一地点完成。Cloudflare 的优势是少做重复建设、持续提高利用效率，而不是把新增计算变成零成本。共享资源与调度约束 ↗AI 推理与网关的分工 ↗

网络的优势，不只是地图上的点多

机器可以买，但把节点接到大量运营商、云平台和企业网络上，还需要地点、互联关系和长期运维。前面规模图中的 335+ 个城市、13,000+ 个网络互连，正是这种积累的外在表现。这些连接有助于减少绕路和第三方转接；Anycast 让同一服务地址从多地发布，再由网络路由选择入口。它追求更合适的路径，并不保证每次都是地理最近或绝对最快。全球网络与互联 ↗

缓存进一步减少重复运输。一份内容已经在边缘或上层缓存里，就不必每次回到源站；站点之间还可以利用 Cloudflare 的骨干网络运输内容。对内容分发来说，用户分布广、访问重复度高时，这些机制能降低回源压力和部分传输成本。这里的“拥有网络”主要指运营自己的服务器、路由和互联体系，也包括租用光纤或波长资源，并不意味着拥有全球运营商的物理线路。骨干网、互联与分层缓存 ↗

规模还让这张网具备多重用途：正常流量用它分发内容和运行代码，恶意流量在接入侧被处理，新的应用则可以接入同一套基础设施。Cloudflare 在 2026 年的网络技术文章中，把开发者平台与这张已有网络直接联系起来。相较只卖一个独立安全工具或一段函数计算，它不必重新获得每一个流量入口；这也是网络覆盖能转化为产品扩展优势的原因。2026 年网络技术说明 ↗

若要说“最大”，需要把尺度写清。2026 年 8 月 31 日，W3Techs 显示 Cloudflare 被 24.9% 的受测网站采用，在能识别反向代理服务的网站中占 84.5%，排名第一。这说明它在该统计范围内，是网站采用最普遍的反向代理服务。网站采用率统计 ↗Cloudflare 官网则将其称为全球最大的网络之一，这是公司的网络规模表述。官方网络介绍 ↗两者都不能证明它的实际传输流量、总带宽或服务器数量全部排名第一。网站覆盖不是字节流量，内容分发网络也不是内容所有权。

从反垃圾邮件项目，到一家全球平台

2004 年，Matthew Prince 和 Lee Holloway 想弄清楚一件事：垃圾邮件发送者是怎样从网站上采集邮箱地址的？两人做了一个让站长参与追踪的系统，叫 Project Honey Pot。项目慢慢有了用户，也收到一个反复出现的要求：已经知道谁在做坏事，能不能直接把他们挡住？今天这家公司的故事，就从这个要求开始。官方创业回顾 ↗

三个人，把“发现坏人”变成了“挡住坏人”

Prince 当时已经有创业经历，曾联合创办软件与服务公司 Unspam Technologies。他的求学路径也颇特别：本科主修英语、辅修计算机科学，之后取得芝加哥大学法学院的 J.D.，又去哈佛商学院读 MBA。技术、法律和商业，先后进入了他的工作。后来 Cloudflare 成立，他从 2009 年 7 月起担任 CEO，直到本文更新的 2026 年 8 月仍在任。Prince 官方履历 ↗

Michelle Zatlyn 在哈佛商学院与 Prince 结识，此前曾在 Google 和 Toshiba 工作。她加入创业团队后，早期负责用户体验，2016 年成为 COO，2020 年成为总裁；目前官方治理页面列出的职务是总裁兼董事会联合主席。她的经历让这家网络技术公司从创业初期就有人专门负责“用户怎么用起来”这件事，而不仅仅是底层系统能不能运行。创办前经历 ↗Zatlyn 官方履历 ↗

Lee Holloway 则是 Prince 在 Project Honey Pot 中的技术伙伴，负责该项目的架构，并在 Cloudflare 筹备期间做出了最早的可运行原型。因此，创始团队不能简单概括为“三位商学院同学”：Prince 与 Zatlyn 在哈佛相识，Holloway 带来的是此前合作中积累的工程经验。原型与创始团队 ↗

2009 年，Matthew Prince、Michelle Zatlyn 与 Lee Holloway 共同创办 Cloudflare。商业计划与技术原型开始汇合：让一项只告诉站长威胁在哪里的服务，变成真正替网站处理访问的产品。2004 年是前身项目的起点，2009 年才是 Cloudflare 的创办年份。成立与原型记录 ↗

上线时，全球网络只有“四个半数据中心”

从监测走到拦截，需要真正介入网站的访问路径。这样做又带来一个问题：多经过一层服务，会不会让网站更慢？按公司的创业回顾，团队围绕延迟反复优化，配合静态资源缓存和恶意流量过滤，让安全与加速逐渐成为一组可以一起卖给站长的服务。2010 年 6 月先向部分社区用户开放私测，9 月 27 日在 TechCrunch Disrupt 正式公开上线。2009 年是公司创办，2010 年是服务公开发布，两种日期说的是不同阶段。公开上线记录 ↗

很难把那时的 Cloudflare 与今天的全球网络直接联系起来。创始人后来回忆，上线时只有“四个半数据中心”：芝加哥、Ashburn、圣何塞、阿姆斯特丹，以及东京。东京之所以只能算“半个”，是因为路由不稳定，团队会把它关闭半天，免得影响其他地方。今天听起来像玩笑的数字，记录的是这张网从小规模、并不完善的系统一点点扩出来的过程。创始人对早期网络的回忆 ↗

商业模式从一开始就给小网站留了入口。2010 年上线时，Cloudflare 同时提供 Free 和每月 20 美元的 Pro 套餐；到 2012 年 6 月，又增加 Business 和面向大客户定制的 Enterprise 套餐。这里的价格是历史定价。免费服务降低了试用门槛，更强的保护、支持与企业要求则为付费留下空间。它的业务由此可以从大量站长的日常使用向上延伸，而不只依赖先签下一张大企业采购单。创始人回顾早期套餐 ↗

2014 年 9 月推出的 Universal SSL，体现了这种扩张方式：Cloudflare 把自动配置的边缘证书和 HTTPS 接入带给免费用户，让更多小网站也能使用原来需要另行处理的能力。这不等于源站连接自动实现完整加密，但网站接入安全服务的门槛确实被降低了。此后部分能力继续从高价套餐向更低层级开放，公司则通过新增产品寻找新的付费需求。Universal SSL 发布 ↗套餐演进思路 ↗

2017—2022：从网站防护，走向开发平台与企业网络

2017 年，Cloudflare 宣布 Workers，2018 年 3 月向所有开发者开放。此前主要由 Cloudflare 决定请求如何缓存、检查和转发，现在客户可以写自己的 JavaScript 来处理请求。两者之间的区别很大：购买预先做好的网络功能，开始变成使用一套可编程的运行环境。Workers 首发 ↗2018 年开放使用 ↗

企业访问是另一条扩展路线。2018 年 1 月发布的 Access，把身份验证与授权带到应用入口，用来判断员工能否访问某个内部系统。Cloudflare 因而从“公众怎样访问网站”，走到“员工怎样访问公司资源”。它仍然使用网络和代理能力，但服务对象、管理者与预算来源都扩大了。Access 发布 ↗

2019 年 9 月 13 日，Cloudflare 在纽约证券交易所上市，股票代码为 NET。从公开上线到敲响上市钟，过去了近九年。此时 Workers 和 Access 都已经出现，这家靠网站安全与加速起步的公司，正在尝试为开发者和企业员工承担更多工作——这一步发生在 ChatGPT 热潮之前。上市日期与代码 ↗

2020 年 10 月，Cloudflare One 把企业连接、身份与安全能力组织成更完整的平台。2022 年 9 月，R2 对象存储正式可用，给文件、图片等数据提供了存放位置，并以不收取出口流量费作为重要区别。前一条路线扩大了网络服务的对象，后一条路线则让开发者不只能够运行一小段代码，还能把应用需要的数据接进来。Cloudflare One 发布 ↗R2 正式可用 ↗

2023 至今：AI 推理、Agent 与开发工具陆续加入平台

2023 年，Workers AI、Vectorize 和 AI Gateway 为模型推理、检索和调用管理补上工具；随后，远程 MCP、Agent 执行环境与内容访问控制，把更多 AI 应用需要的工作带到这张网络上。具体发布阶段会在后文展开。这里先记住一条发展线：安全和加速帮助 Cloudflare 接入网站，Workers 把网络变成能运行客户代码的地方，存储和企业连接又扩大了它能承担的任务。AI 利用了这些积累，并没有让过去的业务消失。2023 年 AI 产品发布 ↗

2026 年 4 月，Cloudflare 与 OpenAI 把合作推进到 Agent 的运行层。企业可以在 Agent Cloud 中使用 OpenAI 模型，也可以把基于 Codex harness 的 Agent 部署到 Cloudflare Sandboxes：模型负责理解任务和决定下一步，Cloudflare 提供运行代码所需的隔离环境。这说明 Workers 周围逐步形成的计算与开发能力，已经开始接入外部 AI 产品；但它并不等于“ChatGPT 整体运行在 Cloudflare”。OpenAI 合作公告 ↗

2026 年 6 月 4 日，Cloudflare 宣布收购尤雨溪（Evan You）领导的 VoidZero，Vite、Vitest、Rolldown、Oxc 等工具背后的团队加入公司。这一步把业务伸到了应用上线以前：开发者还在电脑上写代码、构建和测试时，Cloudflare 就有机会参与其中。它从保护别人做好的网站，走到了帮助人们把应用做出来；这笔收购的产品与商业逻辑，会在后面的开发者章节展开。收购公告 ↗

同年 7 月，合作又延伸到网页托管和搜索发现。OpenAI 的服务商清单把 Cloudflare 列为 CDN 与 Web Hosting 提供商，并明确把 ChatGPT Sites 创建的网页纳入托管范围；双方还启动了一项搜索研究试点，尝试用内容新鲜度、页面变化与流量质量等信号改善内容发现和抓取。前者是已经写入服务商清单的托管关系，后者仍是研究项目；两者都不能推导出“ChatGPT Search 的整套系统运行在 Cloudflare”。OpenAI 服务商清单 ↗搜索研究试点 ↗

所以，今天看 Cloudflare 的产品全景，看到的是多年叠加的结果。它从一个具体的网络滥用问题出发，先让站长愿意接入，再让企业与开发者把更多工作交给它。沿着这段历史往下读，下一章那些看起来分散的产品名称，就有了共同的来处。

同一张网络，服务三种不同的访问

Cloudflare 的产品很多，但可以先按使用者要完成的事情，分成三组：让公众安全、顺畅地访问网站；让员工和不同地点安全地访问公司资源；让开发者直接在网络上运行应用。AI 贯穿后两部分，尤其与开发者平台联系紧密，不必再把它画成一座与其他产品无关的孤岛。

第一组：网站快不快，能不能安全地被访问

CDN 把可以缓存的图片、脚本和页面放在离访问者更近的网络节点，减少每次都回到源站取内容的需要。DNS 回答地址问题，CDN 解决内容分发问题；两者常常一起用，却不是同一种服务。如果页面必须根据当前用户实时生成，缓存也不能代替后面的业务程序。

安全产品则在同一条访问路径上分工。DDoS 防护主要应对试图用大量流量拖垮服务的攻击；WAF 检查针对 Web 应用的恶意请求；Bot Management 辨别自动化访问，帮助处理爬取、撞库或接口滥用。API Shield 等产品进一步面对接口本身的安全问题。一个网站即使没有宕机，也可能每天被程序反复登录、抓取或者消耗计算资源。把这些问题只叫作“防攻击”，会漏掉产品之间的差别。应用服务全景 ↗

这组产品容易成为客户的第一步：源站仍在原处，只把入口接进来，就能增加一些性能和安全能力。接入以后，日志、规则与流量分析也开始进入日常运维。实际效果仍取决于套餐、规则和应用的实现，开启代理并不能自动修复业务代码里的漏洞。

第二组：员工在任何地方，都只访问被允许的资源

公司内部的访问有另一套麻烦。员工在家里、办公室或路上工作，需要访问内部应用和外部 SaaS；把设备连进 VPN，只解决了“进入某个网络”，未必精确回答“这个人此刻能不能打开这个应用”。Cloudflare One 把身份、设备与网络策略放在一起，组织成 SASE 与 Zero Trust 产品。可以先把这两个术语理解为：通过云网络交付连接与安全，并且不因为设备已经在某个网络里，就默认信任它。Cloudflare One ↗

具体分工并不神秘。Access 决定谁能访问哪一个应用；Gateway 检查员工发出的 DNS、网络和 HTTP 流量；Cloudflare One Client 把设备接入网络；Tunnel 则由内部系统主动建立出站连接，把内部资源接出来。DLP 识别敏感数据，CASB 检查 SaaS 和云环境里的风险，Browser Isolation 把浏览器代码放在远端运行。这些名字之所以多，是因为身份、流量、数据和浏览器原本就是不同的控制对象。

当连接范围扩大到办公室、门店、数据中心和多个云，Cloudflare WAN 接手跨地点连接与路由。它是原来的 Magic WAN，不是 Access 的另一个名字：前者连地点和网络，后者决定人对应用的访问资格。企业可以把它们放进一套架构里，也仍需要做迁移、设备管理和策略梳理。Cloudflare 在这里面对的是 Zscaler、Palo Alto Networks 等安全与网络产品，而不只是 CDN 竞争对手。Cloudflare WAN ↗

第三组：开发者直接在网络上运行应用

第三组产品改变了 Cloudflare 与应用的关系。过去，它主要帮别人分发和保护应用；Workers 允许开发者直接把业务代码放进它的网络。一次请求到来，Worker 可以做身份验证、调用多个接口、生成网页，也可以直接返回一个 API 结果。应用不再一定需要在 Cloudflare 后面另放一台 Web 服务器。

与 AWS 放在一起看：面向 Web 和 AI 应用，已经“五脏俱全”

看到这里，再把 Cloudflare 理解成一家“给网站加速的公司”，就会低估它的变化。按 2026 年 8 月 28 日收盘口径，其市值约为 1,068 亿美元，确实是一家千亿美元量级的公司。不过，市值只能提供规模背景，不能用来衡量一套云平台能完成多少工作；AWS 也不是单独上市的公司，不能直接拿亚马逊的总市值当作 AWS 的市值比较。NET 市值与股本口径 ↗

Cloudflare 如今在官网直接使用 AI Cloud 的定位，强调构建、部署 AI 应用与 Agent，以及连接数据、模型和工具。这不是说它已经复制了一整套 AWS，而是它围绕一类越来越重要的开发任务，补齐了应用从上线到运行所需的主要能力。“麻雀虽小，五脏俱全”可以用来概括这个变化，但这里的“五脏”，指的是应用链路完整，而不是产品数量、算力规模和功能深度都与 AWS 相同。Cloudflare AI Cloud ↗

假设一个团队要做面向客户的知识库助手：用户上传资料、登录后提问，系统检索内容、调用模型，必要时由 Agent 查网页、运行代码或创建工单，最后把结果保存并推送回来。这个过程中，入口、程序、文件、数据库、检索、任务状态和安全控制，都能在 Cloudflare 的产品组合里找到位置。模型可以选择 Workers AI 支持的模型，也可以调用外部服务。团队不必为了补齐某个基础环节，先搭一整套服务器集群。这是依据上述产品能力整理的应用示例，不是对任意规模、合规要求和服务等级的承诺。

这是一张按工作职责整理的概括性对照，不是官方迁移矩阵，也不意味着同行中的服务在功能、容量、可用地域、SLA 或计费上等价。Cloudflare 产品说明见文末七类完整目录；AWS 链接列在对应行。产品及价格核对日期：2026 年 8 月 31 日。

因此，更准确的总结是：Cloudflare 已经足以承载许多常见 Web 和 AI 应用的核心基础设施，而不只是给这些应用的外部入口加一层 CDN。 内容产品、开发者工具、轻量 SaaS、知识库问答、客服助手，以及围绕 API 和网页操作的 Agent，都可以按这个方向评估。这里不宜笼统写成“覆盖大部分应用”：大型交易数据库、传统企业软件、特殊操作系统、持续高强度计算和大规模模型训练，会提出另一组要求。AWS 的优势恰恰包括这些更广的选择，而不只是产品目录更长。AWS 产品体系 ↗

完整的七类、67 项产品说明及各组总结，保留在文末产品目录。先理解应用需要完成哪些工作，再查具体产品，下面的技术与案例会更容易读。

Workers：为什么适合开发 AI 原生应用？

模型之外，还有一整个产品要运行

ChatGPT 让人们习惯向模型提问。但把模型做成一个真正能用的产品，还要回答许多普通的软件问题：用户怎么登录，文件放在哪里，回答怎样持续输出，任务中断后怎么办，调用失败去哪里查。Cloudflare 的 AI 机会，正好可以放回这条应用链里理解。

Workers AI、AI Gateway 和 Vectorize 分别负责模型推理、调用管理和向量检索。Workers AI 让开发者通过接口调用 Cloudflare GPU 网络上的模型；AI Gateway 位于应用与模型供应商之间，管理请求、日志、缓存、重试和回退；Vectorize 存储向量，通过语义相似度检索资料。请求经过 AI Gateway，不表示模型也运行在 Cloudflare；使用 Vectorize，也不等于 Cloudflare 在训练一个基础模型。Workers AI ↗AI Gateway ↗Vectorize ↗

以文档问答为例，原始文件可以保存在 R2，拆分后的文本转换成向量存入 Vectorize。用户提问时，Worker 先找相关段落，再把这些资料连同问题交给模型。若接入多家模型或需要追查失败请求，可以再使用 AI Gateway。这是一个可选的组合：只做一段文本摘要的小工具，直接调用模型就可能够用，不必为了“全栈”把所有产品都装上。

理解这件事，可以先想象一个企业知识助手。用户上传资料，提出问题；程序核对权限，检索相关内容，把材料交给模型，边生成边把答案传回页面。有时它还要查询工单、运行代码，或者等人批准后再执行。模型负责其中的推理，应用仍要负责把所有步骤可靠地接起来。Cloudflare 对 AI 原生应用的吸引力，主要在这层应用运行与编排：轻量计算、频繁网络调用、持续状态和工具访问，可以围绕 Workers 组织起来。

一个 Worker 里面，究竟有什么？

开发者上传代码和配置，不必先准备或维护服务器。一次 HTTP 请求到达后，Cloudflare 会运行代码里的 fetch(request, env, ctx)：request 带来用户的请求，env 提供数据库、存储桶等已经配置好的资源，ctx 可以安排不阻塞响应的后台任务；代码处理完毕，再返回一个 Response。开发者面对的仍是 Web 开发中熟悉的请求、响应和异步操作，而不是虚拟机、操作系统与服务器进程。请求处理入口 ↗

再往下看，是 Cloudflare 的 workerd 运行时与 V8 引擎。V8 也被 Chromium 和 Node.js 使用；Workers 用其中的 isolate，为不同程序提供隔离的执行上下文与内存。一个运行时实例可以承载许多 isolate，复用底层引擎，而不是为每个应用重复启动完整的语言进程。它的结构性收益，是降低小程序的启动与内存开销，让大量低频、突发的应用有机会共享服务器资源。Workers：isolate 与运行机制 ↗

isolate 也不是“一次请求配一个”。同一个 Worker 实例可以通过单线程事件循环处理多个并发请求：某个请求正在 await 模型或数据库时，运行时有机会处理其他请求。异步等待不必一直占着 CPU，但大量同步计算仍会占用执行时间。实例可能被回收，连续两次请求也不保证落到同一个实例，所以内存中的全局变量不能作为可靠的用户会话数据库。并发与分布式执行 ↗

这与 AWS 普通按需 Lambda 的区别，首先是运行环境的组织方式。Lambda 在需要新执行环境时，会准备环境、加载运行时和初始化应用；后续请求可以复用已经准备好的环境，并非每次调用都重新启动。Workers 的 isolate 减少了小应用重复初始化的开销，但不能因此保证所有真实请求都“零冷启动、零延迟”：代码初始化、路由与后端访问仍要花时间。AWS 也提供 Provisioned Concurrency 来预先准备执行环境。Lambda 生命周期与预置并发 ↗

AI 请求经常在等待，这改变了什么？

一个聊天或 Agent 请求，可能只用很短的 CPU 时间整理提示词、检查权限和解析结果，却要等待模型连续生成十几秒。这种“计算片段夹着网络等待”的负载，很适合异步事件模型。Workers Standard 的收费把请求次数与实际 CPU 时间分开计算，不对普通请求的整段墙钟时长另收费；墙钟时长就是用户从开始等到结束的时间。Workers 当前计费 ↗

举一个只说明计费机制的假设：同一次模型调用总共经历 15 秒，应用自身累计消耗 50 毫秒 CPU。普通 Worker 的 CPU 计量针对这 50 毫秒，再考虑请求费用；如果使用普通按需 Lambda，在函数里一直等待同一次模型返回，时长计费会覆盖这段调用存续时间，并结合配置内存计算 GB-seconds。这里的 15 秒与 50 毫秒不是实测，也不能直接换算成整套应用便宜多少倍。模型 token、数据库、存储等账单还在外面。Lambda 按需计费 ↗

同样的设计也适合流式响应。Worker 可以收到一段模型输出，就把这一段送给客户端，不必把整个答案缓存在内存里再返回；处理文件时也可以分块传递。节省的是应用层的等待与缓冲负担，模型本身的推理速度不会因此变快。Streams 与增量响应 ↗

比较到完整 Agent 系统时，需要换一把尺子。Cloudflare 的 Durable Objects 在活跃或不符合休眠条件时，仍有按时长计算的费用；AWS AgentCore Runtime 则按实际 CPU 消耗和会话内存计费，没有 CPU 消耗的模型等待不收 CPU 费。Lambda Durable Functions 也可以通过显式等待操作暂停执行，不在暂停期间收取按需计算时长费。这与普通函数里一直 await 一个网络请求并不是同一种机制。因此，Cloudflare 的优势应放在具体架构里看，不能扩大成“AWS 的 Agent 都为等待付费”。DO 计费 ↗ AgentCore 计费 ↗ Lambda 持久执行 ↗

从一段函数到完整应用，还需要数据与状态

只有函数还不够。一个能长期使用的产品，需要保存用户、文件、会话和任务状态。Cloudflare 给出了几种不同的工具；它们不应该都被笼统称为“数据库”。文件与订单记录、配置与聊天室状态，对数据的要求完全不同。

R2 的优势很容易用产品语言解释。假设用户上传一个大文件，之后会被反复下载、处理，或者交给另一家服务使用，出口带宽就可能成为一笔持续成本。R2 不收这项出口费，减少了文件留在 Cloudflare 后“不方便拿走”的负担。它并不是免费网盘：存储、操作和特定存储类别的数据取回仍可能收费。R2 计费边界 ↗

D1 让熟悉 SQL 的开发者继续用表来组织业务；KV 更适合频繁读取、不要求每次写入立刻全局可见的内容；Durable Objects 则适合让一个确定的对象负责某段状态，例如一个多人房间的连接和协作。如果把余额、库存等严格依赖即时一致的数据直接丢进 KV，就误解了产品的设计。全球网络并没有让一致性和延迟的取舍消失。D1 ↗KV ↗Durable Objects ↗

Queues 和 Workflows 处理“这件事不能挤在一次网页请求里完成”的情况。导出报告、转码、长时间分析可以异步进行；跨多个步骤的流程还可能需要重试、等待用户确认，再继续。Queues 采用至少一次交付，可靠送达不代表只送一次，发邮件或写入订单时仍要处理重复任务。Containers 与 Sandboxes 则把完整运行环境接到 Workers 后面，适合执行 Linux 工具或隔离代码；它们在 2026 年 4 月已经正式可用，但容器休眠再启动后的本地磁盘不能被当作永久文件系统。Queues ↗Workflows ↗Containers / Sandboxes GA ↗容器与磁盘 ↗

从能聊天，到能办事：这些组件怎样形成优势？

回到那个知识助手。它如果只回答一次问题，普通 Worker 调用模型、流式返回就够了；一旦开始替用户办事，就需要知道任务上次停在哪里，哪一步已获批准，哪个工具已经执行成功。Durable Objects 给这类状态一个确定的归属：来自不同地点的请求，可以通过同一个对象标识找到同一份状态与处理逻辑。计算与附带的持久存储放在一起，有助于减少“读状态—协调更新—再写回”之间的接线工作。Durable Objects 的计算与状态模型 ↗

Agents SDK 在这些基础能力之上提供会话、状态同步和任务调度等工具。应用可以按用户、会话或工作区划分对象，不必从零搭建整套实时状态管理。但一个对象不会自动变成全世界同时运行的多个主节点，单个热门对象也不会因为全球网络而无限扩容；划分粒度、持久化与业务权限仍然要设计。长任务还应脱离浏览器的一次连接：普通 HTTP Worker 的执行依赖请求生命周期，断开连接后的短暂延续不能替代可靠的后台工作流。Agents SDK 的基础能力 ↗请求生命周期限制 ↗

平台内部的连接方式也有影响。一个 Worker 可以通过 Service binding 调用另一个 Worker 的方法，不必先给内部服务暴露公网 URL。于是身份检查、受控工具调用和业务逻辑可以分开维护，再由明确的绑定连接。这对 Agent 尤其有用：让它获得一组限定操作的接口，比把一把权限很大的密钥直接交给生成代码更容易控制。绑定只决定它能接触哪个服务，服务内部仍须校验用户、资源范围和具体动作。Service bindings 与内部调用 ↗

网络位置则需要分两头考虑。入口靠近用户，适合较早完成身份检查、限流和响应；如果一个 Worker 反复查询远端数据库，把计算放得离用户近，反而可能增加多次跨洲往返。Cloudflare 提供 Placement 来调整运行位置；其中 Smart Placement 会评估特定请求处理路径，必要时把执行转到更接近后端的位置。它不是自动让所有数据全球本地化，也不表示对象存储、Durable Object 和模型都在同一台机器上。运行位置与适用限制 ↗

从研发体验看，吸引人的地方在于这些能力能进入同一个项目工作流。开发者先把问答功能跑起来，再增加文件、状态、审批与工具，不必每加一层都从头选择服务器、部署方式和资源连接方法。后面的 Vite 与 Wrangler 章节，正好解释这一点如何落实到本地开发、测试、发布和排障。对小团队而言，少做一部分基础设施集成，往往与节省一笔运行费同样重要；这是产品组合带来的价值，不能单靠某一项 CPU 单价衡量。

Agent 多出来的，是状态、工具和持续执行

一个问答页面往往在模型返回文字后就结束了；Agent 可能还要查询订单、修改文件、运行程序，遇到关键动作等待人确认，然后继续。Agents SDK 提供会话状态、实时连接、定时任务、存储和恢复执行的基础，Browser、Sandbox 与 MCP 接口分别接入浏览器、隔离代码执行和外部工具。业务方仍要决定 Agent 能做什么，哪些动作需要批准。SDK 并不自动解决权限和业务正确性。Agents SDK ↗

与 AWS 比，哪些优势最值得抓住？

AWS 也能构建上述系统，而且有 CloudFront Functions、Lambda@Edge 等边缘能力。区别不在“Cloudflare 有全球网络、AWS 没有”，而在应用围绕什么默认路径组织：Cloudflare 把 Web 请求、轻量运行环境、绑定和状态服务紧密接在一起；AWS 则可以按负载选择 Lambda、AgentCore、容器与专用计算。下面是面向研发选型的判断，不是两家公司所有产品的性能排名。AWS 的边缘函数选择 ↗

表中的成本机制来自两家官方文档，组合价值与选型倾向是本文分析。Managed Instances 等模式允许在受管实例中并发处理请求，不能沿用普通 Lambda 的逐次时长费公式；R2 的免出口费也不等于对象存储和操作免费。Lambda Managed Instances ↗R2 计费 ↗

另一侧的边界也很具体。普通 Worker 的内存上限是每个 isolate 128 MB，包含 JavaScript 堆和 WebAssembly 分配，并不是每次请求各有 128 MB；Node.js 兼容层覆盖部分 API，不能把任意依赖本地二进制与完整系统环境的程序原封不动搬过来。大型文档解析、复杂 Python 依赖或持续重计算，可以调用 Sandbox、Containers 或外部服务，但到这一步，运行方式与成本就要重新评估。Workers 内存限制 ↗Node.js 兼容范围 ↗

如果目标是自己训练模型、管理 GPU 推理集群，AWS 的 EC2 GPU 实例等资源应当进入比较，而不是拿它们与一个普通 Worker 对照。反过来，若模型通过 API 提供，团队真正要做的是把资料、用户、状态和工具组织成可靠产品，Cloudflare 的优势就更集中：它让一组常见的 AI 应用需求，在相对一致的开发与运行体系里落地。对于已经把数据和运维深度放在 AWS 的企业，继续复用现有环境也可能更省事。AWS GPU 计算的用途 ↗

因此，本文最看重的并非“每一项技术都独有”。V8 是开放的技术，异步执行、边缘计算和按需计费也不只有一家提供。Cloudflare 值得研究的，是把这些机制与已有网络、数据服务和开发工具组合起来，争取成为 AI 应用从原型走向日常运行时的一条顺手路径。它能不能持续赢得开发者，要看这条路径是否真的减少了工作、能否可靠运行，而不仅是发布了多少新产品。

一个工单 Agent，怎样变成每天都能用的系统？

Cloudflare 自己就是一个现成的例子。2026 年 8 月，CIO Sam Rhea 公开介绍了内部使用的 Cloudflare OS。其中一个任务很普通：每天查看 IT 工单，了解积压情况，画出服务指标，并处理隔夜收到的问题。过去，他需要导出 CSV、放进表格，再逐条查看工单；第一版 AI 工作区把这些操作交给了连接工单系统的 Agent，但每天仍要重新消耗模型 token，生成一份内容大同小异的报告。CIO 的实际使用案例 ↗

第二版换了一种做法：让 Agent 把取数、统计和画图写成一个小应用。日常打开仪表盘时，由代码完成确定的工作；需要回复工单时，再调用模型生成草稿，由人审阅并发送。这个案例最值得看的地方，是 Agent 不只回答了一个问题，还留下了一套可以反复使用的软件。

Cloudflare OS 已公布源码。它不是电脑操作系统，而是企业内部的 AI 工作区：结合组织的资料和技能，让员工创建文档、应用与自动化。公开的 v2 仓库仍标注 early access。下面按官方产品说明与代码仓库简化绘图，展示这套系统的主要关系，不补画未披露的生产部署细节。官方源码与开放状态 ↗

把工单 Agent 拆开看：每一层分别做什么

员工先通过 Access 进入工作区。Agent 结合组织提供的资料，编写应用的界面和后端；需要模型时，请求经过 AI Gateway。工作区保存持续修改所需的状态，生成的小应用则有自己的逻辑和数据。同一个 Agent 可以先帮你做出工单仪表盘，之后再按反馈加一列指标、改一种图表，不必每次都从空白对话重新开始。

应用后端按需加载为 Dynamic Worker，并通过 Durable Object Facet 拥有隔离的 SQLite 状态。Facet 可以先理解为小应用自己的状态与执行单元：不同应用不必共用一张大表，也不需要各自长期占着一台服务器。Dynamic Workers 使用轻量的 V8 隔离环境，适合这类代码与接口逻辑，但不能直接等同于一台能安装任意软件的 Linux 主机。Dynamic Workers ↗工作区与 Gadget 架构 ↗

Gatekeeper 解决另一件事：谁有权读哪份数据，谁能执行什么操作。它是服务专用的 Worker，保管凭证，把经过限制的接口交给 Agent 和应用。生成的代码拿到的是使用某项资源的能力，不是一把任意调用企业系统的 API key。分享应用时，还要检查接收者对相关原始资源的权限，不能因为别人发来一个仪表盘，就看见本来无权访问的数据。Gatekeeper 与数据权限 ↗

这也解释了网络、安全与开发者产品为什么会出现在同一套 Agent 系统里。模型生成草稿只是其中一个动作；在它前后，还需要身份验证、授权的数据读取、隔离执行、保存状态和人工确认。安全控制由平台服务执行，不能只在提示词里嘱咐模型“请勿越权”。

技术组合的证据，不等于商业成功的证据

Cloudflare OS 在这里更适合作为一个官方参考应用：它把 Workers、状态存储、身份验证和安全控制组合成了完整的 AI 工作台，让人看到这些产品怎样一起工作。开发者可以参考它的架构和源码，企业采购也能据此理解这套平台能承载什么，以及接入自己的系统还要完成哪些配置。它的价值首先是把产品目录里的能力变成一个可以研究、使用和修改的系统。官方产品与架构说明 ↗

这个应用来自 Cloudflare 自己的内部需求，因此不只是为演示而拼装的样品；但内部使用经验，也不能直接当作外部市场已经接受它的证据。尤其是公开的 v2 仍处于 early access，能部署、能使用，与企业愿意长期采用、持续付费，是不同的事情。源码与当前开放状态 ↗

从商业角度看，即使它可能带动底层云服务的使用，也不能仅凭内部案例和开源发布，就认定新增收入已经形成规模。要判断这一点，还需要外部客户的采用、持续使用及相关付费用量数据。因而，本文用 Cloudflare OS 说明技术组合如何落地，不把它作为独立收入业务或新增长点已经成立的证据。

Wrangler：把开发者平台交到人和 Agent 手里

Wrangler，把资源能力接到日常操作上

产品目录越长，未必越好用。如果每增加一个数据库、存储桶或队列，都要重新学习一套控制台、授权方式和发布流程，丰富的功能反而会成为负担。Wrangler 的价值，就在于把 Workers 周围的大量操作收进同一个命令行入口：写代码的人，可以在项目所在的终端里完成开发、资源管理、部署和排障。Wrangler 官方介绍 ↗

它不是一个只负责“上传代码”的按钮。以一个有文件、有数据记录、有后台任务的应用为例，Workers 处理请求，D1 保存记录，R2 保存文件，Queues 接走耗时任务。Wrangler 可以分别管理这些资源，也能读取同一份项目配置，把它们交给应用使用。对开发者来说，学会一种组织项目的方法，后面增加能力时就有一部分经验可以沿用。

为什么一个命令行，能操作这么多东西？

首先，Wrangler 把不同产品的管理接口组织成了同一套工具。执行 wrangler d1 时处理数据库，执行 wrangler r2 时处理对象存储，执行 wrangler queues 时处理队列。底层仍然是不同服务，但账号认证、项目位置和配置可以沿用，而不是每次从另一套部署工具重新开始。这个统一入口主要围绕开发者平台，并不意味着 Cloudflare 所有安全与网络设置都由 Wrangler 包办。

更重要的是 binding，也就是“绑定”。在 wrangler.jsonc 中，开发者可以声明这个应用要使用哪个数据库、哪个桶、哪个队列；进入业务代码后，它们就成为 env.DB、env.FILES、env.JOBS 这样的对象。调用资源的方法与访问能力被放在一起，Worker 不必为了访问这些已绑定的 Cloudflare 资源，再保存一套账户级密钥。这里减少的既是接线工作，也是一部分凭证管理负担。Binding：接口与资源访问能力 ↗

现在，它还可以把一部分创建资源的步骤接过去。官方的自动资源创建功能仍标注 Beta，已支持 KV、R2、D1、Queues 等：在配置里声明绑定而不填写已有资源 ID，运行 wrangler dev 可以创建本地开发资源，运行 wrangler deploy 可以创建云端资源，并把 ID 写回配置。开发者不一定要先去控制台逐个建立资源、复制编号，再回来发布代码。自动资源创建与支持范围 ↗

从本地试跑，到线上排障，都留在同一个工作过程里

这套体验可以沿着一个应用的生命周期理解。先用 dev 在本地试跑，修改代码以后立即检查结果；需要看数据库、放测试文件或准备后台任务时，使用对应子命令；准备好以后 deploy，再用 tail 看线上请求是否报错。出现代码问题，还可以选择已有版本回滚。命令之间的连续性，比单独节省一次鼠标点击更重要。

表中资源名是示例，命令用于解释能力，并非一份可以不加配置直接运行的脚本。资源创建、发布与回滚都会改变云端状态，应先确认账号、环境和权限。命令来源：Workers、D1、R2、Queues、Secrets与回滚边界。

Wrangler 能统一操作，并不是因为权限被取消了。终端中的工具先通过 OAuth 或 API token 获得管理权限，应用运行时则通过 binding 获得指定资源能力。数据库该有哪些表、队列收到任务后如何处理、用户能读哪份文件，仍由应用决定。减少的是重复配置和工具切换，不是让开发者不再理解数据与权限。Wrangler 认证 ↗队列与应用连接 ↗

对 coding agent，命令行是从“写完”走到“跑起来”的接口

**这种设计在 AI 编程时代更容易显出价值。**一个 coding agent 可以编辑代码和配置，启动本地服务，读取失败信息，再修改并重试；获得相应授权后，还能部署、查看线上日志。它不必为每一项操作识别一遍网页按钮。人也可以检查它改了哪些文件、准备执行什么命令。对不熟悉云平台的人来说，Agent 负责把意图翻译成代码，Wrangler 则为接下来的运行和部署提供共同入口。

放进 Codex 之后，命令行就成了可以直接调用的操作入口

以 Codex 为例，只要项目具备所需工具，并允许 Agent 执行终端命令，Wrangler 就能进入它的工作过程：读取 wrangler.jsonc 或 wrangler.toml，调用 wrangler dev 试跑，查看输出，修改配置，再用 wrangler deploy --dry-run 检查部署产物。在获得部署授权和相应账户权限后，同一套工具还可以把应用发到云端。用户不必先熟悉 Cloudflare 控制台的每个菜单，也不必把 Agent 给出的命令逐条搬到另一个窗口。这种接口减少了从“代码写好了”到“我能打开它”的操作负担。Cloudflare 官方入门文档也已将 Codex 列为通过提示词构建 Workers 应用的入口之一。支持 Codex 的官方指引 ↗ · 公开的 Codex / Wrangler 调用记录 ↗

临时部署进一步缩短了第一次体验。通过 wrangler deploy --temporary，未认证的 Agent 可以发布一个有效 60 分钟的临时 Worker，检查效果，再把认领链接交给用户。先看到能用的东西，再决定是否继续，比一开始就完成整套生产配置更容易起步。正式运行仍需要账户；临时账户也只支持指定资源，当前不包括 R2。临时部署与资源限制 ↗

一个真实过程：在 Codex 里做出链接跳转查询工具

2026 年 6 月 21 日，Simon Willison 记录了一次这样的尝试。他在 Codex Desktop 中使用 GPT-5.5 xhigh，做了一个小工具：粘贴网址后，显示它依次经过哪些 HTTP 跳转、最后落到哪里。公开对话显示，Codex 创建了 Worker 代码和 Wrangler 配置，运行类型检查、启动本地服务，并执行部署预检；当他询问临时部署怎样使用时，Codex 又查看命令帮助，实际运行 npx wrangler deploy --temporary --dry-run，再给出发布命令。应用源码与初始需求 ↗ · 对话与命令记录 ↗

公开对话记录的是开发、测试与部署预检；临时发布成功，则由他随后在博客中确认。他的评价很直接：“The temporary deployment worked as advertised.”——临时部署确实如介绍所说，可以正常工作。这个过程把 Wrangler 的价值落到了实处：Codex 不只告诉用户应该怎么做，还能调用工具完成中间步骤，把可运行的项目和可执行的部署命令交到用户手里。Simon 的亲历记录，2026-06-21 ↗

三个经历各有侧重：Simon 的公开记录说明 Codex 怎样实际调用 Wrangler，新手的帖子描述命令行部署的直接感受，照片站则让人看到非工程师怎样借助 Agent 完成一个自己的项目。它们不代表整体用户的成功率，却把“降低学习与使用成本”变成了可以理解的具体过程：人更少被卡在操作步骤上，Agent 有工具把这些步骤继续执行下去。

因此，Wrangler 的优势不在“别人没有命令行”——AWS 和 Vercel 都有成熟工具——而在它将 Cloudflare 的运行时、资源绑定、本地体验与发布运维接成了一条较短的路径。相同的项目文件和命令既能由人操作，也能进入 CI/CD 和 Agent 的工作过程。这是产品降低学习与使用成本的一种具体方式。

从 Vite 到 Wrangler：接通开发与部署

Workers 解决了“代码放在哪里运行”，但开发者通常不会从这个问题开始。更常见的起点是：选一个熟悉的框架，创建项目，在电脑上修改页面、调试接口，确认能用以后，再决定如何上线。谁让前面这些步骤顺手，谁就更有机会影响最后的部署选择。这是理解 Cloudflare 收购 VoidZero 的一个重要角度。

收购 VoidZero，补的是 Workers 前面的那段路

严格说，Cloudflare 收购的是公司 VoidZero，不是把 Vite 这个开源项目变成自己的独占产品。2026 年 6 月的公告确认，尤雨溪与团队加入 Cloudflare；Vite、Vitest、Rolldown、Oxc 和 Vite+ 继续开源，保留 MIT 许可与供应商中立的方向。这项承诺关系到收购的价值：如果工具只能服务一家云，原来围绕它建立的广泛生态就可能被削弱。Cloudflare 收购与开源承诺 ↗

它确实能补强 Workers，但首先补强的是开发平台的完整性，而非给运行时直接增加算力。 Workers 与 workerd 负责执行程序；VoidZero 的工具处理程序运行以前的事情——组织开发过程、转换与打包代码、执行测试。前者回答“能不能运行”，后者影响“开发者能不能轻松做出来、反复修改，并放心部署”。一个平台即使运行成本有吸引力，如果迁移和调试过于费劲，也很难成为开发者的日常选择。

表格按职责区分，并非要求每个项目安装全部工具，也不是五个必须串行执行的步骤。Vite+ 组织多种工具的使用，具体项目可以选用不同组合。Vite 文档 ↗Vitest 文档 ↗Rolldown ↗Oxc ↗Vite+ ↗

这套整合已经有一个很具体的落点：Cloudflare Vite 插件。开发者运行 vite dev 时，插件可以让服务端 Worker 代码进入 workerd，并使用运行时 API 与资源绑定；前端仍保留熟悉的热更新体验。这样，开发时不必完全依赖另一种服务端运行环境，到发布时才发现接口不兼容。它尽量贴近生产运行方式，但本地模拟仍不能复现全球网络、真实负载和所有服务行为。Vite 插件：现有能力与运行方式 ↗

例如，一个有上传功能的应用，前端负责选文件和展示结果，Worker 处理身份与请求，R2 存文件，D1 存记录。Vite 及相关工具帮助开发者修改和检查代码，插件让服务端逻辑在接近目标平台的环境中试跑，Wrangler 再处理资源配置与部署。这是一个说明分工的例子：收购带来的机会，是减少这些步骤之间的接缝，而不是让 Vite 自己变成数据库，或让已有 Worker 突然跑得更快。

代码已经开源，为什么还值得收购？

双方在收购前就合作过。按 Cloudflare 的介绍，围绕 Vite Environment API 的合作从 2024 年开始，它让开发工具可以连接不同服务端运行时，Cloudflare 插件正是其中一个应用。因此，“为了得到一个能部署 Workers 的插件”不足以解释这笔交易：这个连接此前已经存在。双方合作与技术路线 ↗

更有解释力的线索，来自尤雨溪自己的公告。他坦言，工具采用量快速增长，商业化却没有解决。团队尝试过 Vite+ 的混合许可，后来将其按 MIT 许可开放，并开始做基于 Cloudflare 的部署平台 Void。但这又要求有限的团队同时经营工具链和云平台，两种业务需要不同专长，可规模化收入仍然遥远。VoidZero 创始人对商业化的说明 ↗

由此可以作出一个战略判断：VoidZero 有开发者熟悉的入口，Cloudflare 有能够持续收费的基础设施，两者互补。 对工具团队而言，不必从头再建一套完整云业务；对 Cloudflare 而言，收购带来的核心团队与长期协作能力，可以支持它持续改进框架适配、开发体验和部署流程。开源许可允许它使用代码，却不能让它仅靠复制仓库，就获得原团队的维护经验、生态关系和研发投入。

这条商业路径也比较容易理解。开发者使用免费的工具开始项目，觉得在 Cloudflare 上调试与部署很顺手，便可能把应用放到 Workers；应用投入使用以后，计算、存储与数据库操作才逐渐形成账单。这里的判断不是“卖 Vite 许可证”，而是用更好的开发体验争取云端用量。工具下载量、项目数量和付费客户仍是三件不同的事；开源用户不会因为收购就自动成为 Cloudflare 的客户。

AI 放大开发循环，Cloudflare 争取成为顺手的部署去处

AI 编程让这套工具链多了一类高频使用者。一个 coding agent 可能不断修改、构建、运行测试，读错误后再改。每轮反馈越快，环境之间的差异越少，它就越容易完成整个任务。这首先改善的是开发循环；能否进一步降低完整任务的时间与成本，还取决于模型调用、代码质量和失败重试，不能从某个打包工具的速度直接推导出来。

Cloudflare 在 6 月的公告中给出了相应方向：以 Vite 为基础改进应用 CLI，让开发、构建与部署更连贯；当时新统一 CLI cf 处于技术预览阶段。公告也提出按应用声明自动配置基础设施的方向。这些是收购时公开的路线图，不能一概当作已经兑现的功能；前文仍以已有文档支持的 Wrangler 能力解释今天能做什么。应用 CLI 的演进方向 ↗基础设施集成计划 ↗

从竞争看，Cloudflare 正在向应用开发的更早阶段靠近。过去，开发者可能先完成框架与托管平台选择，最后才考虑要不要加 CDN 或对象存储。Vite 让 Cloudflare 有机会在项目刚开始时就提供一条可选的开发与部署路径。这会让它与 Vercel 的竞争更直接，不过机会来自整合体验，而非独占开源入口：同一套工具仍可服务别的云平台，竞争者也能受益。

因此，我更愿意把这笔收购理解为一次开发者平台建设：把全球运行资源，接到开发者已经熟悉的工作方式上。它的回报最终要落在更多应用愿意长期运行于此，而不只是发布时获得关注。开源中立则是必须保留的约束——社区信任被损害，入口本身也会缩水。Cloudflare 要争取的是“用起来顺手，所以选择这里”，而非让开发者失去其他选择。

与 Vercel 比，差别在开发路径，而非能否做全栈

Vercel 同样能承载完整的 AI 应用，把它理解为“只托管前端”已经不准确。它围绕 Next.js、Git 提交、预览部署与框架优化组织开发体验；AI SDK 帮开发者处理生成、流式输出和工具调用，AI Gateway 管理模型接入。这条路径很贴近“先把应用写出来，再顺畅上线”的日常开发习惯。Vercel / Next.js ↗AI SDK 与 Gateway ↗

Cloudflare 原有的特点，更容易从网络和运行资源的组合看出来：Worker 接请求，R2 放文件，D1 放记录，安全与身份服务管理访问。收购 VoidZero 后，它又向开发工具与框架体验这一侧延伸，试图把这组资源接到开发者熟悉的 Vite 工作流程上。两家公司争取的都包括应用刚开始时的选择，而不只是最后托管在哪里；区别在于它们各自已有的产品组合与整合路径。Cloudflare 的 Vite 整合方向 ↗

如果产品大量处理上传、下载、长任务或 Agent 工具，Cloudflare 的数据与执行组件就不只是托管页面的附属功能。开发者也不必二选一：可以使用 Vercel AI SDK 写程序，用其他模型，再把某些资源放在 Cloudflare。Vite 保持供应商中立，也意味着它的生态采用量不能直接算作 Cloudflare 的市场份额。

实际迁移仍然要看框架兼容性。Cloudflare 在 2026 年 8 月更新的 Next.js 指南默认推荐 vinext，但它仍是 beta，需要另行检查生产兼容性，OpenNext 则是另一条现有路径。不能因此认为所有 Next.js 应用都能毫无变化地搬过去。产品介绍里保留这些细节，比简单评出“谁替代谁”更接近开发者会遇到的问题。Cloudflare 的 Next.js 路径 ↗

下载量，让开发者生态的变化有了一个可观察的数字

npm 官方下载接口显示，wrangler 在 2026 年 8 月 24—30 日这个完整周被下载 20,201,554 次，约 2,020.2 万次。一年前对应周为 173.9 万次，最新值约为其 11.6 倍。下面使用 2025 年 8 月 25 日至 2026 年 8 月 30 日的全部每日数据，按周一至周日汇总为连续 53 周，保留期间的增长与回落。

这个变化与 Cloudflare 越来越多地出现在应用开发流程里的方向一致。不过，下载量统计的是软件包获取次数：同一个开发者、自动构建服务、镜像和机器人，都可能多次贡献下载；命中本地缓存时又未必产生新下载。它是工具传播和自动化活动的信号，不是“新增了两千万名开发者”，也不能单独推导收入或把增幅全归给 AI。npm 官方统计口径 ↗

免费不是终点：从第一次试用，到更大的客户关系

前面讲的免费工具、简化配置和临时部署，降低的是“愿不愿意试一下”的门槛。对 Cloudflare 来说，接下来的问题是：这些尝试能否留下来，变成长期使用和付费？一个团队可以先用免费能力处理一小部分需求，再按用量或新增功能付费；需求变复杂之后，也可能购买更多产品、签订企业合同。这是一条可能的扩张路径，不是每个客户都必须走过的固定阶梯。

免费转小额付费，已经有直接披露

2025 年第四季度，Cloudflare 约有 33.2 万付费客户，环比增加近 3.7 万，同比增长 40%。在 2026 年 2 月的业绩电话会上，CFO 明确说，这轮增长包括从免费套餐升级为小额付费账户的客户，尤其是在开发者平台。这是“免费入口能带来付费”的直接管理层证据；他没有说全部新增客户都来自免费转化，也没有给出其中的具体比例。这里保留该历史季度，是为了说明转化环节，并不把 33.2 万当作今天的客户总数。2025 Q4 官方电话会实录 ↗

企业采购则不只靠自助升级。2026 年二季度的 10-Q 写明，上半年收入的绝大部分来自通过内部及外勤销售团队获得的签约客户。小团队可以先刷卡购买，企业还要处理采购、权限、服务承诺和迁移。因而更接近现实的打法是：低门槛产品带来尝试，已有客户扩大用量与产品组合，销售团队参与较大的合同，而不是所有免费账户自动长成大客户。客户拓展与销售模式 ↗

从降低门槛，到产品破圈：财报里看到了什么？

“产品做得好”在这里可以拆成很具体的事情：常用能力准备齐全，新增资源能沿用熟悉的配置，第一次运行和发布不需要跨过太多步骤。这些设计有助于降低学习与操作成本，让使用者从管理网站的技术团队，扩展到独立开发者、应用团队，以及借助 coding agent 做工具的人。破圈的关键不只是别人听说过 Cloudflare，而是原本不会把应用放在这里的人，现在也能开始尝试。

在最新财报中，这条逻辑有两端可以观察。2026 年 8 月 6 日，CEO 在第二季度财报新闻稿中表示，总付费客户、大客户和平台开发者的增长均创纪录。这是管理层对用户入口扩大的描述；这份新闻稿并未同时给出开发者新增人数或“纪录”的完整比较口径。2026 Q2 财报与管理层表述 ↗

同日的业绩电话会提供了新闻稿之外的数字：CEO 表示，二季度增加超过 8 万付费客户，付费客户数量同比增长 74%；平台开发者超过 740 万，其中近 200 万在二季度加入，超过 2025 全年新增的 150 万。这些数字来自管理层电话会的公开实录转载，并非 10-Q 的客户表格；开发者人数也不能直接当作活跃开发者、付费账户或独立应用数。它们与 npm 下载量一起，分别观察工具传播、平台加入和开始付费，不能互相替代。2026 Q2 电话会：采用与付费增长（实录转载）↗

付费之后，客户是否继续扩大使用？

另一端，是客户使用的深度。第二季度的大客户数从一年前的 3,712 增至 4,698，增加 986，约增长 27%；美元净留存率从 114% 升至 120%。后一个数字意味着，按照公司的统计口径，同一批原有付费客户的年化收入，计入缩减和流失后仍比一年前高出 20%。前者显示更多客户进入较高消费层级，后者显示已有客户的收入贡献继续扩大。2026 Q2 10-Q：客户与净留存 ↗

大客户按当季收入乘四超过 10 万美元定义，并非合同 ARR，企业的独立业务单元也可能分别计数。净留存率不是客户人数留存率或免费转付费率。2026 年起，公司不再将总付费客户数列为披露的关键指标，这里不反推最新总人数。

净留存率还有一个容易忽略的边界：公司明确排除了观察期间免费客户升级付费带来的贡献，也排除了新客户和专业服务。因此，120% 观察的是原有付费客户在扩张、缩减和流失相抵之后的变化，不是用新进来的小账户把数字抬高。在同一批原有付费客户之外，免费转化与新增客户属于另一部分增长。净留存率定义 ↗

管理层在二季度电话会上还说，大客户贡献了当季收入的 73%，去年同期为 71%。这让数量变化有了业务上的分量：大客户不只是名单变长，还是主要收入来源。但现有披露没有告诉我们，这 4,698 家中多少最初使用免费套餐，也没有把同比增加的 986 家拆成新签客户和原有客户跨过门槛两部分。大客户收入贡献（电话会实录转载）↗

没有付费的用户，为什么也值得服务？

免费用户的价值不只有未来付款。公司在二季度 10-Q 中解释，他们带来品牌传播与产品反馈，让平台更早接触多样的流量、威胁和运行问题；更大的网络规模与流量多样性，也有助于运营商互联及带宽、机房合作。开发者在小项目中熟悉产品后，可能把经验带到其他项目；这是产品传播的机制分析，不是已经披露的转化率。免费客户在业务中的作用 ↗

但免费服务仍有成本，公司同时提醒，绝大多数免费客户历史上并未转为付费，并预计未来仍会如此。因此，它并不是靠把每一个免费用户都收费来成立。应当分别观察入口能否吸引人、付费客户能否扩大使用、企业产品能否形成更大的合同。现有资料为这些环节提供了证据，却没有公开一份“免费账户一路成长为大客户”的完整追踪表。免费策略的成本与限制 ↗

把产品和数据合起来，比较有解释力的路径是：功能更完整、资源更容易接起来，有助于扩大愿意尝试的使用者范围；当应用留下来，并逐步增加存储、数据库、安全或更多执行任务，使用也可能从一次实验延伸为长期业务。Wrangler 下载增长与财报中的客户扩展，为这条产品逻辑提供了相互呼应的现象。公开数据尚不能确定 CLI 对增长的具体贡献，销售、定价、流量增长和其他产品同样会起作用；但它已经值得从“一个网站加速工具”，改用“越来越容易被拿来构建应用的平台”来理解。

把产品和股价放回同一条时间线

下面这条线从 ChatGPT 向公众开放的 2022 年 11 月 30 日开始。NET 当日收盘 $49.14，到 2026-08-28 为 $299.84。这段期间，Cloudflare 将推理、检索、模型网关、Agent 执行和内容访问规则接进了产品体系，市场对公司的理解也在反复变化。

价格可以告诉我们市场什么时候兴奋、什么时候失望，却不能单独证明某个产品已经成功。新功能的使用和收入通常要慢慢积累，股价却会同时回应财报、销售执行、组织调整、利率和整体市场。这里因此保留产品发布、经营波折与重大故障三类节点，让两条线并排出现，而不把每个涨跌都写成一个产品的功劳。

早期几段尤其能说明这种不同步：2023 年，Cloudflare 一边发布 AI 推理产品，一边经历收入指引下调；2024 年，先前的测试产品开始正式可用；到了 2025 年，Agent 和远程工具接入变得具体，网站内容访问也开始出现收费机制。2026 年的合作与支付产品延续了这条路线，但其中既有已经可用的组件，也有研究、测试和预约阶段的能力。

1. 202211 / 3001
   行业背景 · 研究预览

   ChatGPT 上线：新的应用入口出现

   OpenAI 以研究预览形式发布 ChatGPT。人们可以直接通过对话测试模型，包括写代码、改写文字和提问。这是时间线的行业起点，当时 Cloudflare 尚未发布后来的 Workers AI 三件套。

   2022-11-30 收盘 $49.14 ↗

   事件来源 ↗

2. 202304 / 2702
   公司 / 经营 · 经营披露

   产品之外，销售执行也要过关

   Cloudflare 一季度收入增长 37%，但公司指出销售周期明显拉长，并下调全年收入展望。股价在下一交易日收于 47.05 美元。产品路线并不会自动变成平滑的经营曲线。

   公告日与图中价格日不同；价格取 2023-04-28 常规收盘。

   2023-04-28 收盘 $47.05 · 单日 -21.03% ↗

   事件来源 ↗ · 补充来源 ↗

3. 202309 / 2703
   产品 · 产品发布 / 早期测试

   推理、检索、网关：AI 三件套成形

   Workers AI、Vectorize 与 AI Gateway 同日登场，分别负责模型推理、向量检索和模型调用管理。Cloudflare 开始把全球网络与开发者平台组合成 AI 应用的基础设施。

   2023-09-27 收盘 $60.54 ↗

   事件来源 ↗ · 补充来源 ↗

4. 202404 / 0204
   产品 · Workers AI 正式可用

   Workers AI 与 D1 进入正式可用阶段

   Workers AI 进入正式可用阶段；前一天，D1 数据库也已 GA。推理与业务数据逐步齐备，Cloudflare 能承担的任务从网站加速，继续延伸到应用运行。

   2024-04-02 收盘 $94.97 ↗

   事件来源 ↗ · 补充来源 ↗

5. 202409 / 2305
   产品 · 分析与控制可用

   AI Audit：站长开始看清谁在抓取

   网站经营者可以查看 AI 爬虫来访、访问页面与频率，并决定允许或阻止哪些爬虫。Cloudflare 开始把原有流量控制能力，转成专门面向 AI 内容访问的工具。

   2024-09-23 收盘 $85.61 ↗

   事件来源 ↗

6. 202503 / 2506
   产品 · 远程 MCP 支持发布

   MCP 上云：让 Agent 连到真实服务

   Cloudflare 推出远程 MCP 服务器部署能力，用 OAuth、McpAgent 等组件处理授权和通信。结合此前发布的 Agents SDK，开发者可以把服务开放给 AI 助手，而不必让每位用户先安装本地服务器。

   2025-03-25 收盘 $127.50 ↗

   事件来源 ↗ · 补充来源 ↗

7. 202507 / 0107
   产品 · 控制可用 / 收费私测

   AI 抓取进入“先获许可”阶段

   Cloudflare 推动按网站选择管理 AI 爬虫，并推出 Pay Per Crawl 私测。内容所有者可以免费开放、收费或阻止访问；网络入口开始尝试承接内容访问的计费与结算。

   2025-07-01 收盘 $184.95 ↗

   事件来源 ↗ · 补充来源 ↗

8. 202511 / 1808
   可靠性 · 重大服务事故

   一次故障，暴露共享底座的另一面

   用户访问受影响的网站时看到服务器错误，Turnstile 验证加载失败；Cloudflare 后台虽然大体运行，大多数用户也因验证故障无法登录。数据库权限变化导致 Bot Management 特征文件异常，触发核心代理故障。14:30 UTC 核心流量大体恢复，17:06 全部系统恢复。

   2025-11-18 收盘 $196.53 ↗

   事件来源 ↗

9. 202512 / 0509
   可靠性 · 重大服务事故

   17 天后再故障：变更安全成为考验

   命中故障条件的网站，除少量测试端点外，所有访问请求都返回 500 错误，用户无法打开正常页面。在处理 React 漏洞的过程中，关闭内部 WAF 测试工具的配置变更触发旧代理错误。事故持续约 25 分钟；受影响客户对应约 28% 的 Cloudflare HTTP 流量，并非全球流量。

   2025-12-05 收盘 $200.95 ↗

   事件来源 ↗

10. 202604 / 1310
    产品 · 平台扩展 / 组件阶段不一

    Agent Cloud：给 Agent 一套运行环境

    Cloudflare 扩展 Agent Cloud，补充动态代码执行、存储、沙箱与长任务工具；OpenAI 同日确认模型接入，以及 Codex harness 在 Cloudflare Sandboxes 正式可用。公司把触角伸向 Agent 的实际运行过程。

    2026-04-13 收盘 $184.02 ↗

    事件来源 ↗ · 补充来源 ↗

11. 202605 / 0711
    公司 / 经营 · 经营与组织披露

    增长与组织调整，同时摆上台面

    一季度收入增长 34%，公司同时宣布向 agentic AI-first 运营模式转型，并计划减少约 1,100 名员工。下一交易日股价明显回落：产品进展、执行成本与经营预期，并不总在同一方向。

    公告日与图中价格日不同；价格取 2026-05-08 常规收盘。

    2026-05-08 收盘 $196.13 · 单日 -23.62% ↗

    事件来源 ↗ · 补充来源 ↗

12. 202607 / 0112
    产品 · 实验

    从按抓取收费，试到按使用付费

    Cloudflare 与 Ceramic.ai、You.com 等合作尝试 Pay Per Use，把付费依据从抓取次数，进一步延伸到内容展示或按需使用。内容控制、分发与报酬之间，开始探索新的连接方式。

    2026-07-01 收盘 $246.31 ↗

    事件来源 ↗ · 补充来源 ↗

13. 202608 / 0413
    产品 · 用户名开放 / 支付待上线

    Wallets：尝试补上身份与支付

    Cloudflare 宣布 Wallets，希望让 Agent 带着身份和预算使用 API 与内容，减少注册、填支付方式和领密钥等人工步骤。当天先开放钱包用户名领取，支付能力仍在后续路线图中。

    2026-08-04 收盘 $301.33 ↗

    事件来源 ↗

当答案不再带来点击，谁为内容买单？

最大的远期机会：当答案不再带来点击，谁为内容买单？

要理解这组产品的潜力，需要先看互联网原有的一笔交换。网站投入成本写文章、做测评、整理资料，允许搜索引擎抓取；搜索引擎帮助用户找到它们，把一部分人送回原网站。用户到站后阅读广告、购买商品，或者转化为订阅者。对依赖搜索流量的内容生意来说，“有人看见内容”和“生产者获得回报”，长期通过页面跳转联系在一起。

过去，内容网站争的是能不能排进搜索结果的第一页。AI 带来的变化更进一步：用户连第一页里的链接，都可能不必点开了。输入一个问题，答案就出现在搜索页或对话框里；原本需要自己打开几篇文章、逐段阅读再比较的工作，由模型代为完成。对用户而言，这是省时间；对原网站而言，内容可能参与了答案的生成，承载广告、订阅入口和品牌关系的那次访问，却未必发生。

这已经能在点击数据中看到迹象。Ahrefs 在 2026 年 2 月发布的研究，用 30 万个关键词及聚合的 Google Search Console 桌面数据，对比出现 AI Overview 与不出现 AI Overview 的样本，并以后一组的变化校正整体趋势。按其估算，2025 年 12 月出现 AI Overview 时，排名第一的页面点击率比“没有 AI Overview”的估算基准低约 58%。这是样本中的相关性与反事实估算，不是全网流量或广告收入下降了 58%。Ahrefs：研究口径与结果 ↗

另一项来自 Pew Research Center 的观察更贴近用户行为：它分析了 900 名美国成年人在 2025 年 3 月的浏览数据。有 AI 摘要的搜索页访问中，8% 发生了对传统结果链接的点击；没有摘要时是 15%。摘要内部来源链接的点击，只发生在有摘要页面访问的 1% 中。这是特定时期和人群的观察，不能直接当作今天全球用户的行为，但它说明了一个问题：被 AI 引用，不等于获得一次真实的网站访问。Pew：搜索摘要与点击行为 ↗

这里受冲击的是依靠回访支撑内容生产的利益分配方式，不宜笼统写成“广告已经消失”或“谷歌的商业模式已经崩塌”。谷歌在 2026 年 5 月还宣布试验 AI Mode 中的新广告形式。答案入口仍然可以赚钱，变化在于这些收入能否传递给提供原始材料的网站。用户获取信息的效率提高了，内容生产者却未必同步受益。Google：AI 搜索中的新广告试验 ↗

这也是比“让爬虫付一点钱”更大的问题。采访、实验、实地调查、专业测评和持续更新数据库，都需要人和资金。AI 可以降低整理与表达的成本，却不会自动替生产者收回这些投入。如果内容不断被使用，而广告回访、订阅转化又不足以覆盖成本，商业机构继续投入高质量原创的动力就会减弱。后果未必是所有人停止写作，也可能是减少原创、提高付费门槛，或只向少数签约平台提供内容；依赖新资料的 AI 产品，最终也要面对供给变少、获取变贵的问题。

因此，我认为这是一次巨大商业模式变化的潜在机会：过去，内容通过带来人的访问获得回报；未来，一部分内容可能需要因为被软件实际使用而获得回报。 订阅、内容授权、收入分成、按查询付费和按次购买，都可能成为补充。旧有回报链条承压，会迫使市场寻找新的安排，但不会保证某一种方案自动成功，更不会保证收益一定落到 Cloudflare 手里。

OpenAI 的搜索合作：内容发现与补偿的相邻问题

前文的公司演进已经讨论了网页托管与 Agent 执行。回到内容经济，还要看第三条线：AI 怎样发现和访问互联网内容。

2026 年 7 月 8 日：让搜索知道哪些网页值得重新抓取

7 月公布的搜索合作是另一件事：双方研究能否利用参与网站的内容新鲜度、页面变化与流量质量信号，改进网页发现和抓取。它说明 Cloudflare 所处的网络位置可能为搜索提供帮助，但目前是研究试点，公告没有说 ChatGPT Search 的主要索引、排序或答案生成运行在 Cloudflare。这与前文托管网页、运行 Agent 的合作应当分开理解。搜索研究试点 ↗

搜索引擎需要不断访问网站，才能知道页面有没有更新。可以把这个试点理解为：Cloudflare 尝试利用网络信号，帮助 OpenAI 判断哪些页面真的变了、哪些重复访问可以省掉；OpenAI 用自己的搜索和回答系统，检验这些信号能否改善内容发现、索引效率和答案的新鲜度。这是合作希望解决的问题，不是已经公布的效果测量结果。双方分工与试点目标 ↗

Cloudflare 对这项研究计划的范围也有明确说明：使用客户选择共享的信号，限于搜索，不共享网页内容，也不用于训练基础模型。搜索研究与内容收费是相邻但不同的工作；这些公告没有确认 OpenAI 已经加入 Pay Per Crawl，不能把“合作改善抓取”直接写成“OpenAI 已经按次付费”。研究范围与内容付费实验的区别 ↗

帮助搜索引擎更有效地发现网页，并不自动解决内容生产者怎样获得报酬。这里的搜索试点研究内容发现与抓取；下文 Ceramic.ai、You.com 的实验，才具体涉及按使用或按需访问补偿内容方。不能把不同合作方、不同阶段的项目合并成一项已经成立的付费安排。搜索试点 ↗内容付费实验 ↗

Cloudflare 想争取的，正是新安排里的基础设施位置。Pay Per Crawl / Pay Per Use 尝试给内容访问或使用附上价格，Monetization Gateway 把收费延伸到 API 与工具，Wallets 则计划让 Agent 带着受限预算完成付款。如果这些能力最终能连起来，它参与的就不只是流量分发，还包括“谁使用了有价值的资源，怎样把钱交给提供者”。这才是把这组产品放在远期机会首位的理由：互联网可能需要重建一部分内容回报机制，而 Cloudflare 已经站在许多内容与请求相遇的地方。下文再看，它具体做到了哪一步。

网站的访问者变了，入口的规则也要变

AI 给 Cloudflare 带来的不只有应用开发。网站原本主要服务人，也接受搜索引擎抓取；现在，模型训练爬虫、AI 搜索机器人和会执行任务的 Agent，都可能来读同一份内容。站主关心的问题随之变得具体：是谁在读，读了多少，愿不愿意开放，以及是否应该收费。

AI Crawl Control 先解决看见和管理访问的问题。它帮助网站识别 AI 流量，并设置允许或拦截策略。这延续了 Cloudflare 熟悉的工作：请求到达网站之前，先判断能不能通过。管理自动化访问并不等于保证识别所有机器人，也不意味着搜索、训练和 Agent 应被视为同一种用途。AI Crawl Control ↗

Pay Per Crawl 在允许与拒绝之外，增加了一个付费选项。网站设置访问价格，支持该机制的爬虫按相应支付流程获取内容。产品可以通过 HTTP 402“需要付款”的响应，把收费要求放进访问过程。它使“别让 Agent 免费拿走内容”从一句诉求，变成可以配置的产品规则。不过，截至本次核验它仍是封闭测试；不是所有 AI 请求都已经在付钱，已有的 WAF 或 Bot 拦截规则也可能先阻止访问。Pay Per Crawl 当前状态 ↗

这件事与普通网站支付的差别在于，付款者可能是程序。人可以看见订阅页、选择套餐、输入支付信息；Agent 更需要可由程序读取的价格、凭证与重试流程。Agents SDK 已提供 x402 与 MPP 的接入方法，服务端可以提出支付要求，客户端付款后携带凭证再次请求。协议能运行，不等于 Cloudflare 自己的钱包已经全部开放。Agent 支付协议接入 ↗

钱包的特色，在于为程序安排预算与权限

Cloudflare Wallets 所描述的方向，是给 Agent 一个可识别的支付身份，并为它安排预算、商户范围和单笔限额。一个替人办事的 Agent，可能需要购买一段数据、调用付费工具或读取收费内容；人未必愿意每笔都手动处理，也不愿意交出一张没有限制的卡。围绕程序身份和支出权限设计钱包，是这个产品值得讲清楚的特色。

但读者需要知道自己现在能用到哪一步。截至 2026 年 8 月 31 日，官方文档仍只允许预约 HANDLE.cloudflare.pay 名称，不能接收、发送或持有资金。账户钱包、虚拟钱包及资金功能属于后续能力。Monetization Gateway 则计划把网页、API、数据和 MCP 工具的收费策略统一起来，目前官方入口仍是早期访问候补名单。Wallets 当前状态 ↗Monetization Gateway ↗

把几个产品放在一起，方向就比较清楚了：AI Crawl Control 管谁能访问；Pay Per Crawl 尝试让内容访问附带价格；支付协议让程序理解付款要求；Wallets 计划管理付款身份与预算。它们的成熟度并不一致，也不自动组成一套已经完整商用的系统。Cloudflare 正沿着原有的网站入口，把访问控制往内容和工具的交易规则延伸。

Agent 成为买家，交易怎样进入一次任务？

假设一家软件公司的研究 Agent，要完成一份供应商比较报告。它可能需要读取一份付费行业材料、查询一个实时数据接口，再调用一次专门的分析工具。今天，这三个步骤可能意味着三个账号、三次付款设置，以及三套密钥。人类愿意为经常使用的软件完成这些手续，却很难替 Agent 每次临时找来的服务都做一遍。

如果价格、使用权限和付款凭证能由程序处理，这份报告就可能在用户给定的预算内自动完成采购。用户支付的是完成任务所需的资源，内容和工具提供者则有机会因交付价值获得报酬。Cloudflare 要解决的，是让这种临时、细小而频繁的交易足够方便，不必每次都靠人注册账号、谈合同和安排付款。

Cloudflare 正在尝试的产品，可以沿着一次请求看懂。下表是各组件的职责与现状，不是一套已经全部上线、端到端验证过的流程。Pay Per Crawl 的 Stripe 结算路径，也不能和 Monetization Gateway 计划采用的 x402 路径混成同一个系统。

Monetization Gateway 计划让网页、数据、API 和 MCP 工具使用同一类收费规则：服务提供者设置哪些请求付费，系统检查支付凭证后再放行。结合前文钱包的付款身份与预算，它要处理的是“程序找到了一个有用的资源，接下来怎样获得购买许可并拿到它”。开放状态已集中在上表及钱包说明中：前者是早期访问候补名单，后者仅开放名称预约。Monetization Gateway 公告 ↗Wallets 当前可用范围 ↗

谁在尝试：内容付费走到了哪一步？

Pay Per Crawl 有人用了吗，赚到钱了吗？

准确的回答是：有具体产品、测试流程和具名合作，但公开资料还不足以证明它已经跑出稳定的交易规模。Pay Per Crawl 在 2025 年 7 月 1 日以 private beta 发布；本次读取的官方说明，最后更新于 2026 年 7 月 28 日，仍标注 closed beta。它已经超出概念阶段，却也没有成为人人可直接接入的正式商用品。最初发布公告 ↗当前产品状态 ↗

产品细节可以证明团队做到了哪里。站主能设置抓取价格，最低为每次 0.001 美元；2026 年 6 月 16 日又加入动态定价，允许通过源站或 Worker 按请求设置不同价格。支付侧，爬虫需要连接 Stripe，出版商也有专用的 Stripe Connect 接入流程。官方规定，成功交付内容后记录费用，再汇总、对账，并按月向符合条件的出版商付款，同时存在结算期与最低付款门槛。价格设置 ↗动态定价更新 ↗爬虫支付接入 ↗出版商结算流程 ↗

这些资料支持“收费与结算流程已经有明确实现和规则”，不能单凭文档中出现余额、付款等字段，就认定某个出版商实际收到了多少钱。本次查阅的产品文档与公告，没有提供可核对的出版商到账案例、付费抓取总量或交易总额。支持 Cloudflare 许可访问方向的媒体，也不能直接计作 Pay Per Crawl 的付费成交客户；例如 Condé Nast 等机构在发布公告中表达的，是对内容控制与合作方向的支持。许可访问模式的支持者声明 ↗

需求端更具体的进展来自 2026 年 7 月 1 日：Cloudflare 公布了与 Ceramic.ai、You.com 的实验。前者尝试在出版商内容出现在搜索结果时支付报酬；后者让 Agent 按需购买特定优质内容。合作对象是真实且具名的，官方对商业阶段的表述仍然是实验，而不是已经完成规模验证。Pay Per Use 的具名合作 ↗

对 Cloudflare 自己是否已经赚钱，也要区分交易发生、获得收入和产生利润。2026 年第二季度财报公告强调了面向 Agent 的支付基础设施方向，但没有单列 Pay Per Crawl / Pay Per Use 的收入或利润；上述产品资料也未给出明确的平台抽成口径。由此只能说，这项业务的收入规模与盈利能力尚不能从公开资料确认，不能写成收入为零，也不能写成已经赚了很多钱。Cloudflare 被列为 Merchant of Record，仍不足以让我们把内容交易总额直接当作它的收入。Q2 2026 财报公告 ↗Pay Per Crawl 中的交易角色 ↗

Ceramic.ai：给模型和 Agent 提供搜索的公司

Ceramic.ai 并不是一家出版商，也不是 Cloudflare 自己的产品。它是一家 AI 基础设施创业公司，创始团队包括曾任 Google 工程与产品副总裁的 Anna Patterson，以及有搜索引擎创业经历的 Tom Costello。Patterson 在 2025 年 3 月的公司发布文章中，最初强调的是让企业更高效地训练自己的模型。到了本次核验时，官网的主打产品已是面向大模型与 Agent 的 Web Search API，并注明这项搜索服务于 2026 年第二季度推出。这个变化也解释了，为什么只看早期介绍，可能会把它理解成一家模型训练公司。创始团队与当前产品 ↗2025 年的最初定位 ↗

它现在卖的，可以理解为“让其他 AI 产品上网查资料”的能力。做聊天助手、研究工具或企业 Agent 的团队，把问题交给搜索接口，再将找到的实时资料送进模型，用来补足训练知识的时效性。Ceramic 的产品重点是降低频繁搜索的成本，目标客户主要是这些开发团队；它不是单纯争取用户每天打开一个搜索首页。这里的搜索 API，也不要与 Cloudflare 用来搜索客户自有数据的 AI Search 产品混淆。Ceramic 产品用途与 API 说明 ↗

于是，与 Cloudflare 的合作有了具体含义：Ceramic 面向 AI 应用提供搜索服务，内容生产者则提供支撑搜索结果的材料。按 Cloudflare 公布的实验安排，出版商选择加入后，内容出现在 Ceramic 的搜索结果中就可能获得报酬。搜索用户支付的 API 费用，与出版商收到的内容补偿，是不同方向的两笔交易，不能混为一谈。我的理解是，Ceramic 想以可负担的搜索成本获得更好的内容供给，Cloudflare 则帮助这种补偿方式触达更多站主；是否能长期兼顾低价搜索与内容报酬，还要看真实使用和交易结果。双方公布的实验安排 ↗

You.com：从 AI 搜索入口，走向给其他 Agent 提供实时资料

You.com 的名字可能更容易让读者联想到一个面向个人的 AI 搜索网站。公司由 Richard Socher 与 Bryan McCann 于 2020 年共同创办；Socher 此前担任 Salesforce 首席科学家，当前仍在公司官网列为 CEO。它有 AI 搜索和助手产品的历史，但今天只把它叫作“另一个聊天机器人”，已经不够准确。公司创办经过 ↗当前团队介绍 ↗

本次读取的官网，把面向 AI 的搜索 API 放在最突出的位置，并列出 Web Search API、Contents API、Research API 与 Finance Research API。它们分别覆盖找网页、提取内容、研究综合及金融研究等需求。对企业开发者来说，这家公司提供的是模型之外的实时资料与研究能力：一个 Agent 不必自己建设网页搜索、正文提取和资料综合的全部流程，就能把这些能力接进自己的产品。You.com 当前产品首页 ↗

这也让它参与内容付费实验显得合理。一个替用户完成研究任务的 Agent，未必需要长期订阅每一家出版商，却可能在某个问题上确实需要一份收费材料。Cloudflare 公告描述的 You.com 路径，正是允许 Agent 按需购买特定优质内容，而无需事先作出长期购买承诺。它更接近“为了完成这一次任务，临时买下需要的访问权”。例如，研究某个细分行业时为一份难以替代的材料付款，是便于理解的假设场景，不是已经披露的客户订单。You.com 参与的按需访问实验 ↗

两家公司代表的是相邻但不同的需求：Ceramic 的实验把报酬与搜索结果中的内容使用联系起来，You.com 的实验侧重任务执行中的按需购买。它们都需要接触模型之外的网页与资料，因此有理由尝试新的内容交易方式。这比一个没有买方的收费设想更具体，但仍不能外推成所有大模型厂商都接受了这套规则，也不能据此估计 Cloudflare 已经赚到了多少收入。

从抓取次数到使用价值，难点开始离开网络本身

按抓取收费容易计量，但和内容产生的价值并不总是对应。一篇文章被抓取一次，可能之后参与许多回答；同一篇文章也可能被反复抓取，却没有真正帮助任何用户。Cloudflare 在 2026 年 7 月的公告中承认了这种错位，并尝试按查询、内容展示或按需访问付费。这是对计价方式的继续探索，不能仅因为开始试验新模式，就断言第一版已经失败。计价方式为何继续变化 ↗

不过，这个变化确实暴露出更难的问题。Cloudflare 能在请求入口看到一次抓取，不代表它天然知道这份内容后来参与了多少次回答、贡献了多少价值。按使用计费需要买方报告、双方认可的归因方法，或其他可核验机制。网络规模能帮助分发规则，却不能独自解决价值归属。出版商还要判断，收费得到的钱是否值得可能损失的曝光；买方也会比较付费内容与其他来源，决定有没有必要成交。

因此，我更看好先从权利清楚、交付明确的 API、数据与工具调用做起。例如一次数据库查询或一次图像处理，通常更容易定义交付内容和计量单位。开放网页、训练素材与多来源合成回答的价值分摊，则需要解决更多买卖双方的分歧。这是对商业落地难度的判断，不是已经被公开交易数据证实的结果。

优势很具体，但“互联网自动收费站”并不自动成立

Cloudflare 的优势，首先是接入位置。对已经经过它的网站和 API，请求本来就要接受安全与访问规则检查，把价格和付款凭证纳入同一次访问，具备技术上的相邻性。其次是供给侧关系：原有站主不用先迁移到一个陌生的内容市场，才有机会试验收费。再加上 Workers、身份工具和开发接口，它有条件把交易规则做成开发者能调用的服务。这里复用的是既有请求处理路径、客户接入和工程能力；支付结算、风控、合规与争议处理仍然有自己的成本和难题。

它也不能决定所有流量都必须成交。AI 公司可以不买，可以寻找替代内容，也可以和大型出版商直接签约；网站可以继续免费开放，或者只对特定用途收费。x402 本身是开放协议，Cloudflare 必须靠更好的接入体验、可靠性与服务争取客户，不能因为参与协议就天然独占交易。Monetization Gateway 的协议与产品范围 ↗

新产品怎么排：今天的生意，与最大的远期机会

把 Cloudflare 最近发布的产品排在一起，很容易产生一种错觉：产品名字越新，越值得期待。可一家公司的产品组合里，有些负责今天收钱，有些让开发者更愿意留下，还有些在试探几年后才可能成立的交易方式。把它们放在同一个成熟度上比较，反而看不清公司的方向。

我的排序是：近期商业化优先看应用与 Agent 的运行基础设施；远期业务形态的变化，优先看内容、API 和工具的机器交易。 前者把已有计算、存储生意卖给新的开发者，后者尝试让 Cloudflare 从收取基础设施费用，进一步参与互联网资源的交易。两种机会都值得写，但需要相信的前提不同。以下是本文的产品判断，并非 Cloudflare 公布的内部优先级。

最靠谱的扩张：让 Agent 多做事，平台多承接任务

前面的工单案例已经说明，Agent 一旦进入工作流程，模型回答只是其中一步。它还要记住进展，等待授权，执行工具，处理失败，再把结果写回系统。Cloudflare 的机会，是把这些步骤接成开发者能掌握的一套产品。Agents SDK 提供状态、会话和执行能力，Sandbox 则提供运行代码与操作文件的环境；客户可以替换模型，仍然需要这些配套服务。Agents 运行体系 ↗Sandbox 产品说明 ↗

这比押注某个模型长期领先更接近 Cloudflare 现有的能力，也能复用 Wrangler、身份控制、网络和数据产品。我把它放在“值得优先研究”的位置：它既有新需求，又能接到现有资源账单上。它面临的考验同样具体——开发者是否愿意把重要任务搬过来，运行时是否兼容现有工具，任务中断后能否恢复，隔离与排障是否足够可靠。前文的 AWS 对照也提醒我们，能搭出同样系统的供应商并不只有一家。

Workers AI 和 Vectorize 的收费也较直接，但不能由此推定利润更好。推理需要算力，模型和硬件效率会改变单位成本；向量检索也要和现有数据库方案竞争。我的判断是，把推理和检索放在应用旁边，减少集成步骤，比笼统宣称“有全球网络，所以所有 AI 计算都更便宜”更有说服力。Workers AI 计费 ↗Vectorize 计费 ↗

相较之下，调用日志、缓存、限流和爬虫面板这类功能，单独改变公司业务形态的空间较小，却能让用户更愿意使用整个平台。AI Crawl Control 的部分能力覆盖免费套餐；AI Gateway 的基础分析、缓存与限流也免费。这一类产品的价值，有时体现在留住开发者和增售其他能力上，不能把每个功能都当成一条独立的大收入线。AI Crawl Control 入门 ↗AI Gateway 定价 ↗

不过，AI Gateway 已经提供了一个具体的收费入口：Unified Billing 对购买的额度收取 5% 手续费，模型推理价格本身按供应商价格传递、不加价。例如购买 100 美元额度，付款是 105 美元。它说明“减少多供应商支付和集成的麻烦”可以有商业价值；但这不是 Pay Per Crawl 的抽成率，也不是 Wallets 的费率，更不代表所有经过 Gateway 的调用都会贡献这笔费用。统一账单的收费规则 ↗

一张排序表，先分清它们靠什么赚钱

表中按“距离可重复收费的生意有多近”分层，同层不强行分出胜负。它不是收入规模排名；同样，远期空间指的是可能拓展的业务范围，不代表成功概率。Workers 与数据产品虽不是刚发布的新产品，仍要放在第一层，因为新场景最终会消耗这些已经计费的资源。

前两层并不需要等所有 AI 公司接受一种全新的付费规则。客户只要把程序部署上去、保存状态、执行任务，就会消耗已有计费资源。Workers 和 R2 的收费口径已经公开；Sandbox 的价格取决于底层 Containers。这个路径比较容易解释给采购者：以前为服务器或云函数付钱，现在为运行 Agent 的资源付钱。Workers 计费 ↗R2 计费 ↗Sandbox 计费 ↗

工具链则负责把更多项目带到这张账单前面。收购 VoidZero 与建设 Wrangler，可以看作 Cloudflare 对“如何让人开始使用”的投入：降低开发与部署的衔接成本，再争取生产用量。这条路径比建立全新的内容付费市场少一个前提——云资源已经有成熟的购买习惯；但它仍要与其他云争夺部署选择，也不能据此认定收购已经带来可量化的收入增长。本文把它列为支撑现有平台扩张的重要能力，而把后面的机器交易体系留给“改变商业模式”的远期想象。

所以，“哪些靠谱、哪些不靠谱”，我会落到具体说法上。让 Agent 在现有平台执行任务并按资源计费，逻辑最扎实；帮助内容和工具提供者试验机器付费，有客户痛点，也有合适的接入位置，值得持续投入研究。把支持者名单当作成交名单、把钱包名称预约当作资金业务上线，或者把所有被拦截的爬虫都想成未来付费买家，就不靠谱。至于“最终会成为机器互联网的通用交易基础设施”，可以作为最大的远期设想，不能当成今天已成立的公司事实。

如果按远期业务扩展范围另排一次，我会把内容与工具交易体系放在第一，Agent 运行平台放在第二，推理、检索及调用管理放在第三。第一名需要同时解决供给、需求、权限与结算，最可能改变 Cloudflare 的业务边界，也最不能只靠一次产品发布就下结论。眼前更容易兑现的仍是运行平台：先让软件在这里把事情做完，再争取让软件在这里完成购买。这两条路线可以相互支持，但前一条的成功并不保证后一条成立。

从那根支柱，重新理解 Cloudflare

再回头看开篇的积木塔，Cloudflare 的变化就更容易理解了。那根支柱画出了大量网站对它的依赖，却没有画出今天的开发者正在上面做什么：请求可以在这里被检查和转发，也可以触发程序、读取数据、调用模型，完成一次应用任务。Cloudflare 正从帮助应用被访问，扩展到参与应用本身的运行。

对一个网站，它可能首先是 CDN 和 WAF；对一家企业，它可能是员工访问和跨地点连接的工具；对文件处理应用，它是运行时、文件与数据库的组合；对 Agent 开发者，它还可以提供状态、执行环境和工具入口。同一家公司，在不同人的工作里会有很不一样的面貌。

它能否进一步破圈，也取决于这些能力能否被顺手地用起来。统一配置、资源绑定和 Wrangler 缩短了从代码到运行的路径，AI 编程又让更多人有机会走上这条路。下载量、客户层级和净留存提供了不同侧面的观察：有人开始接触这套工具，也有客户继续扩大使用。把这些现象放回产品体验中，才更容易理解增长从哪里来。

这也让老业务与新产品很难分开评价。复用网络和工具能减少重复建设，让开发者少配置一些东西；但服务之间的依赖增加，也要求平台控制好故障传播、资源隔离和变更风险。2025 年末相隔 17 天的两场事故提醒我们，能够承载多少新场景，最终仍要建立在可靠运行之上。

重新认识 Cloudflare，要把托住现有网站的网络，与开发者用来构建新应用的平台放在一起看。让原来只是经过这里的流量，带来可以运行在这里的应用，是已经能看见的转型。再往前一步，让这些应用和 Agent 能够购买内容与工具，则是本文最看重的远期可能：它有合适的起点，正在补齐产品，还要靠买卖双方一次次真实交易，把这个设想做成生意。

附录：完整产品目录与逐项说明

这里按 Cloudflare 官网自己的分类，完整保留产品目录。熟悉的 CDN、DNS 和安全产品还在，计算、存储、AI 与媒体服务也已各成一组。先用总览表看各组分工，再逐项解释每个产品做什么、什么时候会用到，以及它与相邻产品有什么区别。点击总览表的分类，可以直接跳到对应说明；也可以回到正文的 与 AWS 的整体对照 和 成本优势总结。