8 月 7 日，Cloudflare 发布了 Kitesurf——一款专门为 AI Agent 而非人类用户设计的浏览器。它完全运行在 Cloudflare Workers 的 V8 isolates 之上，底层没有一行 Chromium 代码。从构思到发布仅用了 12 周。
Kitesurf 从 Agent 的截图、提取文本和操作网页等需求出发设计浏览器，试图减少不必要的资源消耗。对大规模部署 Agent 的团队而言，这提供了一个重新评估浏览器成本的选项，但节省多少仍取决于任务与兼容性。
页面执行、渲染和接口由三个组件分别处理
当前市场上绝大多数 Agent 浏览器基础设施——Browserbase、Hyperbrowser，以及开发者自建的 Playwright/Puppeteer 集群——底层都依赖 Chromium。Chromium 是为人类用户设计的：它需要管理标签页、扩展、视频解码、WebGL 渲染、60fps 动画和复杂的合成层。而对一个只需提取文本、截图或填表提交表单的 Agent 而言，这些功能中的一部分会增加额外开销。
Kitesurf 的答案是彻底替换 Chromium。它的技术栈由三个核心组件构成：
PageScript 负责页面执行。每当 Agent 访问一个新页面或加载一个跨域 iframe，PageScript 通过 Dynamic Workers 创建一个长期存活的 V8 isolate，在其中解析 HTML 文档、执行页面 JavaScript、构建 DOM 树。HTML 解析和 CSS 解析由 Blitz——一个用 Rust 编写的模块化渲染引擎——和 Firefox 的 Stylo CSS 解析器完成。页面中的 <script> 标签和 WebAssembly 代码在同一 isolate 中执行。对于 eval()，由于 Workers 未原生支持，Kitesurf 使用 Boa JS（一个 Rust 实现的 ECMAScript 引擎）作为运行时嵌套方案。
PageRenderer 负责将计算好的页面对象（scene）光栅化为 JPEG、PNG 或 PDF。渲染管线依赖 Blitz 的 blitz-paint 模块和 Parley 文本布局引擎。PageRenderer 本身是无状态的——它不持有页面数据，只维护一个可丢弃的缓存。
Engine 是对外暴露的入口，实现 Chrome DevTools Protocol（CDP）的 WebSocket 和 HTTP REST API。现有的 Puppeteer、Playwright 和 chrome-remote-interface 客户端，可以将连接地址指向 Kitesurf，调用其已支持的功能。
三个组件通过 Cloudflare Workers 内置的 RPC 系统通信。Engine 调用 PageRenderer 的 renderFrame() 获取图像缓冲区，整个过程对调用方透明。由于 PageRenderer 无状态，Engine 可以在任何 RPC 调用失败或卡住时直接销毁并重建渲染 Worker。
这种架构依赖 V8 isolates 提供独立执行环境。与容器或虚拟机不同，一个 isolate 的冷启动只需要几毫秒、几 MB 内存——Cloudflare 自己披露的数据是"比容器快约 100 倍，内存效率高 10-100 倍"。在 Kitesurf 的用例中，这意味着每个页面访问可以拥有独立的执行环境，而无需承担传统浏览器进程的内存开销。
14 个网址测试中，资源占用降低但任务耗时增加
Cloudflare 在 14 个 URL 组成的测试集上比较了 Kitesurf 与 Chromium（预热池）的表现。关键数字：
| 指标 | Kitesurf | Chromium | 差异 |
|---|---|---|---|
| CPU（截图） | 380 ms | 1,173 ms | 约为 Chromium 的 1/3.1 |
| CPU（HTML 提取） | 229 ms | 877 ms | 约为 Chromium 的 1/3.8 |
| 内存（截图） | 57.8 MiB | 271.0 MiB | 约为 Chromium 的 1/4.7 |
| 内存（HTML 提取） | 39.4 MiB | 273.7 MiB | 约为 Chromium 的 1/7.0 |
| Wall time（截图） | 1,148 ms | 637 ms | 耗时约为 Chromium 的 1.8 倍 |
| Wall time（HTML 提取） | 820 ms | 472 ms | 耗时约为 Chromium 的 1.7 倍 |
在单次任务耗时上，经过 JIT 预热的 Chromium 快于冷启动的软件渲染器。但 Kitesurf 的 CPU 用量约为 Chromium 的三分之一至四分之一，内存约为五分之一至七分之一。
在 Agent 工作流程中，浏览器多耗费的几百毫秒，可能只占模型推理与工具调用总耗时的一小部分。每个 session 的内存则相差 200MB 以上；当内存限制并发量时，更低占用有助于在同一台机器上运行更多 session，但不能直接把测试中的内存比值换算成所需机器数量。
随着模型调用价格下降、推理延迟改善，浏览器 session 的 CPU 和内存开销也需要单独核算。Kitesurf 试图降低这部分成本；它在总账单中占多大比例，要看具体工作流程。
网络和页面隔离限制访问，提示注入仍需另外防范
Agent 浏览器除了需要防范恶意网站攻击运行环境，还要应对间接提示注入（indirect prompt injection）：网页内容可能混入指令，误导 Agent 的判断，进而诱使它执行危险操作。
Kitesurf 的设计从三个层面回应了这个威胁模型：
网络隔离。 只有 SandboxOutbound 组件可以发起外部网络请求，其他所有组件被 Dynamic Workers 强制阻断直接网络访问。SandboxOutbound 对每个请求执行 CORS 策略、注入浏览器标准头部、过滤响应、将不同 page 的 cookie 隔离到各自的 jar 中。任何未通过策略的请求返回 403。
页面级隔离。 每个页面或跨域 iframe 在独立的 V8 isolate 中执行，以限制页面间访问。Cloudflare 同时强调，isolate 沙箱仍需要纵深防御；其 Dynamic Workers 安全架构整合了 MPK（Memory Protection Keys）等硬件特性，并引入了针对 Spectre 的额外防御。隔离设计不能被理解为已排除所有跨页面攻击路径。
容错机制优先。 Kitesurf 的设计原则是：出现故障时显示空白画面或略去相应元素，尽量维持会话运行。在 Agent 自动化场景中，静默崩溃可能比渲染错误更难处理——Agent 的任务会中断，也可能无法自行恢复。
不过，isolate 级别的隔离并不能直接防御 prompt injection——恶意指令可以合法地存在于页面 DOM 中，Agent 读取页面内容时自然会将其纳入上下文。Kitesurf 的隔离机制旨在限制恶意页面对运行环境的影响；页面内容是否会误导 Agent，则仍需要 Agent 框架处理。
兼容现有自动化协议，与 Chromium 托管服务竞争
Kitesurf 进入的赛道已经有明确的玩家：
Browserbase 是这一领域的主要服务商之一。2025 年完成 4000 万美元 B 轮融资（估值 3 亿美元），2025 年处理了超过 5000 万 session，客户超过 1000 家，包括 Vercel 和 Perplexity。Browserbase 的价值在"管理 Chromium 的复杂性"：浏览器生命周期、并发 session、鉴权、调试和规模化运维。它的 Stagehand 框架让开发者用自然语言编写自动化脚本。
但 Browserbase 底层仍然是 Chromium。它的创新在管理层，Kitesurf 的创新在执行层。
Playwright 和 Puppeteer 是广泛使用的浏览器自动化工具。Kitesurf 通过兼容 CDP 协议接入这一生态；开发者可在 Browser Run 的连接地址上加 browser=kitesurf 参数，使用已支持的功能。
Obscura 是开源的 Rust headless 引擎，专为 AI 自动化设计，也是 Kitesurf 的灵感来源。Cloudflare 在博客中明确表示，Kitesurf 的第一个概念验证就是把 Obscura 移植到 Workers 上。
Kitesurf 还通过资源占用和部署位置与现有产品区分。它运行在 Cloudflare 全球 335+ 个城市的边缘网络上，session 在离用户最近的节点启动。对于已经在 Cloudflare 生态中的团队——尤其是使用 Workers AI 做推理的——Kitesurf 意味着 Agent 的浏览和推理可以在同一个网络上完成，减少数据传输延迟和出口流量成本。
视频、复杂动态页面和长期登录会话仍有限制
Kitesurf 目前处于 beta 阶段，Cloudflare 坦率列出了不支持的场景：视频播放、WebGL 渲染、需要真实 TLS 指纹的 bot 检测握手、需要持久状态的长时间 authenticated session。兼容性方面，Kitesurf 通过了约 215,000 个 Web Platform Tests，团队每周新增数百个通过用例。对 Agent 重要的领域（CSS、DOM、HTML、SVG、XHR）覆盖率已经不错，但在复杂动态网站上仍然可能出现渲染差异。
更关键的限制是 12 周的开发历史。浏览器引擎的成熟需要多年积累，Chromium 经过了十多年的打磨才达到今天的兼容性和稳定性。Kitesurf 的 12 周产物在任何意义上都处于极早期。
还有一个 HN 用户指出的利益冲突问题值得关注：Cloudflare 同时运营 CDN 反 bot 系统和 Agent 浏览器产品——运行在 Cloudflare Workers 上的 Kitesurf 发起的请求，是否会在同一家公司的反 bot 检测中获得特殊待遇？Cloudflare 在博客中没有回应这个问题，这是企业和内容发布方仍需确认的一个问题。
Cloudflare 扩展 Agent 工具，开源计划仍待兑现
Cloudflare 还在扩展其他 Agent 基础设施。8 月 5 日，Cloudflare 开源了 Agent 编排平台 Cloudflare OS；Kitesurf 发布同日，Cloudflare 刚公布了 Q2 财报——营收 6.96 亿美元，超出预期，盘后涨约 16%。CEO Matthew Prince 在 5 月的裁员公告中将 AI 工具带来的效率提升列为裁员原因之一。这些动作说明 Cloudflare 正把更多产品投入 Agent 场景。
Kitesurf 为 Agent 补充了网页访问与操作能力。若较低的 CPU 和内存占用能在实际工作中稳定复现，它可能降低浏览器服务开销；目前的测试还不能给出整个 session 成本的降幅。
Cloudflare 计划在准备就绪后开源 Kitesurf，让客户在自己的账户上部署自己的 Kitesurf 实例。Blitz 引擎的维护者也在 Hacker News 上确认，Cloudflare 团队打算向上游贡献补丁。如果这个承诺兑现，Kitesurf 的影响力将远超 Cloudflare 的客户群。
Kitesurf 展示了按 Agent 任务需求设计浏览器的另一种方案。它能否从 beta 进入稳定的生产使用，仍取决于兼容性、性能和故障恢复能否满足实际网站的要求。开发者需要据此判断，资源节省是否足以抵消适配成本。
