大規模網頁抓取的 Apify 替代方案（100 萬頁以上）

在百萬頁這個量級下，真正推高成本的往往不是爬蟲本身，而是代理頻寬、失敗重試和瀏覽器渲染。因此，在評估 Apify 的替代方案時，不能只比較表面價格，更重要的是看不同工具如何處理這些實際產生的成本。

單純從 Apify 換到另一個平台，並不會自動降低抓取成本。更有效的做法，是先區分哪些頁面真正需要瀏覽器。如果 API 或一般 HTTP 請求已經能夠取得所需資料，就直接使用它們；只有涉及 JavaScript 渲染、點擊翻頁、表單提交或登入工作階段的任務，才需要進入瀏覽器。

這樣拆分之後，不同工具適合處理的任務也會清晰很多。Apify、Firecrawl 或自建爬蟲更適合大規模處理公開、可直接存取的資料；當工作流程進入真正依賴瀏覽器狀態和互動的環節時，就可以交給 ego (lite) 來完成。

原因在於，這類任務已經不只是「取得一個頁面」。Agent 需要處理渲染後的內容、目前瀏覽器狀態和頁面互動，下一步操作也可能根據頁面回傳的結果動態變化。ego (lite) 直接執行在真實瀏覽器環境中，讓 Agent 能夠讀取目前頁面、繼續完成互動，並在需要人工判斷或接管時，將控制權自然地交回給使用者。

因此，對於大規模任務，更合理的方案通常不是尋找一個工具取代整個 Apify 工作流程，而是根據任務類型選擇合適的執行方式：能用 API 或 HTTP 完成的部分保持簡單，需要大規模抓取的部分交給專門的爬蟲，而真正依賴瀏覽器環境和互動的步驟再使用 ego (lite)。這樣既能控制成本，也能避免為不需要瀏覽器的任務支付額外的瀏覽器執行開銷。

在 Apify 上爬取一百萬頁要花多少錢？

依下方數字約為 430 至 1,300 美元，其中超過 80% 是 Proxy 流量，而不是爬取本身。

這套數字背後的費率公布在 Apify 的定價頁。

運算單位如何計算，文件記載於 Apify 的使用與資源文件。

這個估算來自 Apify 公開的費率，不是帳單或報價。它假設有一百萬個目標網址、其中負責主要負載的多數以 Cheerio 風格的 HTTP 方式抓取、約 100,000 個真正需要 JavaScript 的頁面採瀏覽器算繪，並且整趟都使用住宅 Proxy。

在這個規模下規劃時，有一項區別比其他所有事情都重要。請求量不等於頁面量。如果你的請求有 85% 第一次就成功，那麼一百萬個目標頁面在重試後其實接近 115 萬至 130 萬次請求。你付的是請求的錢，也付它們的流量費，即使是空手而回的那些也一樣。

我們的成本模型，逐項拆解。

請把這段當成一份依公開價格所做的算術練習。我們拿 Apify 的費率套在一個明確的工作量上，並把工作量假設寫出來，方便你換成自己的數字。

表格裡有兩個數字值得再看一眼，因為預算真正出錯的地方就在這裡。

第一個是 1024MB 那一行。新接觸 Apify 的使用者常以為記憶體買越多就越貴。就 CU 而言並非如此：需要兩倍記憶體的工作會用一半時間完成，而計費看的是兩者相乘的結果。記憶體是排程旋鈕，不是成本槓桿。

第二個是 Proxy 那一行。注意平台在這裡根本不可能成為主要成本：視方案不同，每個 CU 為 $0.20 至 $0.13，你得燒掉 2,000 個以上的運算單位，才抵得上一筆中等規模的流量帳單。

如果你的爬取很貴，你付的是流量費，而不是調度費。

Apify 的運算單位模型實際上怎麼計費？

一個運算單位是 1GB 記憶體維持一小時，以秒為精細度計算，也是平台唯一用來計算爬取費用的單位。

記憶體乘上時間。一個以 1024MB 執行一小時的工作正好花掉一個 CU；同樣的工作改用 4096MB 執行十五分鐘，也是一個 CU。這就是為什麼在我們的模型中，改變工作節點大小時 CU 欄位幾乎不動：工作量就是工作量。

這個模型有幾個特性值得記住：

1. Cheerio 不是小小的最佳化。 Apify 自己的指引指出，Cheerio 風格的 HTTP 抓取比用瀏覽器執行同一項工作快上 20 倍。正是這個倍數，讓一百萬頁只需 170 CU 成為可能。
2. 決定你耗時的是並行數，不是工作節點大小。 各方案的上限從免費版的 25 個並行執行，到 Business 版的 256 個，合計記憶體上限則依方案為 16,384MB、65,536MB、262,144MB 與 524,288MB。以 32 個並行任務、每分鐘約 3,200 頁計算，一百萬頁約需 5.2 小時。
3. 有些 actor 有硬性記憶體下限。 瀏覽器 actor 無法低於 1024MB 執行，Google 地圖爬蟲則需要 4096MB 以上。如果你不想逐一調整每個 actor，4096MB 是務實的預設值。
4. 點數不會遞延。 每月未用完的點數會過期。如果你的爬取是爆發式的，也就是每季跑一次超大量，而不是穩定小量，那你等於在為沒有用到的容量付費。

這些都不是在否定 Apify。它是少數能單憑公開文件就推算出單位經濟的平台之一，而且 CU 模型確實很誠實：它按工作量計費，而不是按列數計費。問題在於它沒有納入的東西。

Proxy、吃重的算繪 actor、資料集擺著就不斷累積的儲存費用。這些才是決定百萬頁爬取是數百還是數千美元的項目，而且在你可能考慮的每一個 Apify 替代方案上，都是同樣這幾項。

大規模抓取主要的 Apify 替代方案有哪些？

替代方案有四種，而其中只有一種的定價形狀與 Apify 相同。

大多數「Apify 替代方案」清單，其實是其他網頁抓取工具的清單，那問題並不一樣。如果你的爬取是貴，而不是做不到，那麼相關的軸線不是功能，而是每個廠商對什麼收費。每運算小時的價格、每點數的價格、每 GB Proxy 流量的價格，以及每操作人時的價格，隨著量體成長的行為都不一樣。

1. Firecrawl。 以點數計費的抓取 API，輸出可直接餵給 LLM。一次抓取算一點，而且每一種選用的輸出格式都要加價：JSON 模式 +4，問題或重點擷取每種格式 +4，PII 去識別化 +4。方案價格為 $0、$20、$106、$424 與 $762，分別對應每月 1,000、5,000、100,000、500,000 與 1,000,000 點。
2. ZenRows。 代管抓取服務，支援 JS 算繪與 Proxy 輪替。點數從 $16 方案的 5,000 點，到 $456 方案的 500 萬點；並行數從 5 到 200，更高需求可客製。JavaScript 算繪會讓點數成本乘以 10，JS 加 Proxy 的組合模式則乘以 25。失敗與重試的請求不計費。
3. ScraperAPI。 以點數計費的抓取服務，並行數階梯很單純，從 $49 方案的 20 一路到最高階的 500 以上，點數範圍橫跨 100,000 到 1,050 萬點。
4. Bright Data 與 Oxylabs。 以 Proxy 為主的廠商，同時也販售代管爬蟲。Oxylabs 的 SERP 定價為每個單位序列 $0.50 至 $1.35，住宅流量則從 $3/GB 起，量大可降至 $2/GB。Bright Data 的網頁爬蟲頁面主打不限並行的說法，卻沒有公布價格；這是一項我們無法查證的宣稱，因此不會當成事實轉述。
5. 自架爬蟲。 在你自己的基礎架構上跑 Scrapy 或 Playwright 流程。完全沒有按頁或按 CU 的費用，Proxy 帳單也仍是你自己的帳單。代價是佇列管理、重試、排程與監控，永遠都變成你的問題。
6. 由 Agent 驅動的瀏覽器。 這正是我們投入的路線，請帶著這個前提閱讀。ego (lite) 是一款 Chromium 瀏覽器，會沿用你既有的登入狀態與擴充功能，並由程式 Agent 透過 ego-browser 技能，在它自己獨立的 Space 中操作。當靜態請求不再夠用時，工作流程就會走到這裡：登入步驟、只有在 JavaScript 下才會算繪的檢視、藏在點擊後的分頁、其實是表單的篩選器，以及你得從收件匣讀取的驗證碼。它免費，目前可在 macOS 上執行，Windows 與 Linux 則在開發藍圖中。它沒有可與 Apify 對照的每頁費率，所以該問的不是每頁哪個便宜，而是你的工作流程到底需不需要工作階段。

為什麼 Proxy 流量會主導整筆帳單？

因為它是唯一一項會隨你下載頁面的大小成長，而不是隨你完成的工作量成長的費用。

這條路在同等條件的瀏覽器任務上表現如何，ego (lite) 與 Playwright 的比較就是最直接的。

如何在多次執行之間維持已登入的工作階段，詳見 Agent 執行之間持久的瀏覽器工作階段。

運算隨 CPU 時間成長，並行數隨方案等級成長，流量則隨整個網際網路成長。一 MB 的 HTML 就是一 MB，不管它花了一毫秒還是一秒才送達；而住宅 Proxy 流量是按 GB 計價：Apify 為 $8/GB，Oxylabs 則從 $3/GB 起，量大可降至 $2/GB。

以每頁 50KB 的壓縮 HTML 計算，一百萬頁約為 50GB。依 Apify 公布費率，這在還沒計入重試之前就是 400 美元，而且目標越難就越糟：有機器人防護的頁面更重、往往需要多次請求才能取得，耗用的資源可達友善頁面的三倍。

不舒服的地方在這裡。這些流量大部分都浪費掉了，而你自己也清楚。一個商品列表頁可能有 400KB 的 HTML、CSS、JavaScript、字型與追蹤像素，只是為了讓你讀到一個價格和一個庫存狀態，而真正的訊號或許只有 2KB。你是在用住宅 Proxy 的費率運送包裝。

有三個槓桿可以降低它，而且比換任何廠商都值得。把爬取限制在真正帶有資料的頁面，而不是跟著每個連結跑。在網站有提供結構化端點時抓取端點，因為 JSON 回應只有算繪後頁面重量的一小部分。並且只在真的需要算繪的地方算繪，在我們的模型中，一百萬頁裡只有 100,000 頁。

這些 Apify 替代方案怎麼比較？

依公開費率，最便宜與最貴路線之間的差距大約是十倍，而且沒有一項來自爬取本身。

閱讀每一列時看兩件事：廠商對什麼收費以及它讓你做不到什麼。沒有上限的價格是行銷話術，沒有價格的上限則是一通業務電話。

Firecrawl 那一列最常被誤讀，值得說清楚。一百萬點聽起來像一百萬頁，就單純抓取而言確實如此。但加上 JSON 擷取後，每頁要花五點，同樣的 $749 就只能涵蓋 200,000 頁。這不是定價手法，而是真實工作對應的真實成本；也就是說，你編列預算用的數字，並不是方案卡上的那個數字。

Firecrawl 自己的文件對另一項限制異常坦白：你真正的瓶頸會是並行瀏覽器數。免費方案從 2 個起，Hobby 為 5 個，Standard 為 25 個，Growth 為 50 個，Scale 則為 100 個以上。以 100 個並行頁面、每頁寬鬆地算兩秒，大約是每秒 50 頁，也就是一百萬頁約需 5.6 小時。這行得通，但你無法只靠加點數買到更高的上限。

Firecrawl 的各級並行上限來自它自己的定價頁。

這項選擇背後的抓取函式庫比較，請見 Playwright 與 Puppeteer 的網頁抓取比較。

ZenRows 用另一種方式解決同一個問題：讓重試免費。失敗或重試的請求不計費，在充滿敵意的目標上是實質優勢；在假設較便宜的表面費率會勝出之前，這正是值得先確認的事。

選擇 Apify 替代方案要看哪些標準？

決定結果的有四項數字，其中三項是你工作量的特性，而不是任何廠商的特性。

在這個規模下，功能比較表大多是雜訊，因為每家廠商都能做同樣的核心工作。真正的差異在於當你的爬取量成長一個數量級時，它們的計費方式如何變化，以及它們施加的上限是在成長之前還是之後出現。

注意這張表有多麼不談功能。在「Apify 替代方案」這個關鍵字上競爭的廠商，多半在同一份清單上較勁：Proxy 池、JS 算繪、驗證碼處理、整合。這些清單往往會趨於一致。計費形狀不會趨於一致，而它才是決定你帳單的部分。

該怎麼挑選 Apify 替代方案？

把答案對應到你的算繪比例與授權狀態，候選名單就會收斂到只剩一列。

1. 靜態 HTML、公開、一百萬頁以上。 留在按 CU 計費的平台或自架，並把心力放在 Proxy 費率與降低頁面重量上。在這樣的算繪比例下換平台，只能省下個位數百分比。
2. 大致靜態，但有一小群難以處理的算繪頁面。 拆分爬取。多數用便宜的抓取，其餘走算繪路徑。這是可用選項中報酬率最高的單一決策，而且做出這個決定不需要任何成本。
3. 從頭到尾都是大量 JavaScript，資料公開。 如果這些 API 幫你完成擷取，它們在這裡的價值就站得住，因為你買的是 Token 與結構化輸出，而不只是位元組。挑方案之前，先為格式倍數編列預算。
4. 充滿敵意的目標與頻繁的封鎖。 為重試定價，而不是為請求定價。不針對失敗計費的廠商，即使表面費率較高，也可能更便宜。
5. 在登入之後，或內部儀表板。 別再比較爬蟲價格了。這是經授權、依賴工作階段的工作，而且它執行在一個已經持有該工作階段的瀏覽器裡，這正是ego (lite) 的用途。關於實際機制，請看我們對登入牆後方的抓取的說明；同時請清楚知道，這裡沒有任何工具會繞過網站的存取控制。
6. 數百頁，但經常更新。 以上都不適用。你並不在讓成本模型變得有趣的那個量體區間，無程式碼工具大概才是對的選擇。我們的 AI 網頁抓取工具指南以那樣的規模為前提，涵蓋了無程式碼、API 與 agent-browser 路線。

如果你考慮的是代管瀏覽器基礎架構，而不是爬蟲本身，同樣的邏輯要再往下看一層：無頭與真實瀏覽器的差異才是決定你的每頁成本是否會被算繪主導的關鍵。

什麼情況下值得把 ego (lite) 加進工作流程？

靜態請求會在五個特定時刻變得不足：登入、只有在 JavaScript 下才會算繪的檢視、藏在點擊後的分頁、其實是表單的篩選器，以及驗證步驟。

這五種情況值得一提，因為它們是抓取本身無法自行復原的。curl 會回傳登入頁並回報 200。HTML 送達了，但資料列不在裡面。第二頁確實存在，但只在你送不出請求的點擊之後才會出現。你要的資料藏在表單後面，而不是查詢字串裡。帳號要求你輸入一個驗證碼，而它寄到你另一個分頁開著的收件匣。

遇到這種情況，解法不是更大的爬蟲，而是在一個已經帶著工作階段的瀏覽器裡跑同一套流程。

為了不讓這段流於空談，我們把同一項任務用兩種方式各跑一次並留下證據。任務是：從 Amazon 搜尋結果中抓出前三筆非廣告的魚油商品，包含名稱、品牌、價格、評分、評論數與容量。一次透過 ego (lite)，一次用指令碼走純 HTTP。兩次都在同一天、同一台機器上執行，兩次過程都列在下方。

瀏覽器路線：逐步拆解

瀏覽器那一次分成四個部分：你交出去的輸入、Agent 採取的步驟、遇到不該自行決定的事情時會怎麼做，以及你如何檢查結果。以下逐一對照一次真實的商品搜尋。

1. 輸入。 搜尋網址、一個已登入的 Amazon 帳號，以及一句描述要收集哪些欄位的說明。ego (lite) 是 Chromium，會沿用你既有的登入狀態、擴充功能與歷史紀錄，所以沒有匯出 Cookie 的步驟，也不需要把憑證貼到任何地方。ego-browser 技能與瀏覽器綁定，隨 ego (lite) 一併安裝，你只要在 Agent 的聊天框中輸入 /ego-browser 就能啟用。

1. 關鍵步驟。 Agent 會開啟自己的 Space，那是一個帶有藍色光暈標記的獨立視窗，因此不會操作你正在使用的分頁。在裡面，Agent 進行導覽、對頁面拍快照以讀取結構，並擷取找到的內容。這些快照能讀取巢狀 iframe，而這正是依賴算繪的擷取通常會失敗的地方。

3. 失敗復原。 當執行過程遇到登入、驗證碼，或任何它不該自行決定的事情時，它會停下來並把你拉進它的 Space，而不是擅自猜測。文件記載的行為在風險較高的一端也成立：求職申請會在最後送出前等你確認，訂房流程則會走到付款頁就停下。撞上登入牆的爬蟲會記下一筆 200 然後繼續前進。這一套會問你。
4. 結果驗證。 把你收集到的資料列，對照 Agent 當時實際所在的頁面，而不是你交給它的網址。Agent 據以工作的快照就是證據。這趟執行唯一真正的異常就是在這裡浮現的，而這正是只存在於算繪頁面上的東西。

改用純 HTTP 完成同一項任務

以下是誠實的另一半，因為真正有意思的結果並不是 HTTP 失敗了，而是它在哪裡吃力，以及讓它跑起來要付出多少代價。

HTTP 那一次用指令碼、不開瀏覽器執行同一項任務。它最後還是完成了。那份紀錄記錄了兩者之間隔著多少傳輸工作。

被挑戰的請求就是硬停。但這裡大多數的 503 並不是挑戰，而要分辨兩者得做一次實驗。

重寫傳輸層只是問題的中段，不是終點。接著擷取器還得針對同一個頁面修正兩次。

所以兩次執行都取到了這三筆商品。差別在於各自為了到達那裡付出了什麼。瀏覽器那一次開了一個 Space、讀取頁面，並為它回報的每一個值附上截圖。HTTP 那一次寫了六份指令碼、因為指紋不符而換掉 HTTP 用戶端、加上重試層、修正廣告偵測的錯誤、修正幣別的錯誤，最後以一份承認第一筆商品沒有任何輸出的報告收尾。

這就是按頁計費的成本模型看不到的部分。兩種做法都沒有錯，而那些截圖中的 Token 與實際耗時計數也接近到無法單憑速度下定論。真正分出差別的是時間花在哪裡：一條路線把時間花在閱讀頁面，另一條則花在打造與除錯那套代替「讀過頁面」的機器。

對三筆商品來說，那套機器就是全部的成本，而且回不了本。到了十萬頁，同一套程式碼會無人看管地跑上一整天，這時算盤就完全反過來了。

什麼情況下完全不需要 ego (lite)

純 HTTP 能涵蓋的工作比工具討論裡所暗示的更多。如果頁面會把資料放在 HTML 裡回傳，就抓它。如果網站有公開 API，就用 API，因為那是網站預期的存取路徑，而且能挺過會讓選擇器失效的改版。如果整件工作就是一次大型公開爬取，其中沒有任何步驟需要工作階段，那麼代管平台或以點數計費的 API 在產能上都會勝過本機瀏覽器。

也要用正確的規模來解讀 Amazon 這個案例。它不能證明 HTTP 壞了，因為 HTTP 確實取到了資料；也不能證明瀏覽器很快，因為瀏覽器那一次同樣花了二十多分鐘，而且它自己的報告也記載了一次失敗。它顯示的是兩邊的工作各自花在哪裡。瀏覽器那條路線唯一的真問題來自網站，而不是工具；HTTP 那條路線的問題則全部來自自己。

把瀏覽器加進一個不需要它的工作流程，是讓爬取工作變得更慢、更貴最常見的方式。先檢查便宜的路線，並記下當目標需要工作階段時，代價會是什麼。

自架自己的爬蟲還值得嗎？

通常值得，而且原因是算術，不是工藝：到了那個量體，你付的是佇列與排程器，而這兩者都是大宗物資。

Scrapy 與 Playwright 免費、文件齊全，而且無聊得正像生產基礎架構該有的樣子。如果你的爬取是針對穩定目標的重複性工作，自架流程能完全省下平台費用，只留下伺服器成本，以及無論如何都得付的 Proxy 帳單。

誠實的另一面是，平台費用確實買到了真東西。能處理五種不同失敗模式的重試邏輯、不會漂移的排程器、儲存、日誌，以及在不碰生產環境的情況下重跑資料集的能力。團隊總是低估這些要花多少工程時數，因為那些時數出現在某個人的行事曆上，而不是發票上。

一個粗略的原則：當爬取是重複性、目標穩定時就自架；當爬取是探索性，或你爬的網站每隔幾週就改一次形狀時，就用租的。平台費用基本上是一種變更管理費。

這些選項各自會在哪裡失效？

有三個地方，而它們正是把乾淨的成本模型變成超支的原因。

第一個是每家廠商的行銷宣稱都跑得比文件快，而且落差最大的地方，正好就是你最需要精確的地方。Bright Data 的網頁爬蟲頁面聲稱不限並行，卻在同一頁上不公布任何價格。那不是一個我們能推翻的謊言，而是一項我們無法查證的宣稱，這是另一件、而且更有用的事。把任何「不限」、「企業級」或「無限」的措辭都當成提醒你去把數字找出來；如果數字沒有公開，就假設上限存在，而且是要談的。

第二個是機器人防護，它不是你可以買到的功能，而是一種你得在其中運作的條件。當每個請求都需要住宅 IP、暖好的工作階段與重試預算時，更快抓取路徑帶來的效率提升就全部蒸發。我們的模型會到 1,300 美元，不是因為哪家廠商在敲竹槓，而是因為目標越難，頁面越重、浪費的請求越多。

第三個是沒有人會放進比較表的那一項：這是公開資料的基礎架構，而以那種方式使用它，是你的責任。服務條款、robots 指令、GDPR 或 CCPA 下的個人資料，以及網站的公開頁面和它使用者的私人資訊之間的差別，全都是與你選哪個工具無關的另一組問題。便宜的爬蟲不會讓不被允許的爬取變成被允許。我們不是律師，這也不是法律建議，但最便宜的爬取，是你的組織真正站得住腳的那一種。

常見問題

百萬頁規模下最便宜的 Apify 替代方案是什麼？

依公開費率，是用便宜 Proxy 的自架 Scrapy 流程，因為完全沒有平台費用。在代管選項中，跑 HTTP 抓取、按 CU 計費的平台在單純量體上勝過以點數計費的 API。但誠實的答案是，平台選擇只占帳單較小的一半：以住宅流量 $8/GB 計算，一百萬頁各 50KB，無論由誰來抓，流量費都約 400 美元。

Firecrawl 是好的 Apify 替代品嗎？

就產出可直接餵給 LLM 的 Markdown 與結構化擷取而言，是的：它更容易預估，輸出也替你省下一層解析。但就單純抓取一百萬頁而言，先成為限制的是它的並行上限，而不是點數餘額。免費方案允許 2 個並行瀏覽器，Scale 方案為 100 個以上，因此產能是被方案限制，而不是被花費限制。

Apify 對失敗的請求收費嗎？

會，間接地收。無論請求回傳了什麼，運算單位都會依執行時間累計，Proxy 流量也已經花在傳輸上。一次重試的請求會被收兩次費，而第一次嘗試什麼也沒換到。

為什麼 Apify 替代方案在大規模時常常更貴？

就平台本身而言，通常並沒有。它們看起來貴，是因為點數倍數無法乾淨地對應到頁面：一次抓取是一點，但 JSON 模式是五點，而在以 Proxy 為主的廠商上，JavaScript 算繪可能是單純抓取的十倍或二十五倍。把表面費率乘上你真正需要的倍數，差距就會縮小或反轉。

百萬頁需要瀏覽器算繪嗎？

幾乎不需要全部都用。一個可用的假設是 90% 的頁面能以靜態 HTML 讀取，10% 需要 JavaScript，這也是我們的模型只算繪 100,000 頁、其餘都用抓取的原因。編預算之前，先在 1,000 頁的樣本上測量你的比例，因為它對成本的影響比選哪家廠商更大。

那 Bright Data 與 Oxylabs 作為 Apify 替代方案呢？

當問題出在 Proxy 時，它們最強。Oxylabs 的住宅流量從 $3/GB 起，量大可降至 $2/GB，遠低於 Apify 的 $8/GB；SERP 定價則為每個單位序列 $0.50 至 $1.35。Bright Data 在其網頁爬蟲頁面上不公布價格，只主打一項我們無法查證的不限並行宣稱，所以請把它當成要主動去問的報價，而不是可以拿來規劃的事實。

這裡引用的住宅流量費率列在 Oxylabs 的定價頁。

Bright Data 的方案在抓取器頁面上不公布每 GB 費率，最低起價見它的定價頁。

我可以用 ego (lite) 取代 Apify 嗎？

它們涵蓋不同的步驟，所以這讀起來不像是取代，更像是交接。Apify 負責大量代管爬取；ego (lite) 是一款免費的 macOS 瀏覽器，由程式 Agent 在你已登入的工作階段中操作，當某個步驟需要登入、算繪後的檢視、點擊翻頁、表單或驗證碼時，你就會用它。如果你的工作是一次大型公開爬取，其中沒有任何步驟需要工作階段，那你根本不需要在流程中放進 ego (lite)。

爬取之前，我該怎麼估算 Proxy 流量？

抓取 1,000 個具代表性的網址，測量壓縮後的回應大小，再相乘。接著加上重試係數：在 85% 首次成功率下，一百萬個目標等於 115 萬至 130 萬次請求。請為較高的數字編列預算，因為頁面重量會隨機器人防護而上升。

在這個量體下，Apify 還是對的選擇嗎？

有時候是。它的 CU 模型透明，按工作量而不是列數計費，actor 生態系也省下大量膠水程式碼。如果你的爬取是數十萬頁，而 Proxy 來自更便宜的廠商，那平台就不是你的問題。會考慮離開，通常是因為點數過期、依方案分級的並行上限在你準備好之前就先到頂，或是你在別處能找到更低的流量費率。

百萬頁規模下，最先撐不住的是什麼？

是預算，不是技術。並行上限與重試計費都有文件記載、可預測。讓團隊意外的是流量帳單、對需要算繪頁面數量的假設，以及爬取中最後有多少是根本沒人要的頁面。先修正範圍，再修正廠商。

大多數 Apify 替代方案比較文回答的是功能問題。在百萬頁規模下真正花錢的問題是計費形狀，它有三個部分：廠商對什麼加成收費、它的上限是什麼，以及失敗的請求由誰買單？

Apify 把這些問題回答得很好。它的運算單位是乾淨的工作單位，而且它按瀏覽頁面收費，而不是按列數計算。它控制不了的是你真正會盯著看的那部分帳單：$8/GB 的住宅流量，而且是在大部分位元組都只是支架的頁面上。

所以有用的做法不是換平台，而是把爬取削減到只剩真正帶資料的頁面，用比瀏覽器便宜 20 倍的方式抓取靜態的大多數，只算繪那需要算繪的 10%。做到這件事，廠商比較就會變成一個四捨五入的決定。

爬蟲到不了的那些部分，登入後的頁面與內部工具就是爬取止步、工作階段開始的地方。ego (lite) 在登入狀態已經附帶的情況下執行同一套流程，並在步驟需要人介入時停下來問你。而當單純的抓取已經能回傳資料列，那就是全部的答案：別把瀏覽器牽扯進來。

我們投入第一次百萬頁爬取時，以為平台會是最貴的部分。結果回答我們的是流量。