# Kitesurf：一款在 V8 隔离环境中运行的"代理优先"浏览器 - 来源：Hacker News 热门（buzzing.cc 中文翻译） - 作者：m3h - 发布时间：2026-08-08 02:54 - AIHOT 分数：77 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmsjbn0kl058nroo5kq0m0jws - 原文链接：https://blog.cloudflare.com/kitesurf ## 精选理由 Kitesurf 将浏览器重新设计为无状态、隔离的 Agent 引擎，CPU 和内存占用仅为 Chromium 的 1/3 到 1/7，这对大规模自动化任务的成本结构可能产生实质影响。 ## AI 摘要 Cloudflare 推出 Kitesurf，一款专为 AI 智能体设计的浏览器，完全运行在 Workers 上，基于 V8 隔离环境，现已在 Browser Run 中免费开放测试。 ## 正文 推出 Kitesurf：首个以智能体为先的浏览器，在 Cloudflare Workers 的 V8 隔离环境中运行 我们是否应该构建自己的浏览器？ 这是多年来 Cloudflare 内部每隔几个月就会出现一次的问题之一。不出所料，这类问题往往会引发长篇讨论，包含诸多理由和具有说服力的论点，说明我们为什么应该这样做。浏览器显然是我们每天在电脑上使用的最重要的软件；它可以说是互联网的操作系统。我们是一家致力于帮助构建更美好互联网的公司——谁不想接受构建新浏览器的挑战呢？ 但我们始终未能在这一事业的技术难度与我们将通过它解决的独特问题之间找到平衡。因此，这个想法一次又一次地被搁置。直到现在。 神奇的事情发生了：我们达到了一个临界点——开发者平台上一系列强大的技术进步成为现实，与此同时，AI 智能体的兴起以及对新型浏览器的需求也变得至关重要。 在 Workers 中运行 WebAssembly（Wasm）现在已经非常成熟。动态 Workers、基于 SQLite 的 Durable Objects、Worker 间 RPC、服务绑定、更高的 NodeJS 兼容性以及更高的限制等原语，为更宏大、更复杂的应用打开了大门，而这些在以前根本不可能实现。 我们的无头浏览器自动化 API 产品 Browser Run，随着 AI 的兴起经历了巨大的增长。智能体需要浏览器来执行许多任务，而且在很多情况下，没有浏览器它们就无法成功。 但有一个问题——像 Chromium 这样的浏览器引擎是为人类而非智能体构建的，它们带来的开销是 AI 模型根本不需要的。它们消耗大量内存和计算资源，以至于为每个智能体提供独立实例的成本高得令人望而却步，这限制了 Web 的大部分内容只能由参数知识更丰富、最复杂且最昂贵的 AI 模型访问，同时将许多其他智能体应用拒之门外。 我们应该为所有智能体提供一个在 AI 模型关注的重点方面表现出色的浏览器，即使这意味着在仅对人类有用的功能上有所精简。例如： AI 不在乎标签页、主题、浏览器扩展或跨设备同步。它在乎的是 token 数量、上下文窗口、可扩展性、性能和成本。 结构化、机器可读的内容很重要，但视觉上的完美、流畅的 60 帧滚动并不重要。即使 CSS 解析稍有偏差或渲染并非像素级完美，智能体也不会在意。 在 AI 使用浏览器的背景下，威胁模型是不同的。提示词注入和工具安全等新问题成为首要任务。 面对这些认知，12 周前我们再次提出了那个问题：我们是否应该构建自己的浏览器？这一次，答案是 unanimous：是的！ 今天，我们宣布推出 Kitesurf，这是一款完全运行在 Workers 之上的新浏览器，专为智能体打造，目前在 Browser Run 中免费提供测试版。 对于截图和 HTML 提取等常见的智能体任务，Kitesurf 在 CPU 和内存消耗方面比 Chromium 高效得多。以下是我们构建它的故事。系好安全带，这会有点技术性——但我们保证会保持有趣。 一切是如何开始的 Kitesurf 的诞生，和 Cloudflare 许多伟大创意的起源一样。有人发现了有趣的东西，转眼间，他们就用一个看似不可能但极具吸引力的想法“技术撩拨”了团队的其他成员。 我们的最初灵感来自 obscura，这是一个用 Rust 编写的、用于 AI 自动化的无头引擎，它“没有 Chrome，没有 Node.js，没有依赖”。 然后，在 AI 智能体的帮助下，我们尝试将其移植到 Workers 上。起初效果并不理想。但当我们给 AI 一个扎实的计划和清晰的成功定义——详细到足以让智能体无限循环并在需要时提问——它确实成功了。被这个（勉强）可行的概念验证所震撼，我们决定让团队放手一搏。 设计决策 以下是我们开始之前做出的一些设计决策。 测试，测试，再测试 我们很清楚，从原型走向一个功能完备、能在生产环境中大规模处理实际任务的浏览器，需要大量的工作和反复迭代。我们也不讳言，利用 AI 来加速这一过程是关键。但问题是，在这样一个复杂的项目中，如何运用 AI，在保持代码和结果质量可控的同时，又不牺牲开发速度？答案是：尽可能多地提供测试。 于是我们引入了 Web Platform Tests（WPT），这是理想的选择：一套全面的成功标准，为 AI 智能体提供了清晰的评估功能符合性的目标。我们精心挑选了分配给智能体的功能及其顺序，让人类能够专注于架构工作，并审查智能体的实现方法。 然而，WPT 测试也有其局限性：它们衡量的是对 W3C 标准的符合程度，而非浏览器渲染真实网站并与之交互的能力。为了弥补这一差距，我们采用了集成测试与视觉回归测试相结合的方式——它在真实网站上对 Chromium 和 Kitesurf 运行多步骤的 Puppeteer 测试，不仅比较其断言语义，还在每一步渲染输出，以突出任何不期望出现的差异。 尽可能使用 Rust Cloudflare 长期以来一直在为 Workers 提供对 WebAssembly（Wasm）的出色支持。这很棒，因为我们可以使用高性能的 C、C++ 和 Rust 包，并将它们编译为 Wasm。如果我们使用 Emscripten（例如）及其多层模拟依赖，编译出的二进制文件可能会变得臃肿且运行缓慢。 因此，我们尽可能选择原生 Rust，并使用 wasm-bindgen 直接编译为 WebAssembly，从而避免不必要的模拟层，尽可能贴近底层硬件，实现可靠运行。 异常处理 浏览器必须渲染整个不可靠甚至有时充满恶意的网络世界，同时绝不能丢失它正在处理的页面，因此异常处理不仅仅是一种代码卫生习惯——它是应用在遭遇不良输入时仍能存活而不至于直接崩溃的关键机制。 所以我们从一开始就定下一条规则：任何故障都降级为空白帧或缺失元素，绝不导致会话卡死。在每个边界捕获故障，默认回退到安全且为空的状态，并记录足够的日志以便诊断。 隔离 与在笔记本电脑上运行浏览器（访问的是你信任的网站，站点之间共享一些资源是可以接受的）不同，智能体被指向任务所需的任何内容：来自任意来源的任意代码。 因此，我们构建这个浏览器时基于这样的假设：每次页面加载都是不可信的输入，每个会话都从全新状态开始。每个组件都是隔离的，只能访问其功能严格必需的资源。 这看起来非常适合 Cloudflare Workers，其安全模型本身就围绕隔离设计。但该平台只为我们提供了隔离单元之间的边界。我们仍然需要在应用层面执行同样的原则，决定每个组件可以接触什么，并确保没有任何东西跨过它不应跨越的页面泄漏。 尽可能无状态 状态是让故障代价高昂的原因——如果无需重建任何东西，从崩溃中恢复就只是启动一个新实例并重放请求。无状态组件天生就是可丢弃且可并行的：一旦停滞就杀掉它，同时运行一千个，按需求调整规模而不是保持热备。这完美契合自动化场景，负载以突发形式到来，你能做的最便宜的事情就是启动只消耗实际使用资源、完成后即消失的工作。简而言之，凡是能做成无状态的组件，就应该做成无状态。 我们是如何构建的 有了周密的计划、全面的测试和良好的工具环境，我们准备好在初始概念验证之外继续推进。以下是 Kitesurf 中一个请求的极高层级生命周期，至今仍然适用： 让我们深入探讨让 Kitesurf 运转起来的三个主要组件：Engine、PageScript 和 PageRenderer。 从源站获取内容 为了渲染一个不可信的网页，浏览器必须从互联网上获取任意资源——图片、字体、CSS、JavaScript 和 Wasm 文件。这是浏览器能做的最危险的操作之一。 Kitesurf 通过一个单一组件——SandboxOutbound worker 来实现这一点，除此之外没有任何东西能直接接触网络——这一点由 Dynamic Workers 强制执行。Engine 利用它来引导页面加载，获取主文档及其脚本，而 PageScript 则获取其他所有内容：样式表、图片、字体，以及页面自身的 fetch() 调用。 我们使用 SandboxOutbound 来强制执行 CORS、注入浏览器形态的请求头、过滤响应，并将每个页面的 cookie 保存在各自的独立存储中。任何不符合我们策略的请求都会收到 403——每个组件都恰好获得它所需的网络访问权限，不多也不少。 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 隔离环境，该环境负责处理页面会话，包含一个干净的 globalThis 和 DOM document 对象。 然后，DOM 对象会填充上解析 HTML 文档并运行所有 JavaScript 脚本的结果。为了解析 HTML 和 CSS，我们使用了 Blitz（一个模块化渲染引擎）和 Stylo（Firefox 的高性能 CSS 解析器）的部分代码，两者都是用 Rust 编写的。 对于找到的每个