公测中 · 在 Browser Run 中免费使用

为 AI 智能体
重新发明浏览器

Kitesurf 是 Cloudflare 全新推出的无状态、可高度扩展的浏览器，完全运行在 Workers 之上。它不再运送整个桌面浏览器引擎，而是专注于对智能体真正重要的事情——token 数量、上下文窗口、扩展性、性能与成本，并主动舍弃只有人类才需要的特性：标签页、主题、扩展程序、像素级完美渲染。

查看代码示例了解架构原理

3.8×

CPU 消耗更低

HTML 提取任务

7.0×

内存消耗更低

HTML 提取任务

235K+

WPT 子测试通过

每周新增数百项

12 周

从零到发布

完整浏览器引擎

我们应该为每一个智能体提供一个在「对 AI 模型重要的事情」上表现卓越的浏览器，即使这意味着在「只对人类有用的东西」上做到极简。

— Cloudflare 工程团队

问题所在

浏览器引擎是为人类而生的，
智能体需要的是另一种东西

Browser Run 作为 Cloudflare 的无头浏览器自动化 API 产品，随着 AI 的兴起迎来了爆发式增长。智能体需要浏览器才能完成大量任务——在很多场景下，没有浏览器它们根本无法成功。

为错误的用户优化

像 Chromium 这样的浏览器引擎是为人类设计的，不是为智能体设计的。它们携带了大量 AI 模型根本不需要的开销：标签页管理、主题系统、扩展程序框架、无障碍树、动画合成器、像素级完美的排版微调……这些都是给眼睛看的，不是给模型读的。

成本高到无法普及

它们消耗的内存与算力如此之大，以至于为每个智能体提供独立实例的成本高到不可承受。单次截图任务，Chromium 需要 271 MiB 内存；HTML 提取需要 273.7 MiB。当你要并发运行成千上万个智能体会话时，这个数字会直接决定你的商业模式是否成立。

把 Web 锁在门外

这种成本结构导致互联网的大部分内容只对最昂贵、参数化知识最丰富的 AI 模型开放，而把大量其他智能体应用完全锁在门外。一个小型的、专用的智能体本该能访问网页，但浏览器的成本让它连门都进不去。

决策时刻

面对这些认知，Cloudflare 团队在 12 周前再一次问出了那个问题：「我们应该自己造一个浏览器吗？」这一次，答案是一致同意：应该！

设计哲学

能无状态的地方，就应该无状态

Kitesurf 的每一个架构决策，都可以追溯到一条核心原则。

状态是让失败变得昂贵的东西

如果没有任何东西需要重建，那么从崩溃中恢复就只是「启动一个新的，然后重放请求」而已。无状态组件天然是可丢弃的，也天然是并行的：它一卡住你就可以立刻杀掉它，你可以同时跑一千个，你可以按需求量调整它们的规模，而不是维持一堆预热的实例。

这与自动化场景完美契合——负载是爆发式到来的，而最经济的做法就是启动一份「只按实际用量计费、用完即消失」的工作。简而言之：任何组件只要能做到无状态，就应该做到无状态。

用完即弃

每个 Isolate 廉价且可抛弃，失败的 RPC 调用可以安全地终止并重启，无需担心状态污染。

天然并行

没有共享状态意味着没有锁竞争，同时运行上千个渲染会话不会互相干扰。

按需伸缩

不需要维护温热的浏览器池，规模完全跟随实际请求量，爆发式负载零预热成本。

自包含且可重试

每次渲染请求都是自包含的原子操作，天然支持重试而不会产生副作用。

核心特性

为智能体而优化的每一处细节

Kitesurf 不是一个精简版的 Chromium，而是从第一性原理出发、为一类全新用户重新设计的浏览器。

极致轻量

在截图与 HTML 提取等常见智能体任务上，CPU 消耗降低 3.1–3.8 倍，内存消耗降低 4.7–7.0 倍。这意味着相同的预算下可以运行更多会话。

完全无状态

除了保存会话状态的 Engine 组件，其他所有组件都是无状态的。为短促的、AI 驱动的爆发式负载而生，任务结束即刻消失。

CDP 协议兼容

完整支持 Chrome DevTools Protocol 的 WebSocket 与 HTTP REST API。现有的 Puppeteer、Playwright、chrome-remote-interface，甚至真实的 Chrome DevTools 前端，指向 Kitesurf 就能直接工作。

全球边缘原生

依托 Cloudflare Workers 平台运行，天然具备全球分布、自动扩展、就近执行能力，无需管理任何基础设施。

严格标准合规

通过 Web Platform Tests 中超过 23.5 万个子测试， DOM 97%、HTML 96%、Selection 99%、Encoding 99%，且每周新增数百项通过测试。

Quick Actions 就绪

与 Browser Run 的一次性动作无缝集成——截图、生成 PDF、HTML 提取，一个 HTTP 请求即可完成，无需管理浏览器生命周期。

纵深防御沙箱

所有网络出口都被收敛到唯一的 SandboxOutbound Worker，由 Dynamic Workers 强制执行——其他任何组件都无法直接触碰网络。

Rust 驱动的引擎

HTML 与 CSS 解析基于 Blitz 模块化渲染引擎与 Stylo（Firefox 的高性能 CSS 引擎），均由 Rust 编写。

免费公测

beta 阶段在 Browser Run 中完全免费使用。只需在端点加上 browser=kitesurf 参数即可切换。

架构深度剖析

一个请求的完整生命周期

Kitesurf 由四个关键组件构成：SandboxOutbound（网络出口）、 Engine（协议与会话）、PageScript（解析与执行）、 PageRenderer（栅格化）。它们通过 Workers 内置的 RPC 系统协同工作。

客户端

Puppeteer / Playwright / MCP

CDP

Engine

唯一公网组件 · 持有会话状态

RPC

PageScript

HTML/CSS 解析 · JS 执行 · DOM

Scene

PageRenderer

栅格化 → PNG / JPEG / PDF

网络出口

SandboxOutbound

要渲染一个不可信的网页，浏览器必须从互联网上抓取任意资产——图片、字体、CSS、JavaScript、Wasm 文件。这是浏览器能做的最危险的操作之一。

Kitesurf 把这件事收敛到唯一一个组件：SandboxOutbound worker。除它之外，任何组件都无法直接接触网络——这一约束由 Dynamic Workers 强制执行。 Engine 用它来引导页面（抓取主文档与脚本），PageScript 用它抓取其余一切：样式表、图片、字体，以及页面自身发起的 fetch() 调用。

强制执行 CORS 策略
注入符合浏览器形态的请求头
过滤响应内容
为每个页面维护独立的 Cookie Jar
任何违反策略的请求直接返回 403

每个组件只获得它精确需要的网络权限，不多一分。

协议层

Engine

Engine 是 Kitesurf 唯一面向公网的组件。它处理 CDP WebSocket 与 HTTP REST API，提供一个用于内部测试的着陆页，以及最重要的——存储每一个会话的状态。其他所有组件都是无状态的。

使用 CDP 带来的最大好处是客户端兼容性： Puppeteer、Playwright、chrome-remote-interface，以及真实的 Chrome DevTools 前端——把它们指向 Kitesurf，全都能直接工作。这也正是 Browser Run 本身的工作方式。

与名字给人的感觉相反，Engine 其实是 Kitesurf 中最简单的组件。

解析与执行

PageScript

PageScript 展示了 Workers 新特性的威力——具体来说是 Dynamic Workers。在这个特性出现之前，Kitesurf 根本不可能实现。

每一个新页面或跨进程 iframe（OOPIF）都会通过 Dynamic Workers 启动一个长生命周期的 PageScript isolate 来处理该页面会话，其中包含一个干净的 globalThis 和 DOM document 对象。

随后，DOM 对象会被 HTML 文档解析结果与所有 JavaScript 脚本的执行结果填充。 HTML 与 CSS 的解析使用了 Blitz（模块化渲染引擎）的一部分，以及 Stylo（Firefox 的高性能 CSS 解析器）——两者均由 Rust 编写。

对于每一个发现的 <script> 标签或 .wasm 文件， JavaScript 与 WebAssembly 代码都在同一个 isolate 内执行。

那么 eval 怎么办？

eval 更棘手：出于安全原因，Workers 目前仍不原生支持 eval。也不能为它单独开一个 isolate——那样就访问不到 globalThis 了。

Cloudflare 的解决方案是使用 Boa JS——一个用 Rust 编写的 ECMAScript 引擎，编译后在 Workers 上运行。这本质上是在一个运行时之上再跑一个运行时，听起来不够优雅，确实也不优雅，但它足以应付代码中偶尔出现的 eval。等 Workers 原生支持 eval 落地后，团队会迁移离开 Boa。

栅格化

PageRenderer

这个组件的职责是从计算好的页面对象生成真实的像素。

PageRenderer 与 Engine Worker 以循环方式协作。每当引擎需要一帧画面时， PageRenderer 从 PageScript 获取页面对象（也称为 scene / 场景），从 Static Assets 抓取内部字体与图片，把一切栅格化进一个图像缓冲区，然后以客户端可以直接展示的格式（JPEG / PNG / PDF）把缓冲区返回给引擎。

这里的很大一部分魔法由另一个 Blitz 模块 blitz-paint 完成，它又依赖 Parley 来把字符整形成字形（glyph）、选择字体、以及断行。

Workers 内置 RPC：同一个应用，多个 isolate

Cloudflare Workers 内置了一套 RPC 系统，允许你调用其他 Worker 的方法、在它们之间传递对象、以及调用这些对象上的方法。 你不需要关心 API schema、类型或鉴权—— 直接 remoteFunction(...params) 就能工作。你既享受了远端 Worker 的隔离性与资源，又没有失去用 JavaScript 在本地访问所有函数的便利。

Kitesurf 正是使用这套 RPC 系统：Engine Worker 通过一次单独的调用 向 PageRenderer Worker 发起 renderFrame()，并得到一张 PNG 作为结果。由于渲染器不持有任何页面状态（只有一个可丢弃的缓存），引擎可以在任何失败或卡住的 RPC 调用上安全地杀掉并重启它—— 这让每次渲染请求都是自包含的、可重试的，而它的 isolate 廉价且用完即弃。

技术栈

站在 Rust 生态的肩膀上

Kitesurf 并非从零重写一切，而是精心挑选并组合了一批高质量的开源组件。

Blitz

模块化渲染引擎

提供 HTML 解析与布局能力的 Rust 渲染引擎，Kitesurf 使用了其中的部分模块。

Stylo

CSS 解析与样式计算

Firefox 使用的高性能 CSS 引擎，同样由 Rust 编写，负责样式解析与级联计算。

blitz-paint

绘制与栅格化

Blitz 的绘制模块，负责把场景对象转换为图像缓冲区中的实际像素。

Parley

文本整形与排版

负责把字符整形成字形（glyph）、选择合适的字体，以及处理文本断行。

Boa JS

eval 的 ECMAScript 引擎

用 Rust 编写的 JS 引擎，编译后在 Workers 上运行，专门用于处理 eval 调用。

Workers RPC

组件间通信

Cloudflare Workers 内置的 RPC 系统，无需 schema 与鉴权即可跨 isolate 调用。

Dynamic Workers

动态 isolate 编排

让 Kitesurf 能够按需为每个页面/OOPIF 启动隔离的 PageScript isolate。

CDP

对外协议

Chrome DevTools Protocol，保证与现有浏览器自动化生态的完全兼容。

与 Chromium 的对比

赢在账单，输在墙钟

下表基于 14 个 URL 语料库上 5 次 Browser Run Quick Action 运行的中位数，比较 Chromium（热池）与 Kitesurf 在相同任务下的表现。

指标	Kitesurf	Chromium（热池）	Kitesurf 相对表现
CPU截图	380 ms	1,173 ms	↓CPU 消耗降低 3.1×
CPUHTML 提取	229 ms	877 ms	↓CPU 消耗降低 3.8×
内存截图	57.8 MiB	271.0 MiB	↓内存消耗降低 4.7×
内存HTML 提取	39.4 MiB	273.7 MiB	↓内存消耗降低 7.0×
时间截图墙钟	1,148 ms	637 ms	↑比 Chromium 慢 1.8×
时间HTML 提取墙钟	820 ms	472 ms	↑比 Chromium 慢 1.7×

Kitesurf 赢在哪里

内存与 CPU——也就是真正决定你账单的东西，领先 3–7 倍。对于爆发式、AI 驱动的负载，这直接转化为「相同预算下能跑多少个会话」。

Chromium 赢在哪里

墙钟时间。原因很直白：一个预热好的 JIT 编译器，总是会赢过一个冷启动的软件渲染器。如果延迟是你的第一优先级，Chromium 仍是更好的选择。

Web Platform Tests

通过 235,000+ 项 WPT 子测试

Kitesurf 使用 Web Platform Tests 进行标准符合性验证—— 这是业界用于衡量对 W3C 标准兼容程度的共享测试套件。对智能体最关键的那些领域，覆盖率尤为强劲，且每周新增数百项通过的测试。

DOM

97%

HTML

96%

Selection

99%

SVG

97%

Encoding

99%

CORS

95%

XHR

95%

URL

83%

Kitesurf 目前已能正确渲染 TodoMVC（vanilla / React / Vue / Angular / Preact）、 Wikipedia、Hacker News、 Cloudflare Blog，以及大部分 Cloudflare Dashboard。团队将持续提升 WPT 通过率，以支持更复杂的网页。

使用场景

何时该用，何时别用

Kitesurf 并非要替代 Chromium，而是为一类特定负载提供更经济、更可扩展的选择。诚实地划清边界，比夸大能力更有价值。

✓非常适合

AI 智能体渲染网页 需要渲染页面，但可以接受「不是全功能、非像素级完美的 Chromium」这一权衡。
一次性 Quick Actions 从页面提取内容、为兼容站点生成 PDF 或截图的自动化与应用程序。
爆发式 AI 负载 受益于短生命周期、完全隔离、无状态引擎的工作流——只在任务持续期间存在。
大规模并发抓取 需要同时运行大量会话，且内存/CPU 成本是主要瓶颈的场景。

×暂不适用

播放视频或渲染 WebGL Kitesurf 目前不支持视频解码与 WebGL 上下文。
机器人挑战握手 需要真实 TLS 指纹来通过 bot-challenge 的场景。
长期认证会话 需要持久状态的长时间运行的已登录会话。
像素级完美渲染 需要视觉回归测试或精确排版校验的场景。

上述场景请使用 Browser Run 默认浏览器（由 Chromium 提供）。

判断某个站点是否兼容的最佳方式，就是直接试一下。 可以通过 CDP 端点、Quick Actions，或者在公开的 Playground 中输入 URL 实测。

开始使用

一个参数，即刻切换到 Kitesurf

Browser Run 的 CDP 端点与 Quick Actions 都支持 Kitesurf。只需在端点 URL 中加入 browser=kitesurf 参数—— 你现有的 Puppeteer、Playwright、chrome-remote-interface，或任何会说 MCP 与 CDP 的 AI 智能体，都能立刻工作。

shell · 使用 Kitesurf 生成页面截图

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

仅需在 Quick Action 端点后追加 ?browser=kitesurf，其余参数与默认浏览器完全一致。

shell · 把网页渲染为 PDF

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/pdf?browser=kitesurf' \
  -H 'Authorization: Bearer <API_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://en.wikipedia.org/wiki/Kitesurfing"
  }' \
  --output "page.pdf"

PDF 由 PageRenderer 直接从场景对象栅格化生成，不经过额外的打印管线。

javascript · 通过 CDP 端点连接 Puppeteer

import puppeteer from 'puppeteer-core';

// 唯一的区别：在 wsEndpoint 上加入 browser=kitesurf
const browser = await puppeteer.connect({
  browserWSEndpoint:
    `wss://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/browser-run/devtools/browser?browser=kitesurf`,
  headers: { Authorization: `Bearer ${API_TOKEN}` },
});

const page = await browser.newPage();
await page.goto('https://developers.cloudflare.com', {
  waitUntil: 'networkidle0',
});

// 提取 HTML 供 LLM 消费
const html = await page.content();

// 或者直接截图
await page.screenshot({ path: 'shot.png' });

await browser.close();

Engine 组件完整实现了 CDP WebSocket，因此 Puppeteer 的绝大多数 API 无需改动。

javascript · 通过 CDP 端点连接 Playwright

import { chromium } from 'playwright-core';

const browser = await chromium.connectOverCDP(
  `wss://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/browser-run/devtools/browser?browser=kitesurf`,
  { headers: { Authorization: `Bearer ${API_TOKEN}` } }
);

const context = browser.contexts()[0] ?? await browser.newContext();
const page = await context.newPage();

await page.goto('https://news.ycombinator.com');

// 提取结构化数据交给智能体处理
const titles = await page.$$eval('.titleline > a', els =>
  els.map(e => ({ text: e.textContent, href: e.href }))
);

console.log(titles);
await browser.close();

使用 connectOverCDP 而非 launch，因为浏览器运行在 Cloudflare 边缘而非本地。

json · 在 MCP 客户端中配置 Kitesurf

{
  "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
    }
  }
}

任何支持 MCP 的 AI 智能体都可以通过这个配置获得浏览器能力。

将 <ACCOUNT_ID> 替换为你的 Cloudflare 账户 ID，将 <API_TOKEN> 替换为 Browser Run API 令牌。

常见问题

你可能想知道的

Kitesurf 是要替代 Chromium 吗？

不是。Kitesurf 是 Browser Run 中的一个可选浏览器，适用于「能接受非像素级完美渲染、但在意成本与扩展性」的场景。需要视频、WebGL、真实 TLS 指纹或长期认证会话时，仍应使用由 Chromium 驱动的 Browser Run 默认浏览器。

为什么 Kitesurf 的墙钟时间反而更慢？

因为 Chromium 那一侧使用的是预热的进程池（warm pool），其 JIT 编译器已经完成预热；而 Kitesurf 使用的是冷启动的软件渲染器。一个预热好的 JIT 编译器在单次任务的响应时间上会赢过冷启动的软件渲染路径。

但 Kitesurf 赢在 CPU 时间与内存占用——这两者才是真正决定账单的指标。对于爆发式并发负载，总吞吐量与单位成本远比单次延迟更重要。

我需要改动现有代码吗？

基本不需要。Kitesurf 实现了 Chrome DevTools Protocol，所以只需在端点 URL 中追加 browser=kitesurf 参数。 Puppeteer、Playwright、chrome-remote-interface，甚至真实的 Chrome DevTools 前端都能直接连上。

怎么判断我的目标站点是否兼容？

官方建议：直接试一下。你可以通过 CDP 端点、Quick Actions，或者在公开的 Kitesurf Playground 中输入 URL 实时查看渲染结果并与页面交互。

目前已确认能正确渲染的站点包括 TodoMVC（vanilla / React / Vue / Angular / Preact）、 Wikipedia、Hacker News、Cloudflare Blog，以及大部分 Cloudflare Dashboard。

渲染不可信网页的安全性如何保障？

抓取任意外部资产是浏览器最危险的操作之一。Kitesurf 把所有网络出口收敛到唯一一个 SandboxOutbound Worker，这个约束由 Dynamic Workers 在平台层面强制执行—— 其他任何组件都无法直接触碰网络。

SandboxOutbound 负责强制 CORS、注入符合浏览器形态的请求头、过滤响应、为每个页面维护独立的 Cookie Jar。任何违反策略的请求直接返回 403。每个组件只拿到它精确需要的网络权限。

Kitesurf 支持 eval 吗？

支持，但走的是一条特殊路径。出于安全原因，Workers 目前不原生支持 eval，也无法为它单独开一个 isolate（那样就访问不到 globalThis）。

解决方案是使用 Boa JS——一个用 Rust 编写、可编译到 Workers 上运行的 ECMAScript 引擎。这相当于在一个运行时之上再跑一个运行时，并不优雅，但足以应付代码中偶尔出现的 eval。等 Workers 原生支持落地，团队会迁移离开 Boa。

Kitesurf 现在收费吗？

Beta 阶段在 Browser Run 中完全免费使用。 这是官方公告中明确说明的——「available for free while in beta in Browser Run」。

「Kitesurf」这个名字有什么含义？

Kitesurf（风筝冲浪）是一项依靠风筝牵引、以最少装备在水面上高速滑行的运动—— 这恰好呼应了 Kitesurf 的设计理念：用最轻的装备，获得最大的推进力。没有引擎，没有重量，只有必要的东西。

开始你的第一次飞行

无需写一行代码，直接在 Playground 里试试

在公开的 Kitesurf Playground 中输入任意 URL，即可实时查看渲染效果并与页面交互—— 零配置、零成本、零风险。

阅读官方文档深入技术博客

为 AI 智能体 重新发明浏览器

浏览器引擎是为人类而生的，智能体需要的是另一种东西

为错误的用户优化

成本高到无法普及

把 Web 锁在门外

能无状态的地方，就应该无状态

状态是让失败变得昂贵的东西

用完即弃

天然并行

按需伸缩

自包含且可重试

为智能体而优化的每一处细节

极致轻量

完全无状态

CDP 协议兼容

全球边缘原生

严格标准合规

Quick Actions 就绪

纵深防御沙箱

Rust 驱动的引擎

免费公测

一个请求的完整生命周期

SandboxOutbound

Engine

PageScript

PageRenderer

站在 Rust 生态的肩膀上

赢在账单，输在墙钟

通过 235,000+ 项 WPT 子测试

何时该用，何时别用

✓非常适合

×暂不适用

一个参数，即刻切换到 Kitesurf

你可能想知道的

无需写一行代码，直接在 Playground 里试试

为 AI 智能体
重新发明浏览器

浏览器引擎是为人类而生的，
智能体需要的是另一种东西