Browser Use 於 2026 年 9 月 16 日開源 jev-ultrafast，這是一個以索引式動作空間為核心的瀏覽器代理。專案目前累積 23,328 顆星標與 1,738 個分支，採 MIT 授權，主要語言為 Python。官方公布的實測數據顯示，同一項 Google Flights 機票搜尋任務的中位數完成時間由 9.450 秒降至 7.092 秒，瀏覽器協定呼叫次數由 1,092 次降至 101 次。
這組數字的意義不在於單一任務快了兩秒，而在於成本結構的改變。多數瀏覽器代理的每一步都需把頁面狀態送入大型語言模型，再等待模型輸出指令；jev-ultrafast 把決策拆成兩層，操作與目標由專門的決策模型在單次請求內判定，語言模型只在需要填寫文字欄位時介入。
Jev Ultrafast 是什麼？
Jev Ultrafast 是 Browser Use 開源的瀏覽器代理，以 TypeSafe 決策模型取代逐步呼叫語言模型，單次請求同時決定操作與目標元素，採 MIT 授權。
專案定位寫得相當直接：給代理一個自然語言目標，決策層選出一個操作與一個元素，只有當操作為 TYPE_TEXT 時，才由小型語言模型生成要輸入的字串。整個執行迴圈不依賴截圖，而是讀取結構化的頁面狀態。
技術分工沿著這條界線展開。決策端由 TypeSafe 的 jev-1.13.0 負責，輸出的是操作編號、目標元素編號與各候選項的機率分布；文字端則透過 OpenAI 相容介面接上 inception/mercury-2.5，並關閉推理功能以壓低延遲。官方文件同時註明 Gemini、GLM 與 DeepSeek 皆可作為替代的文字輔助模型。
這種切分使專案的定位有別於一般代理框架。它不試圖建立通用的任務規劃器，而是把瀏覽器互動壓縮成可觀測、可驗證的有限狀態機，並把模型輸出的自由文字徹底排除在控制流之外。模型不會產生選擇器、座標、Shell 指令或可執行 JavaScript，只能從已觀測的元素表中挑選編號。
為什麼 7 秒被視為瀏覽器代理的關鍵門檻？
每步一次的語言模型往返主導了延遲，當十餘步操作累積，回應時間便以數十秒計；把決策與文字生成分離，可直接扣除此項固定成本。
瀏覽器代理的延遲由三部分組成：頁面觀測、模型決策與實際操作。傳統做法在每一步都把可存取性樹或截圖送入模型，等待數百毫秒至數秒的推理，再解析自由文字輸出為可執行指令。任務若有十二步，延遲便隨步數線性疊加，且每次輸出格式的偏差都可能觸發重試。
jev-ultrafast 的做法是把決策請求數壓到與步數相同但單次成本極低的水準。官方紀錄顯示，7.073 秒的執行包含 17 次決策請求、10 次互動加 1 次明確的等待，以及 2 次文字輔助呼叫；決策延遲中位數為 178 毫秒。搜尋動作在 5.217 秒執行，最終完成驗證落在 7.073 秒，中間的時間用於等待 Google 結果載入與狀態變更。
值得注意的是計時邊界。官方明言計時起點是首頁觀測後的第一次預測，終點是系統接受 DONE 的時刻，期間包含文字生成、模型請求、瀏覽器操作、過期決策重試與載入等待，但排除瀏覽器啟動與初始導覽。這種揭露方式讓數字可被重現，也讓「7 秒」不至於被誤讀為從按下執行到看見結果的全程時間。
索引式動作空間如何運作？
每次觀測產生編號元素表，代理只能從中選擇操作與目標；決策模型單次輸出操作、點擊目標與輸入目標，僅實際執行的分支被採用。
觀測階段由一段注入頁面的腳本完成。它遍歷頁面上可見且可互動的元素，依角色分類為按鈕、連結、核取方塊、下拉選單、文字框與搜尋框等，並為每個元素指派遞增編號。輸出是一張表，每列包含編號、角色與名稱，例如第一列是「按鈕 · 更改票種 · 來回」，第三列是「下拉選單 · 目的地 · 空白」。
可用的操作固定為八種：CLICK、TYPE_TEXT、SELECT、SCROLL_UP、SCROLL_DOWN、WAIT、DONE 與 BLOCKED。代理不會收到頁面上不存在的操作選項，選項清單本身即構成約束。決策模型在單次請求中回答三個推測性問題：下一步該做什麼、若要點擊應點哪個元素、若要輸入文字應填哪個元素。三個答案共用同一次往返，實際執行時只採用與操作相符的那一個。
目標選項亦經過過濾。若操作判定為 CLICK，只有可點擊的元素會出現在點擊目標的候選集中；若判定為 TYPE_TEXT，候選集僅含文字框。下拉選單的原生選項則以觀測到的元素與選項索引傳遞，避免模型自行拼湊字串。這種設計把自由生成壓到最小，也讓每一次執行的輸入都能對應回具體的 DOM 節點。
執行層如何保證點擊與輸入的正確性？
執行前重新檢查頁面新鮮度、元素是否被遮擋與當前幾何位置，輸入後驗證欄位狀態；動畫造成的變動不強制重新預測。
決策與執行之間存在時間差，頁面可能已變動。專案以頁面指紋處理此問題：觀測時記錄文件狀態、欄位值與滾動位置，執行前比對指紋，若不一致便拋出過期例外，重新觀測後再決策。動畫引起的 DOM 變動被排除在失效條件之外，否則幾乎每次互動都會觸發重算。
點擊前的守衛涵蓋四項檢查：目標節點是否仍在文件中且可見、是否被其他元素覆蓋、當前幾何位置是否與觀測時一致、鄰近上下文（所屬表單、對話框、列表項）是否已改變。被遮擋的控制項會被拒絕，動畫本身不足以迫使重新預測，但遮擋可以。
輸入後的等待策略同樣以成本為考量。對下拉選單輸入文字後，系統最多等待 200 毫秒讓建議清單出現，避免在彈出視窗尚未完整時要求模型選擇；其他互動則限制在兩個動畫影格或 50 毫秒之內。這些讀取發生在操作已記錄之後，即使導覽中斷也不影響日誌完整性。
文字輔助的輸出必須能解析為僅含 text 鍵的 JSON 物件，否則不予輸入。若頁面在下一次預測前失效，已生成的文字值只在整個輔助輸入完全未變時才被重用，避免把舊值填入新情境。
實測數據顯示多大的效能差距？
六次交替測試中，中位數任務時間由 9.450 秒降至 7.092 秒，瀏覽器協定呼叫由 1,092 次降至 101 次，決策請求由 22 次降至 17 次。
對照實驗的條件寫得相當完整：六次交替執行、同一項任務、同一個既有 Chrome 設定檔、1120×780 視窗、相同的決策模型版本與文字模型、關閉文字推理、相同的操作與請求預算，兩組皆排除初始導覽並各自建立與關閉分頁。三組配對的原始版本為 11.214、8.984 與 9.450 秒，優化版本為 6.964、7.913 與 7.092 秒，六次全部通過獨立結果驗證。
官方並未把這組結果包裝成通用基準。文件明確指出三次配對對統計推論而言過少，雙尾符號檢定的 p 值為 0.25，且 Google 的回應、網路路由與瀏覽器快取皆為即時變動因素。這種自我限定在開源專案中並不常見，也讓數字的可引用性提高。
另外兩項檢查屬於功能驗證而非速度比較：開啟維基百科哥德爾不完備定理條目耗時 2.798 秒，本地旅館篩選測試耗時 1.896 秒。本地瀏覽器檢查涵蓋控制項被移動、替換、隱藏與停用，欄位屬性變更、鄰近上下文改變、覆蓋層阻擋、原生下拉選單執行、真實文字替換、自動完成抵達與頁面導覽等情境。
成本面僅揭露局部。官方記錄顯示，該次執行累計消耗 90,558 個輸入 token 與 6,325 個輸出 token，兩次文字輔助呼叫在 OpenRouter 的計費為 0.00006272 美元。決策模型的回應只提供 token 數量而無計費金額，瀏覽器端成本亦未計入，因此這個數字不能被視為單次任務的完整成本。
與其他瀏覽器代理方案有何差異？
多數方案每步呼叫大型語言模型並解析自由文字；此專案以專用決策模型輸出有限選項，並將截圖排除在預設迴圈之外。
市面上主流的瀏覽器代理可粗分為三類。第一類以截圖為輸入，讓多模態模型直接判讀畫面座標，優點是對視覺化介面適應力強，缺點是每次決策都要傳遞影像，成本與延遲皆高。第二類以可存取性樹為輸入，把頁面結構轉為文字，減少頻寬但節點數量容易膨脹。第三類是自建瀏覽器核心並直接解析 DOM 的專用方案。
jev-ultrafast 屬於第二類的變體，但把決策輸出限制在有限選項內。它不要求模型描述下一步，而是要求模型在編號清單中挑選；不要求模型輸出座標，而是由執行層依觀測時的幾何位置解析。這種約束同時降低了延遲與錯誤率，代價是對不支援標準 HTML 或 ARIA 控制項的介面無能為力。
與 Browser Use 自家的主線專案相比，兩者的定位不同。主線專案著重通用性與社群生態，支援多種模型供應商與雲端執行；jev-ultrafast 則是單一策略的效能實驗，程式碼量刻意壓到可在一小時內讀完的規模，官方亦將它標示為低調的工程預覽版本，建議僅在受信任環境中測試。
如何安裝與執行 Jev Ultrafast？
以 git clone 取得原始碼，執行 uv sync 安裝依賴，設定 TypeSafe 與文字模型的 API 金鑰後啟動本機檢視介面，於瀏覽器開啟 8766 埠。
安裝流程以 uv 為基礎。複製儲存庫後執行 uv sync，複製範例環境檔並填入 TYPESAFE_API_KEY 與 TEXT_MODEL_API_KEY，再以 uv run jev 啟動。本機檢視介面位於 http://127.0.0.1:8766，按下自動執行後可觀察編號元素、操作機率、目標機率與已執行的動作；選擇逐步模式則會在每次執行前暫停。
瀏覽器連線透過 Browser Harness 建立，由 uv sync 一併安裝，必要時可執行 uv run browser-harness --doctor 檢查連線狀態，並在提示時允許 Chrome 開啟遠端除錯。專案使用既有的 Chrome 設定檔，代理建立的分頁與使用者日常瀏覽共用同一個身分環境，這也是官方強調只能在受信任環境測試的原因之一。
若要以程式呼叫，可直接從套件匯入 Agent，傳入起始網址與目標字串，再迭代 run() 取得每一步的狀態、耗時與結果。官方範例包含機票搜尋與維基百科條目開啟，後者附帶結果驗證，前者只執行搜尋而不進行訂票。開發者亦可執行 uv run pytest 進行離線測試，或執行守衛檢查腳本在本地瀏覽器驗證真實控制項，無需消耗模型額度。
目前有哪些已知限制？
不支援 Shadow DOM、框架內頁面、畫布、檔案上傳、彈出分頁、嵌套滾動與任意鍵盤元件；DONE 的判定仍需外部獨立驗證。
官方的限制清單相當坦率。DOM 讀取器只處理常見的 HTML 與 ARIA 控制項，未實作完整的可存取名稱演算法，也不遍歷 Shadow Root 與 iframe。畫布繪製的介面、檔案上傳、開啟新分頁、嵌套滾動與自訂鍵盤元件皆不在支援範圍內。點擊守衛刻意容許無關的可見更新，這在動態頁面上可能造成誤判。
更根本的風險在於任務完成的認定。規劃約 60 步的上限並不妨礙代理在錯誤狀態下宣告完成，DONE 本身從不構成成功證據。官方在機票範例中以獨立檢查器驗證單程設定、出發地、目的地、日期與結果可見性，這種外部驗證被視為必要環節，而非可選項。
成本與依賴也是實際考量。專案需要 TypeSafe 的商業服務與一組額外的文字模型金鑰，兩者皆非本地執行；這意味著延遲與費率取決於供應商，且無法完全離線運作。對於需要資料不出境的場景，這種架構並不適用。官方同時開放雲端候補名單，顯示商業化路徑正沿著託管服務推進。
出處連結有哪些？
原始碼、效能量測與規格文件均位於 GitHub 的 browser-use/jev-ultrafast 儲存庫，決策模型文件位於 TypeSafe 官方網站。
儲存庫網址為 https://github.com/browser-use/jev-ultrafast，效能數據與逐次量測紀錄位於 docs/performance.md，執行迴圈、觀測腳本與瀏覽器連線分別對應 agent.py、snapshot.js 與 browser.py。專案採 MIT 授權，允許商業使用與修改，第三方分散式版本需保留原始授權聲明。決策模型的規格與推測式展開模式，可於 TypeSafe 的文件站查閱。
總結：瀏覽器代理的瓶頸在哪裡？
瓶頸在決策往返次數與輸出格式的解析成本，而非模型本身的推理能力；把選項收窄成有限集合，是此專案最主要的效能來源。
過去一年瀏覽器代理的競爭集中在模型能力，假設更強的模型能處理更複雜的頁面。jev-ultrafast 提供的反例值得注意：同一組模型、同一個任務，僅改變決策的組織方式，中位數時間便下降四分之一，瀏覽器協定呼叫減少約九成。這說明延遲的主要來源是系統設計，而非推理品質。
這種設計的邊界同樣清楚。有限選項換來速度，卻犧牲了對非標準介面的適應力；把模型排除在控制流之外提升了安全性，卻也讓代理無法處理需要組合推理的長流程。專案被定位為工程預覽而非產品，正是對這些取捨的誠實標記。
對評估瀏覽器自動化的團隊而言，這個專案的價值不在於直接採用，而在於提供一組可參照的量測方法：明確的計時邊界、交替執行的對照組、獨立的結果驗證，以及對統計顯著性的自我克制。在一個充斥著示範影片與選擇性數據的領域，這種揭露方式本身就是可借用的做法。
