Cloudflare Kitesurf：智能体浏览器正在从「托管 Chromium」分裂出轻量执行引擎

2026-08-08

一、触发新闻与一句话定义

Cloudflare 在 2026 年 8 月 6 日发布 Kitesurf，并于 8 月 7 日进入今日新闻窗口：这是一款运行在 Cloudflare Workers 的 V8 Isolate 上、专为 AI 智能体设计的无头浏览器；首版用 12 周完成，通过约 21.5 万项 Web Platform Tests，测试期免费接入 Browser Run。

Kitesurf 是一个面向短时、突发、机器驱动网页任务的浏览器执行引擎：它保留 DOM、CSS、JavaScript、截图、HTML 抽取和 Chrome DevTools Protocol（CDP）等智能体常用能力，主动放弃完整 Chromium 的部分兼容性、持久状态和人类界面负担，换取更低的 CPU、内存和会话隔离成本。

这不是又一个把大模型塞进浏览器侧栏的产品。它改的是更靠下的一层：智能体究竟应该「借用一台给人设计的浏览器」，还是应该拥有一种只为机器任务存在、做完即销毁的网页运行时。

Cloudflare 给出的首批数据很尖锐。在 14 个网址、每项五次运行的内部测试中，Kitesurf 截图耗用 380 毫秒 CPU、57.8 MiB 内存；热池 Chromium 分别为 1,173 毫秒和 271 MiB。HTML 抽取的差距更大：229 毫秒 CPU、39.4 MiB 内存，对比 Chromium 的 877 毫秒和 273.7 MiB。代价也写在同一张表里：Kitesurf 的墙钟时间反而慢 1.7—1.8 倍。它省下的是决定并发密度和账单的资源，不是单次任务等待时间。

这组数字来自 Cloudflare 自测，样本只有 14 个网址，不能外推为整个 Web 上的普遍性能结论。但它足够说明 Kitesurf 的设计目标：不争夺「最完整浏览器」，而是争夺「最便宜的合格浏览器」。

二、纵向分析：从诞生到当下

1. 浏览器原本是一台给人使用的通用计算机

浏览器的历史长期围绕同一个方向展开：把更多能力装进一个安全沙箱，让网页越来越像本地应用。标签页、扩展、音视频、WebGL、设备接口、同步、密码管理、辅助功能、GPU 加速，每一项都有真实的人类需求。Chrome、Firefox 和 Safari 的复杂，并不是工程师无节制堆功能，而是三十多年兼容承诺积累出来的结果。

自动化最初只是借用这台通用计算机。Selenium 模拟用户操作，Puppeteer 和 Playwright 经由 CDP 或浏览器协议操控 Chrome/Chromium；爬虫、端到端测试、截图、PDF 生成都因此获得了远胜简单 HTTP 请求的网页理解能力。代价是每个任务都背着完整浏览器进程、渲染管线和状态系统。低并发时，这笔开销可以忽略；当智能体要按需启动成百上千个会话时，它就从工程细节变成经济约束。

智能体又把矛盾推了一步。传统脚本知道要点哪个选择器，失败往往可复现；智能体会读取页面、规划、点击、回退，还可能被网页里的文本改变行为。于是浏览器不再只是「页面渲染器」，它同时是模型的传感器、执行器、身份容器和安全边界。人类浏览器追求像素准确、长期登录和丰富交互，智能体更在意结构化页面状态、Token 数量、快速扩缩、动作审计与最小权限。两组需求开始分叉。

Kitesurf 的诞生不是从 2026 年 5 月的第一行代码开始。Cloudflare 至少用了九年，才把一串原本服务于不同业务的技术积木拼到一起。

2. 2017—2019：Workers 先解决「轻量运行任意代码」

2017 年 9 月，Cloudflare 发布 Workers，允许开发者把 JavaScript 部署到其边缘网络。Workers 没有为每个租户启动虚拟机或完整容器，而是使用 V8 Isolate：同一运行时可以承载大量相互隔离的上下文，启动更快、单实例内存更小。

这个选择在当时解决的是边缘函数冷启动和多租户密度，并不是浏览器问题。它也带来长期约束：Isolate 没有完整操作系统环境，文件系统、原生依赖、任意进程和部分动态代码能力都不能照搬 Node.js。Cloudflare 后来补上 WebAssembly、Node.js 兼容、RPC、Durable Objects、服务绑定与更高资源限制，实际是在不断扩大「轻量隔离能承载什么」的边界。

早期决策的锁定效应在 Kitesurf 上很清楚。若 Cloudflare 当初选择传统容器作为唯一执行单元，2026 年最自然的做法仍会是优化 Chromium 容器池；正因为 Workers 把高密度 Isolate 变成公司熟悉的基础设施，团队才会问：能否把浏览器拆成多个小组件，让每个组件也服从 Isolate 的生灭逻辑？

3. 2020—2021：浏览器隔离让 Cloudflare 真正学会在云里运行浏览器

2020 年 1 月，Cloudflare 收购 S2 Systems，把远程浏览器隔离（Remote Browser Isolation，RBI）纳入 Zero Trust 产品。RBI 的任务是把不可信网页代码留在云端，终端只接收安全的绘制结果或交互数据。S2 的方案使用云端无头 Chromium，拦截绘图命令，再把结果传回本地 HTML5 浏览器。

这是第二块关键积木。Workers 提供轻量代码隔离，S2 则带来浏览器生命周期、恶意网页处理、沙箱和远程交互经验。两者服务对象完全不同：Workers 面向开发者代码，RBI 面向企业员工的长时浏览会话。但 Cloudflare 第一次拥有了全球运行浏览器的生产经验。

这里也埋下后来必须拆分的矛盾。RBI 用户通常需要长而稳定的会话，浏览器要完整、响应要连续；自动化任务则往往短而突发，一批截图或抽取完成后即可销毁。2026 年 Cloudflare 回顾 Browser Run 迁移时坦承，共享 RBI 基础设施造成镜像大、启动慢、全球分布和弹性不理想，两种负载的节奏根本不同。

一个当年的好决策——复用已有浏览器隔离能力——让产品得以快速诞生，也在规模扩大后变成包袱。

4. 2022—2024：从安全产品抽出 Browser Rendering，仍然围绕 Chromium

2022 年 11 月，Cloudflare 推出 Workers Browser Rendering API 私测。开发者在 Worker 中调用 Puppeteer，背后连接数据中心里的隔离 Chromium。产品最初瞄准截图、PDF、性能测试和网页自动化，复用了 RBI 的暖浏览器池与安全沙箱。每次请求获得一次性实例，浏览器之间不共享状态，并以 gVisor、seccomp 和低权限进程降低逃逸风险。

2023 年 5 月，产品进入公开测试。Cloudflare fork 了 Puppeteer，让开发者以接近本地 Puppeteer 的方式连接远程浏览器；同年 9 月又展示用 Durable Objects 延长会话、复用浏览器，从而减少启动和并发成本。这个阶段的中心问题是「怎样把 Chromium 托管好」，不是「是否需要 Chromium」。

这条路线很合理。Web 的兼容性不是一份规范清单，而是数十年错误行为、站点假设、TLS 指纹、媒体栈和浏览器私有差异的总和。直接使用 Chromium，开发者得到最大的网站覆盖率，也能沿用 Puppeteer、Playwright 和 CDP 生态。Cloudflare 只需把基础设施隐藏在一个 binding 后面。

但 AI 智能体改变了负载结构。截图、HTML 抽取和短时导航数量上升；模型常读取 DOM 或无障碍树，不需要平滑滚动、标签同步和扩展生态；大量任务可能只访问一两个页面。完整 Chromium 的兼容性仍然珍贵，却开始出现「为未使用能力持续付费」的问题。

5. 2025—2026 年春：Browser Run 从工具变成智能体基础设施

到 2026 年，Cloudflare 将 Browser Rendering 更名为 Browser Run，定位也从开发者截图服务转向「给智能体一台浏览器」。产品补上 Playwright、直接 CDP、MCP、WebMCP、Quick Actions、Live View、会话录像和人工接管。控制层、可观察性和人机协作开始围绕智能体重做。

2026 年 5 月，Browser Run 迁移到 Cloudflare Containers。默认并发上限从此前水平提高到每个付费账户 120 个浏览器，新建速率达到每秒 1 个，Quick Actions 响应时间下降超过 50%。迁移也把 Browser Run 与 RBI 的长会话负载分开。

这一步看似把产品推回容器，实际为 Kitesurf 创造了对照组。Cloudflare 已经有一个优化过的 Chromium 托管层，兼容复杂页面、视频、WebGL、真实 TLS 指纹和持久登录。新引擎不需要取代它，只需在短任务上比它更省。

同期，Workers 平台补齐 Dynamic Workers、基于 SQLite 的 Durable Objects、Worker 间 RPC、服务绑定、更成熟的 Wasm 和更高限制。Dynamic Workers 允许一个 Worker 动态创建新的隔离执行环境；RPC 让多个 Isolate 像同一应用内的对象那样调用。Cloudflare 多年来反复搁置「自己造浏览器」，正是因为过去缺少这组条件。

6. 2026 年 5—8 月：12 周做出一台「够用」的浏览器

Kitesurf 的第一次提交发生在 2026 年 5 月。灵感来自 Obscura——一个用 Rust 编写、面向 AI 自动化的无头引擎原型。Cloudflare 团队先借助编码智能体把原型移植到 Workers，早期效果并不好；团队随后把架构方案、成功标准和测试目标写清，让智能体在边界明确的任务上持续迭代，人类负责架构和审查。

这个开发过程与产品定位互相呼应。Cloudflare 没有让智能体自由发挥「造一台浏览器」，而是把 Web Platform Tests（WPT）变成可机器判断的验收函数，再用真实网站的 Puppeteer 集成测试和视觉回归补足规范测试的盲区。12 周与 21.5 万项通过测试不是单纯的开发速度故事，它展示了一种更具体的 AI 工程分工：机器吃掉大量有明确反馈的兼容性长尾，人类守住组件边界、失败方式和安全模型。

但数字需要正确理解。WPT 测的是 Web 标准一致性，不等于 21.5 万个网站，也不保证真实网页可用。Cloudflare 自己强调，复杂网站还需集成和视觉回归验证；Kitesurf 当前能正确处理 TodoMVC 的多种前端版本、Wikipedia、Hacker News、Cloudflare Blog 和部分 Cloudflare Dashboard，并未宣称覆盖整个 Web。

7. 架构：把浏览器拆成可丢弃的 Isolate

Kitesurf 的公开架构有四个关键角色。

Engine 是唯一对外组件，接收 CDP WebSocket 和 REST 请求，并保存会话状态。选择 CDP 是一次务实的兼容决策：Puppeteer、Playwright、chrome-remote-interface 和 Chrome DevTools 前端都可以继续使用，开发者不必为新引擎重写控制层。

PageScript 为每个页面或跨进程 iframe 创建独立 Dynamic Worker，维护干净的 globalThis 和 DOM。HTML 与 CSS 处理复用 Rust 生态中的 Blitz 和 Stylo；Stylo 是 Firefox 与 Servo 使用的浏览器级 CSS 引擎。页面脚本和 Wasm 在页面自己的 Isolate 中运行。

PageRenderer 接收页面场景并栅格化为 JPEG、PNG 或 PDF。它尽量无状态，渲染 RPC 卡死或失败时可以直接杀掉重建。失败被设计为缺失元素或空白帧，而不是拖垮整个会话。

SandboxOutbound 是唯一能直接访问网络的组件，集中执行 CORS、请求头注入、响应过滤和 Cookie jar 隔离。其他组件只获得完成职责所需的网络能力。每次会话默认从干净状态开始，页面被视为不可信输入。

一个反直觉细节暴露了新引擎的现实约束。Workers 出于安全原因原生不支持 eval，Kitesurf 于是把 Rust 编写的 Boa ECMAScript 引擎编译到 Workers，在 V8 运行时之上再跑一层 JavaScript 运行时。这并不高效，团队也计划在 Workers 支持原生 eval 后移除 Boa。它说明 Kitesurf 不是从白纸上设计的完美浏览器，而是严格服从 Workers 安全边界的组合系统。

8. 发布时的边界：不是所有任务都该迁移

截至发布日，Kitesurf 适合一次性 HTML 抽取、兼容页面截图、PDF 生成和短时渲染。它还不能播放视频、渲染 WebGL、用真实 TLS 指纹完成反机器人握手，也不适合需要持续十分钟登录状态的会话；CDP 只实现了智能体和自动化常用子集；渲染精度仍在改进。

这些限制不是脚注，而是产品成立的前提。若 Kitesurf 追求 Chromium 的全部能力，它最终会重新长成 Chromium。Cloudflare 真正要维持的，是一条随时间移动的「足够兼容线」：每加入一项 Web API，都要证明其智能体价值高于新增资源和攻击面。

三、横向分析：竞争图谱

当前赛道不是简单的产品排行，而是三条技术路线争夺同一工作负载：完整 Chromium 托管、轻量新引擎，以及模型直接操作人类界面。Kitesurf 位于第二条路线，却依赖第一条路线做失败回退。

1. Cloudflare Browser Run（Chromium）：Kitesurf 的竞品也是后盾

Browser Run 默认引擎仍是完整 Chromium。它支持 Puppeteer、Playwright、CDP、MCP 和 Quick Actions，提供实时查看、会话记录与人工接管，并能处理 Kitesurf 当前做不了的视频、WebGL、复杂反机器人握手和持久认证。

它的优势来自兼容性与连续状态。对于银行后台、保险门户、企业 SaaS 和需要登录的长流程，失败一次的业务代价往往高于多用几百 MiB 内存。开发者选择 Chromium，不是因为喜欢重，而是因为它把真实 Web 的奇怪边角都背在身上。

短板也正是这份重量。Cloudflare 的 14 站点自测里，热池 Chromium 的截图墙钟时间更快，却消耗 Kitesurf 约 3.1 倍 CPU 和 4.7 倍内存；HTML 抽取是 3.8 倍 CPU 和 7 倍内存。对大量一次性任务而言，暖池必须提前占资源，单会话隔离成本很难继续下降。

两者因此不是「新引擎淘汰旧引擎」，而是分层调度。简单页面先走 Kitesurf，遇到兼容性、持久状态或视觉要求再回退 Chromium。这种双引擎结构让 Cloudflare 可以比纯新引擎公司更激进：Kitesurf 不必独自承担整个 Web。

2. Browserbase：押注「真实 Chromium + 智能体全套运营系统」

Browserbase 的路线与 Kitesurf 相反。它明确提供真实 Chromium，每个会话有独立用户目录、指纹、网络身份和生命周期，可经 Playwright、Puppeteer、Selenium、Stagehand 控制；平台把代理、验证码、身份、直播、录像、日志和调试一起包装。

其核心资产不是自研渲染引擎，而是让真实浏览器在生产环境可管理。2026 年 6 月，Browserbase 宣布托管 Browserbase Agents，称底层平台月运行超过 3,500 万次浏览器会话。开发者可以继续自己写 Stagehand 循环，也可以只给自然语言目标，让平台托管模型和执行。它更接近一套「浏览器智能体操作系统」。

用户选择 Browserbase 的真实理由，是复杂网站成功率与可观察性：登录、验证码、代理、重放、人工排障都比纯引擎性能更贴近生产事故。其公开定价也沿着会话运营展开：开发者计划每月 20 美元含 100 浏览器小时，超额每小时 0.12 美元；创业计划每月 99 美元含 500 小时，超额每小时 0.10 美元，并提高并发和数据保留。

相对 Kitesurf，Browserbase 更完整、更成熟，也更难把单次短任务成本压到 Isolate 级别。它的长期风险是：如果大量浏览需求能先被 Fetch API、结构化接口或轻量引擎吸收，完整 Chromium 将退到少数高难度流程。其优势则是，剩下的恰好是付费意愿最高、最需要身份与审计的任务。

3. Lightpanda：从零写轻量浏览器，追求可自托管与 CDP 兼容

Lightpanda 与 Kitesurf最像。它用 Zig 从头构建无头浏览器，面向自动化、抓取和 AI，不依赖 Chromium、Blink 或 WebKit，并通过 CDP 兼容 Puppeteer、Playwright。官方测试声称，相比 Chrome 可实现约 9 倍执行速度和 16 倍更低内存；其网站同时提供 Lightpanda 与 Chrome，承认新引擎并不能覆盖所有场景。

两者的差别在部署哲学。Lightpanda 是可下载、可自托管的独立引擎，适合希望控制基础设施的团队；Kitesurf 深度绑定 Workers 的 Dynamic Workers、RPC、服务绑定与全球调度，目前仍处测试期，官方只承诺未来开源，并计划允许客户部署到自己的 Cloudflare 账户。

Kitesurf 复用 Blitz、Stylo、Boa 等 Rust 模块，Lightpanda 则以 Zig 重新实现更完整的机器浏览器。前者的壁垒是 Cloudflare 网络和 Isolate 运行时，后者的壁垒是独立引擎本身。前者更容易把浏览器与存储、队列、AI Gateway、Agents SDK 接起来；后者更容易进入多云、本地或受监管环境。

公开社区反馈也揭示了两者共同的信任门槛。Rust 社区对 Kitesurf 最直接的质疑不是基准，而是「代码在哪里」；Blitz 仓库自身仍标为 pre-alpha，明确提示存在缺失功能。Cloudflare 表示会在准备好后开源并向上游回馈补丁。在此之前，外界能验证公开 Playground 和 API 行为，却无法完整审计 Cloudflare 对 Blitz 的修改、WPT 选择方式与安全实现。

4. Steel 与开源 Browser Use：把重心放在基础设施编排和智能体层

Steel 提供开源 Browser API 和云端浏览器基础设施，处理会话、代理、反指纹、验证码和扩缩；Browser Use 则位于更上层，把网页状态交给模型，让模型决定导航、填写和提取。两者可以组合：Steel 提供浏览器，Browser Use 提供智能体循环。

这条路线的价值在于可替换。底层仍可用 Chromium，模型与框架可以快速迭代，开发者不必押注某个新浏览器引擎。短板是每层都会增加状态、延迟和安全边界：网页内容进入模型上下文，模型输出驱动浏览器，浏览器持有 Cookie 与凭据，代理与录像又保存新的敏感数据。

2025 年一项针对 Browser Use 的白盒研究展示了提示注入、域名校验绕过和凭据外泄路径。NeurIPS 2025 的 WASP 基准进一步测试 VisualWebArena、Claude Computer Use 和 Operator：低成本人工注入可让智能体在 16%—86% 的测试中开始执行攻击指令，但端到端完成攻击目标的比例为 0%—17%。当前模型能力不足暂时限制了攻击成功，也意味着模型变强会提高防护压力。

Kitesurf 的组件隔离能限制网络访问和跨会话泄漏，却不能单独判断网页文字究竟是内容还是恶意指令。浏览器沙箱解决「代码能碰什么」，模型防线解决「智能体相信什么」，动作策略解决「在什么条件下允许转账、发送或下载」。三层缺一不可。

5. 同一赛道，四种「优化目标」

竞争焦点不会只落在「谁通过更多测试」。开发者真正需要的是路由器：什么时候只做 HTTP Fetch，什么时候启用 Kitesurf/Lightpanda，什么时候升级为完整 Chromium，什么时候要求人接管。能把四级成本与风险自动分流的平台，比单一引擎更可能控制入口。

四、横纵交汇洞察

1. Kitesurf 的优势不是 12 周，而是九年的路径积累

如果只看发布时间，Kitesurf 像一次迅速的 AI 编程实验；把纵轴拉长，它更像 Cloudflare 历史资产的集中兑现。

2017 年选择 V8 Isolate，形成高密度、快速生灭的运行哲学；2020 年收购 S2，获得云端浏览器与恶意网页隔离经验；2022 年 Browser Rendering 把浏览器能力开放给开发者；2026 年 Containers 迁移把完整 Chromium 与 RBI 拆开；Dynamic Workers、RPC、Wasm 和 Durable Objects成熟后，浏览器终于能被拆成 Engine、PageScript、Renderer 和统一出网组件。

今天每个优势都能找到历史根源。低内存来自 Isolate 路线；全球突发扩缩来自 Workers 网络；CDP 兼容来自 Browser Rendering 多年的开发者接口；安全分层来自 RBI；双引擎回退来自 Browser Run 已经存在的 Chromium 平台。12 周解决的是最后一公里，不是从零积累全部能力。

它的劣势也同样有根。Workers 的安全约束使原生 eval 不可用，只能临时套 Boa；平台深度绑定令 Kitesurf 暂时不像 Lightpanda 那样自由部署；Isolate 的短时无状态偏好，与登录、下载、十分钟以上会话天然冲突。历史路径既提供护城河，也规定了河道。

2. 浏览器正在重复数据库的分化：通用系统不会消失，专用执行层会吃掉大吞吐

过去，大家用同一种关系数据库处理越来越多工作；后来缓存、搜索引擎、时序库、列式分析和向量数据库分走特定负载。通用数据库没有消失，反而成为可靠底座，只是不再承担每一次查询。

浏览器可能进入相似阶段。Chromium 继续承担最高兼容、长期身份和复杂多媒体；Fetch 处理无需执行页面的读取；Kitesurf、Lightpanda 承担大量短时 DOM 与渲染；模型智能体只在规则脚本和结构化接口都不够时加入。过去「启动浏览器」是一个二元选择，未来更像查询优化器：平台根据页面与任务特征选择执行计划。

这也解释了为什么 Kitesurf 的墙钟时间慢于暖 Chromium 仍有价值。数据库系统不会因为某个列式查询启动稍慢，就忽视其吞吐和单位成本；对每分钟数千个独立网页任务，CPU 和内存决定可承载并发，单次延迟只是目标之一。若会话量足够大，3—7 倍资源差距会转化为真实价格空间。

3. 真正的行业信号，是浏览器的产品定义从「界面」改成「权限边界」

人类通过浏览器获得一个窗口，智能体通过浏览器获得一组能力。两者看见同一网页，风险完全不同：人看到恶意提示可以忽略，智能体可能把它当成上级指令；人类一次只操作少量标签，智能体可以并发数百会话；人的 Cookie 泄漏影响一个账户，平台级会话复用错误可能跨租户扩散。

Kitesurf 把页面当不可信输入、默认新会话、统一出网、按组件分配网络权限，是正确起点。可它还没有公开完整的提示注入防护、动作授权、凭据代理和审计策略。Cloudflare 官方博客承认提示注入与工具安全是优先威胁，但发布材料主要回答了运行时隔离，而不是模型行为隔离。

我的判断是，智能体浏览器的核心 API 最终不会只是 click()、goto() 和 screenshot()，而会加入带身份的动作能力：只读访问、限定域名、一次性凭据、金额上限、外发审批、可撤销事务。浏览器从页面执行器变成权限执行器后，Cloudflare 的 Zero Trust、Bot Management 和网络策略经验才会真正形成差异。

4. Cloudflare 面临一个只有它格外尖锐的冲突：既服务站点防机器人，也服务智能体访问站点

Cloudflare 一边为网站提供 Bot Management、Turnstile、WAF 和内容控制，一边让智能体更便宜地读取、渲染和操作网页。社区在发布当天就指出这种「同时站在两边」的张力。

这并非一定矛盾。若 Cloudflare 能把智能体身份、站点授权、速率限制、付费抓取与审计接起来，它可能把今天的猫鼠游戏改造成可协商流量：网站知道来者是谁、允许做什么、应否收费；智能体不再靠伪装成人穿过反机器人系统。Cloudflare 2026 年已有 Pay Per Crawl、Bot Management 和 Browser Run 等相邻积木，Kitesurf 可成为受控执行端。

但危险同样清楚。若平台优先强调绕过成本和规模，而没有给内容方明确控制权，Cloudflare 会同时削弱自己在网站客户侧建立的信任。Kitesurf 当前不支持真实 TLS 指纹反机器人握手，反而是一道有意或无意的边界。未来是否跨过去，比再多通过十万项 WPT 更能说明公司选择了哪种秩序。

5. 三个未来剧本

最可能的剧本：Kitesurf 成为 Browser Run 的自动低成本档，而非独立取代 Chromium。 Cloudflare 继续补齐 CDP 和 WPT，在 Quick Actions、公开页面抽取、截图、PDF 等任务上默认尝试 Kitesurf；遇到 WebGL、视频、TLS 挑战、持久登录或渲染差异时，透明回退 Chromium。客户看到的是成功率、延迟和价格，未必需要手选引擎。这个剧本最符合 Cloudflare 已有双栈，也容忍 Kitesurf 长期不完整。可观察指标是：官方是否发布自动兼容性探测与回退、Kitesurf 是否从免费测试转为低于 Chromium 的明确计价、真实站点语料上的成功率是否公开。

最危险的剧本：兼容长尾和安全事件吞掉资源优势。 WPT 数量继续上升，但企业真实流程仍依赖扩展、媒体、复杂 iframe、指纹和状态；团队为追兼容不断加入组件，Kitesurf 逐渐变重。同时，某个隔离或提示注入漏洞导致跨域请求、凭据外泄或未授权动作，企业转回成熟 Chromium 沙箱。届时 3—7 倍资源优势只留在低价值截图任务，无法支撑独立生态。可观察指标是：Bug 与回退率是否集中在高价值网站，开源后安全审计结果如何，SandboxOutbound 和 Cookie jar 是否出现跨会话问题。

最乐观的剧本：Kitesurf 变成「机器 Web」的开放执行标准。 Cloudflare 按承诺开源，把对 Blitz、Stylo、Boa 和 WPT 的改进回馈上游；Lightpanda 等引擎共同推动一个比完整 CDP 更精简、带权限声明的 agent browser profile。站点通过 WebMCP 或类似机制暴露机器可调用能力，浏览器只在必要时渲染，人类界面退为回退层。Cloudflare 用网络位置协调身份、授权、计费和执行，Kitesurf 则成为可在客户账户部署的隔离运行时。这个剧本要求 Cloudflare 主动放弃部分锁定收益，换取标准影响力。

回到开头那组看似矛盾的数据：Kitesurf 单次更慢，却显著更省。它提醒我们，智能体时代评价浏览器的单位已经变了。人类问「这个页面多久出现在我眼前」，平台开始问「一美元、一 GiB 内存和一个权限令牌，能安全完成多少网页任务」。

Kitesurf 现在还不是答案。它更像一个分水岭：浏览器第一次由头部互联网基础设施公司明确承认，给人类做得最完整的工具，未必是给机器做得最合适的工具。

五、信息来源

1. Cloudflare Blog｜Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers 2. Cloudflare Blog｜Introducing Cloudflare Workers: Run JavaScript Service Workers at the Edge 3. Cloudflare Workers Docs｜How Workers works 4. Cloudflare Blog｜Cloudflare + Remote Browser Isolation 5. Cloudflare Blog｜Automate an isolated browser instance with just a few lines of code 6. Cloudflare Blog｜Workers Browser Rendering API enters open beta 7. Cloudflare Blog｜Running Serverless Puppeteer with Workers and Durable Objects 8. Cloudflare Blog｜Browser Run: now running on Cloudflare Containers, it’s faster and more scalable 9. Cloudflare Blog｜Browser Run: give your agents a browser 10. Cloudflare Browser Run Docs｜Pricing 11. Cloudflare Browser Run Docs｜Limits 12. DioxusLabs/Blitz｜A radically modular HTML/CSS rendering engine 13. Servo/Stylo｜CSS engine that powers Servo and Firefox 14. Boa JS｜An ECMAScript engine written in Rust 15. Web Platform Tests｜Project documentation 16. Browserbase｜What is a Browserbase Browser? 17. Browserbase｜Introducing Browserbase Agents 18. Browserbase｜Pricing 19. Lightpanda｜The headless browser 20. Lightpanda Docs｜What is Lightpanda? 21. Steel Docs｜Browser Use integration 22. NeurIPS 2025｜WASP: Benchmarking Web Agent Security Against Prompt Injection Attacks 23. arXiv｜The Hidden Dangers of Browsing AI Agents 24. OpenAI｜Operator System Card 25. Anthropic｜Mitigating the risk of prompt injections in browser use