WebRL: Training LLM Web Agents via Self-Evolving Online Curriculum Reinforcement Learning

论文阅读：WebRL——通过自演化在线课程强化学习训练 LLM Web Agent

论文标题：WebRL: Training LLM Web Agents via Self-Evolving Online Curriculum Reinforcement Learning
作者：Zehan Qi, Xiao Liu, Iat Long Iong, Hanyu Lai, Xueqiao Sun, Wenyi Zhao, Yu Yang, Xinyue Yang, Jiadai Sun, Shuntian Yao, Tianjie Zhang, Wei Xu, Jie Tang, Yuxiao Dong
作者机构：Tsinghua University（清华大学）、Zhipu AI（智谱 AI）
发表位置：ICLR 2025，Conference Paper / Poster
arXiv 编号：2411.02337
原文链接：https://arxiv.org/abs/2411.02337
PDF：https://arxiv.org/pdf/2411.02337
OpenReview：https://openreview.net/forum?id=oVKEAFjEqv
代码：https://github.com/THUDM/WebRL
主题：Web Agent、Agentic RL、Online RL、Curriculum Learning、Self-Evolving
核心问题：如何让开源 LLM 在交互式网页环境中通过不断与环境交互、生成新的训练任务并进行 RL，持续成长为能力更强的 Web Agent？

1. 论文要解决什么问题？

LLM 被用作 Web Agent 时，需要根据用户指令不断观察网页、点击按钮、填写表单、搜索内容，经过多步操作最终完成任务。

例如：

找到 2022 年 3 月到 2023 年 4 月之间所有处于 Pending 状态的订单，然后返回交易金额最高的 8 个订单的 Purchase Date。

这类任务和普通的文本问答有明显区别。

Agent 需要形成一个长达多步的交互 trajectory：

\[s_0 \rightarrow a_0 \rightarrow s_1 \rightarrow a_1 \rightarrow \cdots \rightarrow s_T \]

其中：

  • \(s_t\)：当前网页状态；
  • \(a_t\)：Agent 执行的网页操作；
  • \(T\)：任务结束时的交互步数。

作者认为，当时的 Web Agent 存在一个明显问题：

强 Web Agent 往往高度依赖 GPT-4 等 proprietary LLM，而开源模型直接拿来做 Web Agent 的能力非常弱。

例如在 WebArena-Lite 上：

模型 Success Rate
Llama-3.1-8B-Instruct 4.8%
GLM-4-9B-Chat 6.1%
GPT-4-Turbo 17.6%
AutoWebGLM 18.2%

仅仅依靠 prompting，并不能让较小的开源模型获得足够强的网页决策能力。

因此作者希望直接通过 online reinforcement learning，让模型在网页环境中不断交互和学习。

但这么做又会遇到三个问题。

1.1 训练任务太少

WebArena-Lite 虽然提供了训练数据，但只有约一千条带 oracle trajectory 的 instruction。

对于训练一个 Web Agent 来说，这远远不够。

如果始终在固定的任务集上学习，模型很快就会把这些任务学完，之后很难继续提高。

1.2 Reward 极其稀疏

Web Agent 一条 trajectory 可能包含十几甚至几十步操作。

但环境通常只能告诉 Agent：

最后任务完成了吗？

也就是只有最终 reward：

\[r_T = \begin{cases} 1, & \text{任务成功}\\ 0, & \text{任务失败} \end{cases} \]

中间操作基本没有 reward。

因此很容易出现：

前 9 步都做对了
↓
第 10 步点错
↓
最终任务失败
↓
reward = 0

这样一来，前面那些实际上正确的操作也很难获得有效的学习信号。

1.3 Online Learning 容易发生策略漂移和遗忘

假设 Agent 已经学会了任务 A、B、C。

下一阶段开始训练更加复杂的新任务 D、E、F。

如果只在这些新任务上更新参数，模型可能出现：

D、E、F 学会了，但是 A、B、C 又不会了。

也就是典型的 catastrophic forgetting。

从策略分布角度看，就是新策略 \(\pi_\theta\) 和之前的策略发生了过大的 distribution shift。

因此 WebRL 实际上要同时解决：

问题 WebRL 的解决方案
训练任务不足 Self-Evolving Curriculum
新生成任务没有环境 reward Outcome-Supervised Reward Model（ORM）
Reward 稀疏 Critic + Advantage Estimation
新阶段训练导致旧能力遗忘 KL-Constrained Policy Update
历史经验被丢弃 Experience Replay Buffer
Replay 太简单或太困难 Actor Confidence Filtering

这些组件共同构成了 WebRL。

2. WebRL 整体思路

WebRL 最核心的思想可以先简单概括成一句话：

哪里做不会，就从哪里继续生成新的训练题，然后不断训练。

假设当前 Agent 遇到下面一批任务：

Task A → 成功
Task B → 失败
Task C → 成功
Task D → 失败

WebRL 不只是把 B 和 D 再训练几遍。

而是把这些失败任务作为种子：

Task B
Task D
 ↓
生成一些相似难度、相关类型的新任务
 ↓
过滤掉太简单、太困难或网页环境中根本无法完成的任务
 ↓
得到下一阶段 curriculum

Agent 再去这些新任务上 rollout。

新的失败任务又继续成为下一轮课程生成的种子。

于是形成：

当前 Agent
    ↓
执行任务
    ↓
成功 / 失败
    ↓
失败任务
    ↓
生成新的训练任务
    ↓
筛选适合当前 Agent 的任务
    ↓
Online RL
    ↓
更强的 Agent
    ↓
继续生成下一阶段任务

这就是论文标题里的：

Self-Evolving Online Curriculum Reinforcement Learning

image

【Figure 2（WebRL 整体框架，包括 Web 交互、Actor、Critic、Self-Evolving Tasks、Replay Buffer 和 KL Policy Update）】

不过这里需要特别注意 self-evolving 的具体含义。

WebRL 所谓的“自演化”，主要是：

训练任务集合 / curriculum 随 Agent 当前能力不断演化。

它不是让 Agent：

  • 修改自己的源代码；
  • 修改 Agent framework；
  • 修改 tool schema；
  • 自动重构 Prompt；
  • 自动设计新的 Agent architecture。

真正被 RL 更新的仍然主要是模型参数。

因此 WebRL 中的 self-evolving，更准确地理解应该是：

self-evolving curriculum + continuously updated policy

而不是后来某些 Self-Improving Agent 工作所讨论的“Agent 自己修改自身系统结构”。

3. WebRL 中 Agent 到底看到了什么？

论文将 Web Agent 的 observation 设计为三部分：

  1. User Instruction；
  2. Action History；
  3. 当前网页的 HTML。

即：

用户任务
+
此前采取过的动作
+
当前网页 HTML

作者会对 HTML 进行简化，并给网页中的可交互元素分配 element ID。

例如：

<button id="25">Clear all</button>

模型可以输出：

Click element 25

Agent 支持的操作包括：

  • Click；
  • Hover；
  • Type；
  • Search；
  • Press；
  • Scroll；
  • Select dropdown option；
  • New tab；
  • Tab focus；
  • Close tab；
  • Goto；
  • Go back；
  • Go forward；
  • Exit。

因此这里的 LLM 本质上就是一个 policy：

\[\pi(a_t \mid s_t, I) \]

根据：

  • 当前网页状态 \(s_t\)；
  • 用户任务 \(I\)；

决定下一步执行什么 action。

4. WebRL 的完整训练流程

WebRL 并不是直接拿一个基础模型开始 RL，而是分成两个阶段：

Part 1：SFT 冷启动
Part 2：Self-Evolving Curriculum RL

4.1 第一阶段：先用 SFT 得到一个基础 Web Agent

首先使用 WebArena-Lite 提供的 demonstration data 对基础模型进行 SFT：

\[M_{\mathrm{base}} \rightarrow M_{\mathrm{SFT}} \]

这是必要的，因为如果直接让一个几乎不会操作网页的模型做 online RL：

随机点击
→
几乎所有任务失败
→
reward 几乎全部为 0
→
没有有效学习信号

因此 SFT 相当于给 Agent 一个初始能力。

随后让 \(M_{\mathrm{SFT}}\) 在训练任务上 rollout。

任务被分成：

  • 成功任务；
  • 失败任务。

失败任务会进入 Failure Set：

\[\mathcal F \]

成功经验则成为历史经验的一部分。

之后正式进入 Self-Evolving Curriculum RL。

5. Self-Evolving Curriculum：失败任务如何变成新课程？

这是 WebRL 最核心的设计之一。

论文的基本逻辑是：

如果 Agent 在某类任务上失败，就说明这个区域正好位于 Agent 当前能力边界附近。

与其随机生成大量任务，不如围绕这些失败任务继续生成训练数据。

5.1 用失败任务作为 seed

假设上一阶段模型无法完成：

Fetch the "Order Quantity" from the report on best-selling products between October 1st and 31st, 2022.

那么这个任务会进入 Failure Set。

接下来作者使用 GPT-4o，以这些失败任务作为 examples，通过 in-breadth evolving 的方式生成更多新 instruction。

生成的新任务需要：

  • 保持相同 domain；
  • 与原任务具有相关能力要求；
  • 表达更加多样；
  • 难度大致相近，可以略简单或略困难。

因此不是简单复制失败任务，而是在它附近扩展一个新的任务分布。

5.2 为什么不能直接使用所有生成任务？

LLM 生成出来的任务可能存在两个问题。

第一种是：

太难。

当前 Agent 根本没有能力探索出成功 trajectory。

如果一直训练这种任务：

rollout
→
全部失败
→
reward = 0

还是无法学习。

第二种是：

根本无法在 WebArena 中完成。

例如生成一个网站不存在的功能或者不存在的数据。

所以生成之后必须过滤。

6. 用 Critic 控制 curriculum 难度

作者首先使用当前 Critic 对新 instruction 的初始状态进行评分。

只保留：

\[0.05 < V(s_0,I) < 0.75 \]

的任务。

直观来说：

如果 Critic 给出的 value 很高：

V ≈ 1

说明 Agent 已经非常有把握，这个任务太简单。

如果：

V ≈ 0

则说明当前 Agent 几乎不可能完成，任务太难。

WebRL 希望保留的是：

位于当前 Agent 能力边界附近的任务。

这就是 curriculum learning 的核心。

任务难度并不是提前人工规定：

Easy
Medium
Hard

而是相对于当前 policy 的能力动态确定。

同一个任务：

Phase 1：可能非常困难
Phase 5：可能已经非常简单

因此课程本身会随着 Agent 变化。

6.1 再过滤不可完成任务

仅仅依靠 Critic 仍然不能判断：

这个任务到底能不能在 WebArena 中完成。

作者首先人工分析了一些生成任务，找出典型的 infeasible instruction。

然后根据这些情况构造 Prompt，再调用 GPT-4o 自动判断生成任务是否能在 WebArena 环境中完成。

所以任务生成实际上是：

Failure Tasks
      ↓
GPT-4o 生成新任务
      ↓
Critic 过滤难度
      ↓
GPT-4o 过滤不可执行任务
      ↓
当前 Phase 的 Curriculum

论文实验中，每一个 phase 最终会选取 500 个新的 instruction。

7. Curriculum 到底是如何“演化”的？

论文的 Case Study 很好地解释了这件事。

image

【Figure 8（不同 Phase 下 Self-Evolving Curriculum 生成的任务示例）】

作者观察到课程演化主要出现两类行为。

7.1 第一种：生成相似或更容易的过渡任务

Agent 无法完成一个复杂任务时，并不一定马上生成更难的任务。

系统有时会生成：

  • 任务要求相似；
  • 表达更加明确；
  • 难度稍低；

的新任务。

Agent 先通过这些任务学会对应技能。

随后再回到原来的任务时，就更容易成功。

也就是说，它实际上形成了类似：

困难任务
 ↓
当前不会
 ↓
构造附近较简单任务
 ↓
学习相关技能
 ↓
重新获得解决困难任务的能力

的 curriculum。

7.2 第二种：生成更复杂、更丰富的任务

当某一类能力已经逐渐掌握之后，又会产生：

  • 条件更多；
  • 要求更多；
  • 推理步骤更长；

的新任务。

这样课程会继续推动模型能力边界。

因此作者总结出的整体过程是：

能力边界上的失败任务
        ↓
生成附近任务
        ↓
学会相关能力
        ↓
生成更复杂任务
        ↓
继续扩展能力边界

这就是 WebRL 所谓的 self-evolving curriculum。

需要注意，Figure 8 中相邻两个 Phase 展示的任务不一定存在直接父子生成关系，它们主要是用来展示随着训练进行，整体 curriculum 如何变化。

8. 为什么还需要一个 ORM？

新的 curriculum 是自动生成出来的。

这会导致一个关键问题：

新生成的 instruction 没有 WebArena 官方 reward function。

原始 WebArena 数据可以告诉系统：

这个任务成功了 / 失败了

但是 GPT-4o 新生成的任务不存在预定义 evaluator。

那 RL 的 reward 从哪里来？

WebRL 的解决方案就是：

Outcome-Supervised Reward Model（ORM）

9. ORM：判断一整条 trajectory 是否成功

作者训练一个 LLM 作为 ORM：

\[M_{\mathrm{ORM}} \]

它的任务非常简单：

给定 Agent 的执行结果，判断用户任务最终有没有完成。

ORM 的输入包含：

  1. User Instruction；
  2. Action History；
  3. 最终网页状态的 HTML。

之所以只保留最后一个网页状态的 HTML，是因为完整 trajectory 中的 HTML 太长，会造成严重的 context 开销。

ORM 最终只输出：

YES

或者：

NO

实际判断时比较：

\[P(\text{YES}) \]

和

\[P(\text{NO}) \]

如果：

\[P(\text{YES}) > P(\text{NO}) \]

则认为任务成功：

\[r=1 \]

否则：

\[r=0 \]

因此 ORM 是整个 self-evolving loop 的重要基础设施。

否则系统虽然能够不断自动生成新任务，却无法判断这些新任务有没有完成。

10. ORM 是怎么训练出来的？

WebArena-Lite 本身提供了 1186 条训练样本，每条样本包含：

  • instruction；
  • trajectory；
  • reward function。

作者首先对这些任务进行改写和变量替换，比如修改：

  • 地点名称；
  • 产品名称；
  • 任务表达。

然后让 WebRL 和多个 baseline 在这些任务上 rollout。

因为这些原始任务仍然拥有 WebArena 的真实 reward function，所以可以自动知道：

trajectory → success / failure

最终得到大约 12,200 条样本训练 ORM。

因此这里有一个很重要的数据流：

拥有真实 reward function 的任务
          ↓
收集大量 rollout
          ↓
reward function 自动打标签
          ↓
训练 ORM
          ↓
ORM 学会判断任务是否完成
          ↓
用于后来没有 reward function 的生成任务

换句话说，ORM 相当于把原来有限任务上的 evaluator 能力泛化到了新任务上。

11. WebRL 的 RL 部分解决什么问题？

现在已经有了：

  • 自动生成的新任务；
  • ORM 提供最终 reward。

接下来就可以做 RL。

但是 WebRL 面临一个特殊场景：

Phase 1 学一批任务
Phase 2 换一批任务
Phase 3 又换一批任务
...

如果每一轮都只优化当前 phase：

新任务虽然越来越会做，但以前学到的任务可能不断遗忘。

因此作者重点设计了一个：

KL-constrained policy update

12. KL-Constrained Policy Update

假设：

  • 上一个 phase 的 policy 为 \(\pi_{\mathrm{ref}}\)；
  • 当前需要优化的 policy 为 \(\pi_\theta\)。

WebRL 希望做到两件事：

第一：

新任务要学会。

第二：

新 policy 又不能偏离旧 policy 太远。

论文给出的优化目标为：

\[\max_{\pi_\theta} \mathbb{E}_{I\sim\rho(I),\,a_t\sim\pi_\theta} \left[ \sum_{t=0}^{T} \left( r(s_t,a_t,I) + \beta\log\pi_{\mathrm{ref}}(a_t|s_t,I) \right) + \beta\mathcal{H}(\pi_\theta) \right] \]

其中：

  • \(\rho(I)\)：当前 phase 的任务分布；
  • \(\pi_{\mathrm{ref}}\)：上一阶段 policy；
  • \(\pi_\theta\)：当前正在训练的 policy；
  • \(\mathcal H(\pi_\theta)\)：policy entropy；
  • \(\beta\)：控制 KL constraint 强度。

直观上，这个目标可以理解为：

一方面最大化任务 reward，另一方面限制当前 policy 不要离 reference policy 太远。

13. 从 Advantage 推出 WebRL 的 Policy Loss

作者进一步得到：

\[\beta \log \frac{ \pi^*(a_t|s_t,I) }{ \pi_{\mathrm{ref}}(a_t|s_t,I) } = A^*(s_t,a_t,I) \]

其中 \(A^*\) 表示：

当前 action 相对于这个状态下平均 action 有多好。

因此，如果一个 action 的 advantage 很高：

\[A>0 \]

那么理想 policy 应该提高这个 action 的概率。

如果：

\[A<0 \]

则应该降低其概率。

WebRL 最终构造的 policy loss 为：

\[\mathcal{L}(\pi_\theta) = \mathbb{E}_{\nu} \left[ \left( \beta \log \frac{ \pi_\theta(a|s,I) }{ \pi_{\mathrm{ref}}(a|s,I) } - A^*(s,a,I) \right)^2 \right] \]

其中 \(\nu\) 是训练经验的数据分布。

这个 loss 的直观意义非常重要。

它实际上要求：

\[\beta \log \frac{\pi_\theta}{\pi_{\mathrm{ref}}} \approx A \]

也就是说：

action 的概率应该相对于上一阶段 policy 改变多少，由这个 action 的 advantage 决定。

13.1 Advantage 为正时

如果：

\[A(s,a,I)>0 \]

说明这个 action 是好 action。

模型应该提高：

\[\pi_\theta(a|s,I) \]

但如果当前 policy 相对于 \(\pi_{\mathrm{ref}}\) 已经把这个 action 提高很多了，KL constraint 就会限制它继续无节制增长。

13.2 Advantage 为负时

如果：

\[A(s,a,I)<0 \]

说明这个 action 不好。

模型应该降低这个 action 的概率。

同样，KL constraint 会限制 policy 发生过于激烈的变化。

因此这个更新机制可以简单理解为：

Advantage 决定往哪个方向更新，reference policy 决定最多不要走得太远。

14. Advantage 从哪里来？

真正的 \(A^*\) 不可能直接获得。

所以 WebRL 训练一个 Critic：

\[V(s_t,I) \]

来估计：

从当前网页状态出发，最终完成任务的概率/价值。

由于 Web Agent 中间没有 reward，作者重点结合两种信息：

  1. 下一状态的 value；
  2. 最终任务是否成功。

主文中给出的 advantage estimator 为：

\[A(s_t,a_t,I) = \lambda \left( r(s_t,a_t,I) + V(s_{t+1},I) - V(s_t,I) \right) + (1-\lambda) \left( r(s_T,a_T,I) - V(s_t,I) \right) \]

论文设置：

\[\lambda=0.5 \]

也就是同时参考：

  • one-step value difference；
  • trajectory 最终结果。

附录进一步说明，实际实验中使用 discount factor：

\[\gamma=0.9 \]

因此 Advantage 会同时考虑：

这个 action 有没有让下一状态变得更好，以及整条 trajectory 最终有没有完成任务。

15. 为什么 WebRL 不直接使用 PPO？

论文附录专门讨论了这一点。

PPO 完全可以优化带 KL constraint 的 RLHF-style objective。

问题在于：

PPO 是 on-policy 方法。

也就是说训练过程中需要不断使用当前 policy 重新 rollout 大量数据。

而真实网页交互：

  • 速度慢；
  • 成本高；
  • 环境执行复杂。

因此作者认为 PPO 的 sampling efficiency 不适合 WebArena 这样的环境。

WebRL 特意设计成：

off-policy RL

这样过去收集的 trajectory 也可以继续利用。

15.1 与 DPO 的区别

DPO 依赖 preference pair：

同一个输入
├── preferred response
└── rejected response

但是网页环境很难做到：

回到完全相同的网页状态，然后执行另外一个 action，再观察最终结果。

因此构造 pair-wise trajectory 的成本很高。

WebRL 不依赖这种 pair-wise data。

15.2 与 AWR 的区别

AWR 主要根据 advantage 对行为数据进行加权。

而 WebRL 显式地使用：

\[\pi_{\mathrm{ref}} \]

约束当前 policy。

作者还强调，WebRL 的更新规则能够直接降低负 advantage action 的概率，而 AWR 并不具备完全相同的机制。

因此论文将自己的 policy optimization 定位为：

适用于昂贵网页交互环境的 off-policy、KL-constrained RL。

16. Experience Replay Buffer：防止遗忘

光靠 KL constraint 还不够。

WebRL 又从数据层面引入：

Experience Replay Buffer

每个 phase 中成功完成的 trajectory 会被保存。

后续训练时：

当前阶段的新 rollout
+
过去成功的历史经验

一起训练 Actor 和 Critic。

这样模型学习新任务时仍然不断复习过去能力。

论文还限制：

Replay 的历史数据量最多为当前新 interaction data 的 2 倍。

避免旧经验完全压过新经验。

17. 为什么 Replay Buffer 只存成功 trajectory？

这是一个非常关键的设计。

假设一条 trajectory：

Step 1 正确
Step 2 正确
Step 3 正确
Step 4 错误
Step 5 失败
最终 reward = 0

如果把这条 trajectory 直接拿来 replay：

由于只有最终 outcome reward，算法可能会把：

Step 1
Step 2
Step 3

这些实际上正确的操作也错误地估计成负 advantage。

结果反而降低正确 action 的概率。

因此作者选择：

历史 replay buffer 只保存成功 trajectory。

这样至少可以保证这些历史 trajectory 整体上是正确的。

论文附录也专门进行了实验：

Replay Buffer 中加入 failed trajectories 后，模型提升速度更慢，而且波动更明显。

18. Actor Confidence Filtering：过去的经验也不能全部学

即使全部都是成功 trajectory，也不能无脑 replay。

为什么？

假设有一条经验模型已经熟得不能再熟：

P(action | state) ≈ 1

继续反复训练几乎没有价值。

反过来，如果某条历史 action 对当前模型来说非常陌生：

P(action | state) 极低

强行学习又可能造成很大的 policy shift。

因此作者使用 Actor 计算 replay experience 的 perplexity。

只保留：

\[\mathrm{PPL} \in \left[ \frac{1}{0.95}, \frac{1}{0.5} \right] \]

大约就是：

\[1.05 \sim 2 \]

这个中间区间。

也就是说：

太熟悉       → 不学
中等难度     → 学
过于陌生     → 不学

这实际上又体现了一次 curriculum 的思想：

不只是新任务需要控制难度，历史经验也应该选择当前模型“刚好值得学”的部分。

19. 一轮 WebRL 到底发生什么？

把前面的组件串起来，一轮完整的 Phase 可以概括为：

Step 1：从 Failure Set 中取失败任务

\[\mathcal F \]

保存之前 Agent 没能完成的 instruction。

Step 2：GPT-4o 根据失败任务生成新任务

生成同 domain、相似难度但更加多样的新 instruction。

Step 3：任务过滤

Critic 根据当前模型能力过滤任务，只保留：

\[0.05 < V(s_0,I) < 0.75 \]

的 instruction。

然后再使用 GPT-4o 排除无法在 WebArena 中完成的任务。

每阶段最终选取约 500 个任务。

Step 4：Actor 在这些任务上 rollout

得到新的：

\[D_{\mathrm{rollout}} \]

Step 5：ORM 判断成功还是失败

得到：

\[D_{\mathrm{success}} \]

和：

\[D_{\mathrm{fail}} \]

Step 6：从 Replay Buffer 中选择旧经验

利用 Actor perplexity 找出“中等熟悉度”的历史经验：

\[D_{\mathrm{experience}} \]

Step 7：训练 Actor 和 Critic

训练数据为：

\[D_{\mathrm{rollout}} \cup D_{\mathrm{experience}} \]

Actor 使用 KL-constrained policy update。

Critic 同样同时利用当前 rollout 和历史经验训练。

Step 8：更新 Memory

成功 trajectory 加入 Replay Buffer：

\[\mathcal B \leftarrow \mathcal B \cup D_{\mathrm{success}} \]

失败 instruction 加入 Failure Set：

\[\mathcal F \leftarrow \mathcal F \cup D_{\mathrm{fail}} \]

然后继续下一阶段。

最终形成完整闭环：

失败任务
  ↓
生成课程
  ↓
难度过滤
  ↓
Agent Rollout
  ↓
ORM 判断结果
  ↓
成功 → Replay Buffer
失败 → Failure Set
  ↓
Actor + Critic 更新
  ↓
下一阶段

论文实验中一共进行了 8 个 Phase。

20. 实验设置

作者主要在 WebArena 环境中进行实验。

WebArena 包含多个真实交互式网站环境：

网站 类型
Reddit 社区论坛
GitLab 代码管理
CMS 电商后台管理
Map OpenStreetMap
OSS OneStopShop 电商网站

原始 WebArena 一共有 812 个 instruction。

考虑测试成本，论文使用 WebArena-Lite 中人工验证过的 165 个测试任务进行主要评估。

核心指标为：

Success Rate（SR）

即 Agent 成功完成任务的比例。

21. 主要实验结果

论文最核心的结果如下。

模型 Reddit GitLab CMS Map OSS Avg. SR
GPT-4-Turbo 10.5 16.7 14.3 36.7 13.3 17.6
GPT-4o 10.5 10.0 20.0 20.0 11.1 13.9
AutoWebGLM 6B 9.4 15.0 28.6 24.8 17.1 18.2
GLM-4-9B 5.3 10.0 6.7 3.3 6.7 6.1
GLM-4 + SFT 47.4 13.3 31.4 23.3 13.3 22.4
GLM-4 + DigiRL 63.2 30.0 34.3 26.7 26.7 31.5
GLM-4 + WebRL 57.9 50.0 48.6 36.7 37.8 43.0
Llama-3.1-8B 0.0 3.3 2.9 3.3 11.1 4.8
Llama-3.1-8B + SFT 36.8 6.7 20.0 33.3 17.8 20.6
Llama-3.1-8B + AWR 57.9 26.7 31.4 26.7 17.8 28.5
Llama-3.1-8B + DigiRL 57.9 26.7 37.1 33.3 17.8 30.3
Llama-3.1-8B + WebRL 63.2 46.7 54.3 36.7 31.1 42.4

结果非常明显。

Llama-3.1-8B 从：

\[4.8\% \]

提高到：

\[42.4\% \]

GLM-4-9B 从：

\[6.1\% \]

提高到：

\[43.0\% \]

而同样使用 online RL 的 DigiRL：

  • Llama-3.1-8B：30.3%
  • GLM-4-9B：31.5%

仍然明显低于 WebRL。

作者认为其中一个重要原因就是：

DigiRL 始终使用固定任务集，而 WebRL 会让训练任务随着模型能力变化。

需要注意，论文 Table 1 中 AWM + GPT-4 与 WebPilot + GPT-4o 标有 *，这些数字是文献中在完整 WebArena 上报告的结果，并非全部来自同一个 WebArena-Lite 165-task evaluation 设置，因此解读时需要注意这一点。

22. Scaling：70B 模型是否仍然有效？

作者进一步训练 Llama-3.1-70B。

结果：

方法 Avg. SR
Llama-3.1-70B 12.7
Llama-3.1-70B + SFT 23.0
Llama-3.1-70B + WebRL 49.1

WebRL 相比 SFT 又提高了：

\[49.1-23.0=26.1 \]

个百分点。

因此作者认为 WebRL 并不局限于 8B/9B 规模，在更大的模型上仍然能够获得明显提升。

23. 为什么 RL 比单纯 SFT 更适合 Web Agent？

作者发现一个很典型的现象。

SFT 模型很容易过度模仿 demonstration 中高频出现的动作。

比如 CMS 任务中：

Scroll Down

出现得很多。

SFT 模型可能过度学习：

Scroll Down
Scroll Down
Scroll Down
...

最终陷入循环。

因为 SFT 的目标本质是：

当前状态下模仿 demonstration 的下一步 action。

它并不会直接考虑：

这个 action 最终是否帮助完成整个任务？

而 RL 优化的是 trajectory outcome，因此更加关注长期结果。

24. Error Type 分析

论文将失败分成四种类型：

  • Fail to Recover；
  • Get Stuck Midway；
  • Stop at Wrong Page；
  • Fail to Make Reasonable Attempt。

WebRL 最明显的改进之一是：

减少 Get Stuck Midway。

也就是 Agent 不容易陷入：

同一个操作
↓
还是同一个操作
↓
继续同一个操作

的死循环。

另外一个提升是 Fail to Recover。

例如 Agent 搜索：

Pharmacy near CMU within a 20-minute walking distance

没有得到结果。

较弱的 Agent 可能继续重复相同搜索。

WebRL 训练后的 Agent 则可能修改为：

Pharmacy near CMU

重新探索。

作者认为 curriculum training 帮助模型提高了失败后的恢复能力。

25. 对 Long-Horizon Task 的表现

作者按照完成任务所需要的交互步数进行分析。

结果表明：

  • SFT；
  • Filtered BC；

随着任务步数增加，性能明显下降。

DigiRL 在中等长度任务上较好，但当任务需要：

10 步以上

时性能明显变差。

WebRL 在长任务上的表现更稳定。

作者将这个结果主要归因于 curriculum learning：

固定任务上的 online RL 很难从复杂长任务中获得正 reward。

而 WebRL 可以通过：

相关简单任务
↓
逐渐更复杂
↓
长 horizon 任务

逐步建立能力。

26. 不同任务复杂度上的表现

作者还根据 instruction 中包含多少个要求定义 complexity。

例如：

What are the top-3 best-selling products in Jan 2023?

包含：

  1. 找出 top-3 产品；
  2. 时间限定为 Jan 2023。

因此 complexity level 为 2。

实验表明，随着 instruction complexity 增加：

  • SFT；
  • Filtered BC；
  • AWR；
  • DigiRL；

性能下降更加明显。

WebRL 在复杂 instruction 上仍然保持较明显优势。

这进一步支持了作者的核心论点：

训练任务应该随着模型能力动态变化，而不是从头到尾使用固定任务集。

27. Ablation Study

作者分别移除：

  • Replay Buffer；
  • KL constraint；
  • Curriculum Learning。

8 个 Phase 后的大致结果为：

方法 Success Rate
初始 SFT 20.6%
WebRL w/o KL & Replay Buffer 20.0%
WebRL w/o Replay Buffer 24.8%
WebRL w/o CL 32.7%
WebRL w/o KL 34.5%
完整 WebRL 42.4%

可以看到完整系统明显最好。

27.1 Replay Buffer 的作用

去掉 Replay Buffer 后：

随训练 Phase 增加，性能甚至可能开始下降。

原因是模型不断只学习最新数据，过去能力逐渐遗忘。

因此 replay 的主要作用就是：

防止 continual online learning 中的 catastrophic forgetting。

27.2 KL Constraint 的作用

没有 KL constraint 时，模型更容易：

过拟合当前 Phase 的任务。

尤其当连 Replay Buffer 也删除之后，performance 会快速恶化。

KL constraint 相当于从算法层面限制：

\[\pi_\theta \]

不要偏离上一阶段：

\[\pi_{\mathrm{ref}} \]

太远。

因此：

Replay Buffer → 数据层面的防遗忘
KL Constraint → 参数 / policy 层面的防漂移

二者实际上是互补关系。

27.3 Curriculum Learning 的作用

去掉 Curriculum Learning 后，Agent 依然能够依靠 online RL 提升。

但是：

  • 提升速度更慢；
  • 最终性能更低。

因为训练任务从头到尾保持固定。

这也是 WebRL 和普通 online RL 最大的结构性区别之一。

28. Replay Buffer 应该 replay 什么难度的数据？

作者专门做了 perplexity ablation。

Replay 数据 PPL Success Rate
\([1,\infty)\) 29.1
\([1,1/0.95]\) 27.9
\([1/0.95,1/0.5]\) 31.5
\([1/0.5,\infty)\) 23.0

结果显示：

中等 perplexity 的历史经验效果最好。

过低 perplexity：

模型已经太熟，重复训练反而可能造成过拟合。

过高 perplexity：

对当前 policy 来说过于陌生，容易造成较大的策略漂移。

因此 WebRL 最终使用：

\[\left[ \frac{1}{0.95}, \frac{1}{0.5} \right] \]

作为过滤区间。

29. KL 系数 \(\beta\) 的影响

作者进一步研究 \(\beta\)。

如果：

\[\beta=0.01 \]

太小，那么 KL constraint 太弱。

结果模型容易快速过拟合当前 phase。

但是如果没有 Replay Buffer，而 \(\beta\) 又非常大：

\[\beta \ge 1 \]

模型又会被 reference policy 限制得太死，导致难以学习新任务。

有 Replay Buffer 时，大 \(\beta\) 的负面影响明显减弱。

原因在于：

Replay Buffer 已经提供了多样的旧经验，使模型可以在保持旧能力的同时进行更多有效更新。

因此 WebRL 的稳定性并不是来自某一个单独组件，而是：

KL constraint + Replay Buffer

共同作用的结果。

30. ORM 到底准不准？

因为整个 RL loop 都依赖 ORM 判断：

成功 / 失败

所以 ORM 的准确性非常重要。

论文进行了单独评估：

Reward Evaluator WebArena-Lite Test Rollout
WebRL ORM 8B 80.8% 79.4%
GPT-4 71.9% 71.2%
Captioner + GPT-4 72.6% 73.3%
GPT-4V 71.2% 70.5%

专门训练的 8B ORM 达到了约 80% 准确率，明显高于这些通用模型方案。

这也说明一个比较重要的设计思想：

与其直接让通用大模型判断 Web Agent 是否完成任务，不如利用环境中已有的真实 reward function 构造大量监督数据，训练一个专用 evaluator。

31. Task Generation 是否依赖某一个固定 Prompt？

Self-Evolving Curriculum 使用 GPT-4o 生成训练任务，因此一个自然问题是：

性能是不是碰巧依赖作者写的那个 Prompt？

作者在附录中测试了三个不同版本的生成 Prompt：

Prompt 最终 Success Rate
Prompt 1 42.4
Prompt 2 40.6
Prompt 3 43.6

三种 Prompt 都能够获得较好的结果。

作者据此认为 curriculum learning 对具体生成 Prompt 具有一定稳定性。

32. WebRL 的几个核心组件到底是什么关系？

读完整篇论文后，可以把 WebRL 拆成三个层次。

第一层：课程生成

解决：

数据不够。

Failure Set
↓
GPT-4o Task Generation
↓
Critic Difficulty Filtering
↓
GPT-4o Feasibility Filtering
↓
New Curriculum

第二层：环境反馈

解决：

新任务没有 reward function。

Agent Rollout
↓
Instruction + Action History + Final HTML
↓
ORM
↓
Success / Failure

第三层：RL 更新

解决：

怎样从这些 trajectory 中稳定学习，而且不要忘掉以前能力。

Current Rollout
+
Filtered Replay Experience
↓
Critic → Advantage
↓
KL-Constrained Policy Update
↓
New Actor

三层连接起来：

              ┌──────────────────────────┐
              │      Failure Tasks       │
              └────────────┬─────────────┘
                           ↓
              Self-Evolving Curriculum
                           ↓
                    New Instructions
                           ↓
                     Agent Rollout
                           ↓
                          ORM
                     ↙           ↘
                Success          Failure
                   ↓                ↓
             Replay Buffer      Failure Set
                   ↓                │
                   └──────┐    ┌────┘
                          ↓    ↓
                     Actor + Critic
                          ↓
                   KL-Constrained RL
                          ↓
                      New Policy
                          ↓
                     下一 Phase

这才是 WebRL 真正完整的方法结构。

33. WebRL 中“自进化”的准确含义

从今天常见的 Self-Evolving Agent / Self-Improving Agent 语境回头看这篇论文，特别容易对它的名字产生误解。

WebRL 中真正发生演化的是：

任务分布

\[\mathcal I_1 \rightarrow \mathcal I_2 \rightarrow \cdots \rightarrow \mathcal I_N \]

课程随着 Agent 的失败和能力变化不断变化。

与此同时，模型 policy 通过 RL：

\[\pi_1 \rightarrow \pi_2 \rightarrow \cdots \rightarrow \pi_N \]

不断更新。

但是 framework 本身，例如：

  • Actor / Critic 结构；
  • ORM 机制；
  • Replay Buffer；
  • Action Space；
  • 训练算法；

并不会被 Agent 自主修改。

因此 WebRL 的“Self-Evolving”本质上主要是：

数据课程和 policy 在闭环交互中共同迭代。

而不是：

Agent 自己重新设计自己的 harness。

34. 论文的实现边界

论文没有单独设置 Limitations 章节，不过正文和附录中可以看到几个明确的实验与实现边界。

34.1 Task Generation 仍然使用 GPT-4o

虽然最终训练出来的是开源 Llama / GLM Web Agent，但 Curriculum 中：

  • 新 instruction 生成；
  • infeasible instruction 过滤；

仍然使用 GPT-4o。

因此这里所谓的 open LLM Web Agent，并不意味着整个训练 pipeline 完全不依赖 proprietary model。

这是论文实现流程本身体现出的事实，作者没有将其单独列为 limitation。

34.2 ORM 不是 Oracle

ORM 在 rollout 上的准确率约为：

\[79.4\% \]

因此它仍然可能产生 reward noise。

WebRL 的训练实际依赖一个学习得到的 outcome evaluator，而不是完全准确的环境 reward。

34.3 实验范围集中在 WebArena

论文主要验证了：

  • Reddit；
  • GitLab；
  • CMS；
  • Map；
  • OSS；

五类 WebArena 环境。

论文没有进一步给出跨 Web Agent benchmark 或完全不同交互环境上的系统性验证。

34.4 不同网站之间仍然存在能力 trade-off

附录中作者观察到：

大多数网站随着 phase 增加呈现明显上升趋势。

但 Map：

先提升，后下降。

作者推测，OSS 与 CMS 上的大幅提升可能带来了不同网站能力之间的 trade-off，同时 GitLab 后期也有轻微下降。

因此即使加入 KL constraint 和 replay buffer，也不能保证所有 domain 上的能力都严格单调增长。

35. 总结

WebRL 的目标是解决一个非常现实的问题：

如何真正利用在线环境，通过 RL 把能力较弱的开源 LLM 训练成强 Web Agent？

作者认为仅仅使用固定训练集是不够的，因为 Agent 很快会遇到：

  1. 训练任务不足；
  2. Reward 极度稀疏；
  3. 新旧能力互相干扰。

因此 WebRL 建立了一套完整闭环：

SFT 初始化 Agent
↓
Agent 与网页环境交互
↓
ORM 判断成功 / 失败
↓
失败任务进入 Failure Set
↓
GPT-4o 根据失败任务生成新 instruction
↓
Critic 筛选符合当前能力的任务
↓
形成新的 Curriculum
↓
Agent 再次 Rollout
↓
KL-Constrained Off-Policy RL
↓
成功经验进入 Replay Buffer
↓
Actor Confidence Filtering 选择合适历史经验
↓
继续下一 Phase

其中最核心的几个设计可以概括为：

组件 作用
Self-Evolving Curriculum 从失败任务出发，不断生成新的训练任务
Critic Difficulty Filtering 让任务难度匹配当前 Agent 能力
ORM 为没有预定义 reward function 的新任务判断成功/失败
KL-Constrained RL 防止新 policy 过度偏离上一阶段 policy
Replay Buffer 保存过去成功经验，缓解遗忘
Actor Confidence Filtering 只 replay 当前模型中等难度的经验

最终，WebRL 将：

  • Llama-3.1-8B：4.8% → 42.4%
  • GLM-4-9B：6.1% → 43.0%
  • Llama-3.1-70B：12.7% → 49.1%

显著提高了 WebArena-Lite 上的任务成功率。

因此这篇论文的核心并不只是提出了某一个新的 RL loss，而是构建了一套面向 Web Agent 的 online RL training loop：

让训练任务跟着 Agent 的能力一起变化，同时通过 ORM、KL constraint 和经验回放维持一个能够持续学习的闭环。

参考

  1. Zehan Qi, Xiao Liu, et al. WebRL: Training LLM Web Agents via Self-Evolving Online Curriculum Reinforcement Learning. ICLR 2025.
    https://arxiv.org/abs/2411.02337

  2. OpenReview：
    https://openreview.net/forum?id=oVKEAFjEqv

  3. WebRL GitHub：
    https://github.com/THUDM/WebRL

  4. WebArena：
    Zhou et al. WebArena: A Realistic Web Environment for Building Autonomous Agents.

posted @ 2026-10-22 21:45  YourF4u1t  阅读(22)  评论(0)    收藏  举报