免费看性生交大片,成人天堂精品,一区二区三区欧美精品中,国产欧美另类久久久精品,欧美成人午夜精品一区二区

文章轉(zhuǎn)載自「海外獨角獸」。

瀏覽器的使用者正在逐漸從人類用戶轉(zhuǎn)移到，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)頁進(jìn)行交互的框架，進(jìn)一步拓展了其在 headless browser 領(lǐng)域的影響。

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

Founder Park 正在搭建開發(fā)者社群，邀請積極嘗試、測試新模型、新技術(shù)的開發(fā)者、創(chuàng)業(yè)者們加入，請掃碼詳細(xì)填寫你的產(chǎn)品/項目信息，通過審核后工作人員會拉你入群～

進(jìn)群之后，你有機會得到：

高濃度的主流模型（如 DeepSeek 等）開發(fā)交流；
資源對接，與 API、云廠商、模型廠商直接交流反饋的機會；
好用、有趣的產(chǎn)品/案例，F(xiàn)ounder Park 會主動做宣傳。

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

過去三十年里，瀏覽器一直是人類與網(wǎng)頁交互的默認(rèn)方式。人類是視覺主導(dǎo)的生物，更容易通過圖形化界面來使用線上工具。為了滿足用戶日益增長的需求，人們也一直在努力創(chuàng)新，不斷改進(jìn)網(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 會不斷抓取（Scraping）其中最有價值的部分。之所以需要抓取數(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ù)時，他們通常會模仿瀏覽器，直接對目標(biāo)網(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 獲取，而是需要與頁面進(jìn)行交互，例如點擊鏈接、輸入信息并導(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ā)過程中生成的頁面標(biāo)簽也難以預(yù)測，且可能在每次開發(fā)者重新編譯頁面時發(fā)生變化，因此想要準(zhǔn)確提取數(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 上安裝時需要高達(dá) 282MB 的依賴，這個體積是非常巨大的。作為參考，AWS Lambda 服務(wù)的最大部署大小僅為 250MB，意味著用戶不得不采取其他解決方案。類似的問題也同樣出現(xiàn)在 Playwright 身上。

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

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

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

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

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

另一種方法則是基于 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 的一些客戶

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

? 訓(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)頁進(jìn)行交互，而不再需要手動解析復(fù)雜的網(wǎng)頁結(jié)構(gòu)并進(jìn)行維護，大幅降低了 AI Agent 聯(lián)網(wǎng)的成本。

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

04創(chuàng)業(yè)機會在哪里？

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

如果沒有強有力的 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ū)積極認(rèn)可的可信品牌本身就是一道壁壘，尤其當(dāng)開發(fā)者開始積極貢獻(xiàn)開源核心產(chǎn)品的代碼時。避免成為 commodity 的最佳方式，就是成為開發(fā)者群體的默認(rèn)選擇，而優(yōu)秀的開源項目正是實現(xiàn)這一目標(biāo)的關(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：在已有市場中成為默認(rèn)選擇非常困難

策略：

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

參考案例：

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

Mailgun (已有的領(lǐng)軍企業(yè)) vs Resend (新晉的創(chuàng)業(yè)公司)：Mailgun 是功能強大的郵件基礎(chǔ)設(shè)施領(lǐng)導(dǎo)者，而 Resend 以開發(fā)者體驗和設(shè)計驅(qū)動的服務(wù)，瞄準(zhǔn)現(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)險投資市場中的資金投入明顯不足。現(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ā)者中的品牌認(rèn)可度都很不錯。

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

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

Browse.ai

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

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

Induced.ai

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

Scraping APIs