編譯：Xeriano
編輯：Cage
瀏覽器的使用者正在逐漸從人類使用者轉移到 AI Agent，Agent 與網際網路環境互動的底層設施也因此正在變得越來越重要。傳統瀏覽器無法滿足 AI Agent 自動化抓取、互動和即時資料處理的需求。Browserbase 的創始人 Paul Klein 早在 23 年底就敏銳地洞察到 AI Agent 亟需一個全新的互動載體——一個“為 AI 而生”的雲端瀏覽器。這個瀏覽器不僅要解決現有工具的效能和部署問題，更核心的是要利用 LLM 和 VLM 賦予瀏覽器理解和適應網頁變化的能力，讓 AI Agent 能用更接近自然語言的方式與之互動，穩定地完成任務。
Browserbase 是一家成立一年多的 headless browser 服務提供商，以雲服務的形式為 AI Agent 公司提供 scalable、高可用性的瀏覽器服務。近期，Browserbase 又推出了 StageHand，一種利用 LLM 使得開發者可以用自然語言與網頁進行互動的框架，進一步拓展了其在 headless browser 領域的影響。
本文基於創始人早期備忘錄進行了編譯，詳細闡述了這一技術革新的必要性與可行性。它分析了現有瀏覽器為什麼不夠 AI-native，描繪了利用 LLM 構建新一代 Headless Browser 的藍圖，並探討了如何設計配套的 SDK 和 API 以提供極致的開發者體驗，最終實現大幅降低 AI 與網頁互動的門檻和維護成本的目標。我們編譯的過程中能感受到 Browserbase 這一年多以來的產品實踐和 Stagehand 框架的推出都能和文中的 roadmap 對應上。
💡 目錄 💡
01 目前的瀏覽器無法滿足 AI Agent 需求
02 Browser for AI 市場正在快速增長
03 打造一個更好的 headless browser
04 如何走向市場
05 風險與競爭
06 總結
01.
目前的瀏覽器無法滿足 AI Agent 需求
過去三十年裡，瀏覽器一直是人類與網頁互動的預設方式。人類是視覺主導的生物，更容易透過圖形化介面來使用線上工具。為了滿足使用者日益增長的需求，人們也一直在努力創新，不斷改進網頁開發的流程，來更快地構建新的網站。現在，一個有意思的問題出現了：如果網站的主要使用者並非人類，而是 AI Agent 呢？
根據 Cloudflare 的資料，網際網路上已經有超過 40% 的流量來自其他計算機，也就是我們常說的 bots。由於網際網路擁有海量資訊，這些勤奮的 bots 會不斷抓取（Scraping）其中最有價值的部分。之所以需要抓取資料，是因為很多網站並未提供結構化資料的公開 API 介面，導致機器人不得不像人類一樣，直接在網站上瀏覽和獲取資訊。
一些基於大型語言模型的 AI Agent 展示了模型自主完成任務的能力，它們也會像人類使用者一樣，透過瀏覽網站來執行具體任務。試想一下，你的個人 AI 助手能夠自己開啟航空公司網站，透過聊天視窗幫你重新預訂航班。在缺少 API 的世界裡，網站就成了獲取資訊和互動的主要入口。
正是由於 bots 日益普遍、資料抓取的需求不斷增加，以及需要透過訪問瀏覽器執行任務的 AI Agent 的興起，我們不禁想問：開發者目前是如何構建網路資料自動化解析工具的呢？
問題1：Scraping 並不簡單
Scraping 真正有趣的地方在於：可以採取一種簡單直接的方法，也可以深入構建一個強大的解決方案。當開發者從網站抓取資料時，他們通常會模仿瀏覽器，直接對目標網址發起一個簡單的 HTTP 請求，例如：
這條簡單的命令確實能從 Airbnb 的網站獲取資料，但現實中有不少額外的問題。
現代網站通常不會在首次請求中就載入全部內容，必須等待頁面上的指令碼執行，以動態載入所需的資料。為了執行這些指令碼，需要模擬一個完整的瀏覽器環境，以便指令碼能夠順利呼叫所需的瀏覽器 API。
Airbnb.com 在初始頁面載入後逐步載入資料
有時候想要的資料並不直接透過公開的 URL 獲取，而是需要與頁面進行互動，例如點選連結、輸入資訊並導航到相應位置。這種情況下需要實現頁面互動的自動化。
電子郵件框擋住了文章內容從而無法直接抓取內容
此外，一些網站能夠識別 Scraping 行為，並透過驗證碼（CAPTCHA）來阻止訪問。要繞過這些檢測機制，通常需要傳送特定的 HTTP 頭資訊，模仿正常瀏覽器的行為，偽裝自己的請求。
網站監測到了爬蟲並要求輸入驗證碼
即便順利訪問到了網頁，下一步還得解析資料。然而，由於現代網頁的結構往往十分複雜，開發過程中生成的頁面標籤也難以預測，且可能在每次開發者重新編譯頁面時發生變化，因此想要準確提取資料並非易事。
網頁中複雜結構的示例
這些困難幾乎讓開發者很難僅憑內建工具就構建出有效的 Scraping 流程。而令人意外的是，最好的工具其實正是他們每天都會用到的——瀏覽器。
問題2：現有的 headless browser 不 AI-native
headless browser 是一種完全透過程式碼控制執行的瀏覽器，是做 scraping 最好的基礎設施之一。這類瀏覽器並不會開啟圖形化介面（GUI）並渲染視窗，而是直接在記憶體中完成所有操作。這是因為計算機只能讀取，而不需要“看到”，因此在抓取資料時無需實際渲染頁面。
有頭瀏覽器和無頭瀏覽器的對比
目前，已有一些流行的 headless browser 庫，其中最主流的是谷歌的 Puppeteer 和微軟的 Playwright。兩者都提供了對瀏覽器 API 的全面訪問，廣泛應用於各種場景。
一個建立 Airbnb 賬戶的 Puppeteer 函式
程式設計師透過 headless browser 與網站互動的主要方式是使用 CSS 選擇器。正如上述示例所展示的，選擇器用來確定頁面上哪些元素可見，在哪輸入資訊，以及需要點選的位置。然而，CSS 選擇器是無型別的純文字，因此開發者無法享受現代強型別語言在編譯階段就捕捉錯誤的好處，使得開發過程更加脆弱和容易出錯。此外，定義這些互動流程十分繁瑣，因為選擇器極其脆弱。一旦頁面結構稍有變化，之前建立的流程就會崩潰。如果任一步驟順序出現偏差，整個過程都會中斷。此外，要判斷頁面是否載入完成，通常需要等待網路請求結束，這種模式意味著大量的等待時間。
除了語言本身的複雜性之外，可程式設計瀏覽器庫本身也存在冗餘臃腫的問題。以 Puppeteer 為例，在 Linux 上安裝時需要高達 282MB 的依賴，這個體積是非常巨大的。作為參考，AWS Lambda 服務的最大部署大小僅為 250MB，意味著使用者不得不採取其他解決方案。類似的問題也同樣出現在 Playwright 身上。
造成如此龐大依賴體積的直接原因是 Puppeteer 執行時需要整個瀏覽器環境，導致它攜帶了大量實際程式碼中用不到的功能。
需要強調的是，這些已經是當前最流行的 headless browser 庫了。儘管它們位於諸多重要工作流程的核心，但仍然存在各種不便和痛點，導致開發體驗並不理想。
02.
Browser for AI 市場
正在快速增長
大型語言模型的知識範圍受到訓練資料的限制，因此往往依靠瀏覽器來獲取最新的知識。當前主要有兩種技術途徑實現這一目標：
第一種方法是 RAG。LLMs 會先透過瀏覽器獲取資訊，然後將這些資訊作為額外的上下文，補充到 prompt中。這種額外的上下文能夠幫助 LLMs 給出更精準的回答。
另一種方法則是基於 Plugins/Web Agents 的正規化。一些應用向 LLMs 提供一個瀏覽器介面，當 LLMs 接收到需要聯網執行的任務時，會自主呼叫該瀏覽器介面，自動地完成頁面導航、資料解析等操作，直至完成使用者交代的任務。
除了 ChatGPT 以外，目前其他主流的 LLMs 編排框架也已集成了瀏覽器自動化功能。Langchain 作為當前廣泛使用的框架，提供了一個基礎的 Web Browser 外掛，使用的正是前面提到的 Scraping 方法。同時，Langchain 也與Browserless 有專門的整合，用於更高效、更穩定的 Scraping。
近期，OpenAI 知名研究員 Andrej Karpathy 描述了一種不久之後可能出現的“LLM作業系統”。在他給出的系統圖中，可以清晰地看到：瀏覽器與檔案系統、向量資料庫（embeddings/vector databases）並列，成為LLM的核心基礎元件之一。這一點明確顯示出瀏覽器對於 LLMs 的重要性，尤其是隨著 LLMs 使用外部工具能力的不斷增強，這種趨勢只會越來越明顯。
Andrej Karpathy 在 Youtube 影片中給出的 LLM OS 的結構
當前的 Scraping 和瀏覽器自動化市場已經非常可觀。從 NPM 下載資料來看，Puppeteer 這個庫的增長規模已經與 Next.js 相當，後者是 Vercel 旗下非常流行的網頁框架。
透過 NPM 的每週下載量
可作為參考的上市公司是 UIPath，這家公司專注於 RPA 軟體開發，幫助企業自動執行各種常規業務任務。UiPath 今年的營收預計將超過 10 億美元，充分體現了 AI 驅動的任務自動化所蘊含的巨大市場潛力。然而，其瀏覽器自動化工具本身的吸引力則相對遜色。
目前，這一領域的初創公司已經吸引了諸多財富 500 強企業的關注，這顯示出企業市場對瀏覽器自動化工具的強烈需求。
使用 ScrapingBee 的一些客戶
此外，還有幾個重要的趨勢將進一步推動瀏覽器自動化工具的快速普及：
• 訓練新的基礎模型，需要大規模的資料抓取。
• 資料所有方（例如Wikipedia、Reddit、StackOverflow）希望更好地維護資料的商業價值，這將使資料抓取變得更復雜，從而要求更強大的瀏覽器自動化工具。
• 一批公司將透過 Web Agents 實現自動化地與網站互動，這種功能可能成為這些公司產品的特色甚至其主要的業務方向。
• 現有的 SaaS 公司可能會增加一些基於AI的功能，而這些功能將依賴瀏覽器自動化來實現。
• 許多傳統網站無法提供足夠的 API 來獲取資料，因此長期來看，瀏覽器自動化將成為唯一的解決方案。
03.
打造一個更好的
headless browser
回顧一下此前提到的目前 headless browser 存在的問題：
• 現有的瀏覽器自動化庫臃腫，效能未得到最佳化。
• 在現代雲環境中的部署流程過於複雜。
• 現有的指令碼語言構建的整合方案非常脆弱，經常出現故障。
• 指令碼通常依賴設定任意的等待時間，容易出錯且效率低下。
• 從頁面解析資料的過程繁瑣，往往需要大量試錯。
簡單來說，開發者們真正想要的是一個性能更強、可靠性更高、且使用更簡便的瀏覽器自動化方案。我在閱讀了許多開發者的反饋意見後，可以清晰地看到開發者們同樣迫切地希望擁有一個更出色的瀏覽器自動化平臺。
有三個關鍵的創新點可以實現一個性能更佳、雲原生、以 AI 為核心的下一代瀏覽器自動化平臺：
1. 打造一個開源的、高度最佳化的 headless browser
我們不應再容忍緩慢的冷啟動和臃腫的依賴包。
2. 用 AI 賦予瀏覽器“超能力”
不再強迫開發者手動構建複雜的頁面解析樹，而是透過 LLMs 高效地定位頁面中的資訊，即使網頁結構發生變化，也能快速找到資料。使用 GPT-4V 這類視覺模型，直接基於截圖識別頁面元素，而不是傳統的程式碼解析。開發者可以直觀地詢問：“頁面載入完成了嗎？”或“登入按鈕是否可見？”，而無需複雜的技巧或猜測。訪問被混淆或隱藏的資訊，比如網站為了防止抓取而將價格資訊藏在圖片裡，而非文字中。
3. 提供全新層次的介面，給開發者帶來極致的體驗
從根本上重新設計 SDK，因為當前的流程化介面對處理複雜的重試和分支操作不夠友好。但是，為保證遷移平滑，應同時保持與 Puppeteer 介面的相容性。讓開發者能夠充分利用最新的“AI 原生”創新技術。不過，傳統方法有時可能更高效，因此開發者可以靈活選擇最適合其使用場景的方案。一個出色的平臺還需要提供強大的 API，方便開發者輕鬆管理底層的瀏覽器基礎設施，全面提升使用者體驗。
*譯者注：站在 2025 年回看的 browserbase ，我們會發現其發展歷程與創始人提出的策略三大策略是吻合的，browserbase 透過其開源策略迅速打開了市場，並在 2024 年底釋出了 StageHand，一種利用 LLM 將自然語言指令轉換成 Playwright 程式碼從而操縱 headless browser 的開源框架，使得開發者可以用自然語言與網頁進行互動，而不再需要手動解析複雜的網頁結構並進行維護，大幅降低了 AI Agent 聯網的成本。
開發者使用自然語言與 Stagehand 互動，
Stagehand 則將自然語言轉換成 Playwright 程式碼並透過 Browserbase 呼叫瀏覽器
04.
如何走向市場
如 a16z 合夥人 Alex Rampell 所說：“每家初創公司與現有巨頭之間的競爭，本質上就是看創業公司能否在巨頭實現創新之前，搶先獲得市場分發。”
如果沒有強有力的 GTM 策略就無法獲得成功，“首次創業的人痴迷於產品，二次創業的人則專注於分發。”針對開發者工具類產品，最有效的分發策略如下：
• 打造一流的產品
• 透過開源投資於社群
• 建立值得信賴的品牌
• 教育並賦能開發者
其中最重要的一點是，產品必須卓越。無論多精美的包裝或漂亮的落地頁，都無法彌補產品本質上的不足。只有真正過硬的產品才能抓住當前市場中的巨大機會。
投資於社群，意味著在獲取價值的同時也回饋社群。現有瀏覽器庫大多為開源模式，新的產品也應該如此。開源是一個極佳的分發渠道，將出色的軟體免費提供出去，開發者自然更願意體驗你的產品，並逐步轉化為付費使用者。
在開發者工具領域，建立良好品牌的重要性不容忽視，甚至可以與產品質量本身並列。口碑傳播是開發者工具公司最有效的渠道，其次才是自然搜尋流量。
想要真正吸引開發者，就必須去他們所在的地方與他們互動。如果大量精力投入在吸引使用者上，卻沒有精心撰寫優秀的文件，或缺乏適合開發者語言的 SDK，那之前所有的努力都是徒勞。這些投入會直接推動口碑傳播——最好的讚賞莫過於“你看過這家初創公司的文件嗎？真的太棒了！”
因為現有的瀏覽器自動化流程經常出錯，這為新產品提供了大量機會。開發者在處理原本正常執行的程式碼突然失效時，正是他們最容易轉向其他更穩定工具的時機。這種情景對開發者工具來說相當罕見，因為多數情況下這些工具都是“一次配置好，後續無需再關注”。
擁有一個被社群積極認可的可信品牌本身就是一道壁壘，尤其當開發者開始積極貢獻開源核心產品的程式碼時。避免成為 commodity 的最佳方式，就是成為開發者群體的預設選擇，而優秀的開源專案正是實現這一目標的關鍵。
由於開發者工具領域的絕大部分收入通常來自市場頂端的 20% 使用者，因此自下而上的市場拓展策略（Bottoms-up GTM）更多是為增強口碑傳播，從而長期開啟企業級客戶的收入大門。
最後，隨著核心業務的成功，公司也擁有大量向外擴充套件的機會，比如：
• 將抓取的資料儲存服務打包提供，並開放統一的查詢 API；
• 支援使用者資料持久化，加速任務完成；
• 建立社群化的工作流市場（例如從 McMaster-Carr 訂購特殊螺絲的自動化流程）。
儘管個人更傾向於橫向平臺模式，但短期內，將自身定位成一個統一的傳統資料來源 API 平臺，也可能更快地捕獲市場價值。這樣一來，很多此前無法實現的自動化流程，都可以直接基於該平臺構建和執行。
05.
風險與競爭
Browser for AI 的 6 個風險
風險1：在已有市場中成為預設選擇非常困難
策略：
用全新正規化顛覆市場，使初創公司能夠對市場進行細分，從而找到適合切入的空間。
參考案例：
Heroku (已有的領軍企業) vs Vercel (新晉的創業公司)：Heroku 提供全面的 PaaS 解決方案，而 Vercel 透過無伺服器和前端優先的正規化，專注於現代 JavaScript 開發者的細分需求。
Mailgun (已有的領軍企業) vs Resend (新晉的創業公司)：Mailgun 是功能強大的郵件基礎設施領導者，而 Resend 以開發者體驗和設計驅動的服務，瞄準現代技術棧使用者的特定市場。
風險2：瀏覽器自動化可能與客戶的核心產品深度繫結，客戶可能不願外包
反駁觀點：
如果一個功能足夠重要且具備足夠的複雜度，客戶如果堅持自主開發將面臨巨大成本，這種情況下外購是更合理的選擇。這實際上是典型的“自建 vs 購買”問題。
風險3：LLMs 推理成本太高，可能導致很多使用場景成本過於昂貴
反駁觀點：
LLMs 的推理成本在長期趨勢上很可能會持續下降。
策略：
將 LLMs 的相關功能設計為可選模式，讓客戶能夠自主控制成本，從而支援更廣泛的應用場景。
風險4：這類基礎設施產品容易商品化，利潤率面臨持續壓縮的壓力
策略：
如果可能的話，重新設計創新性的定價策略。例如不再按會話數收費，而可能按照吞吐量收費。
成為基礎設施意味著需要非常小心控制單位成本。
風險5：濫用與法律合規風險
反駁觀點：
截至 2022 年，根據美國第九巡迴上訴法院的裁定，Scraping 行為是合法的。
此外，AI 領域的技術創新也使得識別濫用行為變得比過去容易百倍。
風險6：如果大公司（如 OpenAI、Google 等）自己開發此類產品怎麼辦？
反駁觀點：
本質上，LLMs 本身無法直接內建瀏覽器功能，因為瀏覽器屬於單獨的技術領域。OpenAI 等公司不太可能將瀏覽器與 GPT API 直接捆綁，因為這將引入額外的複雜性（例如計費或技術對接）。
即便 OpenAI 等公司開始整合類似功能，開發者仍然需要大量定製化的配置，以滿足具體應用需求。
個人助理的使用場景可能最終由蘋果或谷歌等巨頭主導，他們會為最常用的服務提供原生整合介面。
但日常生活中頻繁接觸的大量中小型商家（比如街角的麵包店或理髮店）不可能提供原生 API 介面，因此這些場景仍然需要依靠瀏覽器自動化實現。
Browser for AI 的 3 類競爭對手
與向量資料庫領域相比，瀏覽器自動化這一基礎元件在風險投資市場中的資金投入明顯不足。現有的公司大多是自籌資金（bootstrap）起步，或融資金額低於500 萬美元。而獲得大額融資的公司多數並未真正服務於構建相關應用的開發者群體。
本文將現有的初創公司劃分為三大類別：瀏覽器自動化、Scraping API 和 資訊檢索 API。
瀏覽器自動化
Browserless
• Browserless是該領域最接近龍頭位置的公司，在市場滲透率和開發者中的品牌認可度都很不錯。
• 它的本質是遠端託管的 Puppeteer，核心創新主要集中在基礎設施層，而非SDK層。
• 團隊規模較小，最近被一家新 buyout fund 收購。
Browse.ai
• 一家獲得風投支援的公司，但主要偏向消費者市場或低程式碼使用者群。
• 它提供的“Website to API”功能非常有吸引力。
Induced.ai
• 已融資 230 萬美元種子輪，專注於企業 RPA 和專業消費者市場。
Scraping APIs
這些公司提供一個 URL 介面，然後返回通常為非結構化的資料。這些 API 公司通常還提供一些額外的功能，例如繞過 CAPTCHA 驗證或使用代理服務（proxy）。
• ScrapingBee
• WebScrapingAPI
• ScraperAPI
資訊檢索APIs
這類初創公司更專注於特定資訊的搜尋和檢索服務，而非通用的瀏覽器自動化。
• Metaphor Systems
• SerpAPI
未來行業內頂尖公司的產品應該同時吸取上述三類公司的特點和優勢。目前看來，沒有任何一家現有公司處於絕對領先地位，市場中真正最大的競爭對手反而是自己構建方案的開發者。
06.
總結
• 可預見的未來，Scraping 依然會是長期存在的需求。
• 網際網路本質上是不確定的，但我們目前仍在用確定性的工具來應對它。
• 瀏覽器自動化這個基礎元件長期以來缺乏足夠的投資，而 AI 應用在未來很多年都將高度依賴這一能力。
• 市場上存在大量 AI 和非 AI 的使用場景，這為新興創業公司提供了難得的顛覆機會。
• 能夠把握住這個機會的創始人，通常具有深厚的 headless browser 技術背景、開發者工具經驗，以及對 AI 領域的熱情與洞察力。
排版：Doro
延伸閱讀
