Cloudflare Kitesurf 免费吗？价格、额度与适用场景全解析

Cloudflare Kitesurf 免费吗？测试期内答案是肯定的，但 Workers Free 真正可用的额度只有每个账户每天 10 分钟浏览器时长、3 个并发 Browser Session，以及每 20 秒新建 1 个会话。这足够做一次有边界的试点，却不能证明整套智能体技术栈都不花钱。

Cloudflare Kitesurf 免费吗？

只要浏览器仍处于测试期，Kitesurf 就可以免费使用。Cloudflare 在 2026 年 9 月 28 日的更新中明确说明了这一点，同时也给出了一个不能忽略的前提：实际使用受每个账户的 Browser Run 限额约束。

Kitesurf 是 Cloudflare 面向 AI 智能体打造的无状态浏览器引擎。它运行在 Workers 上，舍弃了一部分面向真人用户的浏览器功能，换来更轻量的智能体运行环境。目前 Kitesurf 引擎不单独收费，但外围的 Browser Run 仍按其规则计量。

把当前的 Browser Run 限额与 Browser Run 价格放在一起看，最值得关注的是以下 4 条边界：

所以，“免费”是一个有用的产品结论，却不是完整的预算结论。它只说明 Cloudflare 在测试期如何为 Kitesurf 收费，并不能回答你的工作流是否装得进账户限额、是否需要 Workers Paid，或智能体所用模型会产生多少费用。

本文的价格与限额已于 2026 年 9 月 29 日对照 Cloudflare 的公开页面核验。由于本次评测没有可用的已认证 Browser Run 任务，文中不会虚构控制台账单、耗时结果或工具调用成功率。

2026 年 9 月 28 日，Kitesurf 到底更新了什么？

9 月的更新把 Kitesurf 接入了智能体开发者已经在用的接口，因此更适合扩大试点范围。8 月的首次发布带来了浏览器本身，这次更新则补齐了围绕浏览器的实用入口。

首先，Kitesurf 现在支持 WebMCP。网站可以通过这套浏览器 API，以结构化输入暴露具名工具；智能体不必再从像素里猜按钮，而是能直接调用网站提供的 searchFlights() 一类函数。Cloudflare 的 WebMCP 文档显示，Kitesurf 可通过 Chrome DevTools Protocol 列出并执行这些工具，该协议通常简称 CDP。

其次，Kitesurf 已获得完整的 Browser Run API 支持，可通过 CDP、Playwright、Puppeteer 或 MCP 选择。Quick Actions 是 Cloudflare 面向截图、HTML、PDF 等常见输出提供的单请求接口；现在也能在 Worker 中通过 env.BROWSER.quickAction() 选择 Kitesurf。

第三，渲染器可通过 Kitty 图形协议在兼容终端里运行；终端不支持 Kitty 时，则退回纯 ANSI 文本模式。这样无需另开桌面浏览器，也能从智能体浏览器的视角观察页面。它只是便于检查的工具，并不是新的生产计费档位。

Cloudflare 还在这份 9 月更新中表示，Kitesurf 目前已通过超过 730,000 个 Web Platform Test 子测试，比首次发布时多出逾 500,000 个。这说明兼容性有了显著提升，但不代表任意客户门户都能正确渲染。因此，试点仍然应该限定目标网站清单。

Kitesurf 测试期额度：每天能否跑完 10 个任务？

只有当每个完整任务平均不超过 60 秒浏览器时长时，每天 10 个任务才装得进免费额度。Workers Free 额度是 10 分钟，也就是 600 秒；除以 10 个任务后，每个任务的上限正好是 60 秒。

实用公式是 daily task ceiling = floor(600 / measured browser seconds per task)。不要拿应用日志里的墙钟时间代替浏览器时长。Cloudflare 的价格文档说明，Quick Actions 会在 X-Browser-Ms-Used 响应头中返回浏览器耗时。应当用计划正式运行的同一类任务和目标网站，记录这个值。

时长并非唯一限制。限额页面显示，一个 Free 账户可同时运行 3 个 Browser Session，每 20 秒新建 1 个会话，并且每 10 秒发起 1 个 Quick Actions 请求。默认空闲超时为 60 秒。Cloudflare 在受支持的会话集成中允许更长的 keep_alive 窗口，但 WebMCP 页面指出，Kitesurf 的 Chrome DevTools MCP 配置不接受 keep_alive。

同一份限额页面还为 /crawl 列出了另一组 Free 边界：每天最多 5 个抓取任务，每个任务不超过 100 个页面。如果研究型智能体把一个问题拆成多次抓取，可能尚未用完 10 分钟浏览器时长，就先耗尽了任务次数。

是否及时关闭会话也会影响容量。Cloudflare 警告，未关闭的会话在超时前会一直消耗浏览器时长。主动关闭会记录 NormalClosure，因空闲超时则记录 BrowserIdle。应把 browser.close() 放进 finally 块，并检查关闭原因，不要想当然地认为代码已经完成清理。

判断标准很直接：若实测中位数不超过 60 秒，且速率限制不会让任务排队，那么 10 个任务的试点就能装进额度。否则，先缩小页面集合或任务范围，再考虑为低效循环付费扩容。

Cloudflare Kitesurf 价格要拆成 3 条成本线

Kitesurf、Workers 账户、Browser Run 用量和推理模型是不同的服务，所以价格不可能只用一个数字概括。把它们统称为“免费智能体”，只会掩盖最先发生变化的那笔账单。

对于短任务，当前的纯浏览器超额费用并不高。按已公布的 Browser Run 费率计算，用完 Workers Paid 所含的 10 小时后，一个 60 秒任务按每小时 $0.09 计费就是 $0.0015；这还不包括并发、Workers 计算、模型用量或上游 SaaS 费用。如果任务时长均匀，这 10 小时可容纳 600 个时长为 1 分钟的浏览器任务。

不能把这笔算术题理解为对 Kitesurf 测试期结束后价格的承诺。Cloudflare 尚未在更新公告、Kitesurf 文档、Browser Run 价格页或 Workers 价格页公布 Kitesurf 专属的后续费率。每月最低 $5 购买的是 Workers 账户档位，并不能锁定 Kitesurf 未来的价格。

对采购方而言，清晰的预算表应该把浏览器时长、会话并发、Workers、模型，以及智能体访问的任何付费系统分别列项。免费的浏览器引擎，完全可能运行在一套付费工作流里。

Kitesurf Browser Run 对开发、运维和采购分别意味着什么？

这个平台已经适合边界明确的无状态任务，但还不能充当通用的 Chromium 替代品。不同角色需要据此采取不同做法。

开发者：用能完成任务的最小接口

如果只需要截图、页面内容、PDF 或结构化提取，开发者应从 Quick Action 开始。在端点加入 browser=kitesurf，测量返回的浏览器时长；只有任务必须跨多个操作导航或保持状态时，才升级为完整会话。

如果兼容网站恰好暴露了智能体所需的操作，WebMCP 很有吸引力：它用具名工具替代脆弱的视觉操作循环。但网站的具体实现、权限边界和返回结果，仍然需要验证。

面向客户的会话在走向生产环境时，还应把引擎选择与 Browser Run 的控制措施配套起来。现有的获批主机与只读客户审查指南说明了浏览器选择本身无法覆盖的目标地址边界。

运维人员：把正常任务与失败任务分开测量

运维人员应按任务类型记录浏览器毫秒数、关闭原因、请求结果和模型用量。一次成功提取与一个超时页面并非同一种工作负载；把两者混在一起求平均，只会让人看不出真正需要修复的是浏览器、网站还是智能体循环。

任务失败后，应先保存证据，再发起下一次运行。Browser Run 的检查流程可以展示已记录会话的控制台、网络活动和最终页面状态。失败任务重跑前的调试指南解释了哪些情况下，这些证据比立即重跑更有价值。

采购方：先验证兼容性，再购买容量

采购方不应只因 Free 计数器触顶就立刻升级。第一步是确认 Kitesurf 能正确渲染目标网站并完成任务，然后再判断瓶颈究竟在每日浏览器时长、请求速率、并发还是模型。

Cloudflare 当前的产品文档已经划清了引擎边界。兼容的一次性渲染、数据提取和突发式无状态智能体任务，适合选择 Kitesurf；需要视频、WebGL、带真实 TLS 指纹的反机器人挑战握手，或需要持久状态的长时间认证会话，则应选择 Chromium。

无需大规模铺开也能做出判断：选择 1 个有代表性的任务、1 组目标网站、1 份实测浏览器时长分布，以及 1 个明确的回退方案。如果回退频繁触发，更小的引擎并没有真正节省运维成本。

哪些人现在就该行动，哪些人应该等待？

如果你负责的是围绕公开页面或低风险页面构建的客服、研究或 QA 工作流，现在就可以行动。合适的试点包括截取帮助中心页面、提取发布说明、检查渲染后的组件，或在兼容网站上调用 WebMCP 搜索工具。这些任务耗时短、可审计，也容易与已知结果比较。

如果工作流依赖持久登录状态、视频、WebGL、反机器人挑战兼容性，或需要无人值守地确认敏感 WebMCP 操作，建议等待。Kitesurf 会话不会出现在 wrangler browser list 中，也没有 live view。Cloudflare 表示，因此 Kitesurf 智能体会话无法完成需要暂停并等待人工确认的工具；这种交互必须使用手动体验场。

如果要做延伸到测试期之后的预算承诺，也应等待。当前浏览器免费，但并没有已公布的测试期后 Kitesurf 价格可用于长期合同或固定利润率的客户报价。

如果现有 Chromium Browser Run 工作流已经达到成本与可靠性目标，基本不受影响。9 月的发布只是多提供了一个可评估的后端，并不要求把运行稳定的生产浏览器迁走。

“免费测试版”被夸大了什么？

用“免费”概括整个智能体，实际上让这个词承担了过多含义。免费只覆盖 Kitesurf 的测试期使用资格，不包括模型、运维人员时间、目标 SaaS，也不代表未来的商业价格。

WebMCP 同样没有消除浏览器故障。Cloudflare 列出了 Kitesurf 当前实现中的 4 个关键缺口：没有 WebMCP 工具权限策略或来源过滤；通过 CDP 不会暴露 iframe 或弹窗中的工具；Kitesurf 会话没有 live view；需要人工参与的工具也无法在智能体侧确认。只有页面暴露了正确的函数并妥善保护它时，具名函数才会比点击像素更可靠。

终端渲染器提供的是可观察性，而不是部署方案。它能帮助开发者检查 Kitesurf 看到的内容，却不会改变浏览器分钟数、并发、模型成本或网站兼容性。

性能数据也需要克制解读。在 Cloudflare 自己的中位数基准测试中，测试覆盖一个包含 14 个 URL 的语料集，并对 Quick Action 运行 5 次。截图任务里，Kitesurf 使用 380 ms CPU，而热池 Chromium 为 1,173 ms；内存用量分别为 57.8 MiB 和 271.0 MiB。但 Kitesurf 的墙钟时间反而更慢：1,148 ms 对 637 ms。更低的资源消耗有利于规模化，却不等于每一次请求都会更快完成。

最后，超过 730,000 个通过的子测试，证明的是开发进展迅速，而不是已经覆盖整个 Web。用自己的目标网站建立兼容性矩阵，依然比全局测试数量更有参考价值。

本周行动：只跑一个边界明确的试点

正确的下一步是受控的账户测试，而不是立即迁移架构。本文没有执行已认证的 Browser Run 请求，所以下面的流程是一套可复现的试点方案，并非声称来自第一手基准测试。

1. 1

   检查公开入口

   打开 Cloudflare Radar 上的 Kitesurf 公共体验场。在 DevTools 中进入 Application > WebMCP，记录 Cloudflare 表示 Radar 已暴露的工具，包括 navigate-to 和 set-location。这些工具出现在 Radar，并不证明你的目标网站也提供了同类工具。

2. 2

   运行一个代表性任务

   使用现有测试账户，执行一次内容获取或截图请求。Cloudflare 文档中的截图请求格式如下：

   curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/screenshot?browser=kitesurf' \
     -H 'Authorization: Bearer <API_TOKEN>' \
     -H 'Content-Type: application/json' \
     -d '{"url":"https://example.com"}' \
     --output screenshot.png

   先选用非敏感目标。确认输出正确，再着手优化速度。

3. 3

   记录每一条成本边界

   记录 Workers 套餐、Quick Action 的 X-Browser-Ms-Used、Browser Run 用量、会话关闭原因和模型用量。使用 Browser Session 时，应主动关闭并确认记录为 NormalClosure，而不是 BrowserIdle。

4. 4

   计算免费额度

   用 600 除以每个成功任务实测的浏览器秒数，再向下取整。每天 10 个任务要求实测平均值不超过 60 秒。把模型账单单列一栏，然后判断试点是能装进 Free、需要进一步收紧任务，还是值得升级 Workers Paid。

只需这一次运行，就能补齐真正缺失的证据：真实业务会反复执行的任务，其兼容性、浏览器时长、关闭行为和模型成本究竟如何。

如果你希望把下一次智能体基础设施的价格或限额变化，直接转化为可执行的运营决策，欢迎订阅邮件通讯。