Cloudflare 发布 Kitesurf：跑在 Workers 上的 Agent 专用浏览器，内存比 Chromium 省 7 倍

原文来源：Cloudflare Blog — Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers — Cloudflare 发布了完全跑在 Workers 上的 Agent 优先浏览器 Kitesurf，用 V8 isolate 替代 Chromium，内存和 CPU 消耗大幅下降。

"我们该不该自己造个浏览器？"这个问题，Cloudflare 内部每隔几个月就会冒出来一次，然后被反复搁置。理由很充分：浏览器是我们每天用到的、最重要的软件，几乎是互联网的操作系统——但造一个浏览器的技术难度，和它要解决的问题之间，一直找不到平衡点。

直到现在。两个趋势同时成熟：Developer Platform 上的一批底层能力（WebAssembly、Dynamic Workers、SQLite 版 Durable Objects、Worker 间 RPC）终于够用了；而 AI Agent 的爆发，让"一种新的浏览器"成了刚需。

Agent 不需要标签页和主题

问题出在 Chromium 这类浏览器引擎是为人类设计的，不是为 Agent 设计的。AI 模型用浏览器时：

• 不在乎标签页、主题、扩展、跨设备同步。它只关心 token 数、上下文窗口、可扩展性、性能和成本。
• 不要求像素级完美渲染、60fps 平滑滚动。CSS 解析稍微有点偏差没关系，机器可读的结构化内容才重要。
• 威胁模型完全不同。Prompt 注入和工具安全成了头等大事。

而 Chromium 的内存和计算开销，让"给每个 Agent 开一个浏览器实例"贵得离谱。Cloudflare 内部讨论 12 周后，答案罕见地一致：造！

于是有了 Kitesurf——一个完全跑在 Workers 上的浏览器，专为 Agent 设计，目前在 Browser Run 里免费公测。它从 obscura（一个 Rust 写的无头引擎，"没有 Chrome、没有 Node.js、没有依赖"）获得灵感，团队甚至用 AI Agent 帮忙把它移植到 Workers 上——给了 AI 一个清晰的计划和成功定义，让它能无限循环迭代，居然真跑通了。

三个核心组件

Kitesurf 处理一次请求的生命周期，由三个组件完成：

SandboxOutbound worker：唯一能碰网络的组件。浏览器的职责是渲染不可信的网页——图片、字体、CSS、JS、Wasm 文件全都要从互联网抓取，这是浏览器最危险的操作。Kitesurf 把所有出站流量收敛到这一个组件，由 Dynamic Workers 强制：执行 CORS、注入浏览器风格的请求头、过滤响应、每个页面的 cookie 各归各的 jar。不符合策略的一律 403——每个组件只拿到它严格需要的网络权限。

Engine（引擎）：Kitesurf 唯一对外公开的组件。处理 Chrome DevTools Protocol（CDP）的 WebSocket 和 HTTP REST API，最重要的是存储每个会话的状态，其余组件全部无状态。用 CDP 的好处是客户端兼容性：Puppeteer、Playwright、chrome-remote-interface，甚至 Chrome DevTools 前端，指过来就能用。

PageScript：每个页面或跨进程 iframe 用 Dynamic Workers 拉起一个长期存活的 isolate，处理页面会话——一个干净的 globalThis 加 DOM 文档对象。HTML 和 CSS 解析用了 Blitz（DioxusLabs 的模块化渲染引擎，Rust 写的）和 Stylo（Firefox 的高性能 CSS 解析器）。找到的每个 <script> 标签或 .wasm 文件，都在同一个 isolate 里执行 JS 和 WebAssembly。

PageRenderer：负责把算好的页面对象变成真正的像素。和 Engine 循环配合：每次需要一帧，PageRenderer 从 PageScript 拿页面对象（也叫 scene），从 Static Assets 拉内部字体和图片，光栅化成图像缓冲，再以 JPEG/PNG/PDF 格式返回给客户端。底层是 Blitz 的 blitz-paint 模块，用 Parley 做字形塑造、字体选择和文本换行。

一个有趣的细节是 eval 处理：Workers 出于安全原因还不支持原生 eval，但网页代码里偶尔会出现 eval。Kitesurf 的解决方案是用 Boa JS（一个 Rust 写的 ECMAScript 引擎）在 Workers 上编译运行——等于在一个运行时上再套一个运行时，效率不高但能用。等 Workers 原生支持 eval 后就会迁移走。

性能：CPU 和内存省 3-7 倍

Kitesurf 已经通过 21.5 万+ 个 Web Platform Tests（WPT），每周还在增加几百个。Agent 关心的部分（CSS、DOM、HTML、selection、SVG、XHR）覆盖率已经很好了。

实测数据（14 个 URL 语料、5 次 Browser Run quick-action 的中位数）：

Chromium 赢在秒表上——JIT 已经见过这个页面，冷启动的软件渲染器当然比不过，目前差距约 1.7 倍，主要来自光栅化和 JPEG/PNG 编码，还在继续优化。但 Kitesurf 在真正决定账单的内存和 CPU 上赢 3-7 倍。内存少意味着能跑更多会话、扩展性更好，从根上降低双方的成本。

当然，最重要的测试是：Kitesurf 能跑 Doom。Cloudflare 多年前在 Workers 上做过多人在线 Doom 实验，现在用 Kitesurf 打开那个页面，一切正常。

怎么用：加一个参数的事

Browser Run 的 CDP 端点现在支持 browser=kitesurf 参数，现有的 Puppeteer、Playwright、chrome-remote-interface，或者任何会说 MCP 和 CDP 的 AI Agent 都能直接用。比如配 Opencode 的 MCP：

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": ["npx", "-y", "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <API_TOKEN>\"}"],
      "enabled": true
    }
  }
}

Quick Actions 也一样，加个参数就能用：

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/screenshot?browser=kitesurf' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{"url": "https://example.com"}' \
  --output "screenshot.png"

还有个公开的 Kitesurf Playground（kitesurf.cloudflare.app），输入任意 URL 看渲染效果，还内置了 Chrome DevTools——可以检查展开的 DOM、读控制台消息、看网络活动，甚至用 Memory 面板看每个 isolate 的 WebAssembly 占用。

现在还不行的

需要播放视频、渲染 WebGL、跟需要真实 TLS 指纹的 bot 挑战握手、或者开一个需要持久状态的十分钟长会话——这些 Kitesurf 目前还做不了，得用 Browser Run 默认的 Chromium。

本质上，Kitesurf 是一个为任务而生的临时引擎：完全隔离、无状态、只为任务存续期间存在，非常适合 AI 驱动的突发性负载。它才 12 周大，第一个 commit 还是今年 5 月的事。接下来 Cloudflare 在扩充 CDP 覆盖、提升渲染保真度（LLM 往往从图片里理解得比文本好）、继续刷 WPT 通过率，并计划把它开源。