為什麼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之下的契約，然後直接使用這些契約。如果你想試一試，這裡有一個瀏覽器擴充套件形式的智慧體。