Kitesurf 与 Obscura：AI 浏览器属于谁？

如今谈到 AI 浏览器，许多人首先想到的是带聊天窗口的普通浏览器。AI 可以汇总标签页、回答问题或代填表单。但从技术上看，更有意思的是另一类产品：根本不是为人类设计的浏览器引擎。它们没有可见窗口，由 API 控制，甚至可能只在一次任务期间存在。

我在关于 WebMCP 与代理式 Web 的文章中讨论了网站如何向代理提供结构化功能。Kitesurf 和 Obscura 处理的是问题的另一面。只要大部分 Web 还没有代理接口，AI 系统就仍需要一套能够读取和操作普通网页的引擎。

Cloudflare 正是在这里定位 Kitesurf。这款新浏览器运行在 Cloudflare Workers 上，支持 Chrome DevTools Protocol，目标是以远低于完整 Chromium 进程的成本向代理提供网页。值得关注的不只是架构。Cloudflare 自己表示，首个原型受到了独立 Rust 开源浏览器 Obscura 的启发。

但 Obscura 还有另一个目标。其可选的 Stealth 模式试图隐藏自动化浏览器的典型特征。Kitesurf 并不这样做。恰恰相反，Browser Run 会有意标记出站请求，使网站运营者能够将其识别为 Cloudflare 自动化流量，并以密码学方式验证。

这便引出了一个令人不安的问题：Cloudflare 是否采用了一个优秀的开源思路，去掉了对机器人识别不方便的部分，然后更愿意打造一个由自己控制的产品？

简短回答是：这种批评部分指出了真实的利益冲突，但目前没有证据表明这就是 Kitesurf 诞生的原因。 从技术和战略上看，这并不只是 Obscura 的“净化版”复制品。

测试依据与局限

本文分析基于 Cloudflare 2026 年 8 月 6 日的文章、当时最新的 Browser Run 文档，以及我在 2026 年 8 月 25 日对 Obscura 公共仓库代码和文档的审查。当时最新的 Obscura 0.2.1 于两天前发布。审查重点包括架构、网络路径、Stealth 实现、安全说明、发布说明以及独立的基准测试仓库。

我没有自行测量 Kitesurf 的性能，也没有针对生产环境中的机器人挑战进行尝试。因此，有关识别能力的判断来自实现、已记录的限制和厂商公布的基准测试。凡是由此推断 Cloudflare 战略意图的部分，都明确属于评论，而不是该公司的确认声明。

AI 浏览器在技术上必须做到什么

传统浏览器是一台庞大的通用机器。它渲染复杂 CSS、播放媒体、通过 GPU 加速图形、管理扩展、同步配置，并让大量标签页稳定运行数小时。对于只需要读取商品页、找到按钮或生成截图的代理而言，其中很大一部分都是负担。

但代理仍需要的不只是 HTTP 客户端。现代网页最初往往只返回近乎空白的 HTML 骨架。JavaScript 随后构建真正的内容、发起更多请求、修改 DOM，并响应用户操作。因此，一款可用的 AI 浏览器至少需要：

• JavaScript 运行时
• 足够兼容的 DOM
• 网络、Cookie 与 Origin 逻辑
• 鼠标、键盘、表单和导航事件
• 面向代理与自动化工具的接口
• 视任务而定的布局、截图与 PDF 输出
• 对外来代码、执行时间、内存和网络访问的严格限制

Kitesurf 和 Obscura 都把 Chromium 缩减为与代理相关的部分。两者都提供 CDP，使 Playwright 和 Puppeteer 等现有工具不必为全新接口重写。两者都执行真正的 JavaScript 并构建动态 DOM，也都开发自己的渲染路径，而不是仅用不同启动参数调用 Chromium。

这让它们成为自动化浏览器引擎。语言模型、任务规划、权限，以及代理是否应执行某项操作的决策仍位于其上层。这种分离非常重要。快速的浏览器无法把不可靠的代理变成安全的代理。

Kitesurf：由 Workers 组成的浏览器

Cloudflare 没有把 Kitesurf 构建成单个可执行文件。引擎分布在多个 Worker 组件上，每个组件具有不同的信任边界。

Engine、PageScript 与 PageRenderer

Engine Worker 是公共入口。它接收 CDP 连接和 REST 调用，并维护 Session 状态，因此现有 CDP 客户端可以像连接 Chrome 一样连接 Kitesurf。

Kitesurf 会为每个页面和独立 iframe 启动一个 PageScript Worker。它获得新的全局 JavaScript 上下文和页面 DOM。HTML 与 CSS 由 Blitz 和 Stylo 的组件处理，普通 JavaScript 与 WebAssembly 则在 Worker 的 V8 Isolate 中运行。

一个值得注意的例外是 eval()。出于安全原因，Cloudflare Workers 不原生允许动态代码求值。因此，Kitesurf 使用 Rust 编写的 ECMAScript 引擎 Boa，在 Worker 环境中执行这些调用。这很务实，却也制造了棘手的兼容边界：一部分代码直接在 V8 中运行，动态生成的代码则经过第二套 JavaScript 引擎，行为可能不同。

PageRenderer Worker 为截图和 PDF 生成像素。它接收场景描述、进行光栅化并返回结果。Renderer 不保存重要的页面状态。如果它挂起或崩溃，Engine 可以丢弃它并重新启动渲染任务。

只有一个组件可以访问网络

从安全角度看，SandboxOutbound Worker 尤其值得关注。只有该组件可以从互联网获取资源。它执行 CORS 规则、按页面隔离管理 Cookie、过滤响应并补充类似浏览器的 Header。PageScript 和 Engine 因此不会直接获得不受限制的网络访问。

这与许多自建代理方案形成了有意义的区别。浏览器代理打开的不只是人类已经信任的网站，它还会跟随搜索结果、陌生文档甚至被操纵 Prompt 中的链接。每次页面访问都是不可信输入。因此，网络边界不是优化，而是安全模型的一部分。

Kitesurf 还尽量采用无状态组件。没有状态的组件出错时可以终止并重启。对于短时且波动剧烈的代理工作负载，这种模型很适合 Worker 平台。

Cloudflare 声称 Kitesurf 已通过超过 215,000 项 Web Platform Tests，并在 DOM、HTML、CSS、SVG、Selection 与 XHR 方面具有良好覆盖。这个数字听起来令人印象深刻，但单独看并不能代表成熟度。WPT 文件包含许多子测试，而 Cloudflare 既未公布完整通过率，也未公开 Kitesurf 的代码和确切测试配置。因此，它无法与 Obscura 的公开 WPT Runner 或 Chromium 兼容性进行可靠比较。发布时 Kitesurf 仅开发了十二周，仍是 Beta。

更高效，但并不更快

Cloudflare 自己的测量显示了真正的经济吸引力。在由 14 个 URL 组成、运行五次的语料集上，Cloudflare 称 Kitesurf 截图所需 CPU 比热 Chromium Pool 少 3.1 倍，内存少 4.7 倍。HTML 提取则分别少 3.8 倍 CPU 和 7 倍内存。

但延迟更差。截图中位耗时长 1.8 倍，HTML 提取长 1.7 倍。因此，Kitesurf 主要节省的是每项任务的基础设施成本，并不会自动赢得单页速度竞赛。

这些数字有参考价值，却不是独立基准测试。语料集、环境和对照方案都由 Cloudflare 选择，热 Chromium Pool 也只是多种运行方式之一。测试说明该架构具有潜力，但尚不能证明 Kitesurf 在任意真实代理工作负载中都更便宜或更可靠。

Obscura：独立的 Rust 浏览器

Obscura 以本地或自托管开源项目的形式追求相同的基本理念。代码采用 Apache 2.0 许可证。当时最新的 0.2.1 版本发布于 2026 年 8 月 23 日，由多个 Rust Crate 构成，覆盖 CLI、CDP、浏览器逻辑、JavaScript、DOM、网络、MCP 和渲染。

V8、自有 DOM 与 CPU 渲染

Obscura 通过 deno_core 嵌入 V8。浏览器 API 由一层大型 JavaScript Bootstrap 和 Rust 操作提供，DOM 是自有实现。布局和渲染则使用 Taffy、自身浏览器逻辑以及基于 CPU 的 Paint 路径。

Obscura 同样支持 CDP，并带有 MCP Server。代理可以打开页面、获取 DOM Snapshot、点击、填写表单、执行 JavaScript、生成截图或 PDF。实际优势在于控制权：引擎可以在本地、容器或自有基础设施中运行，不以 Cloudflare 账户为技术前提。

代价是自行运维。架构文档称，同一进程内的页面共享一个 V8 Isolate，JavaScript 工作由全局锁串行执行。Watchdog 和硬 Deadline 用于防止某个页面永久阻塞进程。安全文档仍正确指出了边界：这些机制不能替代操作系统级隔离。大规模处理恶意页面时，应将 Obscura 放入网络受限的容器或虚拟机中。

这不是一个小提示。Rust 无法防住 V8、本地依赖或 FFI 边界中的所有漏洞。执行任意互联网 JavaScript 的进程始终是高风险服务。

Stealth 模式不只是 User-Agent

Obscura 最有意思的差异是可选的 Stealth Build。它用基于 BoringSSL 的 wreq 替换普通 reqwest 传输，并模拟类似 Chrome 的 TLS Handshake，包括 ClientHello、ALPN 和 Cipher Suite 顺序。这一点很重要，因为机器人系统不只检查可见的 User-Agent，还会比较 HTTP Header、TLS Fingerprint 与 JavaScript 属性是否讲述同一个浏览器故事。

在 JavaScript 侧，Obscura 也努力保持故事一致。代码模拟 navigator.userAgentData、平台值、屏幕、GPU、Canvas、Audio、电池等 Fingerprint 表面。navigator.webdriver 保持不可见，内部 Obscura 属性不会被枚举，原生函数通过 Function.prototype.toString() 查看时应呈现为真正的浏览器函数。

event.isTrusted 也被区别处理。页面代码通过 new Event() 创建的事件仍是不可信的，而来自 CDP 路径的输入可标记为浏览器生成事件。统一返回 true 很容易被识别，也会错误模拟正常 Web 行为。

Stealth 路径覆盖导航、子资源、fetch() 和 XHR。这至关重要。如果只有主文档采用类似 Chrome 的 TLS Fingerprint，后续 API 请求却突然像 Rust 库，就会形成机器人系统正在寻找的不一致。

Obscura 还会拦截已知跟踪与 Fingerprinting 端点，并可按 Session 改变浏览器特征。不过文档自己也警告，不匹配的组合会带来问题。IP 区域、时区、Geolocation、JavaScript Profile 与 TLS Fingerprint 必须一致。轮换不是隐身斗篷。一个 Exit IP 不断切换设备身份，反而可能更加显眼。

Obscura 真的更擅长绕过机器人识别吗？

与 Kitesurf 直接比较，Obscura 显然更重视 Anti-Detection，这在代码和文档中都看得出来。但这并不代表它能可靠绕过现代机器人防御。

项目对自身目标的界定相当坦率。Stealth 模式旨在通过简单的 TLS Fingerprint 或 User-Agent 检查。文档明确不支持：

• 交互式 Cloudflare Challenge
• DataDome 与 Akamai Bot Manager 的主动 Challenge
• CAPTCHA
• 基于 IP 的 Rate Limit

因此，常听到的“Obscura 能绕过机器人识别”只在很窄的意义上成立。它努力让自己看起来不像普通 Headless Client，却不是通用 Challenge Bypass。

现代机器人系统还会评估浏览器 Fingerprint 之外的因素，包括 IP Reputation、ASN、请求频率、导航、鼠标与键盘模式、Cookie 历史、账户行为以及众多 Session 之间的关系。如果一千个请求以同样节奏来自同一数据中心，完美模拟的 navigator 属性也帮助不大。

公开的 Obscura 基准测试也应谨慎解读。独立仓库包含针对 WPT、障碍测试、真实网站、可靠性与 Stealth 一致性的可复现脚本，这比单纯的营销表格更好。但 Stealth Suite 在本地运行，主要检查项目自行定义的 Fingerprint 是否内部一致，并不能证明大型商业机器人系统会把该流量视为人类。

项目迭代速度也是一个因素。发布说明显示，Obscura 0.2.0 到 0.2.1 之间两周多一点就有 122 次 Commit。这体现了积极开发，也说明接口仍在剧烈变化。对于年轻的浏览器引擎，不能因一次成功 Demo 就直接推断它已适合生产。

Cloudflare 不想要不可见的机器人

Kitesurf 的情况根本不同。Cloudflare Browser Run 会为出站请求附加不可配置的 Header，并加入 Web Bot Auth Signature，使目标服务器可以用密码学方式验证请求来自 Cloudflare 的浏览器基础设施。

Cloudflare 的 FAQ 表述非常明确：Browser Run 请求始终会被 Cloudflare 识别为机器人流量，网站运营者决定允许还是阻止。若要自动测试自己的 Zone，可以通过 WAF Rule 有针对性地放行这类流量。

Kitesurf 是 Browser Run 内的一项选项。因此，把缺少伪装仅视为技术落后是错误的。透明的机器人身份属于产品模型。Cloudflare 同时运营浏览器自动化平台，以及供网站运营者识别和控制机器人的安全产品。若自家浏览器有意规避这些控制，就会直接损害该模型。

Cloudflare 也坦言，Kitesurf 目前无法用真实 TLS Fingerprint 完成 Bot Challenge Handshake。对于此类网站，公司仍建议使用 Browser Run 中基于 Chromium 的标准方案。但即使是这种 Chromium 流量，也会因 Cloudflare Header 和 Signature 而被识别为自动化。

这种决定值得肯定。网站运营者获得的是可验证身份，而不是任意伪造的 User-Agent。合法机器人可以分别被允许、测量或限流，滥用也能关联到具体供应商与基础设施。

但它同样值得批评。代表用户读取公开网站的个人代理，在技术上会被归类得更像商业爬虫，而不是用户自己的浏览器。网站运营者获得了一个简单开关来阻止 Cloudflare 代理。即使用户只想自动完成自己的研究，也无法退回到普通、看似由人操作的 Session。

Cloudflare 为什么仍要自建

Cloudflare 写道，Obscura 提供了最初的灵感，并首先在 AI 代理帮助下被移植到 Workers。Kitesurf 就诞生于这个几乎无法运行的 Proof of Concept。这是明确署名，而不是暗中声称创意来自自己的实验室。

然而，无论 Kitesurf 文章还是 Browser Run 文档，都没有说 Cloudflare 因 Obscura 的 Stealth 功能而放弃它。更明显的理由有好几个。

Obscura 被设计成自托管进程，Kitesurf 则是分布式 Worker 应用。Cloudflare 希望使用 Isolate、Service Binding、Worker RPC、自有 Outbound Sandbox 和现有 Browser Run API。仅仅在某处启动一个 Rust Binary 无法满足这些要求。

Cloudflare 还需要引擎的生命周期、资源使用、Telemetry 与故障行为适配自家平台。错误 RPC 后可丢弃的无状态 Renderer，与共享 V8 Isolate 和全局锁的进程，是不同的运行架构。

最后，Kitesurf 是一个产品组件。CDP 让客户端较为可移植，但服务本身仍与 Browser Run 和 Cloudflare Workers 紧密绑定。Cloudflare 承诺未来将 Kitesurf 开源，并允许客户部署到自己的 Cloudflare 账户中。不过代码目前尚未公开。Obscura 的架构、安全边界与实现现在即可审查；Kitesurf 目前只能依据已发布设计、文档和可观察行为来评价。

批评在这里完全合理。Cloudflare 受益于开放创意和现有项目，自己的后续开发却暂时保持封闭。Apache 2.0 允许这样做，Cloudflare 也明确提到了 Obscura，法律上没有问题。但对于承诺很快开放源码的公司，最终重要的是发布出来的代码，而不是“soon”这个词。

两款浏览器，两种控制模型

关键差异不能归结为速度。

因此，Kitesurf 并不只是更好的 Obscura，它解决的是另一类运维问题。Cloudflare 想在自己的平台上安全、低成本地执行大量短时浏览器任务。Obscura 则想提供独立浏览器引擎，让运营者自行控制，并在需要时降低可识别性。

尚未解决的安全问题位于浏览器之上

两个项目都投入大量精力隔离网页。这是必要的，却没有解决 AI 浏览器最重要的风险：网页本身可以操纵代理。

DOM 中的 Prompt Injection 文本无需触发 V8 Sandbox Escape。只要模型把它当成指令，泄露内部数据、打开错误链接或调用高权限工具，就足够了。网络隔离保护浏览器基础设施，却不会自动保护用户的意图。

因此，可用于生产的代理浏览器还需要额外控制：

• 为互不相关的任务使用独立浏览器上下文
• 每个 Session 只提供最少 Secret 和短期 Token
• 在登录、购买、上传或更改数据前进行明确授权
• 在页面 JavaScript 之外设置 Domain 与 Egress 规则
• 用日志关联模型决策、浏览器操作与结果
• 为异常导航与下载提供安全终止路径
• 防止页面内容变成系统指令

Cloudflare 把 Prompt Injection 和 Tool Safety 列为优先事项，但 Kitesurf 文章主要描述浏览器隔离。Obscura 提供浏览器工具，却不负责上层代理的授权。使用任何一个项目，都必须自行填补这一缺口。

哪种模型适合哪类用途？

对于在自有、已授权页面上生成截图、提取 HTML 或文档，Kitesurf 很有吸引力。Worker 架构减少运维工作，透明的机器人身份在自有环境中也不是障碍。运营者可专门放行 Browser Run，并获得可追溯来源。

对于本地研究、内部自动化或数据控制要求严格的环境，Obscura 更具吸引力。但引擎必须放入边界清晰的 Runtime 中。容器或 VM、受限 Egress、隔离凭据以及启用 --obey-robots 不应是事后补丁。

对于长期认证 Session、媒体、WebGL 或具有复杂机器人防御的网站，真正的 Chromium 浏览器往往仍是更现实的选择。Cloudflare 对 Kitesurf 也明确这样表示。更小的浏览器并不自动意味着更高兼容性。

Stealth 功能只应在合法、获授权的测试或隐私导向自动化中使用。技术上能够访问一个网站，既不能回答法律问题，也不能说明其规则、Rate Limit 和资源是否得到了尊重。

我的结论

Obscura 显然让 Cloudflare 看到，代理式浏览器不一定非得是 Chromium。Kitesurf 接受这一基本思路，并将其构建为 Worker 原生架构，提供有说服力的隔离、更低资源消耗和直接的 Browser Run 集成。

在机器人识别方面，Obscura 的确更激进。其 Stealth 模式对 TLS、HTTP 和 JavaScript 表面的模拟远比 Kitesurf 有针对性。但称其“更擅长绕过”仍然过度。证据只表明它能更好地伪装以应对简单 Fingerprint 检查，而项目自己也否认能绕过现代交互式 Challenge。

Cloudflare 的克制不只是技术不成熟。Browser Run 就是要能被识别为机器人。不可移除的 Header 与 Web Bot Auth 把透明性变成产品特性。这符合一家同时销售 Bot Management 的公司的利益，却也使 Kitesurf 无法成为代表用户行动的独立浏览器。

因此，最有力的批评不是 Cloudflare 简单复制了 Obscura。两者的架构和运维模型差异太大，Cloudflare 也公开承认了灵感来源。

更有力的批评是：Cloudflare 构建了一款 AI 浏览器，它的身份、运行时、分发方式与访问权都完全契合 Cloudflare 的控制模型。这对运营者可能非常合理，但对于开放、以用户为中心的代理式 Web，它只是一种答案。

Kitesurf 是否真的会开放、发布的代码是否完整，以及浏览器能否脱离 Cloudflare 平台有意义地运行，仍有待观察。在此之前，Obscura 是更开放的实验，Kitesurf 则是集成度更高的产品。

下次再见，
Joe