Browser-Use 與 Computer-Use AI 代理人專用代理（2026 指南）

2026 是 AI 代理人不再只是展示品的一年。browser-use、OpenAI 的 Operator 式代理人、Anthropic 的 computer use，以及十幾個建構在 Playwright 上的框架，如今都在操控真正的瀏覽器去存取真實網站——訂位、購買、研究、監控。而它們全都撞上同一道牆：它們所操作的網站把它們當成機器人，因為它們就是機器人。

本指南專門探討驅動瀏覽器的 AI 代理人的代理層。如果你的代理人使用的是 HTTP 函式庫而非瀏覽器（LangChain 工具、CrewAI 內部的爬蟲），請參閱 AI 代理人專用代理：LangChain、AutoGPT & CrewAI——這篇文章談的是控制完整瀏覽器的代理人。

為何瀏覽器代理人比爬蟲更快被封鎖

違反直覺卻是事實：驅動真正 Chrome 瀏覽器的 LLM 代理人，往往比單純的 Python 爬蟲更快被封鎖。原因有三：

1. 機房 IP ＋ 完美瀏覽器 ＝ 矛盾。瀏覽器指紋說的是「真實硬體上的真實 Chrome」，但 IP 屬於 AWS 或 GCP——大多數代理人都跑在那裡。反機器人廠商對 IP 的 ASN 給予很高權重；機房 ASN 上掛著住宅級指紋，是教科書等級的自動化特徵。
2. 代理人像機器一樣重試。當某個動作失敗，LLM 迴圈會立刻從同一個 IP、用幾乎相同的時序重試。三次快速且相同的重試，是行為偵測的入門教材。
3. CDP 留下痕跡。大多數代理人框架透過 Chrome DevTools Protocol 驅動瀏覽器。網站會探測 navigator.webdriver、CDP 特有的時序痕跡，以及無頭跡象。再加上被標記的 IP，分數會瞬間越過封鎖門檻。

這三者中 IP 是最便宜修好的，而且光修好它就能解決大多數封鎖：把代理人的流量路由經過住宅代理，讓 IP 的故事與瀏覽器的故事相符。

設定：browser-use 搭配住宅代理

browser-use 建構在 Playwright 之上，因此原生支援代理。模式是：每個代理人任務用一個黏性工作階段，讓 IP 在代理人工作期間保持穩定，而下一個任務則換用新 IP。

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

task_id = uuid.uuid4().hex[:8]

browser = Browser(config=BrowserConfig(
    proxy={
        "server": "http://us.jibaoproxy.com:913",
        "username": f"USERNAME-session-{task_id}",   # sticky: same IP for this task
        "password": "PASSWORD",
    },
))

agent = Agent(
    task="Find the current price of the Sony WH-1000XM6 on the three largest US retailers.",
    llm=ChatOpenAI(model="gpt-4o"),
    browser=browser,
)
result = await agent.run()

關鍵細節：session-{task_id} 後綴。少了它，輪換閘道可能在任務進行到一半時把新 IP 交給代理人——購物車內容消失、登入掉線，代理人浪費 LLM 呼叫去重做步驟。有了它，任務從頭到尾都跑在同一個 IP 上，下一個任務則拿到乾淨的 IP。

設定：原生 Playwright／Computer-Use 迴圈

如果你在 Playwright 上自建了代理人迴圈（這是大多數 Operator 式與 computer-use 實作背後的模式），代理要設在瀏覽器 context 上：

from playwright.async_api import async_playwright

async with async_playwright() as p:
    browser = await p.chromium.launch(headless=False)
    context = await browser.new_context(
        proxy={
            "server": "http://us.jibaoproxy.com:913",
            "username": "USERNAME-session-agent42",
            "password": "PASSWORD",
        },
        viewport={"width": 1366, "height": 768},
        locale="en-US",
        timezone_id="America/Chicago",   # match the proxy country
    )
    page = await context.new_page()
    # ... agent loop: screenshot -> LLM -> action -> repeat

把 locale 和 timezone_id 設成與代理所在國家相符。一個從美國 IP 瀏覽、時鐘卻是 UTC+8 的代理人，這種不一致會讓行為系統把分數算到你頭上。

每個 context 各自的代理也讓你能做到一個瀏覽器、多個代理人：每個 new_context() 都能帶自己的工作階段後綴，於是十個並行的代理人任務跑在十個不同的住宅 IP 上，而不需要十個 Chrome 行程。

代理人工作負載的工作階段策略

代理人工作負載	工作階段策略	原因
研究／查價（免登入）	黏性 10 分鐘，每個任務換新工作階段	任務內穩定，跨任務換新 IP
已登入帳號操作	黏性 30 分鐘，每次執行用相同工作階段 ID	網站會標記在登入之間跨國跳動的帳號
結帳／訂位流程	黏性 30 分鐘	結帳途中換 IP 會中斷工作階段並觸發詐欺審查
大量監控（數百頁）	輪換，不固定工作階段	最大化 IP 多樣性，無狀態需保留

成本控管：代理人很吃流量

住宅流量按 GB 計費，而瀏覽器代理人會拉取完整頁面——圖片、字型、追蹤器——不像 HTTP 爬蟲。若不加管理，單一代理人任務可能吃掉 20–50 MB。三個修法，依影響力排序：

1. 封鎖 LLM 不需要的重資源：

   await context.route("**/*.{png,jpg,jpeg,webp,gif,woff,woff2,mp4}",
                       lambda route: route.abort())

   如果你的代理人讀取截圖，就保留目標頁面上的圖片，但仍封鎖影片和字型。如果它讀取 DOM／無障礙樹，連圖片也一起封鎖——能把流量削減 60–80%。
2. 只路由需要路由的東西。LLM API 呼叫（OpenAI／Anthropic）絕對不能經過住宅代理——那是純粹浪費的 GB 加上額外延遲。代理瀏覽器 context，而非主機行程。
3. 在框架層級限制重試次數。最多兩次重試，搭配退避，並在第二次換新工作階段 ID——新 IP 能修好的封鎖，比第三次相同嘗試還多。

有了圖片封鎖與範圍化路由，典型的瀏覽器代理人任務會落在 2–8 MB 區間——以 $2/GB 計算，就是每一百個任務幾美分。

代理修不了的東西

誠實環節。住宅 IP 修好的是 ASN 矛盾與 IP 信譽，那是 2026 反機器人評分中單一最重的訊號。它修不了：

• CDP／無頭偵測——使用你框架的隱身選項（browser-use 內建已修補的啟動旗標；原生 Playwright 可看 rebrowser 式的修補），高價值流程則優先用有頭模式。
• TLS 指紋——對真實瀏覽器代理人不是問題（瀏覽器的 TLS 是真的），但這正是你之後無法用 requests「直接重播」代理人請求的原因。參見 JA3/JA4 詳解。
• 動作流上的行為評分——在動作之間加入小幅隨機延遲，並避免跨次執行出現像素級相同的點擊座標。

在住宅 IP 上把這三層全疊起來，瀏覽器代理人就能通過與真實使用者相同的檢查。對於最難的目標（DataDome、PerimeterX），請參見 我們的 DataDome/PerimeterX 指南。

總結

• 機房 IP 上的代理人等於自報身分；住宅 IP 讓 IP 的故事與瀏覽器的故事相符。
• 每個代理人任務一個黏性工作階段；已登入帳號永遠用同一個工作階段 ID；無狀態監控則用輪換。
• 讓 timezone_id／locale 與代理所在國家相符。
• 封鎖圖片／字型／影片，且絕不讓 LLM API 呼叫走住宅頻寬。
• 重試時換新工作階段 ID，而非用同一個 IP。