firefox-bridge
讓 AI 跟你看同一個畫面——MCP server + Firefox 擴充套件，接手你本人已經登入的那個分頁。
AI 教你的步驟，跟你眼前的畫面對不上
你問 AI「這個系統怎麼改這個設定」，它給你五個步驟。第三步那個按鈕不在那裡。
它不是在亂講。它講的可能是另一個版本、另一套佈景主題、或者是它從文件上讀來的通用流程。更常見的情況是：你們公司那套系統，它根本沒看過——那是十年前導入的 ERP，網路上沒有教學，官方文件鎖在客戶入口網裡。
於是你開始截圖。貼一張，它回三句，你再貼一張。你花在搬運畫面的時間，比它省下的還多。
問題的根不在它笨。是它沒看到你的畫面。
現有的工具，開的都不是你的瀏覽器
要讓 AI 看到網頁，現成的路有好幾條——WebFetch 直接抓 HTML、headless 瀏覽器渲染完再抓、Playwright 開一個乾淨 profile 跑自動化。它們有個共同點，而這個共同點在企業內部系統面前是致命的：
它們開的都是全新的、乾淨的瀏覽器。沒有 session cookie，沒有 SSO 憑證，沒有 MFA 通過的紀錄。所以它們看到的內部系統，永遠只有登入頁那一張。
firefox-bridge 反過來做。它不開新瀏覽器——它接手你已經開著、已經登入的那個分頁。架構上分三段：一個 MCP server 講 MCP 協定給 AI 聽，一個 native messaging host 當管道，一個 Firefox 擴充套件真正在你的瀏覽器裡動手。
lease：誰在操作是明確的
既然動的是你真的在用的瀏覽器，「現在誰在碰這個分頁」就必須講清楚。所以每個分頁都要先租用：acquire_tab 取得、release_tab 交還，list_tabs 會顯示每個分頁的 leasedBy。
這原本只是多 session 共用時的基本防呆——兩個 AI session 不該同時操作同一個分頁。後來才發現它剛好是別的東西，這篇後半會回來講。
44 個工具
| 分類 | 工具 |
|---|---|
| 分頁租借 | list_tabs acquire_tab release_tab close_tab discard_tab open_private_window |
| 導覽 | navigate go_back go_forward scroll_to |
| 讀取 | read_page read_article list_elements list_frames screenshot |
| 互動 | click type select_option hover press_key drag_and_drop upload_file |
| 等待 | wait_for |
| 觀測 | start_console get_console start_network get_network |
| 身分 | list_containers create_container |
| 書籤與歷史 | list_bookmarks add_bookmark search_bookmarks search_history to_be_deleted |
| 分頁選擇 | request_tab_selection get_tab_selection |
| 對話框攔截 | list_dialogs respond_dialog add_dialog_whitelist remove_dialog_whitelist |
| WebMCP | add_webmcp_whitelist remove_webmcp_whitelist webmcp_list_tools webmcp_call_tool |
兩組新分類值得多講一句：
- 分頁選擇——當
list_tabs的 index／active／container／windowId 都不夠分辨兩個以上候選分頁（例如同一個網址開了兩個分頁），request_tab_selection讓使用者直接在 Firefox 分頁列右鍵挑一個，AI 用get_tab_selection輪詢結果——跟前面「換你」那個交接動作是同一個精神，只是這次是指認而不是操作權轉移。 - 對話框攔截——原生
alert／confirm／prompt是這類工具共同的死穴：它們是同步、阻塞式的，一旦跳出來就擋住頁面後續所有事件，一般瀏覽器自動化工具的做法是叫 AI 完全避開，不要碰任何可能觸發它們的按鈕。firefox-bridge 反過來做：白名單網域上攔截這些呼叫，讓 AI 用list_dialogs／respond_dialog看到並回答它們，而不是被卡死。代價寫在工具說明裡不迴避——攔截機制是注入頁面自己的 JS 執行環境，那個網域的頁面程式碼原則上讀得到用來跟本機 helper 對話的 token，所以這是使用者明確選擇加入白名單網域才有的風險，不是預設行為。
清單本身不是重點，挑三個講為什麼它們在這裡：
wait_for——現代網頁的內容是等出來的，不是抓出來的。實測跑一趟 PageSpeed Insights 稽核，分數要等約 60 秒才渲染出來；前兩次read_page讀到的都是loading，等完之後同一個 tabId 再讀就拿到完整報告。WebFetch 抓一百次也只會拿到那個loading。list_containers——Firefox 的 Multi-Account Containers 讓你在同一個瀏覽器裡同時是「公司帳號」和「個人帳號」。AI 要能指定用哪個身分開分頁，否則它會拿錯的那個人的權限去做事。to_be_deleted——名字很怪，但它永遠不真的刪除任何東西，只把書籤搬到一個「Pending Deletion」資料夾，真正的刪除永遠是你之後自己在 Firefox 裡動手。AI 碰使用者資料時，這是應該有的預設立場。
網站自己開的門：WebMCP（v0.3.14）
前面這些工具（分頁選擇、對話框攔截以外的大多數）做的都是同一件事——假裝成人：點按鈕、打字、讀 DOM。這件事有它的天花板：網站的內部狀態、驗證邏輯、副作用，AI 永遠只能透過畫面去猜，猜錯了就是點錯欄位、填錯格式。
還在草案階段的 W3C WebMCP 做的是反過來的事：讓網站自己在頁面裡呼叫 document.modelContext.registerTool(...)，直接把「這裡有一個工具、這是它的參數、呼叫會發生什麼」講給任何懂 MCP 的東西聽——不透過模擬點擊，是網站自己開的門。
問題是目前絕大多數瀏覽器根本沒有這個 API，網站寫了 registerTool 呼叫也是打進空氣。firefox-bridge v0.3.14（2026-08-21）補上這一塊：在使用者明確加入白名單的網域上，注入一個 document.modelContext 的 shim，讓那些呼叫真正落地，需要 Firefox 153.0+。
四支新工具：add_webmcp_whitelist / remove_webmcp_whitelist 逐網域加入或移除（預設不掃描任何網站）；webmcp_list_tools 列出該分頁已註冊的工具，回傳一個綁定「這一次頁面載入」的 documentId；webmcp_call_tool 呼叫工具時要帶著這個 documentId，對不上（例如頁面早就導覽走了）就回 stale_registration，不會把呼叫誤打進另一個頁面。
2026-08-21 拿自己的網站 ai-lab.oao.tw 實測過一輪：加白名單之後要重新整理頁面 shim 才會生效（不是即時的）；documentId 機制確實擋下了跨頁呼叫；讀→寫→讀一輪跑完，簽到資料正確寫回頁面。過程中還看到一個有意思的細節——被測頁面在自己宣告的工具 schema 描述裡，主動寫了給 AI 看的、防 prompt injection 的提醒，這是網站自己選擇要做的事，不是 firefox-bridge 逼出來的。
限制一樣誠實列出：只支援最外層 frame（iframe 裡的 WebMCP 目前碰不到）；只 shim 了 document.modelContext，還沒做 navigator.modelContext；沒有 unregister——一個分頁的工具集合只會變多，要清空得重新整理。112 個自動化測試通過，但這是新功能，離「日常生產流程」還有距離，跟 combo script 那節講的是同一句話：機制驗證過了，規模化還沒發生。
跟第三方實作對照，不只自己測自己
ai-lab.oao.tw 證明機制能動，但那是自己寫的頁面，測不出「跟業界真正的 WebMCP 實作對不對得起來」。所以另外找了 webmcp.sh——MCP-B 的官方 demo，跑了一輪。MCP-B 是目前最接近「WebMCP 參考實作」的專案，跟 W3C Web Machine Learning Community Group 那個工作小組同源，有自己的 Chrome 擴充套件、npm 套件週下載近五千次——不是隨便一個玩具站。
對到真正的第三方實作，不是自己跟自己兜得起來
webmcp_list_tools 正確解析出對方頁面自己註冊的 10 支工具，含完整 schema 與說明；呼叫 list_entities 讀取成功；呼叫 create_entity 寫入一筆中文資料，回應裡看得到完整寫回的物件（id、時間戳記、token_cost 都是對方系統算出來的，不是回聲）；導覽離開頁面後，拿舊的 documentId 重打 list_entities，正確回 stale_registration，沒有誤打進新頁面。
意義在於：firefox-bridge 這個 shim 不是只跟自己寫的測試頁面兜得起來，是跟目前業界最主要的 WebMCP 落地實作對上了介面——讀、寫、跨頁防呆三件事都經得起別人的程式碼檢驗。
這也補上 2026-08-01 講過的一句話：AMO（Firefox Add-ons 官方商店）上架的前置條件是先把 WebMCP 做完——現在做完了，上架這件事可以重新排進來，但截至目前還沒有實際送審。
AI 把自己寫掉的地方：combo script
同一個 repo 裡還有第二台 MCP server，firefox-bridge-bot。它不是主 server 的功能，是獨立註冊的另一台，而它做的事乍看很窄、其實是整個專案的重點。
它是一個 script 載入器。開機時掃 scripts/ 目錄，每個檔案匯出的 name / description / inputSchema 直接註冊成一支 MCP 工具，而 script 拿到的是一條通往同一個 Firefox 的通用通道。
所以 script 能做的事 = bridge 能做的事全集。type、click、upload_file 都在裡面——填表、上傳、跑完一整趟流程都可以，不是只能讀。
現在有三支，各自驗證了機制的不同角落：
read_url_fast——一次讀最多 10 個網址。開拋棄式私密視窗、讀完就關、走 Firefox 自己的 Reader View 抽文，但那是這支 script 的選擇，不是機制的限制。read_news——批次讀自由時報、公視新聞網，能分類別、關鍵字搜尋、或直接吃 RSS feed；同一批文章用bridge.acquireTab+ 有界並發批次抓，抓不到全文時自動退回read_page。分類頁的網址規則、RSS 有哪些分類、關鍵字搜尋涵蓋哪些子網域，全部是逐一驗證過才寫死進 config，不是猜的。get_weather——中央氣象署縣市預報，含即時天氣警特報。縣市名稱找 CID 代碼、Vue 渲染後的預報 widget 用正則從純文字抽欄位、頁面 layout 換行位置不穩定就用容錯 pattern 吸收——這些細節全部沒有官方 API，是對著真實頁面一步步核對出來的。
三支的共同點：要常駐、要留在既有視窗、要填完表單不關掉，都只是另一支 script 的事——機制本身沒有變。
這支 script 的實測數字（工具自報 durationMs，不含模型往返）：
concurrency:1）5 頁跟 3 頁幾乎一樣快——牆鐘時間由最慢那一頁決定，加頁數幾乎不加成本。（循序那組是在並發之後才跑的，快取已暖、條件對它有利，仍然慢三倍，所以不是量測順序造成的偏差。）
要誠實講一件事：這省的是時間，不是 token。並發只縮短牆鐘時間，工具呼叫次數一次都沒少。真正省 token 的是「批次」——10 個網址壓成 1 次呼叫，省掉的是 19 輪模型往返，每一輪都要重送一次上下文。這兩件事常被混為一談。
還缺的一塊：工具端沒有篩選參數。能傳一個關鍵字只回符合的段落，才會真的動到 token 這一項。
這正是對 microsoft/skill-recorder 的回答
微軟 2026 年 8 月開源了 skill-recorder：錄下人的桌面操作，讓 Copilot CLI 事後看錄影反推意圖，產出一份 SKILL.md 給下一次的 AI 讀。
它為什麼需要「人示範、AI 事後看」？因為 Copilot 碰不到那個畫面。錄製不是設計上的偏好，是搆不到的情況下的變通。
firefox-bridge 沒有這個限制，所以它不需要 record mode。AI 自己動手試，當場就知道哪一步成功、哪一步跳出確認框、哪個欄位其實不用填——這些是錄影事後回放猜不出來的。試通了之後，把成功那條路徑寫成一支 script，放進 scripts/，它就是一支永久的工具。
| 誰示範 | 產出物 | 下次執行要 AI 嗎 | |
|---|---|---|---|
| Skill Recorder | 人錄螢幕 | SKILL.md，給 AI 讀的說明 | 要 |
| Copilot Studio computer use | 沒人，雲端 VM 看畫面點滑鼠 | 無，每次重看重點 | 每次都要 |
| firefox-bridge + bot | AI 自己試 | 可執行的 script | 不要 |
差別最後會落在帳單上：computer use 的 AI 是每次執行都要付的通行費，這裡的 AI 是一次性的顧問費。
你幫我，我幫你
但 AI 不是每一步都做得到。而有趣的是，兩邊卡住的地方剛好互補：
- 人卡在「不知道要點什麼」——系統沒人教，設定埋在三層選單裡，上一個負責的人離職了。
- AI 卡在「知道要點什麼，但點不下去」——MFA 推播、CAPTCHA、SSO 跳轉、原生檔案對話框。
錄影解不了這個，因為回放的時候人不在，不能插話。computer use 更解不了，因為人根本不在場，卡住就是卡住。只有共處同一個分頁，才有「換你」這個動作。
2026-08-07 實際跑了一次。用 open_private_window 開一個乾淨的私密視窗（沒有任何既有 session）連 Outlook：
然後在同一個私密視窗裡開另一個服務 admin.microsoft.com——不同 host、不同產品——直接落在 Microsoft 365 admin center 首頁，沒有再出現任何登入畫面。
人做的那一次交接，付清的是整個 tenant
這是乾淨 profile 永遠拿不到的東西：它連第一個服務都進不去，遑論第二個免費。而這裡人只動手一次，之後 AI 在那個視窗裡走到哪、SSO 就跟到哪。
反過來說也成立：那個視窗現在等於管理主控台的操作權。所以 lease 模型跟「什麼時候關由人決定」這個姿態不是多餘的儀式——誰在操作是明確的，而收回權限只是關掉一個視窗。
雙向都成立。AI → 人：走到第七步遇到 MFA，停下來說「推播寄到你手機了」，人按完，AI 接回去繼續，狀態還在那個分頁裡。人 → AI：人自己點到那個藏很深的頁面，然後說「就是這裡，以後每個月幫我做一次」——AI 不必從首頁摸索，它看得到的就是你眼前這一頁。
這就是帶新人的形狀，而且可以中途修正：「那個欄位不用填」「那個是測試環境，換另一個」。
沒有 API 的系統，畫面就是 API
把前面兩段接起來，會得到一個比「瀏覽器自動化工具」大一點的東西。
企業內部系統最常見的狀態是：有畫面，沒有 API。或者有 API 但要另外付費、要走採購、要等原廠排程。而畫面是唯一保證存在、而且不會被拿掉的介面——一整層樓的人靠它上班，廠商可以不給你 API，但不能不給你畫面。
UI 還有一個被低估的好處：它壞掉的時候很吵。系統改版當天使用者就會哀嚎，你當天就知道要修。API 悄悄改了一個欄位的型別，可能三個月後對帳才發現。
所以一條合理的路徑是四階，而且終點是 AI 把自己移除：
第三階不需要任何新東西。MCP 說到底只是 JSON-RPC，一支腳本就可以當 MCP client，跟 LLM 一點關係都沒有。那 44 個工具現在就是一組腳本 API。
它讀起來很像 Playwright。差別只有一個，但那個差別決定一切：Playwright 開乾淨 profile，永遠登不進去。「有登入狀態的瀏覽器自動化」這個東西，市面上其實不存在。
這件事本質上是 RPA 的老命題。不同的是前置成本——摸清流程、寫 selector、維護改版——那一塊被 AI 吃掉了。不是 AI 取代了自動化，是 AI 把自動化的門檻拆掉了。
限制
- 只有瀏覽器。Windows 肥用戶端碰不到——那類系統只能靠桌面層的方案（skill-recorder 錄得到整個桌面，但沒有出海口；兩邊各缺一半）。
- Reader View 會漏「要點擊才渲染」的內容。
read_url_fast跟一般的 readability 系工具漏掉的東西一模一樣，因為底層是同一套。要抓分頁式表格的全部內容，只能拉原始 HTML 自己解。 get_network拿不到 request payload——這是刻意的，理由見下面 Q&A。需要知道前端怎麼組請求時，繞法是讓 AI 直接讀頁面的 JS，比攔封包乾淨。- 「AI 自己寫 script」目前驗證過三個實例（
read_url_fast/read_news/get_weather），還沒跑成一條日常的生產流程。機制本身站得住，但目前每一支都還是「試出來就停在那裡」，沒有排程、沒有下游消費者。 - WebMCP 目前只驗證過兩個網站，還沒有大量網站實際跑過——自己的
ai-lab.oao.tw，以及第三方的webmcp.sh（MCP-B 官方 demo），見上方 WebMCP 段落。 - 還沒上架 Firefox Add-ons——先前等的前置條件（WebMCP）已達成，但還沒送審，見下面 Q&A。
常見問題
不會，而且不是靠事後過濾，是在擴充套件那一側就不存在。password、hidden、file 三種 input 的值整個 key 都不會出現——不是空字串，是那個欄位不存在。上面那趟 Outlook 實測剛好把它演出來，同一次回應裡相鄰的兩筆：
型別比對不分大小寫（type="PASSWORD" 也擋），text 標籤組字也一併排除。
網路觀測那一側更徹底：get_network 只掛 onCompleted，只收 url、method、statusCode、type、timeStamp。要拿到 request body 必須明確去要 requestBody，headers 同理，兩者都沒做——帳密在架構上進不來，不是靠過濾擋住。
殘留的風險講明白：url 是完整記錄的，所以憑證放在 query string 裡的情況（?token=、?api_key=）仍然會整條進去。
Playwright 開的是全新的乾淨 profile，沒有你的 session cookie、沒有 SSO 憑證、沒有 container 身分。對公開網站兩者可以互換，對需要登入的內部系統，Playwright 看到的永遠是登入頁。firefox-bridge 不開瀏覽器，它接手你已經開著的那個。
它們做的是另一件事。那是瀏覽器廠商的 AI，不是你的 AI。
Chrome 的 Built-in AI 把 Gemini Nano 包成一組給網頁開發者呼叫的 API（Writer、Rewriter、Translator、Summarizer、Prompt）——受益的是網站，不是你的 agent。Edge 走得更遠：2026 年 5 月 20 日起在 Edge for Business 開放 agentic browsing 限定預覽，Copilot 可以導覽網頁、填表、跑多步流程，但範圍必須是 IT 政策核准過的網站。
共同點是：模型是廠商綁定的，能力邊界是廠商定的，開放到哪也是廠商決定的。你換不掉那個模型，也不能叫它去做廠商沒開放的事。
firefox-bridge 的方向相反——模型你自己選（任何 MCP client 都能接），協定是開放的，全部跑在本機。它不是「瀏覽器裡多了一個 AI」，是你的 agent 拿到了一個瀏覽器。
Mozilla 的立場剛好站在另一邊，而且他們自己寫得很直白：「在 Firefox 裡，你永遠不會被鎖進單一生態系，也不會被迫在瀏覽時使用 AI。」他們對 AI 公司做的瀏覽器的批評是——那些產品逼你二選一：要嘛一直用 AI，要嘛完全不用；而且是把你困在對話迴圈裡，而不是把你帶向更廣的網路。
要公允的話，有兩件事得補上。第一，Firefox 自己也內建了 AI（側邊欄聊天機器人、分頁分組、連結預覽、PDF 替代文字），所以這不是「不做 AI」，是「AI 預設不來煩你」。第二，那個能一次關掉全部 AI 功能的總開關，是 2026 年初使用者反彈之後才承諾、在 Firefox 148（2026-02-24）才推出的——不是一開始就有。
但對這個專案來說，那個立場剛好是對的地基：firefox-bridge 需要的正是一個不替你決定該用哪個 AI 的瀏覽器。
兩者也不互斥。你大可以在 Edge 裡用 Copilot 做它擅長的事，同時讓自己的 agent 在 Firefox 裡跑那條沒人會替你做的內部系統流程。
從 GitHub Releases 下載簽章過的 .xpi（每個 release 都附 .sha256），加上 MCP server 與 native host 三段各自設定，步驟在 repo 的 README。
還沒上架 Firefox Add-ons（AMO）。先前刻意等的前置條件——把 WebMCP 做完——在 v0.3.14（2026-08-21）已經做完，但截至目前還沒有實際送審。
MIT 授權，可以。原始碼在 github.com/raychao-oao/firefox-bridge，第三方套件授權另列在 THIRD_PARTY_LICENSES.md。
Chrome 那邊已經有 claude-in-chrome，Firefox 沒有對應的東西。而 Firefox 有兩樣 Chrome 給不了的，剛好都打在這件事的要害上：
Multi-Account Containers——同一個瀏覽器同時掛著多重身分，公司帳號跟個人帳號可以並存在線，AI 得指定用哪一個。這是 Firefox 獨有的。
好讀模式（Reader View）——Firefox 把它內建在瀏覽器裡，而且開放給擴充套件用。所以 read_article 跟 read_url_fast 的抽文是直接跟瀏覽器要現成的結果，不用自己塞一份 parser 進來、也不用維護它。
當然，也可能純粹是愛好小動物。
相關專案
- microsoft/skill-recorder 實測評析——本文對照的那個專案，翻進原始碼看它到底錄得到什麼
- cred-mcp——憑證管理層。「明文永遠不進 LLM context」這條線，兩個專案同源
- Enterprise AI Ops Stack——基礎設施層、身分層、終端層的三層架構總覽