如果你在做 AI agent，你遲早會撞上同一面牆：

AI 很會想，但不會動。

它可以規劃任務、分析資料、寫程式，但一旦需要「打開瀏覽器、登入網站、點那個按鈕、把資料填進表單」，它就開始找藉口。

Browser Use 的存在，就是為了把這面牆打掉。

Browser Use 是什麼

Browser Use 是一個讓 AI agent 直接操控瀏覽器的 Python 框架。你把 LLM 當作大腦，把 Browser Use 當作手，然後對 agent 說「幫我去訂機票」或「幫我抓這個 dashboard 的數字」，它就真的去做了。

這不是模擬，不是假的截圖，是真的跑瀏覽器、真的點按鈕、真的輸入文字。

CLI 2.0 是它的命令列版本，主打三件事：

  1. 速度快兩倍
  2. 成本砍半
  3. 可以連進你正在跑的 Chrome（via CDP）
Clawd Clawd 內心戲：

「速度快兩倍、成本砍半」這種說法在 AI 工具圈已經是標配廣告詞，大概跟「突破性進展」一樣常見。但這次有個技術原因撐著，不是純粹在講廢話。關鍵在 CDP，後面會解釋 (⌐■_■)

為什麼是 CDP，不是 Playwright？

要理解 CLI 2.0 為什麼快，要先搞清楚底層在發生什麼。

Playwright 和 Puppeteer 是目前最主流的瀏覽器自動化工具。它們都很好用，API 設計也很人性化。但本質上，它們是在 CDP（Chrome DevTools Protocol）之上 再包一層抽象。

CDP 是 Chrome 官方暴露的底層協議，原本是給開發者工具（DevTools）用的 — 就是你按 F12 打開的那個東西。它讓你直接用 WebSocket 跟瀏覽器說話：「截一張圖」「執行這段 JS」「點座標 (320, 480) 的元素」。

Playwright 的做法是：你的程式碼 → Playwright API → CDP → Chrome。

Browser Use CLI 2.0 的做法是：你的 agent → CDP → Chrome。

少了一層，所以快。少了一層的記憶體開銷，所以便宜。

Clawd Clawd 補個刀：

比喻一下：Playwright 像是請翻譯把你的需求轉成瀏覽器能懂的話，CDP 是你自己直接講瀏覽器母語。翻譯是很棒的工具，但有時候繞過翻譯就是比較快。不過代價是你的程式碼要多懂一些底層細節，Playwright 幫你擋掉的複雜度，現在要自己面對了 ┐(￣ヘ￣)┌

連進正在跑的 Chrome — 這個功能很關鍵

CLI 2.0 最讓我眼睛一亮的功能，是 attach to running Chrome。

之前的做法是：agent 自己啟動一個全新的 headless 瀏覽器，在那個乾淨的環境裡操作。問題是，你的 cookie、你的登入狀態、你的工作 profile — 全部都不在那裡。每次 agent 要登入 Gmail 之前，都得先重新驗證身份，有些網站連 2FA 都要過。

現在的做法是：打開你平常用的 Chrome，讓 agent 直接連進來。它看到的是你已經登入的 Notion、你已經開好的 Google Sheet、你已經在跑的那個 SaaS dashboard。

這個改變聽起來很小，但對實際使用場景是天差地遠。

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

# 然後用 Browser Use CLI 連進去
browser-use --attach-to 9222 "幫我把這個試算表的資料整理成報告"
Clawd Clawd murmur：

這個功能讓我想起一個很有趣的問題：當 AI agent 可以完整操控你的登入狀態的瀏覽器，「信任邊界」在哪裡？你等於是給了 agent 一把萬能鑰匙，可以存取你所有已登入的帳號。這不是要嚇你，只是提醒：在你的 prod 環境跑 agent 之前，想清楚你的信任邊界在哪裡，設好 scope，不然一個 prompt injection 就能讓 agent 幫你做很多你沒要求它做的事 (╯°□°)⁠╯

AI Agent 生態系的「手腳問題」

Browser Use 在解決的，是 AI agent 生態系一個根本性的問題。

現在的 AI agent 生態大概是這個形狀：

  • 大腦：LLM（GPT-4o、Claude、Gemini 之類）
  • 記憶：向量資料庫、context window
  • 工具：API calls、code execution
  • 感知：MCP、function calling

但有一塊長期被忽略：真實世界的 UI 操作。

大部分世界的資料和功能，不是透過 API 暴露的。它們藏在需要登入的網頁後面、藏在只有 GUI 的企業軟體裡、藏在沒有文件的 legacy 系統的按鈕下面。

如果 agent 沒辦法操作瀏覽器，它的能力邊界就停在「API 友善的世界」。Browser Use 把這個邊界往外推了很多。

Clawd Clawd 畫重點：

2026 年的 AI agent 生態系，做大腦的工具多到爆，做手腳的工具相對稀缺。Browser Use、Playwright MCP、Stagehand 這些都在搶這個位置。誰最終贏，可能不是看誰技術最強，而是看誰的 reliability 最好 — 因為瀏覽器操作的 failure mode 很難看，agent 卡在「我看到了一個 CAPTCHA」那一刻，整條 pipeline 就死了 (◕‿◕)

實際跑起來是什麼樣子

Browser Use CLI 的基本使用很直白：

# 安裝
pip install browser-use

# 基本用法
browser-use "去 HN 首頁，把前十名的標題和連結抓下來"

# 連到已有的 Chrome session
browser-use --attach --task "在目前開著的 Google Sheet 裡新增一行，填入今天的日期和數字 42"

它內部的運作方式：agent 觀察目前頁面（截圖 + DOM），決定下一步動作，執行，再觀察，一直循環到任務完成或放棄。

2x 速度的另一個來源，是 更激進的 DOM 解析策略：比起把整個頁面截圖傳給視覺模型，CLI 2.0 優先用精簡的 DOM 結構來描述頁面，只在必要時才截圖。這讓 token 用量大幅下降。

Clawd Clawd 溫馨提示：

「截圖傳給 LLM 讓它告訴我要點哪裡」是早期 browser agent 的標配做法，也是最浪費 token 的做法。一張 1080p 截圖可以燒掉幾千 token，如果 agent 要點 20 次才能完成一個任務，成本會嚇到你。DOM 解析雖然有時候會漏掉純 CSS 渲染的元素，但對多數任務來說夠用，而且便宜超多。這就是「成本砍半」的數學 ٩(◕‿◕｡)۶

現在可以用來做什麼

有幾個用例我覺得直接實用：

自動化報表抓取：那種每週要手動登入、點幾層選單、下載 CSV 的 dashboard，全部自動化。

跨平台資料同步：從 A 系統抓資料、填進 B 系統，不用等 A 開 API。

E2E 測試的替代方案：不是說要取代 Playwright 測試，但對於快速驗證「用戶能不能完成這個流程」，讓 agent 跑一遍是個很低摩擦的方式。

Agent-driven browsing：你的 AI 助理真的可以幫你查資料、填表單、訂東西，而不只是告訴你「你可以去這個網址查」。

延伸閱讀

Clawd Clawd 內心戲：

最後說一件事：Browser Use 是開源的，在 GitHub 上有超過 60k stars，這個數字本身就說明了「讓 AI 操作瀏覽器」這個需求有多剛。它不是炫技，是真的有很多人在用、在貢獻、在生產環境跑。如果你在做 AI agent 相關的東西，這個工具值得認真看一眼。(๑•̀ㅂ•́)و✧