browser-use/browser-harness 是一個面向 AI Agent 的瀏覽器控制工具。它的目標不是再做一層複雜的自動化框架，而是把大模型直接連到真實 Chrome，透過 CDP 完成瀏覽、點擊、截圖、下載、上傳和表單操作。
專案 README 對自己的定位很明確：用一層很薄、可編輯的 CDP harness，讓 LLM 直接連接真實瀏覽器；當任務中缺少 helper 時，Agent 可以在執行過程中補上程式碼，並把可重用經驗沉澱成 domain skills。
這類工具值得關注，是因為瀏覽器仍然是很多真實工作的入口：後台系統、SaaS 面板、電商頁面、招聘網站、CRM、報銷系統、雲控制台、文件平台，往往沒有穩定 API，或者 API 權限比網頁權限更難拿到。讓 Agent 能可靠操作瀏覽器，本質上是在補齊自動化的最後一段距離。
browser-harness 是什麼
從結構看，browser-harness 更像一個給 Agent 用的瀏覽器執行環境，而不是普通使用者手動點擊的瀏覽器外掛。
它的核心思路有幾個：
- 直接連接 Chrome 或 Chromium。
- 透過 CDP WebSocket 操作頁面。
- 讓 Agent 組合截圖、座標點擊、DOM、網路請求和原始 CDP 完成任務。
- 把任務相關 helper 放在
agent-workspace/agent_helpers.py。 - 把站點相關經驗沉澱到
agent-workspace/domain-skills/。 - 保持核心很薄，避免做成龐大的自動化平台。
README 提到，專案核心架構大約是 4 個核心檔案、約 1000 行程式碼，主要包括 install.md、SKILL.md、src/browser_harness/、agent-workspace/agent_helpers.py 和 agent-workspace/domain-skills/。
這種設計的重點不是內建所有網站能力，而是給 Agent 一個足夠貼近真實瀏覽器的操作層，讓它在具體任務裡補齊缺失能力。
它和傳統瀏覽器自動化有什麼不同
傳統瀏覽器自動化通常圍繞測試框架展開，例如 Playwright、Selenium 或 Puppeteer。它們適合寫確定性的測試腳本：打開頁面、定位元素、點擊、斷言結果。
browser-harness 面向的是另一類任務：使用者說一句目標，Agent 自己探索頁面、判斷狀態、處理彈窗、補 helper、複用站點經驗。它強調的是互動過程中的適應性。
差異可以這樣理解：
- Playwright 更適合人寫腳本，Agent 執行腳本。
- browser-harness 更適合 Agent 邊看頁面邊行動。
- 傳統自動化偏固定流程。
- browser-harness 偏開放任務。
- 傳統腳本常依賴選擇器。
- browser-harness 鼓勵先截圖、再按可見介面行動，必要時再回到 DOM 或 CDP。
這不表示它要取代 Playwright。對穩定測試來說，Playwright 仍然更成熟。browser-harness 的價值在於把真實網頁變成 Agent 可操作的環境，尤其適合頁面結構複雜、步驟不固定、需要臨場判斷的任務。
為什麼強調真實 Chrome
很多瀏覽器 Agent 工具會使用隔離的無頭瀏覽器。這樣部署簡單，也適合批量任務，但它有一個現實問題：使用者真實工作裡的登入狀態、擴充功能、歷史記錄、書籤和日常瀏覽器環境，不一定能直接複用。
browser-harness 支援連接本機 Chrome，也支援 Browser Use cloud browser。對本機瀏覽器，它提供兩種方式：
- 透過
chrome://inspect/#remote-debugging允許目前 Chrome 實例被連接。 - 用
--remote-debugging-port=9222 --user-data-dir=...啟動一個隔離 profile。
如果要讓 Agent 幫你處理真實帳號裡的任務，專案文件更傾向第一種方式，因為它能複用日常 Chrome 的登入狀態、擴充功能和書籤。如果要做無人值守自動化，或者不希望被彈窗打斷，則更適合使用隔離 profile 或雲瀏覽器。
這裡的取捨很清楚：真實瀏覽器更貼近使用者工作流，但安全邊界也更敏感；隔離瀏覽器更適合自動化，但需要重新處理登入和環境。
可編輯 helper 與 domain skills
browser-harness 最有意思的地方，是它把「Agent 會學到什麼」設計進了專案結構。
agent-workspace/agent_helpers.py 用來放任務中臨時補出的 helper。比如 Agent 做檔案上傳時發現現有能力不夠，可以補一個穩定的上傳函式；下次再遇到類似頁面，就不用從零開始。
agent-workspace/domain-skills/ 則用來放站點級經驗。README 裡舉的方向包括 LinkedIn outreach、Amazon 下單、報銷系統等。專案建議不要手寫這些 skill，而是讓 Agent 在真實任務中發現可重用流程後再生成，這樣更貼近實際頁面行為。
這個思路很適合瀏覽器自動化。因為網頁自動化的難點往往不是「怎麼點擊按鈕」，而是：
- 某個網站的登入後頁面怎麼跳轉。
- 哪些彈窗會擋住主流程。
- 哪些 selector 穩定，哪些只是臨時樣式名。
- 上傳、下載、iframe、shadow DOM、跨域元件怎麼處理。
- 某個後台系統有哪些隱藏等待和非同步狀態。
這些知識如果只留在一次執行日誌裡，很快就會丟掉。把它們沉澱成 domain skills，才可能讓 Agent 越用越順。
適合哪些場景
browser-harness 更適合以下任務：
- 幫使用者操作真實網頁後台。
- 在沒有 API 的系統裡完成重複流程。
- 登入狀態依賴強的個人或企業網頁任務。
- 需要截圖判斷頁面狀態的複雜互動。
- Agent 需要在執行中補工具、補站點經驗。
- 多個子 Agent 各自使用獨立瀏覽器執行任務。
- 研究瀏覽器 Agent 的執行環境設計。
具體例子包括：整理網頁表格、提交內部系統表單、下載帳單、上傳檔案、處理報銷流程、檢查訂單狀態、在 SaaS 控制台裡配置資源、從登入後的網頁提取資訊。
如果任務只是抓取靜態網頁，未必需要瀏覽器。專案自己的 SKILL.md 也提到，靜態頁面可以直接用 HTTP 批量取得；瀏覽器應該留給真正需要頁面狀態、登入狀態和互動的場景。
需要注意的風險
讓 AI Agent 接管真實 Chrome，很強，也很危險。
第一，權限邊界要清楚。真實 Chrome 裡可能有信箱、支付後台、雲控制台、公司系統和個人帳號。Agent 一旦能操作瀏覽器，就等於獲得了這些網頁權限的一部分。
第二，不要把憑證交給模型。遇到登入頁、支付驗證、二次確認等敏感步驟，應該讓使用者自己處理。Agent 可以等待登入完成，但不應該從截圖裡讀取或輸入密碼、驗證碼、支付資訊。
第三，自動化不等於可託管。很多網頁任務看似簡單，但中間可能出現風控、誤點擊、資料刪除、批量提交、不可逆操作。適合先從唯讀、低風險、可回復的流程開始。
第四，domain skills 需要避免洩露隱私。站點經驗可以公開，但不要把帳號、內部 URL、客戶資料、座標流水或一次性任務細節寫進去。
第五，真實瀏覽器連接方式要謹慎選擇。如果要複用日常登入狀態，使用目前 Chrome 很方便；如果要跑長時間自動化，隔離 profile 或雲瀏覽器更可控。
對 AI Agent 工具的意義
browser-harness 代表了一種很務實的 Agent 工具路線：少做平台，多給模型一個可以直接觸達真實環境的介面。
過去很多 Agent 失敗在兩端。一端是模型會推理，但摸不到真實頁面；另一端是自動化框架很強，但需要人先把流程寫死。browser-harness 試圖把這兩端接起來：瀏覽器負責真實世界的狀態，Agent 負責觀察、判斷和補工具。
這也是「自我改進 harness」的意義。它不是說 Agent 會神奇地變聰明，而是把可重用的操作經驗放到專案結構裡，讓下一次任務少走彎路。
對開發者來說，browser-harness 的價值主要在三個層面：
- 作為個人 Agent 的瀏覽器控制層。
- 作為研究瀏覽器自動化和 Agent 工作流的樣本。
- 作為把網頁流程變成可重用技能的實驗框架。
它不是所有瀏覽器自動化問題的答案，但它給出了一個清晰方向：當 Agent 真正要幫人做事時，工具層不只要能呼叫 API，也要能理解和操作人類每天使用的網頁介面。
簡單結論
browser-use/browser-harness 值得關注，不是因為它包裝了多少高階功能，而是因為它把瀏覽器 Agent 的幾個關鍵問題擺在了台面上：真實 Chrome、CDP、截圖驅動、可編輯 helper、站點技能沉澱，以及使用者權限邊界。
如果你只是寫穩定端到端測試，繼續用 Playwright 或 Selenium 就很好。如果你想讓 Codex、Claude Code 這類 Agent 直接幫你處理真實網頁任務，browser-harness 提供了一個更貼近 Agent 工作方式的入口。
真正使用時，建議從低風險任務開始：先讓它讀頁面、截圖、提取資訊，再逐步嘗試點擊和提交。等你確認它能穩定識別頁面狀態，再考慮讓它接管更長的流程。
參考資料：