WebArena这个榜单最近大半年热度一直很高。但说实话真正能在上面稳定做出成绩的多模态Web Agent并不多。原因很简单模型不仅要看懂页面截图还得能把看图说话的能力落到一连串精准的浏览器操作上这个跨度非常大很多方案都在这里栽了跟头。我近期完整复现并深入研究了一套登顶这个榜单的多模态Web Agent方案代号OpAgent这里把整个思路、实现细节、训练经验以及我踩过的坑系统整理出来。这套方案适合正在做智能体落地、浏览器自动化、多模态大模型应用的同学参考尤其是那些已经试过通用模型直接操作浏览器、但发现效果不稳定的团队。下面内容不堆概念全部围绕到底怎么让模型在真实网页上稳定完成任务展开。1. 先搞懂WebArena到底在考什么1.1 WebArena是什么为什么它能成为行业标尺WebArena是一个模拟真实互联网环境的自动化评估基准。它自己搭了五个独立的站点环境电商、论坛讨论、git代码管理、CMS内容管理、以及一个多功能工具类站点。每个站点里的页面都是动态生成、可交互的任务描述则模仿真实用户需求比如在论坛中回复某位用户的问题并标记为解决方案、把git仓库里的某个分支合并后关闭对应的issue这类任务链路长、涉及多页面跳转和表单操作。它的评价标准不是模型说得对不对而是模型最终有没有把系统状态改对。比如你让Agent去修改CMS文章的分类最终检查的是这篇文章在后台数据库里的分类字段是否变成了目标值而不是模型有没有点击过那个下拉框。这种基于状态验证的设计天然就过滤掉了很多看似在操作、实则没完成的模型。因此WebArena给所有做Web Agent的团队提供了一个非常硬核的参照系。对比那些只靠静态截图问答的基准它的任务完成率含金量高得多也更能反映Agent在混乱真实页面里的鲁棒性。刚接触这个领域的同学建议直接把WebArena当成一个期末考试你的模型、数据、推理框架都得围绕它来打磨。1.2 多模态Web Agent的难点在哪多模态Web Agent的任务链路可以粗分成三层理解。第一层是视觉理解层。模型拿到页面截图得知道页面上有哪些可交互元素它们的语义是什么。这里最大的难点是真实网页长得实在太乱了广告横幅、动态推荐、通栏导航、浮层弹窗堆在一起。模型要从中分辨出哪些区域是内容区哪块是干扰项这本身就比单模态的纯HTML解析要难。第二层是任务规划层。模型要基于自然语言指令把长串任务拆解成一步步可执行的子目标。比如把商品加入购物车并完成结算这个任务可能包含搜索商品、比对价格、选择规格、加入购物车、跳到结算页、填写地址、确认下单等若干步骤。每一步都需要基于当前页面状态重新决策。第三层是动作执行层。模型不仅要决定下一步该做什么还得把这个决策落到具体的浏览器操作上包括确定点击哪个坐标、输入什么文本、滚动到什么位置。注意这一步极其依赖对页面元素位置的精准感知尤其在元素重叠、懒加载背景下差几个像素就可能点击到错误的目标。OpAgent的核心思路就是把这三层整合进一个统一的训练和推理框架里而不是像早期的方案那样用一个模型做视觉定位、另一个模型做规划再外接一堆规则把结果拼接在一起。我后面会细讲它为什么能跑通。2. OpAgent的方案选型与整体设计2.1 为什么不能用纯文本解析方案很多早期Web Agent会走纯文本路线直接把网页的DOM结构、可访问性属性比如a11y树序列化成文本喂给大模型。这种方案在SVG、链接、表单字段比较规范的页面上表现不差因为信息完整度高模型不需要猜页面上有什么。但它在WebArena里会遇到几个典型麻烦。首先是动态页面问题很多内容是在脚本执行后才出现在DOM里静态抓取会漏掉信息然后是视觉布局问题文本序列化会丢失元素的空间关系比如左侧边栏的筛选按钮和右上角的筛选按钮在语义上完全不同但纯文本模型可能看不出区别最后是跨模态一致性问题当我们要让模型去做点击时文本序列中的Aria标签和真实渲染区域未必一一对应模型经常算出应该点保存但并不知道保存按钮的实际像素坐标。我在实际测试中也发现纯文本方案在Task Success Rate上有明显瓶颈尤其是涉及地图、网格图、复杂布局的页面模型基本靠猜。所以OpAgent从一开始就定下来一条底线既然网页是给人看的Agent就应该像人一样看着页面截图来做操作只用文本提示来辅助理解。2.2 状态表示截图、DOM、历史轨迹的三层融合OpAgent在状态表示上没有简单地把截图塞给模型而是设计了三层融合状态。第一层是页面截图。模型每步决策前都会拿到当前页面的全屏截图或关键区域截图。为了保证分辨率不至于超出模型输入上限同时又能保留小字号文字信息这里会做分块编码并配合视觉定位模块输出元素级坐标。这一步的目的很简单让模型看到页面并知道每个可交互元素在像素空间中的位置。第二层是轻量DOM摘要。不是把整个DOM源码喂进去而是提取出交互候选元素比如带ID或name属性的input、带href且可见的a标签、带type的button等并按视觉位置重新排序套入一个预设模板中。模板形如当前页面包含以下可交互控件[idsearch] 搜索框位于[438, 512][idsubmit] 提交按钮位于[600, 120]。我最初觉得这一层重复但实测后发现它帮助极大它给模型提供了一种视觉感知与语言指令对齐的锚点。第三层是历史动作轨迹。把所有已执行动作的摘要按时间顺序拼到上下文里例如第3步点击了搜索框输入keywordwireless charger第4步按Enter确认搜索。这一步需要管理上下文长度通常只保留最近10步太长的任务可以做压缩摘要也可以分段推理。目的就是避免模型失忆。三层信息最终拼成一个提示模板输入模型。训练阶段模型学会在给定当前状态、任务指令时输出下一个动作推理阶段这个状态每执行一步就刷新一次。2.3 动作空间设计分类、参数、目标三件套模型输出不能是自由文本否则很难稳定落地成浏览器操作。OpAgent把动作定义成结构化三元组动作类型、动作参数、目标元素定位。动作类型一共几种全部围绕浏览器真实操作来设计click、input_text、press_key、scroll、select_option、hover、goto_url、wait、stop。没有搞幻想类操作比如什么fill form by intent之类凡是可能产生歧义的动作我一律去掉宁可多Step几次也要保证每个动作可解释。参数部分取决于动作类型。input_text需要携带文本值press_key要携带按键名select_option要带下拉选项的索引或valuegoto_url要带完整URL。这些参数让模型不再需要隐式猜测。目标元素定位是这套动作空间的重头戏。OpAgent用了联合方式先输出候选元素在DOM摘要中的引用ID再输出该元素在截图中的预测中心坐标。引用ID保证语义准确坐标保证视觉点击可靠。模型被强制同时预测两者且训练时的损失函数会把ID分类错误和坐标回归错误分开计算只有两者都对了才算预测对。为什么不只用一种定位方式我后面在实验里遇到过有些按钮没有稳定的DOM属性ID经常是动态生成的每次刷新都变靠ID就废了反过来有些按钮在视觉上非常相似坐标又不足以区分。把两者绑在一起后两者互为兜底成功率明显提升。这也换来一个好处即使未来部署到别的网站只要它的DOM结构和视觉布局差异不大Agent就能直接迁移而不用重新训练。3. 训练范式与关键模块实现3.1 行为克隆用专家轨迹做第一轮对齐训练OpAgent的第一步是用高质量专家轨迹做行为克隆。轨迹样本来自两个渠道一个是在WebArena内置任务里用规则型操作器配合人工校验跑出来的成功轨迹另一个是人工标注员按思考过程动作序列方式记录的操作日志。每条样本都包含上述三层状态表示、当前任务描述、以及动作三元组标签。这里有一个容易被忽略的细节专家轨迹本身也是动作序列所以第二步训练时模型不仅要学当前状态下执行什么动作还要学前几步动作是如何影响后续决策的。具体做法是在训练时把整条轨迹的前缀作为输入上下文动作标签作为输出采用teacher-forcing的方式做交叉熵训练。为了让模型学到上一步错了也要能恢复的鲁棒性我在训练数据里又混入了一部分从错误状态抢救回来的轨迹让模型见过更多的失败恢复路径。但纯行为克隆的问题也很明显数据分布固定模型在推理时一旦遇到未见过的页面布局或分支状态容易连续犯错。所以OpAgent至少在WebArena的排行榜结果出来后还要做一轮迭代细化我观察到很多高分模型其实是在轨迹多样性上下了很大功夫并不是网络结构本身有多玄学。3.2 空间感知训练让模型真的懂这里在哪里如果模型不能稳定输出目标坐标后面所有环节都会崩。因此OpAgent专门设计了空间感知预训练任务作为视觉编码器与动作输出头之间的桥梁。训练思路是阶段一在通用网页截图数据集上做元素检测预训练。给每张截图上标注出所有可交互元素的位置模型要同时完成元素分类和中心点预测。阶段二把检测输出接入动作解码器并冻结视觉主干只更新定位头和动作头。阶段三才进入完整轨迹级别的行为克隆微调。我在复现时对阶段一印象最深数据集的构造非常关键。不能只用合成页面因为合成页面元素太规整模型学不到真实网页里的元素重叠、文字遮挡、动效干扰。我的做法是抓取几千个公开网站的首页和列表页用DOM自带的boundingRect和元素可见性过滤自动生成元素检测标注。虽然有一定噪声但数量级上去了模型对真实网页布局的感知能力明显改善。一个值得记录的参数是坐标输出头不要直接回归绝对像素值而是先做归一化把中心点坐标除以截图宽高变成[0,1]区间的相对坐标。这样无论截图分辨率怎么变模型输出的坐标都能映射回原图。我在项目里吃过亏早期直接回归绝对像素测试时换一个浏览器窗口大小命中率直接掉了一截。3.3 反馈信号融合从失败中学习WebArena的评估会返回每个任务的最终状态但这个反馈很稀疏要么全对要么全错中间过程缺乏细粒度指导。OpAgent巧妙的一点是训练时把WebArena的最终状态Check和中间元素高亮信息都整理成了过程信号。具体来说在每轮动作执行后测评脚本会检查当前页面是否出现了异常状态比如报错提示、404页面、空结果列表。把这些状态做成负标签配合轨迹里的后续成功恢复动作构成对比样本。训练时模型被要求不仅预测下一动作还要预测当前页面是否存在异常这个二分类标签。这个辅助头的价值在长任务里体现得很明显。没有这个头时模型一旦操作失误会傻乎乎地在一个错误页面上重复点击加上之后模型对页面状态的敏感度高了很多至少能自我察觉这里不对了换个路径。从消融实验看这个辅助任务给最终任务成功率带来了约4到6个点的提升在WebArena这种硬基准上这已经是很可观的涨幅了。4. 端到端实操从数据准备到模型部署4.1 搭建最小可用训练环境先给出一份我验证过的基础环境清单按项目跑通的最低配置来列训练机8卡GPU单卡显存建议40GB起步多模态视觉主干部分的批次大小受显存影响较大推理机单卡GPU即可但显存太小会限制截图像素和上下文长度依赖库PyTorch训练框架、浏览器自动化控制库、以及一套自研的DOM摘要提取脚本数据集WebArena官方任务的专家轨迹约几万条加上自采网页截图数据集约20万张这里我想强调一下不要一上来就追求大模型。OpAgent的视觉主干和语言解码器虽然都选用了较强的多模态底座但在训练初期完全可以先用参数量小一档的模型把数据处理、动作空间、评估链路打通。基础设施没问题了再换大模型刷指标。我见过太多团队一上来就启动大规模训练最后卡在数据格式错误上面折腾两周。4.2 数据预处理流程数据预处理是整个复现过程中最耗时、也最决定成败的环节。第一步浏览器自动化采集。对每个WebArena任务先加载初始URL截取整页截图同时执行脚本提取可交互元素的DOM属性tag、id、class、type、value、name以及元素的boundingRect坐标。注意这里有个坑不能直接信任DOM里的坐标因为页面可能有iframe、嵌套滚动容器、以及CSS变换。一定要调用浏览器API做坐标转换把每个元素坐标统一到顶层视口坐标系里否则后续坐标回归训练的标签就是错的。第二步序列化状态。把提取到的元素列表按视觉位置排序组装成前面说的DOM摘要模板。模板中每个元素分配一个稳定IDID由索引前缀标签名第几项组成比如[L3_btn_2]。这样既避免了真实DOM ID不稳定同时又能让模型有稳定的引用对象。第三步动作对齐。把专家轨迹里记录的每次点击或输入操作反查到对应元素上生成动作三元组标签。这一步骤一定要做自动化和人工抽检双重校验因为轨迹文件里记录的坐标如果和下一条轨迹的状态截图不完全对应训练数据里就会出现负样本。第四步采样策略。轨迹条数不能平均分布。长任务超过10步的轨迹在训练集里需要过采样否则模型被短任务主导长链路推理能力会偏弱。我实际设定的比例大约是长度5步以内的轨迹占40%5到10步占35%10步以上的占25%。4.3 训练与评估的循环节奏训练过程大体按三阶段推进我把它当作一个周期循环先在通用截图数据上做空间感知预训练再用WebArena成功轨迹做行为克隆微调最后在WebArena全量任务上做评估。评估不是等全部训练结束才做而是每完成一个epoch就在验证集抽500条任务跑一轮快速评估。这很重要因为行为克隆的损失值下降并不直接等价于任务成功率上升。我见过损失降到很低但任务成功率不动的阶段原因是模型开始过度拟合训练轨迹的文本分布而对视觉状态变化不敏感。快速评估能尽早暴露这个问题这时我会停止微调调高空间感知模块的学习率让模型重新注意页面截图。另一个细节是推理采样的策略。OpAgent虽然动作是结构化的但解码器在生成动作参数时仍然存在不确定性。我采用自采样加打分过滤的方式每一步让模型生成K个候选动作用训练好的异常状态分类头给候选动作对应的新页面状态打分只执行得分最高的那一个。这个方案相比贪心解码在长任务上的成功率提升很明显代价是推理耗时增加但WebArena这类离线评估场景完全能接受。4.4 推理阶段浏览器执行要点模型推理输出的动作三元组最终要通过浏览器自动化库落到真实页面上。这里有几个实战要点值得单独拿出来说。点击动作的执行必须处理元素遮挡问题。浏览器自动化库默认会寻找元素并点击其可见中心点如果该点被弹层盖住点击会落到弹层上。OpAgent在动作执行层加了一道检测执行前先检查目标元素与顶层页面上其他元素的矩形重叠关系若重叠面积超过阈值的30%就先用press_key的Escape关闭弹层或改为滚动到元素再点击。这个小机制让我的任务成功率涨了大概3%。输入动作的执行优先使用浏览器原生事件而不是剪贴板注入。直接注入剪贴板在遇到一些带快捷键冲突的页面时会触发意外行为而原生input事件能更好地适配富文本编辑器。页面跳转和等待不要硬编码sleep。WebArena的页面加载耗时波动很大有的资源加载两秒有的要八秒。我的做法是轮询等待页面关键元素出现超时再抛异常这样既稳又快。5. 常见问题与排查技巧实录5.1 模型老点在奇怪的位置怎么办症状是模型决策正确但点击坐标偏到元素边缘导致点击无效。我先怀疑坐标标签精度后来发现是数据预处理的坐标系转换遗漏了页面缩放因子。排查步骤很标准取一条训练轨迹把样本里的DOM boundingRect、截图、模型输出坐标三者叠加在一起可视化一眼就能看出标签是否错位。检查后发现在采集器中若设置了窗口尺寸而DOM坐标是按CSS像素返回的截图分辨率又是物理像素两者之间存在devicePixelRatio倍数差。统一换算后再训练命中率立刻回升。5.2 长任务总在中段失败怎么定位长任务失败最头疼因为你不知道它是从第几步开始滑出正轨的。我的排查方法是给推理阶段加一个步级别录屏每一步动作执行后都记录页面状态、当前任务描述、模型输出的置信度、以及动作是否被浏览器自动修正。任务结束后人只需要回看视频和日志基本能定位是哪一步出了问题。统计下来大部分长任务失败案例集中在两个位置一是页面跳转后模型还在用旧状态做决策二是上一步操作导致的页面状态变化没有被及时反馈到上下文里。前者通过在每步执行后强制刷新上下文解决后者通过增加动作结果摘要字段解决。5.3 列表页和下拉框处理总出错WebArena里有大量列表页筛选和下拉选择操作。模型经常把select_option误预测成click然后去点击下拉框然后在下拉列表出现后又不知道怎么选。我的对策是在DOM摘要里对select元素专门做标记附带上所有option的value和索引。同时在提示模板里加一条规则当目标是下拉选择时优先使用select_option动作不要先点击下拉框再选择列表项。这种规则型提示在训练里并不能直接注入但推理时可以动态拼接进去效果立竿见影。5.4 训练时损失下降但评估不涨这个问题我在很多项目里都遇到过根本不是模型容量不够而是训练数据存在系统性偏差。比如专家轨迹里的成功路径总是同一套路模型学到的是背答案而不是理解状态。我后来强制把数据集里的轨迹做去重和多样性增强具体操作每天重新做一批随机探索轨迹保留那些中间状态分布差异大的成功样本对失败轨迹也保留一部分并用辅助分类器标注失败原因让模型见过更多负向状态。经过这一轮清洗后评估指标终于和损失保持同步上升。6. 最后的实战体会OpAgent这套方案最让我受益的反而不是某一个模块的设计而是它对状态感知的极度重视。做Web Agent模型推理能力再强如果看不见页面、点不准位置一切都是空中楼阁。多模态的输入形式天然有优势但优势要变成胜势必须靠数据、状态表示、动作空间和评估闭环同时发力。如果你接下来也想挑战WebArena这类基准我给三条建议。第一把大部分时间花在数据清洗和状态管理上不要急于换更大的模型。第二动作空间宁可收敛也不要发散结构化的确定性远比自由度重要。第三每轮训练都做评估可视化用录屏和日志直接观察模型行为效率远高于只盯训练损失曲线。顺带分享一个我踩过的小坑WebArena的测评环境比较严苛缓存和登录状态会影响任务初始条件导致同一模型两次评估结果差异很大。跑分对比时务必固定浏览器profile、清理缓存并统一任务初始化顺序否则你的消融实验根本不可信。我自己把这套方案做完之后最大的感受是多模态Web Agent这条路上工程和数据的权重远远超过模型结构上的花活。理解了这一点再去复现任何顶榜方案你都能跟上节奏。