TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Browser Use 與 Computer Use 怎麼選？先問代理需要看到什麼
Browser Use 讓代理在網頁內用元素引用與截圖座標做事，Computer Use 把範圍擴到整個桌面沙箱。兩家廠牌的官方文件都把代理操作拆成結構讀取與畫面操作兩個工具組，選擇順序從最輕的網頁搜尋擷取開始：公開資訊不必動用代理操作，任務留在網頁內用瀏覽器工具，跨桌面軟體的工作才交出沙箱。兩條分界、由輕到重的選擇階梯，與第一次委派的驗收方法一次看清。
用 AI 摘要這篇文章：
要把一件事交給 AI 代理去操作介面，第一個撞上的名詞通常就是 Browser Use 與 Computer Use。先給結論：這兩個名字來自兩份真實存在的工具清單，分界有兩條，一條是代理靠什麼資訊找到目標，另一條是你願意把多大的環境交給它。官方的選擇順序也跟多數人直覺不同，是從最輕的入口開始：不需要互動的資料用網頁搜尋與擷取就夠，要動作的任務留在網頁內就走 Browser Use，必須跨桌面軟體才動 Computer Use。
這套讀法對照的是 2026 年 11 月 5 日查詢的 Anthropic 與 OpenAI 官方開發文件，加上 Playwright MCP 與 browser-use 兩個開源專案的說明頁。兩家廠牌在各自的文件裡，都把代理操作介面這件事拆成兩個獨立的工具組，拆法彼此印證，分界因此是理解這兩個名字的主軸。
兩個名字，本來是兩份工具清單
Browser Use 與 Computer Use 常被當成兩種產品類別來比較，但它們在 Anthropic 的 API 裡是兩個明確的條目：瀏覽器工具組（browser toolset）與電腦工具組（computer toolset）。瀏覽器工具組預設給模型 27 個成員工具，例如導覽、讀頁面、點擊、截圖，另有 4 個選配成員；電腦工具組給 17 個成員工具，負責截圖、滑鼠鍵盤與縮放。兩者都是客戶端工具組，也就是模型只提出呼叫，真正執行的是你的應用程式。
OpenAI 的開發文件做了同一種切分。它的電腦工具組走截圖加上滑鼠鍵盤，瀏覽器工具組則由你的驅動程式把選定操作包裝成函式工具餵給模型，另外還有一條由 OpenAI 代管瀏覽器的 Agents API 路線。兩家把它拆成兩組，代表這個分法是做出這些工具的廠牌共同的結構判斷，其中一組靠畫面操作，另一組靠頁面結構讀取。
第一條分界：代理靠什麼資訊找到目標
模型要操作介面，先要知道目標在哪裡。Anthropic 的瀏覽器工具給模型兩種線索，而且明定優先順序。
第一種是頁面結構。瀏覽器會把網頁內容整理成無障礙樹，每個節點帶著角色、名稱與狀態，例如「搜尋按鈕」或「已勾選的選項」，這套資訊本來是給螢幕閱讀器用的，對代理來說正好是一份現成的點名單。模型讀頁面時拿到的就是這些整理過的元素引用，例如 ref_2 這種編號，每個編號對應一個真實的節點，版面怎麼重排，名字都不會變。第二種是截圖加座標。模型看一張完整視窗的畫面，用像素位置標出要點的地方，這像用第幾排第幾個座位找人，桌子一搬就對不上。官方文件明說，在頁面有可用結構樹時優先用元素引用，因為引用撐得住版面重排，也能點到滑鼠不容易點的控制項。文件連細節都想到了：模型要求放大畫面細看時，縮放後的區域與座標仍然以整個視窗為基準，執行端不需要另外換算座標系。
截圖路線何時出場？文件列出的情況包括結構樹描述不到的內容：畫布繪圖區、嵌入式影片、遠端桌面畫面、跨來源的 iframe。這些東西在結構樹裡沒有可用的節點，模型只能看畫面、用座標點擊。
電腦工具組則把畫面這條軸走到極端。Anthropic 在瀏覽器工具的文件裡寫得直接：當任務需要整個桌面，改用電腦操作工具，它只靠截圖與座標運作。整個桌面對模型而言就是一張接一張的畫面，沒有元素名稱可以引用。
結構這條軸有獨立存在的證據。微軟的 Playwright MCP 是給各種 AI 應用串接的瀏覽器自動化服務，它的說明文件開頭就寫：透過結構化的無障礙快照操作網頁，繞開截圖與視覺模型的需要，並把「不用像素輸入、不需視覺模型、工具套用結果確定」列為主要特性。同一份文件還給了一個務實的對比：寫程式用的代理改用指令列介面加技能檔更省 token，因為不用把龐大的工具定義與無障礙樹塞進上下文，而需要持續保有頁面狀態的長任務才適合走 MCP 這條路。這個專案截至 11 月 5 日有 39,179 顆星，採 Apache-2.0 授權。它不接任何模型 API 也照樣運作，代表「靠結構讀取」本身是一條完整獨立的技術路線；想在模型側直接串接各種 MCP 伺服器，另有 mcp-use 開源庫 這條捷徑。
對選擇的影響是：先看你的任務目標能不能被結構描述。表單欄位、按鈕、清單項目都有名稱與狀態，結構路線就夠；目標是畫布上的圖形或畫面裡的像素內容，那就必須走截圖路線。
第二條分界：環境邊界畫在哪裡
兩個工具組的第二個差異是活動範圍。瀏覽器工具的座標定義在視窗像素裡，文件特別註明沒有周圍的桌面或視窗框架，邊界就是瀏覽器視窗本身。電腦工具的範圍則是整個桌面環境，模型透過截圖與滑鼠鍵盤，可以在不同應用程式之間工作。
環境大小直接決定授權大小。Anthropic 對電腦操作的安全建議，放在最前面的就是使用最低權限的專用虛擬機器或容器，它的參考實作是一個 Docker 容器加上對外的埠對應。沙箱裡的規則由你安排：代理可以接觸哪些檔案、能連到哪些網站、能呼叫哪些工具，都是部署時就該畫好的線。把整個桌面交出去，代理能碰到的檔案、視窗與設定就多一個量級，所以官方才把沙箱環境列為前提而非選項。
範圍之外，還有一層「誰來準備環境」的差別。OpenAI 的指南列出三種接法：自己跑本機瀏覽器、用夥伴代管的環境（Browserbase、Browser Use、Daytona、E2B 都在列）、或直接用 OpenAI 代管的瀏覽器走 Agents API。開源專案 browser-use 也走同一條路：它是一個 Python 瀏覽器代理庫，可在本機跑任何模型，另有雲端隱匿瀏覽器每小時 0.02 美元起，截至 11 月 5 日在 GitHub 有 120,035 顆星，採 MIT 授權。Chrome 使用者還有 Nanobrowser 這類擴充功能，把網頁代理直接裝進瀏覽器；不想自己接 API 工具組的讀者，這類現成方案都是另一個入口。
模型只提案，動手的永遠是你的程式
兩家文件對執行責任的描述罕見地一致。Anthropic 說：瀏覽器工具的每個呼叫都由你的應用程式在自己的瀏覽器自動化上執行，Anthropic 那一側什麼都不跑。OpenAI 的說法是你的應用程式擁有連線、權限與清理，連失敗時的收尾都算你的。
這條契約的實際影響分兩種人。用現成產品的人，這整段通常已經被產品包好，感知不到，Cursor 的 Computer Use 把代理操作電腦收進開發工具就是一例。自己串接的開發者，則要把三件事接起來：動作執行、狀態回傳、完成判定，還要處理連線逾時與失敗後的資源釋放。OpenAI 指南甚至提醒，就算任務失敗，也要設定逾時並關閉或釋放連線，用環境的網路規則限制連線能碰到的網站。
所以兩個名字的差別，常常不由模型決定，而由誰準備執行環境決定。同一個模型，接上瀏覽器自動化就是 Browser Use，接上桌面沙箱就是 Computer Use，模型本身沒有換。
從最輕的入口開始選
把兩條分界放進選擇順序，官方指引可以整理成一張表：
| 比較項目 | 網頁搜尋與擷取 | Browser Use | Computer Use |
|---|---|---|---|
| 適用條件 | 公開資訊、不需互動 | 任務留在網頁內且要動作 | 需要整個桌面或跨應用程式 |
| 觀察方式 | 服務端直接回傳內容 | 結構樹優先，截圖座標輔助 | 截圖與座標 |
| 環境需求 | 無 | 可受控的瀏覽器 | 沙箱化的桌面環境 |
| 執行者 | API 服務端 | 你的應用程式 | 你的應用程式 |
Anthropic 在瀏覽器工具文件裡給的順序是：頁面可以用網頁擷取或搜尋解決的，用那兩個更輕的服務端工具。所謂服務端工具，是由 API 那一側直接執行、把結果放進回應裡的工具，沒有瀏覽器要操作、沒有環境要準備，成本與複雜度都最低；找資料或讀內容，常常到這一層就結束了。任務留在網頁內且要對頁面動作，或頁面內容靠 JavaScript 生成，才用瀏覽器工具；需要整個桌面，才用電腦操作工具。電腦工具的文件寫出鏡像句：任務留在網頁內時，瀏覽器工具是更貼近的選擇，它不需要完整的桌面環境。
一個任務也不見得只用一個入口。先在網頁上抓檔案，交給沙箱裡的程式整理，再回到網頁檢查結果，這種分段流程兩個文件都支援，重點是每一段都要有自己的可核對產物，出錯時才找得到是哪一段壞了。
第一次委派，把驗收條件寫進交辦
兩種工具共享同一個風險來源：代理讀到的內容可能藏著別人的指令。Anthropic 在安全考量裡明說，某些情況下模型會跟著網頁或圖片裡找到的指令走，即使那些指令與你的交辦衝突。防線有兩層，模型經過抵抗注入的訓練，另外有分類器自動掃描工具回傳的內容（包括截圖），發現潛在注入時會引導模型先回頭確認指令是不是真的來自你。需要登入的網站風險更高，官方提醒別把帳號密碼直接放在交辦文字裡，真的要提供也要隔開標記，官方另建議為這類任務準備專用的低權限帳號。
第一次交辦，與其問哪個工具好，先把驗收條件寫清楚。用結構路線時，元素引用讓「點了什麼」有名有姓：要求代理回報它操作的是哪個元素，比回報一組座標數字容易核對。第一個任務選範圍最小的，例如只開一個指定網址、讀出標題與主要文字、附畫面然後停止，自己打開網址核對內容對不對。之後一次加一種互動，每次先約定操作後應該出現什麼，結果與預期不同時，保留網址、畫面與操作紀錄再查問題，直接反覆重試只會讓狀態更難理解。
跨應用程式的任務，驗收要跟著分段走。網頁端先確認檔案下載完成，桌面端確認軟體讀到的是正確版本，產出端確認成果檔案重新開啟後內容無誤。每一段都有自己的輸入與輸出，壞在哪一段才查得出來，這也是官方文件把「每個環節的結果」當成流程設計重點的原因。
交辦單本身也要畫邊界：可用網站、可修改範圍、停止條件寫明，涉及送出資料這類會改變狀態的動作，更要限定在已授權的範圍內。
官方文件沒有回答的三件事
把文件讀完，有三個問題它們不回答，選型時要自己補。
沒有跨工具的成功率比較。文件描述能力存在，不保證效果，任何「哪個比較可靠」的數字都必須來自你自己任務上的實測。也沒有每任務成本數字。兩家都按 token 與圖片計費，操作回合越多、回傳畫面越多就越貴，把範圍切小不只是安全考量，也是成本考量，但實際數字要用自己的任務量出來。供應狀態則會變動。Anthropic 兩個工具組目前都不在代管代理（Managed Agents）裡提供，工具組版號帶著日期（例如 browser_toolset_20260801），本身就是成員與行為會持續修訂的訊號，工具組的數字與成員清單以 2026 年 11 月 5 日查詢為準，之後選型前值得回來重查一次。
回到最初的問題。Browser Use 與 Computer Use 的選擇，可以化成兩個更具體的問題：這個任務的目標能不能用結構描述，以及它需要碰到多大的環境。下一件要交辦的工作，先照這兩問拆開，再對照從輕到重的階梯選入口，第一次用最小任務驗收，是比記住任何工具名稱更可靠的判斷方式。
