Cloudflare以Apache 2.0许可证开源面向AI智能体的浏览器引擎Kitesurf，支持开发者检查、修改代码并在本地运行或部署到自己的Cloudflare账户。云端自部署仍需Workers付费计划，部署者必须自行配置访问认证；项目仍处于实验阶段，资源消耗优势不等于更低延迟或账单，兼容性也有明确限制。
Cloudflare已将面向AI智能体的浏览器引擎Kitesurf开源，采用Apache 2.0许可证。开发者现在可以检查和修改代码，在本地运行引擎，并将自己的实例部署到Cloudflare账户中。公司在2026年11月12日的开发者更新日志中宣布这一消息，并于11月13日发布详细博客。
这次进展不是一款新浏览器首次亮相，而是此前开源承诺的兑现。它让开发者获得更多代码与部署控制权，但并未消除平台依赖：云端自部署仍需要Workers付费计划，访问认证也必须另行配置。Cloudflare同时明确，Kitesurf仍属实验性项目，正在密集开发中。
从托管浏览器走向可自行维护的引擎
Kitesurf的定位不是供人日常使用的Chrome替代品，而是让智能体访问网页的执行环境。它能够解析HTML、应用CSS、运行页面JavaScript并生成截图，无需启动Chrome或浏览器容器；通过Chrome DevTools Protocol（CDP，Chrome开发者工具协议），Puppeteer等客户端可以连接并控制它。
Cloudflare在2026年8月介绍了Kitesurf，9月又加入WebMCP支持、扩展接口并改善兼容性。AIFlux此前关于Kitesurf推出时的报道提到，公司计划在项目成熟后开放源码。此次变化在于，开发者不再只能使用Cloudflare提供的托管接口，而可以自行查看实现、修改功能和维护部署版本。WebMCP等此前已公布的能力，并非此次开源才首次出现。
按照官方博客，代码主要分为三个部分：Engine负责浏览器会话与客户端连接，PageScript处理页面及其JavaScript，PageRenderer负责绘制结果。底层结合了编译为WebAssembly的Rust组件，包括负责HTML、布局与绘制的Blitz、处理CSS的Stylo，以及提供文字排版和二维图形能力的Linebender相关库。
源码开放使这些实现和组件边界可以被检查，但“可检查”并不等于已经完成独立安全审计，也不代表所有浏览器行为都与Chrome一致。
自部署不等于脱离Cloudflare，也不等于免费
项目README区分了本地开发与云端部署：前者通过Wrangler启动本地开发服务器，后者把引擎部署到开发者自己的Cloudflare账户。云端运行依赖Dynamic Workers，为页面和渲染器创建隔离的Worker，因此要求Workers Paid计划。
这意味着，自部署所增加的是对实例和代码的控制，而不是已经提供了一套可在任意云平台直接运行的独立浏览器服务。开发团队仍需考虑Cloudflare平台的运行条件和账单。
Dynamic Workers定价文档显示，费用涉及动态Worker的每日创建计数、请求量和CPU时间；CPU计费还包括隔离环境启动时的开销。因此，不能只凭浏览器引擎较轻量，就推导出某项业务最终会节省多少费用。
另一方面，Browser Run的Kitesurf产品文档仍将其托管测试版列为免费、但受账户限额约束。托管测试版的免费政策，与在自有账户部署开源引擎所需的付费计划，是两种不同使用方式，不能混为一谈。
本地运行也有接口层面的区别：开源仓库支持构建并启动本地引擎，并不意味着Browser Run的托管浏览器绑定可以直接在本地模拟。产品文档说明，在本地开发环境中调用该绑定的Kitesurf Quick Actions，需要配置为访问远端服务。
认证是部署者的责任
自部署最直接的安全边界，是谁能连接这个浏览器。README明确警告，Kitesurf引擎没有内置认证，需要在入口前配置Cloudflare Access或其他认证层。
未经保护时，知道实例地址的人可以打开开发者工具、连接CDP客户端，通过部署者的Cloudflare账户发出网络请求，并消耗其付费CPU时间与Dynamic Workers资源。默认的workers.dev地址公开可访问，不能把地址不对外宣传当作访问控制。
仓库文档还提醒，先部署、再配置认证，会产生短暂的公开暴露窗口；如需避免这一窗口，应在部署前启用相应的账户级Access保护。通过Access连接Puppeteer等非交互式客户端时，则需要服务令牌和对应的Service Auth策略，不能只照搬未加认证的连接方式。
这里需要区分两件事：页面运行环境的隔离，解决的是页面代码如何被约束；入口认证，解决的是谁有权使用整套浏览器服务。前者不能替代后者。
兼容性和资源优势仍有明确边界
Cloudflare将Kitesurf的优势描述为较低的CPU和内存开销，而不是完整复制桌面浏览器。官方文档列出的适用场景，包括兼容网站的内容提取、截图、PDF生成，以及短时、突发的智能体任务；代价则是放弃部分传统浏览器功能和像素级还原。
公司文档中的比较使用14个网址，统计五次Browser Run Quick Action运行结果的中位数，对照对象为预热池中的Chromium。其中，截图任务的CPU时间分别为Kitesurf的380毫秒和Chromium的1173毫秒，内存分别为57.8 MiB和271.0 MiB；但实际经过时间分别为1148毫秒和637毫秒，Kitesurf反而更慢。
这些厂商公布的结果说明，在该测试条件下，较低资源消耗与较短等待时间不是同一件事。它们也不是智能体完成跨站点、多步骤业务任务的成功率，不能直接转换成用户账单降幅。
兼容性方面，官方明确列出尚不适合的需求：视频播放、WebGL、需要真实TLS指纹的反机器人挑战，以及依赖持久状态的长期认证会话。这些场景仍建议使用Browser Run默认的Chromium。README也强调，提供CDP端点不等于完整实现Chrome，部分开发者工具功能尚不可用。
Apache 2.0许可同样不是对整个依赖树的一揽子替代。仓库说明，随附字体、数据和依赖继续保留各自许可证，采用或再分发时仍需分别核对。
对于希望自行修改浏览器行为、检查底层实现的智能体开发团队，此次开源提供了新的选择。但是否适合生产任务，仍取决于目标网站兼容性、完整工作流的可靠性、访问控制与实际运行成本，而不是“开源”这一标签本身。