Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
on-device-browser-agent：用 WebGPU 在 Chrome 本地跑 AI 網頁自動化的開源擴充功能
on-device-browser-agent 是一個 MIT 授權的 Chrome 擴充功能，透過 WebGPU 與 WebLLM 把大模型推理搬進瀏覽器，不需要 API Key 就能執行 AI 網頁自動化。本文拆解它的安裝流程、Planner 與 Navigator 多 Agent 架構、首次下載 1 GB 模型的隱私邊界，並誠實標出它在 2026 年下半年的程式碼停滯與已宣告的後繼倉庫 runanywhere-sdks。
用 AI 摘要這篇文章：
把「幫我把這頁的表格抽成 JSON」「去某個網站查最新的招標公告並整理成清單」這類口語指令交給瀏覽器自己做，是 2026 年網頁自動化最被看好的方向之一。on-device-browser-agent 是一個 MIT 授權的 Chrome 擴充功能，它把整套大模型推理搬進瀏覽器，透過 WebGPU 在你機器的顯示卡上跑，不需要填 OpenAI API Key、也不把網頁內容回傳雲端。本文把它從安裝到極限逐一拆開，並誠實標出它在 2026 年下半年的活躍度與能力邊界。
專案在 GitHub 上的全名是 RunanywhereAI/on-device-browser-agent，以 MIT 授權公開，主要語言是 TypeScript，截至 2026 年 7 月累積約 296 顆星、29 個 fork、3 個未解 issue。它採用 Chrome Manifest V3，核心依賴是 WebLLM 這套在瀏覽器裡跑大模型的函式庫，搭配 WebGPU 提供的顯示卡加速。把它想成「一個會看網頁、會下達點擊與輸入指令的本地 Agent，而且推理引擎就住在你的瀏覽器服務 worker 裡」，比較不會被雲端 RPA 的既定印象綁住。
為什麼把大模型搬進瀏覽器是另一條路
絕大多數 AI 網頁自動化方案都走雲端：你把要操作的目標網頁內容、Cookie、甚至登入狀態送到某個 API，模型在雲端推理後回傳動作。這條路在效率與整合上成熟，卻把最敏感的環節交給了第三方。on-device-browser-agent 走的是另一條：模型權重在你本機下載一次、快取之後，所有推理都在瀏覽器行程裡完成，目標網頁的 DOM 與你輸入的指令都不離開設備。
這條路能成立，靠的是兩個條件同時成熟。第一是 Chrome 124 版之後把 WebGPU 帶進 service worker，讓擴充功能的背景腳本也能直接呼叫顯示卡；第二是 WebLLM 把量化後的大模型權重包成可串流下載的格式，第一次啟動時拉大約 1 GB 的模型檔，之後就快取在本地。與我們先前介紹過、同樣把運算留在瀏覽器裡的 OnlyOffice Personal WASM 辦公套件，以及用 FFmpeg WASM 在前端切音訊的純前端音轉字工具，背後是同一股「把算力推回終端」的趨勢，差別在於 on-device-browser-agent 處理的是「讓 AI 看懂並操作網頁」這一層。
安裝與首次啟動會遇到的三件事
on-device-browser-agent 沒有上架 Chrome 線上應用程式商店，只能用「載入未封裝項目」的方式安裝，這是它第一個門檻。按照 README 的標準流程，安裝會經過三個動作：先把倉庫 clone 下來、執行 npm install 與 npm run build 編出 dist 資料夾，再到 chrome://extensions 開啟開發者模式、點「載入未封裝項目」指向那個 dist 資料夾。這三步對寫過前端的人是日常，對一般使用者就是第一道篩選門。
第一次點擴充功能圖示時，它會開始下載量化後的模型權重，README 標示大約 1 GB，下載完之後快取起來，後續就能離線使用。這裡有個容易被「完全離線」宣傳遮掉的細節：首次啟動必須連網，模型檔是從 HuggingFace 的 CDN 拉下來的，之後才進入實際的本地推理階段。換句話說，它的隱私邊界是「首次啟動連一次 CDN、之後資料不再外送」，而不是打從第一秒就斷網。
第三件門檻是硬體。WebGPU 目前只在新款顯示卡與整合顯示上運作順暢，README 建議至少 4 GB 以上獨立顯示卡的 NVIDIA 顯示卡，或 Apple M 系列晶片；Chrome 也必須是 124 版之後才支援在 service worker 裡呼叫 WebGPU。如果你用的是較舊的內建顯示或公司配發的入門筆電，初次載入模型到推理完成的等待時間會明顯偏長，這是硬體限制而非軟體 bug。
內部架構：規劃、導航、執行三個角色的分工
on-device-browser-agent 不是單一一個模型在呼叫 API，而是把工作拆給三個 Agent 角色，這點從它的原始碼結構就能看出來。src/background/agents/ 目錄下放了 planner-agent.ts、navigator-agent.ts 與 executor.ts，加上一個共用的 base-agent.ts。規劃 Agent 負責把你輸入的口語任務拆成步驟，導航 Agent 負責看當下網頁的 DOM、判斷下一步要點哪個元素或填哪個欄位，執行層則實際去呼叫瀏覽器動作 API 完成點擊、輸入、抽取。
這套分工對應的是 Agent 領域常見的「思考、觀察、行動」循環：模型先推理出下一步要做什麼，再從頁面拿出可用的元素資訊，最後執行並把結果餵回模型決定下一步。WebLLM 在這裡扮演推理引擎，被包在 llm-engine.ts 裡，對上層 Agent 來說是一個統一的呼叫介面。會做這種拆分，通常是因為單一一個大模型直接端到端操作網頁的失敗率偏高，把「看懂頁面結構」與「決定策略」交給不同提示詞框架，能讓整體穩定度提升。
能做什麼、做不了什麼
能穩定做到的，是任何「可以靠 DOM 結構描述」的操作：在搜尋框輸入關鍵字、點擊分頁、把表格逐列抽出來、把商品清單整理成結構化資料、在沒有 API 的舊版後台系統裡把 Excel 資料逐欄填進表單。這類任務的共同特徵是目標元素有可辨識的 HTML 結構，模型看得到、 executor 就點得到。
README 自己也標出了兩個明確的限制。第一個是純 Canvas 繪製的圖表或複雜的驗證碼，因為畫布內容不存在於 DOM 裡，以 DOM 觀察為主的導航 Agent 看不到、自然操作不了。第二個是大規模部署時的硬體一致性：本地推理對終端設備的規格有硬性要求，辦公室裡每台機器的顯示卡等級不一致，推理速度與成功率就會跟著飄移。這兩個邊界官方並沒有掩飾，使用前先把它們列入評估，才不會把它當成什麼都能做的自動化神仙。
隱私的真實邊界與合規底線
「資料不出設備」是 on-device-browser-agent 最大的賣點，但要把它講準，得拆成三層來看。推理層確實在本地，你輸入的任務描述、模型從頁面抽到的 DOM 片段，都不會送給某個雲端推理服務，這與 WebLLM 的架構一致。但首次下載模型權重時會連到 HuggingFace CDN，這個流量本身會經過對方的內容分發網路，屬於一次性的下載行為而非持續回傳。另一層是 Chrome 擴充功能本身的權限：它能讀到你造訪的所有網頁內容，所以安裝任何具備內容腳本權限的擴充功能前，都應該先看過它的原始碼，而 on-device-browser-agent 的好處正是原始碼完全公開、可以自己審。
另一條更常被忽略的邊界是目標網站的服務條款。自動化採集與操作即使技術上做得到，仍必須遵守目標網站的 robots.txt 與服務條款，這點 README 在部署建議裡明確寫出來。把自己用的帳號丟給 Agent 去跑被禁止的高頻抓取，可能會觸發對方的反爬蟲機制甚至導致帳號被停權，這類風險是使用者的責任，不是工具能幫你扛的。與我們介紹過、同樣強調資料主權的Osaurus 本地 AI Agent，以及自架的JadeAI 履歷工具，on-device-browser-agent 把「本地」這個動作做在瀏覽器這一層，定位上更接近「日常網頁操作的自動化助手」。
與雲端方案、傳統腳本的取捨
把它放在三個常見的選項裡比較，會看得更清楚該不該選它。雲端 AI 網頁自動化（例如把頁面內容送給大型商用模型 API 的方案）推理品質最強、對硬體沒要求，但每一次操作都把目標頁面的內容往外送，對金融、醫療、法務這類合規要求高的場景是硬傷。傳統的 Selenium、Playwright 腳本不依賴模型，速度快、行為可預測，但目標網站一改版腳本就失效，維護成本隨網站數量線性上升。on-device-browser-agent 站在中間：靠模型消化版面變動，又靠本地推理守住資料邊界，代價是推理速度受限於本地顯示卡、且模型規模不及商用雲端方案。
| 方案 | 推理位置 | 資料外送 | 版面變動忍受度 | 主要代價 |
|---|---|---|---|---|
| 雲端 AI RPA | 雲端 | 會 | 高 | 合規風險、API 費用 |
| 傳統腳本（Selenium/Playwright） | 無模型 | 視腳本設計 | 低 | 改版即失效、維護成本高 |
| on-device-browser-agent | 本地瀏覽器 | 首次下載模型後不再回傳 | 中 | 硬體門檻、模型規模受限 |
活躍度與後續方向
這是必須誠實說明的一段。整個倉庫從 2026 年 1 月 18 號建立到現在，提交紀錄只有 5 筆，最後一次提交停留在 2026 年 1 月 22 號，也就是說原始碼已經超過半年沒有再更新。以一個還在早期階段的開源 Agent 專案來說，這種節奏代表它比較接近「概念驗證加上可用原型」，而不是有團隊在背後持續迭代的產品。296 顆星與 29 個 fork 顯示有相當數量的人關注，但關注度不等於維護承諾。
更值得記下的是，README 開頭已經掛出一句聲明：後續的支援會搬到 RunanywhereAI/runanywhere-sdks 這個新倉庫。這是一個明確的後繼方向訊號，使用前建議先到那個新倉庫確認進度，再決定要把力氣投在舊擴充功能還是等新的 SDK 落地。對個人開發者來說，把一個已宣告後繼版本的專案當成穩定生產工具，風險相當明確。
適合誰、不適合誰
把前面的限制綜合起來，on-device-browser-agent 的受眾輪廓其實相當收斂。對資料主權有硬性要求的開發者或組織，目標頁面內容不能送雲端，又需要比傳統腳本更柔軟的版面適應力，會在它身上看到價值。想觀摩 WebLLM 與多 Agent 架構怎麼落地的學習者也很適合，它的原始碼規模適中、結構清晰，是能讀得完的教材。而願意自己讀原始碼、也能接受偶爾自己修問題的 HomeLab 與自架玩家，可以把它當成日常重複操作的輔助工具。
不適合的，是追求開箱即用、期待上架商店一鍵安裝的終端使用者；是需要大量高頻採集的商業場景，本地推理的吞吐量跟不上；以及目標網站大量使用 Canvas 或反機器人驗證碼的工作流程，這兩塊是它目前架構上的盲區。如果你已經在用我們介紹過的OpenCut 本地影片編輯器或FreeCut 瀏覽器影片剪輯這類把運算留在本機的工具，on-device-browser-agent 會是同一個生態系裡補上「網頁操作自動化」這塊的選項，但它的成熟度明顯低於前兩者。
常見問題
需要申請 OpenAI 或其他模型的 API Key 嗎？不需要。推理完全交給 WebLLM 在本地顯示卡上跑，沒有任何雲端 API 呼叫。首次啟動下載模型權重時會連到 HuggingFace 的 CDN，之後就能離線使用。
它能通過驗證碼嗎？不能，也不應該期待它通過。驗證碼與 Canvas 繪製的內容不在 DOM 裡，是它架構上的明確盲區。繞過驗證碼也涉及目標網站服務條款與當地法規，不屬於工具的設計用途。
普通的筆電跑得動嗎？看顯示卡。README 建議 4 GB 以上獨立顯示卡的 NVIDIA 顯示卡或 Apple M 系列晶片，入門內建顯示可以啟動但推理會明顯偏慢。Chrome 也必須是 124 版以上。
這個專案還在維護嗎？原始碼最後一次更新是 2026 年 1 月，之後沒有新提交。README 已宣告後續支援搬到 runanywhere-sdks 倉庫。要不要採用，建議先衡量自己能否接受這種維護節奏。
它會把我看的網頁內容回傳出去嗎？推理在本地進行，網頁 DOM 片段與你輸入的任務描述不會送給雲端推理服務。擴充功能本身具備讀取所有網頁的權限，這是任何內容腳本型擴充功能的共通特性，優點是原始碼完全公開可以自查。
把算力留在終端的代價與回報
on-device-browser-agent 的價值不在它已經多成熟，而在它把一條原本只能靠雲端才能實現的 AI 網頁自動化，用 WebGPU 與 WebLLM 在瀏覽器裡重新示範了一次。對資料主權敏感的場景，它提供了一個可以自己審原始碼、推理不外送的可行原型；對學習者，它的多 Agent 架構與量化模型載入流程是很好的觀察對象。它的代價同樣明確：半年的程式碼停滯、已宣告的後繼倉庫、硬體門檻、以及 DOM 觀察帶來的 Canvas 與驗證碼盲區。把它當成早期原型來評估，而不是穩定產品來依賴，會是比較務實的定位。
如果你正在找一個能示範「資料在哪裡、算力就在哪裡」的開源範例，on-device-browser-agent 值得 clone 下來跑一次；但若你要的是能上線的商業級 RPA，現階段更合理的做法是把它當參考、同時追蹤它的後繼 runanywhere-sdks，等那邊的成熟度跟上再認真投入。
