2026 年，AI agent 最尷尬的場景長這樣：

一個號稱能「自動化一切」的 agent，被要求「登入公司 dashboard、下載這週報表」，回了一句——

「無法操作瀏覽器，但可以提供操作步驟。」

這就像請了一個什麼都懂的顧問，但他的手被綁起來了。Browser Use CLI 2.0 在做的事，不是讓 AI 更聰明——是終於把繩子解開。

Clawd 真心話：

AI 工具圈每週都有人宣布「速度快兩倍、成本砍半」，聽到都免疫了，跟早餐店阿姨說「等一下喔馬上好」一樣可信度。但 Browser Use 這次的 claim 有個技術原因撐著，不是純在喊口號。等一下講 CDP 的時候會解釋為什麼——先不要翻白眼 (⌐■_■)

最危險也最實用的功能：連進正在跑的 Chrome

先不講技術原理，先講讓人又愛又怕的東西。

CLI 2.0 之前，browser agent 的標準做法是自己啟動一個全新的 headless Chrome——乾淨無比，什麼 cookie 都沒有，什麼登入狀態都不存在。Agent 要存取 Gmail？先重新驗證身份。碰到 2FA 的網站？直接卡死。這不是 edge case，是每天都在發生的事。

CLI 2.0 改了遊戲規則：agent 可以直接連進已經在跑的 Chrome。

開發者平常用的那個 Chrome，已經登入的 Notion、已經開好的 Google Sheet、已經在跑的 SaaS dashboard——agent 全部看得到、全部碰得到。從「理論上能用」直接跳到「真的能做事」。

# 用 CDP debug port 啟動 Chrome
google-chrome --remote-debugging-port=9222

# Browser Use CLI 連進去
browser-use --attach-to 9222 "把這個試算表的資料整理成報告"
Clawd 想補充：

講白了，attach to running Chrome = 把所有已登入帳號的鑰匙交給一個 AI agent。這不是比喻，是字面意思。Notion、Gmail、公司內部系統、網路銀行——只要那個 Chrome session 登入過的，agent 全部碰得到。

所以在生產環境跑之前，拜託先想清楚兩件事：(1) 這個 agent 的 scope 設到哪裡，(2) 一個 prompt injection 進來的時候損失上限是多少。不是在嚇人——是這個功能的 blast radius 大到值得認真對待。有些方便是用風險換來的，這個 trade-off 得自己做 (╯°□°)⁠╯

快的代價：繞過 Playwright 直接講瀏覽器母語

好，回來講「速度快兩倍」背後的技術。

Playwright 和 Puppeteer 是目前最主流的瀏覽器自動化工具，API 友善，文件齊全，生態系成熟。但本質上，這兩個工具都是在 CDP（Chrome DevTools Protocol）之上再包一層抽象。

CDP 是什麼？就是按 F12 打開開發者工具時，那個面板背後用的底層協議。Chrome 官方暴露的原生通道，用 WebSocket 直接跟瀏覽器對話：「截圖」「執行這段 JS」「點座標 (320, 480) 的元素」。

Playwright 的路徑：程式碼 → Playwright API → CDP → Chrome。

Browser Use CLI 2.0 的路徑：agent → CDP → Chrome。

少一層轉譯，少一層記憶體開銷。速度快在這裡，成本省在這裡。

但快不是免費的。

Clawd murmur：

這邊要講一個很多人不提的 trade-off：Playwright 那層「多餘的抽象」其實幫開發者擋掉了一堆底層的髒東西——瀏覽器版本差異、race condition、element 定位的邊界條件。拿掉 Playwright 直接打 CDP，等於自己要面對這些妖魔鬼怪。

對 AI agent 來說這可能還好，反正 LLM 本來就是靠截圖 + DOM 在判斷下一步，不需要 Playwright 那層保護。但對想拿 Browser Use 做正經 E2E 測試的人？三思。Playwright 的抽象層確實多繞了一步，但那是保險費，不是浪費 ┐(￣ヘ￣)┌

「成本砍半」還有另一個功臣：DOM 解析策略的翻新。早期 browser agent 的標準做法是把整個頁面截圖，丟給視覺模型問「該點哪裡」——一張 1080p 截圖燒掉幾千 token，agent 點 20 次完成一個任務，帳單直接起飛。CLI 2.0 優先用精簡的 DOM 結構描述頁面，截圖變成 fallback 而不是預設。Token 用量斷崖式下降。

沒有人在搶的位置

拉遠一點看 2026 年的 AI agent 生態系，會發現一個奇怪的失衡。

做「大腦」的工具多到爆——GPT-4o、Claude、Gemini、各種開源 model，每週都有新選手進場。做「記憶」的也不少——向量資料庫、context window 技術、RAG pipeline。做「工具呼叫」的更是蓬勃——MCP、function calling、tool use。

但有一塊地方，長期被所有人忽略：真實世界的 UI 操作。

全世界大部分的資料和功能，不是透過 API 暴露的。那些東西藏在需要登入的網頁後面、藏在只有 GUI 的企業軟體裡、藏在二十年前寫的 legacy 系統的 dropdown 選單下面。如果 agent 不會操作瀏覽器，它的能力邊界就停在「API 友善的世界」——而那個世界，大概只佔真實工作場景的三成。

Browser Use 在搶的，就是這個沒人搶的位置。那種每週要手動登入、點三層選單、下載 CSV 的 dashboard？自動化。從 A 系統抓資料填進 B 系統、不用等 A 開 API？自動化。這些不是假想情境，是每個公司每天都在用人力燒的流程。

Clawd 吐槽時間：

Browser Use、Playwright MCP、Stagehand——2026 年搶「AI 的手腳」這個位置的選手屈指可數。誰最終贏？不會是技術最酷的那個，會是 reliability 最高的那個。

原因很殘酷：瀏覽器操作的 failure mode 不像 API call 那樣優雅。API 失敗回一個 4xx，retry 就好。Browser agent 卡在一個意料之外的 CAPTCHA、一個動態載入的 modal、一個「請更新瀏覽器」彈窗——整條 pipeline 就死在那裡，而且死狀很難看。誰先把這種「死在奇怪地方」的機率壓到最低，誰就贏。不是比酷，是比穩 (◕‿◕)

結語

Browser Use 是開源的（GitHub 60k+ stars），這個數字本身說明「讓 AI 操作瀏覽器」的需求有多真實——不是學術 demo，是真的有人在生產環境跑。

但技術問題解決了，信任問題還沒有。

當一個 AI agent 拿到了完整的瀏覽器控制權、看得到所有已登入的帳號、能代替使用者執行任何操作——「它應該被允許做到哪裡」這個問題，目前沒有標準答案。Browser Use 讓 agent 終於有了手，但什麼時候該把手收回來，還是得靠人自己決定。

Clawd 畫重點：

60k stars 的開源專案，做的事情是「讓 AI 完整操控瀏覽器」。仔細想想這件事有多瘋狂——三年前這種東西會被當 security nightmare 秒殺，現在大家搶著用。不是因為風險消失了，是因為「讓 AI 幫忙做事」的誘惑實在太大，大到人們願意先上車再繫安全帶。

這個工具值得認真看，也值得認真怕 (๑•̀ㅂ•́)و✧

延伸閱讀