BrowserBC：克隆人類點擊，讓一次網頁操作轉化為所有Agent的能力

允中 發自 凹非寺量子位 | 公眾號 QbitAI

Agent從來不是不會用瀏覽器，只是浪費太多時間在探索——BrowserBC把人類軌跡蒸餾成可復用Skill來完成Behavior Cloning，用戶點一遍，Agent照著就能跑通。

今天的Web Agent，已經不缺「會操作」這件事。

Claude、Codex這類Agent能看頁面、能識別按鈕和輸入框，能點擊、輸入、跳轉、提交。

真正卡住它們的，是另一個問題：

每接一個新任務、每換一個新網站，幾乎都要讓最強、也最貴的那個模型，從零開始再把整個流程摸索一遍。

而這種「從零摸索」，常常摸著摸著就出岔子：

陷進死循環，在幾個頁面之間反復橫跳；慢慢偏離最初的任務意圖，越走越遠；在搜索結果里來回切換卻始終沒讀全；或者明明已經很接近答案，卻提前收手、草草交差。

在摸索一遍之后呢？就算這次僥幸做成了，這點經驗也往往隨著這一輪對話一起蒸發。下一次同類任務，再換一個Agent，還要從頭試錯、再踩一遍同樣的坑。

于是，一個很樸素的問題浮出水面：能不能做一次、復用很多次？

更具體一點——能不能讓人把任務認真做一遍，把這一遍操作里的「門道」打包下來，然后交給一個更便宜、更小的模型，讓它照著做，就能完成同一類任務？

Einsia AI旗下Navers Lab發布的開源項目BrowserBC給出的答案，是一條三步范式：錄制→轉寫成Skill→交付執行。

• 錄制：在瀏覽器里做任務的時候，把全過程完整記錄下來——任務指令、每一步的頁面觀察（既有渲染出來的截圖，也有結構化的DOM/可訪問性樹快照）、用戶的每一個動作（點擊、輸入、跳轉、提交，并帶著對應的元素定位）、頁面給出的反饋（頁面跳轉、校驗與報錯信息、完成信號），以及任務最終落到哪個狀態。
• 轉寫：關鍵在于，它不是把這段操作存成一段「回放腳本」，而是由模型把它轉寫成一份自然語言的Skill——一份說明書式的「技能卡」，寫清楚這類任務該怎么做、怎么判斷做對了。
• 執行：再把這份Skill交給任意一個模型去讀。它據此在真實頁面上自己落地操作，而不是機械復刻某一次的點擊坐標。

說得通俗一點，BrowserBC有點像agentic時代的「按鍵精靈」。

傳統的按鍵精靈，會把人的鼠標點擊和鍵盤敲擊錄下來再回放——但它錄的是寫死的坐標和按鍵，頁面一變、布局一動，整段腳本立刻就廢了。

BrowserBC錄的不是坐標，而是把這一遍操作轉寫成一份講清「該做什么、怎么算做完」的技能：

它能被另一個模型讀懂，能在變了樣的頁面上舉一反三，也能被不斷合并、復用——它是那種會「理解」、能遷移、還能直接交給別人用的按鍵精靈。

這也揭示出BrowserBC的核心——技能從哪里來，和技能由誰來執行，可以徹底分開。

人在瀏覽器里把任務做一遍，這一遍操作被轉寫成技能；之后照著技能把同類任務做下去的，是另一個、哪怕更小、更便宜的模型。技能一旦被轉寫成自然語言，就能在模型之間自由地傳遞、復用、組合。

這正是通往「通用網頁瀏覽」的關鍵步驟：把人類每天的瀏覽器行為蒸餾給Agent去做。

*BrowserBC把人類的瀏覽器操作軌跡蒸餾成可復用的自然語言技能，為Agent提供訪問陌生網站時的“決策先驗”。

Github：https://github.com/Einsia/Browser-BC
Blog：https://lab.einsia.ai/browserbc/
Paper：https://lab.einsia.ai/browserbc/paper

人類一次錄制，Agent就能模擬

研究團隊錄制了一個case：

視頻地址：
https://mp.weixin.qq.com/s/OFXkRh_keR4HzgTImCGjVg

任務很常見：旅行前想要在目的地找一處安心、方便、實惠的民宿，需要在預訂網站輸入時間、地點、預約人數，按照網站評分、評分數量篩選，并且排序找出里面最優的選項。

這類任務看起來不難，但是小模型經常栽在它上面——不是不理解任務，而是要么不知道怎么用篩選功能，要么產生幻覺輸出虛構信息假裝完成。

第一步，錄制。研究團隊先讓一個人把它完整做一遍：進入網站→輸入時間地點人數→應用合適的篩選器→閱讀所有搜索結果→找到最佳選項。整個過程被原樣記錄下來。

第二步，轉寫成Skill。系統把這段操作轉寫成一張技能卡，而不是一段坐標回放。卡片上寫的是這一類任務的通用門道：

• 意圖：在預訂網站找到最佳的住宿選項；
• 關鍵步驟：先寫基本信息，搜索之后逐項應用篩選器——這正是小模型最容易不理解或者做不到的地方；
• 完成判據：最后輸出可以人工核查的版本；
• 要避免的坑：官方篩選器可能和用戶實際需要的標準不一樣，如有需要則需要自己編寫腳本篩選。

第三步，交付給一個小模型執行。這張卡片被交給一個明顯更小的模型，讓它去完成另外一次旅程的信息檢索，做同類型的任務。

沒有這張卡片時，它要么跌跌撞撞卡死或者很久才勉強完成任務，要么直接輸出幻覺；拿到卡片后，它立刻知道要輸入什么信息，要核查什么界面，哪些要依賴網站官方哪些要自己判別——于是穩定地把任務做完了。

就這樣，BrowserBC把「操作瀏覽器」這件每天都在發生的事，變成了可以被Agent復用的技能。人把路趟通一次、由系統轉寫成說明書Agent型負責照著說明書把同一類路走順。

而且，這條路天然是可復用、可擴展的。

人類訪問網站的分布服從冪律分布：常見的站點構成了人類訪問的大部分，對于這些站點，用的人越多，Skill庫就會收斂得越完備；更關鍵的是，針對稀疏的長尾分布，BrowserBC使得人們再也不需要等那些落后的舊網站自己來提供MCP（或官方Agent接口）了。

現實是，大量老網站永遠不會專門為Agent開放一套干凈的機器接口；而BrowserBC直接復用人類在「給人看的那套界面」上積累下來的操作經驗——只要人能用瀏覽器把它用起來，Agent就能借由蒸餾出的技能把它用起來。

換句話說，一個網站能不能被Agent高效訪問，不再取決于網站方愿不愿意配合、肯不肯升級，而取決于有沒有人已經在這個網站上走通過路。

這恰恰是「通用」二字的底氣所在。

方法：怎么把一次操作轉寫成能用的Skill，又怎么把越來越多的Skill管起來

*BrowserBC將嘈雜的瀏覽軌跡清洗、蒸餾為可復用的自然語言技能，并進一步組織成可擴展的技能圖，最后檢索相關技能指導Agent完成新任務。

BrowserBC的方法部分，其實就回答兩個問題：一段操作該怎么總結、總結時要注意什么；以及總結出來的成千上萬個Skill，該怎么管理。

第一個問題：怎么轉寫，以及要特別注意什么？

原始的瀏覽器軌跡往往非常嘈雜——里面有誤點擊、無意義的等待、重復嘗試、臨時的頁面狀態，還可能夾著隱私信息。因此在轉寫之前，BrowserBC會先做清洗，并按語義把軌跡切成一段段連貫的子過程，而不是按固定長度硬切。

每一段會先被抽成一份「證據（evidence）」：保留任務指令、這段操作前后的頁面狀態、用戶采取的關鍵步驟、頁面給出的反饋、以及成功或失敗的信號。

然后，把證據轉寫成結構化的自然語言Skill卡，用固定字段說清楚“該做什么、怎么判斷進展、怎么算完成、失敗了怎么辦”，以及它從哪來、在什么場景下適用。

這樣一張卡，既能直接喂給語言模型當作上下文，又方便人去審閱和修改。

這里有一個最該注意的原則：只保留「可遷移的過程性知識」，剝離「會變、會泄露的細節」。

• 要剝掉的：精確坐標、DOM選擇器、臨時ID、登錄態、隱私文本，以及任何指向具體答案、針對評測checker的內容；
• 要留下的：在語義層面「該做什么、怎么判斷進展、怎么算完成」。

舉個例子，一張「填表單」技能卡寫的是「按語義標簽找到對應字段、把任務給定的值原樣填進去、提交后確認頁面出現成功狀態」，而不是「點 (x, y)、再點那個id是某串字符的按鈕」。

原因很直接：網頁天天在變，布局、DOM、版本、登錄態都會變，克隆坐標和選擇器極其脆弱；而克隆「做什么 + 怎么判斷完成」才真正遷移得動。

還有兩點值得一提：

其一，一條成功軌跡就足以蒸出一個可用技能（它本身就刻畫了一種可行解的結構）；

而把同一任務的多次嘗試（含失敗）放在一起，技能會更穩——成功的運行強化執行步驟，失敗的運行則暴露缺失的前置條件、催生出顯式的恢復策略。

其二，轉寫時要做一遍泄露檢查：技能卡只該記可復用的過程，不該把具體答案夾帶進去。

第二個問題：Skill怎么管理？

如果每條軌跡都生成一個互相獨立的技能，庫很快就會失控：重復、冗余、甚至互相沖突。

BrowserBC的做法是把庫組織成一張技能圖（skill graph）。

每當產生一個候選技能，系統就判斷該把它新增（add）為一個新節點、合并（merge）進已有技能、還是登記為某個更通用技能的特化（specialize）：

• 當兩個技能在意圖、前置條件、步驟、效果、終止證據上彼此相容時，就合并；
• 當它們適用條件不同、需要的信息不同、或約束互相沖突時，就保持分開。

圖里的節點是技能，邊是技能之間的關系——時間依賴、特化、同一子目標下的替代方案、以及同一狀態下的互斥。于是一個通用過程（比如「填表單」）可以連到它的各種特化（支付、改資料）和對應的失敗恢復技能，而不必把它們壓成一條扁平的條目。

這張圖帶來三件事，也正是BrowserBC所說的scalable的真正含義：

把重復的演示合并成可復用的節點，而不是無限堆樣本；讓檢索和更新只動相關的局部區域；支持增量精煉——來一條新軌跡，只更新受影響的技能及其鄰居。

需要強調的是，這張圖的價值在于“組織”：學習與復用的基本單元始終是那張自然語言技能卡，而圖把這些卡片有序地存放、檢索和更新起來，正是技能庫能持續擴張卻不失控的關鍵。

到了執行端，檢索也刻意做得很輕：按語義相似度（有額外信息時再疊加與當前頁面上下文的兼容性）挑出一小撮相關技能，塞進Agent的上下文，剩下的落地交給Agent自己讀取當前頁面來完成。

技能既不是可執行腳本，也不是要照搬的演示，它只是把Agent往蒸餾出來的行為模式上引，而每一個具體動作仍然是對著當前頁面現挑的。

實驗與討論：技能帶來跨基準、跨站點的一致提升

BrowserBC首先在WebArena-Hard上接受檢驗：

258個經人類核驗的任務，覆蓋GitLab、電商及其后臺、論壇、跨站點組合等六類自托管站點。

實驗嚴格控制變量——Agent、動作接口、步數與時間預算全部固定，唯一變量是要不要注入BrowserBC檢索到的Skill。

結果是：base agent成功率為60.5%（156/258），注入技能后提升到81.4%（210/258），提升了20.9個百分點，挽回了基線原本失敗的54個任務。

更強的檢驗來自ClawBench：

152個任務跑在真實線上網站上，頁面布局與操作流程會在不同運行間變化，且以寫操作為主。

這個設定抽掉了「靠記憶取巧」的可能——任何編碼精確坐標、DOM選擇器或緩存頁面狀態的技能，在這里只會越用越糟。

結果是：skill-free基線只解出50/152（32.9%），注入技能后解出104/152（68.4%），提升35.5個百分點，幾乎把解出的任務數翻了一倍，且在全部八個類別上普遍成立。

*BrowserBC在WebArena-Hard與ClawBench上的性能表現。

事實上，技能不僅提升成功率，還縮短了完成任務所需的交互。

在WebArena-Hard任務上，Agent的平均工具調用次數從31.2降到22.7（?27.3%）。

這與「技能作為流程性先驗」的定位一致：

它削減了試探性導航與反復的頁面查看，而把底層grounding留給執行時的實時頁面狀態。

*BrowserBC既能提升交互效率，又能讓蒸餾出的技能在不同模型間遷移。

討論一：Skill是一份「帶置信度的先驗」，不是一條命令。

有一個細節很說明問題：

在WebArena-Hard上，如果強制Agent逐字照搬檢索到的技能——哪怕當前頁面證據與它矛盾——成功率只有 77.5%；而讓它選擇性使用、在與頁面沖突時以頁面為準，才到81.4%。

更進一步，約3.9%（10/258）的任務里，盲目照搬技能反而把本來能做對的做壞了。

這恰恰印證了那條核心判斷：自然語言技能的價值在于「提示策略」，落地永遠要交給執行模型去讀當前頁面。

討論二：技能是「蒸餾一次、便宜復用」的模型無關對象。

BrowserBC的一個設計主張是：

技能可以由一個強模型蒸餾一次，再交給另一個更便宜的Agent在執行時復用。

團隊在WebArena-Hard任務上，把「蒸餾技能的模型」與「執行技能的模型」交叉組合，得到兩點結論。

其一，技能質量主要在蒸餾階段決定：Sonnet-4.6蒸餾出的技能能同時大幅提升兩個執行器（+24與+20個百分點），而Qwen-3.7蒸餾的技能只帶來微弱增益。

其二，高質量技能能跨執行器遷移：裝備了Sonnet-4.6技能的小Agent達到77%，逼近大Agent的80%，直接坐實了「蒸餾一次、便宜復用」的設想。

討論三：剩下的難，難在「執行」而非「缺知識」。

對仍然失敗的案例做人工審計后發現，瓶頸大多落在執行精度，而不是缺少知識：

長表單漏掉某個字段、目標對象有歧義、長程任務把預算耗在中間頁、或者模型自己推理過長「跑飛」。

這些情況里技能本身是對的、也用上了，限制因素是「按流程執行的保真度」——也就是底層模型的能力。

這也劃出了「小模型執行」的可行邊界：技能能補「該怎么做」，補不了「手穩不穩」。

討論四：遷移到瀏覽器之外——OSWorld案例研究。

論文還在30個OSWorld風格的Ubuntu桌面任務上做了一次診斷性的遷移研究——

需要說明的是，這并非把它當作一項完整的OSWorld刷榜，而是考察「方法的哪一部分能遷移」。

30個任務里，17個在配上匹配技能后得到改善，說明過程性先驗確實能跨過瀏覽器的邊界發揮作用。

真正可遷移的并不是瀏覽器專屬的動作序列，而是那份過程性先驗——前置條件、語義狀態如何轉移、進度里程碑、終止證據、失敗如何恢復。在瀏覽器里它落在頁面、鏈接、表單上；在桌面上則落在窗口、文件、對話框、持久設置上。

剩下的案例則劃出了方法的邊界：少數任務本來就足夠簡單、不需要技能；一部分卡在GUI控制本身（窗口焦點、模態彈窗、文件選擇器狀態）而非缺知識；還有個別案例因為檢索到錯配的技能被「自信地帶偏」。

也就是說，當缺的是「流程結構」時，技能最有用；當缺的是底層GUI grounding、或檢索喂錯了先驗時，技能幫不上忙，甚至會添亂。

BrowserBC的意義不止是一個方法

BrowserBC不是一個炫技的方法。

它真正重要的地方在于，它指明了人類瀏覽器軌跡的價值：

這是人類群體在瀏覽器迷宮中走出來的高效操作路徑。

BrowserBC做的事情，就是把這些隱含經驗的軌跡蒸餾成Agent可用的skill。

核心啟發在于：

第一，提升Agent的Browser Using能力，其實關鍵在于給它補齊完備的網頁邏輯知識。

第二，人類與虛擬世界的交互過程，本身就是一種尚未被充分利用的數據資源。

第三，如果這些軌跡可以被持續蒸餾和管理復用，那么Agent就可以從“可以操作網頁”，逐漸走向“高效”操作網頁。

所以，BrowserBC的核心不是教Agent點擊網頁——它是在信息不完備的環境里，用人類軌跡為Agent補上決策所需的先驗。

在這個意義上，真正決定Web Agent上限的，從來不是“是否能夠復現某個瀏覽器操作流程”，也不是“是否快速拼裝出一個看似可運行的系統”或是“Demo出一個熱門概念”，而是是否真正構建了可以持續積累、可復用、可遷移的經驗結構。

這可能是讓Web Agent從能用走向好用的臨門一腳。