AI 模型与平台
Cloudflare 为 AI 智能体开源 Kitesurf 浏览器引擎
将 Unite.AI 添加到您在 Google 上的首选来源
要点Kitesurf replaces Chrome with a lighter engine that renders pages and runs JavaScript…
查看更多
- Kitesurf replaces Chrome with a lighter engine that renders pages and runs JavaScript for AI agents.
- Self-hosting shifts security to operators because the engine ships without authentication and exposes a public URL.
- Kitesurf remains experimental with incomplete Chrome compatibility despite its efficiency gains for agent workloads.
Cloudflare 于 2026 年 11 月 13 日宣布，其面向 AI 智能体的实验性浏览器引擎 Kitesurf 现已根据 Apache 2.0 许可证开源。开发者可以查看和修改代码、在本地运行，也可以将自己的实例部署到 Cloudflare Workers 上。
公开代码仓库让开发者可以选择在自己的 Cloudflare 账户中运行和修改该引擎，而不必只依赖 Cloudflare 托管的 Browser Run API。Cloudflare 在 2026 年 8 月 6 日推出 Kitesurf时就承诺会采取这一步，并在 2026 年 9 月 28 日的更新中再次作出承诺；该更新增加了对 WebMCP 的支持，扩展了浏览器 API 和 Browser Run 的覆盖范围，并引入了终端渲染功能。
深入了解 Kitesurf 面向智能体的设计
Kitesurf 无需 Chrome 或浏览器容器，即可将 HTML 和 CSS 渲染为页面、执行页面 JavaScript 并生成屏幕截图。它提供 Chrome DevTools Protocol (CDP) 端点——这是 Chrome DevTools 和兼容自动化软件使用的控制接口——让 Puppeteer 客户端和 AI 智能体运行框架能够连接。
在内部，Engine 负责协调浏览器会话和客户端连接，PageScript 负责运行页面及其 JavaScript，PageRenderer 则生成视觉呈现结果。该引擎将 Cloudflare 的开发者平台与编译为 WebAssembly 的 Rust 组件结合起来：Blitz 提供 HTML 解析、DOM、布局和绘制功能；Stylo 负责处理 CSS；Linebender 库用于文本和 2D 图形；Krilla 则生成 PDF 输出。当页面代码无法在 Dynamic Workers 中运行时，Boa 会在 WebAssembly 内提供备用 JavaScript 运行时。
Cloudflare 表示，其设计目标是让智能体以低于完整 Chromium 浏览器的 CPU 和内存用量，获得所需的网络访问能力，同时根据需求在其 Workers 网络中扩展规模。原始架构将每次页面加载都视为不可信输入，并根据各组件所需的资源将其隔离。专用的 SandboxOutbound worker 负责所有外部请求，执行网络策略并确保每个页面的 Cookie 相互隔离；其他组件无法直接访问网络。
无状态也是这套设计的一部分。Engine 保留会话状态，而其他组件则尽可能设计为可随时销毁，从而使容量能够随智能体活动的突发增长而调整。PageRenderer 不保存持久的页面状态，因此在渲染请求失败或卡住后，Engine 可以将其替换。
自行托管的要求与安全性
本地开发需要 Bazelisk、Node.js 22 或更高版本，以及 pnpm 9.15.4。开发命令会构建 WebAssembly 模块、页面和渲染器捆绑包，随后在 127.0.0.1:8787 启动本地引擎。首次构建会编译 Rust 核心及供应商打包的依赖项，之后的构建则会复用 Bazel 缓存。开发者随后可以通过 Chrome DevTools 检查页面，或连接 Puppeteer 及其他 CDP 客户端。
在 Cloudflare 上部署需要 Workers 付费计划，因为 Dynamic Workers 会创建用于页面和渲染器的隔离 worker。在本地完成测试后，运营者可以将引擎部署到自己的账户，以此替代由 Browser Run 托管的 API。
自行托管也意味着运营者需要承担一项重要的安全责任。该引擎本身没有身份验证功能，其 workers.dev 地址默认公开。如果没有 Cloudflare Access 或其他身份验证层，任何获得该 URL 的人都可以通过引擎浏览网页、连接 CDP 客户端、发出由运营者的 Cloudflare 账户处理的请求，并消耗付费 CPU 时间和 Dynamic Workers。代码仓库要求运营者立即保护该 URL，并说明如何在部署前为整个账户启用 Access，以避免出现公开访问的时间窗口。
实验阶段与贡献流程
Kitesurf 仍处于实验阶段，正在积极开发中。代码仓库将其描述为 CDP 端点，而非完整的 Chrome 实现；部分 Chrome DevTools 功能目前仍不受支持。Cloudflare 正优先推进兼容性、可靠性和效率。
在 8 月发布时，Cloudflare 表示，Kitesurf 当时尚不适用于视频、WebGL、需要真实 TLS 指纹的机器人挑战握手，以及依赖持久状态的长时间身份验证会话。这些限制说明，即使轻量级浏览器的资源占用颇具吸引力，在智能体工作负载中仍有必要检查兼容性。
贡献流程围绕这项持续推进的工作进行组织。Cloudflare 要求有意贡献代码的开发者先提交问题报告，附上最小复现案例或拟议方案，并在提交拉取请求前获得维护者的认可。项目优先考虑范围明确、附带测试的针对性修改，同时也欢迎可复现的渲染错误、自动化工作流故障和文档修正。
对开发者而言，这种取舍很直接：他们可以直接控制浏览器技术栈，但必须自行保障部署安全，并接受该引擎对 Chrome 和 Web 平台的兼容性仍不完善这一现状。
