為什麼Claude用瀏覽器像個喝醉的實習生，以及如何修復

我們花了幾年時間構建客户支持的AI智能體。第一個版本基本上是針對支持上下文的智能搜索：文檔、工單、之前解決方案、內部筆記。這種方案已經能取得不錯的效果，但支持工作很快會觸及產品狀態。答案往往取決於客户的賬户：配置、權限、計費狀態，或者某個隱藏在三級菜單深處的管理員設置。因此，智能體必須檢查產品，有時還要改變它。

我們一開始並不是想“構建一個瀏覽器智能體”，而是“智能體需要連接到API”。那麼，為什麼Claude用瀏覽器像個喝醉的實習生呢？你可能已經用過至少一個瀏覽器智能體，無論是Comet、Claude、ChatGPT Atlas、Browser Use還是其他。流程總是相同的：探索頁面，甚至截圖，找到可能的目標，移動鼠標，點擊，等待，再次截圖，滾動，嘗試下拉菜單，從彈窗中恢復，猜測狀態是否改變。我理解——這是我們能獲取的信息和暴露的功能。但這極其緩慢，效率極低。

這就像讓一個語音智能體通過撥打另一個語音智能體來預約理髮師。技術上可行，第一次使用甚至可能覺得神奇，但一旦意識到兩個系統本可以直接交換結構化數據，就顯得荒謬。UI是為人類優化的：佈局、標籤、漸進式展示、懸停狀態、響應式斷點、視覺層次。這些都不是產品的實際執行模型。

在底層，前端已經在與一個結構化系統對話。一次點擊變成一個請求、變更、RPC調用、WebSocket消息、服務器動作、簽名請求、持久化GraphQL操作或特定於產品的命令。有輸入、輸出、錯誤、權限、副作用和狀態轉換。這正是智能體應該想要的接口，也是我們有MCP服務器和CLI的原因。但由於許多產品還沒有MCP服務器，智能體只能盯着屏幕判斷要點擊哪個按鈕。

顯而易見的解決方案是讓智能體使用UI底層的結構化接口，而非像素。一個操作可以取代十幾個UI步驟。一個小腳本可以取代脆弱的點擊路徑。不要要求模型從截圖和佈局推斷意圖，而是給它對象、字段、方法、響應、錯誤和不變量。這對當前模型來説更合適——它們已經非常擅長代碼、結構化數據和工具調用。而解析截圖、正確點擊並祈禱UI沒有變化，它們的可靠性就差得多了。

因此問題似乎很簡單：為什麼不直接使用底層API？不那麼明顯的答案是：難點不在於接口不存在——UI一直在使用它——而在於該接口沒有被結構化地暴露或文檔化。它通常不公開，可能不穩定，且常常分散在REST端點、GraphQL操作、WebSocket消息、簽名請求、WASM模塊、Web Worker、客户端緩存、服務器動作和純前端約定中。一些重要行為可能存在於請求排序、ID解析、驗證響應、緩存失效或權限相關分支中。“直接使用API”跳過了智能體需要學習UI實際依賴的契約這一部分。

智能體需要知道：存在什麼對象，哪些操作創建或修改它們，認證如何工作，服務器端語言如何映射到面向用户的UI語言，甚至有時狀態ID取決於用户的語言（比如Zendesk）。這些信息通常只隱含地存在於前端代碼、網絡流量、運行時狀態、緩存更新和錯誤處理中。因此，瀏覽器仍然重要——不是作為運行時接口，而是作為發現接口。

當前端執行一個操作時，它揭示了產品契約。它會獲取對象、發送操作、驗證輸入、接收錯誤、更新狀態。智能體可以檢查源代碼，觀察發生了什麼，並提取工作流的形狀：路由、操作或消息模式，請求和響應形狀，必需字段和對象關係，驗證、授權和成功狀態。那麼，我們如何讓智能體從中學習？通過構建技能。

一個簡單的循環已經相當有效：給智能體自己的會話，然後告訴它根據什麼有效、在什麼地方掙扎以及新發現了什麼來更新技能。由於這種學習跨用户進行，我們需要對敏感數據極其小心。幸運的是，我們花了三年時間研究如何讓智能體從過去的支持工單中安全學習而不泄露用户數據。同樣的原則適用。採用這種方法，我們目前已經積累了超過4,300個Web應用的產品特定技能集合。

這些技能包括API路徑、代碼片段、工作流邏輯、領域知識、有用的邊緣情況以及關於產品實際行為的註釋。提取過程還有很多改進空間，但即使是最簡單的方法——讓智能體從會話中生成有用的技能——也能取得令人驚訝的效果。一旦你有了這些技能，就幾乎像擁有一個完美的MCP服務器。智能體可以直接從代碼與API對話，編寫執行多步驟工作流的腳本，並理解從抽象工具描述中永遠無法得知的產品特定事項。

一旦這些技能跨產品存在，工作流也不再侷限於一個標籤頁：從一個工具導出數據，轉換數據，更新另一個工具，並驗證結果。想象一下Claude通過計算機使用去操作VS Code，而不是Claude Code直接處理文件——這就是Pluno與其他瀏覽器智能體的速度差異。

我們創建了一個基準測試，它可能有點不公平，但我想不出其他方法來展示學習產品所產生的效果。我們在24個工具（包括HubSpot、Notion、Stripe、Linear等）的312個真實任務中比較了Pluno和其他瀏覽器智能體。比較並不公平：Pluno之前已經學習過這些產品，知道它們的API、工作流、對象模型、權限以及奇怪的邊緣情況。其他智能體大多像對待新網站一樣處理它們：檢查頁面，推斷下一次點擊，嘗試，失敗後恢復。這不是一個學術上乾淨的比較，但這是我們要構建的產品體驗。用户不想要一個每天早晨重新發現Stripe、Notion、Linear、Salesforce或HubSpot的智能體。他們想要一個已經瞭解底層軟件、因此快上10倍的智能體。

我們預計主要差距在於速度。直接執行避免了截圖、光標移動、重試和等待頁面穩定。但在可靠性上也存在巨大差異。許多瀏覽器智能體不僅運行緩慢，還會卡在UI中、點擊到死衚衕、丟失狀態或放棄。界面不僅是速度的瓶頸，也是成功的瓶頸。因此，請帶着這個前提看待數據：它們並不能證明Pluno在未見過的產品上更優秀，而是展示了當智能體學習了產品後，再將該知識用於下一個任務時會發生什麼。

像素仍然重要的情況包括：首次探索往往需要瀏覽器，視覺產品需要視覺上下文，畫布工具、設計工具、儀表盤、地圖和模糊的工作流可能需要查看屏幕。有些產品可能不暴露可用的後端契約。有些任務需要視覺確認。重點不在於智能體永遠不應使用UI，而是UI不應成為重複性SaaS操作的默認執行層。像素應該是引導層，而非運行時。

瀏覽器智能體緩慢的主要原因是它們使用了錯誤的接口。我們讓越來越擅長代碼和結構化數據的模型，卻通過截圖、按鈕、下拉菜單、佈局變化和彈窗狀態運行。這是本末倒置。軟件在UI之下已經有結構化行為。難點在於安全地將該行為暴露給智能體：學習契約、編輯痕跡、驗證模式、限制權限、要求確認副作用，以及在必要時回退到視覺檢查。未來的方向不是智能體更擅長點擊按鈕，而是它們學習UI之下的契約，然後直接使用這些契約。如果你想試一試，這裏有一個瀏覽器擴展形式的智能體。