別再訓練 AI 按按鈕了：Browser Use 創辦人認為瀏覽器代理人的未來不在 UI

本文整理自《Open Source Startup Podcast》2026 年 2 月播出的單集。收聽完整節目：Spotify ｜ Apple Podcast

所有人都在教 AI 按按鈕，但這條路對嗎？

如果你打開 Anthropic 的 Claude、Google 的 Gemini、或是 OpenAI 的 Operator，它們操作瀏覽器的方式本質上是一樣的：看螢幕截圖，辨識元素位置，然後模擬人類去點擊座標。這跟一個人坐在電腦前，用滑鼠和鍵盤操作網頁的邏輯完全相同，只是把人換成了 AI。

Browser Use 創辦人暨 CEO 穆勒（Magnus Müller）認為這條路走錯了。他在 Open Source Startup Podcast 上拋出一個大膽的觀點：教 AI 精準點擊座標只是一個過渡階段，就像我們曾經用馬車的思維去設計第一代汽車一樣。真正的未來，是讓 AI 代理人完全跳過使用者介面，直接跟網站底層的伺服器溝通。

這不是學術上的空想。穆勒帶領一個 8 人團隊打造了目前 GitHub 上最受歡迎的 AI 瀏覽器自動化工具（近 79,000 顆星星），他每天都在面對座標點擊方案的各種極限。他的判斷來自實戰經驗，而非理論推演。

座標點擊的根本問題：又慢又脆弱

目前的瀏覽器代理人運作方式是這樣的：AI 模型接收一張螢幕截圖（或 HTML 結構），決定要對哪個座標執行什麼動作（點擊、輸入、滾動），然後等待頁面更新，再拍一張新的截圖，重複這個循環。一個簡單的表單填寫，可能要經歷十幾個來回。

這個方案的問題不只是慢。穆勒觀察到幾個結構性的弱點。首先，每一步都有失敗的可能。AI 可能點錯位置、可能遇到彈出視窗遮住按鈕、可能因為網頁還沒載入完就急著操作。當你串連十個步驟，即使每一步成功率有 95%，整體流程的成功率也只剩 60%。

其次，速度是硬傷。每個步驟之間都需要等待模型推理和頁面渲染，開發者在迭代的時候往往要等五到十秒才能看到下一步。穆勒的原話是：「你坐在那邊等，看著代理人慢吞吞地點按鈕，明明你自己做只要兩秒，但你必須等它想五秒鐘才能點下去。」這種體驗直接影響開發者的耐心和產品的可用性。

最後，重複執行的一致性很差。同樣的指令、同樣的網頁，AI 代理人兩次執行的路徑可能完全不同。它可能第一次走了最短路徑，第二次卻繞了一大圈。這種不確定性讓企業客戶無法信任它，因為生產環境需要的是「每次都做一樣的事」的可靠性。

轉化為程式問題：Browser Use 的中間解法

在等待「終極方案」成熟之前，穆勒的團隊找到了一個聰明的中間路線：把瀏覽器操作轉化為程式碼生成問題。

具體來說，AI 代理人第一次執行任務時，仍然用傳統的截圖加座標方式去探索網站。但探索的目的不是完成任務本身，而是生成一段可以重複執行的程式碼。一旦程式碼通過驗證，後續的重複執行就不再需要 AI 即時判斷，直接跑程式碼就好。如果某天網站改版導致程式碼失效，代理人再啟動一次探索，重新生成新的程式碼。

穆勒解釋這個思路背後的洞察：現在的大型語言模型最擅長什麼？寫程式碼。ReMotion（一個用程式碼製作影片的工具）的爆紅已經證明了這一點，AI 用程式碼做出了沒有人預期到的創意影片。同樣的邏輯放到瀏覽器上：與其讓 AI 每次都用「人類的方式」跟網頁互動，不如讓它用「工程師的方式」直接生成操作腳本。把問題轉化成 AI 最擅長的形式，結果自然更可靠、更快、更可預測。

這個設計直接解決了企業客戶最在意的問題：可重複性。傳統的 Playwright 腳本可以重複執行，但寫起來痛苦、維護成本高。AI 代理人用起來簡單，但不可重複。Browser Use 的方案結合了兩者的優點：AI 負責生成，程式碼負責執行。

終極願景：索引網路上的每一個動作

穆勒的 hot take 更進一步。他認為，即使是「生成程式碼來操作瀏覽器」也只是過渡方案。終極目標是建立一個涵蓋整個網際網路的「動作索引」。

概念是這樣的：Google 索引了網路上所有的「內容」（文字、圖片、影片）。穆勒想索引的是所有的「動作」（發訊息、填表單、下載檔案、下單購買）。當這個索引建立起來之後，AI 代理人就不需要打開瀏覽器、載入頁面、找到按鈕再點擊。它只要呼叫一個工具，說「幫我發一則訊息給這個人，內容是這些」，然後 Browser Use 的系統就直接跟網站的 HTTP 層溝通，完成操作。

這等於把網路上每一個沒有公開 API 的服務，都變成有 API 的服務。不是透過逆向工程每一個網站（那樣不可擴展），而是透過 AI 代理人的探索和學習，自動建立起每個操作的最佳路徑，然後快取起來供後續使用。

穆勒承認這「非常、非常難」，但他認為一旦做到，代理人的能力會提升百倍。不用等頁面載入、不用處理彈出視窗、不用擔心座標偏移，直接跟伺服器對話。速度從秒級變成毫秒級，可靠性從 60% 跳到接近 100%。

下一步：不等你開口的主動式代理人

穆勒的另一個預測是關於代理人的「主動性」。他認為目前所有代理人的最大瓶頸不是技術能力，而是「需要人類先開口」。

他舉了自己的例子：以 Opus 4.5 的能力，他幾乎可以用自然語言完成任何瀏覽器操作。分析資料庫、發信給客戶、抓取競品資訊，全都可以靠一句 prompt 啟動。但問題是，他還是得自己打那句 prompt。而人的精力和注意力是有限的，很多可以自動化的事情根本不會想到要去自動化。

真正的突破會在代理人變得「主動」的時候發生。想像一個代理人不是等你下指令，而是自己觀察你的工作流程，然後主動告訴你：「我發現你的使用者留存率這週下降了 5%，我已經分析了原因並送了一個 PR，預計能改善這個問題。」或者：「你上週聯繫過的那三個潛在客戶都還沒回信，我幫你寫了跟進訊息，要不要發出去？」

穆勒認為，這就是為什麼 Claude 的 Bot 功能引起這麼多關注。一個隨時在線、主動觀察、不需要你開口就能行動的代理人，跟一個被動等待指令的工具，帶來的價值完全不同。前者會根本改變人和軟體之間的關係。

我的觀察

穆勒提出的「跳過 UI 直接跟伺服器對話」，聽起來很像早年 IFTTT 和 Zapier 想做的事情，只是當時是靠人工對接每一個服務的 API。差別在於，AI 代理人有能力自己去「發現」服務的溝通方式，不需要每個網站都提供官方 API 文件。這是一個重要的範式轉移：從「平台主動開放」變成「代理人主動探索」。

但我也認為這條路上有一個穆勒沒有提到的巨大障礙：網站營運者不會坐視不管。當代理人開始繞過 UI 直接跟後端溝通，等於繞過了廣告展示、繞過了使用者體驗設計、繞過了平台想要你看到的一切。這會觸發新一輪的攻防戰，就像搜尋引擎和 SEO 的關係一樣。未來我們很可能會看到「anti-agent」技術的興起，而代理伺服器成本居高不下正是這個趨勢的早期信號。

我自己每天用 Claude Code 做各種自動化，最深的感受是穆勒說的那句：「目前唯一的瓶頸是我還得自己打 prompt。」這聽起來像是小問題，但它其實是一個巨大的認知負擔。你必須先意識到某件事可以自動化，然後把需求翻譯成精確的指令，這本身就是一種勞動。如果代理人能做到真正的主動式運作，那它帶來的不只是效率提升，而是把人類從「想到要做什麼」這個最耗能的認知步驟中解放出來。這可能是 AI 代理人真正改變工作方式的轉折點。