Cloudflare 开源 Kitesurf：AI Agent 的浏览器，不一定需要 Chromium

Cloudflare 在 11 月 13 日正式开源 Kitesurf，这是一款专门为 AI Agent 设计、运行在 Cloudflare Workers 上的实验性浏览器引擎。它可以解析 HTML、应用 CSS、执行网页 JavaScript、生成截图和 PDF，却不需要启动 Chromium 进程，也不需要在服务器上维护浏览器容器。项目已采用 Apache 2.0 许可证发布，开发者现在可以检查源码、在本地运行，或部署到自己的 Cloudflare 账户。(blog.cloudflare.com)

Kitesurf 最值得关注的地方不是“Cloudflare 又做了一个浏览器”，而是它直接挑战了 AI Agent 基础设施中的一个默认前提：只要智能体需要操作网页，后台就必须运行一套完整的 Chrome 或 Chromium。

过去两年，Browser Use、OpenAI Operator 类产品以及大量基于 Playwright、Puppeteer 的智能体框架，都沿用了“给 Agent 配一台无头浏览器”的思路。这条路线兼容性高、生态成熟，但成本也非常直接——每个会话都可能占用数百 MiB 内存，并产生进程调度、容器启动、沙箱隔离和浏览器池维护开销。

Kitesurf 的答案是：Agent 需要的是网页能力，而不是一台为人类准备的桌面浏览器。

它不是“精简版 Chrome”

Kitesurf 是一种无状态的 Agent 浏览器引擎，即每次任务都在独立环境中临时创建，任务完成后即可销毁，不依赖长期存活的浏览器进程。它运行在 Cloudflare Workers 和 V8 Isolate 体系之上，并将 Rust 浏览器组件编译为 WebAssembly，而不是把 Chromium 二进制文件塞进容器。

V8 Isolate 是 V8 JavaScript 引擎中的轻量级隔离执行环境，它不等同于虚拟机或容器，但可以为不同任务隔离内存和执行上下文。Cloudflare Workers 本身就是建立在这套模型之上，因此 Kitesurf 能利用 Workers 的快速启动和按需扩缩能力，为每个页面创建短生命周期的执行单元。

浏览器容器则是把 Chromium、系统依赖、字体、沙箱和自动化工具打包在隔离环境中的传统方案。它的好处是网页兼容性接近真实 Chrome，代价是镜像更大、启动更重，而且高并发时需要持续管理浏览器实例池。

Kitesurf 没有试图重新实现 Chromium 的全部能力，而是主动删除 Agent 很少使用的部分。标签页主题、浏览器扩展、视频播放、WebGL、像素级精确渲染，以及面向人类交互的完整浏览器界面，都不是当前版本的核心目标。

这种取舍类似于数据库领域的分析型引擎：它不追求覆盖所有通用场景，而是围绕特定工作负载重新设计执行路径。对网页智能体来说，这类工作负载通常是打开页面、执行脚本、读取 DOM、提取文本、点击元素、填写表单、生成截图，然后结束会话。

最高节省 7 倍内存，但完成任务更慢

Cloudflare 公布的测试显示，Kitesurf 在 CPU 和内存占用上明显优于预热状态的 Chromium，但其实际墙钟时间反而更长。测试取 14 个网址、每项运行 5 次的中位数，场景包括网页截图和 HTML 提取。(developers.cloudflare.com)

| 测试指标 | Kitesurf | Chromium 预热池 | Kitesurf 相对表现 | |---|---:|---:|---:| | 截图 CPU 时间 | 380 ms | 1,173 ms | CPU 消耗减少 67.6%，约为 1/3.1 | | HTML 提取 CPU 时间 | 229 ms | 877 ms | CPU 消耗减少 73.9%，约为 1/3.8 | | 截图内存 | 57.8 MiB | 271.0 MiB | 内存减少 78.7%，约为 1/4.7 | | HTML 提取内存 | 39.4 MiB | 273.7 MiB | 内存减少 85.6%，约为 1/7.0 | | 截图墙钟时间 | 1,148 ms | 637 ms | 慢 1.8 倍 | | HTML 提取墙钟时间 | 820 ms | 472 ms | 慢 1.7 倍 |

这组数据说明 Kitesurf 优化的是单位任务成本和并发密度，而不是单次任务的最低延迟。Chromium 预热池已经完成进程启动，并能依赖成熟的即时编译器和原生渲染管线，因此同一个页面更快完成并不意外。

Kitesurf 的优势会在规模扩大后体现出来。假设一项 HTML 提取任务需要维持 1,000 个并发会话，按照官方中位数粗略估算，Chromium 可能需要约 267 GiB 内存，而 Kitesurf 约为 38.5 GiB，两者相差超过 228 GiB。这个计算不能直接等同于生产环境容量规划，但足以解释 Cloudflare 为什么愿意接受数百毫秒的额外延迟。

对 Agent 平台来说，CPU 时间和内存通常比墙钟时间更接近真实成本。一个网页任务慢 300 毫秒未必会被用户感知，但如果内存占用能从约 274 MiB 降到约 39 MiB，同一台机器或同一组边缘节点能承载的会话数量就会发生数量级变化。

CDP 兼容是这次开源的关键

Chrome DevTools Protocol 是 Chrome DevTools、Puppeteer 等工具用于检查和控制浏览器的远程调试协议。Kitesurf 支持 CDP，意味着现有自动化框架不必理解其内部引擎结构，仍然可以通过熟悉的浏览器控制接口创建页面、导航和截图。

CDP 在这里承担的是兼容层角色，而不是证明 Kitesurf 内部运行着 Chrome。开发者面对的是类似 Chrome 的控制接口，接口后面连接的却是 Kitesurf 自己的 DOM、JavaScript 执行和软件渲染组件。

这一步决定了 Kitesurf 是否只是一个技术演示。假如开发者必须改写完整的 Agent 工具链才能使用新引擎，再低的资源占用也很难弥补迁移成本；现在 Kitesurf 可以被 Puppeteer 等 CDP 客户端驱动，试用门槛已经低了不少。

但兼容 CDP 不等于完整实现 Chrome。Cloudflare 在项目说明中明确表示，Kitesurf 提供的是 CDP 端点，而不是完整的 Chrome 实现，部分 DevTools 功能和协议行为尚不可用。(github.com)

浏览器能力由多个 Rust 项目拼起来

Kitesurf 的技术路线是复用多个 Rust 浏览器组件，而不是从零编写 HTML、CSS、JavaScript 和图形栈。Cloudflare 把这些组件组织成三个主要部分：Engine 负责管理浏览器会话和客户端连接，PageScript 负责页面与 JavaScript 执行，PageRenderer 负责绘制结果。(blog.cloudflare.com)

| 组件或项目 | 在 Kitesurf 中的作用 | |---|---| | Engine | 管理 CDP 连接、浏览器会话及整体生命周期 | | PageScript | 运行页面逻辑、DOM 接口和 JavaScript | | PageRenderer | 将布局结果绘制为截图等视觉输出 | | Blitz | HTML 解析、DOM、布局和绘制基础能力 | | Stylo | CSS 解析、层叠规则与计算样式 | | Boa | 在 WebAssembly 环境中执行页面 JavaScript | | Linebender 组件 | 文本布局与二维图形处理 | | Krilla | 生成 PDF 文件 |

这种组合式路线比重新造一个完整浏览器现实得多。Chromium 是数千万行代码规模的软件工程，包含多进程架构、GPU 管线、媒体系统、扩展框架、无障碍支持和大量平台适配；Kitesurf 只选择与 Agent 任务直接相关的模块，再通过 DOM Shim 和协议层填补缺口。

这种路线的风险同样明显：浏览器兼容性并不是把几个标准组件拼在一起就能自动获得。真实网站包含历史行为、浏览器私有特性、异常 CSS、复杂字体、反自动化机制以及大量依赖 Chrome 细节的前端代码，因此实验室标准测试和生产网站成功率之间仍有距离。

标准测试不错，但不能代替真实网站验证

Web Platform Tests 是用于检查浏览器对 Web 标准实现程度的共享测试套件。Cloudflare 表示，Kitesurf 目前已经通过超过 23.5 万个 WPT 子测试，其中 DOM 覆盖率为 97%、HTML 为 96%、Selection 和 Encoding 均为 99%、SVG 为 97%、CORS 和 XHR 均为 95%，URL 相关覆盖率为 83%。(developers.cloudflare.com)

| Web 能力 | 当前子测试覆盖率 | |---|---:| | DOM | 97% | | HTML | 96% | | Selection | 99% | | SVG | 97% | | Encoding | 99% | | CORS | 95% | | XHR | 95% | | URL | 83% |

这组数字证明 Kitesurf 已经不只是“能抓静态 HTML”的爬虫，但它不能证明所有网站都能正常运行。WPT 衡量的是标准一致性，而真实网站还会依赖浏览器 Bug、非标准接口、字体渲染差异、Canvas 行为、TLS 指纹和服务端风控。

Cloudflare 目前列出的可用页面包括 TodoMVC 的 React、Vue、Angular、Preact 等版本，以及 Wikipedia、Hacker News、Cloudflare Blog 和 Cloudflare 控制面板中的大量页面。对于文档站、资讯页面、后台管理界面和常规单页应用，这已经覆盖了相当一部分 Agent 使用场景。(developers.cloudflare.com)

Kitesurf 还替代不了 Chromium

Kitesurf 当前不适合视频播放、WebGL 渲染、依赖真实 TLS 指纹的反机器人验证，以及需要长期保持登录状态的有状态会话。Cloudflare 对这些限制没有回避，并建议相关场景继续使用 Browser Run 默认的 Chromium 后端。(developers.cloudflare.com)

| 使用场景 | Kitesurf | 完整 Chromium | |---|---|---| | HTML、DOM 与文本提取 | 适合 | 适合 | | 一次性截图或 PDF | 适合兼容网站 | 适合，渲染更准确 | | 突发高并发 Agent 任务 | 资源效率更高 | 浏览器池成本较高 | | 视频与 WebGL | 暂不支持 | 支持 | | 像素级页面还原 | 不保证 | 更适合 | | 长期登录和持久会话 | 暂不适合 | 更适合 | | 复杂反爬与 TLS 指纹 | 能力有限 | 更接近真实用户浏览器 | | 浏览器扩展 | 不支持 | 支持 |

这意味着 Kitesurf 更像 Serverless 浏览器函数，而不是远程桌面中的 Chrome。它最合适的任务是输入一个网址、完成一个动作、输出 HTML 或图片并立即销毁，而不是让 Agent 在购物网站中保持数小时登录、跨多个标签页比较商品并处理验证码。

开源让它从产品功能变成基础设施选项

Kitesurf 开源的实际价值是让开发者能够审计、修改和自行部署浏览器引擎。Cloudflare 在 8 月首次发布 Kitesurf 时，它主要是 Browser Run 中的托管能力；此次开放仓库后，团队可以直接检查协议实现、DOM Shim、渲染器和 Rust 依赖，也可以针对内部网站修复兼容性问题。

自行部署仍然不是完全脱离 Cloudflare 的本地化方案。Kitesurf 可以通过 Wrangler 在本地开发，但部署到 Cloudflare 时依赖 Dynamic Workers 为页面创建隔离 Worker，而 Dynamic Workers 属于 Workers 付费计划能力。Cloudflare 官方也提醒，直接部署的 Kitesurf 引擎本身不提供身份验证，必须使用 Cloudflare Access 或其他认证层保护入口，否则任何获得地址的人都可能借用部署者的账户发起网络请求并消耗计算资源。(github.com)

开源仓库目前仍被标记为实验性项目，贡献规则也比普通社区项目更谨慎。Cloudflare 表示项目处于高强度开发阶段，许多标准和行为仍未完整实现；外部贡献者需要先提交 Issue、获得维护者认可，再创建 Pull Request，未经认可的 PR 可能被自动关闭。(github.com)

真正的竞争不是“谁更像 Chrome”

Kitesurf 的竞争力不在于渲染结果能否击败 Chromium，而在于它能否用足够高的任务成功率换来显著更低的单位成本。如果一个 Agent 平台的 80% 网页任务只是读取文档、生成摘要和提取表格，那么为每个任务启动完整 Chromium 很可能属于过度配置。

传统 Agent 浏览器服务的核心能力是管理一支 Chrome 舰队，包括镜像更新、浏览器池、会话恢复、录屏、代理、验证码和持久登录。Kitesurf 则把问题改写成：能否让网页执行本身变成一种类似 Worker 的轻量计算任务。

这两个方向不会立即互相取代。完整 Chromium 会继续服务高兼容性、视觉操作和长期会话，Kitesurf 一类专用引擎则可能承接大批读取型、一次性、并发突发的任务。更现实的 Agent 架构不是二选一，而是先使用轻量引擎，遇到不兼容页面时再升级到 Chromium。

这种分层调度可能是 Kitesurf 最值得关注的长期影响。Agent 可以先用低成本引擎检查页面、提取 DOM 和判断任务复杂度，只有在需要 WebGL、验证码、复杂登录或高保真视觉理解时，才申请完整浏览器实例。它相当于把浏览器从固定配置变成可路由的计算资源。

OpenAI Hub 观点

Kitesurf 是一次方向正确但尚未成熟的浏览器重构。它用最高 7 倍的内存效率证明，面向人类设计的完整浏览器并不是 AI Agent 访问 Web 的唯一答案；但 1.7 至 1.8 倍的墙钟时间、有限的 CDP 覆盖和真实网站兼容性，决定了它现在更适合作为 Chromium 的补充后端，而不是默认替代品。

开源会加快 Kitesurf 的兼容性修复，也会让开发者看清这种 Agent-first 浏览器究竟省掉了什么。相比又一个封装 Chrome 的自动化产品，Kitesurf 至少在重新定义浏览器应该为机器保留哪些能力，这比单纯增加一层 SDK 更有价值。

接下来真正需要观察的指标不是 WPT 数量继续增长多少，而是典型 Agent 网站集合中的任务成功率、P95 延迟、冷启动时间、单任务成本和降级到 Chromium 的比例。只有这些数据达到生产要求，“不用 Chromium 容器”才会从技术亮点变成可持续的基础设施优势。

参考来源

• Cloudflare Kitesurf GitHub 仓库：项目源码、Apache 2.0 许可证、运行要求、技术栈及部署安全说明。
• IT之家：Cloudflare 开源 Kitesurf：2026 年 11 月 14 日发布的中文事件报道与基本信息整理。