浏览器默认服务的是人：标签页、书签栏、60 帧滚动、扩展商店。Cloudflare 花约十二周从零写出 Kitesurf，却故意拿掉这一切——没有给人看的 UI，只有 Agent 需要的：解析 DOM、跑脚本、吐截图或干净 HTML，并尽量少吃 CPU 与内存。

2026 年 8 月 6 日，Cloudflare 官方 Changelog 与博客同步宣布：Kitesurf 作为 Browser Run 上的 Agent 优先浏览器进入 beta，期内免费（仍有账号用量上限）。Pinggy 对这场发布的拆法很直：Kitesurf 不是 Chromium 套壳，也不是 Firefox 分支，而是跑在 Cloudflare Worker（V8 isolate）里的新渲染管线；入口仍说 Chrome DevTools Protocol，所以 Puppeteer / Playwright / MCP 浏览器工具大多只改 endpoint。产品观察要问的是：Agent 浏览器的单位经济，能不能压过 Browserbase 一类「真浏览器上云」的账单——以及构建者在什么任务上该选瘦引擎、什么时候必须回 Chromium。

这不是又一篇「边缘计算又快了」的稿。真正换挡的是：当 Agent 把网页当 API 用，浏览器还该不该按「给人用的完整客户端」来计费。

产品机制：为并发与成本裁剪，不为单次延迟

为什么要减肥？Cloudflare 博客与 Pinggy 转述的口径一致：单实例无头 Chromium 常驻内存轻松超过约 250MB，完整渲染加截图的 CPU 时间也常以秒计——「给每个 Agent 一台完整浏览器」贵到只剩高预算模型用得起，大量 agentic 应用被锁在门外。Agent 产品若要成千上万次并发会话，要么养一堆胖虚拟机并吃空闲成本，要么把浏览器配额卡到只有有钱团队付得起。

官方文档给出的基准（14 个 URL、各跑五次中位数，对比预热 Chromium 池）大致是：

指标	Kitesurf	Chromium（暖池）	方向
截图 CPU	~380 ms	~1,173 ms	约少 3.1×
截图内存	~57.8 MiB	~271 MiB	约少 4.7×
抽 HTML CPU	~229 ms	~877 ms	约少 3.8×
抽 HTML 内存	~39.4 MiB	~274 MiB	约少 7×
截图墙钟	~1,148 ms	~637 ms	Chromium 约快 1.8×
抽 HTML 墙钟	~820 ms	~472 ms	Chromium 约快 1.7×

Cloudflare 自己的解释很干脆：账单跟的是 CPU 与内存；暖池 Chromium 靠 JIT 赢墙钟，Kitesurf 用冷软件渲染换几倍资源。对「高并发、可排队」的 Agent 任务，这通常划算；对「人在等这一次点击」未必。

架构上拆成多个无状态 Worker isolate：Engine 对外说 CDP，并保存会话状态；PageScript 用 Dynamic Workers 起干净 globalThis，用 Blitz / Stylo 等 Rust→Wasm 组件做 HTML/CSS，用 Boa 处理 Worker 里不好直接 eval 的场景；PageRenderer 出图；只有 SandboxOutbound 能出网，并沿途执行 CORS、隔离 cookie。请求结束 isolate 拆掉——适合突发、中途放弃的 Agent 任务，而不是养一池长驻 Chromium。博客还写明设计前提：每个页面加载都按不可信输入处理，失败降级成空白帧或缺失元素，而不是拖死整个会话。

兼容性上，文档侧最新口径通过逾 23.5 万 项 Web Platform Tests 子测试（博客发布时写逾 21.5 万，覆盖仍在扩），DOM / HTML / Selection 等 Agent 最关心的面覆盖率公开到约 95%–99%；并能正确渲染 Wikipedia、Hacker News、TodoMVC 一类常见页——不是只挑玩具站。公开局限同样诚实：视频、WebGL、部分 bot 检测依赖的深层 TLS 指纹、依赖持久状态的长登录会话，仍可能要回 Chromium。Beta 期 Browser Run 里加 browser=kitesurf 即可切换；本地 localhost 从边缘不可达，开发机要先暴露公网 URL。Playground 还给出硬预算：单次导航约 20 秒 CPU / 60 秒墙钟，超时直接收网——这是 Agent 路径该写进超时与重试策略的数字，不是演示彩蛋。

Worker 约束：为什么「瘦」是有代价的

Kitesurf 能压资源，是因为它站在 Workers 平台的边界上——这些边界会直接变成产品选择：

1. 没有原生 eval：安全模型下 Workers 仍不原生支持 eval；博客写明用 Rust 写的 Boa 引擎「在运行时上再跑一层运行时」扛偶尔的 eval。够用，但不是免费午餐——重度依赖动态脚本生成的站点，失败率会高于暖池 Chromium。
2. Dynamic Workers 是前置能力：干净的 globalThis、按页/OOPIF 起 isolate，依赖较新的 Workers 原语；Kitesurf 本身也是「平台能力成熟之后才写得出来」的产品，不是把 Chromium 塞进边缘那么简单。
3. Isolate 用完即扔：渲染 Worker 无页面状态，卡住的 RPC 可以杀了重拉——对 Agent「试一下、失败就换 URL」极友好，对「登录后点二十步」不友好。无状态是单位经济的朋友，是长会话的敌人。
4. 硬超时写进路径：20s CPU / 60s 墙钟意味着编排层必须把「慢站 / 重站」分流到 Chromium 或拆步；把整条人类操作流塞进一次 Kitesurf 导航，会系统性超时。
5. 出网单点：只有 SandboxOutbound 能碰网络——CORS、cookie 隔离强制在应用层，而不是指望完整浏览器指纹通行证。

博客还提到计划开源，让客户把 Kitesurf 部署到自己的账户——那会把「用 Cloudflare 的 Browser Run」和「自管瘦引擎」拆成两条采购线。在开源落地前，构建者买的仍是托管 beta：免费验证任务占比，而不是现在就锁死长期单价。

商业模式：单位经济 vs Chromium 托管浏览器

Browserbase、Browserless 卖的是托管会话：底下多半是真 Chromium，按会话时长或算力计价。以 Browserbase 公开价为例（以官网为准）：Developer 约 $20 / 月 含 100 browser hours，超出约 $0.12 / 小时；Startup 约 $99 / 月 含 500 hours，超出约 $0.10 / 小时；另有并发上限（约 25 / 100）、会话创建速率、代理流量等平行计量。会话按分钟计、且常见 1 分钟起算——对「抽一次 HTML 只要几秒」的 Agent 任务，你经常在为计费粒度付溢价，而不是为渲染本身付。

Agent 框架越依赖「没有干净 API 的网页」，这一层就越像基础设施品类——分析师口径里，大量网站根本没有可调用的 API 面，任务型 Agent 的企业采用一升，浏览器自动化就从运维边角料变成真金白银的支出项。

Cloudflare 的差异不在品类名，而在 单位经济假设：多数 Agent 任务（截图、抽文、填短表、MCP 一次短浏览）不需要完整浏览器；若资源占用能压到几分之一，就可以在基础设施侧显著降价，再把一部分让利传给调用方——Pinggy 称之为非常 Cloudflare 的一手：把品类里最贵的那截商品化。Changelog 写明 beta 免费，本质是用真实流量验证：Agent 浏览里有多少比例够「瘦浏览器」扛。Browser Run 里 Chromium 与 Kitesurf 并存，也说明官方叙事是 互补默认，不是立刻取代。

粗算一下为什么单位经济会动。若截图路径内存从约 271 MiB 掉到约 58 MiB，同机可并行会话密度理论上可抬约 4～5×；HTML 抽取内存从约 274 MiB 到约 39 MiB，密度叙事可到约 7×。CPU 时间同理（约 3～4×）。云账单往往按 CPU·内存·驻留计，而不是按「像不像 Chrome」。再对照 Browserbase 式「browser hour」：一万次各 5 秒的抽取，若按 1 分钟起算，账单侧可能接近 一万分钟 ≈ 167 browser hours——仅 Developer 套餐内还装得下，但已是「为计费粒度买单」；若会话常驻等待模型思考 30 秒，小时数会再涨一截。Kitesurf 路径若最终按 CPU/内存而非墙钟会话卖，短任务的溢价结构会被拆掉——这正是品类冲击点。团队若把「一万次 HTML 抽取」全丢进暖池 Chromium，付的是为像素完美和 JIT 买的溢价；若其中八成任务其实只要干净 DOM，溢价就是纯浪费。

分流策略可以写进架构评审：

任务形状	更合理的默认	为什么
一次性截图 / 抽 HTML / PDF（兼容站）	Kitesurf	CPU/内存赢 3～7×；无状态贴合 one-shot
突发队列、可重试、失败可降级	Kitesurf	isolate 可丢可重建；适合 Agent 试错
视频、WebGL、强 bot TLS、长登录态	Chromium（Browser Run 默认或 Browserbase 类）	公开局限清单；瘦引擎不是「再调参」能补的
要代理池、验证码、长会话保真、排障录像	Browserbase 类托管 Chromium	你买的是可靠会话与周边能力，不是最低边际渲染成本
人在环、要墙钟最短	暖池 Chromium	基准表里墙钟仍赢约 1.7～1.8×

对创业公司，这把「要不要自建浏览器农场」的问题改写成了「默认走哪条引擎」：编排层继续说 CDP，成本层按任务类型分流。Grok Bot 一类「像人一样点界面」的产品，与 Kitesurf 一类「给 Agent 瘦浏览器」的基建，是同一条链上的不同层——前者卖劳动力席位，后者卖点击网页的边际成本。

定价叙事也值得单独看一眼。Browserbase 类产品卖的是「可靠会话」：你为保真、登录态与排障付费。Kitesurf 卖的是「够用的渲染」：你为并发密度付更低的边际成本。两者客户重叠，但采购问题不同——前者问「这页能不能稳定点完」，后者问「一万次截图会不会烧穿预算」。团队若把所有网页任务都丢进同一引擎，要么为简单任务多付钱，要么为复杂任务频繁失败；分流才是产品化用法。Beta 免费期最该量的不是「能不能打开 Wikipedia」，而是：自家 URL 分布里，有百分之多少能在 20s/60s 预算内用 Kitesurf 交付干净结果——这个比例，才是未来账单谈判的筹码。

和常识不一样的地方

常识一：Agent 要浏览，就得上完整 Chromium。
很多生产路径只要 DOM + 截图 + 短脚本；完整浏览器是遗留默认，不是任务需求。Cloudflare 博客甚至把「AI 不在乎标签页与主题」写成产品需求清单的第一行。

常识二：墙钟更快一定更省钱。
云账单更常跟 CPU 时间与内存驻留走。Kitesurf 用一点延迟换几倍资源，是在为并发密度出价——基准表里墙钟输 1.7～1.8×，CPU/内存却赢 3～7×。Browserbase 式小时计费还会放大「短任务被分钟粒度抬价」的扭曲。

常识三：换引擎等于换 SDK。
CDP 兼容把迁移成本压成改 URL；失败模式「不行就切回 Chromium」也很便宜——这才是 beta 阶段值得现在试的原因。Worker 约束（无原生 eval、硬超时、无状态）才是真正要写进设计文档的，而不是 SDK 迁移工时。

数据来源

• Introducing Kitesurf：跑在 Workers 上的 Agent 优先浏览器（Cloudflare Blog）
• Kitesurf 文档与基准表（Cloudflare Docs）
• Inside Kitesurf：Cloudflare 为 AI Agent 重写的浏览器引擎（Pinggy）