微调4B小模型：浏览器任务准确率从22%飙升至63%

小模型也能胜任浏览器自动化？

长期以来，浏览器自动化任务被认为是大模型的专属领域。面对需要开放式研究或深度推理的浏览场景，小参数模型往往力不从心。然而，一位开发者在Reddit上分享的实验却给出了不同的答案：通过在约3000条浏览器操作轨迹上微调Qwen3.5-4B，他成功将基准测试的准确率从22%提升至63%。

这个实验的核心洞察在于：并非所有浏览器任务都需要复杂推理。许多实际的浏览器自动化工作流其实高度程序化——比如提取结构化数据、上传下载文档、填写和提交表单等。这些任务通常可以被精确定义并重复执行，因此理论上一个小模型只要搭配合适的浏览器执行框架（harness），就能表现得相当不错。

实验设计与数据来源

作者选择了Qwen3.5-4B作为基础模型，这是一个仅有40亿参数的小型模型。Qwen3.5-4B是阿里巴巴通义千问团队推出的Qwen3.5系列中的轻量级版本，该系列采用了混合推理架构，支持"思考模式"和"非思考模式"的切换，使模型能够根据任务复杂度动态分配计算资源。这种混合推理架构（Hybrid Reasoning）是近年来大语言模型设计的重要趋势之一。传统模型对所有输入都采用相同的计算路径，而混合推理架构允许模型根据问题的难度动态选择是否启用深度推理链。在"思考模式"下，模型会生成详细的中间推理步骤（类似Chain-of-Thought），适用于数学证明、逻辑推理等复杂任务；在"非思考模式"下，模型跳过冗长的推理过程直接输出答案，适用于简单的事实查询或格式化操作。这种设计的灵感部分来源于人类认知中的"系统1"与"系统2"思维理论（由Daniel Kahneman在《思考，快与慢》中阐述），即快速直觉式思维与慢速分析式思维的切换。对于浏览器自动化这类任务，大量操作（如点击按钮、填写表单）适合非思考模式的快速响应，而少数需要判断的场景才需要启用思考模式，这使得混合推理架构在该领域尤为适用。4B的参数量意味着该模型可以在单张消费级GPU（如RTX 4090甚至更低规格）上高效运行，量化后甚至可以部署在边缘设备上。虽然这种规模的模型在通用基准测试中通常远逊于百亿级以上的模型，但其推理速度快、内存占用低的特点使其成为特定垂直场景下微调的理想基座。

训练数据来自约3000条由GPT-5.6 Luna生成的浏览器智能体（Browser Agent）操作轨迹。GPT-5.6 Luna本身是浏览任务领域的强基线模型，因此用它生成的高质量轨迹作为监督微调（SFT）的教师数据，是一种典型的知识蒸馏思路。知识蒸馏（Knowledge Distillation）最初由Geoffrey Hinton等人在2015年提出，其核心思想是让一个小模型（学生模型）从大模型（教师模型）的输出中学习，从而在保持较小参数量的同时获得接近大模型的性能。经典的知识蒸馏使用教师模型的软标签（soft labels，即各类别的概率分布）来训练学生模型，因为软标签包含了比硬标签（one-hot编码）更丰富的类间关系信息——例如，教师模型可能给出"90%概率是猫，8%概率是豹"的预测，这个8%就传递了猫和豹在视觉上相似的隐含知识。后续的研究发展出了特征蒸馏（让学生模型学习教师模型的中间层表示）、关系蒸馏（学习样本间的关系结构）等方法。本实验采用的轨迹级蒸馏属于更宏观的行为克隆（Behavioral Cloning）范畴，它不关注模型内部表示的对齐，而是直接让学生模型模仿教师模型的外在行为序列。这种方式的优点是实现简单、对教师模型架构无要求（甚至可以是闭源API），缺点是可能只学到表面行为模式而非深层决策逻辑。在本实验中，这种蒸馏采用了较为直接的方式：用强模型生成高质量操作轨迹，再通过SFT让小模型学习其中的行为模式。SFT本质上是在预训练模型基础上，用标注好的输入-输出对进行进一步训练，这种方法相比强化学习等更复杂的训练范式，实现成本更低，训练过程也更稳定。

你可能没注意到，作者在框架选择上做了权衡。他选择了Browser Agent而非BrowserCode作为微调工作的执行框架。这两者代表了两种不同的浏览器自动化设计哲学：Browser Agent框架通常采用高层语义动作（如"点击元素X"、"在输入框Y中输入文本Z"）来描述操作，每个动作是一个结构化的指令；而BrowserCode框架则让模型直接生成可执行的代码（通常是Python或JavaScript），通过Playwright、Selenium等浏览器自动化库来控制浏览器。Playwright和Selenium是浏览器自动化领域最主流的两个开源工具库。Selenium诞生于2004年，是该领域的先驱，支持多种编程语言和几乎所有主流浏览器，但其基于WebDriver协议的架构在处理现代单页应用（SPA）时存在稳定性问题。Playwright由微软于2020年推出，采用了更现代的CDP（Chrome DevTools Protocol）和类似协议直接与浏览器引擎通信，在自动等待、网络拦截、多标签页管理等方面表现更优，且原生支持无头模式（Headless Mode，即不显示浏览器窗口的后台运行模式）。在AI Agent领域，Playwright因其更可靠的元素定位和更丰富的API接口而逐渐成为首选。代码框架的优势在于表达能力更强，可以实现复杂的条件逻辑和循环操作，但代价是单次操作的token消耗显著增加——一段Python代码的长度远超一条结构化指令。更长的操作轨迹意味着训练和轨迹生成的成本大幅上升。对于一个追求性价比的小模型实验来说，更紧凑的Browser Agent框架显然更为经济高效。

什么是浏览器执行框架（Harness）

对于不熟悉这一概念的读者，浏览器执行框架相当于连接语言模型与真实浏览器之间的"中间层"。模型输出的意图（比如点击某个按钮、输入文本）需要通过框架转化为浏览器的实际操作，同时框架也负责把网页状态反馈给模型。具体来说，框架需要处理几个关键环节：将网页DOM结构或截图转化为模型能理解的文本/视觉输入、解析模型输出的动作指令、通过自动化工具执行操作、处理页面加载和状态变化的等待逻辑，以及错误恢复机制。

其中，将网页信息转化为语言模型能理解的格式，是框架设计中最核心的技术挑战之一。网页的DOM（Document Object Model，文档对象模型）是一个树形结构，完整的DOM可能包含数千个节点，直接将其序列化为文本往往会超出模型的上下文窗口。因此，框架通常采用多种压缩策略：可访问性树（Accessibility Tree）提取——仅保留具有交互意义的元素及其语义标签；视觉标注（Set-of-Marks）——在网页截图上为可交互元素添加数字标记，让多模态模型通过视觉理解页面布局；或者混合方案，同时提供精简的文本DOM和标注后的截图。不同的信息表示方式对模型的要求不同：纯文本DOM适合语言模型但丢失了空间布局信息，截图保留了视觉信息但需要多模态能力。对于4B参数的小模型，选择信息密度高、token消耗少的表示方式尤为关键。

框架的设计质量，往往直接决定了同一个模型在浏览任务上的表现上限。一个设计优秀的框架能够有效减少模型需要处理的信息量，降低决策复杂度，从而让能力较弱的小模型也能完成看似困难的任务。

基准测试结果解读

实验的量化结果颇具说服力，分别在两个基准上进行了验证：

• BrowseWebApp Bench：这个基准测试的是更复杂但定义明确的Web应用工作流，而非开放式的网络研究。微调后模型的准确率从22%跃升至63%，提升接近三倍。
• BU Bench V1：这是一个更为均衡的Browser Use基准测试。微调后准确率从15%提升至53%。

在AI Agent领域，基准测试的设计至关重要，因为不同基准侧重的能力维度差异很大。WebArena、MiniWoB++、Mind2Web等是该领域的早期代表性基准。WebArena是卡内基梅隆大学于2023年推出的基准，它部署了Reddit、GitLab、电商网站等真实Web应用的自托管副本，要求Agent完成如"在GitLab上创建一个issue并分配给某人"这样的端到端任务，强调在真实复杂环境中的操作能力。MiniWoB++则源自OpenAI早期的研究，包含100多个简化的网页交互任务（如拖拽元素、选择日期等），每个任务的网页环境都是人工构造的小型页面，主要测试基础的网页操作能力。Mind2Web由俄亥俄州立大学提出，使用了真实网站的快照，重点评估模型在从未见过的网站上泛化执行任务的能力。这三者代表了从简单到复杂、从受控到真实的基准设计谱系。BrowseWebApp Bench聚焦于定义明确的Web应用操作流程（如SaaS工具的自动化操作），而BU Bench则更均衡地覆盖了Browser Use场景下的多样化任务。理解基准的设计偏向，对于正确解读实验结果非常关键——本实验中小模型的出色表现，很大程度上得益于目标基准侧重程序化任务而非开放式推理。

更令人惊讶的是，在BU Bench V1上，这个仅4B参数的SFT模型甚至超越了DeepSeek V4 Pro和Kimi K2.6在开源Browser Use框架下报告的45%成绩。也就是说，一个经过针对性微调的小模型，在特定任务域内可以战胜通用的大模型。这再次印证了"没有最好的模型，只有最适合特定任务的模型"这一实践法则。

这意味着什么

任务专精 vs 通用能力

这个实验最大的价值在于印证了一个日益重要的趋势：在明确定义的垂直任务上，经过针对性微调的小模型可以媲美甚至超越大模型。这不仅仅是成本问题——4B模型可以在消费级硬件上运行，推理延迟低、部署灵活，非常适合需要大规模、高频率执行的自动化场景。

对于企业而言，这意味着不必为每个浏览器自动化流程都调用昂贵的旗舰模型API。将常见的、程序化的工作流交给微调后的小模型处理，把复杂推理任务留给大模型，是一种更合理的资源分配策略。这种"分层调度"的架构设计正在成为AI应用落地的主流范式：前端部署轻量级专用模型处理高频简单任务，后端保留大模型处理长尾复杂请求，既控制了整体成本，又保证了用户体验。在工业界，这种分层调度（Tiered Dispatch）架构已有不少成功案例。例如，在客服场景中，简单的FAQ查询由小模型或检索系统直接处理，涉及退款计算、合同条款解释等复杂问题才路由至大模型。技术实现上通常包含一个路由层（Router），它可以是基于规则的分类器，也可以是一个轻量级的意图识别模型，负责判断当前请求的复杂度并分配给对应层级的模型。在浏览器自动化场景中，路由决策可以基于任务模板匹配（如"填写表单"直接走小模型）、历史成功率统计、或实时的置信度检测（小模型给出低置信度的回答时自动升级到大模型）。这种架构的挑战在于路由决策本身的准确性——误判可能导致简单任务浪费大模型资源，或复杂任务在小模型上反复失败。

大模型仍有不可替代性

作者也保持了应有的清醒。他明确指出，要达到SOTA（State-of-the-Art，业界最佳）性能，仍然需要将更强的模型与Browser Agent或BrowserCode这样的框架配对使用。小模型的优势在于"够用且高效"，而非全面碾压。对于需要开放式研究、跨页面深度推理的复杂任务——例如在多个网站间比较信息、理解复杂的网页交互逻辑、处理从未见过的网站布局等，大模型的综合能力依然不可或缺。这些场景需要模型具备强大的泛化能力、长上下文理解和多步推理能力，这恰恰是小模型即使经过微调也难以企及的领域。

对开发者的启示

这项工作为想要构建浏览器自动化系统的开发者提供了清晰的实践路径：

1. 先评估任务性质：如果你的工作流是高度程序化、可精确定义的，那么小模型微调很可能是更优选择。
2. 利用强模型生成训练数据：用GPT-5.6 Luna这类强基线模型生成高质量轨迹，再蒸馏到小模型，是一条经过验证的低成本路径。值得注意的是，3000条轨迹这个数据规模并不算大，这说明在任务分布较为集中的场景下，小规模高质量数据就能带来显著的性能提升。这一现象在NLP领域被称为"数据效率"（Data Efficiency），其背后的原理是：当任务空间较为有限时，少量但高度代表性的样本就能覆盖大部分操作模式，模型无需从海量数据中学习泛化能力，而只需掌握有限的操作模板和决策规则。
3. 重视框架选择：框架的设计会显著影响训练成本和最终表现，需要在性能与成本之间权衡。

作者还开源了相关资源，包括微调后的Qwen3.5-4B Browser Agent SFT FP8模型、Browser Agent框架，以及BrowseWebApp Bench和BU Bench V1两个基准测试。其中FP8（8-bit Floating Point）是一种专为深度学习推理加速设计的低精度数值表示格式，由NVIDIA在Hopper架构（H100 GPU）中首次引入硬件原生支持，随后在Ada Lovelace架构（RTX 40系列）中也得到支持。FP8有两种变体：E4M3（4位指数+3位尾数，适合前向推理，数值范围较小但精度相对较高）和E5M2（5位指数+2位尾数，适合梯度计算，数值范围更大但精度较低）。相比传统的FP16，FP8可以将模型内存占用降低一半——一个4B参数模型从约8GB降至约4GB——同时在支持FP8的硬件上利用GPU的Tensor Core进行更高吞吐的矩阵运算，推理速度通常可以提升40%-80%。对于需要实时响应的浏览器自动化任务，这种加速意味着Agent可以更快地做出决策，减少每个操作步骤的等待时间，从而提升整体工作流的执行效率。作者直接提供FP8版本，意味着开发者可以以极低的资源消耗运行该模型，进一步降低了部署门槛。这些开源资源为社区的复现和进一步研究提供了坚实基础。

结语

从22%到63%，这个数字背后传递的信息很清晰：在AI应用落地的浪潮中，"更大"并不总是答案。针对具体任务场景，用合适的数据和框架去微调一个小模型，往往能在成本、速度和效果之间取得更好的平衡。随着开源工具链的成熟，这种"小而专"的路线，可能会成为越来越多实际自动化项目的首选方案。