做过 Agent 抓网页的人都有这个体验：本地起 headless Chrome，依赖装一堆，版本跟着系统走，跑在服务器上还要防反爬。这些事跟业务逻辑毫无关系，但不做又不行，浏览器是 Agent 观察网页世界的唯一眼睛。
cloudflare-browser 是 Cloudflare 官方发布在 Smithery 上的 skill，思路很直接：浏览器我提供，你只要会发 CDP 命令。它通过 Cloudflare Browser Rendering 服务的 WebSocket 端点，控制跑在云端边缘网络上的无头 Chrome，本地一行 node 命令就能截图、录视频、执行 JS。
这个 skill 值得看，是因为它出现的时机很巧。Browser Rendering 在 2026 年 4 月开放了 CDP 直连，把最底层的控制权交了出来，等于告诉所有人：任何语言、任何环境，只要会 WebSocket 就能用上云端浏览器。这个 skill 就是官方对这种用法的封装示范。
这篇会带你走完上手链路：先把环境备好，再跑通截图和多页视频，最后拆解 CDP 连接模式的设计取舍。读完你会清楚它解决了什么，没解决什么，以及你的项目适不适合直接抄它的模式。
把 CDP 直接暴露出来，是 Cloudflare 一个明确的战略动作。之前用 Browser Rendering 得写 Worker 代码、走它封装的 API，现在任何会用 WebSocket 的脚本都能连上来，Puppeteer、Playwright 改一行配置就能把浏览器切到云端。门槛降下来的同时，生态里现成的 CDP 工具全都能复用。
环境准备
用这个 skill 需要三样东西：Cloudflare 账号、开通 Browser Rendering 服务（现在改名叫 Browser Run）、一个部署好的 worker 端点。worker 负责把外部的 WebSocket 请求转给浏览器池，同时用 secret 做鉴权，是整条链路的入口。
skill 要求先设置 CDP_SECRET 环境变量，这个值要和 worker 配置里的 secret 对应。从配置结构看，鉴权走的是 URL query 参数，连接时把 secret 拼在 WebSocket 地址后面带上。
"browser": {
"profiles": {
"cloudflare": {
"cdpUrl": "https://your-worker.workers.dev/cdp?secret=..."
}
}
}
这段配置说明它服务的是 openclaw 生态：openclaw 的浏览器 profile 指向 worker 端点，skill 里的脚本从 profile 拿连接信息。不用 openclaw 的话，自己把 cdpUrl 填进脚本同样能跑，因为底层就是一条裸 WebSocket。
环境就绪后跑第一条截图命令，能出图就说明链路通了。这一步最容易卡在 secret 不匹配，症状是连接直接挂住不返回，跟网络问题很难区分，排障成本不低。
操作流程
截图是最简单的入口。一条 node 命令，传 URL 和输出路径，其余交给脚本：
node /path/to/skills/cloudflare-browser/scripts/screenshot.js https://example.com output.png
这背后是标准的 CDP 流程：先导航，等页面渲染稳定后截帧，再把 base64 存成本地文件。skill 把这几步压成了脚本，但文档里完整保留了连接模式和命令速查，摆明了是让你看懂之后写自己的自动化。
CDP 连接的关键在事件监听。worker 在 WebSocket 建连后会自动创建 page target，脚本必须监听 Target.targetCreated 才能拿到 targetId，这个 id 是后续所有命令的前提：
const ws = new WebSocket(WS_URL);
let targetId = null;
ws.on('message', (data) => {
const msg = JSON.parse(data.toString());
if (msg.method === 'Target.targetCreated' && msg.params?.targetInfo?.type === 'page') {
targetId = msg.params.targetInfo.targetId;
}
});
拿到 targetId 后就是标准的 CDP 命令了。下面四个命令覆盖了大部分自动化需求，消息交互可以看这张时序图。
| CDP 命令 | 用途 |
|---|---|
| Page.navigate | 跳转到指定 URL |
| Page.captureScreenshot | 截取 PNG/JPEG 图像 |
| Runtime.evaluate | 在页面上下文执行 JavaScript |
| Emulation.setDeviceMetricsOverride | 设置视口宽高和设备缩放比 |
多页视频是另一个内置能力。screenshot.js 处理单页，video.js 接收逗号分隔的 URL 列表，逐页截帧后用 ffmpeg 按帧率拼接成 mp4，适合做产品演示视频或者页面巡检记录。
node /path/to/skills/cloudflare-browser/scripts/video.js "https://site1.com,https://site2.com" output.mp4
ffmpeg 拼接这一步没有封装进脚本，需要自己装 ffmpeg 并处理帧序列。从文档给的命令看，帧文件要按四位数字编号，配合 framerate 参数控制成片节奏，流水线里这个细节容易忽略，帧率太低成片会明显卡顿。
文档还保留了不少常用模式：滚动页面用 Runtime.evaluate 执行 window.scrollBy，等渲染用定时器，视口设置用设备指标覆盖。这些片段直接抄进自己的脚本就能组合出更复杂的自动化。
关键设计
这个 skill 最值得琢磨的设计是选 CDP 而不是 Puppeteer 或 Playwright 这类高层 API。高层封装确实省事，但也挡住了控制力；CDP 是最底层协议，Chrome DevTools 底下跑的就是它，控制力度最大，原始消息还能直接喂给模型，做 token 更高效的浏览器控制。
从文档来看，鉴权设计刻意保持简单：secret 走 query 参数，worker 端比对。好处是零额外依赖，一个环境变量就搞定；坏处是 secret 会出现在 URL 里，经过的日志和代理都会留下痕迹，生产环境要防泄露。
跟 skill 里的 secret 方案形成对比的是官方 CDP 端点本身，它用 API Token 走 Authorization header 鉴权。两套体系并存，一套面向原生用户，一套面向 openclaw 这类自建 worker，说明 Cloudflare 想让不同体量的开发者都能接进来，而不是逼所有人都走同一条路。
连接即建页的设计很省事。常规自动化要先 launch 再 newPage，这里 WebSocket 一握手页面就绪，少了一步状态管理。代价是竞态问题：命令发得比 targetCreated 事件快就会找不到目标，文档明确要求监听事件加超时兜底。
把视频能力做进 skill 也算一个信号。截图是单点操作，视频需要串起导航、截帧、编码三步，这暗示 Cloudflare 对它的定位不只是截图服务，而是完整的浏览器会话平台，对应它 4 月中旬发布的 Live View 和会话录制能力。
使用场景
自动化截图是最直接的场景。产品更新后批量生成页面截图、定时抓取报表快照、给社交分享生成预览图，这些任务不需要完整浏览器环境，一个云端 CDP 连接就够，用完即走不占资源。
动态页面抓取是另一个高价值场景。SPA 站点的内容靠 JS 渲染，curl 抓不到，必须等浏览器执行完脚本再取 HTML。配合 Runtime.evaluate 可以直接拿到渲染后的 DOM 和结构化数据，省掉自己写渲染器的麻烦。
还有个容易被忽略的用途：给 JS 重的页面做预渲染。搜索引擎和 AI 爬虫对纯客户端渲染的内容不友好，用云端浏览器先渲染一遍再吐 HTML，站点兼容性立刻提升，Cloudflare 官方也专门出过这个方向的教程，说明这是它想推的主流用法之一。
多页视频适合做演示和巡检。把核心页面按顺序录成视频，比一张张截图更容易传达产品全貌，也方便非技术人员快速了解页面状态，Cloudflare 的全球边缘网络保证页面就近打开，加载速度有保障。
端到端渲染测试也能用上。设置不同视口尺寸验证响应式布局，逐页截帧做视觉回归，浏览器跑在云端意味着不用自己维护测试集群，高峰期和低谷期按需伸缩。
洞察与反思
这个 skill 有个出乎意料的地方：克制。两个脚本，一个截图一个视频，外加连接模式和命令速查，没有堆任何多余功能。从设计意图看，它更像是官方给出的最小可用范例，告诉开发者 CDP 直连的正确姿势，而不是功能齐全的自动化框架。
对比自建 Puppeteer 集群或者 Browserless 这类服务，云端 CDP 的优势是没有浏览器版本维护、没有资源闲置、按用量付费。代价是调试链路变长，出错时只能看到协议层信息，看不到浏览器进程内部状态，排查全靠日志和超时时间。
文档里列的三个排障项暴露了这类方案的共性坑：targetCreated 竞态、worker 冷启动超时、secret 不匹配导致连接挂起。冷启动那条尤其值得注意，文档建议把超时放宽到 30 到 60 秒，说明无服务器浏览器有固有延迟，不适合对首包延迟敏感的场景。
适用边界也要说清楚。这个 skill 面向脚本级自动化，不是交互式调试工具；如果你想边看浏览器边操作，或者需要人类介入处理登录验证码，那是 Browser Run 的 Live View 和 Human in the Loop 的范畴，skill 本身没有覆盖。
把它放到 Smithery 这类 skill 市场分发，本身也是个信号。Cloudflare 显然把浏览器即服务当成 AI Agent 的基础设施来推，skill 市场就是触达开发者的渠道。25 次安装只是起步，CDP 开放之后，这类官方封装会越来越多，先看懂一个，后面的都是变体。
资源地址
| 资源 | 链接 |
|---|---|
| Smithery 页面 | https://smithery.ai/skills/cloudflare/cloudflare-browser |
| Cloudflare Browser Run 文档 | https://developers.cloudflare.com/browser-run |
| CDP 端点发布日志 | https://developers.cloudflare.com/changelog/post/2026-04-10-browser-rendering-cdp-endpoint |
总结
cloudflare-browser 的价值不在功能多，而在它示范了 Agent 上浏览器的最短路径：一条 WebSocket，几个 CDP 命令，剩下交给 Cloudflare。对想给 Agent 加网页能力的开发者，这是目前成本最低的起点。
如果你要做的是批量截图、动态页面抓取、轻量巡检，直接抄它的模式就能用；如果需求已经膨胀到复杂交互和人工介入，建议去看 Browser Run 的会话级能力，那才是重活该去的地方。
这个 skill 在 Smithery 上的安装量目前只有 25 次，用的人还不多，但方向很明确。浏览器正在成为 Agent 的标配外设，谁先把控制链路做顺，谁就占住位置，官方给的这条路径值得先趟一遍。