Cloudflare Kitesurf 是一个运行在 Workers 和 V8 isolate 上的 Agent 浏览器。它的价值来自一份更窄的浏览器合同：减少 Agent 用不到的桌面能力，把组件拆到不同隔离边界，让大部分计算可以随时丢弃和重启。代价同样明确：长时间登录会话、视频、WebGL、真实 TLS 指纹和像素级渲染仍要交给 Chromium。
阅读时间：约 9 分钟 · 约 3,200 字
TL;DR
- Kitesurf 处于 Beta 阶段，定位是 Agent 专用浏览器运行时，适合一批特定任务，当前还不能替代完整 Chromium。
- Engine 保存会话状态；PageScript、PageRenderer 和网络出口分别隔离。渲染器无核心状态，卡死后可以直接重启。
- Cloudflare 在 14 个 URL、每项 5 次运行的自测中，报告 CPU 降低 3.1 到 3.8 倍、内存降低 4.7 到 7 倍；同一组测试里，Kitesurf 的墙钟时间慢 1.7 到 1.8 倍。
- 发布博客写的是通过 21.5 万项以上 WPT 测试；8 月 7 日更新的文档已经变成 23.5 万项以上。WPT 衡量标准兼容，无法替代真实网站和真实任务验收。
- 一次性内容提取、截图、PDF 和突发高并发是优先试用场景；持久登录、音视频、WebGL、反机器人握手和高保真渲染继续使用 Chromium。
- 生产系统更适合做能力路由：Kitesurf 处理已验证的网站类型，遇到明确的能力缺口再回退 Chromium。
选型先看任务合同
Chromium 服务的是人。标签页、扩展、媒体、图形、持久配置和精细渲染都属于它的通用合同。Agent 抓取一段 HTML 或生成一张截图时，只使用其中一小部分能力，却要承担完整浏览器的进程和内存成本。
Kitesurf 从另一侧切入。Cloudflare 发布博客列出的优先级是 token、上下文窗口、扩展能力、性能、成本、提示注入和工具安全。主题、扩展、设备同步、平滑滚动和像素级渲染被主动降级。
这不是简单的功能删减。浏览器的优化单位发生了变化：面向人的浏览器优化一次连续交互；面向 Agent 的浏览器要优化单位算力可以完成多少个经过验证的任务，同时把不可信页面隔离开，并让失败可以廉价恢复。
因此，Kitesurf 更像一个提供浏览器接口的专用执行运行时。它接入 Browser Run 的 Quick Actions，也实现了部分 Chrome DevTools Protocol，现有 Puppeteer、Playwright、chrome-remote-interface 和 MCP 客户端可以连接。接口兼容降低了迁移成本，仍然不等于 Chromium 行为完整兼容。
四个组件决定了系统边界
理解 Kitesurf，可以先看四类职责。
| 组件 | 职责 | 状态与权限边界 |
|---|---|---|
| Engine | 对外提供 CDP WebSocket 与 REST 接口，协调一次请求，保存会话状态 | 唯一对外、主要状态拥有者 |
| PageScript | 解析 HTML 与 CSS，建立 DOM，执行 JavaScript 和 WebAssembly | 每个顶层页面或跨进程 iframe 使用独立的长生命周期 isolate |
| PageRenderer | 把页面场景栅格化为 JPEG、PNG 或 PDF | 除可丢弃缓存外不保存状态，RPC 卡死后可以重启 |
| SandboxOutbound | 获取文档、脚本、样式、图片、字体以及页面发起的网络请求 | 唯一直接访问网络的组件，负责 CORS、请求头、响应过滤和独立 cookie jar |
Engine 本身很简单。它保存会话，使用 Workers RPC 调用其他组件。PageScript 组合 Rust 与 WebAssembly 生态，HTML 解析使用 Blitz 的部分模块，CSS 解析使用 Firefox 的 Stylo。页面 JavaScript 与 WebAssembly 在对应 isolate 中执行。
Workers 当前无法原生支持该场景中的 eval。Kitesurf 的折中方案是在 Workers 上运行 Rust 编写的 Boa JavaScript 引擎。这相当于运行时之上再放一个运行时，可以解决兼容问题，也会带来额外开销。Cloudflare 已明确表示，Workers 原生 eval 可用后会移除这条路径。
PageRenderer 最能体现恢复设计。它接收页面场景，读取内部字体和图片，完成栅格化，再把图片或 PDF 返回给 Engine。渲染器不拥有页面状态，所以 RPC 失败或卡死时，Engine 可以直接杀掉并重启它。一次渲染因此变成可重试的独立操作，不必拖垮完整会话。
这类收益来自基础设施设计。真正的杠杆在组件边界、状态归属、网络权限和恢复语义，而不是在 Chromium 外面再包一层 Agent 框架。
无状态有一个重要限定
Cloudflare 的原话是尽可能无状态。Engine 仍然保存会话，PageScript isolate 也会跟随页面会话存在。这里的无状态，指没有必要持有状态的组件可以直接丢弃。
这个限定决定了两类收益：渲染器卡死后可以替换；短任务每次从干净环境开始；突发流量可以水平扩展，无需维护完整桌面配置。
它也直接暴露产品边界。Kitesurf 官方文档明确表示，当前不适合需要持久状态的长时间登录会话。Agent 如果需要保存登录身份、local storage、浏览器 profile，或者连续执行十分钟以上的交互链路，官方建议继续使用 Browser Run 默认的 Chromium。
所以，无状态恢复的正确理解是：只有把持久状态交给明确的拥有者，其他组件才可以安全销毁。如果业务需要长期身份、进度和审计历史，这些数据仍然要进入持久存储，并单独设计备份、隔离和验证。
这与更广义的 Agent Sandbox 状态合同一致：进程是否存活、文件系统是否保留、会话身份是否延续、业务状态是否持久，属于四种不同承诺。Kitesurf 收窄了浏览器承诺，持久业务状态仍由应用负责。
V8 isolate 只是第一层隔离
Kitesurf 假定每次页面加载都是不可信输入。Workers isolate 提供运行时边界，应用层还要继续规定每个组件能接触什么资源。Cloudflare 在博客中专门强调：平台负责 isolate 之间的边界，组件级权限仍由 Kitesurf 自己执行。
SandboxOutbound 是最关键的例子。页面组件无法直接访问互联网，全部网络请求经过同一个 Worker。这个出口负责 CORS、浏览器形态请求头、响应过滤和每页独立的 cookie jar。团队因此获得一个集中管理出站策略和记录网络行为的位置。
生产验收仍然要覆盖第二层。至少测试跨会话数据泄漏、重定向、DNS 与内网地址访问、cookie 隔离、超大响应、畸形内容、提示注入，以及 CDP 或 MCP 工具连接后的权限扩张。
这和此前对浏览器 Agent 检测的结论一致：更换浏览器内核后，身份、行为和网络证据仍然属于整个系统。Kitesurf 当前也无法完成需要真实 TLS 指纹的机器人挑战握手。
基准数据表达的是取舍
Cloudflare 公布的是 Browser Run Quick Actions 在 14 个 URL 上各运行 5 次后的中位数。对照组是已经预热的 Chromium 池。
| 指标 | Kitesurf | Chromium 预热池 | 官方报告差异 |
|---|---|---|---|
| 截图 CPU | 380 ms | 1,173 ms | CPU 降低 3.1 倍 |
| HTML 提取 CPU | 229 ms | 877 ms | CPU 降低 3.8 倍 |
| 截图内存 | 57.8 MiB | 271.0 MiB | 内存降低 4.7 倍 |
| HTML 提取内存 | 39.4 MiB | 273.7 MiB | 内存降低 7.0 倍 |
| 截图墙钟时间 | 1,148 ms | 637 ms | 慢 1.8 倍 |
| HTML 提取墙钟时间 | 820 ms | 472 ms | 慢 1.7 倍 |
这组数据能支持一个有边界的结论：在 Cloudflare 选择的两类任务和网站集合中，Kitesurf 用更长等待换取更少 CPU 与内存。它无法直接证明所有网站上的成本更低，也无法证明业务吞吐更高。
测试只有 5 次、14 个 URL、两个 Quick Action 场景，并且 Chromium 已经预热。公开材料没有给出复杂网站分布、尾延迟、失败重试率、兼容失败率，以及每个有效业务结果的成本。Cloudflare 把主要时延差距归因于冷启动的软件渲染和图片编码。
真正的选型取决于当前瓶颈：
- 并发密度和内存限制规模时，Kitesurf 可能带来明显容量提升。
- 单次响应时间决定体验时，预热 Chromium 仍然更快。
- 不兼容页面需要多次重试或回退时，兼容成本会吃掉计算优势。
- 输出必须视觉一致时，正确渲染先于低成本。
WPT 通过数量不是网站兼容率
Cloudflare 把 Web Platform Tests 作为 Kitesurf 的明确验收标准。8 月 6 日发布博客写的是通过 21.5 万项以上测试；8 月 7 日更新的文档已经写成 23.5 万项以上，并列出 DOM 97%、HTML 96%、Selection 99%、SVG 97%、Encoding 99%、CORS 95%、XHR 95%、URL 83%。
这个变化说明项目正在快速迭代，也说明引用数字时必须附带时间。
WPT 衡量 Web 标准符合度。它无法覆盖框架组合、反机器人系统、媒体栈、复杂视觉布局、登录链路和网站自身缺陷。Cloudflare 还增加了基于 Puppeteer 的多步集成测试和与 Chromium 的视觉回归对照，最终仍建议用户直接测试目标网站。
Agent 浏览器的终局指标是任务完成。DOM 断言通过，截图仍可能错；页面渲染正确，登录链路仍可能失败。标准符合度是兼容计划的起点，真实任务验收才是终点。
一套可执行的生产选型流程
无需先做大规模迁移。冻结一个代表性语料库，就能完成第一轮判断。
1. 按任务类型分组
至少分开公开静态页面、重 JavaScript 应用、登录链路、反机器人目标、媒体与 WebGL 页面、高保真截图。不同任务合同不能平均成一个总分。
2. 先定义成功，再比较速度
为每类网站写清必需 DOM 字段、交互结果、截图容差、cookie 行为、网络策略和最多重试次数。只有业务输出通过检查，才计为成功。
3. 测量一个有效结果的完整成本
记录 P50/P95 墙钟时间、CPU、峰值内存、失败率、重试率、回退率和每个验证通过结果的成本。厂商数据可以作为先验，自己的任务数据才决定部署。
4. 主动制造失败
注入渲染超时、畸形页面、被阻断网络请求、跨域 iframe 和高频会话创建。核对无状态组件能否恢复、状态是否留在预期拥有者、日志能否定位边界，以及会话之间是否存在数据泄漏。
5. 建立能力路由
已验证的网站类型交给 Kitesurf。持久登录、媒体、真实 TLS 指纹和高保真任务直接进入 Chromium。回退应由明确的兼容性信号触发，而不是由 Agent 猜测页面看起来是否复杂。
这种混合设计也符合此前Agent Cloud 架构的思路：平台价值来自按任务约束匹配执行原语，而不是强迫所有工作使用同一种运行时。
常见问题
Cloudflare Kitesurf 是什么？
它是运行在 Cloudflare Workers 上的 Beta Agent 浏览器引擎，通过 Browser Run Quick Actions 和部分 CDP 接口，为短时、高并发、可隔离的自动化任务提供执行能力。
Kitesurf 基于 Chromium 吗？
不是。它组合 Workers、V8 isolate、Rust 与 WebAssembly 组件，并提供浏览器兼容接口。Browser Run 的默认浏览器仍然是 Chromium。
AI 浏览器和 Agent 浏览器有什么区别？
AI 浏览器通常是给人使用、增加 AI 功能的浏览器。Agent 浏览器是让软件 Agent 通过接口控制的执行运行时。Kitesurf 优先考虑机器可读输出、隔离、扩展能力和成本。
什么场景应该用 Kitesurf？
优先测试一次性内容提取、截图、PDF 和突发自动化任务。长时间登录、视频、WebGL、真实 TLS 指纹和像素级渲染继续使用 Chromium。
Kitesurf 能连接 Playwright、Puppeteer 和 MCP 吗？
Cloudflare 文档说明，可以通过 CDP 连接 Playwright、Puppeteer、chrome-remote-interface，以及同时支持 MCP 与 CDP 的 Agent。Kitesurf 只实现部分 CDP，仍需核对具体命令覆盖。
通过 23.5 万项 WPT 子测试是否代表网站都能用？
不能。WPT 衡量标准符合度。真实兼容还取决于框架行为、视觉渲染、登录、媒体、机器人防御和具体任务步骤。
Kitesurf 已经适合生产吗？资源数据有独立验证吗？
Cloudflare 仍把 Kitesurf 标为 Beta，并建议逐个测试目标网站。公开的 CPU、内存和墙钟时间来自 Cloudflare 在 14 个 URL 上各运行 5 次的自测。它适合做选型线索；生产决策还要用自己的任务核验有效结果成本、尾延迟、回退率和隔离表现。