分享：PyTorch强化学习实战（23）——强化学习在网页导航中的应用

今天翻到一篇不错的技术分享，看完之后自己也琢磨了一下，把思路梳理记录下来。

PyTorch强化学习实战（23）——强化学习在网页导航中的应用

0. 前言
1. 网页导航的演进历程
2. 浏览器自动化
2.1 浏览器自动化与强化学习
2.2 浏览器自动化面临的挑战

3. MiniWoB 基准测试 4. MiniWoB++

4.1 安装
4.2 动作与观测空间
4.3 简单示例

5. 简单点击策略

5.1 网格化动作空间
5.2 强化学习达成
5.3 模型训练
5.4 训练结果

6. 简单点击的局限性 7. 拓展探索方向小结系列链接

0. 前言

在本节中，我们将探讨强化学习 (Reinforcement Learning, RL)在网页导航和浏览器自动化中的实际应用，展示如何将 RL 办法应用于实际问题，包含可能遇到的挑战及其解决方案。

1. 网页导航的演进历程

互联网诞生之初，仅由通过超链接互联的纯文本网页构成。第一个网页东西仅包含文本与链接。用户只能阅读文本并通过点击链接跳转页面。
1995 年，互联网工程任务组 (Internet Engineering Task Force, IETF) 发布了 HTML 2.0 规范，对原始版本进行了大量扩展。其中最重要的扩展是表单及表单元素，使网页开发者可以为网站添加交互功能。用户可输入修改文本、切换复选框、选择下拉列表及点击按钮——这些控件与极简图形用户界面 (Graphical User Interface, GUI) 应用程序的控制组件相似。不同之处在于，这一切都发生在浏览器窗口内，且用户交互的数据和界面控件均由服务器页面定义，而非本地安装的应用程序。
今天，我们已能在浏览器中运行 JavaScript、HTML5 画布甚至微软 Office 应用程序。桌面应用与网页的界限已经变得模糊，用户有时难以分辨自己使用的是网页还是原生应用。但本质上，网页仍然是浏览器在解析 HTML 并通过 HTTP 协议与外界通信。
网页导航的核心定义为用户与网站交互的过程。通过点击链接、输入文本或执行其他操作，用户可达成发送邮件、查询天气、查看最新通知等目标。既然这些都能通过网页导航完成，那么强化学习智能体能否学会完成相同任务。

2. 浏览器自动化

长期以来，网站交互自动化主要聚焦于网站测试和网络爬虫这两大实际任务。
网站测试在复杂网站开发中尤为重要，用于确保网站按预期功能运行。例如，若某个重新设计的登录页面即将部署到线上网站，就必须确保新设计在用户输入错误密码、点击"忘记密码"等场景下能正常响应。一个复杂网站可能包含数百甚至数千个需要每次发布时测试的用例，因此这些功能都应达成自动化。
网络爬虫则致力于大规模从网站提取数据。例如，若要构建一个聚合全市所有火锅店价格的系统，可能需要处理数百个不同网站，其搭建和维护都将面临挑战。爬虫工具通过提供从简单 HTTP 请求与 HTML 解析，到完全模拟用户移动鼠标、点击按钮、反应延迟等完整交互功能来解决这些问题。

2.1 浏览器自动化与强化学习

传统的浏览器自动化通常允许通过程序控制真实浏览器(如 Chrome 或 Firefox)，既可观察网页数据(如文档对象模型 DOM 树和对象屏幕位置)，也能执行操作(如移动鼠标、按键、后退或运行 JavaScript 代码)。这与强化学习的设置明显契合：智能体通过执行动作并观察状态来与网页及浏览器交互。奖励机制则需根据具体任务设定，例如成功填写表单或跳转到目标信息页面。
能学习浏览器任务的系统其实际应用与上述场景紧密相关，主要包含：

对于超大型网站，使用"向左移动鼠标 5 像素随后点击左键"这类底层浏览器操作定义测试流程极其繁琐。理想方式是向系统展示操作示例，让其能泛化并在所有类似场景中复现行为，至少确保在 UI 重新设计、按钮文本更改等情况下保持稳定性
在许多需要预先发现系统弱点的场景中(如安全漏洞检测)，RL 智能体可以极快速度尝试大量异常操作——远超人类效率。虽然安全测试的动作空间巨大，随机点击效果不及经验丰富的人类测试员，但基于 RL 的系统有望融合人类先验知识，同时保持自主探索学习能力
RL 浏览器自动化的另一个潜在应用领域是大规模爬虫与网络数据提取。例如从数十万个酒店预订、租车服务等各类网站抓取数据时，往往需要先填写参数表单才能获取目标数据。由于不同网站的设计布局和自然语言灵活性，这项任务变得异常复杂。RL 智能体可通过可靠且大规模的数据提取，显著节省时间与人力成本

2.2 浏览器自动化面临的挑战

虽然基于强化学习的浏览器自动化具有潜在的实际应用前景，但有一个相当严重的缺点：其规模过于庞大，难以用于研究办法比较。实际上，实现一个完整的网络爬虫系统可能需要耗时数月，而大部分问题(如数据收集、浏览器引擎通信、输入输出表征等实际生产系统开发涉及的环节)与强化学习并无直接关联。
若过度关注这些技术细节，极易陷入"见树不见林"的困境。这正是研究人员钟爱 MNIST、ImageNet 和 Atari 系列等基准数据集的原因。但并非所有问题都适合作为基准测试：理想基准既要足够简单以支持快速实验和办法比较，又需具备足够挑战性并为改进留出空间。以 Atari 基准为例，它包含从半小时即可解决的简单游戏(如 Pong)，到近期才被攻克的复杂游戏。接下来，我们将介绍浏览器自动化领域中的基准测试。

3. MiniWoB 基准测试

2016 年，OpenAI 发布了包含 80 个基于浏览器任务的 MiniWoB 数据集。这些任务通过像素级观测(严格来说，除像素外还会向智能体提供文本任务描述)，并要求通过虚拟网络计算 (Virtual Network Computing, VNC) 客户端使用鼠标和键盘进行交互。VNC 是一种标准远程桌面协议，允许客户端通过网络使用鼠标键盘连接并操作服务器的 GUI 应用程序。
这 80 项任务在复杂度和所需操作上差异显著：有些任务相当简单，例如"点击对话框关闭按钮"或"按下唯一按钮"；但有些则需要多步操作，如"展开折叠分组并点击包含特定文本的链接"，或"使用日期选择工具选择特定日期"(该日期每轮随机生成)。部分任务对人类很简单但需字符识别能力，例如"标记包含此文本的复选框"(文本随机生成)。下图展示了 MiniWoB 部分任务的屏幕截图：

尽管 MiniWoB 创意卓越且极具挑战性，但 OpenAI 在初始发布后几乎立即放弃了该工程。之后，斯坦福大学研究团队发布了升级版 MiniWoB++，不仅增加了更多任务，还重构了系统架构。

4. MiniWoB++

与采用 VNC 协议和真实浏览器交互的方式不同，MiniWoB++ 使用 Selenium 库实现浏览器自动化，显著提升了环境性能与稳定性。目前该工程由 Farama 基金会维护，在本节中，我们将使用其最新版本，但在深入了解 RL 部分之前，我们需要先理解 MiniWoB++ 的开发原理。

4.1 安装

原始 MiniWoB 依赖 VNC 和 OpenAI Universe，导致安装使用异常复杂。但如今流程已大幅简化：无需再处理 Docker 和 VNC。Selenium 库隐藏了所有与浏览器的交互复杂度，浏览器会在后台以无头模式启动。虽然 Selenium 支持多种浏览器，但 MiniWoB++ 开发团队推荐使用 Chrome 或 Chromium，因为其他浏览器可能呈现不同的渲染效果。
除通过 pip install miniwob 安装 MiniWoB++ 包外，还需在系统中配置 chromedriver。这个小型二进制文件负责与浏览器通信并使其运行在"测试模式"。chromedriver 版本必须与已安装 Chrome 版本严格匹配(可通过 Chrome→关于 Google Chrome 查看版本)，下载对应平台和版本的 chromedriver 压缩包。
需要留意的是，除了 ChromeDriver 压缩包，还提供了完整版本的 Chrome 压缩包，但通常无需下载。压缩包内仅含 chromedriver 二进制文件，需将其置于系统 PATH 路径中( Mac 和 Linux 系统可通过 which chromedriver 命令验证，若未显示路径则需修改 PATH)。安装完成后可运行 wob_create.py 测试：若配置正确，将出现显示任务的浏览器窗口并持续 2 秒。

4.2 动作与观测空间

与Atari 游戏和其他 Gym 环境相比，MiniWoB 提供了一个更为通用的动作空间。Atari 游戏通常对应 6-7 个离散动作(控制器按钮与摇杆方向)，CartPole 的动作空间甚至仅含 2 个动作。而浏览器赋予智能体的操作自由度则大得多：先来看，完整键盘(包含控制键与每个按键的上下状态)全部开放使用。这意味着智能体可以同时按下 10 个按键——从 MiniWoB 视角看这完全可以。其次，鼠标动作空间允许移动至任意坐标并控制按键状态，这显著增加了智能体需要学习的动作空间维度。此外还支持双击和鼠标滚轮上下滚动事件。
观测空间方面，MiniWoB 也丰富得多。完整观测值以字典形式呈现，包含以下数据：

任务描述的文本，例如：“点击按钮 ONE” 或 “在 TicTacToe 中扮演 X，赢得游戏”
屏幕的像素值( RGB 值)
底层网页所有 DOM 元素及其属性列表(尺寸、颜色、字体等)

除此之外，还可通过底层浏览器获取更多信息(例如 CSS 属性或原始 HTML 数据等未直接提供的细节)。由此可见，该任务集为实验提供了极大灵活性：既可专注于任务的视觉层面(像素级操作)，也可利用 DOM 信息(环境允许点击特定元素)，甚至结合 NLP 组件——通过理解任务描述来规划动作方案。

4.3 简单示例

为获得 MiniWoB 的实战经验，我们先来看分析用于验证安装的程序 wob_create.py。

(1) 先来看，需要在 Gymnasium 中注册 MiniWoB 环境，通过 register_envs() 函数实现：

import time
import gymnasium as gym
import miniwob
from miniwob.action import ActionTypes

RENDER_ENV = True

if __name__ == "__main__":
    gym.register_envs(miniwob)

实际上这个 register_envs() 函数并无具体操作(所有环境在模块导入时已自动注册)，但 IDE 会智能提示未使用模块，因此该方法让 IDE 认为模块正在被使用。

(2) 接着通过标准 gym.make() 方法创建环境：

env = gym.make('miniwob/click-test-2-v1', render_mode='human' if RENDER_ENV else None)
    print(env)
    try:
        # Start a new episode.
        obs, info = env.reset()
        print("Obs keys:", list(obs.keys()))
        print("Info dict:", info)
        assert obs["utterance"] == "Click button ONE."
        assert obs["fields"] == (("target", "ONE"),)
        print("Screenshot shape:", obs['screenshot'].shape)

本节使用 click-test-2 问题——要求点击随机分布在网页上的两个按钮之一。Farama网站提供了完整的环境列表可供探索。创建环境时传入 render_mode 参数：若设为 ‘human’，将在后台显示浏览器窗口。下图展示了该窗口界面：

(3) 运行程序后将显示环境对象及观测信息。输出结果如下所示：

$ python adhoc/wob_create.py

可以看到，获取了 utterance (需要执行的任务描述)、DOM 元素(网页元素数据
)、screenshot (与 Atari 平台尺寸完全相同的屏幕截图)以及 fields (DOM 树中与任务相关的关键元素)。

(4) 通过遍历 dom_elements 列表找到需要点击的任务元素：

if RENDER_ENV:
            # to let you look at the environment.
            time.sleep(2)

        # Find the HTML element with text "ONE".
        target_elems = [e for e in obs['dom_elements'] if e['text'] == "ONE"]
        assert target_elems
        print("Target elem:", target_elems[0])

遍历观测值中的 dom_elements 字段，筛选出文本东西为"ONE"的元素。找到的元素包含丰富的属性集：

(5) 获取元素引用(整型标识符)并创建 CLICK_ELEMENT 动作：

action = env.unwrapped.create_action(
            ActionTypes.CLICK_ELEMENT, ref=target_elems[0]["ref"])
        obs, reward, terminated, truncated, info = env.step(action)
        print(reward, terminated, info)
    finally:
        env.close()

如前所述，MiniWoB 提供了丰富的可执行动作。此特定动作模拟了鼠标点击指定 DOM 元素的操作。执行此动作后，应当获得奖励：

0.7993 True {'done': True, 'env_reward': 0.7993, 'raw_reward': 1, 'reason': None, 'elapsed': 5.264345169067383}

如果通过设置 RENDER_ENV = False 禁用渲染，控制台和浏览器的所有操作都将隐藏。此模式还会获得更高奖励，因为奖励会随时间递减。

5. 简单点击策略

为了开始进行网页导航，我们首先实现一个基于图像观测决定点击位置的简易异步优势演员-评论家 (Asynchronous Advantage Actor-Critic, A3C) 智能体。该方法仅能解决 MiniWoB 任务集中的一小部分，后续我们将讨论这种方法的局限性，但目前它有助于更好地理解问题本质。在本节中，而是重点分析核心函数并简要概述其余部分。

5.1 网格化动作空间

MiniWoB 架构中动作空间的丰富性和灵活性给 RL 智能体带来巨大挑战。浏览器活动区域虽仅有 210×160 像素，但即使在这么小的区域内，智能体也可能需要执行鼠标移动、点击、拖拽等操作。单就鼠标控制而言，极端情况下智能体可能执行的动作组合近乎无限——例如在某点按下鼠标按钮并拖拽至其他位置。本节中我们将大幅简化问题：仅考虑在网页活动区域内固定网格点上的点击操作。动作空间示意图如下：

(1) 在 MiniWoB 的原始版本中，此类动作的包装器已存在于 OpenAI Universe。但由于 MiniWoB++ 未提供该功能，我们在 wob.py 模块中自行实现，首先从构造函数开始：

# Constants for MiniWoB
WIDTH = 160
HEIGHT = 210
Y_OFS = 50

# default size of the clicking bin - square area we can click
BIN_SIZE = 10

WOB_SHAPE = (3, HEIGHT, WIDTH)

class MiniWoBClickWrapper(gym.ObservationWrapper):
    FULL_OBS_KEY = "full_obs"

    def __init__(self, env: gym.Env, keep_text: bool = False,
                 keep_obs: bool = False, bin_size: int = BIN_SIZE):
        super(MiniWoBClickWrapper, self).__init__(env)
        self.bin_size = bin_size
        self.keep_text = keep_text
        self.keep_obs = keep_obs
        img_space = spaces.Box(low=0, high=255, shape=WOB_SHAPE, dtype=np.uint8)
        if keep_text:
            self.observation_space = spaces.Tuple(
                (img_space, spaces.Text(max_length=1024)))
        else:
            self.observation_space = img_space
        self.x_bins = WIDTH // bin_size
        count = self.x_bins * ((HEIGHT - Y_OFS) // bin_size)
        self.action_space = spaces.Discrete(count)

在构造函数中，我们创建了观测空间( 3×210×160 的张量)和动作空间——当网格单元尺寸为 10 时，对应 256 个离散动作。作为可选功能，可要求包装器保留待执行任务的文本，该功能将在本节后续示例中使用。随后提供类方法以创建特定配置的环境：

@classmethod
    def create(cls, env_name: str, bin_size: int = BIN_SIZE, keep_text: bool = False,
               keep_obs: bool = False, **kwargs) -> "MiniWoBClickWrapper":
        gym.register_envs(miniwob)
        x_bins = WIDTH // bin_size
        y_bins = (HEIGHT - Y_OFS) // bin_size
        act_cfg = ActionSpaceConfig(
            action_types=(ActionTypes.CLICK_COORDS, ), coord_bins=(x_bins, y_bins))
        env = gym.make(env_name, action_space_config=act_cfg, **kwargs)
        return MiniWoBClickWrapper(
            env, keep_text=keep_text, keep_obs=keep_obs, bin_size=bin_size)

(2) 除创建并包装环境外，我们还要求使用自定义的 ActionSpaceConfig 来适配网格尺寸。通过此定制化配置，需要传入网格单元的 (x,y) 坐标来执行点击动作。接着定义辅助方法，将完整观测字典转换为所需格式。reset() 方法直接调用此方法：

def _observation(self, observation: dict) -> np.ndarray | tt.Tuple[np.ndarray, str]:
        text = observation['utterance']
        scr = observation['screenshot']
        scr = np.transpose(scr, (2, 0, 1))
        if self.keep_text:
            return scr, text
        return scr

    def reset(self, *, seed: int | None = None, options: dict[str, tt.Any] | None = None) \
            -> tuple[gym.core.WrapperObsType, dict[str, tt.Any]]:
        obs, info = self.env.reset(seed=seed, options=options)
        if self.keep_obs:
            info[self.FULL_OBS_KEY] = obs
        return self._observation(obs), info

(3) 最终是封装器的核心 step() 方法：

def step(self, action: int) -> tt.Tuple[
        gym.core.WrapperObsType, gym.core.SupportsFloat, bool, bool, dict[str, tt.Any]
    ]:
        b_x, b_y = action_to_bins(action, self.bin_size)
        # click to last two rows might cause MoveOutOfBounds exception
        b_y = min(b_y, 13)
        new_act = {
            "action_type": 0,
            "coords": np.array((b_x, b_y), dtype=np.int8),
        }
        obs, reward, is_done, is_tr, info = self.env.step(new_act)
        if self.keep_obs:
            info[self.FULL_OBS_KEY] = obs
        return self._observation(obs), reward, is_done, is_tr, info

def action_to_bins(action: int, bin_size: int = BIN_SIZE) -> tt.Tuple[int, int]:
    row_bins = WIDTH // bin_size
    b_y = action // row_bins
    b_x = action % row_bins
    return b_x, b_y

为执行动作，我们需要将网格单元索引( 0-255 范围内)转换为单元的 (x,y) 坐标。随后向底层 MiniWoB 环境传递一个包含 action_type=0 (即环境创建时使用的 ActionSpaceConfig 中的索引)的字典，以及包含这些单元坐标的 NumPy 数组。
clicker.py 文件提供了一个演示包装器的小程序，该程序对 click-dialog-v1 任务采用暴力点击策略：目标是通过点击带叉角的按钮来关闭随机位置的对话框。此示例通过顺序点击全部 256 个网格单元来演示封装器功能。

5.2 强化学习实现

通过观测和动作的转换，RL 部分变得相对直接。我们将使用异步优势演员-评论家 (Asynchronous Advantage Actor-Critic, A3C) 方法训练智能体，使其能根据 160×210 的观测数据决定点击哪个网格单元。除输出 256 个网格单元概率分布的策略外，智能体还会估计状态价值，该值将作为策略梯度估计的基线。本节包含以下几个模块：

common.py：本节示例共享的方法，包括 RewardTracker 和 unpack_batch 函数
model.py：模型定义
wob.py：包含 MiniWoB 相关代码，如环境包装器和其他工具函数
wob_click_train.py：用于训练点击模型的脚本
wob_click_play.py：加载模型权重并在单环境中运行，记录观测值和奖励统计的脚本

5.3 模型训练

该模型采用与其他 A3C 示例中相同的模式，结构相当简洁。由于未花费大量时间优化调整架构和超参数，最终结果很可能存在显著改进空间(可基于目前所学自行尝试优化)。以下是包含两个卷积层、单层策略头和价值头的模型定义：

class Model(nn.Module):
    def __init__(self, input_shape: tt.Tuple[int, ...], n_actions: int):
        super(Model, self).__init__()

        self.conv = nn.Sequential(
            nn.Conv2d(input_shape[0], 64, 5, stride=5),
            nn.ReLU(),
            nn.Conv2d(64, 64, 3, stride=2),
            nn.ReLU(),
            nn.Flatten(),
        )
        size = self.conv(torch.zeros(1, *input_shape)).size()[-1]
        self.policy = nn.Linear(size, n_actions)
        self.value = nn.Linear(size, 1)

    def forward(self, x: torch.ByteTensor) -> tt.Tuple[torch.Tensor, torch.Tensor]:
        xx = x / 255.0
        conv_out = self.conv(xx)
        return self.policy(conv_out), self.value(conv_out)

训练脚本在 wob_click_train.py 中，我们使用 AsyncVectorEnv 运行 8 个并行环境，这会在后台启动 8 个 Chrome 实例。若机器内存允许，可增加此数值并观察对训练的影响。

5.4 训练结果

默认使用 click-dialog-v1 问题进行训练，下图展示了平均奖励与步数的变化曲线：

episode_steps 图显示每回合结束前智能体执行动作的平均次数。理想情况下此问题应为 1 次(只需点击对话框关闭按钮)，但实际需要 7-9 帧才能结束回合。原因有二：对话框关闭按钮的叉号图标可能出现延迟显示，且容器内浏览器从点击到获得奖励存在时间间隙。
要检验学习策略，可使用 wob_click_play.py 工具加载模型并在单环境中运行。该工具通过多个回合测试模型平均性能：

$ python3 wob_click_play.py -m saves/click-dialog-v1_t/best_0.992_3629776.dat --verbose
0 0.9186 True {'done': True, 'env_reward': 0.9186, 'raw_reward': 1, 'reason': None, 'elapsed': 0.8150041103363037}
Round 0 done
Done 1 rounds, mean steps 1.00, mean reward 0.919

若以 --render 命令行参数启动，将在智能体操作过程中显示浏览器窗口。

6. 简单点击的局限性

但上述方法仅适用于解决相对简单的问题(如点击对话框)。若尝试处理更复杂任务，则难以收敛。原因如下：
首先，我们的智能体是无状态的——其决策仅基于当前观测，而未考虑先前动作。我们已经讨论了马尔科夫决策过程 (Markov Decision Process, MDP) 的马尔科夫性质，马尔可夫性允许我们丢弃所有历史记录，仅保留当前观测。但在 MiniWoB 中，即使相对简单的问题也可能违反马尔可夫性。例如"点击按钮序列"问题，界面如下图所示，要求智能体先点击按钮 ONE，再点击按钮 TWO。即使智能体侥幸按正确顺序随机点击成功，它也无法从单张图像中分辨下一步该点击哪个按钮。

尽管这个问题看似简单，我们却无法使用 RL 方法解决，因为 MDP 形式体系在此已不适用。这类问题被称为部分可观测马尔可夫决策过程 (Partially Observable MDP, POMDP)，通常的解决方案是让智能体保持某种状态。这里的挑战在于如何平衡信息保留：既要维持最小相关信息量，又要避免因将所有信息纳入观测而让智能体淹没于无关数据中。
我们可能面临的另一个问题是：解决任务所需的数据可能未包含在图像中，或以不便使用的形式存在。例如，点击标签页 (click-tab) 和点击复选框 (click-checkboxes) 两个问题，如下图所示：

第一个任务要求点击三个标签页中的指定页，但每次需要点击的标签页随机选定。目标标签页通过描述文本指明(包含在观测的文本字段中并显示在环境页面顶部)，但我们的智能体仅能获取像素信息——这导致其难以将顶部微小的数字与随机点击结果关联起来。
点击复选框任务的情况更为复杂：需要点击多个带有随机生成文本的复选框。防止过拟合的一种可行方案是使用光学字符识别 (Optical Character Recognition, OCR) 网络将观测图像转换为文本形式。另一种方法是将文本描述融入智能体的观测中。
另一个问题涉及智能体需要探索的动作空间维度。即使对于单次点击问题，动作数量也可能非常庞大，导致智能体需花费大量时间才能发现正确行为模式。可能的解决方案之一是将示范数据纳入训练过程。如下图所示的"计数边数 (count-sides)"问题，目标是点击与所示形状边数对应的按钮：

该问题通过将人类示范数据加入训练可以拿到解决。实验表明，从零开始的训练在经过一整天后仍无进展，但加入几十个正确点击示例后，模型仅在 15 分钟训练内就成功解决了问题。当然我们还可以花时间进一步调整超参数，但示范数据的效果已足够显著。后续学习将介绍如何记录并注入人类示范数据以提升收敛效果。

7. 拓展探索方向

本节我们仅初步探索了 MiniWoB++——从 100 多个问题中挑选了最简单环境进行研究，前方仍有大量未开发领域。若希望深入实践，以下方向值得尝试：

测试示范数据对噪声点击的鲁棒性
通过预测点击位置的 x 和 y 坐标改进点击方法的动作空间
使用 DOM 数据替代(或结合)屏幕像素，使预测目标转为需要点击的树状结构元素
尝试其他类型问题：涵盖键盘事件生成、动作序列规划等多种需求

最新发布的 LaVague 工程使用 LLM 实现网页自动化，其方法是让 LLM 生成执行特定任务的 Selenium Python 代码。我们可以尝试将其应用于 MiniWoB++ 问题。

小结

在本节中，探讨了强化学习方法在浏览器自动化中的实际应用，并使用了 MiniWoB++ 基准测试。浏览器自动化(以及与人类常用软件的交互)将是未来人工智能发展的重要方向。

系列链接

本次分享就到这里。技术这东西越研究越有意思，后续有新的收获我也会继续更新。

小丸子博客

分享：PyTorch强化学习实战（23）——强化学习在网页导航中的应用

PyTorch强化学习实战（23）——强化学习在网页导航中的应用

0. 前言

1. 网页导航的演进历程

2. 浏览器自动化

2.1 浏览器自动化与强化学习

2.2 浏览器自动化面临的挑战

3. MiniWoB 基准测试

4. MiniWoB++

4.1 安装

4.2 动作与观测空间

4.3 简单示例

5. 简单点击策略

5.1 网格化动作空间

5.2 强化学习实现

5.3 模型训练

5.4 训练结果

6. 简单点击的局限性

7. 拓展探索方向

小结

系列链接

评论 (0)