如何在 Chrome 擴充功能中使用 Transformers.js

隨著瀏覽器擴充功能的功能日益強大，將機器學習模型直接帶入客戶端已成為開發趨勢。Transformers.js 讓開發者能在瀏覽器中執行 Hugging Face 上的模型，而 Chrome 擴充功能則是絕佳的應用場景。最近 Hugging Face 官方部落格分享了一份實戰指南，說明如何在 Manifest V3 的限制下，利用 Transformers.js 打造具備本地 AI 能力的 Chrome 擴充功能。這份指南不僅展示了技術架構，更提供許多實務觀察，值得台灣的開發者與 AI 應用愛好者參考。

### 架構總覽：三個運行環境各司其職

在 Manifest V3 的規範下，擴充功能主要由三個進入點組成：背景服務工作者（background service worker）、側邊面板（side panel）以及內容腳本（content script）。背景腳本扮演「控制中樞」的角色，負責管理模型生命週期、代理邏輯與工具執行，所有耗費資源的推理工作都在這裡完成。側邊面板則作為使用者互動層，負責聊天輸入輸出與串流更新，保持輕量化。內容腳本則像一座「頁面橋樑」，專注於 DOM 提取與元素突顯等頁面級操作。這樣的職責分離，不僅能避免模型重複載入，也能確保 UI 反應迅速，同時遵守 Chrome 對 DOM 存取的資安邊界。

### 訊息傳遞：單一協調者模式是關鍵

由於三個運行環境彼此隔離，標準化的訊息溝通便成為整座架構的骨幹。這份指南建議開發者透過列舉型別（enum）定義所有訊息類型，並讓背景腳本擔任唯一的協調者。例如側邊面板發送「AGENT_GENERATE_TEXT」事件，背景腳本收到後立即附加到對話記錄、執行推理，再發出「MESSAGES_UPDATE」事件讓側邊面板重新渲染。同樣地，內容腳本也僅透過背景腳本接收「EXTRACT_PAGE_DATA」或「HIGHLIGHT_ELEMENTS」等指令。這種單向、統一的訊息流，大幅降低除錯難度，也讓擴充功能更容易維護。

### 模型整合細節：雙模型分工提升效率

在模型選擇上，該擴充功能使用兩個不同角色的模型：文字生成採用 Gemma 4（E2B 版本的 ONNX 量化模型，位元率 q4f16），負責推理與工具決策；向量嵌入則使用輕量級的 all-MiniLM-L6-v2（FP32 格式），專門處理語義相似度搜尋（例如「詢問網站」或「尋找歷史記錄」功能）。所有推理都集中在背景腳本執行，這樣的好處是：所有分頁與工作階段共享同一組模型實例，不僅節省記憶體，也能利用 Transformers.js 最新提供的 DynamicCache 類別實現一致的 KV 快取，進而加速生成速度。

### 實際開發觀察：回應性與記憶體管理的權衡

在實作過程中，開發者特別提到幾個值得注意的面向。首先，Manifest V3 的服務工作者在閒置時可能被瀏覽器終止，因此模型載入與快取策略必須考慮重新初始化成本。其次，由於大型語言模型在客戶端佔用不少記憶體，選擇適當的量化格式（如 q4f16）以及只在必要時加載模型，是維持瀏覽器流暢的關鍵。此外，對話歷史儲存在背景腳本的記憶體中，而非傳送到側邊面板儲存，這樣能避免資料不一致，也讓串流更新更自然。

### 可能影響：本地 AI 擴充功能的新標準

這份指南的推出，對 Chrome 擴充功能開發社群具有指標意義。過去要在擴充功能中整合 AI，多半依賴雲端 API，但 Transformers.js 搭配 Manifest V3 的架構，讓開發者能完全在本地端執行推理，達成更好的隱私保護與離線可用性。對於台灣的開發者而言，這意味著可以設計出更多不依賴後端伺服器的智慧工具，例如即時網頁摘要、自訂搜尋助手