浏览器给AI打工：Cloudflare这次改名藏着什么算盘

「Browser Rendering」这个名字，Cloudflare自己都觉得别扭。今天他们干脆改叫「Browser Run」——一个更直白的信号：这东西不是给人看的，是给AI用的。

改名背后是一整套产品重构。从30个并发浏览器拉到120个，新增实时画面、人工介入、协议开放、会话录制——每一项都在回答同一个问题：当AI代理大规模上网，浏览器该长什么样？

实时画面：别让AI在黑箱里瞎转

AI代理上网最怕什么？你不知道它在干嘛。点了按钮没反应，是页面没加载完，还是元素定位错了？卡在登录页，是验证码挡住了，还是密码填错了？

Browser Run的Live View解决的就是这个。运营人员能实时看到代理看到的画面，像看监控一样盯进度。出问题立刻知道，不用等跑完才发现中间某步已经崩了。

这个功能听起来简单，但省的是排查时间。代理任务一跑几十分钟，最后报错，你回去翻日志猜原因——这种体验谁碰过谁懂。

人工介入：承认AI会翻车，比假装不会更诚实

Cloudflare没装。他们在文档里直接写：代理会遇到登录页、意外弹窗、各种边缘情况，然后卡住。

Human in the Loop就是给这种情况开的后门。代理搞不定的时候，把控制权交给人，处理完再交回去。不是失败终止，是暂停续传。

这个设计暴露了代理落地的真实痛点：完全无人值守还不现实。但「人工兜底」不等于「人工全程陪跑」，而是让代理在确定能搞定的环节自治，在搞不定的环节求救。分工明确，成本可控。

开放协议：为什么非要支持Chrome开发者工具协议

Browser Run现在直接暴露CDP（Chrome开发者工具协议）端点。这是浏览器自动化的底层协议，市面上大部分代理工具都基于它构建。

支持CDP意味着两件事：第一，现有脚本不用改就能跑在Cloudflare上；第二，代理对浏览器的控制粒度拉到最大——不是封装好的API能比的。

Cloudflare还补了MCP客户端支持。Claude Desktop、Cursor、OpenCode这些AI编程工具，现在能把Browser Run当远程浏览器用。写代码的代理和上网的代理，终于能无缝对接。

更野心的是WebMCP。Cloudflare的判断是：未来代理数量会超过人类用户。WebMCP让网站主动声明「我能提供什么操作」，代理来发现和调用——不是硬爬页面猜结构，是标准化的服务发现。

会话录制：事后复盘比实时盯更累人

Session Recordings把每次浏览全程录下来，包括DOM变化、用户交互、页面跳转。Debug的时候有完整现场，不用靠猜。

这个功能配合Live View用：实时盯紧关键任务，事后翻录像查偶发问题。120个并发浏览器跑起来，全靠日志定位故障不现实，有录像才能还原现场。

并发翻倍：从30到120的数字背后

并发数从30提到120，不是简单的扩容。Cloudflare的全球网络让浏览器会话开在离用户近的节点，按需伸缩。代理任务的特点是突发——可能凌晨批量跑几百个查询，白天闲置。传统方案要么备着一堆机器空转，要么临时扩容来不及。

Browser Run的卖法是「无基础设施」：不用管Chrome版本，不用维护实例池，按用量付。这对中小团队吸引力很明显——自己搭Selenium Grid或Playwright集群，运维成本远高于使用成本。

代理上网，浏览器只是起点

Cloudflare把Browser Run和自家的Agents SDK打包推。SDK负责长周期运行、记忆管理、自主决策，Browser Run负责上网执行。这个组合意图很明显：代理不是「能上网的脚本」，是「能记住上下文、自主规划、持续运行」的数字员工。

改名、扩并发、开协议、加人工介入——这些动作指向同一个判断：代理上网的需求已经从「能跑就行」进化到「跑得稳、看得见、管得了」。Cloudflare在抢这个基础设施的位置，而且动作很快。

如果你正在做代理相关的产品，建议现在就去开Browser Run的Live View试试。不是因为它完美，而是因为你在找的坑，别人可能已经踩过并录下来了。