摘要： AI 購物代理回答商品問題時，靠的是訓練資料，而訓練資料裡沒有今天的價格和庫存。Firecrawl 在 2026 年 11 月 3 日發表的比較文章，把市面上五個 product data API 選項整理成一份實作指南，並說明自家方案如何用一個帳號涵蓋零售商連接器和任意商品頁的結構化擷取。對正在打造代理的開發者來說，這是選型時值得先讀的基準。
為什麼代理需要即時商品資料
Firecrawl 文章的核心論點很簡單：語言模型只能從訓練資料回答問題，它不知道今天的售價、某個尺寸是否還有貨，或昨天結束的特價。沒有即時查詢的代理，本質上是在猜。Firecrawl 引用 Gartner 在 2026 年 5 月 27 日發布的調查，54% 用 AI 協助購物的消費者表示必須自行覆核 AI 給的所有資訊。另一邊，Adobe 數據經 Digital Commerce 360 報導顯示，2026 年 7 月美國零售網站的 AI 導流流量年增 62%，而這些訪客的轉換率比非 AI 流量高 60%。需求已經存在，問題是資料從哪來。
商品資料的兩條路徑
文章把商品資料分成兩種取得方式。第一種是零售商與市集連接器：代理用關鍵字或 ID 搜尋某個商店的目錄，拿到含價格、評分和配送選項的乾淨記錄。第二種是商品頁擷取：代理傳入一個商品頁 URL，取回頁面上這個商品的每個 variant 的價格與庫存狀態。實務上兩種都需要——連接器覆蓋大型零售商，擷取處理沒有連接器的品牌獨立商店。
選型時文章建議看四件事：連接器覆蓋哪些零售商、資料是即時呼叫還是快照集、價格與庫存是否掛在每個 variant 上、以及是否提供 MCP server 和 ChatGPT、Claude 的外掛。最後一項容易被忽略：代理在每次對話中會發出大量查詢，單次查詢成本要乘上對話次數才是真實開銷。
五個選項怎麼計費
Bright Data、Apify、Oxylabs、Zyte 和 Firecrawl 都透過 MCP server 連接 AI 代理，差別在取數方式與計費模型。根據 Firecrawl 的比較：Bright Data 用 Web Scraper API 提供按站點的爬蟲與預建資料集，按每千筆記錄計費，資料集從 250 美元／10 萬筆起；Apify 靠其市集中的 Actors，按運算單位計費，電商工具每千筆商品詳情從 1 美元起；Oxylabs 的 Web API 按目標站點提供專用爬蟲，/scrape 端點每千筆結果從 0.50 美元起；Zyte 用 AI 擷取回傳商品欄位，價格隨站點抓取難度與是否需要瀏覽器浮動，成功回應每千筆從 0.06 美元起。
Firecrawl 自己的路線是「一個帳號兩條路徑」：Firecrawl Alexandria 提供零售商 provider（Shopify、Walmart、Best Buy、Newegg 等），/scrape 的 product format 則把任意商品頁轉成結構化 JSON，/search 找商品頁，/monitor 追蹤價格變動。商品頁擷取每次花 1 個 Firecrawl credit，多數 Alexandria 零售工具每次 5 個，免費方案每月給 1,000 credits。
product format 為什麼值得注意
Firecrawl /scrape 的 product format 有個對成本敏感的設計：它不需要 LLM 呼叫，也不用你提供 schema。它讀取商店本身發布的結構化資料（JSON-LD、schema.org markup、嵌入的 app state），合併後回傳標題、品牌、分類與每個 variant 的價格、原價、庫存與圖片。當頁面資訊模糊時，它回傳「無商品」加警告，而不是猜一個答案。對長尾的品牌獨立店來說，這是把任意商品頁變成代理可讀資料的低成本手段。文章引述電商客服平台 Minimal 共同創辦人 Niek Hogenboom 的說法，他們每月透過 Firecrawl 處理近六百萬個 storefront 頁面，讓 AI 客服代理從即時門市資料回答問題。
接上你的代理
接入方式涵蓋三種：ChatGPT 的 Firecrawl 外掛、Claude 的 connector，以及任何支援 MCP 的代理可用的 Firecrawl MCP server。三種都透過登入帳號授權，不用貼 API key。對自己寫代理的團隊，這和先前談過的 MCP server 選型比較是同一個生態問題——工具怎麼進到代理的執行環境裡。
一個實際的下一步：先算清楚你的一輪對話需要幾次商品查詢，再把那個數字乘上各家的單價。Firecrawl 的免費方案夠做原型驗證，但資料集類需求（例如歷史價格分析）可能仍適合 Bright Data 這類快照型供應商。兩種場景，兩種工具，別硬套同一個答案。