摘要： Firecrawl 於 4 月 28 日上線 /parse，把本地檔案送進與 /scrape 同規格的解析管線，支援八種格式、單檔 50 MB，並可在同一呼叫回傳 Markdown 與結構化 JSON。Rust 引擎平均每頁低於 400 毫秒；每次呼叫重新解析且不快取，Enterprise 方案可啟用 ZDR。
做 RAG 或文件自動化的團隊都碰過同一個卡點：網頁上的內容好抓，麻煩的是硬碟裡那些合約、報告、發票與使用者上傳的檔案——格式雜、解析與清理程式得自己寫，寫完才輪得到 LLM。Firecrawl 在 4 月 28 日上線的 /parse 端點填補的正是這段缺口：本地檔案直接上傳，拿回的輸出與網頁抓取完全同規格——PDF 保住閱讀順序與表格、Word 去除 XML 雜訊、試算表轉為整齊的 tabular Markdown；同一通呼叫裡還能順帶要求摘要，或做結構化 JSON 抽取。
網頁與本地文件，收進同一個 API
從定位看，/parse 就是 /scrape 的本地檔案版本：兩者共用同一套解析引擎，輸出格式一致，清洗、切塊、入向量庫這段下游管線因此只需要寫一份。公告把適用場景講得相當直白——合約、報告、發票、上傳檔案這些待處理的文件多半放在磁碟上而非網路上；以前這條路得自己接 OCR 或文件庫，如今它與網頁抓取收斂成同一個 API。
格式支援範圍是 PDF、DOCX、DOC、ODT、RTF、XLSX、XLS、HTML 八種，單檔以 50 MB 為限。清單以外的格式不會被勉強處理，而是直接回 UNSUPPORTED_FILE_TYPE 錯誤。已經在用 /scrape 的開發者幾乎沒有遷移成本：檔案來源從 URL 換成上傳，其餘參數與回應結構原封不動。
底層 Rust 引擎的思路：能不跑 OCR 就不跑
引擎本體以 Rust 寫成，平均每頁低於 400 毫秒即可處理完畢。設計上最關鍵的選擇是先分類、後處理，而不是把每一頁都送進 OCR：
- 原生抽取對付純文字頁：開源 Rust 函式庫
pdf-inspector直接解析 PDF 內部結構——字型、文字運算子、圖片覆蓋率——以毫秒級速度取出文字，過程中完全不需要渲染。 - GPU 留給真正需要的頁面：掃描頁與以圖片為主的頁面才會被送往 GPU 叢集，並採 lane-based 隔離，一份 200 頁的報告不會因此拖慢別人單頁發票的處理。
- 按版面調校的準確度：神經版面模型分開偵測表格、公式、文字區塊與標題，再針對各區域個別調參——表格拿到更高的 token 預算、公式以 LaTeX 保留、多欄文件的閱讀順序交由模型預測。
分層處理換來速度與成本的務實平衡：便宜的原生抽取承接純文字頁，昂貴的 GPU 資源只花在確實需要的掃描頁上。
上傳同一通呼叫，Markdown 和結構化欄位一起回
實際用起來最方便的一點，是 schema 抽取直接內建在上傳呼叫中。拿合約來說，把 JSON schema 和檔案一併送出：
import requests
import json
with open("contract.pdf", "rb") as f:
response = requests.post(
"https://api.firecrawl.dev/v2/parse",
headers={"Authorization": "Bearer fc-YOUR_API_KEY"},
files={"file": f},
data={
"options": json.dumps({
"formats": ["markdown", "json"],
"json": {
"schema": {
"type": "object",
"properties": {
"parties": {"type": "array", "items": {"type": "string"}},
"effective_date": {"type": "string"},
"total_value": {"type": "string"}
}
}
}
})
}
)
data = response.json()["data"]
print(data["markdown"])
print(data["json"])回傳內容分成兩塊：markdown 是保住表格與閱讀順序的全文，json 則是依 schema 抽出的 typed 欄位，例如當事人、生效日、總額。兩種輸出一次到手，第二段解析程式就此省下。放進 RAG 流程時，這一步的產出已經 embedding-ready——結構在、表格完整、需要時還帶摘要，切完塊就能進向量庫。
採用前先掌握的三件事：計費、快取與掃描品質
公告對自身限制沒有迴避。其一，每一通呼叫都會重新解析：沒有任何快取，同一份檔案傳第二次就再收一次費；計費方式比照 /scrape——基本呼叫一次，再加上你指定的 LLM 格式（JSON 抽取之類）。其二，掃描 PDF 的品質天花板就是掃描本身：掃得乾淨就解得乾淨，低解析度或手寫內容的輸出會打折扣，因為這種頁面終歸得靠 OCR。其三，格式與大小都是定死的：50 MB、八種格式，沒有模糊地帶。
還有一個與合規有關的細節：Enterprise 方案可開啟 Zero Data Retention（ZDR），解析輸出因此不會落地保存。對需要處理合約、醫療記錄或內部報告的團隊而言，把文件管線交給第三方服務之前，這一項得先確認。
開發者視角：兩個立刻能落地的場景
/parse 現在開放給所有 Firecrawl API 使用者。馬上能派上用場的有兩種情境：
- 產品內的檔案上傳流程：使用者把 PDF 或 DOCX 丟進你的產品，一通呼叫換回 Markdown 加結構化欄位；之後無論進向量庫、觸發 workflow 或寫入資料庫，面對的都是同一種格式。
- 單一文件管線：Email 附件、下載的報表、網頁內容、使用者上傳——四種來源都交給 Firecrawl，輸出規格統一，自己要維護的解析器又少一套。
導入做法不複雜：先抓一批你真的會遇到的文件——掃描件與多欄表格尤其要包含——實際跑過一輪檢查輸出品質。掃描品質和版面複雜度是左右結果的最大變數，自己測一次永遠比規格表可靠。若工作流程會反覆碰到同一批檔案，記得把「不快取、按次計費」寫進成本模型；考慮在自己的系統層快取解析結果，同一份未變動的文件重複處理時就不再付費——在官方的計費設計下，這是最直接的成本槓桿。