ServiceNow/BrowserGym 是什么？

BrowserGym 是 ServiceNow 开源的 Web 任务自动化 Gym 环境，把 MiniWoB、WebArena、WorkArena 等九个基准统一到同一套 gymnasium 接口下。它解决的是评测接入的重复劳动，但代价是每个基准仍要单独配置，且官方明确说它不是消费级产品。

ServiceNow/BrowserGym 可以商用吗？

请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。

ServiceNow/BrowserGym 还在维护吗？

在维护。仓库最近一次提交在 60 天前。

ServiceNow/BrowserGym 是用什么编程语言写的？

主要是 Python（依据 GitHub 的语言统计）。

BrowserGym 评测框架解析：Gym 接口、基准接入与真实限制

秒懂

它是什么？: BrowserGym 是 ServiceNow 开源的 Web 任务自动化 Gym 环境，把 MiniWoB、WebArena、WorkArena 等九个基准统一到同一套 gymnasium 接口下。它解决的是评测接入的重复劳动，但代价是每个基准仍要单独配置，且官方明确说它不是消费级产品。
适合谁用？: 如果你在做 Web 智能体研究，需要把同一个 agent 跑在 MiniWoB、WebArena、WorkArena 等多个基准上做横向对比，BrowserGym 的 gymnasium 接口能省掉为每个基准重写交互循环的工作，值得先装 browsergym-core 跑通 openended 任务再逐个加基准包。如果你要的是能直接交付给业务方的浏览器自动化工具，或者无法接受为每个基准单独准备环境（WebArena 需要自建站点、WorkArena 需要 ServiceNow 实例），这个项目不合适，README 自己就写了它不是消费级产品。
能商用吗？: 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
还在维护吗？: 在维护。仓库最近一次提交在 60 天前。
用什么语言写的？: 主要是 Python（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年9月10日 · ServiceNow/BrowserGym

它替代的不是 Playwright，而是每个基准各自的胶水代码

做 Web 智能体研究的人通常不缺浏览器控制能力，Playwright 已经能做点击和输入。缺的是评测：同一个 agent 要在 MiniWoB 上跑一遍，再在 WebArena 上跑一遍，两边的任务定义、观测格式、奖励计算、终止条件都不一样，每换一个基准就要重写一遍 agent 与环境之间的循环。BrowserGym 要消掉的就是这部分重复劳动。它把每个基准包装成一个 gymnasium 环境，agent 侧只需要面对 obs、reward、terminated、truncated、info 这五个量。README 里那段 openended 任务的样板代码就是这个意思：env.reset() 之后进入 while 循环，agent 产出 action，env.step(action) 返回结果，循环直到终止。换成 MiniWoB 或 WebArena，改变的是 gym.make 的环境 id，循环结构不动。目标读者是研究者和基准作者，不是想给业务系统加自动化的工程团队。README 顶部那条警告写得很直白：它用来加速 Web 智能体研究，不是消费级产品，使用需谨慎。

环境 id 是这套抽象的落点

BrowserGym 的机制里最实在的一点是命名约定。每个基准包被 import 时向 gymnasium 注册自己的环境，id 形如 browsergym/miniwob.choose-list、browsergym/workarena.servicenow.order-ipad-pro、browsergym/webarena.310、browsergym/visualwebarena.721、browsergym/assistantbench.validation.3。前缀是基准名，点号后面是具体任务。README 给出的枚举方式是直接遍历 gym.envs.registry.keys()，用 startswith 过滤出某个基准下的全部任务。这意味着任务发现不需要读额外的清单文件，注册表本身就是清单。对写实验脚本的人来说，这比维护一份 YAML 任务列表省事，但代价是环境 id 的语义完全依赖各基准包的注册代码，README 没有给出跨基准统一的命名规范说明，不同基准的点号后段格式并不一致（有的是任务名，有的是数字编号）。

从 pip 到能跑，中间隔着每个基准自己的 README

安装本身是分层的。README 列出 pip install browsergym 装全部，browsergym-experiments 装实验工具加下层，browsergym-core 只装核心功能且不带任何基准，只提供 openended 任务，其余按基准拆成 browsergym-miniwob、browsergym-webarena、browsergym-webarena-verified、browsergym-visualwebarena、browsergym-workarena、browsergym-assistantbench、browsergym-timewarp，WebLINX 走的是另一个包名 weblinx-browsergym。装完还要跑 playwright install chromium，浏览器由 Playwright 提供。真正的工作量在下一步：README 明确说每个基准都有各自的额外配置步骤，并逐个指向 miniwob/README.md、webarena/README.md、webarena_verified/README.md、visualwebarena/README.md、assistantbench/README.md，WorkArena 指向它自己的仓库，OpenApps 指向 Facebook Research 的文档站，TimeWarp 指向 sparklabutah/timewarp。也就是说 pip 只解决了代码依赖，环境依赖（站点、账号、数据）没有任何统一入口。想本地开发则走 git clone 加 make install。

扩展一个新基准，继承点只有一个类

README 说设计新 Web 基准很容易，只需要继承 AbstractBrowserTask 类，并给出了它在仓库中的路径 browsergym/core/src/browsergym/core/task.py。从仓库布局能确认的是，核心包位于 browsergym/core 下，源码在 src/browsergym/core 这一层，各基准是并列的子目录。这条继承路径是 BrowserGym 作为框架而非单一基准集合的关键：它把任务抽象暴露出来，而不是只提供几个写死的评测集。不过 README 对 AbstractBrowserTask 只给了一个类名和一行链接，没有说明必须实现哪些方法、奖励如何上报、观测如何构造。要真的写一个新基准，得读 task.py 源码本身。这是文档偏薄的地方，也是评估这个项目时要计入的成本。

默认基准里有静态的那一个，说明抽象并不完全统一

README 列出的默认基准包含 MiniWoB、WebArena、WebArenaVerified、VisualWebArena、WorkArena、AssistantBench、WebLINX、OpenApps、TimeWarp 九个。其中 WebLINX 被特别标注为 static benchmark，其余没有这个标注。这个细节值得注意：如果所有基准都是同一种交互式环境，就不需要单独标出静态。这说明 BrowserGym 的抽象要同时容纳交互式任务和静态数据集回放，两类东西在 step 语义上未必一致。README 没有展开这个差异，但选型时应该把 WebLINX 单独看待，不要假设它和其他基准的循环行为完全相同。

真正的门槛不在代码，在环境资源

BrowserGym 最大的限制不是接口设计，而是它对上游环境的依赖。WebArena 这类基准需要一套可访问的站点环境，WorkArena 指向 ServiceNow 自己的仓库，OpenApps 指向外部文档。README 把这些全部推给各基准的 README，没有提供容器化的统一方案。结果是，一个团队可以在一小时内装好 browsergym-core 并跑通 openended 任务，但要让 WebArena 跑起来可能需要另外的部署工作，具体多少取决于那份 README 的要求，这里无法从现有材料判断。另一个限制是版本节奏：最近发布是 v0.14.3（2026-01-20），此前有 v0.14.3.dev4（2026-01-08）和 v0.14.2（2025-08-05），主分支最后推送时间晚于最新发布。dev 版本进入发布序列，说明接口仍在演进中，锁定版本号比跟随主分支更稳妥。

和 AgentLab 的关系，以及和裸 Playwright 的差别

README 在显著位置推荐同属 ServiceNow 的 AgentLab，称其为在 BrowserGym 全部基准上实现、测试和评估 Web 智能体的框架。两者分工是清楚的：BrowserGym 提供环境，AgentLab 提供 agent 侧的实现与实验循环。BrowserGym 自己也有 browsergym-experiments 这个包，包含 agent、loop、benchmarks 等实验工具，所以两者在功能上存在重叠区间，README 没有说明该用哪一个作为实验入口。另一个更根本的对比对象是直接用 Playwright：Playwright 给你浏览器控制原语，不给你任务定义、奖励和终止条件，你需要自己写评测逻辑；BrowserGym 把这些包进 gymnasium 接口，代价是接受它的抽象和它对各基准的适配方式。如果你的目标只是让脚本完成一次网页操作，Playwright 更直接；如果目标是比较两个 agent 在标准任务上的表现，BrowserGym 省下的正是评测代码。

许可证与维护成本

仓库元数据里的许可证标识是 NOASSERTION，而 README 的 PyPI 许可证徽章链接指向 Apache-2.0。这两个来源不一致，GitHub 没能从仓库中识别出标准许可证文件。在把 BrowserGym 纳入任何有分发需求的项目之前，应当直接查看仓库根目录的 LICENSE 文件确认实际条款，这里不能替你做法律判断。维护成本方面，可确认的是项目未归档，主分支在 2026-07-17 仍有推送，最近三次发布跨越 2025-08 到 2026-01，节奏不算快但持续。实际成本主要来自上游：每个基准的配置步骤由各自的 README 维护，BrowserGym 无法替你保证它们长期可用。升级时值得先固定 browsergym-core 的版本，再逐个验证你实际使用的基准包，因为基准包和核心包是分开发布的。

编辑结论

如果你在做 Web 智能体研究，需要把同一个 agent 跑在 MiniWoB、WebArena、WorkArena 等多个基准上做横向对比，BrowserGym 的 gymnasium 接口能省掉为每个基准重写交互循环的工作，值得先装 browsergym-core 跑通 openended 任务再逐个加基准包。如果你要的是能直接交付给业务方的浏览器自动化工具，或者无法接受为每个基准单独准备环境（WebArena 需要自建站点、WorkArena 需要 ServiceNow 实例），这个项目不合适，README 自己就写了它不是消费级产品。上手前必须先确认三件事：仓库的 LICENSE 文件实际内容是什么（元数据是 NOASSERTION，README 徽章指向 Apache-2.0，两者不一致）；你要用的基准对应的 README 里那套额外步骤具体要求什么资源；以及 v0.14.3 之后主分支是否已经引入了未发布的行为变化。

官方来源

社区笔记