Cloudflare 推出 Kitesurf，挑战 Chromium 作为 AI Agent 默认选择的地位
Cloudflare 在历经 12 周开发冲刺后推出了 Kitesurf，为 AI Agent 提供了一款不再将 Chromium 视为网页自动化默认选项的浏览器。techcrunch cloudflare 的这篇报道之所以重要，是因为 Kitesurf 改变的是 Agent 底层基础设施，而不只是指挥它们的模型。
Cloudflare 表示，在某些常见任务中，Kitesurf 的 CPU 和内存消耗比 Chromium 低三至七倍。这些任务包括加载网页、提取 HTML、创建截图以及生成 PDF。这一比较仍属于公司基准测试，但其所指向的问题揭示了当今 Agent 技术栈中代价高昂的不匹配。
开发者通常会在为人类视觉体验设计的浏览器之上部署 AI 模型。这类浏览器需要支持标签页、扩展、媒体、无障碍功能、图形以及数不清的兼容性行为。Kitesurf 去除了其中大部分负担，同时也接受了一个现实：某些页面的外观或行为不会与 Chrome 完全一致。
结果是一款范围更窄、主张更鲜明的产品。需要结构化内容或临时页面会话的 Agent，并不总是需要一套完整的桌面浏览器。不过，要完成购买、访问受保护网站或管理复杂应用的 Agent，很可能仍然需要。
TechCrunch 的 Cloudflare 报道称发生了什么变化
Kitesurf 将浏览器从常驻应用转变为 Agent 基础设施中的临时单元。
根据原始的Agent 浏览器报道，Cloudflare 将 Kitesurf 打造成面向软件 Agent 而非人类用户的云托管浏览器。它通过 Cloudflare Workers——该公司的无服务器计算平台——运行，并通过 Browser Run 以 Beta 版形式提供。
无头浏览器可在不显示传统桌面窗口的情况下渲染和操作网页。现有的无头 Chromium 部署仍然包含大量面向人类浏览器所需的机制。Kitesurf 则从另一项假设出发：软件将直接消费其输出结果。
这一假设改变了浏览器必须优先满足的需求。Agent 需要加载 URL、执行 JavaScript、检查文档对象模型、跟随链接、填写字段并捕获输出。它也需要隔离能力，因为访问的每个页面都不受信任。
Kitesurf 被设计为仅在任务持续期间存在。Cloudflare 将其描述为短暂且无状态，这意味着一个新实例可为单个任务启动，并在完成后消失。与一批长期运行的浏览器进程相比，这种模式更适合并行工作负载的突发增长。
Cloudflare 通过模块化组件构建 Kitesurf，而非整体采用 Chromium。据报道，其组件包括 Blitz 渲染引擎、Mozilla 的 Stylo CSS 系统以及 Boa JavaScript 引擎。Rust 构成了实现的大部分基础。
Blitz 负责网页布局和渲染，而无需携带主流浏览器中捆绑的所有子系统。Stylo 解析并应用 CSS，Boa 则执行 JavaScript。将这些项目组合起来，使 Cloudflare 获得了一条可针对 Agent 工作负载逐个优化组件的浏览器处理管线。
Cloudflare 表示，Kitesurf 已通过超过 215,000 项 Web 平台测试。这个数字表明其具备实质性的兼容性，但并不能证明它在开放网络上与 Chromium 完全对等。Web 平台测试涵盖的是已定义的行为，而生产环境的网站往往依赖于不寻常的浏览器细节。
目前的 Beta 版与 Cloudflare 基于 Chromium 的 Browser Run 服务并行提供，而非取代后者。这一安排很重要：开发者可以为兼容的工作选择轻量级引擎，并在保真度至关重要时保留完整浏览器。
Cloudflare 还在测试期间免费提供该 Beta 版，无需额外付费。这一决定应能鼓励试用，但并未透露未来的商业条款。在计算任何长期节省之前，开发者仍需要运营数据。
因此，眼下的变化本质上是架构性的。浏览器自动化不再必然意味着默认启动 Chrome。Kitesurf 为开发者提供了第二条执行路径，围绕机器消费和短生命周期任务进行了优化。
Chromium 承载着许多 Agent 从不会使用的功能
Kitesurf 对“每个自动化请求都值得为最高浏览器兼容性付出计算成本”这一假设提出了挑战。
Chromium 仍然是最稳妥的通用选择，因为它代表了网站已经在测试的行为。Playwright、Puppeteer 以及许多 Agent 框架也围绕 Chrome DevTools Protocol（CDP）构建。CDP 是用于检查和控制 Chromium 浏览器的底层接口。
这种兼容性有其代价。一个 Chromium 实例支持的远不只是文档提取。它还处理高级图形、媒体播放、扩展、浏览器配置文件、开发者工具、无障碍功能以及广泛的安全攻击面。
这些能力对人类用户和复杂自动化仍然很有价值。但当 Agent 仅需获取产品页面中的文本与链接时，它们就成了额外负担。当一项服务启动数百个浏览器、各自只生成一张截图时，同样的不匹配也会出现。
Cloudflare 表示，其更轻量的设计可在选定任务中将 CPU 和内存消耗降低三至七倍。由于浏览器工作负载差异很大，这一区间较宽。静态文章、JavaScript 仪表板和 WebGL 应用对资源的需求截然不同。
更低的内存占用可能意味着，同一套基础设施可承载更多并发会话。更低的 CPU 使用量也可能减少反复渲染页面的成本。当 Agent 在给出一个答案前需要探索大量网页时，这些优势便会变得显著。
这种经济性还延伸到浏览器进程之外。浏览器结果往往会成为模型输入，未经筛选的页面内容会消耗 Token。以 Agent 为先的浏览器可以返回更干净的文档表示，从而减少传入模型上下文窗口的材料。
上下文窗口是模型在一次请求中可处理的文本和结构化信息量。用隐藏导航、样式细节和无关页面元素填满它会增加成本，也可能让模型偏离任务重点。
这也是为什么 Kitesurf 最有说服力的用例并不是炫目的桌面演示，而是提取内容、总结页面、生成截图，以及在大量 URL 集合上进行兼容性检查等重复性操作。在这些环境中，微小的节省会迅速累积。
Cloudflare 此前已通过 Browser Run 朝这一方向推进。其 2026 年 4 月的Browser Run 更新新增了直接 CDP 访问、会话录制、人工介入以及对 120 个并发浏览器的支持。该公司将这些功能定位为围绕大规模操作 Chrome 的 Agent 而设计。
Kitesurf 则更进一步，提出 Chrome 是否必须存在的问题。Browser Run 提供管理层，而 Kitesurf 则在其下提供另一种引擎。因此，这次发布是一项基础设施决策，而非新的用户界面。
Chromium 并非在所有场景中都突然变得低效。它的重量来自数十年的兼容性、安全工作和用户需求。Kitesurf 的效率部分来自于缩小自身承担的责任，因此两者不应被视为完全相同的浏览器来评判。
真正受到压力的，是那些为简单、可预测任务部署 Chromium 的开发者。他们现在需要证明，这一选择相较更小的运行时为何合理。如果 Kitesurf 被证明可靠，完整浏览器将成为升级路径，而非基线选择。
Kitesurf 如何以浏览器保真度换取 Agent 效率
Kitesurf 之所以更轻，是因为它接受了 AI Agent 往往需要的是有用的结构，而不是对人类而言像素级完美的体验。
主流浏览器必须以足够一致的方式显示网页，供人们阅读、观看、购物、交流和工作。细微的布局错误就可能遮挡按钮或让用户困惑。因此，浏览器厂商维护着复杂引擎，以覆盖极为广泛的标准和硬件组合。
AI Agent 通常通过网页的 DOM、无障碍树、截图或一组提取出的操作来评估页面。DOM 是网页元素的结构化表示。即使细微的视觉样式有所不同，它仍能暴露按钮及其标签。
Kitesurf 利用了这种差异。Cloudflare 表示，只要底层内容仍可访问，Agent 就可以容忍一些 CSS 差异和不完美的渲染。这种容忍度使公司能够省去那些对人类比对机器更重要的系统。
这一架构也适配 Cloudflare Workers。Workers 使用 V8 isolates，即彼此隔离的轻量级 JavaScript 执行环境。Cloudflare 曾表示，其基于 isolate 的 Agent 沙箱启动速度远快于传统虚拟机或容器。
其isolate 沙箱设计展现了更广泛的平台战略。Cloudflare 希望让 Agent 代码、浏览器执行、存储、编排和网络能力能够彼此靠近地运行。Kitesurf 填补了该技术栈中浏览器形态的空缺。
每个临时 Kitesurf 实例都可处理不受信任的页面，而不会让该页面直接访问 Agent 的主运行时。隔离并不会让恶意内容变得无害，但它限制了被攻破的页面进程能够触及的范围。在任务完成后丢弃实例，也可以减少持久状态。
这种差异很重要，因为 Web Agent 面临的不只是传统浏览器漏洞。它们还会遭遇间接提示注入，即页面上的文本试图覆盖 Agent 的指令。隐藏信息可能要求 Agent 泄露数据、访问攻击者的链接，或滥用已认证会话。
浏览器隔离无法判断页面指令是否合法。这项判断属于 Agent、其权限系统以及外围应用的职责。不过，隔离浏览器执行可以防止某一类入侵扩散到宿主环境。
开发者还必须控制哪些数据流出沙箱。如果浏览器将每条页面指令都未经筛选地返回给模型，单靠隔离提供的保护就很有限。Agent 仍需要来源规则、操作审批、凭据边界和输出验证。
Kitesurf 的兼容性目标带来了另一项取舍。模块化引擎可以快速改进，但现代 Web 对 Chromium 行为的依赖并不亚于对书面标准的依赖。网站有时依赖未公开的怪异行为、浏览器指纹，或小型引擎尚未实现的 API。
Cloudflare 的测试数量提供了有用的基线。通过超过 215,000 项测试表明，Kitesurf 并非简单的 HTML 解析器。但庞大的测试总数无法预测某个特定的银行门户、商业结账流程或内部仪表板是否能正常运行。
真正有意义的衡量标准将是任务完成情况。开发者应比较 Kitesurf 与 Chromium 是否产生相同的成功结果，而非截图是否每个像素都完全一致。答案将因工作负载而异。
这提示了一种实用的路由模型。Agent 可以先使用 Kitesurf 获取内容并进行常规交互。当页面需要不受支持的功能、精确的视觉渲染或人工接手时，它可以切换至 Browser Run 的 Chromium 引擎。
此类路由会增加复杂性，因为团队必须对故障进行分类，并在不同引擎之间保留状态。不过，它也避免了让每个页面都承担完整 Chromium 的成本。Cloudflare 的价值取决于能否让这种升级机制足够可靠，以满足生产环境使用需求。
浏览器效率主张仍需独立验证
Cloudflare 的基准测试令人期待，但其范围仍然过于有限，尚不足以宣称 Kitesurf 是 Chromium 的通用替代方案。
三至七倍的效率区间来自 Cloudflare，而非独立实验室。公开说明尚未提供足够细节，无法复现每一项比较。硬件、页面选择、并发量、缓存状态和测量边界都会影响结果。
浏览器可能因为支持的功能较少而占用更少内存。这是合理的工程取舍，但也改变了比较基础。在将这一醒目的比率套用到运营预算之前，开发者需要知道哪些工作负载能够成功完成。
最有说服力的基准测试应比较单位计算资源完成的任务数量。它们应涵盖内容提取、截图、重度依赖 JavaScript 的网站、表单工作流、需认证的应用，以及故障恢复。原始进程内存只能反映运营图景的一部分。
错误率同样重要，因为重试会消耗资源。一个需要重复执行数次任务的轻量级引擎，可能会抹去其初始优势。回退到 Chromium 还会增加延迟，并要求应用能够识别故障由 Kitesurf 引起。
渲染质量需要针对具体工作负载进行评估。在文章提取过程中，细微的 CSS 差异可能无关紧要；但当智能体通过截图定位控件或解读可视化图表时，这些差异可能至关重要。
JavaScript 兼容性也面临类似挑战。现代网站会加载大型应用程序包，并假设浏览器支持超出核心 ECMAScript 范围的 API。Boa 可以执行 JavaScript，但能否成功执行还取决于周边的文档、网络、存储和事件 API。
开源问题也引发了审视。Kitesurf 使用开源组件，但参与发布讨论的开发者指出，Cloudflare 在推出时并未发布完整的浏览器代码。组件透明并不自动意味着集成后的服务可以复现。
这一缺口会影响信任与调试。团队可以检查 Blitz、Stylo 或 Boa，但若没有集成代码，就无法完整追踪 Cloudflare 特有的行为。Cloudflare 可以通过发布补丁、实现细节或清晰的上游贡献计划来回应这一担忧。
反机器人保护是另一项有意设定的边界。Kitesurf 并非用于规避 CAPTCHA、浏览器指纹检查或网站访问政策。轻量级服务器端浏览器可能比传统的人类会话看起来更自动化，而不是更少。
这一限制让 Cloudflare 的立场呈现出一种表面上的张力。该公司既销售帮助网站所有者限制不受欢迎自动化流量的工具，也通过 Kitesurf 帮助开发者运行 Web 智能体。只有在 Cloudflare 保留网站所有者控制权的前提下，这两种角色才能兼容。
Browser Run 已经为这种平衡提供了一种模式。Cloudflare 表示，其爬虫遵守 robots.txt、使用明确的身份标识，并且不会绕过反机器人保护。Kitesurf 的采用情况将部分取决于开发者能否识别获授权的智能体，同时又不为滥用性抓取提供便利。
研究也表明，简单化的检测并不足够。一篇关于智能体指纹识别的 2026 年论文发现，行为和浏览器信号能够区分智能体，而现有防御措施可能漏掉部分自动化系统。检测仍是执行环境与网站政策之间不断演变的博弈。
提示注入带来了另一项尚未解决的风险。沙箱可以保护基础设施，但已认证的智能体仍可能通过合法的浏览器操作服从恶意页面内容。更安全的浏览器并不一定意味着更安全的智能体。
开发者应将 Kitesurf 视为一个带有可验证假设的 beta 执行引擎。他们应记录完成率、回退频率、资源使用情况和安全事件。单一的平均效率数字无法替代这些工作负载层面的结果。
Cloudflare 正在构建智能体 Web 的两端
与其说 Kitesurf 是一次试图击败 Chrome 的独立尝试，不如说它是 Cloudflare 智能体平台的一部分，因此更具合理性。
Cloudflare 已经运营在网站与访客之间。其网络负责交付页面、过滤机器人、运行代码并应用安全规则。AI 智能体带来了一类新的访客：它们有时应获得访问权限，有时又与滥用行为无异。
Kitesurf 为这些访客提供了运行时环境。当需要完整兼容性时，Browser Run 提供托管的 Chromium 会话。Workers 和 Dynamic Workers 提供轻量级计算，而 Durable Objects 则为长时间运行的智能体维护状态。
该公司的 Agents SDK 增加了通信、调度、存储和模型集成功能。这些服务共同让开发者能够在一个平台上托管智能体的控制循环和浏览器活动。因此，浏览器的发布强化了更广泛的基础设施组合。
Cloudflare 与其说是在与 Chrome 本身竞争，不如说是在与浏览器自动化基础设施竞争。开发者可以自行托管 Playwright、维护容器并管理浏览器版本；也可以使用通过 API 提供 Chromium 会话的托管浏览器服务商。
自行托管提供了控制权，但也带来运营工作。浏览器进程会崩溃、消耗内存、需要打补丁，并使扩展变得复杂。托管服务能够减轻一部分负担，但也引入了供应商依赖和数据处理方面的问题。
Kitesurf 通过在托管服务中提供非 Chromium 路径，改变了这种比较。如果其资源特征得以保持，竞争对手将面临压力：要么引入轻量级提取引擎，要么将简单任务从完整浏览器实例中分流出去。
云服务提供商也有理由作出回应。AI 智能体平台日益需要代码执行、浏览器访问、状态、身份和可观测性。Cloudflare 的网络位置使其能够整合这些要素，而无需从集中式模型托管业务起步。
2026 年 5 月的一篇平台分析将 Cloudflare 的智能体产品描述为一个涵盖计算、编排、记忆、浏览和商业的分层技术栈。Kitesurf 缩减了其中成本最高的一个层级。
这种集成可以使开发者受益，因为网络、计算和浏览器调用都保留在同一环境中。但它也可能加深锁定效应。围绕 Cloudflare 特定绑定编写的智能体，可能比控制标准本地 Chromium 进程的智能体更难迁移。
协议兼容性可以降低这种风险。CDP、Playwright、Puppeteer 和 Model Context Protocol 提供了熟悉的接口。不过，较小的引擎即便接受相关接口，也无法保证每条命令的行为都与 Chrome 完全一致。
因此，Cloudflare 必须平衡两项承诺。Kitesurf 需要具备足够的标准兼容性，才能融入现有的智能体框架；同时，它也需要保持足够的架构自由度，才能明显比 Chromium 更轻量。
该公司不同寻常的定位也带来了治理问题。Cloudflare 可以观察大量 Web 流量、识别机器人、托管智能体，并提供其浏览器。客户将希望对遥测数据、内容访问、凭证和执行机制设定清晰边界。
对开发者而言，架构文档与基准测试图表同等重要。团队需要知道浏览器数据在哪里运行、保留多久，以及 Cloudflare 会保存哪些日志。企业采用将取决于这些问题的答案。
对网站所有者而言，身份比浏览器品牌更重要。他们需要一种方式来区分获授权的购物助手与收集受保护内容的提取机器人。Cloudflare 的长期机会在于调解这种区分。
因此，Kitesurf 一部分是浏览器，一部分是基础设施押注，也一部分是围绕自动化访问展开的协商。其效率吸引了关注，但其战略价值在于，在可执行规则下将智能体连接到 Cloudflare 的网络。
三个信号将显示 Kitesurf 能否走出 Beta 阶段
只有当真实工作负载能够保持其效率优势，同时又不带来不可接受的兼容性或安全成本，Kitesurf 才能成功。
第一个信号是独立的性能数据。开发者需要公开的比较结果，其中包括任务完成情况、CPU 时间、峰值内存、延迟、重试次数和回退至 Chromium 的比率。静态页面和复杂应用程序中的结果将揭示 Kitesurf 的实际运行范围。
在内容提取、截图和普通导航中保持稳定优势，将支持 Cloudflare 的核心主张。如果这种优势在重试后消失，其说服力就会减弱。公开基准测试代码会使这些结论更值得信赖。
第二个信号是兼容性的增长。Cloudflare 报告称，已有超过 215,000 项 Web 平台测试通过，这为 Kitesurf 提供了起点。接下来关键在于，后续版本能否填补生产环境智能体所遇到的差距。
开发者应关注认证、存储、现代 JavaScript 应用程序、浏览器自动化命令和视觉交互相关的支持情况。他们还应关注 Cloudflare 建议切换至 Chromium 的频率。
即使 Kitesurf 永远无法实现完全对等，清晰的回退指引也能增强产品竞争力。轻量级浏览器不需要处理每一个页面；它需要能够迅速识别不受支持的情况，并在不破坏状态的前提下转交任务。
第三个信号是 Cloudflare 针对可信智能体流量的政策。Kitesurf 不应成为绕过网站控制的工具，但获授权的智能体需要一条可靠的 Web 通路。签名身份、明确权限和由网站声明的工具，都有助于建立这条路径。
WebMCP 是一种可能的桥梁。它允许网站向智能体暴露结构化操作，减少对脆弱的视觉导航的依赖。智能体可以调用声明的搜索或预订功能，而不是猜测应点击哪个页面元素。
这种做法也降低了像素级完美渲染的重要性。如果网站提供机器可读的工具，Kitesurf 就可以专注于编排、内容和安全。对于仅提供人类界面的页面，Chromium 仍然可用。
评估 beta 版本的开发者应从范围受限的任务开始。合适的候选任务包括公开页面提取、受控截图、文档转换，以及监控自己拥有的网站。这些工作负载更容易衡量故障并验证输出。
测试期间应保留 Chromium。双引擎设计能够提供基线，并防止 Kitesurf 的局限性演变为无声的数据错误。日志应显示每项任务由哪个引擎完成，以及发生任何回退的原因。
安全测试同样值得同等重视。团队应让测试智能体面对敌意页面指令、可疑重定向、超大文档和意外下载。他们应确认浏览器隔离、应用权限和凭证控制能够协同运行。
知识工作者将间接感受到 Kitesurf 的影响。研究智能体可能更快地收集来源，或在相同的基础设施预算内处理更多页面。用户仍然需要证据链，因为更低的浏览成本并不会让提取的信息变得准确。
构建研究工作流的团队可以将源材料保存在可搜索的工程知识库中。这种做法让浏览器输出在智能体完成任务后仍可审计。
techcrunch cloudflare 的报道最终指向一种务实的转变。AI 智能体并不总是需要人们日常使用的浏览器。它们需要的是能够安全、可验证地完成既定任务的最小化浏览器。
Kitesurf 现在必须证明这一边界究竟在哪里。开发者应测试一项可重复的工作流，将其与 Chromium 对比，并公开失败案例与节省的成本。这些结果将决定以智能体为先的浏览器能否成为一个持久的基础设施类别。
