浏览器自动化正在从测试工具扩展到 AI Agent、数据采集、网页操作和后台任务。Cloudflare 最近公布了 Kitesurf，一个面向自动化工作负载的轻量浏览器。它把浏览器组件运行在 Cloudflare Workers 上隔离的 WebAssembly/Rust 环境中，并通过 Chrome DevTools Protocol（CDP）兼容 Playwright、Puppeteer 等现有工具。
这意味着开发者不必为每个自动化任务都启动一个完整的 Chromium 实例，可以用更贴近无服务器运行方式的浏览器引擎承载 Agent 工作流。
Kitesurf 解决的是什么问题
传统浏览器自动化通常直接启动 Chromium。这个方案兼容性强，但资源成本也明显：浏览器进程需要占用内存，启动时间较长，并且在多租户或高并发任务中需要额外处理进程隔离、生命周期管理和资源限制。
Kitesurf 的定位更轻量。根据公开介绍，它将浏览器组件放入隔离的 WebAssembly 和 Rust 环境，并运行在 Cloudflare Workers 的执行模型中。对自动化任务而言，这种架构有几个直接价值：
- 浏览器任务可以更接近无服务器函数的方式启动和回收。
- 隔离执行环境适合处理来自不同用户或不同任务的网页操作。
- Rust 和 WebAssembly 有助于控制运行时开销，但具体性能仍取决于页面复杂度、网络请求和脚本执行情况。
- 通过 CDP 暴露控制接口，现有 Playwright 或 Puppeteer 工作流有机会以较小改动迁移。
这里的关键不是“把 Chromium 缩小”这么简单，而是重新考虑浏览器自动化的运行边界：浏览器不再只是开发者电脑上的测试进程，也可以成为边缘任务和 Agent 工作流中的基础执行单元。
CDP 让上层工具保持熟悉
Chrome DevTools Protocol 是浏览器调试和自动化生态的重要接口。Playwright 和 Puppeteer 都可以通过 CDP 连接到兼容的浏览器服务，因此业务代码通常仍然可以使用熟悉的页面导航、元素定位、截图和脚本执行 API。
可以这样理解分层关系：
Agent / 业务任务
|
Playwright 或 Puppeteer
|
Chrome DevTools Protocol
|
Kitesurf 浏览器运行时
|
Cloudflare Workers 隔离环境
不过，CDP 兼容并不自动意味着所有 Chromium 行为都完全一致。实际迁移时，需要重点验证以下内容：
- 页面导航和等待策略是否符合预期。
- JavaScript、Cookie、Storage 和网络拦截能力是否完整。
- 是否支持项目依赖的 PDF、下载、扩展、字体或媒体能力。
- 目标网站是否依赖真实浏览器特征、持久化会话或复杂的人机验证。
- 单次任务的 CPU、内存、执行时长和并发限制如何计费或限制。
一个可改造的 CDP 调用示例
下面的示例使用 Playwright 连接到一个 CDP 浏览器端点。CDP_ENDPOINT 是部署 Kitesurf 后由运行环境提供的地址，示例不假定具体的 Cloudflare 配置或端点格式。把它替换成实际地址后，就可以用于验证导航、读取标题和抓取页面文本。
先创建一个 Node.js 项目并安装 Playwright：
mkdir kitesurf-cdp-demo
cd kitesurf-cdp-demo
npm init -y
npm install playwright
export CDP_ENDPOINT="http://127.0.0.1:9222"
创建 check-page.mjs：
import { chromium } from "playwright";
const endpoint = process.env.CDP_ENDPOINT;
if (!endpoint) {
throw new Error("请设置 CDP_ENDPOINT，例如 http://127.0.0.1:9222");
}
const browser = await chromium.connectOverCDP(endpoint);
const context = browser.contexts()[0] ?? await browser.newContext();
const page = await context.newPage();
try {
await page.goto("https://example.com", {
waitUntil: "domcontentloaded",
timeout: 30_000,
});
console.log("title:", await page.title());
console.log("text:", (await page.locator("body").innerText()).slice(0, 500));
} finally {
await page.close();
await browser.close();
}
运行：
node check-page.mjs
这个示例适合做第一轮兼容性检查。接入 Agent 时，可以把 page.goto 替换成任务规划器生成的导航步骤，把页面文本交给模型分析，再让模型通过经过约束的动作集合执行点击或填写。生产环境中不要直接允许模型执行任意 JavaScript；应限制可访问域名、操作类型、超时时间和单任务请求数量。
采用时要权衡什么
Kitesurf 最适合短生命周期、可水平扩展、对资源开销敏感的浏览器任务，例如页面检查、轻量数据提取、自动化表单操作和 Agent 的网页交互步骤。它不一定适合所有浏览器场景。需要完整 Chromium 兼容性、复杂下载流程、浏览器扩展、长期会话或高保真视觉回归测试时，传统浏览器运行时可能仍然更稳妥。
迁移可以按以下顺序推进：
- 用 CDP 连接一个最小页面任务，验证导航、选择器、脚本和会话行为。
- 记录冷启动时间、单任务内存、执行时长和并发下的失败率。
- 为任务设置域名白名单、网络超时、最大页面数和资源配额。
- 将浏览器能力封装在业务接口后面，避免业务代码依赖特定运行时细节。
- 对登录、验证码、下载、文件上传和复杂前端应用建立单独的兼容性测试。
Kitesurf 的价值在于为浏览器自动化提供一种更轻、更接近边缘计算的执行形态。真正是否值得采用，仍应由实际页面类型、并发模型、隔离要求和 CDP 兼容性测试来决定，而不是只看浏览器启动速度。