★ FEATURED ARTICLE 1. 本地浏览器自动化到底解决了什么问题浏览器自动化这个词做过爬虫或者RPA的朋友应该都不陌生。Selenium、Playwright、Puppeteer这些工具已经非常成熟了写几行代码就能让浏览器自动打开页面、点击按钮、填写表单。但问题在于传统方案本质上还是写死的脚本——你得提前知道页面上有哪些元素、它们的CSS选择器或XPath是什么、操作顺序是怎样的。一旦页面结构变了脚本就废了。而Computer Use这个概念之所以火起来是因为它换了一种思路不再让程序去解析DOM而是让AI像人一样看屏幕然后决定点哪里、输入什么。这背后的核心能力是大模型的视觉理解和任务规划。之前这类能力基本被云端API垄断调用一次不便宜而且数据要传到别人的服务器上。Fast Browser Use这个项目做的事情就是把这套能力搬到本地来跑。配合Qwen3.5的9B和35B两个规格的模型通过Ollama在本地启动整个链路——从截图、理解页面、规划动作到执行点击和输入——全部在你自己的机器上完成。不联网、不付费、数据不出本机。对于需要处理敏感数据、或者想低成本批量跑自动化任务的场景来说这个组合的吸引力非常直接。这篇文章我会从架构思路、环境搭建、模型选型、实操流程、踩坑记录几个维度把整个方案拆开讲清楚。不管你是刚接触浏览器自动化的新手还是已经在用Playwright做RPA的老手都能从中找到可以直接复用的东西。2. 整体架构与核心思路拆解2.1 为什么是视觉理解动作执行而不是传统选择器传统浏览器自动化的核心逻辑是找到元素→操作元素。找元素的方式无非是ID、class、XPath、文本内容这些。这套逻辑在页面结构稳定的情况下非常好用速度快、资源消耗低。但它有两个硬伤一是页面改版就失效二是跨网站的任务几乎没法复用。Fast Browser Use走的是另一条路。它的工作循环大致是这样的截取当前浏览器窗口的截图→把截图和任务描述一起发给本地大模型→模型输出下一步动作比如点击坐标(320, 480)或在输入框输入关键词→程序执行动作→再次截图→循环。这个循环听起来简单但里面有几个关键设计决策值得说清楚。第一个决策是用截图而不是DOM树。DOM树的信息量其实更大但结构复杂、token消耗高而且很多视觉上重要的信息比如按钮的位置、颜色、是否被遮挡在DOM里体现不出来。截图虽然信息密度低一些但更接近人类操作浏览器的真实体验模型也更容易理解。第二个决策是动作空间的设计。模型不能输出任意代码只能从预定义的动作集合里选点击、输入、滚动、等待、完成。这样做的好处是安全可控不会出现模型自作主张执行危险操作的情况。代价是灵活性受限复杂操作需要拆成多步。第三个决策是本地模型的选择。Qwen3.5在这个方案里扮演的是大脑角色负责理解截图内容和规划动作。9B版本跑在消费级显卡上没问题35B版本则需要更好的硬件。两个规格的取舍后面会详细讲。2.2 Fast Browser Use在整个链路中的位置很多人容易把Fast Browser Use和Playwright搞混。实际上它们是互补关系。Playwright负责手的部分——真正去操控浏览器、执行点击和输入Fast Browser Use负责脑的部分——决定什么时候该做什么动作。你可以把它理解成一个调度层把大模型的输出翻译成Playwright能执行的指令。这个分层设计的好处是底层浏览器操控的稳定性由Playwright保证它本身非常成熟上层智能决策由大模型负责。即使模型偶尔判断失误也不会导致浏览器崩溃或者系统异常最多就是点错地方下一轮截图后模型能自己纠正。整个数据流是这样的用户输入任务描述→Fast Browser Use启动浏览器并截图→截图编码后发给Ollama上的Qwen3.5→模型返回动作指令→Fast Browser Use解析指令并调用Playwright执行→循环直到任务完成或达到最大步数。全程本地没有任何外部API调用。2.3 纯离线方案的优势与边界纯离线最大的优势是数据安全。你让AI帮你登录后台系统、填写包含客户信息的表单、抓取内部数据这些操作全程不离开本机不存在数据泄露的风险。对于金融、医疗、法务这类对数据敏感的行业这个特性是刚需。第二个优势是成本。云端Computer Use类API按调用次数或token计费批量跑任务时成本会快速累积。本地跑的话电费之外没有额外开销。如果你有大量重复性的浏览器操作任务本地方案的边际成本几乎为零。但边界也很明显。本地9B模型的理解能力肯定不如云端的大模型复杂页面、模糊指令、多步骤任务的成功率会打折扣。35B版本好一些但对硬件要求更高。另外本地方案的响应速度受限于你的显卡如果显卡性能一般每一步操作的延迟可能达到几秒甚至十几秒做简单任务还行做需要快速交互的任务就不太合适了。3. 环境搭建与模型部署实操3.1 硬件与系统准备先说硬件门槛。9B模型用4-bit量化后大概占5-6GB显存一张RTX 3060 12GB就能跑得很舒服。35B模型4-bit量化后需要20GB左右的显存RTX 4090 24GB可以勉强跑或者用双卡。如果没有独立显卡纯CPU跑9B模型也可以但速度会慢很多每一步可能要等十几秒。内存方面建议至少16GB32GB更稳妥。因为除了模型本身浏览器、Python进程、系统缓存都要占内存。硬盘留出至少20GB空间给模型文件和依赖库。系统我用的是Windows 11Ollama对Windows的支持已经比较完善了。Linux和macOS也可以命令略有不同。下面以Windows 11为例走一遍完整流程。3.2 Ollama安装与Qwen3.5模型拉取Ollama的安装很直接去官网下载Windows安装包双击运行装完后打开终端输入ollama --version确认安装成功。接下来拉取模型。Qwen3.5在Ollama上的模型名需要确认一下通常格式是qwen3.5:9b和qwen3.5:35b这样的标签。拉取命令ollama pull qwen3.5:9b35B版本ollama pull qwen3.5:35b拉取时间取决于网速9B大概5-6GB35B大概20GB。拉完后用ollama list确认模型已经在本地了。启动模型服务ollama serve默认监听11434端口。你可以用curl测试一下curl http://localhost:11434/api/generate -d {\model\:\qwen3.5:9b\,\prompt\:\你好\}如果返回了正常的文本说明模型服务没问题。注意Ollama默认会把模型加载到显存里如果显存不够会自动降级到CPU。你可以在启动时通过环境变量控制比如OLLAMA_GPU_LAYERS20来指定有多少层跑在GPU上。这个参数对速度影响很大值得花时间调优。3.3 Fast Browser Use的安装与配置Fast Browser Use本身是一个Python项目安装方式通常是pippip install fast-browser-use它依赖Playwright所以还需要安装Playwright的浏览器驱动playwright install chromium安装完成后需要配置模型连接信息。Fast Browser Use需要知道Ollama的地址和要用的模型名。通常是在项目目录下创建一个配置文件或者在代码里直接指定from fast_browser_use import BrowserAgent agent BrowserAgent( modelqwen3.5:9b, base_urlhttp://localhost:11434, max_steps20, headlessFalse )headlessFalse表示显示浏览器窗口方便你观察AI的操作过程。调试阶段强烈建议开着窗口能看到模型每一步在做什么出问题时也好排查。3.4 模型选型9B还是35B这是很多人纠结的点。我的建议是先用9B跑通流程确认整个链路没问题再根据实际效果决定要不要上35B。9B的优势是快、省资源、部署简单。在RTX 3060上每一步推理大概1-3秒做简单的表单填写、页面点击、信息提取完全够用。缺点是复杂页面的理解能力有限比如页面上有大量相似元素时容易点错或者对模糊指令的理解不够准确。35B的优势是理解能力强复杂任务的成功率明显更高。但代价是显存需求大、推理速度慢。在RTX 4090上每一步推理大概3-8秒做多步骤任务时整体耗时会比较可观。我的实测经验是如果任务步骤在5步以内、页面结构清晰9B足够如果任务涉及多页面跳转、条件判断、复杂表单35B的成功率会高不少。你可以两个都拉下来根据任务复杂度切换。4. 浏览器自动化任务实操全流程4.1 第一个任务自动搜索并提取结果我们从最简单的场景开始让AI打开搜索引擎搜索一个关键词然后把前几条结果的标题提取出来。任务描述这样写task 打开搜索引擎搜索本地大模型部署然后提取前5条搜索结果的标题运行后Fast Browser Use会启动Chromium截图当前页面把截图和任务描述发给Qwen3.5。模型看到截图后会输出类似点击搜索框的动作。程序执行后再次截图模型看到搜索框已聚焦输出输入本地大模型部署。输入完成后模型输出点击搜索按钮或按回车。结果页加载后模型分析截图提取标题文本任务完成。整个过程你可以在浏览器窗口里实时看到。第一次跑的时候建议盯着看观察模型的决策逻辑这对后续调试很有帮助。实操心得任务描述要尽量具体。搜索本地大模型部署比搜索一下本地大模型好因为前者明确了搜索词模型不需要猜测。提取前5条标题比看看结果好因为前者有明确的输出要求。4.2 表单自动填写从简单到复杂表单填写是浏览器自动化最常见的场景。我们先从一个简单的登录表单开始。假设你要自动登录一个内部系统任务描述task 在用户名输入框填写admin在密码输入框填写password123然后点击登录按钮模型看到登录页面截图后会依次执行点击用户名框→输入admin→点击密码框→输入password123→点击登录按钮。每一步都会截图确认。复杂表单的挑战在于字段多、布局复杂。比如一个注册页面有十几个输入框模型可能会搞混。这时候有两个策略一是把任务拆成多个子任务分步执行二是在任务描述里明确每个字段的位置特征比如在标有手机号的输入框里填写...。我试过一个包含姓名、邮箱、电话、地址、公司、职位的注册表单9B模型在第三步开始出错把电话填到了邮箱框里。换成35B后一次通过。所以复杂表单建议直接用35B。4.3 多步骤任务页面跳转与条件判断真正体现Computer Use价值的是多步骤任务。比如打开电商网站搜索机械键盘找到价格低于300元的第一个商品点击进入详情页把商品标题和价格记录下来。这个任务涉及搜索→结果页分析→价格筛选→点击进入→信息提取。每一步都依赖上一步的截图结果。9B模型在前两步没问题到价格筛选时容易出错因为它需要从截图中识别出多个价格数字并比较。35B在这方面的表现明显更好。另一个难点是页面加载等待。有些页面点击后需要几秒才加载完如果模型在加载完成前就截图会看到空白页或加载动画导致决策失误。Fast Browser Use通常有等待机制但你也可以在任务描述里加一句等待页面完全加载后再操作。4.4 动作空间与参数详解Fast Browser Use支持的动作类型主要包括动作类型参数说明clickx, y坐标点击指定位置type文本内容在当前焦点输入文本scroll方向、距离滚动页面wait秒数等待指定时间done结果文本任务完成返回结果坐标点击是核心动作。模型通过分析截图估算目标元素的中心坐标然后输出click动作。这里有个精度问题截图分辨率和实际浏览器窗口分辨率可能不一致需要做坐标映射。Fast Browser Use内部会处理这个转换但如果你自己改代码要注意这个细节。输入动作依赖于焦点。模型必须先点击输入框使其获得焦点才能执行type动作。如果模型跳过了点击直接输入文本会跑到错误的位置。这是9B模型偶尔会犯的错误35B基本不会。5. 常见问题与排查技巧实录5.1 模型响应慢或超时这是最常见的问题。原因通常是显存不足导致模型部分跑在CPU上或者模型太大超出了硬件能力。排查步骤先用ollama ps看模型加载状态确认是否全部在GPU上。如果显示部分在CPU说明显存不够需要换小模型或者调整GPU层数。另外检查是否有其他程序占用显存浏览器本身也会占一部分。如果硬件没问题但还是很慢可能是Ollama的默认配置不够优化。可以尝试设置OLLAMA_NUM_PARALLEL1减少并发把资源集中给单个请求。5.2 点击位置偏移模型输出的坐标和实际点击位置有偏差导致点错元素。这个问题通常有三个原因截图缩放比例不一致、页面有滚动条导致坐标偏移、模型估算不准。解决办法确保截图分辨率和浏览器视口分辨率一致在任务开始前先把页面滚动到顶部如果某个元素总是点不准可以在任务描述里给出更明确的位置提示比如点击页面右上角的登录按钮。5.3 模型陷入循环模型反复执行同一个动作比如一直点击同一个位置任务无法推进。这通常是因为模型没有正确理解上一步的结果或者页面状态没有按预期变化。Fast Browser Use有max_steps参数限制最大步数防止无限循环。但更好的做法是在任务描述里加入纠错提示比如如果点击后页面没有变化尝试滚动页面或等待几秒。另外检查页面是否有弹窗遮挡弹窗是导致循环的常见原因。5.4 中文输入问题在输入框里输入中文时有时会出现乱码或输入不完整。这通常和输入法状态有关。Playwright的type动作是模拟键盘输入如果系统输入法处于中文状态可能会干扰。解决办法在自动化开始前把系统输入法切换到英文状态或者用Playwright的fill方法直接设置输入框的值不模拟键盘但这样可能触发不了某些页面的JS事件。折中方案是先用type输入一个字符触发焦点再用fill设置完整值。5.5 常见问题速查表问题现象可能原因解决方法模型响应超过30秒显存不足部分跑在CPU换小模型或减少GPU层数点击总是偏几像素截图与视口分辨率不一致统一分辨率设置反复点击同一位置页面状态未变化或弹窗遮挡检查弹窗增加等待时间中文输入乱码输入法状态干扰切换英文输入法或改用fill任务中途卡住模型无法理解当前页面简化任务描述拆分子任务浏览器启动失败Playwright驱动未安装执行playwright install避坑技巧调试阶段一定要开headlessFalse能直接看到模型在做什么。很多问题看一眼浏览器窗口就明白了比看日志快得多。另外把每一步的截图保存下来出问题时可以回放整个决策过程。6. 性能调优与进阶玩法6.1 提示词工程对成功率的影响任务描述的质量直接决定成功率。我总结了几条经验第一动作要具体说点击搜索按钮而不是搜索一下第二顺序要明确用然后、接着连接步骤第三异常处理要提前说比如如果出现弹窗先关闭弹窗第四输出格式要指定比如以JSON格式返回结果。一个优化前后的对比例子。优化前帮我查一下天气。优化后打开搜索引擎搜索北京今天天气从结果中提取温度和天气状况以温度X天气Y的格式返回。后者的成功率明显更高。6.2 多模型协作的思路9B快但不够聪明35B聪明但慢。一个进阶玩法是用9B做常规步骤遇到复杂决策时切换到35B。Fast Browser Use本身可能不支持动态切换但你可以在外层包一层逻辑根据任务阶段选择不同的模型实例。另一个思路是用9B做执行者用35B做规划者。35B先分析任务、拆解步骤9B逐步执行。这样兼顾了速度和准确率。6.3 与现有RPA流程的结合如果你已经在用Playwright或Selenium做RPA不需要完全替换。可以把Fast Browser Use作为兜底方案在传统选择器失效时让AI接管。比如页面改版后原来的XPath找不到了就调用AI来定位元素。这样既保留了传统方案的稳定性又增加了应对变化的能力。具体做法是封装一个函数先尝试用选择器定位失败后调用Fast Browser Use的agent执行点击。两种方式共用同一个浏览器实例切换成本很低。6.4 批量任务的队列管理当你需要跑大量自动化任务时队列管理就很重要了。不建议同时开多个浏览器实例因为显存和内存会不够。更好的做法是串行执行用一个任务队列一个跑完再跑下一个。每个任务结束后要确保浏览器状态干净——关闭所有标签页、清空cookies如果需要、回到初始页面。否则上一个任务的状态可能影响下一个任务。我试过连续跑20个表单填写任务前5个正常第6个开始出错排查后发现是cookies累积导致页面跳转到了已登录状态和预期不符。7. 实际使用中的体会与建议我从这个方案刚出来就开始折腾前后跑了大概上百个任务覆盖了信息提取、表单填写、页面操作几大类场景。最大的感受是本地浏览器自动化已经能用了但离好用还有距离。9B模型做简单任务没问题复杂任务的成功率大概在六七成需要人工兜底。35B能到八九成但速度慢适合对准确性要求高、对时间不敏感的场景。硬件方面如果你打算认真用这个方案建议至少准备12GB显存的显卡。8GB能跑9B但比较勉强6GB以下基本只能跑CPU体验会差很多。内存32GB是舒适线16GB会经常遇到内存压力。最后分享一个小技巧把常用的任务描述存成模板用的时候改几个参数就行。比如登录模板、搜索模板、表单填写模板。这样不用每次重新组织语言也能保证描述质量的一致性。模板积累多了之后你会发现大部分日常自动化需求都能覆盖。
阅读完成 · 觉得有帮助？
