為什么 AI Agent 需要專屬瀏覽器?

0 評(píng)論 2292 瀏覽 19 收藏 30 分鐘

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

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

Browserbase 是一家成立一年多的 headless browser 服務(wù)提供商,以云服務(wù)的形式為 AI Agent 公司提供 scalable、高可用性的瀏覽器服務(wù)。近期,Browserbase 又推出了 StageHand,一種利用 LLM 使得開發(fā)者可以用自然語(yǔ)言與網(wǎng)頁(yè)進(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)頁(yè)交互的門檻和維護(hù)成本的目標(biāo)。我們編譯的過(guò)程中能感受到 Browserbase 這一年多以來(lái)的產(chǎn)品實(shí)踐和 Stagehand 框架的推出都能和文中的 roadmap 對(duì)應(yīng)上。

?? 目錄 ??

 01 目前的瀏覽器無(wú)法滿足 AI Agent 需求

 02 Browser for AI 市場(chǎng)正在快速增長(zhǎng)

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

 04 如何走向市場(chǎng)

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

 06 總結(jié)

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

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

根據(jù) Cloudflare 的數(shù)據(jù),互聯(lián)網(wǎng)上已經(jīng)有超過(guò) 40% 的流量來(lái)自其他計(jì)算機(jī),也就是我們常說(shuō)的 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)站上瀏覽和獲取信息。

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

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

問(wèn)題1:Scraping 并不簡(jiǎn)單

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

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

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

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

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

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

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

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

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

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

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

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

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

有頭瀏覽器和無(wú)頭瀏覽器的對(duì)比

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

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

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

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

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

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

02.Browser for AI 市場(chǎng)正在快速增長(zhǎng)

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

第一種方法是 RAG。LLMs 會(huì)先通過(guò)瀏覽器獲取信息,然后將這些信息作為額外的上下文,補(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)地完成頁(yè)面導(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ù)庫(kù)(embeddings/vector databases)并列,成為L(zhǎng)LM的核心基礎(chǔ)組件之一。這一點(diǎn)明確顯示出瀏覽器對(duì)于 LLMs 的重要性,尤其是隨著 LLMs 使用外部工具能力的不斷增強(qiáng),這種趨勢(shì)只會(huì)越來(lái)越明顯。

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

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

通過(guò) NPM 的每周下載量

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

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

使用 ScrapingBee 的一些客戶

此外,還有幾個(gè)重要的趨勢(shì)將進(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)化工具。

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

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

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

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

回顧一下此前提到的目前 headless browser 存在的問(wèn)題:

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

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

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

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

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

簡(jiǎn)單來(lái)說(shuō),開發(fā)者們真正想要的是一個(gè)性能更強(qiáng)、可靠性更高、且使用更簡(jiǎn)便的瀏覽器自動(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 賦予瀏覽器“超能力”

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

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

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

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

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

04.如何走向市場(chǎng)

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

如果沒(méi)有強(qiáng)有力的 GTM 策略就無(wú)法獲得成功,“首次創(chuàng)業(yè)的人癡迷于產(chǎn)品,二次創(chuàng)業(yè)的人則專注于分發(fā)?!贬槍?duì)開發(fā)者工具類產(chǎn)品,最有效的分發(fā)策略如下:

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

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

? 建立值得信賴的品牌

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

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

投資于社區(qū),意味著在獲取價(jià)值的同時(shí)也回饋社區(qū)?,F(xiàn)有瀏覽器庫(kù)大多為開源模式,新的產(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)。如果大量精力投入在吸引用戶上,卻沒(méi)有精心撰寫優(yōu)秀的文檔,或缺乏適合開發(fā)者語(yǔ)言的 SDK,那之前所有的努力都是徒勞。這些投入會(huì)直接推動(dòng)口碑傳播——最好的贊賞莫過(guò)于“你看過(guò)這家初創(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ī)。這種情景對(duì)開發(fā)者工具來(lái)說(shuō)相當(dāng)罕見,因?yàn)槎鄶?shù)情況下這些工具都是“一次配置好,后續(xù)無(wú)需再關(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)域的絕大部分收入通常來(lái)自市場(chǎng)頂端的 20% 用戶,因此自下而上的市場(chǎng)拓展策略(Bottoms-up GTM)更多是為增強(qiáng)口碑傳播,從而長(zhǎng)期打開企業(yè)級(jí)客戶的收入大門。

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

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

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

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

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

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

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

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

策略:

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

參考案例:

Heroku (已有的領(lǐng)軍企業(yè)) vs Vercel (新晉的創(chuàng)業(yè)公司):Heroku 提供全面的 PaaS 解決方案,而 Vercel 通過(guò)無(wú)服務(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ù)棧用戶的特定市場(chǎng)。

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

反駁觀點(diǎn):

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

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

反駁觀點(diǎn):

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

策略:

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

風(fēng)險(xiǎn)4:這類基礎(chǔ)設(shè)施產(chǎn)品容易商品化,利潤(rù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ù)美國(guó)第九巡回上訴法院的裁定,Scraping 行為是合法的。

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

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

反駁觀點(diǎn):

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

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

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

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

Browser for AI 的 3 類競(jìng)爭(zhēng)對(duì)手

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

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

瀏覽器自動(dòng)化

Browserless

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

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

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

Browse.ai

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

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

Induced.ai

? 已融資 230 萬(wàn)美元種子輪,專注于企業(yè) RPA 和專業(yè)消費(fèi)者市場(chǎng)。

Scraping APIs

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

? ScrapingBee

? WebScrapingAPI

? ScraperAPI

信息檢索APIs

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

? Metaphor Systems

? SerpAPI

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

06.總結(jié)

? 可預(yù)見的未來(lái),Scraping 依然會(huì)是長(zhǎng)期存在的需求。

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

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

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

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

編譯:Xeriano 編輯:Cage

本文由人人都是產(chǎn)品經(jīng)理作者【海外獨(dú)角獸】,微信公眾號(hào):【海外獨(dú)角獸】,原創(chuàng)/授權(quán) 發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash,基于 CC0 協(xié)議。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 目前還沒(méi)評(píng)論,等你發(fā)揮!