BrowserGym：把瀏覽器包成 Gymnasium 環境的網頁代理研究框架

它解決的是基準測試之間的介面摩擦，不是瀏覽器控制本身

網頁代理研究有個長期困擾：每個基準測試都自帶一套執行方式。MiniWoB 有自己的任務格式，WebArena 需要自行架設網站環境，WorkArena 綁在 ServiceNow 平台上。研究者想在同一個方法上比較不同基準的表現，往往得為每個基準寫一份膠水程式碼。BrowserGym 的做法是把這些基準全部註冊成 Gymnasium 環境，於是 agent 端只需要面對 reset、step、close 這幾個呼叫。README 列的預設基準包括 MiniWoB、WebArena、WebArenaVerified、VisualWebArena、WorkArena、AssistantBench、WebLINX、OpenApps 與 TimeWarp。目標讀者是做研究的工程師，不是想自動化日常網頁操作的人。README 的警告寫得很直白：BrowserGym 是為了加速網頁代理研究而提供的開放、易用、可擴充框架，並非消費級產品。

AbstractBrowserTask 是擴充點，Gymnasium 是外殼

BrowserGym 的架構可以從兩層來看。外層是 Gymnasium：每個任務都是一個環境 id，例如 browsergym/miniwob.choose-list、browsergym/workarena.servicenow.order-ipad-pro、browsergym/webarena.310。透過 gym.envs.registry.keys() 就能列出某個前綴下的所有任務，README 的範例就是用這個方式印出 MiniWoB 的完整任務清單。內層是任務定義：README 說設計新基準只需要繼承 AbstractBrowserTask 類別，連結指向 browsergym/core/src/browsergym/core/task.py。這意味著 BrowserGym 的擴充單位是任務類別，而不是環境類別，新增一個基準時你寫的是任務邏輯與評分方式，Gymnasium 的註冊與迴圈由框架處理。至於瀏覽器本身，安裝步驟要求執行 playwright install chromium，所以實際的頁面操作走的是 Playwright 驅動的 Chromium。

安裝要分兩層：先選套件，再處理各基準的額外設定

BrowserGym 把套件切成多個粒度。想一次拿到全部就執行 pip install browsergym，README 標註這是建議選項。只想用核心功能、不要任何基準，可以裝 browsergym-core，它只提供 openended 任務。要單一基準則有對應套件：browsergym-miniwob、browsergym-webarena、browsergym-webarena-verified、browsergym-visualwebarena、browsergym-workarena、browsergym-assistantbench，WebLINX 走 weblinx-browsergym，TimeWarp 走 browsergym-timewarp。另外還有 browsergym-experiments，包含 agent、迴圈與 benchmarks 等實驗工具。裝完套件之後要跑 playwright install chromium。這還沒結束。README 明講每個 benchmark 都有各自的 setup，需要額外步驟，並逐一指向 miniwob/README.md、webarena/README.md、webarena_verified/README.md、visualwebarena/README.md、assistantbench/README.md 等文件，WorkArena 與 OpenApps 則連到各自的專案文件。也就是說，pip 安裝只解決了程式碼依賴，環境依賴要靠這些文件。開發者若要在本機改動原始碼，README 給的是 git clone 加上 make install。

openended 任務示範了這套介面的最小用法

README 的 openended 範例值得逐行看，因為它揭露了幾個設計決定。建立環境時傳入 task_kwargs={"start_url": "https://www.google.com/"} 指定起始網址，另外傳 wait_for_user_message=True，這個參數的意思是每次 agent 送出訊息後等待使用者訊息，等於把環境切成互動式對話模式。接著是標準的 Gymnasium 迴圈：obs, info = env.reset()，然後在 while True 裡呼叫 env.step(action)，檢查 terminated 或 truncated 決定是否跳出，最後 env.close() 釋放環境。註解裡 action = ... 那一行是留給使用者的，BrowserGym 不提供 agent 實作，它只提供環境。這個邊界劃分很清楚：AgentLab 是 ServiceNow 另一個倉庫，README 說它是用來在 BrowserGym 的所有基準上實作、測試與評估網頁代理的框架。要 agent 請往那邊走。

基準測試的環境依賴是導入時最大的不確定性

BrowserGym 本身可以 pip 安裝，但它包住的基準未必能順利跑起來。WebArena 這類基準需要先架設可存取的網站環境，WorkArena 依賴 ServiceNow 執行個體，這些都不是 pip install 能解決的事。README 把每個基準的 setup 指向各自的文件，等於承認這層複雜度無法由框架吸收。對照之下，MiniWoB 的 setup 相對單純，這也是 README 拿它當第一個使用範例的原因。另一個要留意的點是套件粒度與基準的對應關係：裝了 browsergym-core 並不會附帶任何基準，只有 openended 任務可用，如果照著 WebArena 範例寫程式卻只裝了 core，import browsergym.webarena 會直接失敗。最後，倉庫的授權標示並不一致，PyPI 授權徽章連到 Apache-2.0，但倉庫 metadata 的 license 欄位是 NOASSERTION。這種不一致在採用前應該查清楚，本文不對授權條款提供法律意見。

與 AgentLab 的分工，以及不該用 BrowserGym 的場合

BrowserGym 與 AgentLab 是同一個組織下的兩個倉庫，職責切得很乾淨。BrowserGym 提供環境：Gymnasium 註冊、任務定義、與瀏覽器的連接。AgentLab 提供代理：實作、測試與評估流程。如果你要的是端到端的代理實驗平台，BrowserGym 單獨用起來會覺得少了一半，README 也主動把讀者推向 AgentLab。反過來說，如果你的需求是產品化的瀏覽器自動化，例如定期抓取網頁或填寫表單，BrowserGym 是錯的工具。它的抽象層是為了基準測試的可重現性而設計，不是為了穩定執行生產任務；README 的警告已經說明了這個定位。另一個不適合的情況是只需要單一基準：如果你只跑 WebArena，直接使用 WebArena 原本的介面可能比多繞一層 Gymnasium 更直接，BrowserGym 的整合價值要在跨多個基準比較時才顯現。

版本節奏與維護成本的觀察

從發布記錄看，BrowserGym 在 2026 年 1 月發布 v0.14.3，前一版 v0.14.2 是 2025 年 8 月，中間還有 v0.14.3.dev4 這種開發版。版本號停在 0.x，代表介面尚未凍結，升級時要有心理準備。維護成本主要落在兩個地方：一是基準本身的環境，WebArena 或 WorkArena 的底層變動會傳導上來；二是 Playwright 與 Chromium 的版本，瀏覽器行為改變可能影響任務執行結果。開發者若要在本機跟進，README 給的是 git clone 加 make install 這條路。至於升級的具體相容性資訊，目前提供的材料只有版本號與日期，無法從中判斷哪些變更會破壞既有程式碼，這點需要自行查閱各版本的 release notes。

編輯結論

BrowserGym 適合已經在做網頁代理研究、需要跨多個基準測試比較方法的人，尤其是想用同一段 Gymnasium 迴圈跑 MiniWoB 與 WebArena 的團隊。它不適合當成產品化的瀏覽器自動化方案，README 開頭就警告這不是消費級產品。導入前先確認兩件事：一是你要用的那幾個基準各自的 setup 步驟是否能在你的環境跑完，因為每個 benchmark 的 README 都要求額外設定；二是授權條款，PyPI 徽章指向 Apache-2.0，但倉庫的 license 欄位是 NOASSERTION，兩者不一致，採用前應以倉庫內的 LICENSE 檔案為準。

官方來源

1. Issues
2. README
3. Releases
4. ServiceNow/BrowserGym on GitHub