摘要： Firecrawl 的 /scrape 端點把瀏覽器渲染、代理與快取收進單次 API 呼叫，可在同一請求索取 markdown、HTML、截圖、連結、摘要、JSON 等多種輸出。基礎抓取為 1 credit，JSON 提取加 4 credits，PDF 解析每頁再加 1 credit；快取只降低延遲，不會減少 credit。
網頁資料想抓得穩，難度只會一路往上爬。頁面內容要靠 JavaScript 才長得出來、網站佈下層層反爬關卡、同一份 HTML 換個地區樣貌就跟著變，開發者往往得先拼出一套下載器，後面再串一條清洗管線，才換得到乾淨的文字或結構化記錄。
Firecrawl 的 /scrape 端點把這一長串工序收攏成單次 API 呼叫。你丟給它一個 URL 並指名要哪些格式，它便在伺服器端以真實瀏覽器渲染頁面、代管代理與快取，再把你要的結果送回來。本文站在產品建構者的立場，逐一檢視這個端點的核心參數與計費邏輯，也說明提示詞驅動的 JSON 提取和嚴格資料模型各自適用的時機。
十一種輸出格式，一次呼叫全帶回
/scrape 最直觀的好處是「呼叫一次，帶回多種資料」。markdown、html、rawHtml、links、screenshot、summary、images、json、branding、audio、question 這些格式可以併在同一個請求裡索取，Firecrawl 會把你指定的資料全部放進同一份回應。
底下以 Python 對 arXiv.org 同時索取多種格式：
from firecrawl import Firecrawl
from dotenv import load_dotenv
load_dotenv()
app = Firecrawl()
url = "https://arxiv.org"
data = app.scrape(
url,
formats=['html', 'rawHtml', 'links', 'screenshot', 'summary', 'images']
)拿 markdown 來說，頁面主體會被轉成對 LLM 親和的純文字，接上 RAG 管線或摘要模型都很合適。screenshot 給的是帶簽章的 PNG 連結，搭配 fullPage 參數可截下整個頁面。audio 能從 YouTube 網址直接抽出 MP3，不過目前只能靠 REST API 呼叫。
Firecrawl 官方文件說明，各格式共用同一套渲染流程：頁面先在無頭瀏覽器裡載入並執行 JavaScript，重新導向也一併處理完畢，最後才依 formats 參數產出對應的結果。換句話說，瀏覽器實例與代理池都不必你自己維護。
結構化抽取：提示詞與資料模型兩條路
若目標是從頁面撈出特定欄位——例如品名、售價、庫存狀態——json 格式提供了兩種做法。
第一種完全由提示詞驅動：用自然語言寫下需求，例如「從這頁取出所有文章的標題、作者與分數」，欄位名稱與結構交給 LLM 自行推論。這條路動手最快，代價是欄位名稱每次未必相同，下游程式得保留彈性。
拿 Hacker News 示範，用一段提示詞請它抓出前三名故事：
url = "https://news.ycombinator.com"
data = app.scrape(
url,
formats=[
"markdown",
{
"type": "json",
"prompt": "Extract the top 3 stories on the page. For each story, include its title, the URL it links to, the points score, and the author who submitted it."
}
]
)
print(data.json)回傳的 JSON 會接近底下這個樣子：
{
"stories": [
{
"title": "BYOMesh – New LoRa mesh radio offers 100x the bandwidth",
"url": "https://example.com/story1",
"points": 209,
"author": "nullagent"
}
]
}第二種是傳入 Pydantic schema（或等價的 JSON Schema），把欄位名稱與型別整組釘死。假設你宣告 title: str、points: int，回傳的 JSON 就會嚴守這個形狀，適合直接寫進資料庫，或交給型別檢查嚴謹的程式處理。
巢狀 schema 的寫法，官方部落格有完整示範：
from pydantic import BaseModel, Field
class IndividualArticle(BaseModel):
title: str = Field(description="The title of the news article")
subtitle: str = Field(description="The subtitle")
url: str = Field(description="The URL")
author: str = Field(description="The author")
date: str = Field(description="The publication date")
read_duration: int = Field(description="Estimated reading time in minutes")
topics: list[str] = Field(description="List of topics")
class NewsArticlesSchema(BaseModel):
news_articles: list[IndividualArticle] = Field(description="Extracted articles")
data = app.scrape(
url,
formats=[
{
"type": "json",
"schema": NewsArticlesSchema,
"prompt": "Extract the top 5 stories as news articles."
}
]
)
print(data.json)Firecrawl 的教學文章用 Hacker News 當例子，把兩種方式都走了一遍。團隊若對輸出形狀有硬性要求，建議採用 schema 模式；只是想快速摸索資料，提示詞模式已經夠用。
費用與快取：省下的是延遲，不是 credit
/scrape 每次呼叫的基礎費用是 1 個 credit。依照官方計價表，會把成本往上加的選項有：
- JSON 提取：加收 4 credits（合計 5）
- PDF 解析（
parsers=["pdf"]）：每頁 PDF 加收 1 credit - 音訊提取（
formats=["audio"]，只有 REST 提供）：加收 4 credits - ZDR（
zeroDataRetention=True，Enterprise 方案）：每頁加收 1 credit
官方文件裡的計價表，整理如下：
| 項目 | Credit 費用 |
|---|---|
| 基礎抓取（任何單一格式） | 1 |
JSON 提取（formats: [{type: "json"}]） |
加 4（合計 5） |
增強代理（proxy: "enhanced"） |
一樣是 1 credit，不加價 |
PDF 解析（parsers: ["pdf"]） |
每頁 PDF 加 1 |
音訊提取（formats: ["audio"]，只有 REST 提供） |
加 4（合計 5） |
| 快取結果 | 1（快取省的是時間，省不了 credits） |
實務上有兩個容易搞錯的地方：快取命中照樣收足 1 credit——省下來的是延遲，不是帳單；增強代理和基礎抓取同價（同樣是每頁 1 credit），不必為了省錢刻意繞開。快取窗口由 max_age 參數控制（單位是毫秒；預設約兩天）：設 0 會強制重新抓取、3600000 代表一小時、86400000 代表一天；回應裡的 result.metadata.cache_state 會回報 "hit" 或 "miss"。
安全要求高的場景可以啟用 Firecrawl 的 Lockdown Mode：設定 lockdown=True 之後，端點只從既有索引提供資料，不再對外發出任何新請求；URL 若不在快取裡，就直接回傳錯誤。對必須嚴格管控出站流量、或要求從索引快照做確定性重放的環境來說，這個模式非常合用。
批次任務與需要互動的頁面
面對數百甚至數千個 URL，單筆呼叫根本應付不來。Firecrawl 備有 batch_scrape()（同步）與 start_batch_scrape()（非同步）兩種方法，讓你一次提交整批任務，之後靠輪詢或回呼收取結果。
另一個好用的功能是 actions 參數。你依序定義 click、type、wait、screenshot 這類動作，Firecrawl 就會先在頁面上完成互動、再回頭抓取內容。官方教學示範了登入測試網站、並擷取登入後截圖的流程。凡是需要填表單或點按鈕的情境，這項功能都相當關鍵。
動手前的務實建議
第一次嘗試的話，最省事的路徑是用 cURL 直接打 REST API。等格式與成本都確認無誤，再換成 Python 或 Node SDK 接進應用程式。團隊若平常就在用 Claude Desktop 或 Cursor，Firecrawl 也提供 MCP 伺服器，模型能直接呼叫 firecrawl_scrape，一行程式都不必寫。
最精簡的 cURL 請求如下，先用它確認回傳格式，再進行後續整合：
curl -X POST https://api.firecrawl.dev/v2/scrape \
-H "Authorization: Bearer $FIRECRAWL_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com", "formats": ["markdown"]}'最後提醒一件事：快取不會幫你省 credits，卻能把延遲壓低一大截。更新頻率不高的頁面，只要把 max_age 設得合理（例如 86400000，也就是一天），多個請求就能共用同一份快取，省掉不必要的重複抓取。
Firecrawl 並非萬能——碰上登入之後還要連續多步操作的複雜流程，仍得搭配 actions 或自行處理 session。但對絕大多數「給我這個 URL 的乾淨資料」的任務來說，/scrape 端點已經把進入門檻壓得夠低了。