为什么要自己做浏览器：Chromium 是给人做的

「我们该不该自己做个浏览器」这个问题，在 Cloudflare 内部每隔几个月就被提一次，提了好几年，每次都被搁置，技术难度和「能解决什么独特问题」这两头，始终没找到平衡。

这次答案变成「做」，是因为两边同时到了临界点。平台这边成熟了：Workers 上跑 WebAssembly 已经很稳，Dynamic WorkersCloudflare Workers 的一个能力：代码运行时动态创建新的隔离环境去跑另一段代码，并且能限定它能碰什么。、基于 SQLite 的 Durable Objects、Worker 之间的直接调用凑齐之后，以前做不了的复杂应用变得可能。需求那边逼上来了：Browser Run（Cloudflare 的无头浏览器自动化产品）随着 AI 起来增长很猛，Agent 干很多活离了浏览器就是不行。

卡住的地方在这儿：传统浏览器都是为人类设计的，要好看的界面、标签页、丰富的扩展、流畅的 60 帧滚动。这些东西让它极其吃内存和 CPU，吃到「给每个 Agent 配一个实例」贵得不可行。结果就是网页世界的大部分只对最贵、最聪明的模型开放，别的 Agent 应用被挡在门外。

但 AI Agent 并不需要这些花架子。他们把两边在乎的东西摆出来对了一遍，这段是全篇的思想基础：

还有一条容易被忽略：威胁模型不一样了。人开浏览器，访问的是自己认识的网站；AI 开浏览器，是被任务指到哪儿就去哪儿。提示注入、工具安全这类新问题，在这个场景里才是首要的。

于是 12 周前他们又问了一次那个老问题，这次全票通过：做。舍弃所有只有人类才需要的视觉和功能，只保留 AI 用得上的核心能力。

核心优势：省钱省资源、完全无状态、兼容性极强

一、极其省钱省资源（核心价值）

跟标准 Chromium 比，这是最直接的一笔账。对手是热池里的 Chromium，已经预热好、随时能接活的那种。

原始数字全在这儿：

小缺点 / 折中点：它在页面渲染的墙上时间（wall time）上比 Chromium 慢 1.7 到 1.8 倍。官方给的解释是：一个已经见过这个页面的即时编译器（JIT），永远比冷启动的软件渲染器快；差距主要出在光栅化和 JPEG/PNG 编码这两块，还在继续优化。用一点点等待时间换 3 到 7 倍的资源，对 AI 自动化任务来说很划算。

数据与解释均来自 Kitesurf 发布博客

二、完全无状态、高度隔离

整套东西跑在 Workers 上，每一次页面加载都当成不可信输入，每一个会话都从头开始。三个组件里只有引擎记事，其余全部无状态，没有状态要重建，从崩溃里恢复就等于重开一个再把请求放一遍。

好处很实在：某个页面崩了不会牵连整个系统，卡住的渲染可以直接杀掉重来，同时开一千个也不用一直养着它们。

三、兼容性极强：改个参数就能接上

它说的是标准的 CDPChrome DevTools Protocol，Chrome 开发者工具跟浏览器之间说话用的协议。Puppeteer、Playwright 这些自动化工具都靠它遥控浏览器。（Chrome DevTools Protocol）。这意味着你原本在用的 Puppeteer、Playwright、chrome-remote-interface，或者任何会说 MCP 和 CDP 的 AI 框架，改一个 URL 参数就能无缝切换接入，代码一行不用动。

规范符合度上，它已经通过了 WPTWeb Platform Tests，一套公开的、庞大的浏览器规范符合度测试集，用来检查一个浏览器把网页标准实现到了什么程度。（Web Platform Tests）里的 215,000 多项测试，每周还在加几百项。

分区看更能说明问题：Agent 真正用得上的那几块覆盖不错，但同一张表上也摆着明显偏低的：

最后是那项传统测试：它能跑 Doom。他们的原话是，不管你有多少测试，一个项目不跑起 Doom 就不算真的完成。

技术架构：三个模块加一个网络出口

整张图最该记住的是三件事：谁有状态、谁无状态、谁能碰网络。

Engine（引擎）：唯一对外的组件，接 CDP 的 WebSocket 和 HTTP 接口，并且存着每个会话的状态。名字听着最唬人，反而是三个组件里最简单的一个。

PageScript（脚本与解析）：每打开一个新页面或跨进程 iframe，就用 Dynamic Workers 起一个长生命周期的隔离环境，里面有干净的全局对象和 DOM 文档。HTML 和 CSS 的解析用了 Blitz（模块化渲染引擎）和 Stylo（Firefox 的高性能 CSS 解析器）的一部分，两个都是 Rust 写的。

这里有个细节值得说：网页里的 eval 怎么办？ Workers 出于安全原因至今不原生支持 eval；又不能另起一个隔离环境去处理，因为那样就拿不到页面的全局对象了。他们的解法是用 Boa JS（一个 Rust 写的 JavaScript 引擎）编译到 Workers 上跑。等于在一个运行时上面再跑一个运行时，他们自己承认这看着不优雅，实际上也确实不优雅，但足够应付代码里偶尔出现的 eval。等 Workers 原生支持 eval，就把 Boa 换掉。

PageRenderer（渲染）：从 PageScript 拿到算好的页面对象（他们叫「场景」），取字体和图片，光栅化成图像缓冲，按客户端要的 JPEG / PNG / PDF 返回。它不持有页面状态，只有一份可丢弃的缓存，所以这次调用失败或者卡住，引擎可以直接把它杀掉重启，每次渲染请求都是自包含、可重试的。

SandboxOutbound（网络出口）：渲染一个不可信的网页，必然要去互联网上抓任意资源，图片、字体、CSS、JavaScript、Wasm 文件。这是浏览器能做的最危险的操作之一。Kitesurf 把它收敛到一个组件，其余任何东西都碰不到网络，这条由 Dynamic Workers 强制。它负责执行跨域策略、注入浏览器形状的请求头、过滤响应，每个页面的 cookie 单独一罐，不符合策略的一律 403。

它是怎么在 12 周里造出来的

这一节是整篇里最能拿走用的一段：怎么让 AI 干一件复杂又容易失控的活。

起点是一个开源项目 obscura，Rust 写的无头引擎，主打「没有 Chrome、没有 Node.js、没有依赖」。

他们让 AI Agent 试着把它移植到 Workers 上，一开始效果很差。转折点是：给了 AI 一份扎实的计划，加上一个清楚的成功定义，详细到 Agent 能一直循环下去、卡住时知道回来提问。然后就跑通了。被这个勉强能跑的原型震到之后，团队才放开手做。

接下来是他们自己抛出的核心问题：

从原型走到一个能在生产里扛住规模的完整浏览器，要大量的工作和迭代。我们不否认，用 AI 加速这个过程是关键。但在这么复杂的项目里怎么用 AI，既保住代码和结果的质量、又不掉速度？

答案是：尽可能多地提供测试。

Kitesurf 发布博客

用的是 WPT，它给 AI Agent 提供了明确的球门：哪个特性做到了、哪个没做到，一测便知。人只做两件事：挑选和排序要交给 Agent 的特性，以及盯架构、看 Agent 的思路对不对。

但 WPT 只测到规范符合度，测不出「能不能渲染和操作真实网站」。所以他们又补了一层：集成测试加视觉回归测试，用 Puppeteer 在真实网站上跑多步操作，同时跑 Chromium 和 Kitesurf，不光比断言结果，每一步的渲染输出也逐张比对，把不该有的差异标出来。

动手前定死的四条规矩

除了测试，还有四条在写第一行正式代码之前就定死了。每一条后面都跟着「所以会怎样」。

适合接什么活，不适合接什么活

这一节是给你判断「我这个活该不该换过去」用的。

官方给的定位是一句挺准确的话：把 Kitesurf 想成一个短命、完全隔离、无状态的引擎，只在一个任务的时长内存在，适合一阵一阵涌进来的 AI 负载。

网站兼容性方面，现在能正确渲染的包括：TodoMVC 的各个版本（原生、React、Vue、Angular、Preact）、Wikipedia、Hacker News、Cloudflare 博客，以及 Cloudflare 仪表盘的大部分。要判断某个具体网站行不行，最快的办法是直接去公开的 playground 输网址试一下。

怎么体验，以及开源计划

公测免费：目前在 Cloudflare 的 Browser Run 产品里开放免费测试，有按账号的额度限制。用法就是在接口上加一个参数：

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"

在线 Playground：官方提供了公开的 kitesurf.cloudflare.app，输入任意网址就能直接看 Kitesurf 的渲染效果，还能交互。

里面有个别处看不到的东西：他们把 Chrome DevTools 注入进了界面，而且专门实现了 Memory 面板需要的那几条 CDP 指令，所以你能看到每个隔离环境（包括各个 frame）的 WebAssembly 占用。

官方列了正在做的四件事：更全的 CDP 覆盖；截图和 PDF 的渲染保真度（他们的理由是 AI 常常看图比看文字效果更好）；更多 WPT 覆盖；以及效率，CPU、内存、墙上时间的基准一直在跑。

开源计划：他们说准备把 Kitesurf 开源，「等我们准备好，希望很快」。目标是让客户能在自己的账号里部署自己的那一份。

第一版是 AI Agent 移植开源引擎 obscura 做的，一开始跑不通；给它一份扎实计划和明确到能一直循环的成功定义，才跑出能用的原型。这么复杂的项目交给 AI 写，怎么不让质量失控？给它一个能自动打分的靶子。

靶子是 Web Platform Tests，一套检测浏览器有没有把网页标准做对的公开测试集。AI 改代码、跑测试、拿分数、再改，人只挑该测哪些特性、盯架构和思路。测试测不出真实网站好不好用，又补一层：同时跑 Chromium 和 Kitesurf 访问同一网站，逐张比对渲染画面。

下面数字是 Cloudflare 自测：场景是截图和抓正文，对手是热池里待命的 Chromium，第三方还没复现过。同样两件事，Kitesurf 的 CPU 和内存小了一大截，等待时间却变长。

Kitesurf 的定位是一个短命、完全隔离、无状态的引擎，只在一个任务的时长里存在，适合一阵一阵涌进来的 AI 负载，给 Chromium 之外多一个便宜档。

现在能正常渲染 Wikipedia、Hacker News、Cloudflare 博客和仪表盘，还有 TodoMVC 各框架版本；某个网站行不行，去 kitesurf.cloudflare.app 输网址试最快。公测免费，有账号额度限制；开源已在计划里，目标是让客户能在自己账号部署一份。