傳統(tǒng)的瀏覽器設(shè)計主要是為了滿足人類用戶的交互需求，其功能和性能在很大程度上無法適應(yīng)AI Agent自動化抓取、交互和實時數(shù)據(jù)處理的復(fù)雜需求。本文深入探討了為什么現(xiàn)有的瀏覽器無法滿足AI Agent的需求，以及如何構(gòu)建一個全新的、專為AI設(shè)計的瀏覽器來解決這些問題。

瀏覽器的使用者正在逐漸從人類用戶轉(zhuǎn)移到 AI Agent，Agent 與互聯(lián)網(wǎng)環(huán)境互動的底層設(shè)施也因此正在變得越來越重要。傳統(tǒng)瀏覽器無法滿足 AI Agent 自動化抓取、交互和實時數(shù)據(jù)處理的需求。Browserbase 的創(chuàng)始人 Paul Klein 早在 23 年底就敏銳地洞察到 AI Agent 亟需一個全新的交互載體——一個“為 AI 而生”的云端瀏覽器。這個瀏覽器不僅要解決現(xiàn)有工具的性能和部署問題，更核心的是要利用 LLM 和 VLM 賦予瀏覽器理解和適應(yīng)網(wǎng)頁變化的能力，讓 AI Agent 能用更接近自然語言的方式與之交互，穩(wěn)定地完成任務(wù)。

Browserbase 是一家成立一年多的 headless browser 服務(wù)提供商，以云服務(wù)的形式為 AI Agent 公司提供 scalable、高可用性的瀏覽器服務(wù)。近期，Browserbase 又推出了 StageHand，一種利用 LLM 使得開發(fā)者可以用自然語言與網(wǎng)頁進行交互的框架，進一步拓展了其在 headless browser 領(lǐng)域的影響。

本文基于創(chuàng)始人早期備忘錄進行了編譯，詳細闡述了這一技術(shù)革新的必要性與可行性。它分析了現(xiàn)有瀏覽器為什么不夠 AI-native，描繪了利用 LLM 構(gòu)建新一代 Headless Browser 的藍圖，并探討了如何設(shè)計配套的 SDK 和 API 以提供極致的開發(fā)者體驗，最終實現(xiàn)大幅降低 AI 與網(wǎng)頁交互的門檻和維護成本的目標。我們編譯的過程中能感受到 Browserbase 這一年多以來的產(chǎn)品實踐和 Stagehand 框架的推出都能和文中的 roadmap 對應(yīng)上。

?? 目錄 ??

 01 目前的瀏覽器無法滿足 AI Agent 需求

 02 Browser for AI 市場正在快速增長

 03 打造一個更好的 headless browser

 04 如何走向市場

 05 風(fēng)險與競爭

 06 總結(jié)

01.目前的瀏覽器無法滿足 AI Agent 需求

過去三十年里，瀏覽器一直是人類與網(wǎng)頁交互的默認方式。人類是視覺主導(dǎo)的生物，更容易通過圖形化界面來使用線上工具。為了滿足用戶日益增長的需求，人們也一直在努力創(chuàng)新，不斷改進網(wǎng)頁開發(fā)的流程，來更快地構(gòu)建新的網(wǎng)站。現(xiàn)在，一個有意思的問題出現(xiàn)了：如果網(wǎng)站的主要用戶并非人類，而是 AI Agent 呢？

根據(jù) Cloudflare 的數(shù)據(jù)，互聯(lián)網(wǎng)上已經(jīng)有超過 40% 的流量來自其他計算機，也就是我們常說的 bots。由于互聯(lián)網(wǎng)擁有海量信息，這些勤奮的 bots 會不斷抓?。⊿craping）其中最有價值的部分。之所以需要抓取數(shù)據(jù)，是因為很多網(wǎng)站并未提供結(jié)構(gòu)化數(shù)據(jù)的公開 API 接口，導(dǎo)致機器人不得不像人類一樣，直接在網(wǎng)站上瀏覽和獲取信息。

一些基于大型語言模型的 AI Agent 展示了模型自主完成任務(wù)的能力，它們也會像人類用戶一樣，通過瀏覽網(wǎng)站來執(zhí)行具體任務(wù)。試想一下，你的個人 AI 助手能夠自己打開航空公司網(wǎng)站，通過聊天窗口幫你重新預(yù)訂航班。在缺少 API 的世界里，網(wǎng)站就成了獲取信息和交互的主要入口。

正是由于 bots 日益普遍、數(shù)據(jù)抓取的需求不斷增加，以及需要通過訪問瀏覽器執(zhí)行任務(wù)的 AI Agent 的興起，我們不禁想問：開發(fā)者目前是如何構(gòu)建網(wǎng)絡(luò)數(shù)據(jù)自動化解析工具的呢？

問題1：Scraping 并不簡單

Scraping 真正有趣的地方在于：可以采取一種簡單直接的方法，也可以深入構(gòu)建一個強大的解決方案。當(dāng)開發(fā)者從網(wǎng)站抓取數(shù)據(jù)時，他們通常會模仿瀏覽器，直接對目標網(wǎng)址發(fā)起一個簡單的 HTTP 請求，例如：

這條簡單的命令確實能從 Airbnb 的網(wǎng)站獲取數(shù)據(jù)，但現(xiàn)實中有不少額外的問題。

現(xiàn)代網(wǎng)站通常不會在首次請求中就加載全部內(nèi)容，必須等待頁面上的腳本運行，以動態(tài)加載所需的數(shù)據(jù)。為了執(zhí)行這些腳本，需要模擬一個完整的瀏覽器環(huán)境，以便腳本能夠順利調(diào)用所需的瀏覽器 API。

Airbnb.com 在初始頁面加載后逐步加載數(shù)據(jù)

有時候想要的數(shù)據(jù)并不直接通過公開的 URL 獲取，而是需要與頁面進行交互，例如點擊鏈接、輸入信息并導(dǎo)航到相應(yīng)位置。這種情況下需要實現(xiàn)頁面交互的自動化。

電子郵件框擋住了文章內(nèi)容從而無法直接抓取內(nèi)容

此外，一些網(wǎng)站能夠識別 Scraping 行為，并通過驗證碼（CAPTCHA）來阻止訪問。要繞過這些檢測機制，通常需要發(fā)送特定的 HTTP 頭信息，模仿正常瀏覽器的行為，偽裝自己的請求。

網(wǎng)站監(jiān)測到了爬蟲并要求輸入驗證碼

即便順利訪問到了網(wǎng)頁，下一步還得解析數(shù)據(jù)。然而，由于現(xiàn)代網(wǎng)頁的結(jié)構(gòu)往往十分復(fù)雜，開發(fā)過程中生成的頁面標簽也難以預(yù)測，且可能在每次開發(fā)者重新編譯頁面時發(fā)生變化，因此想要準確提取數(shù)據(jù)并非易事。

網(wǎng)頁中復(fù)雜結(jié)構(gòu)的示例

這些困難幾乎讓開發(fā)者很難僅憑內(nèi)置工具就構(gòu)建出有效的 Scraping 流程。而令人意外的是，最好的工具其實正是他們每天都會用到的——瀏覽器。

問題2：現(xiàn)有的 headless browser 不 AI-native

headless browser 是一種完全通過代碼控制運行的瀏覽器，是做 scraping 最好的基礎(chǔ)設(shè)施之一。這類瀏覽器并不會打開圖形化界面（GUI）并渲染窗口，而是直接在內(nèi)存中完成所有操作。這是因為計算機只能讀取，而不需要“看到”，因此在抓取數(shù)據(jù)時無需實際渲染頁面。

有頭瀏覽器和無頭瀏覽器的對比

目前，已有一些流行的 headless browser 庫，其中最主流的是谷歌的 Puppeteer 和微軟的 Playwright。兩者都提供了對瀏覽器 API 的全面訪問，廣泛應(yīng)用于各種場景。

一個創(chuàng)建 Airbnb 賬戶的 Puppeteer 函數(shù)

程序員通過 headless browser 與網(wǎng)站交互的主要方式是使用 CSS 選擇器。正如上述示例所展示的，選擇器用來確定頁面上哪些元素可見，在哪輸入信息，以及需要點擊的位置。然而，CSS 選擇器是無類型的純文本，因此開發(fā)者無法享受現(xiàn)代強類型語言在編譯階段就捕捉錯誤的好處，使得開發(fā)過程更加脆弱和容易出錯。此外，定義這些交互流程十分繁瑣，因為選擇器極其脆弱。一旦頁面結(jié)構(gòu)稍有變化，之前建立的流程就會崩潰。如果任一步驟順序出現(xiàn)偏差，整個過程都會中斷。此外，要判斷頁面是否加載完成，通常需要等待網(wǎng)絡(luò)請求結(jié)束，這種模式意味著大量的等待時間。

除了語言本身的復(fù)雜性之外，可編程瀏覽器庫本身也存在冗余臃腫的問題。以 Puppeteer 為例，在 Linux 上安裝時需要高達 282MB 的依賴，這個體積是非常巨大的。作為參考，AWS Lambda 服務(wù)的最大部署大小僅為 250MB，意味著用戶不得不采取其他解決方案。類似的問題也同樣出現(xiàn)在 Playwright 身上。

造成如此龐大依賴體積的直接原因是 Puppeteer 運行時需要整個瀏覽器環(huán)境，導(dǎo)致它攜帶了大量實際代碼中用不到的功能。

需要強調(diào)的是，這些已經(jīng)是當(dāng)前最流行的 headless browser 庫了。盡管它們位于諸多重要工作流程的核心，但仍然存在各種不便和痛點，導(dǎo)致開發(fā)體驗并不理想。

02.Browser for AI 市場正在快速增長

大型語言模型的知識范圍受到訓(xùn)練數(shù)據(jù)的限制，因此往往依靠瀏覽器來獲取最新的知識。當(dāng)前主要有兩種技術(shù)途徑實現(xiàn)這一目標：

第一種方法是 RAG。LLMs 會先通過瀏覽器獲取信息，然后將這些信息作為額外的上下文，補充到 prompt中。這種額外的上下文能夠幫助 LLMs 給出更精準的回答。

另一種方法則是基于 Plugins/Web Agents 的范式。一些應(yīng)用向 LLMs 提供一個瀏覽器接口，當(dāng) LLMs 接收到需要聯(lián)網(wǎng)執(zhí)行的任務(wù)時，會自主調(diào)用該瀏覽器接口，自動地完成頁面導(dǎo)航、數(shù)據(jù)解析等操作，直至完成用戶交代的任務(wù)。

除了 ChatGPT 以外，目前其他主流的 LLMs 編排框架也已集成了瀏覽器自動化功能。Langchain 作為當(dāng)前廣泛使用的框架，提供了一個基礎(chǔ)的 Web Browser 插件，使用的正是前面提到的 Scraping 方法。同時，Langchain 也與Browserless 有專門的集成，用于更高效、更穩(wěn)定的 Scraping。

近期，OpenAI 知名研究員 Andrej Karpathy 描述了一種不久之后可能出現(xiàn)的“LLM操作系統(tǒng)”。在他給出的系統(tǒng)圖中，可以清晰地看到：瀏覽器與文件系統(tǒng)、向量數(shù)據(jù)庫（embeddings/vector databases）并列，成為LLM的核心基礎(chǔ)組件之一。這一點明確顯示出瀏覽器對于 LLMs 的重要性，尤其是隨著 LLMs 使用外部工具能力的不斷增強，這種趨勢只會越來越明顯。

Andrej Karpathy 在 Youtube 視頻中給出的 LLM OS 的結(jié)構(gòu)

當(dāng)前的 Scraping 和瀏覽器自動化市場已經(jīng)非?？捎^。從 NPM 下載數(shù)據(jù)來看，Puppeteer 這個庫的增長規(guī)模已經(jīng)與 Next.js 相當(dāng)，后者是 Vercel 旗下非常流行的網(wǎng)頁框架。

通過 NPM 的每周下載量

可作為參考的上市公司是 UIPath，這家公司專注于 RPA 軟件開發(fā)，幫助企業(yè)自動執(zhí)行各種常規(guī)業(yè)務(wù)任務(wù)。UiPath 今年的營收預(yù)計將超過 10 億美元，充分體現(xiàn)了 AI 驅(qū)動的任務(wù)自動化所蘊含的巨大市場潛力。然而，其瀏覽器自動化工具本身的吸引力則相對遜色。

目前，這一領(lǐng)域的初創(chuàng)公司已經(jīng)吸引了諸多財富 500 強企業(yè)的關(guān)注，這顯示出企業(yè)市場對瀏覽器自動化工具的強烈需求。

使用 ScrapingBee 的一些客戶

此外，還有幾個重要的趨勢將進一步推動瀏覽器自動化工具的快速普及：

? 訓(xùn)練新的基礎(chǔ)模型，需要大規(guī)模的數(shù)據(jù)抓取。

? 數(shù)據(jù)所有方（例如Wikipedia、Reddit、StackOverflow）希望更好地維護數(shù)據(jù)的商業(yè)價值，這將使數(shù)據(jù)抓取變得更復(fù)雜，從而要求更強大的瀏覽器自動化工具。

? 一批公司將通過 Web Agents 實現(xiàn)自動化地與網(wǎng)站交互，這種功能可能成為這些公司產(chǎn)品的特色甚至其主要的業(yè)務(wù)方向。

? 現(xiàn)有的 SaaS 公司可能會增加一些基于AI的功能，而這些功能將依賴瀏覽器自動化來實現(xiàn)。

? 許多傳統(tǒng)網(wǎng)站無法提供足夠的 API 來獲取數(shù)據(jù)，因此長期來看，瀏覽器自動化將成為唯一的解決方案。

03.打造一個更好的 headless browser

回顧一下此前提到的目前 headless browser 存在的問題：

? 現(xiàn)有的瀏覽器自動化庫臃腫，性能未得到優(yōu)化。

? 在現(xiàn)代云環(huán)境中的部署流程過于復(fù)雜。

? 現(xiàn)有的腳本語言構(gòu)建的集成方案非常脆弱，經(jīng)常出現(xiàn)故障。

? 腳本通常依賴設(shè)置任意的等待時間，容易出錯且效率低下。

? 從頁面解析數(shù)據(jù)的過程繁瑣，往往需要大量試錯。

簡單來說，開發(fā)者們真正想要的是一個性能更強、可靠性更高、且使用更簡便的瀏覽器自動化方案。我在閱讀了許多開發(fā)者的反饋意見后，可以清晰地看到開發(fā)者們同樣迫切地希望擁有一個更出色的瀏覽器自動化平臺。

有三個關(guān)鍵的創(chuàng)新點可以實現(xiàn)一個性能更佳、云原生、以 AI 為核心的下一代瀏覽器自動化平臺：

1. 打造一個開源的、高度優(yōu)化的 headless browser

我們不應(yīng)再容忍緩慢的冷啟動和臃腫的依賴包。

2. 用 AI 賦予瀏覽器“超能力”

不再強迫開發(fā)者手動構(gòu)建復(fù)雜的頁面解析樹，而是通過 LLMs 高效地定位頁面中的信息，即使網(wǎng)頁結(jié)構(gòu)發(fā)生變化，也能快速找到數(shù)據(jù)。使用 GPT-4V 這類視覺模型，直接基于截圖識別頁面元素，而不是傳統(tǒng)的代碼解析。開發(fā)者可以直觀地詢問：“頁面加載完成了嗎？”或“登錄按鈕是否可見？”，而無需復(fù)雜的技巧或猜測。訪問被混淆或隱藏的信息，比如網(wǎng)站為了防止抓取而將價格信息藏在圖片里，而非文本中。

3. 提供全新層次的接口，給開發(fā)者帶來極致的體驗

從根本上重新設(shè)計 SDK，因為當(dāng)前的流程化接口對處理復(fù)雜的重試和分支操作不夠友好。但是，為保證遷移平滑，應(yīng)同時保持與 Puppeteer 接口的兼容性。讓開發(fā)者能夠充分利用最新的“AI 原生”創(chuàng)新技術(shù)。不過，傳統(tǒng)方法有時可能更高效，因此開發(fā)者可以靈活選擇最適合其使用場景的方案。一個出色的平臺還需要提供強大的 API，方便開發(fā)者輕松管理底層的瀏覽器基礎(chǔ)設(shè)施，全面提升用戶體驗。

*譯者注：站在 2025 年回看的 browserbase ，我們會發(fā)現(xiàn)其發(fā)展歷程與創(chuàng)始人提出的策略三大策略是吻合的，browserbase 通過其開源策略迅速打開了市場，并在 2024 年底發(fā)布了 StageHand，一種利用 LLM 將自然語言指令轉(zhuǎn)換成 Playwright 代碼從而操縱 headless browser 的開源框架，使得開發(fā)者可以用自然語言與網(wǎng)頁進行交互，而不再需要手動解析復(fù)雜的網(wǎng)頁結(jié)構(gòu)并進行維護，大幅降低了 AI Agent 聯(lián)網(wǎng)的成本。

開發(fā)者使用自然語言與 Stagehand 交互，Stagehand 則將自然語言轉(zhuǎn)換成 Playwright 代碼并通過 Browserbase 調(diào)用瀏覽器

04.如何走向市場

如 a16z 合伙人 Alex Rampell 所說：“每家初創(chuàng)公司與現(xiàn)有巨頭之間的競爭，本質(zhì)上就是看創(chuàng)業(yè)公司能否在巨頭實現(xiàn)創(chuàng)新之前，搶先獲得市場分發(fā)?！?/p>

如果沒有強有力的 GTM 策略就無法獲得成功，“首次創(chuàng)業(yè)的人癡迷于產(chǎn)品，二次創(chuàng)業(yè)的人則專注于分發(fā)?！贬槍﹂_發(fā)者工具類產(chǎn)品，最有效的分發(fā)策略如下：

? 打造一流的產(chǎn)品

? 通過開源投資于社區(qū)

? 建立值得信賴的品牌

? 教育并賦能開發(fā)者

其中最重要的一點是，產(chǎn)品必須卓越。無論多精美的包裝或漂亮的落地頁，都無法彌補產(chǎn)品本質(zhì)上的不足。只有真正過硬的產(chǎn)品才能抓住當(dāng)前市場中的巨大機會。

投資于社區(qū)，意味著在獲取價值的同時也回饋社區(qū)?，F(xiàn)有瀏覽器庫大多為開源模式，新的產(chǎn)品也應(yīng)該如此。開源是一個極佳的分發(fā)渠道，將出色的軟件免費提供出去，開發(fā)者自然更愿意體驗?zāi)愕漠a(chǎn)品，并逐步轉(zhuǎn)化為付費用戶。

在開發(fā)者工具領(lǐng)域，建立良好品牌的重要性不容忽視，甚至可以與產(chǎn)品質(zhì)量本身并列?？诒畟鞑ナ情_發(fā)者工具公司最有效的渠道，其次才是自然搜索流量。

想要真正吸引開發(fā)者，就必須去他們所在的地方與他們互動。如果大量精力投入在吸引用戶上，卻沒有精心撰寫優(yōu)秀的文檔，或缺乏適合開發(fā)者語言的 SDK，那之前所有的努力都是徒勞。這些投入會直接推動口碑傳播——最好的贊賞莫過于“你看過這家初創(chuàng)公司的文檔嗎？真的太棒了！”

因為現(xiàn)有的瀏覽器自動化流程經(jīng)常出錯，這為新產(chǎn)品提供了大量機會。開發(fā)者在處理原本正常運行的代碼突然失效時，正是他們最容易轉(zhuǎn)向其他更穩(wěn)定工具的時機。這種情景對開發(fā)者工具來說相當(dāng)罕見，因為多數(shù)情況下這些工具都是“一次配置好，后續(xù)無需再關(guān)注”。

擁有一個被社區(qū)積極認可的可信品牌本身就是一道壁壘，尤其當(dāng)開發(fā)者開始積極貢獻開源核心產(chǎn)品的代碼時。避免成為 commodity 的最佳方式，就是成為開發(fā)者群體的默認選擇，而優(yōu)秀的開源項目正是實現(xiàn)這一目標的關(guān)鍵。

由于開發(fā)者工具領(lǐng)域的絕大部分收入通常來自市場頂端的 20% 用戶，因此自下而上的市場拓展策略（Bottoms-up GTM）更多是為增強口碑傳播，從而長期打開企業(yè)級客戶的收入大門。

最后，隨著核心業(yè)務(wù)的成功，公司也擁有大量向外擴展的機會，比如：

? 將抓取的數(shù)據(jù)存儲服務(wù)打包提供，并開放統(tǒng)一的查詢 API；

? 支持用戶數(shù)據(jù)持久化，加速任務(wù)完成；

? 建立社區(qū)化的工作流市場（例如從 McMaster-Carr 訂購特殊螺絲的自動化流程）。

盡管個人更傾向于橫向平臺模式，但短期內(nèi)，將自身定位成一個統(tǒng)一的傳統(tǒng)數(shù)據(jù)源 API 平臺，也可能更快地捕獲市場價值。這樣一來，很多此前無法實現(xiàn)的自動化流程，都可以直接基于該平臺構(gòu)建和運行。

05.風(fēng)險與競爭

Browser for AI 的 6 個風(fēng)險

風(fēng)險1：在已有市場中成為默認選擇非常困難

策略：

用全新范式顛覆市場，使初創(chuàng)公司能夠?qū)κ袌鲞M行細分，從而找到適合切入的空間。

參考案例：

Heroku (已有的領(lǐng)軍企業(yè)) vs Vercel (新晉的創(chuàng)業(yè)公司)：Heroku 提供全面的 PaaS 解決方案，而 Vercel 通過無服務(wù)器和前端優(yōu)先的范式，專注于現(xiàn)代 JavaScript 開發(fā)者的細分需求。

Mailgun (已有的領(lǐng)軍企業(yè)) vs Resend (新晉的創(chuàng)業(yè)公司)：Mailgun 是功能強大的郵件基礎(chǔ)設(shè)施領(lǐng)導(dǎo)者，而 Resend 以開發(fā)者體驗和設(shè)計驅(qū)動的服務(wù)，瞄準現(xiàn)代技術(shù)棧用戶的特定市場。

風(fēng)險2：瀏覽器自動化可能與客戶的核心產(chǎn)品深度綁定，客戶可能不愿外包

反駁觀點：

如果一個功能足夠重要且具備足夠的復(fù)雜度，客戶如果堅持自主開發(fā)將面臨巨大成本，這種情況下外購是更合理的選擇。這實際上是典型的“自建 vs 購買”問題。

風(fēng)險3：LLMs 推理成本太高，可能導(dǎo)致很多使用場景成本過于昂貴

反駁觀點：

LLMs 的推理成本在長期趨勢上很可能會持續(xù)下降。

策略：

將 LLMs 的相關(guān)功能設(shè)計為可選模式，讓客戶能夠自主控制成本，從而支持更廣泛的應(yīng)用場景。

風(fēng)險4：這類基礎(chǔ)設(shè)施產(chǎn)品容易商品化，利潤率面臨持續(xù)壓縮的壓力

策略：

如果可能的話，重新設(shè)計創(chuàng)新性的定價策略。例如不再按會話數(shù)收費，而可能按照吞吐量收費。

成為基礎(chǔ)設(shè)施意味著需要非常小心控制單位成本。

風(fēng)險5：濫用與法律合規(guī)風(fēng)險

反駁觀點：

截至 2022 年，根據(jù)美國第九巡回上訴法院的裁定，Scraping 行為是合法的。

此外，AI 領(lǐng)域的技術(shù)創(chuàng)新也使得識別濫用行為變得比過去容易百倍。

風(fēng)險6：如果大公司（如 OpenAI、Google 等）自己開發(fā)此類產(chǎn)品怎么辦？

反駁觀點：

本質(zhì)上，LLMs 本身無法直接內(nèi)置瀏覽器功能，因為瀏覽器屬于單獨的技術(shù)領(lǐng)域。OpenAI 等公司不太可能將瀏覽器與 GPT API 直接捆綁，因為這將引入額外的復(fù)雜性（例如計費或技術(shù)對接）。

即便 OpenAI 等公司開始整合類似功能，開發(fā)者仍然需要大量定制化的配置，以滿足具體應(yīng)用需求。

個人助理的使用場景可能最終由蘋果或谷歌等巨頭主導(dǎo)，他們會為最常用的服務(wù)提供原生集成接口。

但日常生活中頻繁接觸的大量中小型商家（比如街角的面包店或理發(fā)店）不可能提供原生 API 接口，因此這些場景仍然需要依靠瀏覽器自動化實現(xiàn)。

Browser for AI 的 3 類競爭對手

與向量數(shù)據(jù)庫領(lǐng)域相比，瀏覽器自動化這一基礎(chǔ)組件在風(fēng)險投資市場中的資金投入明顯不足?，F(xiàn)有的公司大多是自籌資金（bootstrap）起步，或融資金額低于500 萬美元。而獲得大額融資的公司多數(shù)并未真正服務(wù)于構(gòu)建相關(guān)應(yīng)用的開發(fā)者群體。

本文將現(xiàn)有的初創(chuàng)公司劃分為三大類別：瀏覽器自動化、Scraping API 和 信息檢索 API。

瀏覽器自動化

Browserless

? Browserless是該領(lǐng)域最接近龍頭位置的公司，在市場滲透率和開發(fā)者中的品牌認可度都很不錯。

? 它的本質(zhì)是遠程托管的 Puppeteer，核心創(chuàng)新主要集中在基礎(chǔ)設(shè)施層，而非SDK層。

? 團隊規(guī)模較小，最近被一家新 buyout fund 收購。

Browse.ai

? 一家獲得風(fēng)投支持的公司，但主要偏向消費者市場或低代碼用戶群。

? 它提供的“Website to API”功能非常有吸引力。

Induced.ai

? 已融資 230 萬美元種子輪，專注于企業(yè) RPA 和專業(yè)消費者市場。

Scraping APIs

這些公司提供一個 URL 接口，然后返回通常為非結(jié)構(gòu)化的數(shù)據(jù)。這些 API 公司通常還提供一些額外的功能，例如繞過 CAPTCHA 驗證或使用代理服務(wù)（proxy）。

? ScrapingBee

? WebScrapingAPI

? ScraperAPI

信息檢索APIs

這類初創(chuàng)公司更專注于特定信息的搜索和檢索服務(wù)，而非通用的瀏覽器自動化。

? Metaphor Systems

? SerpAPI

未來行業(yè)內(nèi)頂尖公司的產(chǎn)品應(yīng)該同時吸取上述三類公司的特點和優(yōu)勢。目前看來，沒有任何一家現(xiàn)有公司處于絕對領(lǐng)先地位，市場中真正最大的競爭對手反而是自己構(gòu)建方案的開發(fā)者。

06.總結(jié)

? 可預(yù)見的未來，Scraping 依然會是長期存在的需求。

? 互聯(lián)網(wǎng)本質(zhì)上是不確定的，但我們目前仍在用確定性的工具來應(yīng)對它。

? 瀏覽器自動化這個基礎(chǔ)組件長期以來缺乏足夠的投資，而 AI 應(yīng)用在未來很多年都將高度依賴這一能力。

? 市場上存在大量 AI 和非 AI 的使用場景，這為新興創(chuàng)業(yè)公司提供了難得的顛覆機會。

? 能夠把握住這個機會的創(chuàng)始人，通常具有深厚的 headless browser 技術(shù)背景、開發(fā)者工具經(jīng)驗，以及對 AI 領(lǐng)域的熱情與洞察力。