Gemini Nexus：把 Gemini 網頁版、官方 API 與 OpenAI 相容介面塞進同一個 Chrome 側邊欄
Gemini Nexus 是一款面向浏览器场景的 AI 助手扩展，集成 Gemini Web、Gemini API 与 OpenAI 兼容接口，支持网页上下文、图像处理、工具调用和 MCP 浏览器控制。
秒懂
- 它是什麼？
- 這個 MV3 擴充套件用一套 provider 驅動層同時接上九種以上的模型來源，還內建 CDP 瀏覽器控制與 MCP 工具。它最吸引人的 Web Client 模式靠逆向 RPC 端點取得 token，README 自己就說這很可能違反 Google 服務條款。
- 適合誰用？
- 如果你已經有 Google AI Studio、OpenRouter 或 Anthropic 的 key，而且想要一個能讀取當前分頁、能呼叫 CDP 控制瀏覽器的側邊欄，Gemini Nexus 值得裝來試；如果你打算在受管理的企業 Chrome 環境或需要合規稽核的團隊裡部署，Web Client 模式與浮水印移除這兩個功能會直接踩到紅線，請改用純 API provider 或換工具。動手前先確認三件事：manifest 要求的權限範圍、`services/providers` 底下對應你 provider 的驅動檔是否支援你要的模型 ID、以及 Web Client 模式抓取的 `atValue`、`blValue`、`f.sid` 是否會被 Google 的風控擋下。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 9 天前。
- 用什麼語言寫的？
- 主要是 JavaScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是分頁與模型之間的搬運問題
多數人用 AI 的流程是這樣：看到一段內容，複製，切到另一個分頁或桌面應用，貼上，等回覆，再複製回來。Gemini Nexus 針對的就是這段搬運。它是一個 Manifest V3 的 Chrome 擴充套件，把對話介面放在側邊欄，同時注入一條浮動工具列，讓你在原頁面上直接框選、截圖、丟圖片進去問。
目標使用者是已經在瀏覽器裡工作的人：讀規格文件、比對多個網頁、看儀表板截圖、需要 AI 讀當前頁面上下文。README 把這個定位寫成「give your browser a native AI layer」，實際做法是把模型來源抽象成 provider，讓同一個介面後面可以掛 Gemini Web、Gemini 官方 API、OpenAI 相容端點、Anthropic Messages API 等等。另一個容易被忽略的功能是側邊欄的作用範圍可以用分頁限制，避免每個分頁都跳出助手。
provider 驅動層：九種來源，四種實作
README 列出的 provider 對照表透露了架構重點：表面上支援九種來源，實際上只落在四個驅動檔上。`services/providers` 底下有 `web.js`、`official.js`、`openai_compatible.js`、`anthropic.js`。OpenAI 官方、DeepSeek、OpenRouter、Qwen / DashScope、Zhipu 全部走 `openai_compatible.js`，靠不同的 Base URL、API Key 與模型 ID 參數，加上各自的預設值來區分。
這個設計的好處是接入新 provider 的成本低，只要它的端點相容 Chat Completions 或 Responses API。代價是差異被壓進同一條程式路徑裡：OpenRouter 要抓 `/models` 並支援 provider routing JSON、要送原生的 `reasoning` 欄位；DashScope 要 `enable_thinking` 與 VL 圖片輸入；Zhipu 有自己的 thinking payload 格式。這些都變成 `openai_compatible.js` 內部的分支。Anthropic 與 Gemini 官方 API 各自獨立成檔，因為 Messages API 與 Gemini 的請求格式差得夠遠。
Web Client 是唯一不靠 API key 的路徑，也是整個專案爭議最大的部分。README 的資料流揭露章節寫得很直接：擴充套件逆向 gemini.google.com 的內部 RPC 端點，從頁面 HTML 裡抽取 `atValue`、`blValue`、`f.sid` 這幾個 token，存在本機，再用來模擬瀏覽器請求。請求會帶著你的 session 憑證送到 `gemini.google.com` 與 `push.clients6.google.com`。
網頁上下文、CDP 控制與 MCP 三條線
除了聊天，這個擴充套件還有三組功能值得分開看。
第一組是網頁內容理解。側邊欄可以讀當前分頁，也可以吃圖片與截圖。這是側邊欄型擴充套件的基本盤，沒有太多意外。
第二組是瀏覽器控制。README 說它用 Chrome DevTools Protocol 提供 browser-control 工具，並用 Chrome 原生的 tab group 標記被控制的分頁，讓 `list_pages` 與 `select_page` 只聚焦在受控範圍內。這個設計是對的：如果沒有把受控分頁圈起來，模型在多分頁環境下很容易操作到錯的目標。
第三組是外部 MCP 工具。README 把它列為選用功能，讓瀏覽器內的工作流程可以呼叫外部的 MCP server。這裡要注意資料流：一旦接了自架的 MCP server，你的文字、圖片與上傳檔案就會送到那個端點，而不是只到模型供應商。
另外 README 提到 Gemini API 的 Google Search grounding 會把網路來源顯示在回覆裡，OpenAI 相容路徑則可依端點選擇 Responses API 的 `web_search` 或 Chat Completions 的 `web_search_options`。這兩個是不同層級的搜尋整合，行為不會一致。
安裝與設定：從原始碼建置到 provider 參數
專案是 Vite 加 TypeScript 的組合，主要語言標示為 JavaScript。README 沒有附上完整的安裝指令區塊，只給了技術棧徽章與 provider 對照表，所以建置步驟需要以倉庫內的 `package.json` 為準，這點在採用前要先自己確認。
設定面的關鍵是每個 provider 各自的 Base URL、API Key 與 Model IDs。API key 存在 Chrome extension storage 裡，README 明確說不會傳給所選 provider 以外的第三方。Gemini Web 走的是另一條路：不需要 key，但需要保持 Google 帳號登入狀態，而且可以開啟 temporary chat，讓 Web provider 的請求不進入 Gemini 的 Recent chats。
上下文管理有兩個機制：summary compression 與 recent-turn trimming，目的是降低超過模型上下文上限的風險。歷史訊息重編輯只支援 API provider，Web Client 不在支援範圍內。README 也提到設定會盡量在擴充套件身分變更與本機升級路徑之間保留。
如果你只想驗證基本可用性，最短路徑是先在側邊欄填入一個 OpenAI 相容端點的 Base URL、API Key 與模型 ID，確認對話能通，再決定要不要碰 Web Client。
Web Client 與浮水印移除：README 自己標紅的兩個功能
這個專案最罕見的地方是它把風險寫在 README 裡。關於 Web Client，原文寫著這個做法「likely violates Google's Terms of Service」，並可能構成未授權存取。這不是社群揣測，是專案自己的揭露。
第二個是浮水印移除。README 說針對 Gemini 生成的圖片，擴充套件會移除內嵌的浮水印（metadata marker）以便直接下載，並提醒這會剝除 AI 生成內容的署名，使用者要自行注意著作權與 Google 對生成內容的政策。
兩件事合起來意味著：這個擴充套件有一部分功能在設計上就預設了服務條款的灰色地帶。README 用「Use at your own risk」收尾，並說這些功能是為研究與實驗用途提供。對個人實驗者，這是知情選擇；對需要合規紀錄的組織，這是直接排除項。
還有一個實際風險是穩定性。逆向 RPC 端點與從 HTML 抽 token 的做法，會隨 Google 前端改版而失效，而且失效時通常不會有優雅的錯誤訊息，只是登入狀態抓不到。這是選用 Web Client 就必須接受的維護現實。
什麼情況下它不是對的工具
第一，需要跨裝置同步對話與設定的情境。這是 Chrome 擴充套件，對話與 key 綁在瀏覽器設定檔裡。你在筆電上問過的內容，不會出現在桌機上。
第二，需要團隊共用 prompt 或集中管理的場景。這裡沒有伺服器端，沒有共享工作區，每個人各自填自己的 key。
第三，只需要單純聊天、不需要讀取當前分頁的人。那用 Gemini 網頁版或任何桌面客戶端就好，裝一個要求瀏覽器控制權限的擴充套件來做同一件事，是把攻擊面變大而沒有換到東西。
第四，對供應鏈敏感的人。MV3 擴充套件能讀取你造訪的頁面內容，這個專案還額外要求 CDP 控制與注入浮動工具列。README 沒有提供權限最小化的說明，採用前應該自己讀 manifest。
第五，需要穩定 API 契約的自動化流程。Web Client 依賴逆向端點，把它放進 CI 或排程任務裡，等於把排程綁在別人的前端版更節奏上。
替代路線與真正的差異
最直接的替代是各家官方的桌面或網頁客戶端，例如 Gemini 網頁版本身、ChatGPT 桌面版、Claude 桌面版。差異在上下文取得方式：官方客戶端要靠你手動複製貼上，或透過各自有限的外掛機制；Gemini Nexus 是直接讀當前分頁與截圖。代價是你要交出瀏覽器權限。
另一條路是純 API 的自架聊天前端，例如各式接 OpenAI 相容端點的開源介面。它們的 provider 抽象通常做得更乾淨，也更容易部署給多人用，但沒有瀏覽器控制這一層，`list_pages`、`select_page` 這種能力不存在。
還有一條是自動化框架路線，例如直接寫 Playwright 或 Puppeteer 腳本搭配模型 API。這條路換來的是可重現性與版本控制，代價是你要自己處理對話狀態、上下文壓縮與 UI。Gemini Nexus 把這些都包好了，但包好的東西不能進版控。
真正的分界線是：你要的是「在瀏覽器裡隨手用 AI 讀頁面」，還是「把 AI 讀頁面變成可重複執行的流程」。前者選 Gemini Nexus，後者選腳本。
授權、維護成本與採用判斷
授權是 MIT，預設分支 main，最近一次推送在 2026 年 9 月，近期釋出 v5.3.0、v5.2.4、v5.2.0。釋出節奏看起來是幾週一版，這對一個依賴外部服務前端行為的擴充套件來說是必要的，但也意味著版本之間可能出現設定或行為變動。
MIT 只涵蓋程式碼本身。它不會讓你取得 Gemini Web 的合法存取權，也不會改變 Google 對生成內容的政策。README 自己就把 Web Client 與浮水印移除標為可能違反 ToS，這部分的法律風險由使用者承擔。我不是律師，這裡只能指出專案揭露了什麼，實際後果要自己評估。
維護成本主要落在兩處。一是 provider 端點的變動：OpenAI 相容生態的欄位（`web_search_options`、`reasoning`、`enable_thinking`）各自演化，`openai_compatible.js` 會是最常被改的檔案。二是 Web Client 的 token 抽取：`atValue`、`blValue`、`f.sid` 這三個欄位只要 Google 改一次頁面結構就會斷。
判斷方式很簡單。先決定你要不要 Web Client 模式。不要，這個專案就是一個功能偏多的多 provider 側邊欄，風險可控。要，就接受它隨時可能失效，而且失效原因不在專案作者手上。
編輯結論
如果你已經有 Google AI Studio、OpenRouter 或 Anthropic 的 key，而且想要一個能讀取當前分頁、能呼叫 CDP 控制瀏覽器的側邊欄，Gemini Nexus 值得裝來試；如果你打算在受管理的企業 Chrome 環境或需要合規稽核的團隊裡部署，Web Client 模式與浮水印移除這兩個功能會直接踩到紅線，請改用純 API provider 或換工具。動手前先確認三件事：manifest 要求的權限範圍、`services/providers` 底下對應你 provider 的驅動檔是否支援你要的模型 ID、以及 Web Client 模式抓取的 `atValue`、`blValue`、`f.sid` 是否會被 Google 的風控擋下。
社群筆記