AI开源软件工具

Cloudflare 把「Agent 专用浏览器」开源了：内存只要 50MB，代价是比 Chrome 慢八成

2026年11月15日1 次阅读
Cloudflare 把「Agent 专用浏览器」开源了：内存只要 50MB，代价是比 Chrome 慢八成
📅 2026 年 11 月 14 日 · 事件日期 2026 年 11 月 13 日 · 分类：AI开源软件工具
CloudflareKitesurfBrowserCDPApache 2.0Agent

3分钟看懂

Cloudflare 在 11 月 13 日把 Kitesurf 开源了，许可证是 Apache 2.0。项目地址 github.com/cloudflare/kitesurf。

一句话概括：它让 AI Agent 打开网页这件事，不再需要为每个任务启动一个 Chromium。

官方自己跑的对比数据（38 个网页各跑 5 次取中位数，2026-11-14 02:40 UTC 那次）：

  • 截图任务：内存 50 MiB，对比 Browser Run 的 400 MiB、冷启动 Chrome 的 329 MiB
  • 截图任务：CPU 387 毫秒，对比 Browser Run 的 1.67 秒、Chrome 的 767 毫秒
  • 但更慢：截图墙上时间 1.79 秒，Browser Run 1.20 秒，冷启动 Chrome 1.01 秒

也就是说，它拿"单次更慢"换了"每次便宜一个数量级"。对一天跑几十万次抓取的 Agent 平台，这笔账划得来；对只想快点截一张图的人，不划算。

50 MiB
截图任务内存占用（官方自测）
387 毫秒
截图任务 CPU 时间（官方自测）
1.79 秒
截图任务墙上时间（比 Chrome 慢）
98.3%
Web Platform Tests 子测试通过率

它到底是什么

Kitesurf 是 Cloudflare 今年 8 月推出的东西，当时叫"跑在 Workers 上的无状态浏览器"，9 月补了 WebMCP 支持和更多 API。那时候它只是 Cloudflare 自己托管的一项服务（Browser Run 的一部分）。开源的意思是：你可以把代码拉下来、改、然后部署到你自己的 Cloudflare 账号上。

它不用 Chromium，也没有浏览器容器。整套东西跑在 Cloudflare Workers 里，由几个 Rust 编译成 WebAssembly 的组件拼起来：

  • Blitz：解析 HTML、构建 DOM、布局
  • Stylo：CSS 解析与计算样式
  • Boa：JS 引擎，作为兜底（正常情况下页面 JS 跑在 Dynamic Workers 里）
  • Linebender 系列 + Krilla：文字排版、2D 图形、导出 PDF

代码分成三块：Engine 管浏览器会话和客户端连接，PageScript 跑页面和它的 JavaScript，PageRenderer 负责画出来。

关键的一点是它讲 Chrome DevTools Protocol（CDP）。这意味着 Puppeteer、Playwright 这类现成工具能直接连上去，不需要为了它换一套自动化框架。

为什么这件事值得单独说

过去两年，"让 Agent 上网"的做法基本都是：起一个无头 Chrome → 打开页面 → 截图或抽 HTML → 关掉。这条路能用，但成本结构很别扭：一个 Chromium 进程动辄几百 MB 内存，冷启动一秒上下，抓一千个页面就是一千次启动。

Kitesurf 的思路是砍掉"只有人需要"的部分——标签页、主题、扩展、像素级一致的渲染——只保留 Agent 真正在意的：能不能跑 JS、能不能拿到 DOM、能不能截图、能不能生成 PDF。

官方在文档里写得很直白：对截图和 HTML 抽取这类常见 Agent 任务，Kitesurf 用的 CPU 和内存显著少于 Chromium，所以同样的机器能跑更多会话，尤其适合忽高忽低的突发流量。

官方自测：省资源，但慢一点

Kitesurf 官网有一个持续更新的跑分页，最新一次是 2026-11-14 02:40 UTC，38 个页面，每页跑 5 次取中位数。三组对手：Kitesurf（跑在 Workers 上）、Browser Run（页面之间复用 Chrome）、Chrome 冷启动（每次新开）。

截图任务：

指标KitesurfBrowser RunChrome 冷启动
墙上时间1.79 秒1.20 秒1.01 秒
CPU 时间387 毫秒1.67 秒767 毫秒
内存50 MiB400 MiB329 MiB

抽 HTML 任务：

指标KitesurfBrowser RunChrome 冷启动
墙上时间1.37 秒1.10 秒894 毫秒
CPU 时间446 毫秒1.59 秒637 毫秒
内存29 MiB398 MiB316 MiB

三件事值得注意：

  1. 内存差 8 到 13 倍，CPU 差 3 到 4 倍，这是它真正的卖点。
  2. 墙上时间它最慢，慢 40% 到 80%。如果延迟是你的第一指标，它不适合。
  3. 这组数字是厂商自己跑的公开基准，页面、脚本、配置都由 Cloudflare 设定，不是第三方复现。当参考值看，别当定论。

兼容性方面，官网也放了 Web Platform Tests 的结果，最新一次是 2026-11-13 16:24 UTC：

  • 子测试通过率 98.3%：1,543,968 个里有 1,517,208 个通过
  • 测试文件通过率 77.3%：11,764 个里有 9,093 个
  • 跳过 56,854 个文件（其中 56,823 个是没纳入测试集，31 个标了 SKIP）

子测试通过率看着很高，但文件通过率只有七成七，说明"大部分断言能过、一部分页面整体还是不行"。官方承认这仍是实验性项目，正在补标准兼容、渲染保真度和性能。

怎么用：本地跑起来

前置条件官方列得很清楚：Node.js 22 以上、pnpm 9.15.4（仓库锁了版本）、Bazelisk（以 bazel 命令存在）、macOS 上还要装 GNU tar（brew install gnu-tar）。

第一步，拉代码装依赖：

git clone https://github.com/cloudflare/kitesurf.git
cd kitesurf
pnpm install --frozen-lockfile

第二步，启动本地引擎：

pnpm run dev

第一次构建要编译 Rust 核心和它依赖的 crate，会等挺久；之后走 Bazel 缓存就快了。引擎起在 http://127.0.0.1:8787，访问 /health 确认活着。如果 8787 被占，设 KITESURF_PORT 换端口。

第三步，用 Puppeteer 连上去：

import puppeteer from "puppeteer-core";

const browser = await puppeteer.connect({
  browserWSEndpoint: "ws://127.0.0.1:8787/devtools/browser",
});

之后 newPage()、goto()、screenshot() 都是老一套。如果你用的是自己的 Agent 框架，把 CDP 端口指给 ws://127.0.0.1:8787/devtools/browser 就行——官方在博客里的原话是"agents love CDP"。

想部署到自己的账号，在仓库根目录跑 pnpm run deploy。

适用场景：谁该用它

  • 大批量抓取的 Agent 平台：一天几万到几十万次页面加载，内存和 CPU 是主要成本项，这时候 8 倍内存差会直接体现在账单上。
  • 一次性动作（官方叫 Quick Actions）：抽正文、生成 PDF、截一张图，抓完就扔，不需要保持状态。
  • 突发流量：本来就是无状态、用完即走的设计，扩缩容不需要预热浏览器池。
  • 已经在用 CDP 的团队：不用改自动化框架，换个 endpoint 就能试。
  • 需要在国内/多区域就近渲染的服务：跑在 Workers 的全球网络上，不需要自己在每个区域养浏览器集群。

不适用场景：谁别碰

官方文档里专门有一节列了"Kitesurf 现在还做不了什么"，很实在：

  • 要放视频、要跑 WebGL：不行，这两类直接排除。
  • 要过硬碰硬的机器人挑战：它没法完成真实 TLS 指纹的握手，遇到 Cloudflare 自己的挑战页、或者别的站点的高级反爬，过不去。
  • 需要长时间保持登录态：它不做长会话，需要持久状态和身份的场景请用 Chromium。
  • 要求像素级一致：它明确放弃了 pixel-perfect 渲染，做视觉回归测试、UI 截图对比这类工作，结果会和真浏览器有差异。
  • 低延迟优先的交互：墙上时间比 Chromium 慢，实时性要求高的别选。

判断某个具体站点能不能用，最快的办法是拿它的公开 playground 试一次，或者本地起引擎打开那一页看。

避坑：最容易踩的四个点

第一，自部署必须要 Workers Paid。 Kitesurf 用 Dynamic Workers 给每个页面建隔离的 Worker，这项能力只在付费计划里。最低消费是每月 5 美元。本地开发用 wrangler dev 不需要付费。

第二，它自己没有鉴权。 官方在 changelog 里专门加了一句警告：部署上线后要自己用 Cloudflare Access 或别的认证层挡住，Kitesurf 不提供内置认证。一个能打开任意 URL、还能跑 JS 的端点裸露在公网，是现成的 SSRF 跳板。

第三，Dynamic Workers 是按"每天新建多少个"计费的。 官方定价页写的是每月含 1,000 个唯一 Dynamic Worker，超出每个每天 0.002 美元；同一个 Worker ID 加同一份代码重复调用只算一次，但代码一变或者 ID 一变就重新计。如果你的实现每次请求都 load(code) 而不给稳定 ID，会被按每次调用计费。这是最容易在账单上炸的一点。

第四，它还在实验阶段。 官方原话是 "under heavy development"，重点是补兼容性、可靠性和性能，评审能力有限。放在生产关键路径上要有回退到 Chromium 的方案。

成本和时间

  • 代码本身：Apache 2.0，免费商用。但它依赖的开源组件各有各的许可证，仓库的 NOTICE 文件里列了第三方声明，商用前值得扫一眼。
  • 托管使用：Kitesurf 目前在 Browser Run 里是 beta，按官方文档"免费、但受每个账号的限额约束"。等它转正式，会走 Browser Run 的浏览器小时计费（付费计划每月含 10 小时，超出每小时 0.09 美元）。
  • 自部署：Workers Paid 每月最低 5 美元，含每月 1,000 万次请求、3,000 万毫秒 CPU 时间、1,000 个唯一 Dynamic Worker。超出部分：请求每百万 0.30 美元，CPU 每百万毫秒 0.02 美元，Dynamic Worker 每个每天 0.002 美元。
  • 上手时间：装 Bun 之外的那套工具链（Node、pnpm、Bazelisk）大概十几分钟；第一次 pnpm run dev 的 Rust 编译是最慢的一步，取决于机器，官方没给具体时长，只提醒"给它点时间"。

行动建议

第一步，先别改代码，去 kitesurf.dev 的 playground 拿你实际要抓的两三个页面跑一遍，看渲染对不对、JS 有没有跑起来。这一步五分钟能省掉后面几小时的返工。

第二步，本地 git clone + pnpm install + pnpm run dev，用 Puppeteer 连 ws://127.0.0.1:8787/devtools/browser，把你现有脚本里的 endpoint 换掉，量一下成功率和耗时差异。

第三步，算账。把"每天抓多少次"乘上"每次省多少内存和 CPU"，再对比墙上时间变慢带来的重试成本。如果省下来的机器钱覆盖不了延迟损失，就别上。

第四步，真要上生产，先接 Cloudflare Access 挡住端点，再给 Dynamic Worker 用稳定 ID，最后留一条回退到 Chromium 的开关。

参考来源

评论

0 条已公开
登录或注册后可以参与评论。

正在加载评论...