Kitesurf 是什么?Cloudflare 为 AI Agent 打造的 Workers 原生浏览器

Cloudflare 于 2026 年 8 月 6 日公布 Kitesurf,一款面向 AI Agent 和自动化任务的浏览器引擎。它直接运行在 Cloudflare Workers 上,使用 V8 isolates、WebAssembly、Dynamic Workers、Durable Objects 和 Workers RPC 等能力处理页面,提供 DOM、网络检查、截图与 PDF 等功能。

Kitesurf 风筝形浏览器引擎连接三个隔离执行舱的封面

Agent 提取网页内容或完成一次性操作时,往往更关心结果、资源消耗和并发能力。Kitesurf 因而选择较轻的执行方式,把页面代码、网络访问和渲染拆到隔离组件中;像素级还原、视频和复杂图形等能力则需要另行评估。

官方测试中,省资源与更快完成是两回事

发布时,Cloudflare 对 14 个 URL 分别运行五次 Browser Run Quick Actions,公布了与热池 Chromium 对比的中位数。截图和 HTML 提取消耗的 CPU 与内存明显减少,但实际完成时间更长。

测试指标 Kitesurf Chromium 热池 这组测试中的差异
截图 CPU 380 ms 1,173 ms 约为 Chromium 的 32%
HTML 提取 CPU 229 ms 877 ms 约为 Chromium 的 26%
截图内存 57.8 MiB 271.0 MiB 约为 Chromium 的 21%
HTML 提取内存 39.4 MiB 273.7 MiB 约为 Chromium 的 14%
截图总耗时 1,148 ms 637 ms 耗时约为 Chromium 的 1.8 倍
HTML 提取总耗时 820 ms 472 ms 耗时约为 Chromium 的 1.7 倍

CPU 耗时减少,不等于用户等待时间缩短。这组结果支持的是资源利用方面的优势,不能直接推出单次任务延迟更低、实际账单必然更便宜,或复杂网站也会有同样的比例。测试由 Cloudflare 提供,本文未做独立性能测试。

Cloudflare 在发布文章中还称 Kitesurf 已通过约 21.5 万项 Web Platform Tests,并继续增加覆盖。标准测试通过数有助于了解实现进度,但不能代替目标网站的实际兼容性验证。

一次页面任务怎样经过四个组件

  1. Engine 接收任务、管理会话。它是对外提供接口的组件,处理 Chrome DevTools Protocol(CDP)WebSocket 与 HTTP REST API,保存会话状态。
  2. SandboxOutbound 统一处理网络。HTML、CSS、JavaScript、图片、字体及 WebAssembly 的外部请求都经过它;组件执行 CORS 策略、添加浏览器式请求头、过滤响应,并给页面维护独立 Cookie 容器。策略不允许的请求返回 403。
  3. PageScript 解析并运行页面。新页面或跨进程 iframe 通过 Dynamic Workers 获得隔离执行环境,从干净的 globalThis 和 DOM 开始,解析 HTML、CSS,运行 JavaScript 与 WebAssembly。Blitz、Stylo 等 Rust 组件参与页面与样式处理。
  4. PageRenderer 输出图像或 PDF。它读取已经计算的页面场景,处理字体、图片与布局,生成 PNG、JPEG 或 PDF。Engine 通过 Workers RPC 调用它;渲染器只保留可丢弃缓存,失败时可重启,而不必重建整个页面会话。

这里的“尽量无状态”主要指可以丢弃和重启的组件,并不表示页面完全没有状态。Engine 保存会话,PageScript 中的 DOM 和页面代码也在该页面会话内持续存在;隔离与恢复成本是这套设计的重点。

发布文章还解释了一个实现取舍:当时 Workers 不能原生执行 eval,Kitesurf 暂借 Rust 编写的 Boa JavaScript 引擎处理这类动态代码。Cloudflare 表示希望在 Workers 原生支持后替换它;这是发布时的方案与计划,不应直接当作之后所有版本的实现。

沿用 CDP 客户端,仍要检查参数与能力

Kitesurf 提供 CDP 接口,因此可与 Puppeteer、Playwright、chrome-remote-interface、Chrome DevTools 前端及使用 MCP/CDP 的 Agent 对接。兼容同一种接口,不表示它实现了 Chrome 的全部 CDP 指令或 Web API。

  1. 先用公开 Playground 或小范围 API 任务检查目标网页,观察 DOM、控制台、网络、截图及实际操作结果。Playground 还可查看各 isolate 的 WebAssembly 内存信息。
  2. 按 Browser Run 文档配置账户 ID、API Token 和权限,在支持的 CDP 或 Quick Actions 端点选择 browser=kitesurf。
  3. 核对现有脚本使用的指令和参数。2026 年 10 月 7 日读取的 CDP 文档明确说明,browser=kitesurf 不能与 keep_alive、lab 或 recording 组合使用。
  4. 确认结果满足任务要求后,再扩大使用范围,遇到不兼容的任务时,应能够切回 Chromium。真实令牌应保存在私有配置中。

怎样判断是否值得采用

允许渲染差异的短任务,可以先做兼容性验证

页面内容提取、一次性 Quick Actions,以及兼容网站的截图和 PDF,是发布文章强调的场景。若任务以 DOM 和网络检查为主、需要批量并发,并且能接受一定的渲染差异,可以先测试 Kitesurf 在这些任务中的表现。是否节省实际成本,还要结合任务量、延迟和服务计费判断。

Cloudflare 发布时列举了 TodoMVC、Wikipedia、Hacker News、Cloudflare Blog,以及 Cloudflare Dashboard 的大量页面作为兼容示例。这些示例不能保证其他网站或同一网站的所有交互都能运行。

这些要求下,Chromium 仍是更稳妥的起点

  • 需要播放视频、使用 WebGL,或调用尚未被 Kitesurf 覆盖的 Web API。
  • 需要真实 TLS 指纹完成机器人挑战握手。
  • 需要持续约十分钟、依赖持久登录状态的会话。
  • 截图必须高度还原页面,或复杂交互不能接受兼容性差异。

上述限制来自发布时的官方说明,后续能力可能变化。具体项目应核对当前文档并测试目标页面,尤其不能只凭“支持 Puppeteer”就把生产流程整体切换过去。

试用、价格与开源要分别核对

在 2026 年 8 月的发布说明中,Kitesurf 作为 Browser Run 的可选浏览器进入 Beta,测试期免费但受账户限额约束。Cloudflare 当时表示准备好后会开源,希望用户可部署到自己的账户,尚未给出确定的开源日期或许可证。

发布时,项目从当年 5 月首次提交算起约 12 周,团队仍在改进 CDP、Web API、WPT 覆盖、渲染精度及运行效率。免费试用安排和未来开源计划都不能当作永久承诺;采用前应核对当前服务说明。

  • Cloudflare Kitesurf 发布文章:https://blog.cloudflare.com/kitesurf/
  • Kitesurf Playground:https://kitesurf.cloudflare.app/
  • Browser Run 文档:https://developers.cloudflare.com/browser-run/
  • Browser Run CDP 文档:https://developers.cloudflare.com/browser-run/cdp/
  • Browser Run 更新日志:https://developers.cloudflare.com/browser-run/changelog/

本文于 2026 年 10 月 7 日对照发布文章与当前 CDP 文档整理。架构、基准测试和初始兼容范围均按发布时资料说明;未对当前价格、全部兼容能力或开源进度作独立验证。

© 版权声明
THE END
喜欢就支持一下吧
点赞12 分享
评论 抢沙发

请登录后发表评论

    暂无评论内容