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 不該同時操作同一個分頁。後來才發現它剛好是別的東西，這篇後半會回來講。
33 個工具
| 分類 | 工具 |
|---|---|
| 分頁租借 | 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 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 |
清單本身不是重點，挑三個講為什麼它們在這裡：
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 碰使用者資料時，這是應該有的預設立場。
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 的選擇，不是機制的限制。要常駐、要留在既有視窗、要填完表單不關掉，都只是另一支 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 一點關係都沒有。那 33 個工具現在就是一組腳本 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」目前是設計成立，還沒有第二個實例。
scripts/裡現在只有read_url_fast一支。機制驗證過了，但把它跑成一條日常的生產流程還沒發生。 - 還沒上架 Firefox Add-ons，而且是刻意的——見下面 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 做完才會考慮送審——現在送出去的會是一個還沒定型的介面。
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——基礎設施層、身分層、終端層的三層架構總覽