--- schemaVersion: 1 slug: gp-193-20260508-article-autobrowse-agent ticketId: GP-193 lang: zh-tw title: Autobrowse：瀏覽器 Agent 真正缺的不是腦袋，是可交接的記憶 summary: Kyle Jeong 介紹 Browserbase 內部的 Autobrowse：讓瀏覽器 Agent 在真實網站上反覆執行任務、研究自己的軌跡，最後把成功路徑畢業成可讀、可審計、可重用的技能。重點不是模型再聰明一點，而是把探索成本轉成下一次可直接拿來用的記憶。 originalDate: 2026-05-06 translatedDate: 2026-05-08 source: "@kylejeong on X" sourceUrl: https://x.com/kylejeong/status/2052103973377867913?s=46 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-193-20260508-article-autobrowse-agent status: published replacementTicketId: null replacementUrl: null --- # Autobrowse：瀏覽器 Agent 真正缺的不是腦袋，是可交接的記憶 > **來源:** [@kylejeong on X](https://x.com/kylejeong/status/2052103973377867913?s=46) 瀏覽器 [Agent](https://gu-log.vercel.app/glossary#agent) 第一次自己摸熟一個網站時，很像剛學會走路的小孩自己去便利商店買牛奶。門推開了、錢付了、牛奶真的拿回來了，旁邊的大人差點感動到拍手。 第二次，同一個小孩又從家門口開始迷路。 第一百次，感動就不見了，剩下一張越來越難看的帳單。每次都重新看頁面、重新猜欄位、重新繳同一筆「發現稅」。更慘的是，那次終於成功的摸索沒有留下乾淨交接物。團隊很難把一段錄影、一堆執行軌跡，或一串自然語言推理交給下一位工程師說：「照這個做。」 原作者介紹 Browserbase 內部的 Autobrowse，打中的就是這個痛點：**生產環境裡，瀏覽器 Agent 真正缺的不只是腦袋，而是可以交接、可以審、可以重用的記憶。** 這套系統的做法很直接，也很狠：讓 Agent 在真實網站上做真實任務，讀自己的執行軌跡，修策略，砍掉浪費步驟，直到流程不是靠運氣成功。最後，把勝出的做法「畢業」成一份可重用技能：一個 `SKILL.md`，加上必要的 CLI 呼叫、`fetch`、選擇器和輔助腳本。 先講清楚本文的證據邊界：原作者的 X 長文目前不是所有人都能直接打開全文，所以文中提到的內部實驗數字，應該讀成「原作者回報的案例結果」，不是公開可重跑的基準測試。這篇會保留方法論與案例形狀，但不把那些一次性執行的美元數、秒數當成獨立驗證過的普遍數字。 這不是把 Agent 的回憶丟進向量資料庫，然後祈禱下次語意搜尋會找對。這更像把偵探辦案筆記整理成作業手冊：誰接手都能讀，Agent 也能照著跑。 > **Mogu 想補充：** > > 這裡最重要的轉念是：記憶不是「一坨向量表示」。記憶如果不能被人審、不能被改、不能進版本控制，那在企業工作流裡就很像一個會通靈的黑盒同事。很神，但交接時讓人心臟很痛。 這條線其實接上了 gu-log 前面幾篇同一個問題的不同切面：[GP-191 談 Claude Dreams 怎麼整理 Agent 記憶垃圾山](https://gu-log.vercel.app/posts/gp-191-20260507-danizhu-claude-dreams-agent/)，[GP-135 談為什麼 Agent 應該用檔案系統保存狀態](https://gu-log.vercel.app/posts/gp-135-20260328-trq212-agent-file-system/)，[GP-158 則談生產環境裡怎麼用執行軌跡改進 Agent](https://gu-log.vercel.app/posts/gp-158-20260403-braintrust-agent-production-trace/)。Autobrowse 比較像把這三件事疊在一起：記憶要整理、要落地，還要能從一次次執行裡長出下一次可重用的做法。 ## 沒有海馬迴的天才 原作者用了一個很準的形容：瀏覽器 Agent 像是沒有海馬迴的天才。 海馬迴是大腦裡跟記憶形成很有關的區域。瀏覽器 Agent 在單次工作裡可以很靈活，面對真實網站那些很煩的狀況也能現場處理：不同使用者代理看到不同頁面、內容藏在 JavaScript 後面、真正資料躲在沒文件的 JSON 端點、網站看到陌生連線就丟驗證碼、某個週二突然改版。 通用 Agent 迴圈當下可能都能扛。問題是，這次任務一關，星期一解掉問題的推理就一起蒸發。下次再來，又從零開始。 這種失憶在展示影片裡不明顯，因為展示影片看的是「有沒有完成」。但一進生產環境，真正要看的會變成：「每次完成要花多少錢？要多久？能不能穩定？出了事誰能讀懂？」 如果答案是每次都要重走一遍探索路線，那就像每次去同一家餐廳都重新用 Google 地圖 繞一圈找門口。第一次叫探索，第一百次叫浪費生命。 --- ## 不是再聰明一點，是別再重學一次 Autobrowse 是一個用 AI 改進 AI 的工作流。原作者把它放在類似 [Karpathy](https://gu-log.vercel.app/glossary#andrej-karpathy) 自動研究框架的脈絡裡，只是目標不是研究問題，而是學出更快、更便宜的瀏覽器技能。它不是只叫 Agent 跑一次任務，而是把「跑任務」變成學習迴圈。 流程可以拆成七步。 第一，給 Agent 一個真實目標，例如在 OpenTable 幫某間餐廳訂晚上七點的位置。第二，讓 Agent 用真實瀏覽器從頭到尾嘗試完成。第三，Agent 回頭讀自己的執行軌跡：哪裡卡住、哪裡在猜、哪裡浪費了不必要的 [Token](https://gu-log.vercel.app/glossary#token)。 第四，外層迴圈維護一份 `strategy.md`。這份檔案像操場旁邊的戰術板，記下每次迭代後的觀察：哪些有效、哪些壞掉、下次要試什麼、哪些動作該停止。下一輪開始前，Agent 先讀 `strategy.md`，所以改善會累積，不會每輪都失憶。 第五，根據筆記修策略。沒有貢獻的步驟砍掉；能用確定性工具處理的地方，就改用 `browse fetch`、`browse search` 或客製 Python。第六，當連續幾次迭代在成本或回合數上沒有明顯改善，就提早停止。第七，把最後勝出的流程寫成 `SKILL.md`，連同輔助檔案放進公開技能庫。 原作者說實務上迭代數會壓得很低，大約三到五次，而且會積極提早停止。目標不是追求理論上的全域最佳解，而是找到一條可靠、便宜、足夠重用的路。 這裡有一個很反直覺的經濟學：第一輪貴是故意的。第一輪不是單純在完成任務，而是在付未來所有執行的學費。只要最後產物能被重用，前面花掉的探索成本就有機會攤平。 > **Mogu 插嘴：** > > 這跟「請 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](https://gu-log.vercel.app/glossary#claude-code) 迴圈每次都要重新探索；畢業後的 Autobrowse 技能則明顯壓低單次成本與耗時。本文不重複那些一次性執行的精確美元數與秒數，因為它們比較像內部實驗紀錄，不是公開可重跑基準測試。 原作者強調，重點不是絕對數字，而是形狀。第一次上站成本看起來會像通用 Agent 迴圈該有的成本；但技能一旦形成，後面每次執行都不再重新推導。它直接走 Agent 找到的最短可靠路線。 原作者也提到另一個早期表單填寫實驗：經過少量迭代後，成本大幅下降。靠的不是魔法，而是讓 Agent 看懂自己哪些步驟其實沒有貢獻，然後刪掉。 Craigslist 技能的路線可以濃縮成一句話：不要從最像人的路開始，從最像資料的路開始。 一般瀏覽器 Agent 看到搜尋頁，直覺會像人一樣輸入關鍵字、等畫面更新、讀列表、點下一頁。這條路看起來合理，因為畫面就是網站拿來給人看的介面。問題是，畫面常常不是資料本身，只是資料穿好衣服出來見客。 Autobrowse 學到的路線比較工程一點：先選城市和分類，再打 Craigslist 的搜尋 API，檢查回來的城市範圍對不對，然後解碼每筆貼文，最後組出可用的貼文 URL。分頁也盡量跟著 API 回傳走，不要回去叫瀏覽器慢慢點。 這裡對初學者最容易卡住的點，是那些看起來像低階實作細節的字：`Referer`、`postal`、解碼表、位置陣列、無障礙索引。其實可以先不用背名詞，只要抓住同一件事：**網站會把資料藏在好幾層包裝後面，技能負責記住哪一層才是真的門。** `Referer` 和 `postal` 這類資訊，是在告訴網站「這次搜尋應該算哪個城市」。解碼表是在把網站壓縮過的回傳翻回人看得懂的標題、價格、地點。無障礙索引則提醒 Agent：有些畫面對自動化工具來說是空的，硬點 UI 不如直接抓底下的資料。 這樣講就不會被 Craigslist 的細節淹死。真正重要的是模式：Agent 第一次花力氣把網站摸熟，第二次開始就不要再演偵探劇。技能把「原本要靠踩坑才知道」的細節存下來。下次 Agent 不需要再看著客戶端渲染頁面發呆，不需要再猜為什麼紐約查詢回來是舊金山，也不需要再把位移值當 ID 做出一排 404。 > **Mogu 吐槽時間：** > > 這份 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。結果是幾乎不需要推理成本，就能完整抓出表格。 這件事最後被寫進技能裡： ```bash # 第一步：先用 fetch 試探。 browse fetch "" # 如果資料乾淨回來，就直接寫解析程式。 # 如果回應是空的、動態的，或被關卡擋住，再升級到 Autobrowse。 ``` 這段教訓非常樸素：先 `fetch` 看看。資料乾乾淨淨回來，就寫解析器。回應是空的、動態的、被門禁擋住，再升級到 Autobrowse。 瀏覽器 Agent 其實有不同自主程度。最底層可能只是靜態腳本，沒有 LLM 在迴圈裡；再來是路由式或會用工具的 Agent；最高才是能自動迭代、開工具、甚至叫出其他 Agent 的自治迴圈。選哪一級不是信仰題，是工程決策。 Autobrowse 位在高自主程度那端。高自主工具很強，但也很貴、很會把簡單事搞得像畢業專題。資料就在 HTML 裡時，叫 Autobrowse 反覆探索，真的像派消防車去澆桌上的多肉植物。車來了，水管接好了，多肉也淹死了。 > **Mogu 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](https://gu-log.vercel.app/glossary#prompt)、更好的基本動作選擇先驗、更適合不同任務類型的技能模板。 --- ## 更大的圖像 現在對瀏覽器 Agent 有一種很常見的故事：等底層模型再強一點，某次 Anthropic 或 OpenAI 發表新版本之後，Agent 就會突然在網路上「真的能用」。 Kyle 不完全買單。 就算模型完美，它在每個新網站上還是得發現那些「如果以前來過就該知道」的事情。沒有地方存放學到的東西，每次執行都是重新開始。模型再聰明，也不該每次都重讀同一本迷宮攻略。 Autobrowse 的核心主張因此不是「做一個更聰明的瀏覽器 Agent」，而是「把探索痕跡畢業成可重用技能」。這也是本文最值得帶走的主軸：瀏覽器 Agent 的真正瓶頸，不是只差下一代模型多一點推理，而是缺少一種可審計、可重用、能被人和 Agent 一起讀懂的記憶格式。 這個格式目前看起來意外樸素：Markdown、少量輔助工具、清楚的踩坑提醒、必要時搭配確定性程式碼。 很不炫，但很工程。 ## 結語 Autobrowse 最有意思的地方，不是 Agent 會自己操作瀏覽器。那件事已經不稀奇了。 真正有意思的是，它把一次性的探索變成可以交接的資產。Agent 今天迷路的成本，應該變成明天少走冤枉路的技能；Agent 今天撞到的坑，應該變成下一個人和下一個 Agent 都看得懂的警告牌。 如果瀏覽器 Agent 要進入嚴肅工作流，最後勝出的可能不是最會即興表演的 Agent，而是最會留下工作筆記的 Agent。(๑•̀ㅂ•́)و✧