Browser Harness 是什麼？讓 AI Agent 控制 Chrome 的開源瀏覽器工具

Browser Harness 是 Browser Use 開源的自我修補瀏覽器代理人工具（self-healing browser agent tool）。它讓大型語言模型（large language model, LLM）透過 Chrome 開發者工具協定（Chrome DevTools Protocol, CDP）直接控制真實 Chrome；當任務中缺少操作能力時，代理人（agent）可以補寫輔助函式（helper function），讓瀏覽器自動化不再只依賴預先寫好的 click、type、scroll 工具。

Browser Harness 讓人興奮的地方，不是它已經完美，而是它讓人第一次看到：原來 AI 代理人（AI agent）使用瀏覽器，不一定只能被關在一組固定工具裡。

如果你正在搜尋「Browser Harness 是什麼」、「AI Agent 控制 Chrome」或「browser harness 中文教學」，這篇會把它當成一篇入口文來讀：它是什麼、為什麼短期爆紅、跟 Playwright、browser-use、Chrome DevTools MCP 差在哪、怎麼安裝，以及台灣開發者可以從哪裡開始試。

如果你還不熟 AI 代理人的基本概念，可以先看我們的 AI Agent 是什麼；如果你想理解它為什麼需要工具，可以接著看 Tool calling 是什麼。Browser Harness 則是把這兩件事放到真實瀏覽器裡。

Browser Harness 是什麼？

Browser Harness 是 Browser Use 團隊開源的瀏覽器代理人控制架（browser agent harness）。它的主張很簡單，也很刺激：不要再把瀏覽器代理人（browser agent）關在一組預先寫好的點擊、輸入、捲動工具裡，而是把大型語言模型直接接到 Chrome 開發者工具協定，給它一個薄、可編輯的瀏覽器控制層。

當任務中缺少某個操作，例如上傳檔案、切進內嵌框架（iframe）、等待前端狀態更新、抽取特定網站資料，Browser Harness 的想法不是等框架作者未來補一個新 API，而是讓代理人在任務中補寫它需要的輔助函式，繼續完成工作。

這就是它短期爆紅的理由。Browser Harness 讓瀏覽器代理人看起來不再只是「會點網頁的聊天機器人」，而是開始像一個會學、會補工具、會把網站操作經驗留下來的工作夥伴。

這個專案還很早期，不是所有場景都該馬上交給它。但如果你想理解 AI 代理人接下來會怎麼用瀏覽器、怎麼從一次任務學到下一次、怎麼把原本易碎的瀏覽器自動化（browser automation）變成可累積的工作流，Browser Harness 值得花一個下午看懂。

Browser Harness 和 Harness AI / Harness.io 有關嗎？

沒有。Browser Harness 是 Browser Use 團隊開源的瀏覽器代理人控制架；Harness.io 則是另一家公司，主要做開發維運（DevOps）、持續整合與持續部署（CI/CD）、測試自動化與 Harness AI。

兩者名字都包含 harness，但不是同一個產品。如果你搜尋到「Harness Browser」、「Harness AI browser」、「Harness browser agent」或「Harness.io browser agent」，很容易被帶到 Harness.io 的開發維運或測試自動化內容；這篇討論的是 browser-use/browser-harness 這個開源專案。

爆紅不是因為它又能點網頁

瀏覽器代理人最常卡住的時刻，不是它完全看不懂網頁。

更常見的是：它看得到，但工具不夠用。它知道要上傳檔案，卻沒有 upload_file()；它知道按鈕在內嵌框架（iframe）裡，原本的包裝層（wrapper）卻切不進去；它知道表單看起來填好了，前端框架卻沒有真的收到輸入事件（input event）。這些問題在展示影片裡像小瑕疵，在真實工作流裡就是卡死。

Browser Harness 的吸引力，就是它沒有把答案做成「更多預先定義好的瀏覽器工具」。它反過來問：如果程式代理人（coding agent）已經能讀程式碼、改程式碼、理解錯誤訊息，那為什麼瀏覽器操作層不能也變成它能修補的程式碼庫（codebase）？

這是很大的轉念。傳統自動化框架通常假設人類先寫好腳本，框架提供穩定 API，任務在預期路徑裡跑。Browser Harness 假設網頁本來就會超出預期，所以與其把代理人鎖在固定輔助函式裡，不如讓它看見底層協定、看見錯誤、補上它需要的那一步。

Browser Use 官方文章把這套思路稱為代理人控制架（agent harness）的苦澀教訓（bitter lesson）：不是只不要把大型語言模型包在厚框架裡，連工具也不要包得太死。這句話會讓很多做代理人工作流（agent workflow）的人眼睛一亮，因為它點出瀏覽器代理人過去最不舒服的地方：模型越來越會推理，工具層卻常常像昨天寫死的遙控器。

Browser Harness 跟 Playwright、browser-use、Chrome DevTools MCP 差在哪？

很多人第一次看到 Browser Harness，會問：這不就是 Playwright 或 Puppeteer 嗎？或者，Browser Use 本來不就已經是瀏覽器代理人工具了嗎？

差別在抽象層。Playwright 和 Puppeteer 是人類寫腳本控制瀏覽器；browser-use 給代理人一組更好使用的瀏覽器操作抽象；Chrome 開發者工具 MCP（Chrome DevTools MCP）讓代理人透過模型脈絡協定（Model Context Protocol, MCP）使用 Chrome 開發者工具。Browser Harness 更激進：它讓代理人看見底層工具怎麼運作，必要時自己補輔助函式。

工具	核心想法	優點	風險
Playwright / Puppeteer	人類寫腳本控制瀏覽器	穩定、可測試、適合持續整合（CI）	網站變動時要改腳本
browser-use	給代理人一套瀏覽器操作抽象	容易上手、適合代理人工作流	抽象層可能限制代理人
Chrome 開發者工具 MCP（Chrome DevTools MCP）	讓代理人透過 MCP 使用 Chrome 開發者工具	適合開發者除錯與檢查頁面狀態	不一定是完整工作流框架
Browser Harness	讓代理人直連 CDP，必要時補寫輔助函式	彈性高、可自我修補、適合實驗	安全、審查、版本控管更難

這張表也說明了 Browser Harness 的定位：它短期內不會取代 Playwright，也不一定適合所有正式環境自動化。它更像一個探索「代理人怎麼真正使用瀏覽器」的開源實驗場。

專案現在長什麼樣子

截至 2026-05-03，我用 GitHub API 和本地淺層複製（shallow clone）檢查，browser-use/browser-harness 是 MIT 授權的 Python 專案，GitHub API 顯示約 9,802 顆星（stars）、906 個分叉（forks），程式碼庫（repo）同日仍有推送（push）。GitHub 頁面也顯示 301 次提交（commits）。

這些數字不是成熟度證明，但足夠說明一件事：很多人正在等這種東西。

README 目前把架構描述成大約 1,000 行、分布在 4 個核心檔案與工作區（workspace）：install.md 處理安裝和瀏覽器啟動；SKILL.md 告訴代理人日常怎麼用；src/browser_harness/ 是較受保護的核心套件（package）；agent-workspace/agent_helpers.py 是代理人可以補寫的輔助函式；agent-workspace/domain-skills/ 則保存特定網站技能（domain skills）。

這裡最迷人的不是核心套件有多小，而是 agent-workspace 這個概念。它把瀏覽器自動化從「人類寫腳本，機器照跑」改成「代理人操作、發現缺口、補輔助函式、留下技能」。

agent-workspace/domain-skills/ 尤其值得注意。它讓 Browser Harness 不只是每次重新操作瀏覽器，而是把一次任務裡發現的網站規則留下來。官方相關文章 Web Agents That Actually Learn 的核心論點是：網頁代理人（web agent）的成本很多花在探索，技能可以把探索成本攤到下一次。

這也解釋為什麼目前程式碼庫裡有大量特定網站技能的拉取請求（pull request, PR）。很多貢獻不是在改核心執行層（runtime），而是在補某個網站、某種表單、某種單頁應用（single-page application, SPA）、某種登入或資料抽取流程。這是 Browser Harness 最值得注意的地方：它把瀏覽器自動化從「寫一支腳本」變成「累積一個代理人操作知識庫」。

工具 / 專案：Browser Harness

讓瀏覽器代理人直接控制 Chrome，並在任務中補寫自己的工具

Browser Harness 值得看，不是因為它已經是成熟企業工具，而是因為它把瀏覽器代理人的下一步做出來了：代理人不只點網頁，也開始補工具、累積網站操作記憶。

前往專案 ↗ · 看編輯部評語 →

它讓網站經驗變成可重用的技能

如果只把 Browser Harness 看成「大型語言模型控制 Chrome」，會低估它。

真正值得學的是它把網站操作經驗做成特定網站技能的方向。

人類用網站時，會記得很多小技巧：Google Flights 要等下拉選單（dropdown）、某個後台表單要先失焦（blur）才會保存、某個網站的搜尋結果其實可以直接打 API、某個單頁應用的載入狀態（loading state）會騙你以為完成了。這些知識很瑣碎，但它們就是瀏覽器工作流的真實成本。

Browser Harness 的特定網站技能嘗試把這些「只會留在人腦裡的小技巧」變成代理人可讀的操作記憶。下一次代理人來到同一個網站，不必從零開始猜選擇器（selector）、猜等待條件、猜哪個按鈕是真的送出。

這件事對開發者很有啟發。未來好用的代理人工具，未必是單一超強模型配一包萬能工具，而可能是一組會累積現場知識的工作空間：這個網站怎麼登入、哪裡會卡、哪些選擇器穩定、哪些操作要人類批准（human approval）、哪些情況要放棄。

如果你想理解這種「給代理人讀的文件與工具描述」為什麼重要，可以延伸看 MCP 是什麼。Browser Harness 的 SKILL.md 和特定網站技能，正是代理人可讀文件（agent-readable docs）在瀏覽器自動化上的具體例子。

這也是為什麼 Browser Harness 的熱度不只是「又一個開源工具」。它指向一個更大的可能性：代理人不只完成任務，也開始替下一個代理人留下路標。

網路討論看見的是可能性

Hacker News 的 Show HN 討論很快抓到重點。支持者覺得直接使用 CDP 比 Playwright 包裝層更不受限，尤其遇到跨來源內嵌框架（cross-origin iframe）、影子 DOM（shadow DOM）、真實瀏覽器工作階段（browser session）、登入狀態和各種介面邊界案例（UI edge case）時，少一層抽象就少一層卡住的地方。有人把它視為即時代理人式編程（just-in-time agentic coding）：任務中缺什麼，就現場補工具。

Reddit 上一些代理人使用者的討論也很實際：大家想要的不是只會截圖和點擊的玩具，而是能進入真實瀏覽器工作階段、處理登入狀態、搭配搜尋和抽取工具、完成一段可交付工作的代理人。Browser Harness 正好踩在這個期待上。

外部討論當然也有疑問：安裝是不是太麻煩？模型會不會亂改輔助函式？機器人偵測（bot detection）和網站服務條款（Terms of Service, ToS）怎麼辦？這些問題都合理。但 Browser Harness 最有趣的地方不是它已經回答完所有問題，而是它讓很多人第一次看到：瀏覽器代理人可以不是一支寫死的自動化腳本，而是一個會長出工具記憶的系統。

爆紅通常不是因為專案完美，而是因為它提早把一個還沒定型的未來做成了可下載、可 fork、可試玩的東西。Browser Harness 正是如此。

Browser Harness 怎麼安裝？

最簡單的方法，是直接請 Claude Code 或 Codex 讀官方 repo 的 install.md 幫你安裝。Browser Harness 官方 README 甚至提供了一句 setup prompt：請代理人讀 install.md，安裝 browser-harness，並連到你的瀏覽器。

如果你想手動做，基本流程如下：

git clone https://github.com/browser-use/browser-harness
cd browser-harness
uv tool install -e .
command -v browser-harness
browser-harness --doctor

官方建議把 repo 放在穩定位置，例如 ~/Developer/browser-harness，不要放在 /tmp。因為 uv tool install -e . 會把 browser-harness 做成全域可用指令，但仍指向這份可編輯 repo；當代理人修改 agent-workspace/agent_helpers.py 時，下一次執行就會使用新程式碼。

安裝後，還要把 SKILL.md 註冊給你使用的代理人。以 Codex 為例，官方文件建議可以把 repo 裡的 SKILL.md 連到全域 skill 目錄：

mkdir -p "${CODEX_HOME:-$HOME/.codex}/skills/browser-harness"
ln -sf "$PWD/SKILL.md" "${CODEX_HOME:-$HOME/.codex}/skills/browser-harness/SKILL.md"

接著要讓 Browser Harness 連到瀏覽器。官方文件提供兩條路：

1. 使用你的日常 Chrome：到 chrome://inspect/#remote-debugging 勾選允許遠端除錯。這條路會沿用你的登入狀態、擴充功能和書籤，適合你在旁邊看著代理人操作。
2. 使用隔離 Chrome：用 --remote-debugging-port=9222 --user-data-dir=<path> 啟動一個獨立 profile，再設定 BU_CDP_URL=http://127.0.0.1:9222。這條路更適合無人值守或不想干擾日常瀏覽器的任務。

Browser Harness 也支援 Browser Use 雲端瀏覽器（Browser Use Cloud browser）。如果你要跑隔離、雲端或 headless 任務，可以再看官方文件的 BROWSER_USE_API_KEY 與雲端瀏覽器設定。

可以怎麼開始試

我的建議不是先問「它能不能進生產環境（production）」，而是先把它當成一個可以學的代理人實驗室（agent lab）。

第一，拿它試低風險瀏覽器任務。公開資料整理、需要人工巡覽的網站研究、簡單下載、表格抽取、非敏感後台瀏覽、一次性操作流程，都是適合起步的地方。目標不是立刻省多少時間，而是觀察它怎麼遇到問題、怎麼補輔助函式、怎麼留下技能。

第二，讀它的 SKILL.md 和 install.md。這兩個檔案比一般 README 更能看出專案精神：它不是只給人類看的文件，而是寫給代理人看的操作規則。這種「代理人可讀文件（agent-readable docs）」本身就是值得學的設計。

第三，觀察特定網站技能怎麼寫。不要只看核心執行層；看貢獻者怎麼把 GitHub、LinkedIn、Amazon、Google Ads、X.com 或其他網站的特殊操作記下來。這些技能才是瀏覽器代理人從一次性展示（demo）走向可複製工作流的關鍵。

第四，把它的模式學到自己的代理人工作流。就算你不直接採用 Browser Harness，也可以學它的做法：把輔助函式放在可審查（review）的地方，把網站知識寫成技能，把一次任務中學到的選擇器、URL 模式（URL pattern）、API 端點（API endpoint）、等待條件、失敗訊號保存起來。

這篇的讀者如果是開發者，我會建議至少看一次程式碼庫。不是因為它保證會成為最後的標準答案，而是因為它把「代理人怎麼使用瀏覽器」這件事推到一個更有想像力的位置。

常見問題

Browser Harness 是什麼？

Browser Harness 是 Browser Use 開源的自我修補瀏覽器代理人控制架（self-healing browser agent harness），讓大型語言模型透過 Chrome 開發者工具協定控制 Chrome，並在任務中補寫輔助函式。

Browser Harness 可以取代 Playwright 嗎？

短期不會。Playwright 適合穩定、可測試、可重播的瀏覽器自動化；Browser Harness 更適合探索性、代理人式、自我修補的瀏覽器任務。

Browser Harness 適合用在正式環境嗎？

目前比較適合低風險實驗、資料整理、研究與內部流程測試。不建議直接用在付款、權限管理、大量外部互動，或可能違反網站服務條款（Terms of Service, ToS）的任務。

Browser Harness 和 browser-use 是同一個東西嗎？

不是。Browser Harness 來自 Browser Use 團隊，但方向更薄、更底層，強調直接接 CDP 與讓代理人自行補輔助函式；browser-use 則是較完整的瀏覽器代理人抽象與產品生態。

Harness Browser 是不是 Browser Harness？

多數情況下，使用者說的 Harness Browser 其實是 Browser Harness。它不是 Harness.io 的產品，也不是 Harness AI 的瀏覽器功能。

讓實驗留在可控範圍

興奮歸興奮，邊界還是要有。

Browser Harness 的自我修補（self-healing）不是說系統自動變安全，也不是說代理人不會亂做事。它指的是，當任務缺少某個操作能力時，代理人可以補寫輔助函式或技能，讓任務繼續。這很像程式代理人在專案裡遇到缺少匯入（missing import）、缺少工具函式（utility function）、測試失敗時自己修掉。

所以短期內，不要把它直接用在付款、資金轉移、客戶資料刪改、權限管理、公開社群發文、大量外部互動，或任何違反網站規則可能造成帳號風險的任務。遇到登入、雙因素驗證（2FA）、CAPTCHA、金流、法務同意，也應該讓代理人停下來問人。

更好的起點是：低風險任務先玩起來，輔助函式差異（diff）要看，特定網站技能要審查，重要流程要能重播。這些不是要澆熄興奮感，而是讓興奮感真的走得遠一點。

Browser Harness 令人興奮的地方，不是它已經把瀏覽器代理人的所有問題解完了。它令人興奮，是因為它把下一步可能長什麼樣子做出來了：代理人不只操作網頁，也開始補自己的工具、留下自己的工作記憶，讓下一次任務站在上一次的肩膀上。