Cloudflare 开源 Kitesurf：面向 AI 智能体的无状态浏览器引擎

Cloudflare 开源 Kitesurf：专为 AI 智能体打造的无状态浏览器引擎

Cloudflare 在官方博客宣布，Kitesurf 已经在 GitHub 上以 Apache 2.0 许可证开源。Kitesurf 是一个完全运行在 Cloudflare Workers 之上的、面向 AI 智能体的无状态浏览器。文章署名作者为 Celso Martinho、Rui Figueira、Bernardo Pereira 和 Luís Duarte。官方原文把它定位为供智能体使用的轻量浏览器引擎，而不是一套已被证明的完整多租户隔离沙箱框架。

背景：一个兑现的承诺

Cloudflare 在 8 月首次介绍了 Kitesurf，9 月又发布了后续文章，加入了 WebMCP 支持、新的接口和更好的兼容性。两次发布时，团队都表示会把它开源，让开发者可以在自己的 Cloudflare 账户上运行自己的浏览器引擎。这次发布就是兑现承诺。你可以阅读代码、在本地运行、修改，并把自己的实例部署到 Cloudflare Workers。

它是什么

官方的描述很具体。Kitesurf 完全运行在 Cloudflare Workers 上：解析 HTML，应用 CSS，执行页面中的 JavaScript，并渲染截图，整个过程不需要浏览器容器。它支持 Chrome DevTools Protocol，也就是 CDP，所以 Puppeteer 这类客户端可以直接连接。

团队的主要目标，是给 AI 智能体一个轻量而高效的浏览器：能加载网站、执行 JavaScript、与页面交互，同时比 Chromium 这样的完整浏览器占用更少的 CPU 和内存，并且借助 Cloudflare 全球 Workers 网络按需扩展。

仓库里有什么

Kitesurf 建立在 Cloudflare 开发者平台和接口之上，并使用一批编译为 WebAssembly 的 Rust 开源组件。其中 Blitz 提供 HTML 解析、DOM、布局和绘制，Stylo 提供 CSS 解析、层叠和计算样式。Boa 在 WebAssembly 内运行 JavaScript，不过只作为最后手段，也就是在无法用 Dynamic Workers 运行 JavaScript 的时候才使用。Linebender 系列库负责文字排版和二维图形，Krilla 负责生成 PDF。这些项目各自保留原有的许可证，仓库中的 NOTICE 文件记录了第三方声明。

整体架构分三部分：Engine 管理浏览器会话和客户端连接，PageScript 运行页面及其 JavaScript，PageRenderer 把结果绘制出来。所有软件包，包括引擎、Rust 核心、DOM 垫片、渲染器和 Kitesurf 命令行工具，都分别放在仓库 packages 目录下的不同文件夹中，便于了解各部分如何配合。

如何在本地运行

先按仓库中的构建要求准备环境，然后克隆仓库，用 pnpm 安装依赖并启动引擎，命令是 pnpm run dev。首次构建需要编译 Rust 核心及其依赖，所以要多等一会儿，之后的构建会复用缓存。启动后，wrangler 会在 127.0.0.1:8787 开启本地开发服务器。你可以在 Chrome DevTools 中打开这个地址试用页面，也可以用 Node.js 脚本配合 puppeteer-core，把 browserWSEndpoint 指向本地的 devtools/browser 地址，再打开页面并截图。官方还建议把你的 AI 框架直接指向本地 CDP 端口，让智能体完全控制 Kitesurf。

部署到自己的账户

本地修改和测试完成后，可以把引擎部署到自己的 Cloudflare 账户，不再使用 Cloudflare 提供的 Browser Run 托管接口。需要注意，部署需要 Workers 付费计划，因为 Kitesurf 使用 Dynamic Workers 为页面创建相互隔离的 Workers。在仓库根目录运行 pnpm run deploy 即可。

参与贡献与现状

和 Cloudflare 其他开源项目一样，Kitesurf 在 GitHub 上欢迎复刻和贡献。但官方明确提醒：项目仍在快速开发中，当前重点是提高引擎的兼容性（可以参考 Web Platform Tests 的进展）、可靠性和效率。想贡献的人应先阅读贡献指南，提交带最小复现或方案思路的议题，并在提交拉取请求之前获得维护者的认可。范围明确、带测试和证据的小修复，比大规模重写更容易审查。贡献不一定是代码：一个能复现渲染错误的小页面、一个失败的自动化流程，或一处文档更正，同样有价值。

对开发者意味着什么

对做智能体和自动化的团队来说，这件事有两层意义。其一，浏览器引擎本身可以自托管，不再只能依赖托管服务，代码可审查、可修改。其二，它走的是"不用浏览器容器"的路线，如果兼容性足够，在成本和扩展上可能有优势。不过官方也坦率说明，兼容性仍在改进，团队公布了 Web Platform Tests 的进展页面和基准测试页面，开发者在采用前应当用自己的目标网站做验证。

值得留意的几点

第一，Kitesurf 的许可证是 Apache 2.0，使用和修改的限制相对宽松，但它依赖的 Blitz、Stylo、Boa 等组件各有各的许可证，企业在引入前应对照仓库中的 NOTICE 文件做合规检查。第二，部署要求 Workers 付费计划，个人开发者做试验时应先确认成本。第三，官方强调项目处于快速开发期，接口和行为可能变化，不宜在没有回归测试的情况下直接用于关键业务流程。第四，Kitesurf 把 JavaScript 的执行优先放在 Dynamic Workers 里，只有在无法这样做时才退回 WebAssembly 中的 Boa，这意味着不同页面的执行路径和表现可能不同，排查问题时需要留意。

后续动向

官方建议读者关注 Cloudflare 的博客和更新日志，以及项目的官方落地页，那里会持续公布标准兼容性的 Web Platform Tests 结果和基准测试。团队也在 Discord 上开放交流。作者在文末写道，他们正在打造一个面向智能体的浏览器，希望更多人参与改进。