不再只是聊天：Browser-use 讓 AI 真正長出了「雙手」，實測與深度解析

當你問 ChatGPT「幫我查一下這週五飛往東京最便宜的機票，然後直接幫我下單」時，通常會得到這樣的回答：「抱歉，我無法直接瀏覽即時網頁或進行交易…」

這是目前 LLM（大型語言模型）的主要限制——它們被困在對話框裡，有大腦，卻沒有手。Browser-use 這個開源項目的出現，正是為了打破這道牆。它不是簡單的爬蟲工具，而是一個讓 AI Agent 能夠像人類一樣操作瀏覽器的橋樑。

本文將深入分析這個庫的實際功能、部署流程，以及在真實生產環境中的表現。

核心概念：當 LLM 遇上 Playwright

在 Browser-use 出現之前，如果你想用 AI 自動化網頁操作，通常需要寫大量的 Selenium 或 Puppeteer 腳本，去定位 DOM 元素（比如 div.class-name > button）。一旦網站改版，腳本就掛了。

Browser-use 的邏輯完全不同。它結合了 LangChain（大腦）和 Playwright（手腳），並引入了 視覺能力（Vision）。

它的工作流程是這樣的：

1. 觀察（Observe）：Agent 獲取當前頁面的截圖和簡化的 DOM 結構。
2. 思考（Think）：將截圖傳給 GPT-4o 或 Claude 3.5 Sonnet，問它：「為了完成用戶的任務（比如買機票），下一步該點哪裡？」
3. 行動（Act）：LLM 返回指令（例如「點擊坐標 (200, 300) 的按鈕」或「在輸入框輸入 ‘Tokyo’」）。
4. 執行（Execute）：Playwright 執行操作，然後重複第一步。

這意味著，它對網頁結構的變化具有極強的魯棒性（Robustness）。就算按鈕的 ID 變了，只要它長得像個「購買按鈕」，AI 就能認出來。

---

實戰部署：從零開始

別被「AI Agent」這個詞嚇到，Browser-use 的封裝做得非常好，上手難度極低。但有幾個環境坑點需要注意。

1. 環境準備（避坑指南）

關鍵要求：Python 版本必須 >= 3.11。這是硬性規定，因為它依賴了一些新的異步特性。

建議使用 uv 來管理依賴（官方也推薦），它比 pip 快得多，也能避免依賴衝突。

# 如果你還沒安裝 uv
pip install uv

# 創建並初始化虛擬環境
uv init
uv venv

# 安裝 browser-use
uv add browser-use

# 關鍵步驟：安裝 Playwright 的瀏覽器內核
# 很多人報錯都是因為漏了這一步
uv run playwright install

2. 配置你的「大腦」

你需要一個強大的 LLM。雖然它支持本地模型（如 Ollama），但建議使用 GPT-4o 或 Claude 3.5 Sonnet。因為網頁分析需要極高的視覺理解能力，弱模型會導致 Agent 重複執行相同操作。

在項目根目錄創建 .env 文件：

OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxx
# 如果你想用 Anthropic
# ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxx

3. Hello World：讓 AI 幫你逛 GitHub

我們來寫一個簡單的腳本，讓 AI 去 Browser-use 的 GitHub 頁面看看有多少顆星。

import asyncio
import os
from dotenv import load_dotenv
from langchain_openai import ChatOpenAI
from browser_use import Agent

# 加載環境變量
load_dotenv()

async def main():
    # 1. 初始化大腦
    # 建議開啟 vision (雖然更貴，但準確率高很多)
    llm = ChatOpenAI(model="gpt-4o")

    # 2. 定義 Agent
    agent = Agent(
        task="去 https://github.com/browser-use/browser-use 看看現在有多少顆 stars，並告訴我這個庫的主要用途是什麼。",
        llm=llm,
    )

    # 3. 執行並獲取結果
    # 這裡會自動彈出一個瀏覽器窗口，可以看到 AI 在操作
    result = await agent.run()

    print("\n最終結果：")
    print(result)

if __name__ == "__main__":
    asyncio.run(main())

運行後你會看到： 一個 Chromium 瀏覽器自動彈出，跳轉到 GitHub，頁面滾動，然後控制台輸出 Stars 數量和項目簡介。這一切都不需要你寫一行 page.click() 代碼。

---

進階玩法：不只是看，還能做

Browser-use 的強大之處在於交互。我們可以讓它執行更複雜的任務，比如填寫表單、登錄網站，甚至處理驗證碼（雖然成功率取決於模型）。

1. 保持登錄狀態（Cookie 持久化）

默認情況下，每次運行都是一個全新的無痕瀏覽器。如果你要操作需要登錄的網站（如 Gmail、Twitter），你需要持久化 Browser Context。

from browser_use import Agent, Browser, BrowserConfig
from langchain_openai import ChatOpenAI
import asyncio

async def persistent_session():
    llm = ChatOpenAI(model="gpt-4o")
    
    # 配置瀏覽器，指定 chrome_instance_path 可以復用本地 Chrome (需先關閉所有 Chrome 窗口)
    # 或者更簡單的方式：使用 user_data_dir
    browser = Browser(
        config=BrowserConfig(
            headless=False, # 設為 False 可以看到操作過程
            # 這裡指定一個本地路徑來存儲 Cookies 和緩存
            # 注意：不同操作系統路徑不同，這裡是 macOS 示例
            chrome_instance_path='/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        )
    )

    agent = Agent(
        task="去我的 Amazon 訂單頁面，看看最近一筆訂單是什麼。",
        llm=llm,
        browser=browser,
    )

    await agent.run()
    await browser.close()

2. CLI 命令行神器

如果你懶得寫 Python 腳本，Browser-use 提供了一個非常好用的 CLI 工具，適合快速測試。

# 直接在終端機指揮瀏覽器
uvx browser-use open https://www.google.com

# 讓它執行動作
# 系統會列出可交互元素的編號，你只需要輸入編號或指令
> Type "Weather in Taipei"
> Click 3

這對於調試「AI 到底看到了什麼」非常有用。你可以輸入 state 查看當前頁面的解析狀態。

---

批判性分析：炒作還是革命？

Browser-use 在 GitHub 上星數暴漲（77k+ stars）。在決定將它用於生產環境之前，需要冷靜地看看它的優缺點。

優點

1. 極低的維護成本：這是最大的賣點。網頁改版後，只要人類還能看懂，AI 就能看懂。不再需要為了維護 CSS Selector 而煩惱。
2. 多模態融合：它利用了 GPT-4o 的視覺能力，能理解圖表、佈局，甚至能繞過一些簡單的視覺驗證碼。
3. 通用性：同一個 Agent 代碼，可以稍作修改就應用於完全不同的網站。

缺點與挑戰

1. 成本高昂：每一步操作（滾動、點擊、輸入）通常都伴隨著一次截圖上傳和 LLM 調用。一個複雜的任務可能需要 20-30 個步驟。如果使用 GPT-4o，單次任務的成本可能高達 0.5 - 2 美元。這比傳統爬蟲貴了幾個數量級。

2. 速度慢：傳統爬蟲是毫秒級的。Browser-use 的流程是：截圖 -> 上傳 -> LLM 思考 -> 下發指令。每一步可能有 2-5 秒的延遲。這不適合高頻交易或搶票。

3. 幻覺風險：AI 偶爾會出現錯誤。它可能會點擊廣告，或者在填寫表單時編造數據。雖然可以通過 System Prompt 進行約束，但無法 100% 避免。

4. 反爬蟲機制：雖然它模擬了人類操作，但底層依然是 Playwright。像 Cloudflare 這樣的高級防護依然能檢測到它是自動化工具（除非配合指紋瀏覽器或雲端隱身服務）。

---

對比：Browser-use vs 傳統自動化

特性	傳統爬蟲 (Selenium/Scrapy)	Browser-use (AI Agent)
開發速度	慢（需分析 DOM、抓包）	極快（自然語言描述任務）
維護成本	高（網頁改版即失效）	低（自適應 UI 變化）
運行成本	極低（僅消耗算力/帶寬）	高（Token 費用昂貴）
運行速度	快	慢（受限於 LLM 推理速度）
適用場景	大規模數據採集、固定流程	複雜交互、非結構化任務、探索性測試

---

總結與建議

Browser-use 是一個里程碑式的工具。它標誌著我們從「編寫腳本」向「編排意圖」的轉變。

適用場景：

• 需要自動化複雜流程（如跨網站訂票、填寫複雜的政府表單）
• 目標網站沒有 API，且 DOM 結構經常變動
• 任務頻率低，但價值高（成本不是首要考量）
• 快速原型開發（MVP）

不適用場景：

• 需要抓取百萬級別的數據（建議用 Scrapy）
• 需要毫秒級的響應速度
• 預算非常有限

未來方向： 隨著本地多模態模型（如 LLaVA、Qwen-VL）的進步，未來可能在本地運行 Browser-use，從而大幅降低成本並提高隱私性。

---

參考資料 / References:

• Browser-use GitHub Repository
• Browser-use Official Documentation
• LangChain Documentation