ruyiJS：Python 執行與自動化限制

ruyiJS 是由 Python 控制的 JavaScript 執行環境，使用 Firefox 元件，提供可保留狀態的 Context、DOM 與網路 API。官方倉庫限定 Windows x64，並明確說明沒有瀏覽器視窗、完整頁面排版與繪製。需要執行腳本並取得數值時可以評估；需要確認使用者看到的畫面時，必須有完整渲染能力。

在一則本機 AI Agent 的 Reddit 討論中，kvyb 將複雜 JavaScript 網站、驗證、分頁與表單列為需求。這份清單說明自動化包含不同層次，並非 ruyiJS 使用心得。後文以 Tabbit Browser 說明需要真實瀏覽器與既有登入狀態時的做法。

本文於 2026 年 10 月 28 日核對公開文件，未安裝測試 ruyiJS，也未進行反爬或效能測試。PyPI 0.1.0於 10 月 22 日發布，GitHub 倉庫於 10 月 26 日建立，兩個日期不能混用。調查時 README 和目前 PyPI 頁面顯示 0.1.6。

重要結論

• ruyiJS 提供腳本與 Web API 環境，並非完整的視覺化 Firefox。

• README 將 SpiderMonkey、Necko 列為 JavaScript 與網路元件；Firefox 158 的說法來自專案方，本文未獨立稽核。

• 先確認 Windows x64 與 Python 3.10+ 部署條件。

• 持續狀態、離線資源與邏輯時鐘適合建立腳本重播，但仍須測試實際相容性。

• 選擇工具前，先確定交付的是計算值、渲染畫面，還是經人員複核的瀏覽器任務。

ruyiJS 能力一覽

來源：README。瀏覽器引擎介紹說明 JavaScript 引擎與渲染引擎的差別。

Context 實際負責什麼

架構為 Python → 獨立 Context 程序 → SpiderMonkey、Web API 與 Necko。同一 Context 的多次 eval() 可使用先前留下的變數與函式，Python 負責提供資料並取得回傳結果。

UI 測試關心按鈕是否可見、能否點擊；ruyiJS 任務可能只關心腳本載入後的函式結果。Agent 瀏覽器介紹討論額外的規劃與互動層。安裝 ruyiJS 本身不等於取得 LLM 任務規劃器。

README 列出 DOM、Canvas 相關 API、Workers 與 iframe。這些是子系統範圍，仍需逐項驗證實際行為。能查詢 DOM，不代表會計算完整頁面排版。

從離線範例開始

在文件支援的 Windows x64 環境中，建立獨立 Python 環境並固定版本：

python -m venv .venv
.venv\Scripts\activate
python -m pip install ruyijs==0.1.6

這是依據文件整理的指令，並非本文安裝紀錄。執行前確認 PyPI 要求。先測試不需網路的基本運算：

from ruyijs import Context

with Context() as context:
    context.eval("let count = 40")
    print(context.eval("count += 2"))

文件預期結果為 42。接著以自己提供的 HTML 和資源測試 DOM：

from ruyijs import Context

with Context() as context:
    context.put_resource("https://example.test/app.js", "window.answer = 42")
    context.load_page("https://example.test/", '''
        <script src="/app.js"></script><p id="message">hello</p>
    ''')
    print(context.eval("document.querySelector('#message').textContent"))
    print(context.eval("answer"))

0.1.0 文件的預期輸出為 hello 和 42。load_page(url, html) 接收基準網址與 HTML，相對資源依該網址解析；不要與 README 另外列出的頂層導覽 navigate(url) 混淆。

明確管理狀態、時鐘與請求

在第一個頁面腳本執行前呼叫 context.configure_fingerprint(profile)，設定 Navigator、Screen、視窗大小、時區等欄位。設定成功不代表網站一定接受這個環境。

需要乾淨狀態時，建立新的 Context。PyPI 文件說明，JSObject、JSFunction 的即時參照在所屬 Context 關閉後失效。

宿主必須推進排程。邏輯時鐘範例呼叫 advance(10)；系統時鐘模式可能實際等待。對網路 Promise，不能以一次短暫推進當作完成證明，應設定條件、截止時間及錯誤處理。

put_resource() 可供應固定回應，適合建立離線樣本。重播仍需完整輸入，請一起保存 HTML、腳本版本、設定與預期輸出。net_log() 可區分網路失敗與腳本錯誤，網頁相容性排查也採用分層定位。

先用限制篩選工具

截圖、元素實際位置與視覺回歸都需要完整渲染能力。設定 viewport 不會增加渲染器。

平台同樣是前提。變更紀錄提到 Wine 導覽修復，不能據此聲稱原生支援 Linux。本文在 macOS 研究文件，未於支援平台執行安裝測試。

反爬範例來自維護者，並非獨立基準，也無法保證網站未來回應。本文沒有成功率、速度或記憶體比較。星數只能表示關注，不能驗證可靠性。

專案標示 MPL-2.0，README 另提出再散布及商業使用前聯絡作者的禮貌請求。整合前閱讀目前 LICENSE 與聲明，本文不判定個別部署的授權結果。

用 Tabbit 處理真實網頁任務

如果要開啟多個文件頁面，以既有登入狀態閱讀，再回傳附來源的比較表，交付物是經核對的資料整理。Tabbit 中國大陸版 v1.13 更新紀錄公布 CLI 整合，可讓 Codex、Cursor、Workbuddy 等 Code Agent 操作瀏覽器並共用使用者登入狀態。

先完成客戶端要求的整合，再提供範圍清楚的唯讀指令。以下是建議用法，不表示本文執行過這項任務：

在 Tabbit 開啟我提供的文件頁面。
比較支援平台、安裝要求與頁面渲染能力。
每項結論附來源 URL 與可見版本或日期。
資料缺漏標示未知。不要送出表單或變更帳號設定。

Tabbit 工作流程文章提供案例，產品介紹說明定位。操作仍需設定、網站權限和結果複核。引用文件屬於中國大陸桌面版，國際版與行動端須另行確認。

共用登入不會消除會話失效。在 Firefox 自動化討論中，Deep_Ad1959 描述過期工作階段與偶發同意視窗造成不穩定。這是一般自動化經驗，並非 Tabbit 或 ruyiJS 測試。瀏覽器設定檔介紹有助釐清工作階段資料。

Tabbit 的瀏覽器操控與 ruyiJS Python API 不同。沒有證據顯示 Tabbit 內嵌 ruyiJS、提供相同指紋設定或執行其挑戰範例；隔離的 ruyiJS 程序也不會自動繼承 Tabbit 登入與分頁。

依交付結果選擇

瀏覽器選擇指南從重複任務出發。評估新流程時，可先當作第二瀏覽器使用。

結論是：ruyiJS 可列入支援平台上的腳本執行與重播候選，但不能視為渲染式 UI 自動化的通用替代。先用自有樣本及已知結果驗證；需要人員監督的真實頁面操作時，再依實際任務評估 Tabbit 整合與回傳來源。

Secholar.L

Tabbit 成長與內容

Secholar.L 專注 AI 瀏覽器與 Agent 工作流的實測寫作,基於真實調研比較工具,引用可查證的一手來源。