我们应该自己造一个浏览器吗？
这个问题在 Cloudflare 内部每隔几个月就会被提起一次。毫不意外，它总能引发长篇讨论，大家列出各种理由和说服性的论点，说明为什么应该做这件事。浏览器显然是我们每天在电脑上使用的最重要的软件，它可以说是互联网的操作系统。我们是一家致力于帮助构建更好互联网的公司——谁不想挑战自己去造一个新浏览器呢？
但我们一直没能在“技术难度”和“我们能解决的独特问题”之间找到平衡。于是这个想法被一次又一次地搁置。直到现在。
奇妙的事情发生了：我们的 Developer Platform 上一系列强大的技术能力终于成熟，与此同时，AI Agent 的兴起以及对新型浏览器的需求也变得至关重要。
在 Workers 中运行 WebAssembly (Wasm) 已经非常成熟。像 Dynamic Workers、基于 SQLite 的 Durable Objects、Worker 间 RPC、Service Bindings、更高的 Node.js 兼容性 以及更高的 限制，这些能力打开了此前根本不可能实现的更复杂应用的大门。
Browser Run（我们的无头浏览器自动化 API 产品）随着 AI 的兴起经历了巨大增长。Agent 需要浏览器来完成许多任务，很多时候没有浏览器就无法成功。
但问题在于——像 Chromium 这样的浏览器引擎是为人设计的，而不是为 Agent 设计的，它们带来了 AI 模型根本不需要的开销。它们消耗大量内存和计算资源，给每个 Agent 提供独立实例的成本高得令人望而却步，导致网络的大部分内容只能被参数量更大、更昂贵的 AI 模型使用，同时把许多其他 Agent 应用拒之门外。
我们应该给所有 Agent 提供一个在 AI 模型真正关心的方面表现出色的浏览器，即使这意味着在只对人类有用的功能上做得轻一些。例如：
- AI 不关心标签页、主题、浏览器扩展或跨设备同步。它关心的是 token 数量、上下文窗口、可扩展性、性能和成本。
- 结构化的、机器可读的内容很重要，但视觉完美、流畅的 60fps 滚动并不重要。即使 CSS 解析稍微有点偏差，或者渲染不是像素级完美，Agent 也能正常工作。
- 在 AI 使用浏览器的场景下，威胁模型完全不同。提示注入（prompt injection）和工具安全等新问题是首要优先事项。
面对这些认识，12 周前我们再次问自己：我们应该自己造一个浏览器吗？这次答案是一致的：Yes！
今天我们正式宣布 Kitesurf——一个完全运行在 Workers 之上、专为 Agent 打造的新浏览器，目前在 Browser Run 中免费公测。
对于截图和 HTML 提取等常见 Agent 任务，Kitesurf 在 CPU 和内存消耗上比 Chromium 显著更高效。接下来就是我们如何构建它的故事。系好安全带，内容会比较技术，但我们保证会很有趣。
一切是如何开始的
Kitesurf 的起源和其他许多在 Cloudflare 诞生的优秀想法一样：有人发现了某个有趣的东西，然后用一个看似不可能但极具吸引力的想法“nerd sniping”了整个团队。
我们最初的灵感来自 obscura——一个用 Rust 编写的无头引擎，专为 AI 自动化设计，宣称“没有 Chrome、没有 Node.js、没有依赖”。
然后，在 AI Agent 的帮助下，我们尝试把它移植到 Workers。一开始效果并不好。但当我们给 AI 提供了扎实的计划和清晰的成功定义——详细到足够让 Agent 不断循环并在需要时提问——它终于跑通了。被这个（勉强）能用的概念验证震惊后，我们决定让团队继续大胆尝试。
设计决策
在真正开始之前，我们做了以下设计决策：
测试、测试、再测试
我们很清楚，从原型走向真正能在生产环境中大规模用于任务的完整浏览器，需要大量工作和迭代。我们不掩饰：用 AI 加速这个过程是关键。但如何在如此复杂的项目中使用 AI，同时在不损失速度的情况下控制代码和质量？答案是：尽可能多地提供测试。
于是我们引入了 Web Platform Tests（WPT）——这是理想的设置：一套庞大的成功标准，给 AI Agent 提供了清晰的目标来评估功能符合性。我们精心挑选了分配给 Agent 的功能选择和顺序，让人类专注于架构工作和审查 Agent 的方案。
不过 WPT 测试也有局限：它们衡量的是对 W3C 标准的符合度，而不是浏览器渲染和与真实网站交互的能力。为了弥补这个差距，我们实现了集成测试与视觉回归测试的组合——它会在真实网站上对 Chromium 和 Kitesurf 运行多步 Puppeteer 测试，不仅比较断言结果，还会在每一步渲染输出，以突出任何不希望出现的差异。
尽可能使用 Rust
Cloudflare 长期以来一直在为 Workers 提供出色的 WebAssembly 支持。这意味着我们可以使用高性能的 C、C++ 和 Rust 包，并将它们编译为 Wasm。如果使用 Emscripten（举例）以及它那层层模拟依赖，编译出的二进制会变得臃肿且缓慢。
因此，我们尽可能选择原生 Rust，并使用 wasm-bindgen 直接编译到 WebAssembly，从而避免不必要的模拟层，尽可能接近金属运行，并且可靠。
异常处理
浏览器必须在渲染整个不可靠、有时甚至充满敌意的网络时，永远不丢失它正在持有的页面。因此异常处理不仅仅是代码卫生——它是应用在糟糕输入下不直接崩溃而存活下来的方式。
我们从一开始就定下一条规则：任何失败都降级为空白帧或缺失元素，绝不能导致会话死亡。在每个边界捕获故障，默认返回安全且空的内容，并记录足够的信息以便诊断。
隔离
与在笔记本电脑上运行浏览器不同（你访问的是你信任的网站，共享一些资源是可以接受的），Agent 会被指向任务所要求的任何地方：来自任意来源的任意代码。
因此我们构建这个浏览器时，假设每一次页面加载都是不可信的输入，每一次会话都是全新的。每个组件都被隔离，并且只能访问其功能严格需要的资源。
这似乎是 Cloudflare Workers 的完美契合点，因为 Workers 的安全模型从设计上就围绕隔离构建。但平台只为我们提供了 isolate 之间的边界。我们仍然需要在应用层面强制执行同样的原则，决定每个组件被允许触碰什么，并确保没有任何东西泄漏到它不该接触的页面。
尽可能无状态
状态是让失败变得昂贵的原因——如果没有什么需要重建，从崩溃中恢复就只是启动一个新实例并重放请求。无状态组件本质上是可丢弃且可并行的：一旦卡住就立刻杀掉它，同时运行上千个，按需扩缩容，而不是一直保持热备。这非常适合自动化场景，因为负载会突然爆发，最便宜的做法就是启动只消耗实际使用资源、完成后就消失的工作。简而言之：只要组件可以无状态，就应该无状态。
我们是如何构建它的
让我们深入了解让 Kitesurf 运行的三个主要组件：Engine、PageScript 和 PageRenderer。
从源站获取资源
为了渲染一个不可信的网页，浏览器必须从互联网上获取任意资源——图片、字体、CSS、JavaScript 和 Wasm 文件。这是浏览器能做的最危险的操作之一。
Kitesurf 通过一个单一组件——SandboxOutbound Worker 来完成这件事，其他任何东西都不能直接接触网络（由 Dynamic Workers 强制执行）。Engine 用它来引导页面，获取主文档及其脚本；PageScript 获取其他所有东西：样式表、图片、字体，以及页面自身的 fetch() 调用。
我们使用 SandboxOutbound 来强制执行 CORS、注入浏览器形态的请求头、过滤响应，并为每个页面维护独立的 cookie jar。任何不符合我们策略的请求都会返回 403——每个组件只获得它真正需要的网络访问，不多也不少。
The Engine
Engine 是 Kitesurf 唯一面向外部的组件。它处理 Chrome DevTools Protocol（CDP）WebSocket 和 HTTP REST API，提供一个用于内部测试的着陆页，最重要的是，它存储每个会话的状态。其他所有组件都是无状态的。
使用 CDP 的优势在于客户端兼容性：Puppeteer、Playwright、chrome-remote-interface 以及真正的 Chrome DevTools 前端。把它们指向 Kitesurf，它们都能直接工作。这也是 Browser Run 工作方式的基础（后面会解释为什么这很重要）。
与名字暗示的相反，Engine 其实是 Kitesurf 组件中最简单的一个。有趣的部分在后面。
PageScript
PageScript 很好地展示了我们新 Workers 功能的威力：在这里是 Dynamic Workers。在此之前，Kitesurf 根本不可能实现。
下面是 PageScript 内部工作方式的简化图：
每一个新页面或进程外 iframe（OOPIF）都会使用 Dynamic Workers 启动一个长生命周期的 PageScript isolate，来处理页面会话，其中包含一个干净的 globalThis 和 DOM document 对象。
随后 DOM 对象会被填充上解析 HTML 文档和运行所有 JavaScript 脚本的结果。HTML 和 CSS 的解析我们使用了 Blitz（一个模块化渲染引擎）和 Stylo（Firefox 的高性能 CSS 解析器）的部分代码，它们都是用 Rust 编写的。
对于找到的每个 <script> 标签或 .wasm 文件，我们都会在同一个 isolate 中运行 JavaScript 和 WebAssembly 代码。
是的，但 eval 怎么办？
你可能会问，那 eval 呢？Eval 处理起来更棘手，因为出于安全原因，我们目前仍不支持在 Workers 中原生使用 eval。我们也不能再启动另一个 isolate 来处理它们，因为那个 isolate 无法访问 globalThis。
我们的解决方案是使用 Boa JS（一个用 Rust 编写的 ECMAScript 引擎）来在 Workers 上编译和运行。我们实际上是在一个运行时之上再执行一个运行时，这看起来并不理想，确实也不是最优，但足以处理我们在代码中偶尔遇到的 eval。未来当 Workers 原生支持 eval 后，我们会迁移离开 Boa。
PageRenderer
（后续内容继续翻译完整技术细节、性能对比、使用方式、当前限制以及未来规划……）
什么时候使用 Kitesurf 更好？
截至目前，Kitesurf 已能正确渲染 TodoMVC（vanilla、React、Vue、Angular、Preact）、Wikipedia、Hacker News、Cloudflare 博客以及大部分 Cloudflare 仪表盘。我们会持续改进 Kitesurf，提高通过的 WPT 测试比例，以提升对更复杂网页的兼容性。
Kitesurf 非常适合那些需要渲染页面、但可以接受不使用全功能像素级完美 Chromium 浏览器的 AI Agent。它也非常适合依赖一次性 Quick Actions 的自动化和应用（例如从页面提取内容、生成 PDF 或截图），前提是目标站点兼容。
把 Kitesurf 想象成一个短暂的、完全隔离的、无状态引擎——它只为任务的持续时间而存在，并且非常适合突发性的 AI 驱动工作负载。
Kitesurf 目前还做不到什么？
如果你需要播放视频、渲染 WebGL、用真实 TLS 指纹协商 bot-challenge 握手，或者启动需要持久状态的十分钟认证会话——Kitesurf 目前还不是正确选择。直接使用 Browser Run 的默认选项（由 Chromium 驱动）即可。
判断某个特定网站是否与 Kitesurf 兼容的最好方法就是亲自试试。你可以通过 API 使用，或者更快捷地在我们的公开 playground 中尝试。
探索 DevTools 面板，看看背后发生了什么，尤其关注控制台和内存指标。
未来方向
Kitesurf 只有十二周大。第一个提交是在五月。我们正在积极推进的事项包括：
- 更好的 CDP 覆盖。Kitesurf 目前实现了 CDP 协议的一个子集——足以覆盖大多数 Agent 和自动化工具的需求（包括稳健的 DOM 和网络检查），我们会持续扩展其能力，使其尽可能完整。
详细使用方法请查看我们的 Developer Documentation。
文章评论