文章轉載自「海外獨角獸」。

瀏覽器的使用者正在逐漸從人類用戶轉移到 ，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 對應上。

Founder Park 正在搭建開發者社群，邀請積極嘗試、測試新模型、新技術的開發者、創業者們加入，請掃碼詳細填寫你的產品/項目信息，通過審核后工作人員會拉你入群～

進群之后，你有機會得到：

• 高濃度的主流模型（如 DeepSeek 等）開發交流；

• 資源對接，與 API、云廠商、模型廠商直接交流反饋的機會；

• 好用、有趣的產品/案例，Founder Park 會主動做宣傳。

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 庫了。盡管它們位于諸多重要工作流程的核心，但仍然存在各種不便和痛點，導致開發體驗并不理想。

02Browser 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 (新晉的創業公司)：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 領域的熱情與洞察力。

轉載原創文章請添加微信：founderparker