OpenWebRL：面向视觉网页智能体的在线多轮强化学习开源框架
OpenWebRL: Demystifying Online Multi-turn Reinforcement Learning for Visual Web Agents
OpenWebRL是一个用于在真实网站上通过在线多轮强化学习训练视觉网页智能体的开源框架，覆盖了完整的训练流程。基于该框架训练的OpenWebRL-4B模型，在仅使用0.4K条监督初始化轨迹和2.2K个开放式RL训练任务的情况下，在Online-Mind2Web基准上达到67.0%成功率，在DeepShop基准上达到64.0%，超越了同规模或更大规模的先前开源智能体，性能可与OpenAI CUA和Gemini CUA等闭源系统竞争。该工作为构建更强、可复现且高性价比的开源网页智能体提供了实践路径。
做 Web Agent 的同行终于不用再羡慕闭源了。OpenWebRL 用 4B 模型和 2.2K RL 任务就逼近 OpenAI CUA，而且全开源，这路子值得认真读一读。
构建具备能力的视觉网络智能体需要长程推理、精确定位以及与动态真实网站进行稳健交互。尽管进展迅速，但最强大的系统在很大程度上仍属专有，而开源智能体依然严重依赖于在大量精心策划的网络轨迹数据上进行监督式后训练。这种依赖性造成了重大的可扩展性瓶颈：高质量的示范数据收集成本高昂，且静态数据集对多样化、不断变化的开放网络的覆盖范围有限。尽管在线强化学习（RL）在基于文本的智能体方面已展现出潜力，但其在真实网站上直接训练视觉网络智能体的潜力在很大程度上仍未得到充分探索。在本文中，我们介绍了 OpenWebRL，这是一个用于在真实网站上通过在线多轮强化学习训练视觉网络智能体的开放框架。OpenWebRL 涵盖了完整的训练流程，包括可扩展的实时浏览器基础设施、监督式初始化、多模态上下文管理、轨迹级成功判定以及高效的多轮策略优化。利用该框架，我们训练了 OpenWebRL-4B，它在具有挑战性的实时网络基准测试上树立了新的开源最优水平。仅使用 0.4K 条初始化轨迹和 2.2K 个开放式强化学习训练任务，OpenWebRL-4B 在 Online-Mind2Web 上达到了 67.0% 的成功率，在 DeepShop 上达到了 64.0% 的成功率，优于先前相似或更大规模的开源智能体，并与包括 OpenAI CUA 和 Gemini CUA 在内的专有系统保持竞争力。除了强大的基准测试性能外，我们还系统性地研究了使在线强化学习对视觉网络智能体有效的关键设计选择，并分析了强化学习如何改进智能体推理。总体而言，我们的工作为构建更强大、可复现且更具成本效益的开源网络智能体提供了一条实用路径。我们将发布我们的训练数据、模型和代码以支持未来的研究。
OpenWebRL：揭秘视觉网络智能体的在线多轮强化学习
杨睿
吴倩慧
陈宇曦
白浩
姚文琳
程浩
彭宝林
张欢
张潼
高剑锋
![[Uncaptioned image]](/api/img-proxy?u=https%3A%2F%2Farxiv.org%2Fhtml%2F2606.02031v2%2Fx1.png&mode=full&exp=1790899200&sig=54467139c6f97151){kind=small}
伊利诺伊大学厄巴纳-香槟分校，
微软
1 引言
由大型视觉语言模型（VLM）驱动的网页智能体 achiam2023gpt; bai2025qwen3; team2025kimi; singh2025openai; wang2025uitars2 在现实浏览器任务中取得了快速进展，包括产品搜索、信息提取和多步骤导航 deng2023mind2web; he2024webvoyager; he2025openwebvoyager; xue2025an; zheng2025deepresearcher; xu2024aguvis; gou2024navigating; liu2025scalecua。然而，最强的开源智能体在长程规划和对动态网站的适应能力上仍落后于专有系统。与此同时，专有模型、封闭的训练数据和流程，以及昂贵的基于 API 的评估，为开放研究设置了巨大障碍。因此，封闭系统所能达到的水平与开放研究社区能够研究、复现并在此基础上构建的成果之间，差距正在不断扩大。
一个核心瓶颈在于缺乏可扩展的数据与训练框架。目前领先的开源智能体，如 MolmoWeb gupta2026molmoweb，依赖对数十万条精心整理的轨迹进行监督式后训练（例如 27.8 万条轨迹），这些轨迹不仅收集成本高昂，且本质上受限于静态覆盖范围 fara7b2025; gupta2026molmoweb; he2025webstar。在线强化学习提供了一种原则性替代方案：智能体无需模仿固定的演示数据，而是通过与真实网站交互并从任务结果中学习来提升自身能力。然而，将在线强化学习应用于开放网络上的视觉智能体会带来一系列挑战，这些挑战与受控环境中的情况截然不同：网页是动态且非平稳的，实时浏览器交互缓慢且脆弱，而开放式任务往往缺乏可靠的基于规则的验证。以往的强化学习研究大多回避了这些挑战，主要聚焦于模拟或自托管环境中的纯文本智能体 wang2025ragen; zhang2025agentrl; wei2025webagent。最接近在真实网站上开展的工作，例如 PAE zhou2024pae 和 WebGym bai2026webgym，其强化学习框架仍然有限，并且依赖成本高昂的专有评估。更广泛地说，使在线强化学习对视觉网络智能体有效的设计选择仍有待深入探索。
我们推出 OpenWebRL，这是一个完全开源的框架，用于通过与真实网站的直接交互来训练视觉网络智能体。OpenWebRL 并未将在线强化学习视为一个黑箱方案，而是揭示并系统性地研究了有效开放网络学习背后的关键因素。该框架构建于一个稳健的浏览器基础设施之上，用于大规模并行轨迹收集，并由三个部分组成：(1) 仅使用 0.4K 条轨迹进行监督式热启动，使策略在在线训练前进入高效的探索状态；(2) 一个智能体工具集，具备多工具动作执行、文本环境反馈以及多模态上下文管理功能，使在线智能体强化学习更高效、更可靠；(3) 一个多模态多轮 GRPO 目标函数，结合轨迹级评判，使用基于 GPT 的评判器或经过蒸馏的 8B 评判器，在匹配专有系统性能的同时，将每次实验的评估成本降低约 545.5 美元。基于此框架构建的 OpenWebRL-4B，在三个具有挑战性的真实网络基准测试中，在所有开源视觉网络智能体中达到了最先进的水平。仅凭 4B 的骨干网络、0.4K 条热启动轨迹和 2.2K 个开放网络强化学习训练任务，OpenWebRL-4B 在 WebVoyager 上达到了 74.1% 的成功率，在 Online-Mind2Web 上达到 67.0%，在 DeepShop 上达到 64.0%。这些结果大幅超越了之前的开源智能体，包括 FARA-7B、MolmoWeb-8B，甚至在评估基准上超越了 Qwen3-VL-235B-A22B-Thinking，同时与多个专有系统（如 GPT-5、OpenAI CUA 和 Gemini CUA）相比也具备竞争力。除了基准性能之外，我们还系统性地分析了使在线强化学习对视觉网络智能体有效的关键设计选择，并研究了强化学习如何在训练过程中塑造智能体的推理能力。
我们的贡献体现在三个方面。首先，我们推出了 OpenWebRL，这是一个完全开源的框架，用于在真实网站上对视觉网页智能体进行端到端的在线强化学习。其次，我们开发了一套实用的多模态多轮强化学习方案，该方案结合了稳健的浏览器基础设施、轨迹级别的评判以及高效的上下文管理，使得在开放网页上进行训练对紧凑型模型同样有效。第三，我们发布了一个强大的 4B 规模的开源智能体，并附带了关于使在线强化学习成功应用于视觉网页交互的各项要素的详细实证研究。我们希望 OpenWebRL 能够为未来关于能力强、可复现且成本效益高的开源网页智能体的研究提供一个实用的基础。
| 论文 | 方法 | 观测方式 | 训练环境 | 奖励 | 权重 | 数据 | 代码 |
| WebRL qi2024webrl | 在线课程强化学习 | 文本 | 自托管网页 | 训练过的评判器 | ✓ | ✓ | ✓ |
| AgentRL zhang2025agentrl | SFT+GRPO | 文本 | 模拟网页 | 基于规则 | ✗ | ✓ | ✓ |
| PAE zhou2024pae | 在线过滤行为克隆 | 多模态 | 开放网页 | 提示词驱动的评判器 | ✓ | ✓ | ✓ |
| RAGEN wang2025ragen | StarPO | 文本 | 模拟网页 | 基于规则 | ✗ | ✓ | ✓ |
| WebAgent-R1 wei2025webagent | SFT+多轮 GRPO | 文本 | 自托管网页 | 基于规则 | ✗ | ✓ | ✓ |
| UI-TARS-2 wang2025uitars2 | 多轮 PPO | 多模态 | 计算机使用沙箱 | 混合评判器 | ✗ | ✗ | ✗ |
| WebGym bai2026webgym | 在线过滤行为克隆 | 多模态 | 开放网页 | 提示词驱动的评判器 | ✗ | ✓ | ✓ |
| WebSTAR he2025webstar | 步骤过滤 SFT | 多模态 | — | 提示词驱动的评判器 | ✗ | ✓ | ✓ |
| GUI-Libra yang2026guilibra | 步骤级 GRPO | 多模态 | — | 基于规则 | ✓ | ✓ | ✓ |
| ScaleCUA liu2025scalecua | SFT | 多模态 | — | — | ✓ | ✓ | ✓ |
| Fara-7B fara7b2025 | SFT | 多模态 | — | — | ✓ | ✗ | ✗ |
| MolmoWeb gupta2026molmoweb | SFT | 多模态 | — | — | ✓ | ✓ | ✓ |
| OpenWebRL（我们的方法） | SFT + MM-GRPO | 多模态 | 开放网页 | 混合评判器 | ✓ | ✓ | ✓ |
2 相关工作
基于 LLM/VLM 的网页智能体。近期，基于 LLM/VLM 的网页智能体领域取得了进展，这主要得益于三条互补的技术路线：更强的基座模型（bai2025qwen3; team2025kimi; chen2024internvl; yang2025magma; hong2025glm）、智能体框架（gu2024your; yang2025agentoccam; wang2026webxskill），以及针对网页或图形用户界面的特定后训练（xu2024aguvis; qin2025ui; cheng2024seeclick; wu2024atlas; wu2025gui; wang2025uitars2; gou2024navigating; chae2025web; zhuang2026workforceagent）。更近期的系统通过精心策划的演示数据、合成数据以及针对真实浏览器交互场景定制的监督微调，进一步增强了智能体的能力（liu2025scalecua; fara7b2025; gupta2026molmoweb; he2025webstar）。与此同时，评估方式也已从精心策划的静态网页基准，扩展到更加多样化和真实的开放网络环境（pan2024webcanvas; he2024webvoyager; xue2025an; lyu2025deepshop; trabucco2025insta; hong2026embodied; yu2026visual; chen2026captcha; bai2026webgym）。
面向多模态智能体的强化学习。将 VLM 作为智能体部署在视觉化环境中，需要从静态理解转向长程决策（yang2025embodiedbench; wang2026vagen）。为弥合这一差距，近期研究采用了先 SFT 后 RL 的两阶段范式（chen2025era; zhai2024finetuninglargevisionlanguagemodels; zhan2025visual）。基于结果的强化学习在语言推理领域的成功（guo2025deepseek），激发了将 RLVR 扩展到 VLM 和交互式智能体的日益增长的努力。早期工作将该范式应用于感知、定位和视觉问答等静态任务（liu2025visual; huang2025vision; shen2025vlm; wang2025vl; lu2026ui; luo2025gui; yang2026guilibra），而近期的方法则针对多轮交互和智能体场景（qi2024webrl; zhou2024pae; bai2024digirl; bai2026webgym; wang2025ragen; zhang2025agentrl; wei2025webagent; wang2025uitars2）。然而，这些工作大多在模拟、自托管或范围狭窄的环境中进行。相比之下，我们研究的是在真实网站上训练和评估的紧凑型视觉网页智能体的完全开放在线强化学习。
3 预备知识
问题形式化。我们将多模态网络智能体的训练形式化为一个部分可观测马尔可夫决策过程（POMDP）。每个任务指定一个起始 URL 和指令。在步骤 t，智能体观察到 o_t，其中 o_t^text 包含文本形式的浏览器信息（URL、标签页信息、环境反馈），而 o_t^image 是一张截图。给定交互历史 h_t，策略 π 生成一个包含推理过程和结构化浏览器动作的响应 a_t，之后环境转移到 s_{t+1} 并产生 o_{t+1}。当智能体调用完成（done）、步骤预算耗尽或发生环境故障时，一个回合终止。任务成功与否仅在完整交互结束后通过基于规则的检查或评判模型进行评估。
多轮 GRPO。GRPO（Shao et al., 2024, DeepSeekMath）是一种无评论家的策略优化方法，它用群体相对优势替代了学习到的价值函数。在多轮设置中，采样的单元是整个轨迹而非单个响应。对于每个任务，策略采样一组轨迹 {τ_1, τ_2, ..., τ_G}，其中每条轨迹 τ_i 获得一个轨迹级别的奖励 R(τ_i)。群体相对优势为 A_i = (R(τ_i) - mean({R(τ_j)})) / std({R(τ_j)})。多轮 GRPO（Wei et al., 2025, WebAgent）将此轨迹级别的信号传播到轨迹 τ_i 中所有轮次生成的动作 token 上。用 a_{i,t,k} 表示轨迹 τ_i 在第 t 轮响应中的第 k 个 token，优化目标变为：
其中 ρ_{i,t,k} = π_θ(a_{i,t,k} | h_{i,t}) / π_θ_old(a_{i,t,k} | h_{i,t}) 是第 t 轮的 token 级别重要性比率。
4 OpenWebRL：面向视觉网络智能体的在线强化学习训练框架
我们采用端到端在线强化学习流程，在开放网络上训练多模态网络智能体，起点是一个通用视觉语言模型。我们的目标不仅是提升视觉网络智能体的性能，还要系统性地研究在线强化学习在开放网络导航中的关键组成部分。由于在线强化学习计算成本高昂，我们将主要实验聚焦于小型视觉语言模型，例如 Qwen3-VL-4B（bai2025qwen3）。然而，通用型小型视觉语言模型往往缺乏在动态浏览器环境中运行所需的网络特定知识。因此，我们使用一个更强的开源模型收集少量轨迹数据，通过监督微调对策略进行热启动。从监督微调策略出发，我们在实时浏览器环境中迭代收集在线轨迹，并使用分组相对策略优化来更新模型。在以下小节中，我们将描述数据准备、轨迹收集系统、奖励设计和优化目标。
4.1 智能体框架
在实时网站上训练和评估网络智能体会引入大量环境噪声，包括动态页面更新、弹窗、重定向、机器人检测、拦截以及临时性网络故障。为了使开放网络的轨迹收集更加可靠，我们基于 Orchard Env（peng2026orchard）构建了一个容错浏览器环境，具备导航重试、超时处理和结构化故障归因功能，从而将不稳定的网站行为与模型行为区分开来，使故障在大规模训练过程中可诊断。为了提高效率，我们并行运行多个浏览器实例，这些实例异步采样独立的轨迹，每个实例维护自己的页面状态和交互历史。实现细节见附录 A.1。
基于环境基础设施，我们采用了一种通用的多轮 ReAct 风格工具调用智能体（yao2023react），以避免将脚手架特定效果与数据或训练方案上的差异混为一谈，更重要的是，让相同的智能体范式能够泛化到 GUI 导航之外的任何工具使用领域。在此框架内，唯一与浏览器相关的设计选择是：如何组织观测信息、智能体可以调用哪些工具，以及如何维护多步交互历史记录。
观测与环境反馈。环境提供多模态观测信息，包括当前屏幕截图、活动 URL、视口尺寸和标签页元数据。这些信号使智能体能够跨具有不同布局、动态内容和多标签工作流的异构网站追踪浏览器状态。此外，每个动作都会返回一条简洁的文本形式环境反馈消息，该消息从连续交互步骤之间的 DOM 树变化中提取。这些消息总结了执行结果和可观测的状态变化，例如页面导航成功、新标签页创建、输入文本不匹配或滚动尝试失败。这种轻量级反馈使 Web 交互更具可观测性，让智能体能够区分成功动作与静默失败或在线网站上常见的意外浏览器行为。更多细节见附录 A.2。
动作空间与多工具调用接口。该智能体配备了一个结构化的原子浏览器工具动作空间，涵盖指针管理（点击、悬停、拖拽）、键盘输入（写入、按键）、页面导航（滚动、跳转URL、后退、等待）、标签页管理（新建标签页、切换标签页、关闭标签页），以及通过`done(response)`终止——这是成功结束一个回合并输出最终面向用户回答的唯一机制。在每个步骤中，策略响应应包含一个推理块，后跟一个或多个工具调用块。环境解析这些工具调用，并依次执行相应的浏览器操作，然后返回每次调用的反馈和下一张屏幕截图。这种多工具调用接口提升了展开效率：短小的确定性交互链——例如聚焦搜索框、输入查询并按下回车键——可以在单个模型步骤内完成，从而消除了不必要的模型-环境往返，否则这些往返将主导实时网页展开。更多详情请参见表6。
上下文管理。长周期网页交互为多模态强化学习智能体带来了根本性的上下文管理挑战（huang2026rethinking）。每个展开步骤可能包含一张全页截图、文本元数据、工具调用、环境反馈以及模型推理轨迹。保留所有截图很快就会变得不切实际：即使对于64k token的模型，一个30步的轨迹也可能超出上下文预算。然而，保留每一张历史截图通常并无必要。人类用户并不会反复检查每一个之前的浏览器状态；相反，他们主要依赖最近的视觉观察，并结合对先前动作、结果和任务进展的记忆。我们采用相同的原则，将视觉定位与长期记忆分离。最近的截图被显式保留用于感知，而较早的交互历史则被压缩为文本状态信息，包括环境反馈和智能体自身的推理轨迹。
具体而言，在第 t 轮交互中，策略模型接收系统指令、任务查询、之前所有模型响应的完整序列、之前所有环境反馈字符串的完整序列，以及当前的浏览器观测信息。每条观测信息表示为 (o_t^text, o_t^image)，其中 o_t^text 包含轻量级文本元数据，如当前活动标签页、URL 和上一步反馈，而 o_t^image 则表示渲染后的屏幕截图。为了控制多模态上下文成本，我们仅保留最近的 k 张屏幕截图：(o_{t-k+1}^image, ..., o_t^image)。根据经验，仅保留当前屏幕截图 (k=1) 已能实现强劲性能，同时大幅降低训练成本（第 5.1 节）。设 a_t 为第 t 轮包含推理内容和工具调用的模型响应，则最终的策略上下文为：context_t = [system_instruction, query, (o_1^text, o_1^image), a_1, feedback_1, ..., (o_t^text, o_t^image)]。
一个关键的设计选择是：环境反馈始终被保留，即使其对应的屏幕截图已被丢弃。这些反馈字符串为浏览器操作提供了唯一明确的执行信号，指示交互是成功、失败、触发了页面跳转、打开了新标签页，还是产生了仅凭屏幕截图可能无法直观察觉的意外行为。这一点在我们多工具调用接口下尤为重要，因为单个模型步骤可能顺序执行多个浏览器操作，而后续轮次必须识别出哪些子操作成功，哪些需要恢复或重试。
与以往将历史记录压缩为简短操作摘要或可执行操作代码的 GUI 智能体方法不同，我们保留了智能体完整的历史推理轨迹作为上下文的一部分。我们发现，这些推理轨迹天然地充当了紧凑的文本记忆，捕捉了先前的视觉观测、操作意图、中间结论和任务进度，而无需将所有过去的屏幕截图保留在上下文中。
4.2 数据准备与监督微调
我们通过任务过滤、教师模型 rollout 和轨迹整理流程，基于 WebGym（bai2026webgym）构建了训练语料库。从 292K 个原始任务实例出发，我们移除了与评估基准重叠的任务、从父级意图分解出的子任务、来自长尾或不稳定网站的任务，以及近似重复的意图。为识别近似重复项，我们使用 Qwen3-Embedding-8B 对任务意图进行嵌入，并采用基于相似度的贪心去重方法，设定预定义阈值。我们使用某个阈值构建 SFT 候选池，最终得到 15,601 个经过筛选的种子任务。对于 RL 任务池，我们采用相同的过滤流程，但使用更严格的阈值以进一步降低语义冗余，最终保留约 2.2K 个覆盖多样化真实网站的任务用于强化学习。
为了获取用于监督式热启动的示范数据，我们使用第 4.1 节中描述的智能体框架，对一个强大的开源教师模型 Qwen3-VL-235B-A22B-Thinking（bai2025qwen3）进行了轨迹展开。对于每个经过筛选的种子任务，我们采样四条独立的教师轨迹，并使用 GPT-4.1 根据最终答案、交互历史和截图轨迹来判断任务是否成功。这产生了一个包含成功示范的数据池，每个任务有多次尝试，既提供了高质量的轨迹，也提供了关于任务难度和轨迹多样性的有用信号。对于 SFT，我们有意策划了一个小而高质量的子集，而不是模仿所有成功的教师轨迹。其目标是让小型模型具备足够的网页交互能力以进行有效的探索，同时避免过度模仿，以免限制后续在线 RL 的效果。默认情况下，我们从 PAE-WebVoyager 子集中选择成功的轨迹，该子集密集覆盖了流行的真实世界网站。对于每个任务组，我们保留最短的成功轨迹。当多条轨迹长度相同时，我们使用较短的总响应长度作为决胜标准。我们还限制了每个网站的任务数量，以提高领域多样性。这产生了我们默认的 SFT 数据集，包含覆盖 70 个网站的 412 条轨迹。同样的筛选规则可以应用于 InSTA-v3 子集，以构建更大的 SFT 数据集，但在实践中，我们发现 412 条轨迹的数据集已经足以对小型模型进行监督式热启动。
我们在经过筛选的轨迹上，使用多轮行为克隆来训练小型模型，例如 Qwen3-VL-4B-Thinking。每个助手轮次都被视为一个训练目标，其条件是基于序列化的交互历史，包括截图、推理轨迹、工具调用和环境反馈。遵循标准的智能体多轮训练实践，我们仅对目标助手的响应计算损失，并屏蔽历史上下文和环境观察。
4.3 奖励设计与评判模型
我们设计了奖励函数，以同时捕捉格式正确性和任务成功性，具体细节见附录 A.4。该奖励由两部分组成。（1）格式奖励。首先，格式奖励检查响应是否遵循所需的浏览器智能体协议：只有当响应包含所需的思考结束标签和成功解析的工具调用时，才能获得格式分数。（2）任务成功奖励。对于已完成的轨迹，我们使用 VLM 作为评判模型的奖励来评估任务是否成功完成。评判模型接收任务指令、最终响应、最近的截图以及轨迹历史（包括工具调用和环境反馈）作为输入。评判模型的输入和输出示例见附录 F.2。最终奖励在轨迹层面进行分配。只有当轨迹既遵循所需的响应格式又被评判为成功时，它才会获得正向奖励。如果轨迹因重复的格式错误而终止，则获得负向奖励，否则获得零奖励。这种设计鼓励智能体在优化实际任务完成度的同时，生成有效且可执行的动作。
我们在训练中使用 GPT-4.1 作为默认评判模型。然而，依赖专有评判模型成本高昂，并可能限制研究社区的可及性。在我们的实验中，一次典型的训练运行需要 43.2K 次评判 API 调用，成本约为 545.5 美元。为了降低这一成本并使流程更易于使用，我们从 12.5K 个多样化的在线 rollout 数据和 GPT-4.1 评判标签中蒸馏出一个 8B 评判模型。蒸馏后的评判模型经过训练，可以同时预测评判理由和最终的成功评估。我们在第 5.4 节中评估了所学评判模型的有效性。
4.4 多模态多轮 GRPO
由于奖励仅在轨迹层面分配，我们将 GRPO 扩展为在一次 rollout 中优化所有智能体的回复，为轨迹中的每一轮对话赋予相同的组相对优势。对于包含多轮智能体回复的轨迹，我们构建 ，其中 是受管理的多模态上下文， 是第 轮中智能体的回复。我们在 rollout 和优化过程中使用相同的上下文管理流程，并且仅对智能体回复的 token 施加损失。
对于每个任务 ，我们从当前策略中采样一组轨迹：, 。令 为轨迹层面的奖励。根据组相对策略优化，我们计算归一化的组相对优势：，其中 ， 是组内奖励的标准差。由此得到的优势值被分配给轨迹 所有轮次中的所有回复 token。我们优化裁剪后的多轮 GRPO 目标函数：
其中 是轨迹 第 轮中 token 的重要性比率， 用于屏蔽非智能体 token。请注意，我们不在轨迹层面纳入归一化因子，因为这样做会降低较长轨迹的权重，并削弱对需要更多交互步骤的困难任务的学习信号。
我们采用非对称裁剪，参数为 和 ，并采用 (yu2025dapo) 中的轨迹级动态采样策略，丢弃那些所有轨迹都获得相同奖励（例如全零或全一）的任务组。这种过滤机制去除了由环境失败或琐碎任务主导的组，同时形成了一种自然的课程学习，使优化聚焦于当前策略能够解决但尚未稳定解决的任务。我们省略了 KL 和熵正则化，以使训练信号集中在轨迹层面的奖励上。
5 实验
训练设置。我们使用 Qwen3-VL-4B-Thinking（bai2025qwen3）作为主要基础模型，以保持在线强化学习在计算上的可行性。我们首先通过 LlamaFactory（zheng2024llamafactory）对模型进行 3 个 epoch 的 SFT 热启动，得到 OpenWebRL-4B-SFT。从该 SFT 检查点出发，我们进一步在在线网页环境中应用 MM-GRPO 算法，使用第 4.2 节中描述的精选 2.2K 训练集。主要强化学习训练运行 90 次迭代，每次迭代包括在线 rollout 和随后的 MM-GRPO 更新，总共需要约 300 B200 GPU 小时。在整个训练过程中，我们收集了约 54K 条在线轨迹。由于 30 步 rollout 速度明显较慢，我们分两个阶段训练 OpenWebRL-4B：先进行 90 次迭代，每次最多 15 步 rollout，随后进行 50 次迭代，每次最多 30 步 rollout。我们还报告了使用我们蒸馏的 8B 评判模型训练的 4B 变体，以及使用相同流程训练的 8B 变体（OpenWebRL-8B）的结果。更多训练细节见附录 A.5。
评测基准。我们在三个具有挑战性的在线网页评测基准上进行评估：WebVoyager（he2024webvoyager），涵盖热门网站上的开放域导航（使用 FARA 整理的 595 任务版本（fara7b2025））；Online-Mind2Web（xue2025an），包含 136 个网站上的 300 个长周期任务；以及 DeepShop（lyu2025deepshop），专注于具有多约束产品选择的真实购物任务。我们遵循每个评测基准的标准评估协议。完整细节见附录 B。
基线模型。我们将我们的模型与专有和开源基线模型进行比较。专有基线模型包括 GPT-5、Gemini-3-Flash、o3、OpenAI CUA 和 Gemini CUA。开源基线模型包括 Holo1-7B（andreux2025surfer）、UI-TARS-1.5-7B（qin2025ui）、GLM-4.1V-9B-Thinking（hong2025glm）、FARA-7B（fara7b2025）、MolmoWeb-4B/8B（gupta2026molmoweb）、Qwen3-VL-4B-Thinking 和 Qwen3-VL-235B-A22B-Thinking（bai2025qwen3）。
评估指标。我们的主要指标是官方成功率，遵循先前工作 fara7b2025 和 gupta2026molmoweb 中使用的标准评估协议。该协议依赖于 Browser-Use Stealth Browsers111https://browser-use.com/stealth-browsers，这是一个托管的云浏览器服务，提供 CAPTCHA 验证码解决和稳定的浏览器会话，减少了在实时网络评估中因网站拦截和会话不稳定导致的失败。然而，Browser-Use 服务引入了付费的第三方依赖，这增加了评估成本，并使学术界难以精确复现。为了提高透明度，我们还报告了“排除中止任务后的成功率”——即排除因页面被拦截或浏览器会话断开等非智能体故障的任务后的成功率，从而提供在不使用 Browser-Use 服务情况下的智能体性能估计。
| 模型名称 | 步骤数 | 任务数 | WebVoyager | Online-Mind2Web | DeepShop | 平均 |
| 专有模型 | ||||||
| GPT-5 (Axtree)† | 30 | – | 70.6 | 41.9 | 40.7 | 51.1 |
| Gemini-3-flash (Axtree)† | 30 | – | 74.4 | 34.8 | 45.1 | 51.4 |
| Gemini-3-flash (Axtree)† | 100 | – | 85.6 | 44.8 | 55.3 | 61.9 |
| GPT-4o (SoM)* | 100 | – | 65.1 | 34.6 | 16.0 | 38.6 |
| o3 (SoM)* | 100 | – | 79.3 | 55.4 | 49.7 | 61.5 |
| GPT-5 (SoM)* | 100 | – | 90.6 | 57.7 | 49.1 | 65.8 |
| OpenAI computer-use-preview* | 100 | – | 70.9 | 58.3 | 24.7 | 51.3 |
| Gemini computer-use-preview† | 100 | – | 88.6 | 57.3 | 62.0 | 69.3 |
| 开源模型 | ||||||
| Holo1-7B† | 30 | 15.6k | 55.4 | – | – | – |
| UI-TARS-1.5-7B* | 100 | – | 66.4 | 31.3 | 11.6 | 36.4 |
| GLM-4.1V-9B-Thinking* | 100 | – | 66.8 | 33.9 | 32.0 | 44.2 |
| Fara-7B* | 100 | 123.2k | 73.5 | 34.1 | 26.2 | 44.6 |
| MolmoWeb-4B† | 100 | 278.5k | 75.2 | 31.3 | 35.6 | 47.4 |
| MolmoWeb-8B† | 100 | 278.5k | 78.2 | 35.3 | 42.3 | 51.9 |
| Qwen3-VL-4B-Thinking | 30 | – | 52.6 | 32.0 | 33.3 | 39.3 |
| Qwen3-VL-8B-Thinking | 30 | – | 61.3 | 38.7 | 44.0 | 48.0 |
| Qwen3-VL-235B-A22B-Thinking | 30 | – | 66.4 | 63.7 | 56.7 | 62.3 |
| 我们的模型：4B 骨干网络 | ||||||
| OpenWebRL-4B-SFT | 30 | 0.4k | 60.2 | 47.0 | 48.7 | 52.0 |
| OpenWebRL-4B | 30 | 2.2k | 74.1 | 67.0 | 64.0 | 68.4 |
| OpenWebRL-4B w/ OpenWebRL-Judge-8B | 30 | 2.2k | 68.9 | 67.3 | 68.7 | 68.3 |
| 我们的模型：8B 骨干网络 | ||||||
| OpenWebRL-8B-SFT | 30 | 0.9k | 66.2 | 54.0 | 50.0 | 56.7 |
| OpenWebRL-8B | 30 | 2.2k | 73.8 | 67.0 | 65.3 | 68.7 |
| OpenWebRL-8B | 50 | 2.2k | 74.6 | 69.7 | 63.3 | 69.2 |
5.1 主要结果
OpenWebRL 建立了开源领域的新标杆，其性能可与专有网络智能体相媲美。表 2 报告了在三个实时网络基准测试上的官方成功率。仅凭 4B 参数量的基础模型、30 步的评估预算以及比此前开源系统小得多的训练集，OpenWebRL-4B 就取得了平均成功率，大幅超越了现有开源智能体。如附录 C.1 所示，OpenWebRL-4B 在长周期基准测试（即 Online-Mind2Web 和 DeepShop）上的优势尤为显著。在这两项基准测试中，OpenWebRL-4B 分别以 和 个百分点的优势超越 FARA-7B，并以 和 个百分点的优势超越 MolmoWeb-8B。将基础模型规模扩展至 8B，在相同的 30 步评估预算下，平均成功率进一步提升至 。将评估预算增加到 50 步，OpenWebRL-8B 的平均成功率略升至 ，这表明尽管模型仅使用 30 步的 SFT 和 RL 预算进行训练，但仍能泛化至更长的交互周期。然而，50 步设置也会带来显著更高的计算成本和实际耗时，因此我们默认采用 30 步作为评估设置。值得注意的是，OpenWebRL-4B 和 OpenWebRL-8B 均与专有系统具有很强的竞争力。在 Online-Mind2Web 和 DeepShop 上，它们超越了包括 GPT-5、Gemini-3-Flash、GPT-4o、o3 以及 OpenAI/Gemini 计算机使用智能体在内的多个闭源智能体。这些结果表明，有效的在线强化学习能够显著提升用于实时网页交互的开源 VLM，使紧凑的 4B–8B 模型能够在具有挑战性的实时网络任务中与规模大得多的专有系统一较高下。
监督微调（SFT）和多模态组相对策略优化（MM-GRPO）都对最终性能提升有贡献。表2显示，监督微调为两种规模的模型提供了良好的热启动，而多模态组相对策略优化在后续的在线强化学习阶段带来了更大的改进。对于4B骨干网络，监督微调将平均成功率从[原文缺失]提升至[原文缺失]，而多模态组相对策略优化进一步将其提升至[原文缺失]，相比监督微调提升了[原文缺失]个百分点，相比基础模型提升了[原文缺失]个百分点。我们在8B骨干网络上观察到类似的趋势：监督微调将平均成功率从[原文缺失]提升至[原文缺失]，多模态组相对策略优化进一步将其提升至[原文缺失]，相比监督微调提升了[原文缺失]个百分点，相比原始骨干网络提升了[原文缺失]个百分点。所有三个基准测试上的改进是一致的，这表明监督微调提供了探索所需的交互能力，而在线强化学习是最终性能提升的关键驱动力。
5.2 多模态组相对策略优化的学习动态
监督微调初始化带来了更快、更有效的强化学习。图2比较了在Online-Mind2Web基准测试上，从基础模型（Qwen3-VL-4B-Thinking）初始化和从监督微调检查点初始化的多模态组相对策略优化训练过程。尽管两种运行最终都达到了相似的训练奖励并遵循相似的评估趋势，但监督微调初始化的运行在整个训练过程中始终保持着10%的评估成功率优势。这种差距表明，监督式热启动的作用不仅仅是加速优化：它将策略置于行为空间中更优的区域，从而实现更有效的在线探索。总体而言，多模态组相对策略优化从两种初始化方式中都产生了稳定的改进，并且监督微调初始化的策略即使在80次迭代后仍在持续提升。
SFT 初始化的优势在较难任务上尤为显著。图 2(d) 进一步按任务难度细分了性能表现。基于 SFT 检查点的 MM-GRPO 在所有难度划分上均提升了成功率，其中在困难任务上的增益最大（+22.3 个点）。相比之下，从基座模型开始的强化学习在困难任务上仅取得微小提升（+2.3 个点），其大部分增益集中在简单和中等难度划分上。综合来看，这些结果验证了从 SFT 模型热启动在线强化学习、而非直接从基座模型开始训练的有效性和必要性。
MM-GRPO 驱动的是有针对性的推理扩展，而非均匀扩展。如图 2(b) 所示，模型在 MM-GRPO 训练期间生成了更长的回复。我们进一步在图 3 中分析了回复长度的变化。有趣的是，整体轨迹长度并未增加。相反，平均交互步数从第 0 次迭代的 14.0 步减少到第 80 次迭代的 8.9 步，而平均轨迹长度和第 90 百分位轨迹长度分别从 10.9K 和 18.1K 个 token 下降到 7.9K 和 15.0K 个 token。为了更好地理解回复长度增加的来源，我们对模型在 Online-Mind2Web 上的输出应用了词汇代理检测，以识别几种步级推理模式（详见附录 D）。如图 3(b) 和 (c) 所示，MM-GRPO 提高了多种常见推理模式的出现频率和条件长度，包括历史总结、障碍诊断、重试计划推理和条件证明推理。例如，历史总结的步级出现率从 14.5% 上升到 21.4%，障碍诊断从 14.2% 上升到 23.7%。带有代理标记的步级的平均回复长度也大幅增长，历史总结从 332 个 token 增加到 542 个 token，障碍诊断从 273 个 token 增加到 440 个 token。相比之下，无代理标记的步级则稳定得多，平均仅从 282 个 token 增加到 325 个 token。这些结果表明，强化学习期间的回复长度增长并非所有回复的均匀扩展；相反，模型选择性地将额外的冗长内容和推理模式分配给了重要步骤。
5.3 测试时扩展
我们进一步研究视觉网页智能体是否能从额外的测试时计算中获益。具体来说，我们评估了 pass@k 指标，其中每个任务通过独立运行尝试，如果至少有一次运行成功，则视为任务成功。我们在各模型间保持推理设置不变，最大运行步数固定。图 4 比较了基础模型（Qwen3-VL-4B-Thinking）、OpenWebRL-4B-SFT 和 OpenWebRL-4B 在 WebVoyager、Online-Mind2Web 和 DeepShop 上的表现。结果表明，通过采样多次独立尝试，可以扩展实时网页智能体的性能。然而，OpenWebRL-4B 在所有三个基准测试中都展现出比基础模型和 SFT 模型更强的 pass@k 曲线。这表明在线强化学习不仅提升了单次运行的成功率，也提高了重复尝试发现成功轨迹的概率。值得注意的是，OpenWebRL-4B 在三个实时网页基准测试中均实现了超过 pass@4 的官方成功率，显著优于 MolmoWeb-8B（gupta2026molmoweb），后者在 Online-Mind2Web 上报告的 pass@4 成功率约为某个值。强大的 pass@k 扩展能力表明，OpenWebRL-4B 不仅学习了更准确的单个动作，还学习了更丰富的可行交互策略分布，这些策略可以通过多次测试时尝试加以利用。
5.4 OpenWebRL-Judge 评估
经过知识蒸馏的 OpenWebRL-Judge-8B 为稳定的在线强化学习提供了有效的训练信号。如表 2 所示，使用 OpenWebRL-Judge-8B 的 OpenWebRL-4B 在 Online-Mind2Web（67.3）和 DeepShop（68.7）两个基准上，均在开源智能体中取得了强劲的性能。其总体平均得分（68.3）与使用 GPT-4.1-Judge 的变体（68.4）几乎相同，尽管在强化学习训练过程中完全依赖于一个经过蒸馏的开源奖励模型，这大幅降低了与专有 API 调用相关的成本和依赖。我们进一步在图 5.4 中比较了强化学习训练动态。在 Online-Mind2Web 上，训练奖励和排除失败任务后的评估成功率均显示出稳定的优化趋势，与使用 GPT-4.1 监督获得的结果高度吻合。相比之下，使用 Qwen3-VL-8B 作为评判模型则导致了明显的奖励作弊行为（gao2023scaling; yang2024regularizing; miao2024inform），产生了更高的训练奖励，但评估成功率却显著降低。这些结果进一步证明，OpenWebRL-Judge-8B 为稳定的在线强化学习训练提供了可靠且有效的奖励信号。
| 模型 | 准确率 | 精确率 | 召回率 | F1 分数 |
| o4-mini | 76.0 | 95.2 | 61.7 | 74.9 |
| gpt-4o | 85.6 | 83.6 | 93.4 | 88.3 |
| WebJudge-7B（xue2025an） | 71.6 | 67.9 | 96.9 | 79.8 |
| Qwen3-VL-4B-Instruct | 76.8 | 75.7 | 89.0 | 81.8 |
| Qwen3-VL-8B-Instruct | 80.6 | 78.6 | 91.7 | 84.7 |
| Qwen3-VL-32B-Instruct | 85.8 | 87.4 | 88.3 | 87.8 |
| OpenWebRL-Judge-4B | 85.2 | 86.1 | 89.7 | 87.8 |
| OpenWebRL-Judge-8B | 89.8 | 89.5 | 94.8 | 92.1 |
OpenWebRL-Judge-8B 在保留轨迹评估上与 GPT-4.1 高度吻合。为了独立于 RL 训练评估评判模型，我们构建了一个包含 500 条轨迹展开的保留集，这些轨迹来自不同训练阶段，并使用 GPT-4.1 进行标注。随后，我们通过衡量多个评判模型与这些 GPT-4.1 标注的一致性来比较它们。如表 3 所示，OpenWebRL-Judge-8B 与 GPT-4.1 的对齐效果最强，达到了 89.8% 的准确率和 92.1% 的 F1 分数。它优于包括 WebJudge-7B xue2025an、Qwen3-VL-32B 和 GPT-4o 在内的强基线模型。虽然某些基线模型在精确率或召回率上表现突出，但它们的整体准确率和 F1 分数仍然较低，这表明我们蒸馏得到的评判模型在此设置下，比通用 VLM 评判模型和先前的网页专用评判模型都能更可靠地捕捉网页任务的成功信号。
| 系统 | WebVoyager | Online-Mind2Web | DeepShop |
| OpenWebRL-4B | 74.1 | 67.0 | 64.0 |
| 展开长度消融实验 | |||
| 仅使用 30 步展开的 RL | 66.7 ( -7.4) | 65.4 ( -1.6) | 63.3 ( -0.7) |
| 仅使用 15 步展开的 RL | 70.1 ( -4.0) | 65.0 ( -2.0) | 63.3 ( -0.7) |
| 仅使用 10 步展开的 RL | 70.6 ( -3.5) | 60.7 ( -6.3) | 57.3 ( -6.7) |
| 使用 15 步展开的上下文管理消融实验 | |||
| 使用最近两张截图 | 68.2 ( -1.9) | 65.3 ( +0.3) | 59.3 ( -4.0) |
| 无文本环境反馈 | 64.9 ( -5.2) | 57.0 ( -8.0) | 56.7 ( -6.6) |
| 无历史推理 | 55.5 ( -14.6) | 41.3 ( -23.7) | 54.7 ( -8.6) |
5.5 关于展开和上下文管理的消融实验
这里我们对 OpenWebRL-4B 中的关键设计选择进行了消融实验：(i) OpenWebRL-4B 中使用的 rollout 长度课程，即先以 15 步 horizon 运行在线强化学习，再继续以 30 步 horizon 运行；(ii) 三种上下文管理策略，包括文本环境反馈、历史推理以及上下文中保留的最近截图数量。为确保控制变量比较，所有变体均从相同的 SFT 检查点初始化，并使用相同的强化学习训练方案，仅改变被消融的因素。出于成本效率考虑，上下文管理消融实验仅使用 15 步 rollout 进行训练，并与“仅 15 步 rollout 的强化学习”基线进行比较。表 4 报告了结果。
Rollout 长度课程。OpenWebRL-4B 在所有固定预算的强化学习变体中表现最佳。仅使用 30 步 rollout 训练会导致在 WebVoyager、Online-Mind2Web 和 DeepShop 上分别下降 、 和 个点。仅使用 15 步 rollout 的表现优于直接以 30 步 rollout 开始，但仍比完整课程低 、 和 个点。此外，使用过短的 horizon（例如 10 步 rollout）会严重损害 Online-Mind2Web 和 DeepShop 上的性能（下降 和 个点），这两个任务都需要更长的交互 horizon 才能成功完成。这些结果表明，中等 horizon 的训练阶段有助于稳定早期探索，而更长 horizon 的 rollout 则能提升策略处理需要长时间交互的任务的能力。总体而言，结合 15 步和 30 步训练阶段比在整个训练过程中使用固定 rollout 预算更有效。
文本环境反馈提供了轻量级但信息丰富的信号。移除该反馈后，相对于 15 步 rollout 基线，强化学习性能下降了 、 和 个点。这意味着该反馈提供了关于动作执行的明确信息，而这些信息并非总能仅从截图中推断出来。没有它，策略在决定是否重试、从错误中恢复或调整策略时可靠性降低，尤其是在 Online-Mind2Web 这类 horizon 更长且更容易失败的环境中。
历史推理提供了关键的上下文信号。移除历史推理在所有消融实验中造成的性能下降最大，相对于15步展开基线，性能分别降低了、和个百分点。我们推测，这些推理轨迹可以作为高层计划、对过往观察结果的解读、已尝试的动作及其结果的一种紧凑记忆。没有这些信息，模型实际上必须在每一步都从头重新规划，并且失去了对累积上下文的访问，这在长周期网页导航中尤其有害。
保留更多最近的截图并不总能带来帮助。默认情况下，模型仅在上下文中保留最近的一张截图。将其增加到保留最近的两张截图并未带来一致的收益，性能分别变化了、和个百分点。这表明历史推理已经捕获了早期视觉观察中的大部分有用信息，而额外的截图主要增加了上下文长度和视觉token开销。除了最新帧之外，视觉历史提供的收益有限，甚至可能降低性能。它还显著增加了训练成本，将运行时间从大约240 GPU小时延长到了400 GPU小时。
5.6 MM-GRPO设计的消融实验
在线强化学习最能从平衡的监督微调热启动中获益。我们首先研究了监督式热启动如何影响后续的在线强化学习。图 6 比较了从四种初始 4B 策略开始的 MM-GRPO 训练：未经 SFT 的基础模型、在 0.4K 轨迹上训练 1 个 epoch 的轻量级 SFT 模型、在相同 0.4K 轨迹上训练 3 个 epoch 的默认 SFT 模型，以及在 1.9K 轨迹上训练 3 个 epoch 的大数据 SFT 模型。这 1.9K 轨迹使用相同的教师 rollout 流程收集，但保留了来自 WebGym 的更广泛且筛选不那么严格的任务分布。结果表明，监督式初始化至关重要，即所有 SFT 初始化都优于基础模型初始化，但更强的热启动并不一定能带来更好的在线强化学习。经过在线强化学习后，1.9K/3-epoch 初始化的表现不如默认设置。尽管它从一个相对较强的策略开始，但其改进很快趋于饱和，最终评估性能仍低于 0.4K/3-epoch 初始化。我们推测，更重的模仿训练，尤其是在筛选不那么严格的任务分布上，可能会降低策略的可塑性，或使策略偏向于不太适合在线优化的行为。相比之下，默认初始化赋予了策略足够的能力进行有效探索，同时仍允许强化学习通过在线试错进一步调整策略。
轨迹动态采样提升了训练稳定性与优化效率。如图7(a)和(b)所示，移除轨迹级动态采样后，训练奖励和评估成功率均出现明显更不稳定的训练动态。采用动态采样时，训练过程通过过滤掉奖励方差为零的组来收集固定数量的有效组；而不采用动态采样的变体则始终收集固定数量的组，无论奖励方差如何。因此，在不采用动态采样的情况下，有效批次大小在不同迭代轮次间可能发生显著变化，导致策略更新噪声更大、优化过程更不稳定。相比之下，动态采样稳定了训练过程，并使MM-GRPO的性能提升速度更快。
适度的PPO轮次能在数据效率与稳定优化之间取得平衡。PPO轮次控制着在收集新轨迹之前，同一轮次批次数据被用于更新策略的次数，这形成了数据效率与离策略性之间的权衡。如图7(c)和(d)所示，仅使用一个PPO轮次会导致优化速度较慢且评估性能较差，表明对每批轮次数据的更新不足。将PPO轮次增加到2次后，训练奖励和评估成功率均显著提升，达到了最佳整体性能。然而，将PPO轮次增加到3次会导致评估行为变得不稳定：尽管训练奖励仍然很高，但评估成功率在早期达到峰值后便出现下降。这表明过度重复使用同一轮次数据会增加离策略性，并可能导致过度优化，而适度的PPO轮次则能更好地平衡样本效率与稳定的在线强化学习训练。
6 附加分析
我们在附录中提供了额外的诊断分析，以进一步深入理解主要结果。
- •
附录C.1分析了基准测试的难度，结果表明Online-Mind2Web和DeepShop需要更长的轨迹，且成功率低于WebVoyager，这使得OpenWebRL-4B在这些基准测试上的提升更具参考价值。
- •
附录 E 进一步分析了 OpenWebRL-4B 的 100 条失败轨迹。访问与环境问题占失败原因的最大比例（51%），其次是推理与约束跟踪限制（27%）、视觉定位与交互错误（13%），以及任务定义或评判器问题（9%）。这些结果表明，未来的进展不仅需要更强的策略，还需要更稳健的开放网络智能体基础设施。
7 结论
我们提出了 OpenWebRL，这是一个用于在真实网站上通过在线多轮强化学习训练视觉网络智能体的开放框架。基于该框架构建的 OpenWebRL-4B 在具有挑战性的真实网络基准测试中取得了强劲性能，表明有效的网络智能体训练可以通过相对适度的监督初始化和可扩展的在线交互来实现，而非依赖大规模演示数据集。通过系统分析，我们确定了使在线强化学习对视觉网络智能体有效的几个关键要素，包括监督式热启动、文本环境反馈、用于长程记忆的历史推理、展开长度课程以及可靠的轨迹级成功评判。我们希望 OpenWebRL 能够为未来关于开放、经济高效且可扩展的网络智能体训练的研究提供一个可操作且可复现的基础，并有助于缩小开放系统与专有系统在真实网络上进行长程交互方面的差距。
参考文献
附录 A 实现细节
A.1 稳健的网络环境基础设施
为了支持在真实网站上进行浏览器智能体训练，我们实现了一个稳健的网络环境，以显式处理开放网络的不稳定性。与自托管的基准测试网站不同，真实网站表现出频繁的布局变化、异步加载、弹窗、重定向、反自动化防御、网络错误以及非确定性的页面状态。
沙盒化执行。
该环境基于 Playwright 构建，采用 Chromium 后端，默认支持沙箱化执行。每次运行都在隔离的 Kubernetes 沙箱 [peng2026orchard] 内进行，配有独立的浏览器环境服务器，可防止崩溃、过期 cookie、内存泄漏以及特定站点的副作用污染其他轨迹。
超时与恢复。
浏览器环境对初始化、交互和截图分别设置了独立的超时时间。初始导航会多次重试，以应对常见的实时网站故障，例如 HTTP/2 错误、连接重置、脚本缓慢以及瞬时的机器人检测行为。
故障归因与诊断。
运行层通过明确的终止原因将模型故障与环境及基础设施故障区分开来，这些原因包括：任务完成、达到最大步骤数、生成长度限制、格式错误、环境步骤错误、沙箱故障以及初始化失败。系统还会记录服务器延迟、内存使用量、运行时间、请求次数和回溯信息等诊断数据，以便事后分析低奖励值究竟是模型行为所致，还是由屏蔽、网络不稳定或服务器故障等外部因素引起。与网络相关的初始化错误还可更新主机黑名单，使后续训练能够避开那些反复无法访问或对自动化不友好的网站。
| 动作 | 反馈信号 | 反馈示例 |
| 点击 | 目标元素、位置、导航或新标签页效果 | 成功：对位于 (512, 86) 的 <button> "搜索" 执行了 'click'。页面已导航至…… |
| 点击 | 无操作检测 | 成功：对位于 (211, 335) 的 <div> 执行了 'click'。注意：未检测到可见的导航或新标签页。 |
| 输入 | 聚焦的元素及输入内容 | 成功：'write' 将 "Alpine Ridge" 输入到了角色为 combobox 的 "搜索" <input> 中。 |
| 输入 | 实际值不匹配 | 注意：该字段的实际值为 "New York, NY"，与输入的文本不一致。 |
| 滚动 | 滚动方向、距离及边界检测 | 成功：执行“向下滚动 50%”。注意：页面滚动位置未发生变化，可能已到达边界。 |
| 按键操作 | 标准化按键及导航效果 | 成功：执行“按键操作”[“回车”]。页面已导航至…… |
| 跳转网址 | 直接导航成功或失败 | 失败：“跳转网址”执行失败：Page.goto: net::ERR_HTTP2_PROTOCOL_ERROR…… |
| 标签页操作 | 新建、切换或关闭标签页的状态 | 成功：“切换标签页”已切换到标签页 1 (https://example.com)。 |
| 完成 | 任务终止并给出最终回复 | 成功：任务标记为完成。回复：…… |
A.2 文本环境反馈
浏览器智能体在经过程序化处理的网络环境中运行，该环境会暴露一些无法直接从截图中看到的状态信号。这些信号包括：操作坐标对应的 DOM 元素、当前聚焦的输入框、活动 URL、标签页状态以及轻量级的无障碍树变化。如果智能体仅依赖视觉输入，它往往需要多张历史截图才能推断出执行某个操作后当前状态是否发生了变化。例如，点击之后，仅凭一张截图可能无法清晰判断目标元素是否被选中、输入框是否获得焦点，或者导航是否被阻止。同样，滚动之后，智能体可能无法知道页面是否真的移动了，还是已经到达边界。如果没有这种反馈，智能体很容易重复执行相同的失败点击，或在当前状态下继续滚动。为了更高效地提供这些信息，我们通过轻量级的文本环境反馈来增强视觉观测。
对于每个解析出的工具调用，环境会通过比较动作执行前后的浏览器状态来生成反馈。在执行动作之前，环境会记录轻量级状态变量，例如当前活动页面的 URL、打开的标签页数量、当前滚动位置、聚焦的元素，以及在适用情况下位于动作坐标处的 DOM 元素。然后，环境执行相应的 Playwright 操作，并应用特定于动作的规则逻辑，将观察到的状态变化转换为简洁的文本消息。当一个动作包含多个工具调用时，环境会按顺序处理它们，并将反馈以列表形式返回，其中每个条目对应一个已执行的工具调用。
下面和表 5 中总结了几条具有代表性的反馈规则。对于点击操作，反馈会使用点击的坐标、`document.elementFromPoint` 返回的 DOM 元素、页面 URL 的变化以及打开的标签页数量的变化。对于写入操作，反馈会报告当前聚焦的元素，并比较输入后字段中预期文本与实际值。对于滚动操作，反馈会比较动作前后的滚动偏移量，以识别滚动成功、边界条件或无操作。对于按键操作，环境会报告标准化后的按键序列，以及该动作是否触发了 URL 变化。
执行异常也会被捕获并转换为明确的失败消息，而不是静默终止运行。成功的动作会返回简洁的消息，描述执行状态和可观察到的浏览器状态变化。生成的反馈会被附加到下一次观测中，从而为策略提供紧凑的信号，用于检测失败的点击、被阻止的导航、意外的标签页切换、被拒绝的输入、边界滚动以及其他常见的开放网络交互问题。
A.3 动作空间
我们定义了一个紧凑的浏览器动作空间，包含 13 个原子工具，如表 6 所示。这些工具涵盖了开放网页交互所需的核心操作，包括指针控制、键盘输入、页面导航、标签页管理和任务终止。每个动作都表示为一个带有显式参数的结构化工具调用，这使得策略输出易于在浏览器环境中解析和执行。
| 类别 | 工具 | 参数 | 描述 |
| 指针管理 | click（点击） | x, y, button, click_type | 在屏幕像素点处进行鼠标点击；支持单击/双击以及左键/右键/中键。 |
| hover（悬停） | x, y | 将光标移动至某个像素点以显示工具提示或打开下拉菜单。 | |
| drag（拖拽） | x1, y1, x2, y2 | 从起始像素点拖放至结束像素点。 | |
| 键盘管理 | write（输入） | text（文本） | 清除焦点输入框并输入一串字符。 |
| press_keys（按键） | keys（按键） | 按顺序按键或作为热键组合按键。 | |
| 页面导航 | scroll（滚动） | direction（方向）, amount（数量） | 按视口比例滚动页面或元素。 |
| goto_url（跳转URL） | url | 将当前标签页导航至给定的 URL。 | |
| go_back（返回） | — | 在浏览器历史记录中向后导航。 | |
| wait（等待） | seconds（秒） | 暂停若干秒以等待页面稳定。 | |
| 标签页管理 | new_tab（新建标签页） | — | 打开一个新的空白浏览器标签页。 |
| switch_tab（切换标签页） | index（索引） | 切换到指定索引（从 0 开始）的标签页。 | |
| close_tab（关闭标签页） | — | 关闭当前标签页。 | |
| 终止 | done（完成） | answer（答案） | 结束本轮交互并输出最终答案。 |
A.4 奖励设计
我们的浏览器强化学习奖励是确定性规则验证与大语言模型作为评判者评估的混合体。确定性规则有两个目的：它们强制执行浏览器环境所需的交互协议，并且它们避免对明显无效或不完整的轨迹进行不必要的评判者调用。评判模型仅用于通过这些基本有效性检查的已完成轨迹。对于每个生成的轨迹，我们计算三个与奖励相关的量：格式分数、评判分数和最终训练奖励。
基于规则的格式验证。
在调用评判模型之前，我们会验证智能体的响应是否符合所需的浏览器操作格式。在我们的响应格式中，一个轮次只有在包含预期的结束思考标签和可解析的工具调用时，才被视为有效。这确保了模型输出的是可执行的浏览器操作，而非自由格式的文本。
基于规则的状态过滤。
对于未达到完成浏览器状态（即智能体自行输出“完成”）的轨迹，不会调用评判模型。如果运行因格式错误的工具调用、生成中止、上下文窗口截断、环境错误或超出最大浏览器步骤数而终止，则评判分数按规则设为零：
格式错误导致的终止被视为一种特殊的失败情况，并会获得负面的最终奖励：
这会对无法生成可执行浏览器操作的轨迹进行惩罚。
即使对于已完成的轨迹，如果无法提取出最终答案，也会跳过评判模型。最终答案必须来自最终的“完成”工具调用。如果最终答案缺失，我们会在不查询评判模型的情况下设置分数。
视觉语言模型作为评判的评估。
对于具有有效最终答案的已完成轨迹，我们会查询一个评判模型来确定任务是否成功。评判模型的输入包含原始任务指令、智能体的最终答案、轨迹中最近的三张截图，以及一份总结智能体工具调用和环境反馈的显式操作历史。评判模型被指示返回“成功”或“不成功”的判定结果。
评判模型的输出通过一个确定性解析器映射回二元分数：
解析器会先检查“不成功”，再检查“成功”，以避免将否定判定误判为肯定判定。
最终奖励的构成。
最终奖励是基于规则的检查与评判模型分数的门控组合：
因此，一条轨迹只有在既遵循所需的浏览器操作格式，又被评判为成功的情况下，才能获得奖励。
无效或不可靠的样本。
如果因裁判超时或基础设施相关的部署故障导致奖励评估失败，该样本可标记为从优化中移除。此类样本的损失掩码被置零，因此不会贡献梯度。这可以防止奖励模型或环境系统的故障引入有噪声的策略更新。
| 超参数 | 数值 |
| 训练迭代次数 | 90 |
| 最大 rollout 步数 | 15, 30 |
| 每轮上下文截图数 | 1 |
| 每条轨迹裁判截图数 | 3 |
| 裁判模型 | GPT-4.1 或我们训练的 8B 裁判模型 |
| 每次迭代有效 rollout 查询数 | 48 |
| 每组提示词大小 | 5 |
| PPO 轮数 | 2 |
| 最大响应长度 | 1024 |
| 最大上下文长度 | 32768 |
| RL 算法 | MM-GRPO |
| KL 系数 | 0.0 |
| 熵系数 | 0.0 |
| PPO 裁剪范围 | 低 0.2，高 0.28 |
| 优化全局批次大小 | 256 |
| 优化器 | Adam |
| 学习率 | ，恒定调度 |
| 权重衰减 | 0.1 |
| Adam betas | |
| 训练后端 | Megatron |
| 张量并行大小 | 4 |
| 微批次大小 | 1 |
| 注意力后端 | FlashAttention |
| 浏览器视口 | ，DPR 1 |
| 坐标归一化尺度 | 1000 |
| 采样温度 | 0.8 |
| Rollout 引擎 | SGLang |
| 沙箱模式 | Kubernetes 沙箱 |
| 沙箱 CPU 和内存 | 1 CPU，4 GiB |
| 最大并发沙箱数 | 训练期间 80–100 |
| 推理步骤超时 | 30 秒 |
| Rollout 任务超时 | 600 秒 |
| 沙箱获取超时 | 600 秒 |
| 浏览器步骤请求超时 | 45 秒 |
| 浏览器步骤重试次数 | 2 |
| 环境退出超时 | 15 秒 |
| Rollout 中止等待超时 | 30 秒 |
| Rollout 健康检查 | 间隔 30 秒，超时 30 秒，首次等待 180 秒 |
| 超参数 | 数值 |
| 最大评估 rollout 步数 | 30 |
| 沙箱模式 | Kubernetes 沙箱 |
| 沙箱 CPU 和内存 | 1 CPU，4 GiB |
| 并行浏览器沙箱数 | 16 |
| 每轮上下文截图数 | 1 |
| 每条轨迹裁判截图数 | 3 |
| 裁判模型 | 用于我们评估成功率（不含中止任务）的 GPT-4.1； |
| 用于报告官方分数的官方推荐模型 | |
| 裁判超时 | 120 秒 |
| 生成温度 | 官方分数评估为 0.6，评估成功率（不含中止任务）为 0.0 |
| Top- | 官方评分评估为 0.95，未中止任务的评估成功率为 1.0 |
| 前 | 官方评分评估为 20，未中止任务的评估成功率为 1 |
| 最大回复长度 | 4096 个 token |
| 最大上下文长度 | 32768 个 token |
| 任务超时时间 | 600 秒 |
| 推理步骤超时时间 | 120 秒 |
| 推理引擎 | SGLang |
| SGLang 数据类型 | bfloat16 |
| SGLang 上下文长度 | 32768 个 token |
| SGLang 张量并行数 | 2 |
| SGLang 数据并行数 | 4 |
A.5 训练细节
SFT。我们训练 Qwen3-VL-4B-Thinking 多个 epoch，采用余弦学习率调度和线性预热，峰值学习率为 。每个优化器步骤使用每设备批次 ，并配合 步梯度累积，使得每个工作节点的有效批次为 ，在 8 个数据并行工作节点上全局批次为 128。对于 8B 模型，我们使用相同的训练设置，唯一的区别在于 SFT 数据集：我们添加了来自 InSTA-v3 子集的轨迹，总计得到 条轨迹。
MM-GRPO。策略从 SFT 检查点初始化。训练过程中，每个任务在实时浏览器环境中交互式执行。每个推理状态包含当前观察、近期截图上下文以及浏览器工具调用格式的环境反馈。奖励结合了格式有效性和以 LLM 为评判者的成功信号，评判者接收完整的动作历史和近期轨迹截图作为输入。为确保训练稳定，我们采用有界推理执行，并设置明确的超时机制来控制模型生成、浏览器动作、沙箱获取以及任务级推理完成。训练运行 90 次迭代，总共需要约 300 个 B200 GPU 小时。我们采用轨迹级动态采样，持续收集推理结果，直到获得 48 个有效组，每组大小为 5。我们 OpenWebRL-4B 的关键训练超参数总结在表 7 中。对于 8B 模型，我们使用了更低的学习率 。
A.6 评估细节
每个评估任务都以交互式浏览器轨迹的形式执行，最多包含 30 个步骤。我们使用 SGLang 框架来部署模型。在官方成功率评估中，我们遵循先前工作的评判协议，并使用 Browser-Use Stealth Browsers。基于 [gupta2026molmoweb] 的发现——即随机采样在网页智能体上的表现优于确定性采样——我们采用随机解码，超参数设置如下：温度 0.6，top-p 0.95，top-k 20，最大响应长度 4096 个 token，重复惩罚 1.0。对于不包含中止任务的成功率评估，我们使用温度 0.0 的确定性解码。所有评估设置和解码参数汇总于表 8。
附录 B 基准测试详情
我们在三个在线基准测试上进行评估：
- •
WebVoyager [he2024webvoyager] 是一个包含 643 个任务的开放域基准测试，涵盖 15 个热门网站。我们使用 FARA [fara7b2025] 整理的版本，该版本移除了不可行的任务，并更新了原始数据集中信息过时的任务，最终得到 595 个任务222https://github.com/microsoft/fara/blob/44908264c810d3806365c6aab63a43c2d52a8057/webeval/data/webvoyager/WebVoyager_data_08312025.jsonl#L4。评估时，我们遵循标准的 WebVoyager 协议333https://github.com/MinorJerry/WebVoyager/blob/main/evaluation/auto_eval.py，并使用 GPT-4o 作为评判模型，与 FARA 保持一致。
- •
Online-Mind2Web [xue2025an] 包含 300 个更长周期的任务，这些任务来自 136 个涵盖不同领域的流行网站。与 WebVoyager 相比，这些任务通常需要更长的多步推理和交互序列。评估时，我们采用 OSU AgentTrek 协议444https://github.com/OSU-NLP-Group/Online-Mind2Web/blob/main/src/methods/agenttrek_eval.py，遵循先前工作中使用的标准设置，并以 o4-mini 作为评判模型。
- •
DeepShop [lyu2025deepshop] 是一个包含150个任务的基准测试，专注于在线购物场景，智能体必须在现实约束条件下进行搜索、比较和选择商品。任务成功与否通过 Molmo-Web 的结构化输出评估协议 [gupta2026molmoweb] 判定，并以 GPT-4o 作为裁判，该协议以编程方式验证最终回答的正确性555https://github.com/allenai/molmoweb/blob/main/benchmarks/judges/deepshop_judge.py。
附录C 补充实验结果
C.1 任务难度理解
为了描述任务难度以及完成任务所需的步骤数，我们分析了 Qwen3-VL-235B-Thinking 在三个在线基准测试上的结果。如图8所示，与 WebVoyager（平均8.0步）相比，Online-Mind2Web 和 DeepShop 的成功率较低，且需要更多步骤才能成功完成（平均分别为11.5步和14.2步）。请注意，图8中报告的步骤数是所有轨迹的平均值，包括失败的轨迹。这些结果证实，Online-Mind2Web 和 DeepShop 是更具挑战性的基准测试，需要更长的动作序列，且成功率更低。而 OpenWebRL-4B 恰恰在这些更难的基准测试上表现更强（表2），这更有力地证明了我们训练框架的有效性。
C.2 AgentRewardBench 上的结果
为了进一步评估我们裁判模型的泛化能力和有效性，我们报告了在 AgentRewardBench [lu2025agentrewardbench] 上的结果。AgentRewardBench 包含来自五个广泛使用的网页智能体基准测试的1302条轨迹：WebArena (WA)、VisualWebArena (VWA)、AssistantBench (AB)、WorkArena (Work) 和 WorkArena++ (Wk++)。如表9所示，OpenWebRL-Judge-8B 在整体 F1 分数和召回率上取得了最佳成绩，同时在各个基准测试中保持了具有竞争力的精确率。OpenWebRL-Judge-4B 也表现强劲，在 WebArena 和 WorkArena 上取得了最佳精确率。
值得注意的是，AgentRewardBench 构建于不同的智能体技术栈之上，在动作表示和可用的环境反馈两方面均引入了分布偏移。具体而言，AgentRewardBench 包含我们动作空间之外的动作类型，导致部分动作转换只能近似处理。其轨迹数据也缺少我们评判器所使用的逐步骤环境反馈，仅保留了 URL 变化、传播错误以及无障碍树片段等部分信号。我们认为，这些结果应被视为我们在该分布外设定下性能的下界估计。
| 评判器 | 整体 | 逐基准精确率 | ||||||
| 精确率 | 召回率 | F1 | AB | VWA | WA | Work | Wk++ | |
| Claude 3.7 S.† | 69.4 | 76.3 | 72.7 | 71.4 | 64.8 | 69.3 | 85.3 | 66.7 |
| GPT-4o† | 68.1 | 80.3 | 73.7 | 77.8 | 60.7 | 69.9 | 93.8 | 59.6 |
| GPT-4o Mini† | 64.5 | 78.3 | 70.8 | 80.0 | 57.4 | 66.9 | 90.3 | 54.8 |
| WebJudge (GPT-4o)∗ | 73.7 | 71.2 | 72.4 | 66.7 | 69.8 | 72.6 | 92.3 | 75.0 |
| WebJudge-7B∗ | 75.7 | 58.0 | 65.6 | 80.0 | 66.7 | 77.5 | 100.0 | 70.0 |
| OpenWebRL-Judge-4B | 73.2 | 67.0 | 70.0 | 75.0 | 62.2 | 78.0 | 92.6 | 70.0 |
| OpenWebRL-Judge-8B | 72.8 | 72.5 | 72.7 | 80.0 | 67.0 | 73.5 | 82.9 | 74.2 |
C.3 与在线过滤行为克隆基线的比较
图9将MM-GRPO与在线过滤行为克隆（BC）基线进行了比较。该BC基线使用与MM-GRPO相同的在线训练设置，并基于相同的SFT检查点，但仅保留成功的轨迹用于监督更新，使用固定的生成查询批次大小，并且不应用动态采样。尽管在线过滤BC最初获得了具有竞争力的训练奖励，但其在未中止任务情况下的评估成功率在整个训练过程中稳步下降，最终降至30%以下。相比之下，MM-GRPO保持了稳定的优化，并持续提升评估性能，达到了超过50%的评估成功率，这表明在开放网络环境中，单纯模仿过滤后的在线轨迹不足以实现稳健的策略改进。这些结果凸显了强化学习更新（而非纯粹的监督模仿）对于有效的在线适应和长周期网络交互的重要性。
附录D 基于代理指标的回答长度分析
为了更好地理解为什么回答长度会随着训练轮次增加，我们针对智能体回答定义了四个轻量级词汇代理指标。这些代理指标并非旨在成为详尽的语义标签；相反，它们提供了可解释、可自动计算的指标，用于指示在长回答中观察到的常见推理模式。我们通过匹配首次工具调用前推理文本中面向精度的正则表达式族，将其应用于助手轮次。这些代理指标特意设计得简单且透明。一个回答可能匹配多个代理指标，且这些类别并非互斥。例如，一个回答既可以总结失败的尝试，也可以诊断CAPTCHA拦截器。因此，我们将这些代理指标用作描述性度量，而非真实语义标签。我们在表10中总结了这些代理指标。
| 代理指标 | 衡量内容 | 示例短语族 | 动机 |
| 历史总结 | 智能体会列出之前的尝试、操作、失败或已用尽的来源。 | “我已经试过”、“我们检查过了”、“之前的尝试”、“到目前为止”、“多种方法”、“所有来源都失败了”。 | 长回复通常包含对先前失败的详细列举，尤其是在接近终止时。 |
| 障碍诊断 | 智能体诊断验证码、验证、访问拒绝或与自动化相关的障碍。 | “验证码”、“Cloudflare”、“403 禁止访问”、“需要验证”、“反机器人”、“自动化访问”、“无法解决验证”。 | 许多长尾失败源于网络安全或反自动化屏障。 |
| 重试计划循环 | 智能体会考虑重复的替代方案、直接导航或“再试一次”的尝试。 | “最后一种方法”、“尝试不同的搜索”、“替代来源”、“返回”、“直接搜索”、“让我重新考虑”。 | 捕捉智能体持续规划重试而非终止或采取简洁操作的情况。 |
| 条件验证 | 智能体逐一检查任务约束，或明确验证具体约束是否满足。 | “满足要求”、“所有标准都符合”、“第一个条件”、“低于 50 美元”、“5 英里以内”、“无麸质”。 | 冗长的成功或部分成功案例通常会逐一验证用户的每个约束。 |
所有正则表达式均不区分大小写进行评估。如果一个步骤匹配四个代理家族中任一模式，则标记为带有代理特征。我们还单独跟踪不包含任何代理特征的响应作为基线。这个无代理基线显示的长度增长小于带有代理特征的响应，表明这四个模式在观察到的每步冗长增加中占了相当大的一部分。
在我们的分析中，这些代理模式在早期迭代中就已出现，表明后续训练并未引入全新的推理模式。相反，后续迭代倾向于在模式出现时将其放大。具体而言，历史摘要和重试-计划循环与更长的响应和更重的响应长度尾部相关。障碍诊断捕获了由 CAPTCHA 或访问限制导致的常见失败状态，而条件证明则解释了为何即使是有效或成功的响应也可能变得更加冗长：智能体通过明确检查任务要求来日益强化其答案。
精确匹配模式。
为确保可复现性，我们在下方列出了分析中使用的精确补丁代理定义。我们采用紧凑风格以保持长正则表达式的可读性。
⬇
HISTORY_SUMMARIZATION=[
r"\b(?:i(?:’ve|have)|we(?:’ve|have))\s+(?:already\s+)?"
r"(?:tried|attempted|checked|searched|lookedat|visited|used)\b",
r"\b(?:i|we)\s+already\s+"
r"(?:tried|attempted|checked|searched|lookedat|visited|used)\b",
r"\b(?:i|we)\s+had\s+(?:already\s+)?"
r"(?:tried|attempted|checked|searched|lookedat|visited|used)\b",
r"\b(?:previous|earlier|last)\s+"
r"(?:attempt|search|approach|step|site|page)\b",
r"\b(?:sofar|uptothispoint),?\s+(?:i|we)\s+(?:have|’ve|had)\b",
r"\b(?:tried|attempted|checked|searched|lookedat|visited|used)\b"
r"[^.!?\n]{0,80}\b(?:multiple|several)\s+"
r"(?:attempts|approaches|searches|sites|websites|sources)\b",
r"\b(?:multiple|several)\s+"
r"(?:attempts|approaches|searches|sites|websites|sources)\b"
r"[^.!?\n]{0,80}\b(?:failed|blocked|ledto|resultedin|didnot|"
r"didn’t|couldn’t|cannot)\b",
r"\b(?:all|every)\s+(?:attempt|approach|site|source|path|option)s?\s+"
r"(?:has|have)\s+(?:failed|ledto|resultedin)\b",
r"\b(?:exhausted|tried)\s+(?:all|every|multiple|several)\s+"
r"(?:options|approaches|paths|sources|sites)\b",
]
⬇
BLOCKER_DIAGNOSIS=[
r"\b(?:captcha|recaptcha|cloudflare|accessdenied|403\s+forbidden|"
r"robotcheck)\b",
r"\baccess\s+(?:is\s+)?forbidden\b",
r"\b(?:blocked|blocking|unabletoaccess|cannotaccess|can’taccess|"
r"notaccessible)\b",
r"\b(?:(?:security|bot|human)\s+verification|verification\s+"
r"(?:challenge|required|page|screen|check))\b",
r"\b(?:securitycheck|securitymeasure|anti[-]bot|anti[-]automation)\b",
r"\b(?:automatedaccess|automatedbehavior|botdetection|"
r"detectedautomated)\b",
r"\b(?:requires?|needs?)\s+human\s+"
r"(?:interaction|verification|input)\b",
r"\b(?:cannot|can’t|unableto)\s+(?:interactwith|solve|complete)\s+"
r"(?:the\s+)?(?:captcha|recaptcha|verification)\b",
]
⬇
=[
r"\b(?:one|a)\s+(?:final|last)\s+(?:approach|attempt|try|option)\b",
r"\b(?:try|attempt|use|take)\s+(?:a\s+)?"
r"(?:different|another|alternative|new)\s+"
r"(?:approach|search|query|site|source|path|method)\b",
r"\b(?:need|needs|needed|should|could|might|may|will|would|try|use|"
r"take|switchto|lookfor|searchfor)\b[^.!?\n]{0,50}\b"
r"(?:different|alternative|another|new)\s+"
r"(?:approach|search|query|site|source|path|method)\b",
r"\b(?:different|alternative|another|new)\s+"
r"(?:approach|search|query|site|source|path|method)\b"
r"[^.!?\n]{0,50}\b(?:isneeded|maywork|mightwork|couldwork|"
r"shouldwork|wouldhelp|totry|tosearch|touse)\b",
r"\b(?:goback|return)\s+(?:and|to)\s+(?:try|search|look|navigate)\b",
r"\b(?:navigatedirectly|searchdirectly|trysearchingdirectly|"
r"searchmorebroadly)\b",
r"\b(?:letme|ishould)\s+"
r"(?:reconsider|tryagain|tryanother|switchto|useadifferent)\b",
r"\b(?:ratherthan|insteadof)\s+[^.!?\n]{0,80}\b"
r"(?:ishould|i’ll|iwill|letme)\s+(?:try|search|navigate|use)\b",
]
⬇
PROOF_VERB=(
r"\b(?:meets?|matches?|satisf(?:y|ies|ied)|fulfills?|"
r"qualif(?:y|ies|ied)|confirms?|verif(?:y|ies|ied)|fits?|"
r"complieswith|addresses)\b"
)
REQ_WORD=(
r"(?:criteria|requirements|conditions|constraints|criterion|"
r"requirement|condition|constraint)"
)
REQ_MET=PROOF_VERB+r"[^.!?\n]{0,80}\b"+REQ_WORD+r"\b"
ALL_MET=(
r"\b(?:all|each|every)\s+(?:the\s+)?"
r"(?:criteria|requirements|conditions|constraints)\b"
r"[^.!?\n]{0,80}\b(?:met|satisfied|fulfilled|addressed|checked)\b"
)
ORDINAL_REQ=(
r"\b(?:(?:first|second|third|fourth|fifth|sixth|seventh|eighth|"
r"ninth|tenth|final|last)|\d+(?:st|nd|rd|th)?)\s+\b"
+REQ_WORD+r"\b"
)
VALUE_PATTERNS=[
r"\b(?:under|lessthan|below)\s+\$?[0-9][0-9,]*(?:\.[0-9]+)?\b",
r"\b(?:atleast|atmost|nomorethan|fewerthan|greaterthan)\s+"
r"[0-9][0-9,]*(?:\.[0-9]+)?\b",
r"\bwithin\s+[0-9][0-9,]*(?:\.[0-9]+)?\s*"
r"(?:miles?|mi|km|kilometers?)\b",
r"\b(?:before|after)\s+[0-9]{1,2}:[0-9]{2}\b",
r"\b(?:modelyears?|years?)\s+[0-9]{4}\s*(?:-|to)\s*[0-9]{4}\b",
]
DOMAIN_PATTERNS=[
r"\bgoodwithkids\b",
r"\bgoodwithcats\b",
r"\bgluten[-]free\b",
r"\bnut[-]free\b",
r"\bshort[-]haired\b",
r"\bdepart(?:ing|s)?from\s+[A-Z][A-Za-z.-]+",
r"\blocatednear\s+[A-Z0-9][A-Za-z0-9.-]+",
]
def has_condition_proof(step):
if re.search(REQ_MET, step, flags=re.I):
return True
if re.search(ALL_MET, step, flags=re.I):
return True
if re.search(ORDINAL_REQ, step, flags=re.I):
return True
constraints = VALUE_PATTERNS + DOMAIN_PATTERNS
for sent in re.split(r"[.!?\n]+", step):
has_proof = re.search(PROOF_VERB, sent, flags=re.I)
n_constraints = sum(
bool(re.search(pat, sent, flags=re.I)) for pat in constraints
)
has_value = any(
re.search(pat, sent, flags=re.I) for pat in VALUE_PATTERNS
)
if has_proof and has_value:
return True
if has_proof and n_constraints >= 2:
return True
return False
⬇
def proxy_labels(step):
labels = set()
if any(re.search(p, step, flags=re.I) for p in HISTORY_SUMMARIZATION):
labels.add("history_summarization")
if any(re.search(p, step, flags=re.I) for p in BLOCKER_DIAGNOSIS):
labels.add("blocker_diagnosis")
if any(re.search(p, step, flags=re.I) for p in ):
labels.add("retry_plan_loop")
if has_condition_proof(step):
labels.add("condition_proof")
return labels
def is_non_proxy(step):
return len(proxy_labels(step)) == 0
局限性。
由于这些代理基于正则表达式，它们可能会遗漏同义改写或包含少量误报。重试计划代理有意设计得较为宽泛，以便能捕捉到基于上下文锚定的替代方法表述，但这同时也意味着一些良性的规划陈述也可能被计入。条件证明代理则更为保守：仅泛泛提及约束条件是不够的，除非它们匹配明确的需求满足模式，或者在同一句子中与具体约束条件和证明动词同时出现。尽管如此，这些代理定义是可解释的、易于复现的，并且有助于识别响应长度增长背后的高层机制。
附录 E 错误分析
我们手动检查了从多个 OpenWebRL 检查点在 Online-Mind2Web 上（未使用 Browser-Use Stealth Browser 服务）的评估运行中抽取的 100 条失败轨迹，并将其归类为四种失败类型。图 10 总结了其分布情况。
访问与环境问题（51%）。占比最大的类别源于实时网络的不稳定性，包括页面加载失败、访问限制和 CAPTCHA 验证码拦截。在这些情况下，智能体通常遵循合理的策略，但环境障碍阻止了轨迹达到可验证的终止状态。
推理与知识局限（27%）。第二大类别反映了模型端在规划与约束追踪方面的不足。在长周期任务中——尤其是涉及价格、颜色、评分、尺寸和产品类型等多个同时性需求的购物或搜索任务——智能体可能满足了大部分约束，却忽略了一个或多个。还有一小部分失败源于任务预设了模型并不稳定具备的背景知识或领域特定知识。
视觉定位与交互错误（13%）。另一种常见的失败模式是与页面的不准确交互。智能体可能会点击附近但错误的元素，遗漏小的下拉菜单或分页控件，或者未能注意到某个筛选条件尚未应用。当在下次观察之前执行了多个操作时，这些错误更有可能发生，这使得智能体更难诊断中间环节的失败。
任务定义与评估问题（9%）。其余的失败源于模糊或说明不充分的任务指令，其中一小部分归因于评判者错误——即智能体正确完成了任务，但自动评判者错误地将其标记为未完成。
总体而言，这项错误分析表明，进一步的进展需要：对开放网络不稳定性更强的鲁棒性、更可靠的长期约束维持、改进的中间状态监控，以及针对失败交互的更强大的恢复机制。
附录 F 提示词模板
本节展示了我们流程中使用的提示词示例。对于执行示例，我们展示了一个用户轮次及对应的助手轮次，其格式为模型所消费的精确序列化对话格式。对于评判者示例，我们提供了完整的模板，以及一个基于真实轨迹构建的具体示例。
F.1 智能体输入与输出
F.2 OpenWebRL-评判者输入与输出
来源：HuggingFace Daily Papers（社区热门论文） · arxiv.org