Chrome on KnightLi的博客

browser-harness 的 domain skills 機制：讓 AI Agent 不再重複踩網頁自動化的坑

Sun, 24 May 2026 23:43:35 +0800

browser-use/browser-harness 最有意思的地方，不只是讓 AI Agent 能控制真實 Chrome，而是它把網頁操作中的經驗變成了可以重用的 domain skills。

這件事很關鍵。瀏覽器自動化真正困難的地方，往往不是「能不能點擊按鈕」，而是每個網站都有自己的細節：

哪些頁面必須登入。
哪些資料可以直接走 API。
哪些按鈕用普通 DOM 點擊無效。
哪些 iframe、shadow DOM、彈窗會擋住流程。
哪些選擇器穩定，哪些只是臨時 class。
哪些操作涉及帳號、支付或不可逆變更，必須讓人確認。

如果這些經驗只留在一次任務日誌裡，Agent 下次還會重新踩坑。domain skills 的作用，就是把這些經驗沉澱下來，讓 Agent 不必每次都像第一次打開網站。

domain skills 是什麼

可以把 domain skills 理解成「給 Agent 看的站點操作手冊」。

它不是普通的使用者文件，也不是一次性腳本。它更像一組經過實測的站點級知識：

這個站點適不適合用瀏覽器。
如果有 API，應該優先用哪個 API。
如果必須操作網頁，應該從哪個 URL 進入。
哪些 DOM 結構、aria-label、按鈕行為經過驗證。
哪些常見寫法會失敗。
哪些場景要停止並請求人類介入。

這類內容既能被人類審查，也能被 Agent 在任務中讀取。它把「臨場摸索」變成「可維護經驗」。

它不是讓 Agent 盲目點擊

一個好的瀏覽器 Agent，不應該把所有問題都變成打開網頁、看截圖、點按鈕。

domain skills 裡很重要的一類經驗，恰恰是在告訴 Agent：什麼時候不要用瀏覽器。

比如 ArXiv 這類站點，論文搜尋、元資料和摘要可以透過 Atom API 或 HTML meta 標籤直接拿到。用 HTTP 請求通常比打開瀏覽器更快、更穩，也更容易解析。

GitHub 也是類似思路。倉庫、使用者、release 資料優先用 REST API；檔案內容優先讀 raw.githubusercontent.com；只有 GitHub Trending 這類沒有等價 API 的頁面，才需要進入瀏覽器。

這說明 browser-harness 的思路不是「瀏覽器萬能」，而是把瀏覽器放在正確位置：當 API、HTTP、靜態頁面無法解決問題時，再讓 Agent 操作真實頁面。

它記錄的是站點級知識

傳統自動化腳本通常圍繞一次任務寫，比如：

`1`	`打開頁面 -> 輸入關鍵詞 -> 點擊按鈕 -> 下載文件`

這種腳本可以完成任務，但經驗很容易散落在程式碼裡。站點一改版，腳本失效；換一個任務，很多經驗也沒法重用。

domain skills 的粒度更接近站點級知識庫。它關心的是：

Amazon 搜尋結果裡哪個容器選擇器穩定。
GitHub 哪些資料應該走 REST API。
LinkedIn 邀請管理頁的按鈕 aria-label 有什麼差異。
Shopify Admin 裡哪些頁面是嵌入式 app。
Shopify Polaris 輸入框為什麼不能只用普通 JS 設定 value。
Browser Use Cloud 的瀏覽器實例如何建立、列出和清理。

這些經驗不是一次任務的步驟，而是以後很多任務都會用到的判斷依據。

例子：Amazon 商品搜尋

Amazon 商品搜尋的經驗，重點不只是「怎麼搜尋商品」，而是哪些路徑更穩定。

比較可靠的做法是直接使用搜尋 URL，而不是每次都打開首頁再模擬輸入。搜尋結果可以從 [data-component-type="s-search-result"] 這樣的容器中提取。欄位提取也有細節：標題、價格、評分、評論數、是否贊助，都有各自更穩的 DOM 來源。

這種經驗對 Agent 很有價值。沒有它時，Agent 可能會從截圖裡猜按鈕、反覆嘗試選擇器；有了它之後，Agent 可以直接進入更穩定的資料提取路徑。

更重要的是，這類 skill 還會記錄陷阱。例如某些看似可用的選擇器，在贊助結果或交叉推薦區域裡會誤讀。這種坑只有實測過才知道。

例子：LinkedIn 邀請管理

LinkedIn 這類站點更接近真實帳號工作流，風險也更高。

在邀請管理頁裡，Accept 和 Ignore 按鈕的 aria-label 格式不同，不能簡單地從一個推導另一個。有些邀請卡片裡的 Accept 控件甚至不是 <button>，而是 <a>，普通 CDP 點擊不一定能觸發接受動作。

這種細節說明，真實網頁自動化不是「定位到元素就結束」。按鈕標籤、事件綁定、軟導航、元件實作方式，都會影響操作是否真的生效。

對 Agent 來說，這類經驗還有一個安全含義：涉及社交帳號、邀請、消息、發文的操作，不應該完全託管。skill 可以記錄路徑和陷阱，但批量接受邀請、對外發送內容、修改帳號資料這類動作，最好保留人工確認。

例子：Shopify Admin

Shopify Admin 的經驗說明了另一個問題：後台系統往往不是一個頁面，而是一堆嵌入式應用和複雜元件的組合。

很多 Shopify app 會運行在 iframe 裡。Polaris React 輸入框、Web Components、嵌入式 app 的互動方式也不同。某些輸入框不能只用 element.value = ...，需要使用更接近真實鍵盤輸入的 CDP keystrokes。

這類 skill 的價值在於，它讓 Agent 先判斷目前頁面屬於哪類 UI，再選擇合適的操作方式。

同時，Shopify 的經驗也強調「能不用瀏覽器就不用瀏覽器」：

唯讀商品和庫存資料，優先用 Storefront API。
有 Admin API token 時，優先用 Admin API。
編輯主題程式碼時，優先用 Shopify CLI。
只有沒有 API、一次性設定、探索後台時，才適合讓瀏覽器介入。

這才是成熟的 Agent 工具選擇邏輯。

例子：Browser Use Cloud

domain skills 不只服務網頁點擊，也可以記錄圍繞瀏覽器執行環境的 API 經驗。

Browser Use Cloud 的經驗裡，會記錄如何透過 REST API 建立 cloud browser、列出正在運行的瀏覽器、清理 zombie browser、取得 liveUrl 和 cdpUrl 等資訊。

這說明 skill 的邊界並不侷限於「某個網頁按鈕怎麼點」。只要某類任務會反覆出現，而且有穩定做法，就可以沉澱成 skill：

API 呼叫方式。
鑑權頭格式。
請求和回應結構。
已驗證狀態碼。
常見失敗模式。
清理和回收資源的方法。

對 Agent 來說，這些都是可重用能力。

為什麼這比臨場推理更可靠

很多人期待大模型每次都能「自己看懂網頁」。但真實任務裡，只靠臨場推理並不穩定。

原因很簡單：

網頁 UI 經常變化。
同一按鈕可能有多種實作。
看得見不代表點得動。
能點擊不代表操作真的生效。
有些任務本來就應該用 API，而不是瀏覽器。
有些操作需要人類確認，不能讓模型自己決定。

domain skills 把這些經驗寫成文件後，有幾個好處：

人類可以 review。
錯誤經驗可以修正。
同一站點的經驗可以持續積累。
新 Agent 可以直接繼承舊經驗。
臨時任務發現可以變成長期知識。

這比把一切都塞進 prompt 或聊天上下文更穩。

團隊可以怎麼用

如果把 browser-harness 用在團隊裡，domain skills 可以變成一種輕量自動化知識庫。

比較適合沉澱的內容包括：

內部後台的登入後路徑。
報表匯出流程。
常見彈窗處理方式。
哪些按鈕需要人工確認。
哪些頁面有 API 替代方案。
哪些選擇器經過實測可靠。
哪些任務不允許 Agent 自動執行。

這類知識不必一開始就很完整。更實際的做法是從低風險、高頻、可回復的流程開始：先讓 Agent 做唯讀、下載、整理、檢查類任務。等流程穩定後，再把經驗整理成 skill。

對團隊管理者來說，skill 文件還有一個好處：它讓自動化邊界變得可見。你可以審查 Agent 知道什麼、能做什麼、應該停在哪裡。

需要注意的邊界

domain skills 能提高 Agent 成功率，但它不應該讓高風險操作完全自動化。

幾個邊界要守住：

不記錄密碼、Cookie、token、客戶資料和內部敏感 URL。
支付、刪除、批量提交、帳號變更、對外發布內容，要保留人工確認。
skill 要寫明驗證日期和適用範圍。
站點改版後，要允許 skill 失效並重新驗證。
不要把繞過風控、規避平台限制當成目標。

換句話說，domain skill 是讓 Agent 更穩，不是讓 Agent 無限制地做事。

簡單結論

browser-harness 的 domain skills 機制說明了一件事：AI Agent 的瀏覽器自動化，不能只靠模型臨場發揮。

一個可用的瀏覽器 Agent，至少需要三層能力：

底層控制能力：截圖、點擊、輸入、下載、CDP、HTTP。
站點級知識：API 優先級、穩定選擇器、元件陷阱、登入邊界。
人類安全規則：憑據不交給模型，高風險操作要確認，敏感資訊不寫進 skill。

domain skills 補的是第二層。它讓 Agent 帶著驗證過的經驗進入網頁任務，而不是每次都重新摸索。

參考資料：

browser-harness domain skills：https://github.com/browser-use/browser-harness/tree/main/agent-workspace/domain-skills
Amazon product-search skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/amazon/product-search.md
ArXiv scraping skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/arxiv/scraping.md
GitHub scraping skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/github/scraping.md
LinkedIn invitation-manager skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/linkedin/invitation-manager.md
Shopify admin skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/shopify-admin/README.md
Browser Use Cloud skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/browser-use-cloud/cloud.md

browser-harness 是什麼？讓 AI Agent 接管真實 Chrome 的瀏覽器自動化工具

Sun, 24 May 2026 17:19:54 +0800

browser-use/browser-harness 是一個面向 AI Agent 的瀏覽器控制工具。它的目標不是再做一層複雜的自動化框架，而是把大模型直接連到真實 Chrome，透過 CDP 完成瀏覽、點擊、截圖、下載、上傳和表單操作。

專案 README 對自己的定位很明確：用一層很薄、可編輯的 CDP harness，讓 LLM 直接連接真實瀏覽器；當任務中缺少 helper 時，Agent 可以在執行過程中補上程式碼，並把可重用經驗沉澱成 domain skills。

這類工具值得關注，是因為瀏覽器仍然是很多真實工作的入口：後台系統、SaaS 面板、電商頁面、招聘網站、CRM、報銷系統、雲控制台、文件平台，往往沒有穩定 API，或者 API 權限比網頁權限更難拿到。讓 Agent 能可靠操作瀏覽器，本質上是在補齊自動化的最後一段距離。

browser-harness 是什麼

從結構看，browser-harness 更像一個給 Agent 用的瀏覽器執行環境，而不是普通使用者手動點擊的瀏覽器外掛。

它的核心思路有幾個：

直接連接 Chrome 或 Chromium。
透過 CDP WebSocket 操作頁面。
讓 Agent 組合截圖、座標點擊、DOM、網路請求和原始 CDP 完成任務。
把任務相關 helper 放在 agent-workspace/agent_helpers.py。
把站點相關經驗沉澱到 agent-workspace/domain-skills/。
保持核心很薄，避免做成龐大的自動化平台。

README 提到，專案核心架構大約是 4 個核心檔案、約 1000 行程式碼，主要包括 install.md、SKILL.md、src/browser_harness/、agent-workspace/agent_helpers.py 和 agent-workspace/domain-skills/。

這種設計的重點不是內建所有網站能力，而是給 Agent 一個足夠貼近真實瀏覽器的操作層，讓它在具體任務裡補齊缺失能力。

它和傳統瀏覽器自動化有什麼不同

傳統瀏覽器自動化通常圍繞測試框架展開，例如 Playwright、Selenium 或 Puppeteer。它們適合寫確定性的測試腳本：打開頁面、定位元素、點擊、斷言結果。

browser-harness 面向的是另一類任務：使用者說一句目標，Agent 自己探索頁面、判斷狀態、處理彈窗、補 helper、複用站點經驗。它強調的是互動過程中的適應性。

差異可以這樣理解：

Playwright 更適合人寫腳本，Agent 執行腳本。
browser-harness 更適合 Agent 邊看頁面邊行動。
傳統自動化偏固定流程。
browser-harness 偏開放任務。
傳統腳本常依賴選擇器。
browser-harness 鼓勵先截圖、再按可見介面行動，必要時再回到 DOM 或 CDP。

這不表示它要取代 Playwright。對穩定測試來說，Playwright 仍然更成熟。browser-harness 的價值在於把真實網頁變成 Agent 可操作的環境，尤其適合頁面結構複雜、步驟不固定、需要臨場判斷的任務。

為什麼強調真實 Chrome

很多瀏覽器 Agent 工具會使用隔離的無頭瀏覽器。這樣部署簡單，也適合批量任務，但它有一個現實問題：使用者真實工作裡的登入狀態、擴充功能、歷史記錄、書籤和日常瀏覽器環境，不一定能直接複用。

browser-harness 支援連接本機 Chrome，也支援 Browser Use cloud browser。對本機瀏覽器，它提供兩種方式：

透過 chrome://inspect/#remote-debugging 允許目前 Chrome 實例被連接。
用 --remote-debugging-port=9222 --user-data-dir=... 啟動一個隔離 profile。

如果要讓 Agent 幫你處理真實帳號裡的任務，專案文件更傾向第一種方式，因為它能複用日常 Chrome 的登入狀態、擴充功能和書籤。如果要做無人值守自動化，或者不希望被彈窗打斷，則更適合使用隔離 profile 或雲瀏覽器。

這裡的取捨很清楚：真實瀏覽器更貼近使用者工作流，但安全邊界也更敏感；隔離瀏覽器更適合自動化，但需要重新處理登入和環境。

可編輯 helper 與 domain skills

browser-harness 最有意思的地方，是它把「Agent 會學到什麼」設計進了專案結構。

agent-workspace/agent_helpers.py 用來放任務中臨時補出的 helper。比如 Agent 做檔案上傳時發現現有能力不夠，可以補一個穩定的上傳函式；下次再遇到類似頁面，就不用從零開始。

agent-workspace/domain-skills/ 則用來放站點級經驗。README 裡舉的方向包括 LinkedIn outreach、Amazon 下單、報銷系統等。專案建議不要手寫這些 skill，而是讓 Agent 在真實任務中發現可重用流程後再生成，這樣更貼近實際頁面行為。

這個思路很適合瀏覽器自動化。因為網頁自動化的難點往往不是「怎麼點擊按鈕」，而是：

某個網站的登入後頁面怎麼跳轉。
哪些彈窗會擋住主流程。
哪些 selector 穩定，哪些只是臨時樣式名。
上傳、下載、iframe、shadow DOM、跨域元件怎麼處理。
某個後台系統有哪些隱藏等待和非同步狀態。

這些知識如果只留在一次執行日誌裡，很快就會丟掉。把它們沉澱成 domain skills，才可能讓 Agent 越用越順。

適合哪些場景

browser-harness 更適合以下任務：

幫使用者操作真實網頁後台。
在沒有 API 的系統裡完成重複流程。
登入狀態依賴強的個人或企業網頁任務。
需要截圖判斷頁面狀態的複雜互動。
Agent 需要在執行中補工具、補站點經驗。
多個子 Agent 各自使用獨立瀏覽器執行任務。
研究瀏覽器 Agent 的執行環境設計。

具體例子包括：整理網頁表格、提交內部系統表單、下載帳單、上傳檔案、處理報銷流程、檢查訂單狀態、在 SaaS 控制台裡配置資源、從登入後的網頁提取資訊。

如果任務只是抓取靜態網頁，未必需要瀏覽器。專案自己的 SKILL.md 也提到，靜態頁面可以直接用 HTTP 批量取得；瀏覽器應該留給真正需要頁面狀態、登入狀態和互動的場景。

需要注意的風險

讓 AI Agent 接管真實 Chrome，很強，也很危險。

第一，權限邊界要清楚。真實 Chrome 裡可能有信箱、支付後台、雲控制台、公司系統和個人帳號。Agent 一旦能操作瀏覽器，就等於獲得了這些網頁權限的一部分。

第二，不要把憑證交給模型。遇到登入頁、支付驗證、二次確認等敏感步驟，應該讓使用者自己處理。Agent 可以等待登入完成，但不應該從截圖裡讀取或輸入密碼、驗證碼、支付資訊。

第三，自動化不等於可託管。很多網頁任務看似簡單，但中間可能出現風控、誤點擊、資料刪除、批量提交、不可逆操作。適合先從唯讀、低風險、可回復的流程開始。

第四，domain skills 需要避免洩露隱私。站點經驗可以公開，但不要把帳號、內部 URL、客戶資料、座標流水或一次性任務細節寫進去。

第五，真實瀏覽器連接方式要謹慎選擇。如果要複用日常登入狀態，使用目前 Chrome 很方便；如果要跑長時間自動化，隔離 profile 或雲瀏覽器更可控。

對 AI Agent 工具的意義

browser-harness 代表了一種很務實的 Agent 工具路線：少做平台，多給模型一個可以直接觸達真實環境的介面。

過去很多 Agent 失敗在兩端。一端是模型會推理，但摸不到真實頁面；另一端是自動化框架很強，但需要人先把流程寫死。browser-harness 試圖把這兩端接起來：瀏覽器負責真實世界的狀態，Agent 負責觀察、判斷和補工具。

這也是「自我改進 harness」的意義。它不是說 Agent 會神奇地變聰明，而是把可重用的操作經驗放到專案結構裡，讓下一次任務少走彎路。

對開發者來說，browser-harness 的價值主要在三個層面：

作為個人 Agent 的瀏覽器控制層。
作為研究瀏覽器自動化和 Agent 工作流的樣本。
作為把網頁流程變成可重用技能的實驗框架。

它不是所有瀏覽器自動化問題的答案，但它給出了一個清晰方向：當 Agent 真正要幫人做事時，工具層不只要能呼叫 API，也要能理解和操作人類每天使用的網頁介面。

簡單結論

browser-use/browser-harness 值得關注，不是因為它包裝了多少高階功能，而是因為它把瀏覽器 Agent 的幾個關鍵問題擺在了台面上：真實 Chrome、CDP、截圖驅動、可編輯 helper、站點技能沉澱，以及使用者權限邊界。

如果你只是寫穩定端到端測試，繼續用 Playwright 或 Selenium 就很好。如果你想讓 Codex、Claude Code 這類 Agent 直接幫你處理真實網頁任務，browser-harness 提供了一個更貼近 Agent 工作方式的入口。

真正使用時，建議從低風險任務開始：先讓它讀頁面、截圖、提取資訊，再逐步嘗試點擊和提交。等你確認它能穩定識別頁面狀態，再考慮讓它接管更長的流程。

參考資料：

GitHub 專案：https://github.com/browser-use/browser-harness
README：https://github.com/browser-use/browser-harness/blob/main/README.md
安裝文件：https://github.com/browser-use/browser-harness/blob/main/install.md
使用說明：https://github.com/browser-use/browser-harness/blob/main/SKILL.md

Chrome 靜默下載 4GB Gemini Nano：怎麼檢查、關閉和刪除？

Sat, 09 May 2026 21:37:18 +0800

Google Chrome 瀏覽器被曝會在未經使用者明確許可的情況下，於背景下載約 4GB 的本地 AI 模型檔案，引發關於隱私、儲存空間和環境影響的討論。

這批檔案與 Gemini Nano 有關，主要用於 Chrome 的本地 AI 功能。爭議點不在於瀏覽器支援本地 AI 本身，而在於下載過程是否足夠透明、使用者是否應該事先知情，以及系統資源是否被合理占用。

事件細節

被討論的模型檔案名為 weights.bin，位於 Chrome 的 OptGuideOnDeviceModel 目錄中。外界認為它是 Gemini Nano 的本地化版本，用於在裝置端完成部分 AI 推理。

Chrome 會根據裝置硬體能力在背景判斷是否下載，尤其會參考 RAM 和 VRAM 等條件。使用者通常不需要主動啟動下載流程，也可能不會在下載前看到清楚提示。

更麻煩的是，手動刪除模型檔案通常不能徹底阻止它回來。只要相關功能仍處於啟用狀態，Chrome 在重新啟動或後續更新後可能再次下載該模型。

目前討論中提到的影響平台包括 Windows 11、macOS 和 Ubuntu 等桌面系統。按 Chrome 桌面裝機量估算，潛在影響裝置可能達到數億台。

Google 的說法

Google 的解釋是，這些檔案用於支援本地 AI 功能，例如「幫我寫作」（Help me write）和詐騙偵測。把模型放在本地執行，可以減少部分資料上傳，從而改善隱私保護。

Google 還表示，如果裝置儲存空間不足，Chrome 會自動移除相關模型以釋放空間。也就是說，模型不一定會永久占用磁碟。

同時，Google 稱從 2024 年 2 月起，使用者已經可以在 Chrome 設定中停用相關功能。停用後，模型不會繼續下載或更新。

如何檢查和停用

如果你不希望 Chrome 在本地保留 Gemini Nano 模型，可以從以下幾處檢查。

首先，進入 Chrome 設定，查找與「裝置端 AI」、本地 AI、寫作輔助或最佳化建議相關的選項，並關閉不需要的功能。

其次，可以在網址列輸入：

`1`	`chrome://flags`

然後搜尋並停用：

`1`	`Enables optimization guide on device`

最後，再到 Chrome 使用者資料目錄中查找 OptGuideOnDeviceModel 資料夾，並刪除其中的模型檔案。需要注意的是，單獨刪除檔案通常不夠，最好先停用相關 flag 或設定，否則 Chrome 之後仍可能重新下載。

不同系統裡的可能路徑

OptGuideOnDeviceModel 通常位於 Chrome 的使用者資料目錄下。不同系統和安裝方式會有差異，可以優先從這些位置查找：

Windows：%LOCALAPPDATA%\Google\Chrome\User Data\
macOS：~/Library/Application Support/Google/Chrome/
Linux：~/.config/google-chrome/
Chromium：~/.config/chromium/

進入對應目錄後，可以搜尋 OptGuideOnDeviceModel 或 weights.bin。如果使用的是 Chrome Beta、Dev、Canary，目錄名稱可能會帶有對應版本標識。

如何判斷 weights.bin 是否已經下載

最直接的方法是在 Chrome 使用者資料目錄中搜尋：

`1`	`weights.bin`

如果已經下載，通常可以看到它位於 OptGuideOnDeviceModel 目錄內，檔案體積可能接近數 GB。也可以按檔案修改時間判斷它是否在最近由 Chrome 背景生成或更新。

如果找不到 weights.bin，不一定代表裝置永遠不會下載。Chrome 可能會根據硬體條件、地區、版本、功能開關和實驗配置決定是否拉取模型。

關閉後會影響哪些 Chrome AI 功能

關閉相關本地 AI 或最佳化功能後，可能影響依賴 Gemini Nano 的裝置端能力，例如「幫我寫作」（Help me write）、本地詐騙偵測，以及未來更多不經過雲端的瀏覽器 AI 功能。

對不使用這些功能的使用者來說，關閉後的日常瀏覽影響通常不大。對經常使用 Chrome 內建寫作輔助、頁面理解或安全偵測實驗功能的使用者來說，體驗可能會退回到雲端處理、不可用，或由瀏覽器採用其他替代方案。

爭議在哪裡

這件事的核心爭議，是瀏覽器能否在使用者沒有明確同意的情況下，為 AI 功能提前下載數 GB 的模型檔案。

支持者會認為，本地 AI 可以減少雲端處理，有助於隱私保護，也能提升回應速度。反對者則認為，使用者至少應該在下載前看到明確提示，尤其是在檔案體積接近 4GB、且可能影響儲存空間和網路流量時。

隱私專家還指出，這類未經充分告知的背景下載行為，可能觸及歐盟 ePrivacy 指令和 GDPR 的合規問題。是否構成違規，還要看 Google 的告知方式、預設設定、資料處理路徑和使用者控制選項。

小結

Chrome 引入 Gemini Nano 代表瀏覽器正在把更多 AI 能力放到本地執行，但這也帶來了新的產品邊界問題：本地模型同樣會占用磁碟、消耗頻寬，並影響使用者對裝置的控制感。

對普通使用者來說，最直接的做法是檢查 Chrome 的本地 AI 和最佳化功能設定。如果不需要這些功能，可以關閉相關選項，並在停用後刪除 OptGuideOnDeviceModel 目錄中的模型檔案。