你团队里的 AI Agent 需要访问网页的时候，背后是怎么做的？

目前大部分方案都绕不开 Chromium——要么用 Puppeteer/Playwright 拉起一个无头 Chrome，要么用 Browserless/Selenium 之类的云端方案。结果呢？一个无头 Chrome 实例动辄占用 200-300MB 内存，CPU 开销也大得离谱。对于需要同时跑几十上百个 Agent 的场景，这笔开销直接反映在账单上。

昨天 Cloudflare 在 Agents Week 上扔了一枚重磅炸弹：Kitesurf——一个完全跑在 Workers V8 Isolate 里的浏览器，专门为 AI Agent 设计，没有 Chromium，没有单独的 Node.js 进程，只用了 12 周就从灵感走到了 Beta 发布。

Chromium 很好，但 Agent 需要的不是这些

Cloudflare 团队直白地说了一个很多人心知肚明但没人敢直说的事实：Chromium 是为人类设计的，不是为 AI Agent 设计的。

人类用户需要标签页、主题、扩展插件、设备间同步、60fps 顺滑滚动。Agent 在乎的是什么？Token 开销、上下文窗口、延迟、并发、可扩展性——这些 Chromium 一个都没优化过。

更关键的是，Chromium 的安全模型和 Agent 的使用场景完全不匹配。Agent 需要访问的页面来自不可信的第三方来源，prompt injection、工具滥用等新型攻击面在 Chromium 的架构里根本没有考虑。

所以 Cloudflare 问了自己一个问题：我们能不能重新造一个浏览器，只保留 Agent 需要的部分，砍掉所有人类专属的包袱？

答案是 Yes，而且只用了 12 周。

12 周从零到发布：Rust + Wasm 堆栈

Kitesurf 的起点是一个叫 Obscura 的开源项目——一个用 Rust 写的无头浏览器引擎，没有任何 Chrome/Node.js 依赖。Cloudflare 团队在 AI Agent 的帮助下，花了 12 周把它移植到了 Workers 平台上。

结果是一个三层架构的浏览器，完全跑在 Cloudflare Workers 的 V8 Isolate 里：

三层架构

1. Engine（引擎层）

Engine 是 Kitesurf 唯一对外的组件。它处理 Chrome DevTools Protocol（CDP）的 WebSocket 和 HTTP REST API，管理每个 session 的状态。所有其他组件都是无状态的。

这意味着你现有的 Puppeteer、Playwright、chrome-remote-interface 脚本几乎不用改就能直接切到 Kitesurf。

2. PageScript（页面脚本层）

每个页面或跨进程 iframe（OOPIF）通过 Dynamic Workers 启动一个独立的 PageScript Isolate。这个 Isolate 有干净的 globalThis 和 DOM document 对象。

HTML 和 CSS 解析用 Blitz（一个模块化渲染引擎）和 Stylo（Firefox 的高性能 CSS 解析器）——都是 Rust 写的。JavaScript 和 WebAssembly 在同一个 Isolate 里执行。对于 eval 场景，他们用 Boa JS（另一个 Rust ECMAScript 引擎）做运行时之上的运行时。

3. PageRenderer（页面渲染层）

负责把 computed page object 变成像素。Engine 每次需要一帧时，PageRenderer 从 PageScript 拿到页面对象（scene），拉取内部字体和图片，用 blitz-paint + Parley 做文字排版和光栅化，返回 JPEG/PNG/PDF。

Workers 内置的 RPC 系统让这一切变得简单——Engine Worker 调用 renderFrame() 就像调用本地函数一样，实际跨 Isolate 执行。

性能数据：3-7 倍差距

Cloudflare 放出了一组对比数据，非常直观：

关键洞察：Kitesurf 在绝对速度上略慢于 Chromium（JIT 预热后的引擎总是比冷启动的软件光栅化快），但在真正决定成本的内存和 CPU 上，Kitesurf 领先 3-7 倍。更少的内存意味着可以运行更多并发 Session，更低的 CPU 意味着更少的计算资源消耗——这直接体现为更低的账单。

安全设计：默认隔离

Kitesurf 的安全模型值得单独拎出来说。

传统浏览器在人类使用场景下，同一用户的多个标签页共享资源是可以接受的。但 Agent 访问的页面来自不可信的、任意来源。Kitesurf 的假设是：每个页面加载都是不可信的输入，每个 Session 从零开始。

具体做法：

• SandboxOutbound Worker：唯一能接触网络的组件，强制 CORS，注入浏览器特征头，过滤响应，每个页面的 Cookie 独立管理
• 组件级隔离：每个组件只能访问其功能所需的最小资源
• 无状态优先：无状态组件可随时销毁和重建，崩溃只是重启

这和我们已经讨论过的 MCP 安全模型 形成互补——MCP 解决的是 Agent 之间通信的安全，Kitesurf 解决的是 Agent 访问 Web 的运行时安全。

可用性：免费 Beta，CDP 兼容

Kitesurf 已经在 Cloudflare Browser Run 中开放 Beta，免费使用（有账户级别限制）。

现有 Puppeteer/Playwright 用户只需要在 Browser Run 的 CDP endpoint 上加一个 browser=kitesurf 参数即可切换。甚至可以直接和 OpenCode 等 MCP 客户端集成：

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx", "-y", "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <API_TOKEN>\"}"
      ],
      "enabled": true
    }
  }
}

Cloudflare 还提供了一个公开的 Playground，可以输入任意 URL 看 Kitesurf 的渲染效果，甚至可以直接在页面里打开 Chrome DevTools 检查 DOM、Console、Network。最有趣的是 Memory 面板——它可以报告每个 Isolate 的 WebAssembly 内存占用。

还不能做什么？

公平地说，Kitesurf 只有 12 周大，不是万能的：

• ❌ 不能播放视频
• ❌ 不支持 WebGL
• ❌ 无法处理 bot challenge 握手（如 Cloudflare 自己的挑战页面）
• ❌ 不支持需要持久化 State 的长会话（如 10 分钟的认证流程）

对于这些场景，Cloudflare 推荐继续用 Browser Run 的默认 Chromium 后端。Kitesurf 最适合的是一次性、短周期、高并发的 Agent 任务——截个图、提取 HTML、做个 PDF，然后释放。

Cloudflare 也承诺未来会开源 Kitesurf，让客户可以在自己的账户上部署自己的版本。

写在最后

Kitesurf 的出现释放了一个明确的信号：AI Agent 的基础设施正在从「拿人类工具硬改」走向「从零设计」。就像当年容器化推动了从 VM 思维到 Container 思维的转变一样，Agent 时代也会催生一批全新的基础组件——Agent 专用的浏览器只是其中之一。

12 周从灵感到 Beta，Rust + Wasm + Workers 的技术栈，比 Chromium 少 7 倍内存——这些数字本身就很 Cloudflare：用架构优势换成本优势，而不是用功能堆叠换增长。

如果你也在跑 Agent 业务，给 Kitesurf 一个机会。免费的，试试不吃亏。

延伸阅读：最近 AI Agent 基础设施领域还有不少大动作——Agent Plugins 1.0 标准发布 和 Microsoft 的 Token 预算「急刹车」 都值得一读。