瀏覽器 Agent 第一次自己摸熟一個網站時，很像剛學會走路的小孩自己去便利商店買牛奶。門推開了、錢付了、牛奶真的拿回來了，旁邊的大人差點感動到拍手。

第二次，同一個小孩又從家門口開始迷路。

第一百次，感動就不見了，剩下一張越來越難看的帳單。每次都重新看頁面、重新猜欄位、重新繳同一筆「發現稅」。更慘的是，那次終於成功的摸索沒有留下乾淨交接物。團隊很難把一段錄影、一堆執行軌跡，或一串自然語言推理交給下一位工程師說：「照這個做。」

原作者介紹 Browserbase 內部的 Autobrowse，打中的就是這個痛點：生產環境裡，瀏覽器 Agent 真正缺的不只是腦袋，而是可以交接、可以審、可以重用的記憶。

這套系統的做法很直接，也很狠：讓 Agent 在真實網站上做真實任務，讀自己的執行軌跡，修策略，砍掉浪費步驟，直到流程不是靠運氣成功。最後，把勝出的做法「畢業」成一份可重用技能：一個 SKILL.md，加上必要的 CLI 呼叫、fetch、選擇器和輔助腳本。

先講清楚本文的證據邊界：原作者的 X 長文目前不是所有人都能直接打開全文，所以文中提到的內部實驗數字，應該讀成「原作者回報的案例結果」，不是公開可重跑的基準測試。這篇會保留方法論與案例形狀，但不把那些一次性執行的美元數、秒數當成獨立驗證過的普遍數字。

這不是把 Agent 的回憶丟進向量資料庫，然後祈禱下次語意搜尋會找對。這更像把偵探辦案筆記整理成作業手冊：誰接手都能讀，Agent 也能照著跑。

Clawd 想補充：

這裡最重要的轉念是：記憶不是「一坨向量表示」。記憶如果不能被人審、不能被改、不能進版本控制，那在企業工作流裡就很像一個會通靈的黑盒同事。很神，但交接時讓人心臟很痛。

這條線其實接上了 gu-log 前面幾篇同一個問題的不同切面：SP-191 談 Claude Dreams 怎麼整理 Agent 記憶垃圾山，SP-135 談為什麼 Agent 應該用檔案系統保存狀態，SP-158 則談生產環境裡怎麼用執行軌跡改進 Agent。Autobrowse 比較像把這三件事疊在一起：記憶要整理、要落地，還要能從一次次執行裡長出下一次可重用的做法。

沒有海馬迴的天才

原作者用了一個很準的形容：瀏覽器 Agent 像是沒有海馬迴的天才。

海馬迴是大腦裡跟記憶形成很有關的區域。瀏覽器 Agent 在單次工作裡可以很靈活，面對真實網站那些很煩的狀況也能現場處理：不同使用者代理看到不同頁面、內容藏在 JavaScript 後面、真正資料躲在沒文件的 JSON 端點、網站看到陌生連線就丟驗證碼、某個週二突然改版。

通用 Agent 迴圈當下可能都能扛。問題是，這次任務一關，星期一解掉問題的推理就一起蒸發。下次再來，又從零開始。

這種失憶在展示影片裡不明顯，因為展示影片看的是「有沒有完成」。但一進生產環境，真正要看的會變成：「每次完成要花多少錢？要多久？能不能穩定？出了事誰能讀懂？」

如果答案是每次都要重走一遍探索路線，那就像每次去同一家餐廳都重新用 Google 地圖 繞一圈找門口。第一次叫探索，第一百次叫浪費生命。

不是再聰明一點，是別再重學一次

Autobrowse 是一個用 AI 改進 AI 的工作流。原作者把它放在類似 Karpathy 自動研究框架的脈絡裡，只是目標不是研究問題，而是學出更快、更便宜的瀏覽器技能。它不是只叫 Agent 跑一次任務，而是把「跑任務」變成學習迴圈。

流程可以拆成七步。

第一，給 Agent 一個真實目標，例如在 OpenTable 幫某間餐廳訂晚上七點的位置。第二，讓 Agent 用真實瀏覽器從頭到尾嘗試完成。第三，Agent 回頭讀自己的執行軌跡：哪裡卡住、哪裡在猜、哪裡浪費了不必要的 Token。

第四，外層迴圈維護一份 strategy.md。這份檔案像操場旁邊的戰術板，記下每次迭代後的觀察：哪些有效、哪些壞掉、下次要試什麼、哪些動作該停止。下一輪開始前，Agent 先讀 strategy.md，所以改善會累積，不會每輪都失憶。

第五，根據筆記修策略。沒有貢獻的步驟砍掉；能用確定性工具處理的地方，就改用 browse fetch、browse search 或客製 Python。第六，當連續幾次迭代在成本或回合數上沒有明顯改善，就提早停止。第七，把最後勝出的流程寫成 SKILL.md，連同輔助檔案放進公開技能庫。

原作者說實務上迭代數會壓得很低，大約三到五次，而且會積極提早停止。目標不是追求理論上的全域最佳解，而是找到一條可靠、便宜、足夠重用的路。

這裡有一個很反直覺的經濟學：第一輪貴是故意的。第一輪不是單純在完成任務，而是在付未來所有執行的學費。只要最後產物能被重用，前面花掉的探索成本就有機會攤平。

Clawd 插嘴：

這跟「請 Agent 每次都自己想辦法」的差別很大。每次都自己想辦法，聽起來很智慧，實際上像每天早上都重新發明牙刷。這套系統要的是第一次可以笨、可以貴，但笨過一次後要留下工具，不能一直笨得很穩定。

產物不是錄影，是一張後門地圖

Autobrowse 最關鍵的產物不是逐字紀錄、不是截圖合集、不是向量索引，而是一份小小的、可讀的 Markdown 技能。

原作者貼出的 Craigslist 範例很值得細看。那份技能的開頭資訊會標出名稱、用途、網站、分類、標籤、狀態、來源、更新日期、推薦方法，以及替代方法。正文則寫清楚目的、使用時機、工作流程，還有網站專屬坑洞。下面這些細節，是照原作者對範例技能的描述整理；重點在「技能會保存哪種操作知識」，不是要讀者直接照抄成 Craigslist 永久 API 文件。

它不是泛泛地說「去 Craigslist 搜尋」。它把探索結果壓成一張可交接的踩坑地圖。

最上層的結論很簡單：Craigslist 的網頁 UI 背後，其實有一條 JSON API 路線。Agent 不必每次開瀏覽器慢慢點列表，可以先用 fetch 打 API，再把結果解出來。

但真正有價值的不是「找到 API」四個字，而是旁邊那一串小字。搜尋要像從正確城市來的，否則網站可能用出站 IP 猜地理位置；某些回傳欄位不是好懂的 title、price，而是塞在位置陣列裡，要搭配解碼表還原；頁面看起來可以點，但實際內容主要靠前端渲染，硬叫 Agent 盯著畫面找列表，很容易白忙一場。

換句話說，這份技能不是 API 文件，也不是工程師炫技筆記。它比較像餐廳後門路線圖：正門很漂亮，但外送員真正需要的是「走巷子、按左邊電鈴、不要相信門口那張舊告示」。

Craigslist 技能甚至細到提醒：某些欄位看起來像 ID，其實只是位移值；某些查表資料可能每次回應都重建，不能硬寫；分類縮寫也不一定有公開文件可以查。直接把這些東西當穩定資料結構，下一步很可能就是做出一排 404。技能真正保存的，不只是「打哪個端點」，而是「哪些欄位看起來像常識，其實是陷阱」。

這種東西對 Agent 有用，對人也有用。工程師可以讀、改、提交；下一個 Agent 可以載進脈絡；客戶端團隊也能拿來審計。成功不再只是一段神祕執行軌跡，而是一份工作手冊。

Craigslist 範例：少走那條漂亮的冤枉路

Craigslist 是原作者分享的具體內部測試案例。

原作者回報的結果是：傳統 Claude Code 迴圈每次都要重新探索；畢業後的 Autobrowse 技能則明顯壓低單次成本與耗時。本文不重複那些一次性執行的精確美元數與秒數，因為它們比較像內部實驗紀錄，不是公開可重跑基準測試。

原作者強調，重點不是絕對數字，而是形狀。第一次上站成本看起來會像通用 Agent 迴圈該有的成本；但技能一旦形成，後面每次執行都不再重新推導。它直接走 Agent 找到的最短可靠路線。

原作者也提到另一個早期表單填寫實驗：經過少量迭代後，成本大幅下降。靠的不是魔法，而是讓 Agent 看懂自己哪些步驟其實沒有貢獻，然後刪掉。

Craigslist 技能的路線可以濃縮成一句話：不要從最像人的路開始，從最像資料的路開始。

一般瀏覽器 Agent 看到搜尋頁，直覺會像人一樣輸入關鍵字、等畫面更新、讀列表、點下一頁。這條路看起來合理，因為畫面就是網站拿來給人看的介面。問題是，畫面常常不是資料本身，只是資料穿好衣服出來見客。

Autobrowse 學到的路線比較工程一點：先選城市和分類，再打 Craigslist 的搜尋 API，檢查回來的城市範圍對不對，然後解碼每筆貼文，最後組出可用的貼文 URL。分頁也盡量跟著 API 回傳走，不要回去叫瀏覽器慢慢點。

這裡對初學者最容易卡住的點，是那些看起來像低階實作細節的字：Referer、postal、解碼表、位置陣列、無障礙索引。其實可以先不用背名詞，只要抓住同一件事：網站會把資料藏在好幾層包裝後面，技能負責記住哪一層才是真的門。

Referer 和 postal 這類資訊，是在告訴網站「這次搜尋應該算哪個城市」。解碼表是在把網站壓縮過的回傳翻回人看得懂的標題、價格、地點。無障礙索引則提醒 Agent：有些畫面對自動化工具來說是空的，硬點 UI 不如直接抓底下的資料。

這樣講就不會被 Craigslist 的細節淹死。真正重要的是模式：Agent 第一次花力氣把網站摸熟，第二次開始就不要再演偵探劇。技能把「原本要靠踩坑才知道」的細節存下來。下次 Agent 不需要再看著客戶端渲染頁面發呆，不需要再猜為什麼紐約查詢回來是舊金山，也不需要再把位移值當 ID 做出一排 404。

Clawd 吐槽時間：

這份 Craigslist 技能最有趣的地方不是「找到 API」四個字，而是把 API 周邊那些髒髒的現實都寫進去。城市可能被 IP 影響，回傳格式可能要解碼，分類縮寫可能沒文件，地區標籤也不一定可靠。真正的生產知識通常都長這樣，不是美美的架構圖，是一堆「拜託不要再踩」。

真的該派偵探的時候

Autobrowse 強的地方，是那些真的需要探索的網站。

例如隱藏或沒文件的 API。它們不會出現在渲染後頁面，但會在網路請求裡露餡。再來是重度客戶端渲染，真正內容要經過一串互動才出現。還有多步驟登入、精靈式表單，第一個畫面看不出正確路徑。以及任何 UI，只要最短可靠路徑複雜到足以讓人類工程師花幾小時逆向，就很適合讓這套系統先去撞。

它也適合找省 Token 的機會。若 UI 沒有實質變化，browse screenshot 可能根本不用每步都做；若某些互動只是繞路，技能就該把它們移除。

原作者提到一個美國聯邦補助入口網站的例子。Autobrowse 去玩這個入口網站時，找出一個沒文件的 JSON 端點，可以一次回傳所有目前補助案。原本看起來像要刮 28 頁，最後變成一次 browse fetch。這個發現被寫進畢業技能，後面就不必再重新發現。

原文有一句很漂亮：Agent 會試人不會試的東西，然後找到人看不到的東西。

這不是說人類比較笨，而是搜尋空間不一樣。人類工程師通常會沿著正常 UI 路線走，因為那是網站設計出來給人看的路。Agent 可以比較沒有包袱地亂試基本動作、讀執行軌跡、看請求、改策略。只要最後有技能把結果整理成可審計路徑，亂試就不只是亂試，而是探索投資。

但不要拿消防車澆多肉

原作者沒有把 Autobrowse 吹成萬靈丹，這點很重要。好工具最怕被拿去解錯問題。

原文給了一個慘痛例子：一份靜態 HTML 州目錄。資料就在標記裡，沒有 JavaScript、沒有登入、沒有反機器人機制、沒有神祕互動，只有一列列資料。

Browserbase 還是把 Autobrowse 丟上去，因為「讓 Agent 自己想辦法」這個敘事太誘人。結果跑了幾輪、燒了不必要的推理成本之後，迴圈還是沒能一次乾淨回傳全部資料列。模型每回合輸出上限截斷推理，迭代迴圈則一直試圖聰明地解一個根本不需要聰明的問題。

後來辨認出問題型態不對，Agent 改用一小段確定性 Python，搭配 browse fetch 和 BeautifulSoup。結果是幾乎不需要推理成本，就能完整抓出表格。

這件事最後被寫進技能裡：

# 第一步：先用 fetch 試探。
browse fetch "<https://example.gov/programs>"
# 如果資料乾淨回來，就直接寫解析程式。
# 如果回應是空的、動態的，或被關卡擋住，再升級到 Autobrowse。

這段教訓非常樸素：先 fetch 看看。資料乾乾淨淨回來，就寫解析器。回應是空的、動態的、被門禁擋住，再升級到 Autobrowse。

瀏覽器 Agent 其實有不同自主程度。最底層可能只是靜態腳本，沒有 LLM 在迴圈裡；再來是路由式或會用工具的 Agent；最高才是能自動迭代、開工具、甚至叫出其他 Agent 的自治迴圈。選哪一級不是信仰題，是工程決策。

Autobrowse 位在高自主程度那端。高自主工具很強，但也很貴、很會把簡單事搞得像畢業專題。資料就在 HTML 裡時，叫 Autobrowse 反覆探索，真的像派消防車去澆桌上的多肉植物。車來了，水管接好了，多肉也淹死了。

Clawd OS：

這個失敗案例反而讓 Autobrowse 更可信。因為真正懂工具的人會說「這個不要用」。只會說「全部交給 Agent」的系統，通常最後會把一張普通 HTML 表格做成一題很貴的哲學問題。

為什麼這會改變交接方式

原作者對技能的定位很清楚：它是一種交給客戶接手的工作交接物，而且這個定位很重。

現在很多 Agent 成功完成工作後，能交給客戶工程團隊的東西通常是執行軌跡、工作重播，或一段自然語言推理。這些東西對除錯有幫助，但不一定能被工作流程負責人真正擁有。它們比較像「這次 Agent 做了什麼」的紀錄，不像「以後這件事該怎麼做」的手冊。

技能不一樣。技能看得懂、留得住、能除錯、能給人審，也能被某個團隊真正擁有。工程師能讀、能改、能提交。非工程師只要夠懂業務，例如技術 PM、技術副總、非常熟悉補助入口網站的管理者，也可以大致看懂 Agent 正在做什麼，不需要碰程式碼。

因此工作流程從「相信 Agent 的輸出」變成「閱讀 Agent 的作戰手冊」。

這個差別很大。原作者的看法是，企業環境裡的可靠不是只有成功率，還包含出事時能不能追、能不能審、能不能改、能不能交接。黑盒式成功很爽，但要進入嚴肅工作流，最後還是得留下人可以擁有的東西。

更長期看，每個新網站都會產出一個新技能。技能庫長大後，Agent 在長尾重複工作上會越來越便宜、越來越快，因為它不再每次付探索稅。原作者說 Autobrowse 已經像是瀏覽器 Agent 能力的工廠；單一技能有用，但真正的獎品，是任何跑瀏覽器 Agent 的人都能使用的一整座公開技能目錄。

接下來要改進什麼

Autobrowse 目前還不是終點。原作者提到幾個方向。

第一是更聰明的停止條件。現在做法是限制少量迭代，並在連續執行的成本與回合數收斂時提早停止。這合理，但也粗。未來希望讓 Agent 更明確地推理自己是否真的收斂，不只看成本和回合數，也比較多次執行之間的軌跡結構。

這裡有個微妙點：一些最有價值的發現，像美國聯邦入口網站的 JSON 端點，來自 Agent 隨機變化策略時意外撞到更短路徑。如果過早把變異性優化掉，可能會錯過真正的大獎。所以停止條件不能只是一把鈍刀。

第二是更好的探索先驗。Browserbase 希望 Agent 在開完整瀏覽器工作前，先想到 fetch 和 search 這些基本動作。很多看起來像探索的問題，其實一個 fetch 就能回答。更進階的任務則可以讓 Agent 檢查瀏覽器軌跡、網路事件和 CDP 紀錄，透過觀察網路請求找內部 API，而不是只從渲染後 DOM 猜。

第三是讓 Autobrowse 改進 Autobrowse。今天的迭代迴圈、收斂判斷、技能模板大多還是手工設計。既然 Autobrowse 可以替單一網站畢業技能，同樣想法也可以用來替框架本身畢業改進：更好的迭代 Prompt、更好的基本動作選擇先驗、更適合不同任務類型的技能模板。

更大的圖像

現在對瀏覽器 Agent 有一種很常見的故事：等底層模型再強一點，某次 Anthropic 或 OpenAI 發表新版本之後，Agent 就會突然在網路上「真的能用」。

Kyle 不完全買單。

就算模型完美，它在每個新網站上還是得發現那些「如果以前來過就該知道」的事情。沒有地方存放學到的東西，每次執行都是重新開始。模型再聰明，也不該每次都重讀同一本迷宮攻略。

Autobrowse 的核心主張因此不是「做一個更聰明的瀏覽器 Agent」，而是「把探索痕跡畢業成可重用技能」。這也是本文最值得帶走的主軸：瀏覽器 Agent 的真正瓶頸，不是只差下一代模型多一點推理，而是缺少一種可審計、可重用、能被人和 Agent 一起讀懂的記憶格式。

這個格式目前看起來意外樸素：Markdown、少量輔助工具、清楚的踩坑提醒、必要時搭配確定性程式碼。

很不炫，但很工程。

結語

Autobrowse 最有意思的地方，不是 Agent 會自己操作瀏覽器。那件事已經不稀奇了。

真正有意思的是，它把一次性的探索變成可以交接的資產。Agent 今天迷路的成本，應該變成明天少走冤枉路的技能；Agent 今天撞到的坑，應該變成下一個人和下一個 Agent 都看得懂的警告牌。

如果瀏覽器 Agent 要進入嚴肅工作流，最後勝出的可能不是最會即興表演的 Agent，而是最會留下工作筆記的 Agent。(๑•̀ㅂ•́)و✧