P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。

前言

做AI Agent的朋友最近肯定常听见browser use这个词。说白了就是让AI像真人一样点开浏览器，点点按钮填填表，听起来挺高科技，实际上原理说穿了一点都不神秘。

今天咱们就掰开揉碎了唠，顺便吐槽吐槽这里面的坑和有意思的地方。

一、AI操控浏览器，其实就两大门派

别看各家产品吹得天花乱坠，本质上AI操作浏览器就两种路子，没有第三种。

1. 截图+坐标：纯靠眼神儿办事

这个路子特别好理解：给页面拍张照发给大模型，大模型看完说“点那个坐标(x,y)的地方”，然后自动化工具照着点就行。

听起来很直观对吧？缺点也很明显。首先得用多模态模型，纯文本模型干不了这活，成本直接上去了。

但有些场景还真就得用它，比如canvas做的游戏、图表，还有纯渲染的页面，连DOM都没有，文本树直接空了，不靠眼神真不行。像Anthropic的Computer Use、OpenAI的Operator，走的就是这个纯视觉路线。

2. 文本树+编号：靠暗号精准定位

这就是现在主流方案了，也是咱们今天重点唠的。简单说就是把网页转成一棵带编号的文本树，AI选编号，工具按编号找真实元素操作。

不用视觉能力，纯文本模型也能玩，成本低还稳定，属于性价比拉满的方案。现在Gemini CLI、Claude Code这些主流工具，默认都是这个路子，视觉只当补充。

二、好好的webFetch不用，为啥非要搞browser use？

很多人会问，Agent不是都有webFetch吗？抓网页内容不就完了，搞这么复杂干啥？

这话对也不对。webFetch本质上就是发个HTTP请求，属于“一次性拿完就走”，跟你直接curl一个网址没啥本质区别。碰到复杂场景直接歇菜。

1. 需要登录的页面，它进不去

webFetch没cookie没session，就像你没带工牌想进公司大楼，保安直接给你拦在门外。后台页面、会员内容，它啥也拿不着。

2. SPA应用，它拿到的是空壳

现在前端基本都是Vue、React写的SPA，页面初始HTML就一个空div，内容全靠JS渲染出来。webFetch拿完一看，好家伙就一个空盒子，里面啥货都没有，跟你点外卖收到个空餐盒似的，气不气人。

3. 多步交互，它根本玩不转

查个机票得选出发地、目的地、日期，再点搜索；翻个帖子得翻页、点详情。这些操作都得保持页面状态，webFetch抓一次就完事了，根本走不完流程。

而browser use呢？它直接启动一个真实的浏览器，跟你手动开Chrome一模一样，该登录登录，该点按钮点按钮，该渲染渲染，完全模拟人的操作。

当然也不是啥场景都要用它。就看个静态文章，webFetch完全够用，又快又省钱。非得用浏览器去读静态文章，就像你开卡车去买瓶矿泉水，纯属大材小用费油钱。

而且不用你自己判断该用哪个，大模型自己会看工具描述选。当然这也看模型聪不聪明，笨模型可能放着近路不走绕远路，那也没办法。

三、核心揭秘：文本树到底是怎么来的？

很多人好奇，网页那么多代码、样式、图片，怎么就变成一段简洁的文本树了？其实这东西不是新技术，浏览器早就有了。

1. 源头：浏览器自带的“无障碍树”

每个浏览器内核里都维护着一棵无障碍树，是给屏幕阅读器、语音控制这些辅助功能用的，都存在十几年了，比AI Agent资格老多了。

它根据DOM、CSS样式、ARIA属性生成，只保留语义信息：这个元素是按钮还是输入框，叫什么名字，能不能点，状态是啥。

说白了就是浏览器早就把网页“翻译”成了程序能读懂的结构，以前是给残障人士辅助工具用的，现在被AI拿来直接用了，属于经典的“技术跨界再就业”。

比如一个<button>提交</button>，在无障碍树里就是：角色是按钮，名字叫“提交”，可以交互。不管你CSS写得花里胡哨，它的语义都是按钮。

2. 怎么把这棵树读出来？

读这棵树得用浏览器自动化工具，现在主流用的是Playwright，微软开源的东西，靠谱得很。前端同学写E2E测试肯定熟，现在它成了AI操控浏览器的底层发动机。

当然LLM不能直接调用Playwright，中间得有个翻译官，就是@playwright/mcp这个包，把Playwright的能力包装成MCP工具，LLM就能直接调用了。

整个流程其实很简单：

• LLM说“给我拍个页面快照”
• MCP服务端喊Playwright干活
• Playwright通过CDP协议跟浏览器要完整无障碍树
• 浏览器返回一大坨JSON数据
• Playwright加工一下：删掉看不见的、没用的节点，给可交互元素编上号，转成YAML格式
• 最后把简洁的YAML文本还给LLM

为啥不直接用DOM？因为DOM太啰嗦了。一个页面几千个节点，大半都是装样式的div、小图标、隐藏元素，全是没用的废话。无障碍树直接把垃圾信息过滤掉，全是干货，信息密度直接拉满。

几百KB的HTML处理完，就剩几十个节点的YAML，LLM看着也省心，省token就是省钱啊朋友们。

3. ref编号：AI和浏览器的“接头暗号”

文本树里每个可交互元素都有个[ref=eXX]的编号，比如e8是出发地输入框，e20是搜索按钮。AI想点哪个，直接报编号就行。

这个编号不是AI瞎编的，是生成快照的时候Playwright自动分配的，就像餐厅给你发的取餐号，一一对应。而且只要元素没变，多次快照编号基本不变，挺稳定。

当然也有失效的时候。比如你点了搜索，页面刷新了，元素全换了，旧编号就作废了，得重新拿快照。就像餐厅换了一批菜，原来的取餐号自然就没用了。

AI点e20的时候，Playwright内部有个映射表，直接找到对应的DOM元素执行点击。要是元素没了，就会报错说编号找不到，得重新拍快照，属于正常现象。

四、完整流程走一遍：AI是怎么查机票的

说这么多干的，咱们拿查机票举个例子，看看整个流程是怎么跑通的。

就比如你说“帮我查北京到上海最便宜的三个航班”：

1. LLM一看这活webFetch干不了，得用浏览器，就委派给browser子agent
2. 子agent静默启动Chrome，打开去哪儿网首页
3. 调用快照工具，拿到首页的文本树，知道了输入框和按钮的编号
4. 调用填表工具，在对应编号里填好北京、上海、日期
5. 调用点击工具，点搜索按钮
6. 页面跳转后，自动返回新的快照，里面全是航班信息
7. LLM从里面挑出最便宜的三个，把结果返回给你

整个过程行云流水，你都看不见浏览器窗口，后台默默就干完了。而且每次操作完自动返回新快照，不用AI再手动调一次，属于一步到位。

五、视觉方案：文本树搞不定的时候怎么办

文本树虽好，但也不是万能的。有些场景它真玩不转，就得靠截图视觉方案来补。

1. 什么时候得用视觉？

主要两类场景：

• canvas、WebGL渲染的内容：游戏、图表、视频播放器这些，根本没有DOM，无障碍树是空的，文本树直接罢工
• 靠外观区分的元素：比如“点那个黄色的按钮”、“看看红色的报错”，文本树里没颜色信息，定位不了

简单说：正常网页用文本树，稳又便宜；花里胡哨的渲染内容，才上视觉。两者是搭配干活，不是二选一。

2. 视觉方案的那些坑

首先不是所有模型都支持视觉，纯文本模型就没这能力，得看模型ID判断。而且不同厂商接口还不一样。

比如Anthropic家的API，支持直接在工具返回里放图片，很方便。其他家兼容OpenAI格式的，直接放图片会变成一长串base64，模型根本看不懂，还容易把上下文撑爆。

怎么办呢？就得先找个视觉模型把截图翻译成文字描述，再把文字发给主模型。相当于找个翻译官先看一眼图，再把内容念给主模型听。

当然这样精度就差点，坐标是近似值，属于凑合用的方案。选翻译模型也讲究，优先挑便宜的、免费的，能省则省，毕竟创业公司每一分钱都得花在刀刃上。

六、Agent集成技巧：别让浏览器工具拖垮性能

browser use的工具有二十多个，全塞给主agent可不是明智之举，这里面大有学问。

1. 子agent隔离：专人干专事

很多人图省事，把所有工具都堆主agent里，结果问题一大堆：

• 系统提示词变巨长，前缀缓存直接失效，钱哗哗地涨
• 大部分任务根本用不上浏览器，纯纯浪费token

正确做法是单独整个browser子agent，工具全放它那。主agent觉得需要用浏览器了，就把任务委派给子agent，子agent干完只返回最终结果，中间过程主agent不用管。

就像老板不自己跑客户，专门雇个销售，销售搞定了回来汇报就行，老板不用跟着跑断腿，省下来的精力干更重要的事。

2. 懒启动+缓存：别没事就开浏览器

浏览器也不是程序一启动就打开，那样纯纯浪费资源。都是第一次用的时候才启动，启动完就缓存下来，后面再用直接复用，不用反复开开关关。

就像你不会一上班就把打印机打开，真要打印的时候再开，开完就一直用着，省电还省时间。

要是浏览器意外关了或者崩了，缓存自动清掉，下次用再重新启动，很智能。

3. 权限分级：不能啥都让AI干

安全这根弦不能松。浏览器权限可大可小，全放开了容易出事。一般分三档：

• 完全不让用的：比如直接执行Node代码的工具，能读写你本地文件，太危险，直接不注册
• 每次都要问的：比如在页面里执行JS，能读cookie和本地存储，涉及隐私，每次调用都得用户确认
• 直接放行的：普通的跳转、点击、截图、快照，没啥风险，启用浏览器就默认授权了

毕竟AI干活可以，不能让它拿着你账号到处瞎逛，安全第一。

七、省钱大法：怎么把token开销打下来

用browser use最心疼的就是token，多步任务跑下来，token账单蹭蹭涨。这里面有个核心省钱技巧，亲测有效。

只留最新快照，旧的全扔掉

多步操作会反复调用快照，历史对话里会堆一大堆旧快照。这些旧快照对下一步操作一点用都没有，但每轮请求都得带着，纯纯浪费钱。

就像你聊天只需要看最新一条消息就行，前面的历史记录全是冗余信息，但系统偏要每次都全量发一遍，这不坑钱吗。

解决办法很简单：每轮请求发出去之前，把旧的快照、截图返回值全替换成一行占位提示，只留最新的一份。

别小看这一招，十步的任务能省百分之七八十的浏览器相关token，属于立竿见影的省钱技巧。Gemini CLI也是这么干的，英雄所见略同。

另外补充一句：截图的token消耗是按分辨率算的，跟文件大小没关系。压成JPEG只是传得快，不省token。想省截图token就得控制视口大小，别搞全页长截图，那玩意巨费钱。

八、市面上的产品都咋做的？简单盘一盘

说了这么多技术细节，咱们也看看市面上主流产品都是怎么实现的，各有啥特点。

1. x-code-cli

就是咱们今天主要参考的实现，用的是@playwright/mcp，主打文本树方案，视觉能力按模型自动开启。非Anthropic的模型用caption方式转文字描述，好处是纯文本模型也能用浏览器，跨供应商支持做得好。

2. Gemini CLI

谷歌自家的东西，内置了browser_agent，底层用chrome-devtools-mcp加puppeteer-core。也是文本树为主，截图分析是单独调用视觉模型，图不进主对话历史，省token。还支持好几种会话模式，玩法多。

3. Claude Code

Anthropic家的路子比较野，有Chrome扩展方案，能直接复用你本地Chrome的登录状态，cookie、OAuth都能用，相当于借你的浏览器干活。另外还有桌面级的computer use，纯视觉方案，不过只支持macOS。

4. Codex CLI

Rust写的通用MCP框架，本身不带浏览器功能，你自己配MCP服务端就行。灵活性拉满，就是啥都得自己折腾，适合动手能力强的朋友。

九、边界和槽点：它也不是万能的

吹了这么多，也得说说browser use的局限，别以为有了它就能让AI帮你干所有上网的活。

1. 页面写得烂，它也认不出来

文本树方案全靠页面语义撑着。要是前端图省事，全用div写按钮，又不加ARIA属性，那无障碍树里就只有普通节点，AI根本不知道这是个能点的按钮。

所以说写页面用语义化标签不光是政治正确，现在还关系到AI能不能看懂你家网站，以后说不定还影响SEO，前端同学可得上点心。

2. 人机验证是过不去的坎

碰到图片验证码、滑块验证、短信验证码，AI直接抓瞎，必须人工介入。还有Cloudflare这类反爬机制，也很容易把自动化浏览器拦下来。

这就像你去小区串门，AI能自己开门坐电梯，到了门禁刷脸那一步，还是得你本人来。毕竟安全机制本来就是防机器的，AI也是机器，防的就是它。

3. 移动端支持不行

现在只支持桌面端三大浏览器内核，移动端真实浏览器不支持，只能模拟视口和UA凑合用。原生App里的WebView更是碰不着，移动端场景还是受限。

十、最后唠两句

总的来说，browser use不是什么黑科技，本质上是把浏览器十几年前就有的无障碍能力，和成熟的自动化测试工具，通过MCP协议跟大模型接在了一起。

思路很巧妙，用最低的成本实现了最通用的浏览器操控能力，比纯视觉方案性价比高太多，所以才成了现在的主流。

当然它也不是银弹，有自己的适用场景和边界。静态内容用webFetch，复杂交互才上browser use，把钱花在刀刃上，才是合格的AI工程师。

以后AI操控浏览器肯定会越来越成熟，说不定哪天咱们真就能动动嘴，让AI把所有网页操作都干了。就是不知道到时候前端测试工程师会不会失业，哈哈。

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了