BrowserWing：開源瀏覽器自動化工具，把錄製的操作變成 AI Agent 能呼叫的指令

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

BrowserWing 是一款用 Go 寫成的開源工具，做的事情可以用一句話講完：把你在 Chrome 裡手動錄製的一段網頁操作，打包成 AI Agent 能直接呼叫的指令。裝完它在本機跑一個 HTTP 服務，AI 透過 MCP、Skill 檔或 CLI 三種方式呼叫，就能重播你剛剛錄的那段流程。以下內容依官方 GitHub 文件、issue 與 release 資料整理，實際效果與穩定度需要你自己驗證。

它和 TechMoon 先前介紹過的 BrowserOS、on-device-browser-agent 走的不是同一條路。那兩篇的主角都是把 AI 模型放進瀏覽器決策迴圈裡，讓模型逐步看畫面、決定下一步；BrowserWing 反過來，把人的操作先錄下來當成確定性腳本，AI 只負責在對的時機呼叫這段腳本。這個設計選擇直接決定了它省 token 的方式，也決定了它會在哪種任務上破功。

把「人錄製」當成 AI 與瀏覽器之間的插槽

從 GitHub README 觀察到的核心機制是三段式：先在 BrowserWing 的網頁介面開啟錄製，手動操作瀏覽器（點擊、導航、輸入），它把每一步記錄成可編輯的腳本；接著把這份腳本匯出成三種格式之一，分別對應三種使用場景。

一種是 MCP 指令。BrowserWing 啟動後會在本機提供一個 MCP 端點（位置是 http://localhost:8080/api/v1/mcp/message），任何支援 MCP 的 AI 工具把它加進設定後，就能把你錄的腳本當成一個 MCP 工具呼叫。README 給的設定範例很短，把那一行 url 塞進工具的 mcpServers 設定就完成接線。另一種是 Skill 檔，README 示範可以把多支腳本組合成一份 SKILL.md，匯入支援 Skills 協定的工具；還有一種是 CLI，直接在終端下 browserwing run 腳本名 拿結構化 JSON，這條路線完全不開瀏覽器視窗，適合串在其他程式或 shell pipeline 後面。

要把它當 AI Agent 用，還需要你自己帶模型 API key。README 列出相容 OpenAI、Claude、DeepSeek 等模型，這表示模型費用與帳號是你的責任，BrowserWing 本身不代理、也不分潤。把 key 設好之後，AI 介面能讀懂你錄的腳本清單、決定何時呼叫哪一支。理解這一層之後，官方宣稱的「token 友好」才有合理的位置：它省的是「瀏覽器操作那段不用模型逐步推理」，而不是模型本身的計價。

實際用起來的迴圈是這樣：先在介面裡錄一段、例如登入某平台後把當天的訂單清單抓下來，存成腳本；再把它匯出成 MCP 指令加進你的 AI 工具。之後你對 AI 說「抓今天的訂單」，它不必看著畫面一步步推理，而是直接呼叫那支腳本，幾秒內吐出結構化結果。錄製成功過一次，後續每次重播都是同一條路徑、同一份花費；這也是為什麼它強調要先錄得起來：錄不起來的網站，整套省 token 的前提就跟著落空。

官方在 repo 描述裡把這個設計意圖講得很直白：與其讓模型用又慢又耗 token 的方式逐步操作瀏覽器，不如讓 agent 直接呼叫指令、跑得更快。翻成白話就是：與其讓模型每一步都看著 DOM 推理燒 token，不如讓它只下一次「執行這段錄好的流程」的指令。這條路徑的 token 效率來自「重播是確定性、不經過模型」這個前提。這個區別很重要，因為它同時意味著：一旦錄製失敗或網站結構變了，省 token 的前提就跟著消失，這時你要嘛重錄，要嘛退回讓模型逐步操作的路線。

把視野拉大一點，BrowserWing 在 AI 瀏覽器自動化的光譜上佔的是「先把人的動作固化下來」這一端。BrowserOS 那類是把 AI 模型塞進瀏覽器決策迴圈、讓模型逐步看畫面決定下一步；on-device-browser-agent 則進一步把模型搬到你本機用 WebGPU 跑，隱私與硬體門檻跟著拉高。BrowserWing 不碰模型擺放，它假設你已經有 AI 工具，只缺一個「把瀏覽器操作變成可呼叫指令」的轉接器。選哪一端，取決於你的任務能不能事先錄得起來。

裝完即用的 78 個內建腳本

不必從零錄製。README 列出 78 個內建腳本，分佈在 10 個分類，涵蓋 Bilibili、GitHub Trending、Reddit、Hacker News、YouTube、Steam、Weibo、Zhihu、Google Scholar、Binance、Amazon、BBC、Bloomberg、Reuters、CNKI 等。中國平台的覆蓋密度明顯較高，這也反映了專案主要受眾的組成。

Pin

官方在 README 示範的使用流程是三行指令：npm install -g browserwing && browserwing --port 8080 裝好啟動，再用 browserwing run github-trending 或 browserwing run bilibili-hot 直接拿結構化資料，輸出可以管線給 jq 處理。CLI 預設是無頭模式，不開瀏覽器視窗。這條流程只能證明這 78 支腳本跑得動、會吐 JSON；至於每支腳本在你目標網站的長期穩定度、網站改版後多久會壞，README 沒給保證，issue 列表裡也看得到相關的真實抱怨。

把你自己錄的腳本交給 AI 的流程，README 用一張「Turn Scripts Into Claude Skill」的示意圖說明：勾選幾支腳本、點匯出，就產出一份可匯入的 SKILL.md。這條是官方展示的匯出流程。

Pin

官方沒給答案的三件事：token 數字、穩定度、競品比較

BrowserWing 官方資料能支持的，是「這套機制存在、這 78 支腳本存在、MIT 授權、持續有維護」；不能支持的，是「它比 browser-use 或 BrowserOS 更強」「它的 token 消耗具體是多少」「它在你目標網站能穩定跑多久」這三類結論。

官方的確在 README 與 repo 描述裡反覆宣稱 token 使用友好、成本極低，這是作者自己的宣稱。機制上「重播不經過模型」可以合理推論出 token 會比逐步視覺操作省，但 README 沒有附任何基準測試數字，也沒有和同類工具的對照組。如果你需要定量數字，只能自己用同一個任務跑兩條路線比較：把一段多步驟的網頁操作分別交給 BrowserWing 的錄製重播、以及某個逐步操作的 AI 瀏覽器工具，記下兩邊各自燒掉的 token 與完成時間，才會得到對你的任務有意義的數字。沒做這一步之前，官方的「低成本」對你而言只是方向性的描述，不是承諾。

同理，這裡不放「BrowserWing 勝過某某工具」的比較表，沒有對稱實測就寫比較表，等於把官方宣稱包裝成編輯判斷。它能跟你已經在用的 AI 工具互補（任何支援 MCP 或 Skills 協定的都能接），至於要不要用它取代你現有的流程，要看你自己的任務特性，後面會給判斷框架。這條紅線也適用在你看其他介紹文時：凡是只引用官方行銷語句、卻沒附自己跑出來的數字或對照組的「完勝」「最強」結論，都該當成廣告詞而非評測。

會卡住你的幾個已知缺陷

裝之前，有幾個會直接影響決策的限制值得先知道。

最該先看的是資安模型。BrowserWing 啟動後預設監聽所有網路介面，GitHub issue 編號 11 已經明白標記這是安全問題：在任何公開網路環境下，別人有可能遠端呼叫你的 BrowserWing、連帶驅動你已登入的 Chrome 工作階段。這條風險維護者也承認、issue 目前仍 open，不是純理論推測。把它當作本機工具用、手動綁到 localhost 或用防火牆擋掉對外埠，是基本動作；如果你打算部署在共用機器或容器裡，更要先處理這一層。它驅動的是你真實的瀏覽器 session，cookie 與登入狀態都掛在其上，這一點和 Coworker 這類桌面 Agent 共用同一個風險結構。

緊接著的摩擦出現在 macOS。從 GitHub 下載的預編譯檔會被 Gatekeeper 擋下，README 給的解法是 xattr -d com.apple.quarantine $(which browserwing) 解除隔離屬性；issue 編號 7 另外有使用者反映 M 系列 Mac 打不開程式。蘋果晶片的使用者第一次啟動要有心理準備會踩到這一關，透過 npm 裝則會自動測試 GitHub 與 Gitee 鏡像、挑快的來源，這條路徑遇到的阻力較小。

錄製本身則有覆蓋範圍的死角。issue 編號 3 指出部分頁面在開啟錄製時，點擊後頁面不跳轉、操作抓不到；另一條 issue 編號 8 反映 webssh 或 xterm 這種 canvas 終端機回放時無法重現輸入。這直接戳中 BrowserWing 的核心前提：重播是確定性，但前提是「錄製階段有抓到」。單頁應用、動態載入、canvas 渲染的場景，是已知會破功的類別，能不能用要拿你的目標網站實際試。

專案節奏也值得摸一下底。Repo 從 2025 年 12 月建立，截至 2026 年 5 月最近一次程式碼推送為止，repo 累積約 1400 顆 star、128 個 fork、22 個 open issue，最新版本是 2026 年 4 月的 v1.1.0。它不是死專案，但也不算每週迭代的熱區，issue 回覆速度與社群腳本貢獻的活躍度，是你決定要不要把生產流程押在上面時的參考指標。

把那 22 個 open issue 稍微分類一下，會看到幾種重複出現的類型：資安設定（監聽範圍）、錄製覆蓋範圍（特定頁面抓不到操作）、在地化設定（如何接國內模型、能否用自架 API），以及 macOS 啟動問題。對潛在使用者來說，這份分類本身就是一份「裝之前先預期會踩到什麼」的清單。如果你打算認真採用，花十分鐘把 issue 列表掃一遍，比你裝完才發現自己的情境剛好落在已知缺陷上、再回頭找解法，要省時得多。

授權這一項倒是沒有灰箱子。條款是 MIT，允許商用與改作，倉庫有 LICENSE 檔案可核對。

什麼情境值得試，怎麼開始

綜合上面的機制與限制，BrowserWing 比較可能勝任的，是「目標網站結構相對穩定、操作重複性高、你希望讓 AI 一次呼叫就跑完整段」的場景，例如每天抓一次某平台的熱門榜、把資料彙整到另一個地方、批次發佈內容到幾個後台。78 支內建腳本裡如果有對應到你需求的，等於別人已經幫你錄好，先試內建的會比自己錄快。如果你的任務網站是高度動態的 SPA、或需要 canvas 操作、或目標網站反機器人偵測強，錄製前提本身就脆，這時退回讓模型逐步操作的工具反而實際。

開始的方式有三條。官方推薦用 npm：npm install -g browserwing 裝好，browserwing --port 8080 啟動，打開 http://localhost:8080 就是網頁介面。不想裝 npm 的，README 有給 Linux 與 macOS 的一鍵安裝腳本，以及 Windows 的 PowerShell 版本；release 頁面也有各平台預編譯檔可直接下載。從原始碼 build 則需要 Go 加 pnpm。三條路徑裡，npm 那條會自動測試 GitHub 與 Gitee 兩個鏡像、挑快的來源，對 GitHub 連線不穩的環境比較友善；release 預編譯檔適合不想裝 Node 的人，但要自己處理 macOS 隔離屬性。

不管挑哪條，啟動後第一件事不是錄腳本，而是確認它綁在 localhost。最直接的做法是用 --host 127.0.0.1 之類的啟動參數或防火牆規則，把那個 8080 埠限制成只有本機連得到；issue 11 之所以被報出來，就是因為預設值不是這樣。設定它驅動的 Chrome profile 時，先用一個沒有敏感帳號的乾淨瀏覽器環境測，別直接把它接在你日常工作、已登入一堆服務的那個 Chrome 上。等確認機制運作、也親眼看到監聽行為在你的環境被擋掉，再決定要不要擴大使用範圍。

成本的現實層也要算進去。BrowserWing 本體開源免費，但用它當 AI Agent 時，模型呼叫的帳單掛在你身上；選 OpenAI、Claude 或 DeepSeek，單價與額度上限差很多，而你的任務能錄成多長的腳本、要呼叫幾次，會直接決定每個月燒多少。先用小流量跑一週、記下實際 token 消耗，再決定要不要把它推到日常流程，會比一開始就大規模部署穩當。這套工具能不能幫你省事，取決於你的任務是不是落在「可錄製、可重播」這個甜蜜區，把它當成需要自己驗證假設的開源實驗，別當成裝完就見效的現成方案。