Browser Harness — 用不到 600 行 Python 讓 AI Agent 接管你開著的 Chrome

讓 AI 操控瀏覽器這件事，過去一年的解法方向全錯了。

大家都在往「更完整」走：更多 action、更聰明的 retry、更嚴謹的 session manager、更漂亮的 tool schema。框架疊得越來越厚，號稱替你把每一種狀況都想好了。結果是，agent 能做的事，被它能呼叫的那幾個 action 框死；遇到框架沒設計過的網站怪癖，它就卡在那，因為它沒有權限自己長出新工具。

browser-use 團隊在 2026 年 4 月丟出來的 browser-harness，走的是完全相反的路。整個專案不到 600 行 Python，沒有 retry、沒有 session manager、沒有 action DSL。它只做一件事：把一條通往你 Chrome 的 CDP WebSocket 交到 agent 手上，剩下的——你想點哪、想抓什麼、遇到問題怎麼繞——agent 自己寫 Python 解決。

把廚房鑰匙交出去

傳統 agent framework 像飯店的自助餐。廚師在後場把流程都準備好了：action registry、prompt template、tool schema、retry policy 全給你打點妥當。你走到取餐檯，夾架上有的菜。問題是，架上沒有的，你夾不到。

browser-harness 反過來，它把廚房鑰匙交給你。想吃什麼自己進去做。

這個比喻聽起來像在偷懶——把麻煩丟回給使用者，不就是設計失職嗎？但這正是反直覺的地方。當「使用者」其實是一個會寫程式的 LLM，把鑰匙交出去不是失職，是解放。LLM 最強的能力本來就是當場生出一段程式碼解決眼前的問題，而厚重的框架做的事，恰好是把這個能力鎖起來、只准你按那幾顆它預設好的按鈕。

這背後是一篇叫「Bitter Lesson: agent frameworks」的部落格在撐腰。論點很硬：過去一年 agent framework 疊了太多層抽象，每一層都在好心地「幫」LLM 做決定，加總起來反而把 LLM 的自由度綁死。他們的解法只有一句話——去掉抽象，只留下一條通往 Chrome 的 websocket。

工具箱會自己長大

最能說明這個哲學的，是一個叫 self-healing 的設計。

所有瀏覽器操作的基礎函式都放在一個叫 helpers.py 的檔案裡，整份才 195 行。agent 在做事的過程中，如果發現少了某個函式——比方說它想批次下載一堆 PDF，但現成的 helper 沒有這招——它可以直接編輯 helpers.py，自己加一個新函式進去。下一次 browser-harness 被呼叫，新版本就載入了。

停下來想想這意味著什麼。一般的程式庫是死的，寫好就定型，你只能用裡面有的東西。這裡的程式庫是活的，agent 邊做邊往裡面塞工具，它的能力會隨著用得越久而長出越多。195 行的長度也是刻意的——短到 agent 能一口氣讀完、完全搞懂結構，知道該往哪裡加、不會改壞。它把「函式庫」變成了 agent 可以邊跑邊擴充的記憶。

這就是「簡潔」真正的力量。不是程式碼少看起來比較清爽，而是因為它夠短、夠透明，連 AI 都能讀懂並且安全地改它。複雜的東西，連人都不敢動，更別說讓 agent 自己改了。

它解掉的，是 selector 這個老問題

技術上有一個細節值得單獨拎出來講，因為它解掉的是寫過爬蟲的人都恨過的東西：座標點擊。

click(500, 300) 背後呼叫的是 CDP 的 Input.dispatchMouseEvent，這個滑鼠事件發生在瀏覽器的 compositor 這一層，比 DOM 更底層。換句話說，它不在乎 DOM 的邊界。

寫過自動化的都知道，最痛苦的不是點按鈕，是「點不到」那個按鈕：它躲在一個跨網域的 iframe 裡、藏在 Shadow DOM 深處、或者是 Cloudflare 那個你怎麼寫 selector 都選不中的人機驗證方塊。傳統工具要你想盡辦法讓 selector 穿過這些邊界，常常繞到最後還是失敗。

座標點擊把這題整個跳過。agent 看一張截圖，認出按鈕大概在哪個位置，報一組 x、y 座標，事件就從底層打下去，DOM 怎麼包裝的它一概不管。要點 YouTube 內嵌的播放器？看圖、抓座標、點下去，結束。

不用框架，但也不是叫你從零開始

講到這裡你可能會擔心：什麼都丟給 agent，那它面對陌生網站不就要一直踩坑、一直試錯、一直燒 token？

這專案有個聰明的回答，叫 skill system，但它不是寫死的程式碼，而是一疊人類和 agent 都讀得懂的 markdown 筆記。一種是 17 份「interaction-skills」，記的是通用的 UI 招數——對付 dialog、iframe、下拉選單、檔案上傳這些常見場景該怎麼處理。另一種更實用，是 66 個知名網站的「domain-skills」：Amazon、LinkedIn、TikTok、GitHub、Zillow、Booking.com 這些站各自的怪脾氣，都有人踩過坑寫成筆記了。

巧妙的是觸發方式。當 agent 導航到 github.com，goto() 會自動回傳一行 domain_skills: ['github/*.md']，等於在旁邊提醒它：「這個網站有現成的攻略，要不要先看一下？」知識不是塞進框架裡限制你，而是擺在手邊當參考。要不要查、查了怎麼用，決定權還在 agent。

這跟前面的哲學是一致的：不替 agent 做決定，但把它做決定需要的材料準備好。

那它到底適合誰

最關鍵的一個分界線，是 browser-harness 預設 attach 你已經開著、已經登入好的那個 Chrome，而不是像其他框架那樣自己另外開一個乾淨的瀏覽器。

這個差別比聽起來重要。attach 真實 Chrome，意味著你的 cookie、登入狀態、瀏覽歷史、裝好的擴充套件，全部原封不動帶著。那些「一定要登入才能做」的事——回 LinkedIn 訊息、訂 Amazon、把 Gmail 某個分類的信整理進 Notion、下載電子發票——這個 harness 最拿手，因為它操作的根本就是你本人的瀏覽器。順帶一提，這也天然繞過了大部分反爬蟲機制，因為從網站的角度看，這就是一個正常使用者在用他自己的 Chrome。

但它的取捨也很誠實。這是 2026 年 4 月才公開的 v0.1.0，刻意不做 retry、不做 timeout、不做 session 管理，出錯了 agent 得自己收拾。所以它擺明了適合個人自動化跟 agent 研究，不適合拿去扛生產線上不能出錯的關鍵業務——那種場景你要的是 Playwright 那種跑一百遍結果都一樣的確定性，不是一個會即興發揮的 agent。它也只支援 Python，TypeScript 的人得去看 Stagehand 或 Playwright-MCP。還有一個安全紅線：domain-skills 是公開共享的知識庫，別把 cookie、密鑰、個資寫進去。

所以該不該用它，其實取決於你要的是哪一種東西。如果你想要的是一台穩定、可重複、誰來跑都一樣的自動化機器，這個 harness 不是給你的。但如果你要的是把自己的 Chrome 交給一個會臨場想辦法的 AI，讓它用你的身分、你的登入狀態去把事情做完——那這 600 行就是目前定位最清楚的一個。

它真正示範的，其實是一個更大的判斷：當你的使用者從「人」變成「會寫程式的 AI」，很多我們以為理所當然該幫使用者準備好的東西，反而成了綁手綁腳的枷鎖。少做一點，有時候是更難、也更聰明的設計選擇。