Cloudflare 更新 Kitesurf 浏览器，支持 WebMCP 与终端运行

8 月，我们推出了 Kitesurf，这是一款专为智能体时代打造的浏览器，完全运行在 Cloudflare Workers 上。我们围绕智能体对网络的需求构建了它，而不是承载专为人类设计的浏览器所具备的所有功能和臃肿内容。如果你是第一次听说它，我们强烈建议你阅读这篇博客文章我们介绍 Kitesurf 的地方，以获取关于我们如何实现它的所有精彩技术细节。

自那时起，我们让 Kitesurf 执行了日益逼真的任务，并利用来自客户的内部和外部反馈使其功能更强大、效率更高。以下是所发生的变化、你今天如何尝试它，以及我们接下来的发展方向。

WebMCP 支持

网站并非为智能体使用而构建。如今的浏览过程是一个混乱的过程，需要点击像素并祈祷正确的元素加载。在程序化世界中，这是缓慢且脆弱的。WebMCP 通过允许开发者直接向智能体公开网站功能来提供帮助，智能体可以在其中调用诸如 searchFlights() 之类的函数，而不是模拟点击。

Cloudflare 自早期以来一直支持 WebMCP；就在几周前，我们宣布网站所有者现在可以通过一个开关开启 WebMCP，这样浏览器智能体无需更改网站代码即可发现并使用其网站上的工具，而且 Browser Run 在使用 Chrome beta 时也已经支持 WebMCP 一段时间了。

今天我们宣布 Kitesurf 现已支持 WebMCP。

你可以通过访问我们的公共 Kitesurf playground，打开 Cloudflare Radar，并导航到 DevTools 面板中 Application 选项卡下的 WebMCP 来进行测试。正如你所见，Radar 公开了一系列 WebMCP 工具，例如 navigate-to 或 set-location，它们允许客户端与页面交互并以编程方式探索 Radar。

如果你将 AI 智能体指向 Kitesurf：

{
  "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 <BEARER_TOKEN>\"}",
        "--category-experimental-webmcp"
      ],
      "enabled": true
    }
  }
}

你可以看到 AI 模型可以与公开的 WebMCP 工具进行交互，你可以利用这些工具更可靠地完成任务。

你可以在此阅读更多关于如何将 WebMCP 与 Kitesurf 和 Browser Run 结合使用的信息。

新 API，更好的 WPT 覆盖率

自最初发布以来，我们一直在增加更多的浏览器标准，以便智能体能够渲染更复杂的页面。Kitesurf 支持的 API 列表已经增加，现在包括：

我们增加了基于 URL 的模块解析、JSON 模块和导入映射处理——这对分块加载 JavaScript 的网站很重要。此外，我们正在使用新的 Cloudflare Workers 模块注册表来支持从 URL 导入。

Iframe 的行为也得到了改善；现在它们可以在正确的时间加载，保持更好的隔离性，并能更准确地显示跨多种语言和编码的文本。

正如我们在发布时所说，运行测试是我们控制代码和结果质量，同时在改进 Kitesurf 时保持开发速度的方法。Web Platform Tests (WPT) 是一个共享的开源测试套件，用于检查浏览器是否一致地实现了 Web 标准。

我们现在通过了 730,000 多个 WPT 子测试，并且数量还在增加。这比我们发布时增加了 500,000 个子测试。在这里，你可以看到自我们启动该项目以来，测试数量随时间演变的情况，直至最新版本：

针对智能体优化的效率

对于 AI 智能体而言，效率与其说是关于页面加载速度，不如说是关于智能体循环的延迟。为了让 Kitesurf 真正具备智能体能力，我们对浏览器引擎的内部结构进行了深度优化，使每一次 DOM 遍历、计时器和字体获取都尽可能轻量化，确保智能体将计算周期花在推理上，而不是等待浏览器响应。

这些优化包括：

改进了 JavaScript 执行效率，减少了 Boa 与 DOM 之间的交互工作，使边界与真实的 Web 框架更加兼容。常见的读取操作（如 getAttribute、id 和 parentNode）现在可以在 Wasm DOM 内部完成，而无需重复进行“Boa → JavaScript shim → Wasm”的往返调用。
Kitesurf 在运行计时器和加载脚本时减少了重复工作，并释放了不再需要的对象内存。当代码在其两个 JavaScript 引擎之间移动时，它也能更一致地处理对象和类，从而更高效地运行繁忙页面。
Kitesurf 现在仅在需要时加载字体，减少了页面不会用到的字体获取，在获取特定语言的字体文件前会检查页面上出现的字符，并能更准确地渲染合成斜体。

总的来说，这些优化有助于保持 Kitesurf 对智能体的高效性。尽管增加了对更多 Web 标准的支持，并使 Kitesurf 更接近 Chrome 等全功能浏览器的能力，但其挂钟时间和 CPU 使用率仍与我们发布时的基准基本持平，在某些情况下甚至有所改善。

与 Browser Run 配合更佳

Browser Run 是我们的开发者平台产品，允许你以编程方式控制和运行无头浏览器实例。当你使用此 API 时，可以从我们支持的浏览器列表中进行选择，包括 Kitesurf。

这意味着我们必须确保所有浏览器都能在 API 接口上得到支持。从今天开始，Kitesurf 已全面覆盖 Browser Run API。你可以将 Kitesurf 与 CDP、Playwright、Puppeteer 或 MCP 一起使用。

作为 Browser Run 最受欢迎的功能之一，快速操作 (Quick Actions) 为常见的浏览器任务（如截屏、提取 HTML 内容、生成 PDF 等）提供了简单的接口。当我们发布 Kitesurf 时，你可以通过我们的 REST API 使用快速操作。现在，你也可以在 Worker 脚本中使用 env.BROWSER.quickAction() 绑定来使用它们：

interface Env {
	BROWSER: BrowserRun;
}

export default {
	async fetch(request, env): Promise<Response> {
		return await env.BROWSER.quickAction("screenshot", {
			url: "https://example.com",
			browser: "kitesurf"
		});
	},
} satisfies ExportedHandler<Env>;

Kitesurf 现在可以在终端中运行

正如我们在公告博客文章的构建方式部分所详述的那样，Kitesurf 将 PageScript（处理页面会话并运行页面代码的隔离区）与 PageRenderer（负责根据计算出的页面对象生成实际像素）分离开来。

这不仅提供了出色的隔离性和灵活性，还使我们能够解耦并将渲染逻辑移至 Kitesurf 之外（例如移至客户端或另一个 Worker），同时将安全关键部分保留在服务器端，在我们的网络中运行。

如果这个模型听起来很熟悉，那可能是因为 Cloudflare 还有另一款名为 Cloudflare Browser Isolation 的 SASE 产品，它在我们的全球网络边缘运行所有不受信任的 Web 代码，同时将渲染数据“流式传输”回客户端。

我们可以用 Kitesurf 做类似的事情。为了证明这一点，我们将 PageRenderer 移到了我们的 Playground Worker 中，并对该版本进行了修补，使其不再将场景数据转换为图像，而是输出到 Kitty——这是一种现代终端（如 Kitty 本身、Ghostty、WezTerm 等）支持的终端图形协议。我们甚至更进一步，为不支持 Kitty 的环境添加了纯 ANSI 文本模式。

结果就是，你现在无需离开舒适的终端应用程序，即可快速打开并渲染页面。这不仅非常有用，因为你现在可以一眼浏览现代 Web 而无需切换上下文，而且你还可以使用此工具查看使用 Kitesurf 的代理是如何“看待”页面的。

要安装 Kitesurf 的终端版本，请执行以下操作：

$ brew install cloudflare/cloudflare/kitesurf

从现在开始，只需在终端中输入：

$ kitesurf https://blog.cloudflare.com
$ kitesurf --help

这是一个运行演示。

终端还会回传滚动和点击事件，因此你可以像在专用浏览器应用程序窗口中一样正常使用键盘、箭头键或鼠标。

这是我们的 Silent Space Marine Doom 演示在终端内的 Kitesurf 中运行的效果：

我们接下来的方向

我们继续在为客户和开发者打造最佳代理浏览器的道路上快速迭代。预计性能基准测试会越来越好，支持的 Web 标准列表和 WPT 测试覆盖率也会持续快速上升。事实上，我们已决定将结果在此和在此公开，以便你在我们前进的过程中实时跟踪它们。

我们将继续探索将 Kitesurf 解耦并将 PageRenderer 从 PageScript 中移出对代理有优势的场景，或者对更高帧率至关重要的场景。在我们撰写本文时，我们可能（也可能没有）有一个在 Kitesurf 中运行的 30fps Doom 版本。

我们还想解决一个显而易见的问题：虽然我们目前优先考虑快速开发，但我们仍然致力于开源 Kitesurf。这很快就会实现，但我们希望以正确的方式进行，因此我们已做好长期支持它的准备。

Kitesurf 忠实于其最初的设计目标：它像任何其他客户应用程序一样，完全运行在 Workers 之上；这意味着我们仅使用公开可用的功能和 API，没有任何特殊权限。这不仅是验证我们自身平台并进行“吃自己狗粮”（dogfooding）的绝佳方式，也是使 Kitesurf 成本极低并能在 Cloudflare 全球网络上自动扩展的唯一途径。

欢迎在焕然一新的 kitesurf.dev 演练场中试用 Kitesurf，并通过 Browser Run 在您的项目中使用它。它在测试阶段免费提供，但受每个账户的限制。请关注我们的更新日志，并欢迎在 Discord 上与团队交流。分享您的使用体验并向我们发送反馈——我们随时倾听。