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

瀏覽器的使用者正在逐漸從人類用戶轉(zhuǎn)移到 AI Agent，Agent 與互聯(lián)網(wǎng)環(huán)境互動(dòng)的底層設(shè)施也因此正在變得越來越重要。傳統(tǒng)瀏覽器無法滿足 AI Agent 自動(dòng)化抓取、交互和實(shí)時(shí)數(shù)據(jù)處理的需求。Browserbase 的創(chuàng)始人 Paul Klein 早在 23 年底就敏銳地洞察到 AI Agent 亟需一個(gè)全新的交互載體——一個(gè)“為 AI 而生”的云端瀏覽器。這個(gè)瀏覽器不僅要解決現(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è)計(jì)配套的 SDK 和 API 以提供極致的開發(fā)者體驗(yàn)，最終實(shí)現(xiàn)大幅降低 AI 與網(wǎng)頁交互的門檻和維護(hù)成本的目標(biāo)。我們編譯的過程中能感受到 Browserbase 這一年多以來的產(chǎn)品實(shí)踐和 Stagehand 框架的推出都能和文中的 roadmap 對應(yīng)上。

?? 目錄 ??

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

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

 03 打造一個(gè)更好的 headless browser

 04 如何走向市場

 05 風(fēng)險(xiǎn)與競爭

 06 總結(jié)

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

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

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

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

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

問題1：Scraping 并不簡單

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通過 NPM 的每周下載量

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

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

使用 ScrapingBee 的一些客戶

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

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

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

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

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

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

03.打造一個(gè)更好的 headless browser

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*譯者注：站在 2025 年回看的 browserbase ，我們會(huì)發(fā)現(xiàn)其發(fā)展歷程與創(chuàng)始人提出的策略三大策略是吻合的，browserbase 通過其開源策略迅速打開了市場，并在 2024 年底發(fā)布了 StageHand，一種利用 LLM 將自然語言指令轉(zhuǎn)換成 Playwright 代碼從而操縱 headless browser 的開源框架，使得開發(fā)者可以用自然語言與網(wǎng)頁進(jìn)行交互，而不再需要手動(dòng)解析復(fù)雜的網(wǎng)頁結(jié)構(gòu)并進(jìn)行維護(hù)，大幅降低了 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è)公司能否在巨頭實(shí)現(xiàn)創(chuàng)新之前，搶先獲得市場分發(fā)?！?/p>

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

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

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

? 建立值得信賴的品牌

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Browser for AI 的 6 個(gè)風(fēng)險(xiǎn)

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

策略：

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

參考案例：

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

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

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

反駁觀點(diǎn)：

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

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

反駁觀點(diǎn)：

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

策略：

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

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

策略：

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

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

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

反駁觀點(diǎn)：

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

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

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

反駁觀點(diǎn)：

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

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

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

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

Browser for AI 的 3 類競爭對手

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

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

瀏覽器自動(dòng)化

Browserless

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

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

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

Browse.ai

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

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

Induced.ai

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

Scraping APIs

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

? ScrapingBee

? WebScrapingAPI

? ScraperAPI

信息檢索APIs

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

? Metaphor Systems

? SerpAPI

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

06.總結(jié)

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

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

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

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

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