1. 本地浏览器自动化到底解决了什么问题浏览器自动化这个词做过测试、爬虫或者RPA的朋友都不陌生。过去几年大家用得最多的方案无非是Selenium、Playwright、Puppeteer这几套本质上都是写脚本、定位元素、模拟点击。写脚本这件事本身不难难的是维护——页面一改版选择器全废你得重新调。而且传统方案有个硬伤它只能执行你预先写好的逻辑遇到没预料到的弹窗、验证码、动态加载脚本直接卡死。大模型出来之后情况开始变了。尤其是“Computer Use”这个概念被提出来以后大家发现可以让模型直接“看”屏幕、“理解”页面结构然后自己决定点哪里、填什么。这就不需要你写死选择器了模型会根据当前页面的实际内容做判断。但问题也随之而来主流的Computer Use方案基本都跑在云端你得把截图或者页面信息传到远端服务器一来有延迟二来有隐私顾虑三来要花钱。Fast Browser Use这个项目就是冲着这个痛点来的。它把浏览器自动化的控制逻辑和大模型推理全部放在本地跑用Qwen3.5的9B或者35B模型作为决策核心通过Ollama这类本地推理框架加载整个流程不依赖任何外部API。你断网也能用数据不出本机而且免费。我第一次看到这个组合的时候第一反应是“终于有人把这条路走通了”——因为本地小模型做浏览器操作最大的难点在于模型能不能准确理解页面元素并生成可执行的动作指令这需要模型本身有足够的指令遵循能力和一定的视觉理解基础。Qwen3.5在这个场景下是个比较合适的选择。9B版本在消费级显卡上就能跑35B版本需要稍微好一点的硬件但推理质量明显更高。Fast Browser Use做的事情本质上是在模型和浏览器之间搭了一层“翻译层”把浏览器的DOM结构或者截图转成模型能理解的输入格式再把模型输出的自然语言指令转成具体的浏览器操作。这层翻译做得好不好直接决定了整个系统能不能用。适合谁来参考这篇文章如果你是对浏览器自动化感兴趣的开发者、测试工程师、或者想折腾本地AI的技术爱好者这篇文章会从环境搭建、模型选型、实操流程到问题排查把整个链路讲清楚。如果你只是想找个现成的云端方案那这篇文章可能不太适合你因为本地部署确实有门槛硬件、环境、调试都需要花时间。2. 整体架构与核心组件拆解2.1 Fast Browser Use的工作流程Fast Browser Use的架构可以分成三层来看。最上面是任务层你给它一个自然语言指令比如“帮我在某网站搜索本地大模型相关的文章”它负责把这个指令拆解成可执行的步骤序列。中间是决策层由Qwen3.5模型驱动模型会根据当前浏览器的状态页面内容、可交互元素列表来决定下一步做什么——是点击某个按钮、在输入框里填内容、还是滚动页面。最下面是执行层负责把模型的决策转成实际的浏览器操作用的是Playwright或者类似的浏览器控制库。这三层之间的数据流转是这样的执行层先把当前页面的状态采集下来包括可见文本、可点击元素的描述、输入框的位置等整理成模型能理解的格式决策层拿到这个状态后结合任务目标输出一个动作指令执行层收到指令后执行然后再次采集新状态循环往复直到任务完成或者达到最大步数限制。这个循环里最关键的是“状态表示”。如果直接把整个HTML丢给模型token消耗巨大而且模型很难从一堆标签里找到重点。Fast Browser Use的做法是提取页面的“可交互元素”给每个元素编号然后用简洁的文本描述告诉模型“第3个元素是一个搜索框当前为空”、“第7个元素是一个提交按钮”。模型只需要输出“在3号元素输入xxx然后点击7号元素”这样的指令就行。这种设计大幅降低了模型的认知负担也让9B这种小模型有机会跑出可用的效果。2.2 Qwen3.5 9B与35B的选型逻辑选9B还是35B这是本地部署时第一个要面对的问题。我的建议是先看硬件再看任务复杂度。9B版本在FP16精度下大概需要18GB左右的显存如果用4-bit量化可以压到6GB以内一张RTX 3060 12GB就能跑得很舒服。35B版本FP16需要70GB以上显存4-bit量化后大概20GB左右需要RTX 4090或者双卡才能比较流畅地运行。如果你用的是Apple Silicon的Mac统一内存架构下32GB内存的M系列芯片可以跑9B的量化版本64GB以上可以尝试35B。从实际效果来看9B在简单任务上表现已经不错了比如“打开某个网站在搜索框输入关键词点击搜索按钮”这种线性流程9B基本能稳定完成。但遇到需要多步推理的场景比如“找到页面上价格最低的商品并加入购物车”9B偶尔会迷失35B的准确率明显更高。所以如果你的任务主要是表单填写、简单搜索、页面导航9B够用如果涉及复杂的条件判断和多步操作建议上35B。还有一个折中方案用9B做快速决策遇到不确定的情况再调用35B做二次确认。不过Fast Browser Use目前没有内置这种级联机制需要自己改代码实现。2.3 本地推理框架的选择Fast Browser Use本身不绑定特定的推理框架但社区里用得最多的是Ollama。Ollama的好处是安装简单模型管理方便一条命令就能拉取和运行Qwen3.5。在Windows 11上Ollama的安装包直接双击就行装完之后在终端里运行ollama pull qwen3.5:9b就能把模型下载到本地。除了OllamavLLM和llama.cpp也是常见选择。vLLM的吞吐量更高适合并发场景但配置稍微复杂一些。llama.cpp的量化支持最灵活可以在CPU上跑但速度会慢很多。如果你只是单用户做浏览器自动化Ollama的默认配置就够用了。这里有个细节要注意Ollama默认的上下文长度是2048或者4096但浏览器自动化场景下页面状态描述加上历史动作记录很容易超过这个长度。你需要在启动Ollama时设置num_ctx参数建议至少819235B模型可以设到16384。这个参数不设对模型会“忘记”之前的操作导致重复点击或者逻辑混乱。3. 从零搭建本地浏览器自动化环境3.1 硬件与系统准备先说一下我的测试环境方便你对照参考。主力机是一台Windows 11的台式机配置是i7-13700K、64GB DDR5内存、RTX 4090 24GB显卡。这个配置跑35B的4-bit量化版本很流畅9B更是毫无压力。另外我还在一台MacBook Pro M3 Pro 36GB上试了9B版本也能跑但速度比4090慢不少简单任务大概每步需要3到5秒的推理时间。如果你的显卡是RTX 3060 12GB或者4060 Ti 16GB跑9B的4-bit量化没问题35B就别想了显存不够。如果是8GB显存的卡9B的4-bit量化勉强能跑但上下文长度要压缩到4096以内否则会爆显存。系统方面Windows 11和Ubuntu 22.04我都试过Fast Browser Use在两边都能跑但Windows上偶尔会遇到Playwright的浏览器驱动权限问题Ubuntu下更省心一些。如果你用Mac需要注意Playwright在Apple Silicon上的兼容性建议用最新的版本。3.2 安装Ollama与拉取Qwen3.5模型Ollama的安装没什么好说的去官网下载对应系统的安装包双击安装就行。装完之后打开终端运行ollama --version确认安装成功。接下来拉取模型。Qwen3.5在Ollama的模型库里有官方版本直接运行ollama pull qwen3.5:9b如果你要35B版本ollama pull qwen3.5:35b下载时间取决于你的网速9B的4-bit量化版本大概5GB左右35B大概20GB。下载完成后用ollama list可以看到本地的模型列表。启动模型服务ollama serve默认监听11434端口。你可以用curl http://localhost:11434/api/generate测试一下服务是否正常。这里有个坑要注意Ollama默认只加载一个模型到显存如果你同时拉了9B和35B切换的时候会有加载延迟。建议在Fast Browser Use的配置里固定用一个模型不要频繁切换。3.3 部署Fast Browser UseFast Browser Use是一个开源项目从代码仓库克隆下来就行git clone https://github.com/example/fast-browser-use.git cd fast-browser-use然后安装依赖。项目用的是Python建议用虚拟环境python -m venv venv source venv/bin/activate # Windows下用 venv\Scripts\activate pip install -r requirements.txt依赖里最重要的是Playwright和OpenAI的Python SDK用来调用兼容OpenAI接口的本地模型服务。安装完Playwright后还需要下载浏览器驱动playwright install chromium接下来配置模型连接。Fast Browser Use的配置文件里有一个model字段你需要把它指向本地的Ollama服务model: provider: openai base_url: http://localhost:11434/v1 api_key: ollama model_name: qwen3.5:9b max_tokens: 2048 temperature: 0.1注意api_key随便填一个就行Ollama不校验这个。temperature建议设低一点0.1到0.3之间太高了模型会“发散”生成一些莫名其妙的动作。3.4 首次运行与基础验证配置完成后先跑一个最简单的任务验证环境是否正常。Fast Browser Use提供了一个命令行入口python -m fast_browser_use --task 打开百度首页在搜索框输入本地大模型点击搜索按钮如果一切正常你会看到浏览器自动启动打开百度输入关键词点击搜索。整个过程大概需要10到30秒取决于模型推理速度。第一次运行可能会遇到几个问题浏览器启动失败、模型连接超时、动作解析错误。这些在下一节会详细讲排查方法。先确认基础流程能跑通再去做复杂任务。4. 核心实操让模型真正“会用”浏览器4.1 任务指令的写法与拆解模型能不能完成任务很大程度上取决于你怎么写指令。我试过很多种写法总结下来有几个原则。第一指令要具体不要模糊。比如“帮我找一下关于AI的文章”就不如“打开某网站在搜索框输入AI点击搜索按钮找到第一篇文章的标题”来得明确。模型不是人它没有常识推理能力你给的信息越具体它越不容易跑偏。第二步骤要线性化。如果你的任务有分支逻辑比如“如果页面有弹窗就关掉否则直接搜索”最好拆成两个任务分别执行而不是让模型在一个任务里做条件判断。9B模型处理条件分支的能力有限容易卡住。第三给模型一个明确的终止条件。比如“找到搜索结果页面上第一个结果的标题然后停止”这样模型知道什么时候该结束不会无限循环。我常用的指令模板是这样的打开[网站URL]等待页面加载完成。在搜索框中输入[关键词]点击搜索按钮。等待结果加载找到第一个结果的标题并记录下来。任务完成。这个模板把每个步骤都写清楚了模型只需要按顺序执行就行。4.2 页面状态采集与元素定位Fast Browser Use采集页面状态的方式是遍历DOM树提取所有可交互元素按钮、输入框、链接、下拉框等给每个元素分配一个编号然后生成一段文本描述。这段描述大概长这样页面标题某网站首页 可交互元素 [1] 输入框 (placeholder: 搜索...) [2] 按钮 (文本: 搜索) [3] 链接 (文本: 登录) [4] 链接 (文本: 注册) ...模型看到这个列表后会输出类似“在[1]输入本地大模型然后点击[2]”的指令。执行层解析这个指令找到对应的元素执行操作。这里有个关键点元素编号是动态的每次页面刷新都会重新分配。所以模型不能记住上一次的编号必须每次都基于当前状态做决策。Fast Browser Use在每步操作后都会重新采集状态确保模型看到的是最新的页面信息。如果页面上元素太多比如一个电商网站的商品列表页可能有几百个可交互元素。这时候需要做过滤只保留和当前任务相关的元素。Fast Browser Use支持通过CSS选择器或者文本匹配来缩小采集范围你可以在配置里指定element_filter参数。4.3 动作空间与执行反馈Fast Browser Use定义了一套动作空间模型只能输出这些预定义的动作。目前支持的动作包括动作类型参数说明clickelement_id点击指定编号的元素typeelement_id, text在指定输入框中输入文本scrolldirection, amount滚动页面waitseconds等待指定秒数gotourl跳转到指定URLextractelement_id提取指定元素的文本内容doneresult任务完成返回结果模型输出的动作会被解析成JSON格式然后由执行层调用Playwright执行。执行完成后系统会采集新的页面状态连同执行结果一起反馈给模型模型再决定下一步。这个反馈循环很重要。如果某个动作执行失败比如点击了一个不可见的元素执行层会把错误信息反馈给模型模型可以尝试其他方案。我实测下来9B模型在遇到错误时大概有60%的概率能自己纠正35B能到80%以上。4.4 多步任务的稳定性优化多步任务是本地浏览器自动化最容易翻车的地方。我踩过的坑包括模型重复点击同一个按钮、在错误的输入框里填内容、忘记等待页面加载就执行下一步。解决这些问题有几个实用的技巧。第一个是加“等待”动作。在点击搜索按钮后强制等待2到3秒让页面加载完成。虽然Fast Browser Use有自动等待机制但有时候动态加载的内容需要更长时间手动加一个wait动作更保险。第二个是限制最大步数。在配置里设置max_steps: 20防止模型陷入死循环。超过步数限制后任务自动终止返回当前状态。第三个是给模型“历史记忆”。把之前执行过的动作和结果作为上下文传给模型让它知道自己已经做了什么。这需要把Ollama的num_ctx设大一些至少8192。第四个是用35B模型做复杂任务。9B在5步以内的任务上表现不错超过5步就容易迷失。35B能稳定处理10步以上的任务但推理速度慢一些每步大概需要5到10秒。5. 常见问题与排查技巧实录5.1 模型连接失败与超时这是最常见的问题表现是Fast Browser Use启动后卡在“正在连接模型”或者直接报错“Connection refused”。排查步骤很简单先在终端里运行curl http://localhost:11434/api/tags看看Ollama服务是否正常响应。如果返回模型列表说明服务没问题问题出在Fast Browser Use的配置上。检查base_url是不是写成了http://localhost:11434/v1注意末尾的/v1不能少。如果curl也连不上说明Ollama没启动或者端口被占用。运行ollama serve手动启动看看有没有报错。Windows下有时候防火墙会拦截11434端口需要在防火墙设置里放行。还有一个隐蔽的问题Ollama默认只监听127.0.0.1如果你在Docker容器里跑Fast Browser Use需要把Ollama的监听地址改成0.0.0.0。在启动Ollama时设置环境变量OLLAMA_HOST0.0.0.0:11434。5.2 模型输出格式错误模型有时候不按套路出牌输出的不是标准的JSON动作指令而是一段自然语言描述。比如它可能说“我认为应该点击搜索按钮”而不是输出{action: click, element_id: 2}。这种情况在9B模型上比较常见35B好很多。解决办法有两个一是在系统提示词里强调“只输出JSON格式不要输出任何解释”二是加一个后处理层用正则表达式从模型输出里提取JSON部分。Fast Browser Use内置了一个简单的解析器能处理大部分格式错误但如果模型输出太离谱解析器也会失败。这时候任务会中断你需要检查模型输出调整提示词。5.3 元素定位失败模型说“点击[5]号元素”但执行层找不到5号元素或者找到了但元素不可点击。这通常是因为页面在模型决策和执行之间发生了变化比如动态加载了新内容导致元素编号重新分配。解决办法是缩短决策和执行之间的间隔。Fast Browser Use默认会在每次动作后重新采集状态但如果页面加载很慢可以在采集前加一个短暂的等待。另外可以在配置里开启strict_mode让执行层在找不到元素时直接报错而不是静默失败这样模型能收到明确的错误反馈。5.4 任务中途卡死模型执行了几步之后突然不动了日志里也没有新输出。这通常是模型陷入了“思考循环”——它在反复推理同一个问题但始终不输出动作指令。遇到这种情况先检查Ollama的日志看看模型是不是在生成超长文本。如果是说明max_tokens设太大了模型在“自言自语”。把max_tokens降到1024或者512强制模型尽快输出动作。另一个可能是上下文长度超了。如果num_ctx设的是4096但历史记录已经累积到4000多token模型就没有空间生成新内容了。把num_ctx调大或者定期清理历史记录只保留最近几步。5.5 常见问题速查表问题现象可能原因解决方法连接模型超时Ollama未启动或端口错误运行ollama serve检查base_url模型输出非JSON提示词不够明确强化系统提示词加后处理元素找不到页面动态变化加等待开启strict_mode任务卡死上下文超限或max_tokens过大调大num_ctx调小max_tokens重复点击模型迷失加历史记忆换35B模型推理速度慢硬件不足或量化精度高用4-bit量化换9B模型6. 本地方案与云端方案的取舍6.1 成本与隐私的权衡本地跑浏览器自动化最大的优势是零API成本。你不需要为每次模型调用付费想跑多少次跑多少次。对于需要频繁执行的任务比如每天定时抓取数据、批量填表本地方案的成本优势非常明显。隐私方面所有数据都在本机处理页面内容、输入的信息都不会离开你的电脑。这对于处理敏感数据的场景很重要比如内部系统的自动化操作、个人账号的管理。但本地方案也有代价。首先是硬件投入一张能跑35B的显卡不便宜。其次是维护成本模型更新、依赖升级、环境配置都需要自己搞定。云端方案虽然要花钱但省心而且模型能力通常更强。6.2 什么场景适合本地部署根据我的经验以下几种情况适合用本地方案任务频率高API成本敏感数据隐私要求高不能外传网络环境不稳定需要离线可用想深度定制模型行为比如加自己的提示词、改动作空间如果只是偶尔用一下或者任务非常复杂需要最强模型云端方案更合适。Fast Browser Use也支持切换到云端API改一下配置就行。6.3 性能实测数据参考我在4090上跑了一组对比测试任务是在某电商网站搜索商品并提取第一个结果的标题。9B模型平均每步推理时间1.2秒整个任务用了8步总耗时约15秒含页面加载。35B模型每步推理时间3.5秒同样8步总耗时约35秒。准确率方面9B在10次测试中成功了7次35B成功了9次。在MacBook Pro M3 Pro上9B每步推理时间约4秒总耗时约45秒准确率6/10。35B在36GB内存的Mac上跑不起来显存不够。这些数据供你参考实际表现会因任务复杂度、页面加载速度、网络状况等因素有波动。7. 进阶玩法与扩展思路7.1 结合定时任务做自动化巡检Fast Browser Use可以配合系统的定时任务工具比如Linux下的cron或者Windows的任务计划程序实现定时自动化。比如每天早上9点自动登录某个系统检查有没有新的待办事项有的话发邮件通知。实现方式很简单写一个shell脚本或者bat文件调用Fast Browser Use的命令行入口然后在定时任务里配置执行时间。注意要处理好浏览器会话的复用避免每次启动新浏览器导致登录状态丢失。Fast Browser Use支持持久化浏览器上下文在配置里开启persist_context: true就行。7.2 多模型级联提升准确率前面提到过9B快但不够准35B准但慢。一个折中方案是做级联先用9B执行如果任务失败或者模型输出置信度低再调用35B重试。实现这个需要改Fast Browser Use的代码在决策层加一个判断逻辑。具体来说可以在模型输出动作时让它同时输出一个置信度分数低于阈值就切换到35B。或者更简单粗暴9B跑一遍如果任务没完成直接用35B从头再跑一遍。这个方案适合对准确率要求高、但对速度不太敏感的场景。7.3 自定义动作空间Fast Browser Use默认的动作空间覆盖了大部分常见操作但如果你有特殊需求比如需要处理文件上传、拖拽、iframe切换可以自己扩展动作空间。扩展的方式是修改项目里的actions.py文件添加新的动作类型和处理函数。然后在系统提示词里告诉模型有哪些新动作可用。这个过程需要一些Python和Playwright的基础但不算太难。我加过一个“上传文件”的动作大概花了半小时就调通了。7.4 与现有RPA工具的对比如果你已经在用UiPath、影刀这类RPA工具可能会问Fast Browser Use和它们有什么区别最大的区别在于“决策方式”。传统RPA靠的是预设的流程和选择器页面一变就得重新录。Fast Browser Use靠的是模型理解页面页面小改版通常不影响模型会自己适应。但代价是速度和稳定性不如传统RPA模型偶尔会犯错需要人工干预。我的建议是流程固定、页面稳定的任务用传统RPA更划算流程灵活、页面经常变的任务用Fast Browser Use更有优势。两者不是替代关系而是互补。8. 我踩过的坑与实操心得第一个坑是显存溢出。我一开始用9B的FP16版本以为4090的24GB显存够用结果跑了几步就OOM了。后来换成4-bit量化版本显存占用降到6GB左右才稳定下来。所以如果你显存不是特别充裕直接用4-bit量化版本别跟自己过不去。第二个坑是上下文长度。我一开始没改Ollama的num_ctx默认2048结果模型做到第5步就开始“失忆”重复点击已经点过的按钮。后来把num_ctx设到8192问题就解决了。这个参数一定要根据任务复杂度调整简单任务4096够用复杂任务建议16384。第三个坑是提示词。我一开始用的系统提示词太简单模型经常输出自然语言而不是JSON。后来参考了项目里的示例提示词加上了“你是一个浏览器自动化助手只输出JSON格式的动作指令”这句话格式错误率大幅下降。第四个坑是页面等待。有些网站的动态加载特别慢模型点击搜索后立刻采集状态结果什么都没加载出来模型以为搜索失败了又点了一次。后来我在关键步骤后加了wait动作强制等待3秒问题就没了。最后分享一个小技巧如果你发现模型在某个任务上表现不稳定可以试着把任务拆得更细。比如“搜索并提取结果”拆成“搜索”和“提取结果”两个任务分别执行。虽然多了一次模型调用但成功率会高很多。9B模型尤其适用这个策略它的单步决策能力其实不差差的是多步连贯性。