Kitesurf迈向智能体浏览器
Cloudflare AI··作者 Celso Martinho
关键信息
Kitesurf可以通过Chrome DevTools MCP配置中的实验性WebMCP集成，发现Cloudflare Radar等网站暴露的工具，例如navigate-to和set-location。Cloudflare还加入了基于URL的模块解析、JSON模块、导入映射表、通过Workers模块注册表进行URL导入的能力，并减少了Boa与DOM之间JavaScript交互的开销。
资讯摘要
Cloudflare在8月推出了Kitesurf，将其定位为面向智能体时代、完全运行在Cloudflare Workers上的浏览器。Kitesurf没有继承面向人类用户的浏览器所包含的大量功能和开销，而是围绕AI智能体访问网页所需的能力进行设计。Cloudflare使用越来越真实的任务对其进行测试，并结合客户反馈进行了更新，如今Kitesurf已经加入WebMCP支持。WebMCP允许网站直接向智能体暴露结构化函数，使智能体可以调用searchFlights()这样的操作，而不必模拟一连串点击。
在Cloudflare Radar中，Kitesurf可以通过公开体验环境和DevTools面板发现navigate-to、set-location等工具。该浏览器现在支持更多Web标准，包括基于URL的模块解析、JSON模块和导入映射表，同时改进了iframe的加载时机、隔离效果、文本显示以及语言和编码处理。Cloudflare表示，Kitesurf目前通过了超过73万个Web Platform Tests子测试，比发布时增加了50万个；其内部优化还降低了DOM遍历、计时器、字体获取以及Boa与DOM之间JavaScript执行的开销。
资讯正文
今年8月，我们推出了 Kitesurf——一款面向代理时代的浏览器，完全运行在 Cloudflare Workers 上。我们围绕代理对 Web 的需求来构建它，而不是沿用为人类设计的浏览器所包含的全部功能和臃肿。如果这是你第一次听说 Kitesurf，我们强烈建议你阅读介绍 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 Agent 使用 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 模块和 import map 处理能力——对于那些分块加载 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 现在会在需要时加载字体，减少获取页面不会使用的字体数量；在获取特定语言的字体文件前，会先检查页面中出现了哪些字符；同时，它对合成斜体的渲染也更加准确。
这些优化共同帮助 Kitesurf 保持对代理而言的高效率。尽管我们增加了对更多 Web 标准的支持，并让 Kitesurf 更接近 Chrome 等功能完整的浏览器的能力，但其实际运行时间和 CPU 使用量仍大致与发布时的基准保持一致，在某些情况下甚至有所改善。
与 Browser Run 更好地协作
Browser Run 是我们的开发者平台产品，允许你通过编程方式控制并运行无头浏览器实例。使用该 API 时，你可以从我们支持的浏览器类型列表中进行选择，其中包括 Kitesurf。
这意味着我们必须确保所有浏览器都能在整个 API 范围内获得支持。从今天开始，Kitesurf 已实现对 Browser Run API 的全面覆盖。你可以通过 CDP、Playwright、Puppeteer 或 MCP 使用 Kitesurf。
Browser Run 最受欢迎的功能之一是 Quick Actions，它为常见的浏览器任务提供了简单的接口，例如截取屏幕截图、提取 HTML 内容、生成 PDF 等。Kitesurf 发布时，你可以通过我们的 REST API 使用 Quick Actions。现在，你也可以在 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，并且无法访问任何特殊权限。这不仅是内部试用并验证我们自有平台的绝佳方式，也是让 Kitesurf 保持极低成本，并能够在 Cloudflare 全球网络上自动扩展的唯一途径。
欢迎在更新后的 kitesurf.dev playground 中试用 Kitesurf，并通过 Browser Run 将其用于你的项目。在测试阶段，Kitesurf 可免费使用，但每个账户会受到相应限制。请关注我们的更新日志，也欢迎在 Discord 上与团队交流。分享你的使用体验并向我们发送反馈——我们会认真听取。
来源与参考
收录于 2026-09-29