让 Agent 上网，现在的主流做法是给它一整套 Chromium：开一个容器、连一个 CDP 端口、点、截图、读 DOM。这套办法能跑通，但成本结构很难看——每多一个并发会话，就多一份完整的桌面浏览器开销。
Cloudflare 走的是另一条路。它 8 月推出的 Kitesurf 是一个跑在 Cloudflare Workers 上的浏览器引擎：自己解析 HTML、套用 CSS、执行页面里的 JavaScript、渲染截图，底下没有任何 Chromium 进程或容器。当地时间 11 月 13 日，Cloudflare 把这个项目开源了。
仓库 cloudflare/kitesurf 采用 Apache-2.0，截至 2026-11-14 约 930 star、41 个 fork、375 次提交，官方在 About 里写得很清楚：experimental，实验性项目。
它砍掉了什么，又留下了什么
官方的说法是，Kitesurf 没有照搬完整的桌面浏览器引擎，而是只保留 Agent 真正用得上的那部分。取舍清单很直白：
| 保留 | 舍弃 |
|---|---|
| HTML 解析、DOM、布局与绘制 | 标签页 |
| CSS 解析、层叠与计算样式 | 外观主题 |
| 页面 JavaScript 执行 | 浏览器扩展 |
| 截图渲染 | 像素级精确渲染 |
它优化的指标也跟着换了：Token 消耗量、上下文窗口占用、可扩展性、性能、成本。这五项恰好是"人类浏览网页"时根本不会考虑的指标——人会看字体有没有糊、动画顺不顺，Agent 只关心这一页得花多少 token、能不能同时开两百个。
底下拼的是一组 Rust 开源项目：Blitz 负责 HTML 解析、DOM、布局和绘制；Stylo（来自 Servo）负责 CSS 解析与计算样式；Boa 在 WebAssembly 里跑页面 JavaScript；Linebender 家的 Parley、Vello、Kurbo、Peniko 负责文字排版和 2D 图形；Krilla 负责生成 PDF。整个仓库用 Bazel 构建，Cloudflare 还给这些 Rust 依赖打了一组补丁，补丁序列就放在 scripts/patches/ 里，由 Bazel 自动应用。
接法：因为它说 CDP，所以现有工具能直接用
这是 Kitesurf 最聪明的一处设计：它实现了 Chrome DevTools Protocol，所以 Puppeteer 这类现成的 CDP 客户端不用改代码就能连上去。
import puppeteer from "puppeteer-core";
const browser = await puppeteer.connect({
browserWSEndpoint: "ws://127.0.0.1:8787/devtools/browser",
});
const page = await browser.newPage();
await page.goto("https://example.com/");
await page.screenshot({ path: "page.png" });
await browser.disconnect();本地跑起来要几样东西：Bazelisk（命令名是 bazel）、Node.js 22 以上、pnpm 9.15.4，macOS 上还要装 GNU tar（brew install gnu-tar）。pnpm run dev 会先用 Bazel 编 WebAssembly 模块和渲染包，再起 wrangler dev；第一次编译 Rust 核心要等一会儿，之后走缓存。默认监听 127.0.0.1:8787，/health 能确认是否起来了。
仓库里还有一个终端客户端包 kitesurf-cli，以及可选的 DevTools 前端。要注意，默认构建不包含前端：要用得加 --config=devtools 重新构建，第一次会下载约 250 MB 的前端包。不加的时候，DevTools 界面是从 Google 托管的 chrome-devtools-frontend.appspot.com 拉取的，而且它只能连 127.0.0.1，所以部署出去的引擎用不了这套界面。
三个必须在动手前知道的限制
一、它是"实验性"的，而且不是零成本。Kitesurf 需要 Cloudflare Dynamic Workers 来给每个页面和渲染器开独立 worker，而 Dynamic Workers 属于 Workers 付费计划。换句话说，本地玩可以，真要跑在 Cloudflare 上，得先有付费账户。
二、它自己没有鉴权。README 里有一段加粗警告：不要把没有鉴权的 Kitesurf 部署出去，前面必须挡一层 Cloudflare Access 或别的认证。原因写得非常具体——拿到 URL 的人可以用你的引擎浏览网页、接 Puppeteer、以你的 Cloudflare 账户身份发出站请求、消耗你付费的 CPU 和 Dynamic Workers。而 workers.dev 的地址默认是公开的，命名还遵循可预测的 kitesurf.<你的子域>.workers.dev。部署命令和加 Access 之间那段时间，引擎就是裸奔的。这不算 Kitesurf 独有的问题，但一个"给 Agent 用的浏览器"落在公网上，风险比静态站高一个量级。
三、它不是 Chrome。官方明说提供的是 CDP 端点，不是完整 Chrome 实现，部分 DevTools 功能还不支持。像素级精确渲染是被主动放弃的——如果你的任务依赖"这一像素对不对"，Kitesurf 不适合。
三条路线，各有各的代价
把今天能用的 Agent 浏览器方案摆在一起，差异其实很清楚：
| 路线 | 代表 | 保真度 | 单会话成本 | 适合 |
|---|---|---|---|---|
| 驱动真实 Chrome | Chrome DevTools MCP | 最高，就是真浏览器 | 一整套浏览器 | 调试、性能分析、登录态 |
| 命令驱动的浏览器 | Vercel agent-browser | 高 | 中等 | 脚本化操作网页 |
| 自建引擎 | Kitesurf | 够用但不精确 | 低，按页开 isolate | 高并发抓取、截图、HTML 提取 |
这张表里没有"更好"，只有"更便宜"。Kitesurf 换来的东西是可扩展性：官方说在截图、HTML 提取这类常见任务上，它的 CPU 和内存消耗显著低于 Chromium，因此能同时跑更多会话——但这句话没有给任何数字，是官方口径，不是可复核的基准。
该信多少
- 本文读了仓库 README 与 IT 之家的报道，没有安装、没有运行、没有做任何性能对比。
- "资源占用显著低于 Chromium"来自 Cloudflare 官方表述，公开材料里没有具体数值；IT 之家的报道也是转述这句话，没有附测试数据。任何"省了百分之多少"的说法，目前都缺原始依据。
- 约 930 星、375 次提交是 2026-11-14 抓取时的状态；experimental 项目的接口和目录结构都可能变。
- 它是浏览器引擎，不是爬虫合规方案。抓什么、抓谁的页面，责任在调用方。
一句话判断
Kitesurf 的价值不在于"又有一个浏览器"，而在于它把 Agent 浏览器的成本模型摊开重算了一遍：人不需要的东西（标签页、主题、扩展、像素级渲染）全部砍掉，只留解析、执行和截图，再把 CDP 这层接口保留下来，让既有工具无缝接上。代价是保真度和成熟度，还有你必须自己补上的那层鉴权。
如果你的 Agent 每天要开几百个页面只为了拿一段文字或一张截图，它值得盯；如果你要的是"和人看到的完全一样"，现在还不是时候。
来源
- cloudflare/kitesurf（README、技术栈、部署与安全警告；约 930 星，Apache-2.0，2026-11-14 读取）
- IT之家：Cloudflare 开源为 AI 智能体打造的浏览器 Kitesurf（2026-11-14 18:06）
说明：本文为官方文档与报道解读，未安装或运行 Kitesurf；资源占用的说法为 Cloudflare 官方口径，暂无公开数值。
——诺谱