给 Agent 配一个浏览器：Cloudflare Browser Run 全面解析

互联网是为人类建的Agent 要用它Agent 需要和网页交互。填表单、提取数据、截图、导航——这些是 Agent 执行任务的基本动作。问题是整个互联网的设计预设是有一个人坐在屏幕前操作。Agent 不是人它没有鼠标没有视网膜它需要一个专门为它准备好的浏览器基础设施。这次Cloudflare 把 Browser Rendering 正式更名为Browser Run同步发布了一批面向 Agent 场景设计的新功能。名字的变化本身就是一个信号这个产品的定位从渲染工具演进成了给 Agent 用的完整浏览器基础设施。新发布的功能清单Live View实时看到 Agent 在做什么包括页面、DOM、控制台和网络请求Human in the LoopAgent 卡住时人工接管处理完成后交还控制权CDP 直连端点Chrome DevTools Protocol 直接暴露Agent 框架和现有脚本可以直接连接MCP 客户端支持Claude Desktop、Cursor、OpenCode 等编码 Agent 可以把 Browser Run 作为远端浏览器WebMCP 支持网站主动声明对 Agent 可用的工具让 Agent 导航更可靠Session Recordings录下每一个会话出问题时有完整回放并发上限提升从 30 提升到 120提升 4 倍以下逐一展开。一、启动一个浏览器Agent 首先需要一个可以按需开启的浏览器。Browser Run 在 Cloudflare 全球网络上提供无头 Chrome 实例不需要管理任何基础设施也不需要维护 Chrome 版本。浏览器会话就近用户所在位置启动延迟低按需扩缩用完即释放。配合 Agents SDK可以构建长时间运行的 Agent——浏览网页、记住上下文、自主行动不需要自己搭一套浏览器管理系统。二、控制浏览器四种方式覆盖不同场景有了浏览器Agent 需要能控制它。Browser Run 提供了从高层到低层的多种方式。CDP 直连端点最大控制权Chrome DevTools ProtocolCDP是浏览器自动化的底层协议。你在 Chrome 里打开开发者工具时背后运行的就是 CDP。Puppeteer、Playwright以及绝大多数 Agent 框架都建立在它之上。以前Browser Run 也是通过 CDP 工作的但开发者只能通过 Puppeteer 或 Playwright 这样的上层封装来使用。现在Cloudflare 把 CDP 端点直接暴露出来。对 Agent 来说这个改变有三点实质意义第一最大控制权。直接访问 CDP 可以使用 Puppeteer 或 Playwright 覆盖不到的浏览器能力比如 JavaScript 调试。第二框架原生兼容。Agent 框架已经在内部使用 CDP可以直接连接不需要额外适配层。第三Token 效率更高。绕过上层库把原始 CDP 消息直接传给模型不需要为封装层的语义转换付出额外 Token 成本。迁移成本极低。如果已有连接到自托管 Chrome 的 CDP 脚本只需修改一行配置// 之前连接到本地自托管 Chromeconstbrowserawaitpuppeteer.connect({browserWSEndpoint:ws://localhost:9222/devtools/browser});// 之后连接到 Browser Runconstbrowserawaitpuppeteer.connect({browserWSEndpoint:wss://api.cloudflare.com/client/v4/accounts/ACCOUNT_ID/browser-rendering/devtools/browser,headers:{Authorization:Bearer API_TOKEN}});一行改动不再需要维护自己的 Chrome 基础设施。同时CDP 端点不依赖 Cloudflare Worker可以从任何语言、任何环境直接调用。MCP 客户端支持让编码 Agent 直接用上浏览器因为 Browser Run 现在暴露了 CDP 端点Claude Desktop、Cursor、Codex、OpenCode 这类编码 Agent 可以把 Browser Run 作为它们的远端浏览器。具体实现是通过 Chrome DevTools 团队发布的chrome-devtools-mcp包——这是一个 MCP Server把完整的 Chrome DevTools 能力可靠的自动化、深度调试、性能分析以 MCP 协议的形式暴露给 AI 编码助手。配置方式非常简单以 Claude Desktop 为例{mcpServers:{browser-rendering:{command:npx,args:[-y,chrome-devtools-mcplatest,--wsEndpointwss://api.cloudflare.com/client/v4/accounts/ACCOUNT_ID/browser-rendering/devtools/browser?keep_alive600000,--wsHeaders{\Authorization\:\Bearer API_TOKEN\}]}}}加上这段配置Claude Desktop 就有了一个完整的 Chrome 浏览器可以驱动。WebMCP让网站主动对 Agent 开放传统的网页 UI 是为人类设计的。Agent 浏览网页时往往需要循环截图 → 分析 → 点击的过程速度慢、可靠性低一旦 UI 发生变化整条流程就可能失效。WebMCP 是 Google Chrome 团队推出的新 Web 标准在 Chromium 146 中落地。它允许网站主动声明哪些操作可以被 Agent 发现并调用。两个 API 实现这件事navigator.modelContext网站用这个接口注册自己的工具告诉 Agent我支持哪些操作navigator.modelContextTestingAgent 用这个接口在页面上发现和调用工具举个具体场景今天一个 Agent 访问机票预订网站需要分析页面结构、找到搜索表单、填写字段整个过程依赖对 UI 的视觉理解。有了 WebMCP网站可以声明我有一个search_flights工具接受出发地、目的地和日期三个参数。Agent 直接调用这个工具跳过所有的 UI 分析过程更快、更可靠而且不受 UI 改版影响。工具是在页面上按需发现的而不是预加载的。这对于覆盖长尾网站来说非常重要——无法事先为每个可能访问的网站都预配一个 MCP Server页面级发现机制解决了这个问题。Browser Run 提供了一个运行 Chrome beta 的实验性浏览器池可以在稳定版 Chrome 之前测试 WebMCP 等新特性npmi-gwranglerlatest wrangler browser create--lab--keepAlive300现有方式继续可用Puppeteer、Playwright、Stagehand 这些已有的全浏览器自动化方式在 Browser Run 上完全不受影响。对于截图、PDF 生成、Markdown 提取这类简单任务Quick Action 端点依然是最快的选择。/crawl端点是最近新增的支持单次 API 调用爬取整个网站给一个起始 URL自动发现和抓取页面返回 HTML、Markdown 或结构化 JSON 格式支持控制爬取深度和范围可以跳过未更新的页面可以指定包含或排除的路径。值得一提的是爬虫合规性的处理/crawl端点是一个经过签名认证的合规爬虫遵守robots.txt和 AI Crawl Control 规则不会绕过 Cloudflare 的机器人防护或 CAPTCHA。网站所有者对自己内容的可访问性有完整控制权爬虫尊重这些设置。三、可观测性知道 Agent 在做什么Cloudflare 从用户反馈里总结出一个高频问题自动化流程失败了但完全不知道为什么。这次专门针对可观测性做了三方面改进。Live View实时目击Live View 让你看到 Agent 正在操作的浏览器页面实时、同步包括页面本身、DOM 结构、Console 输出和网络请求。当自动化出了问题——预期的按钮不在、页面需要登录、出现了 CAPTCHA——你可以立刻发现而不是等任务失败之后再来排查。访问方式有两种通过代码获取session_id和devtoolsFrontendURL在 Chrome 里打开或者在 Cloudflare Dashboard 的 Browser Run 部分进入 Live Sessions 标签点击任意活跃会话查看。Session Recordings事后回放不可能实时盯着每一个会话。Session Recordings 解决了这个问题——它把 DOM 变化、鼠标键盘事件和页面导航记录为结构化 JSON会话结束后可以完整回放。启动浏览器时传入recording: true即可开启。会话关闭后可以在 Dashboard 的 Runs 标签里找到录像也可以通过 API 获取用 rrweb-player 在本地回放。接下来还会支持在回放时间轴的任意位置检查 DOM 状态和 Console 输出不只是看录像还能在任意时间点打断点查看状态。Dashboard 重设计旧版 Dashboard 只显示浏览器会话的日志截图、PDF、Markdown 提取、Crawl 这些请求都不可见出了问题完全没有线索。新版 Runs 标签把所有类型的请求统一展示可以按端点类型过滤每条记录都有目标 URL、执行状态和耗时。四、人工干预Agent 卡住时不必重来Agent 不是万能的。登录页面、双因素认证、意料之外的弹窗——这些场景今天的 Agent 大多数处理不了。如果碰到这类情况只能整个流程重启实用性会大打折扣。Human in the Loop提供了另一种处理方式当自动化遇到障碍人工接管当前的活跃会话处理 Agent 无法处理的部分然后让自动化继续。现在的实现方式是通过 Live View URL 直接进入活跃会话操作页面。接下来要做的是更完整的交接流程Agent 能够主动发出我需要帮助的信号触发通知提醒人工介入人工处理完成后把控制权明确交回给 Agent整条流程有完整的状态传递。五、规模并发翻了 4 倍并发浏览器上限从 30 提升到120Quick Actions 的请求速率提升到10 次/秒。Browser Run 全球维护一个预热的浏览器实例池会话打开时立刻可用没有冷启动等待时间。有更高并发需求的团队可以直接申请提升限额。路线图原文在路线图部分列出了四项接下来要做的事情Human in the Loop 主动交接流程现在是人看到问题后主动进入 Live View 接管接下来是 Agent 主动发出求助信号触发通知完成后明确交还控制权整条交接有完整的系统支撑。Session Recordings DOM 检查现在可以在时间轴上前后拖动回放会话接下来可以在任意时间点检查 DOM 状态和 Console 输出把录像从视频升级成可交互的调试快照。Traces 和浏览器日志不需要在代码里插桩Console 日志、网络请求、时序数据自动可查。出了问题直接看 Trace知道哪里断的。Workers Binding 直接调用截图、PDF、Markdown 提取现在需要通过 REST API 调用需要 API Token。接下来这些功能将直接作为 Workers Binding 提供env.BROWSER.screenshot()直接用不需要 API Token和调用其他 Workers 服务没有区别。小结这次发布的核心是把 Browser Run 从一个渲染工具升级成一个完整的 Agent 浏览器基础设施。五个维度的改进——开启浏览器、控制浏览器、可观测性、人工干预、规模——基本覆盖了一个 Agent 在使用浏览器时会遇到的全部问题。有几个判断值得单独提出WebMCP 的方向比功能本身更重要。今天 WebMCP 支持的网站还很少但它代表的是互联网基础设施向对 Agent 友好演进的方向。网站开始主动声明自己对 Agent 可用的工具意味着 Agent 和 Web 之间的交互模式会发生根本性的改变——从Agent 猜测如何操作 UI到网站告诉 Agent 能做什么。CDP 直连端点打通了现有生态。大量现有的浏览器自动化脚本和 Agent 框架都在用 CDP只改一行 WebSocket 地址就能从自托管 Chrome 迁到 Browser Run迁移成本几乎为零。Human in the Loop 改变了自动化的可靠性预期。以前自动化不能处理就失败是默认预设Human in the Loop 让自动化处理不了的交给人人处理完继续自动化成为一个可以设计进产品里的正常流程。Browser Run 在 Free 和 Paid 套餐下均可使用今天发布的所有功能立即可用。参考链接原文https://blog.cloudflare.com/browser-run-for-ai-agents/Browser Run 文档https://developers.cloudflare.com/browser-rendering/CDP 端点文档https://developers.cloudflare.com/browser-rendering/cdp/WebMCP 文档https://developers.cloudflare.com/browser-run/features/webmcp/Live View 文档https://developers.cloudflare.com/browser-run/features/live-view/Human in the Loop 文档https://developers.cloudflare.com/browser-run/features/human-in-the-loop//crawl 端点文档https://developers.cloudflare.com/browser-rendering/rest-api/crawl-endpoint/