Docling 常常被拿去跟網頁爬蟲放在一起討論，但它其實不是爬蟲。它是 IBM Research 開發的文件轉換工具組——如今已成為 LF AI & Data Foundation 專案——可以把你手上的檔案（PDF、DOCX、PPTX、XLSX、HTML、圖片）轉成 Markdown 或 JSON。它自己的標語甚至直接寫著：「讓你的文件為生成式 AI 做好準備。」
所以這篇是針對轉換器的實測評測，不是針對爬蟲的測試。以下所有結果都來自一台僅用 CPU 的機器量測（macOS arm64、Python 3.14.2、Docling 2.111.0），以腳本評分，失敗項也如實記錄。這個專案規模龐大，而且每天都在變動——63,069 顆星、4,449 個 fork，且我抓取 metadata 的同一天就有更新——所以這裡看到的 issue 數量或版本號，都應視為某個時間點的截面，而不是固定不變的數字。
Docling 到底是什麼，又不是什麼
Docling 的核心資料單位是 DoclingDocument：先把文件解析成這個結構，再匯出成 Markdown、HTML、DocTags 或無損 JSON。這套程式碼採用 MIT 授權（個別模型的授權可能不同），起源於 IBM Research Zurich，而撰文當下最新版本是 v2.112.0，距離我實測前兩天才剛發布。
它最受矚目的能力，是處理 PDF 與圖片的那條路徑。這條路徑不是單純做字串解析，而是一整套機器學習模型組合：RT-DETR 版面模型、TableFormer 表格結構模型、可選的視覺語言模型，以及用於掃描檔的 RapidOCR。這些模型負責還原頁面版面、閱讀順序與表格結構。這才是最值得評測的地方；如果只是 HTML 測試，根本看不到這些能力。
有一個區別，可以省掉你一整週的困惑。Docling 不會幫你抓取任何內容。它不會渲染 JavaScript，不會突破反機器人限制，也不會爬網頁。你只要把檔案交給它，它負責理解。至於爬取，是另一類工具的工作；這點之後很重要，因為很多人會問 Docling 是否能取代 Firecrawl（答案是不能——兩者是互補的，後面我會說原因）。
第一次跑起來，沒人先提醒你的事
在 Python 3.14.2 上執行 pip install docling 很順利。接著你打開虛擬環境一看，會發現它竟然有 1.3 GB。Docling 會把整套 ML 堆疊當成硬依賴拉進來，就算你最後只轉換一個 HTML 檔也是如此：
| 相依套件 | 磁碟占用（MiB，du） |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr（含內建模型） | 72.1 |
| docling_parse | 30 |
這還是在你轉換第一個 PDF 之前。真正的摩擦點出現在第一次 PDF 轉換時，因為那時才會下載模型。在全新的、隔離的 HuggingFace cache 環境中，第一次 PDF 轉換約花了 224 秒——而且幾乎全部時間都耗在下載，不是推理。版面模型加上 TableFormer 模型落地後，磁碟占用約 506 MiB（TableFormer 342 MiB + layout 164 MiB，經 du 驗證），RapidOCR 則會把約 40 MB 的 PP-OCRv4 權重下載到 site-packages。同一份檔案第二次轉換呢？0.55 秒。 模型快取後，就只需要付一次過路費。
有一個數字你要直接忽略：coldstart 腳本印出的 model_download_mb 是 1060.2。這個數字不能拿來當實際占用。原因是它用了 os.walk 並追蹤 symlink，而 HuggingFace cache 會先把模型檔案各存一次在 blobs/，再透過 snapshots/ symlink 重新暴露出來——所以那次 walk 把 14 個模型檔算了兩次。與 du 相符、且去除 symlink 重複計算後的數值是 約 506 MiB（只看 blobs 則是 505.4 MiB）。對任何要評測 Docling 的人來說，重點是：下載量與磁碟落地量要分開報，因為它們本來就不是同一件事。
另外還有一個坑，會卡到要把 Docling 打包進容器的人。這些權重分別在兩個位置、兩套時程下載。layout 與 TableFormer 模型會遵守 HF_HOME，並在第一次 PDF 轉換時下載；但 RapidOCR 的模型不會——它們會直接落到 …/site-packages/rapidocr/models/，完全繞過你的 cache 設定。如果你要預先打包映像檔，或是在離線環境部署，兩套快取都得處理，光設 HF_HOME 是不夠的。
不過也要講公道話。自從 Docling 前期版本之後，專案推出了 docling-slim——一個約 50 MB 的核心包，讓你可以用 pip install docling-slim[format-html] 來處理 HTML，而不用硬拖 torch 進來。所以預設 docling 套件的 1.3 GB वजन 是真的，但現在已經可以選擇避開。這次我測的是預設套件，因為 pip install docling 預設就是這樣；但它的沉重並不是沒人處理的缺陷——對應的模組化解法已經存在，並追蹤在 issue #2393。
安裝過程中，我也碰到一個很小但值得記下的使用體驗問題：import docling; docling.__version__ 會丟出 AttributeError: module 'docling' has no attribute '__version__'。這個模組本身沒有暴露版本號。可行的查法是 importlib.metadata.version("docling")，它會回傳 '2.111.0'。這只是小小的 DX 不便，而且自 2026 年 7 月起就已在上游以 issue #3733 開著。
表格保真度：TableFormer 真正值回票價的地方
表格是大家會想拿 Docling 來做，而不是用單純 PDF 轉文字的主要原因，所以我做了七份含機器可讀 ground truth 的表格 PDF，並逐格評分。這裡有兩個重要指標，而且它們不是同一件事：cell recall 是 ground truth 的值有多少被找進了偵測到的表格裡；in-row rate 是這些值有多少進到了正確的列。把這兩者混為一談會讓工具看起來比實際更好，所以我兩個都列出來：
| 表格（壓力測試） | 是否偵測到 | Cell recall | In-row rate | 備註 |
|---|---|---|---|---|
| T1 有框線的簡單網格（8 列 × 5 欄），單獨放在一頁上 | 否 | 0.0 | — | 被分類成 <!-- image -->，所有儲存格都掉了 |
| T2 無框線（只有表頭底線） | 是 | 1.00 | 1.00 | 完美，格線正確 |
| T3 兩層合併欄標題（colspan） | 是 | 1.00 | 0.97 | 所有值都有找到；但有一個表頭值跑到下一列 |
| T4 合併列標籤（rowspan），單獨放在一頁上 | 否 | 0.0 | — | 被分類成 <!-- image --> |
| T5 colspan 表頭 + 無框線 | 是 | 1.00 | 0.97 | 所有值都有找到；與 T3 一樣有表頭列偏移 |
| T6 財務表、空白欄、靠右對齊 | 是 | 1.00 | 1.00 | 空白欄有保留，沒有被移位 |
| T7 寬版 12 欄網格 | 是 | 1.00 | 1.00 | 寬表沒有欄位偏移 |
在 Docling 有偵測到的五張表裡，所有 ground truth 值都完整還原——cell recall 全部都是 1.00。其中三張表，每個值也都落在正確的列上。至於兩個多層表頭案例（T3、T5），有一個表頭值會從原本的列滑掉，讓 in-row rate 降到 0.97——資料都在，只是遇到堆疊式表頭時，列對齊會有一格飄移。
比較難的結構情況，其實比我預期中還穩。兩層 colspan 的表頭被正確攤平成 GitHub-flavored Markdown（"Q1 2026" 標籤跨兩欄重複出現，這正是把 colspan 轉成 GFM 時該有的表現）。只有表頭線的無框線表格（T2）也完全正確。12 欄的寬表（T7）沒有欄位偏移。空白的財務欄（T6）也以空儲存格保留下來，沒有被刪掉或壓縮。這和 官方 TableFormer TEDS 分數 一致——simple 95.4、complex 90.1、all-tables 93.6——模型卡上也明顯高於 Camelot（73.0）與 EDD（88.3）。
不過合併儲存格還是要小心，因為有一個開放 issue 的說法跟我的結果相反。issue #3698 回報 V1 與 V2 在處理合併列與合併欄時有問題。我的測試中，簡單的 colspan（T3/T5）與 rowspan 值都有正確攤平，只有前面提到的多層表頭列偏移。但 #3698 出問題的情境是更不規則的多列／多欄合併，以及 跨頁表格——那才是最棘手的極端案例。我的測試屬於簡單端，所以正確的說法只能很精準地這樣說：這裡的簡單 colspan 和 rowspan 有被正確還原（但多層表頭可能會偏一列）；複雜且不規則的合併仍然是已知但尚未解決的問題。不能說「合併儲存格都正常」，也不能說「合併儲存格全壞了」。
陷阱：單獨放在一頁上的表格，可能直接消失
回頭看那張表——T1 和 T4 根本沒被偵測到。Docling 直接輸出 <!-- image -->，所有儲存格都丟失，而且沒有報錯。T1 明明就是一個很普通、有框線、8 列 5 欄的網格。這已經嚴重到讓我不敢直接把它歸因於表格解析能力不足，所以我做了一組腳本化 A/B 測試，想先找出真正的觸發條件。
我先排除最直覺的原因。文字層是完整的——pypdfium2 從 T1 讀到 327 個字元、從 T4 讀到 221 個字元，所以這些都是真正的數位 PDF，不是掃描影像。把 OCR 關掉（do_ocr=False）也沒用；表格還是會消失。再直接檢查 DoclingDocument，結果是 len(doc.tables) == 0，但 len(doc.pictures) == 1——也就是說，版面模型把整個表格區域判成了 Picture。
接著是關鍵測試。我把完全相同的 T1 和 T4 表格重新排版，這次在四周加上幾段普通內文，再重新轉換。這回兩張表都完美通過：len(doc.tables) == 1，正確輸出 GFM 表格，而 T4b 的 rowspan 標籤「North」也正確跨了三列重複出現。表格還是那張表，唯一改變的是它是孤零零地放在稀疏頁面上，還是嵌在文字之中。
所以真正的 caveat 不是 TableFormer 很脆弱，而是 Docling 的 RT-DETR 版面模型會利用頁面上下文；一個小表格如果孤單地放在幾乎空白的頁面上，很可能會被讀成 Picture，然後安靜地被丟掉。這在實務上很容易遇到，因為發票、規格書、裁切輸出，通常就是一頁一個表格、周圍幾乎沒有段落文字。解法不華麗但有效：給版面模型更多頁面上下文，或在轉換後檢查 doc.tables，如果某頁數量是零就標記出來。這跟 issue #3495（同一張表同時被偵測成 Table 和 Picture）有點相近，但我在公開資料裡找不到「頁面過於稀疏會觸發、單獨放置會掉、嵌入文字就正常」這個具體情況。這是我實測出來、先前未被明確記錄的現象，不是沒人知道的 bug。
真實掃描件上的 OCR：RapidOCR，不是 EasyOCR
掃描 PDF 往往是很多轉換器默默翻車的地方，所以我丟給 Docling 兩份真正的掃描檔，而且它們的文字層經量測是 0 字元——pypdfium2 回報完全沒有可回收字元，這也證明任何輸出都必然來自 OCR，而不是隨文件附帶的隱藏文字層。
單頁的 ocr_test.pdf 在 CPU 上用了 14.3 秒就乾淨辨識回來：「Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package,」一字不差地還原。四頁的 nemotron_multipage.pdf 則讓 OCR 在四頁上全部跑過一輪，總共 70.1 秒（每頁 17.5 秒），每頁都輸出重複的測試句。預設 OCR 是自動啟動的——不用額外旗標，也不用任何設定。
這裡有一個很多文章寫錯的細節：預設 OCR 引擎其實是 RapidOCR，不是 EasyOCR。我是看第一次執行時下載的 PP-OCRv4 .pth 權重才確認的。現在不少舊文章和早期 Docling FAQ 仍然寫 EasyOCR 是預設值，那已經過時了。EasyOCR 現在是可選加裝項。唯一仍然成立的提醒是：OCR 在大規模場景下會是慢路徑，而我這裡的結果全都是 CPU 上限；若換成 GPU，速度會明顯改善。
真實 PDF、閱讀順序，與每頁耗時
合成測資能證明特定行為；真實 PDF 才能證明它真的能用。我跑了兩份原生數位化的學術論文——9 頁的 Docling 技術報告，以及 15 頁的「Attention Is All You Need」，兩者都是雙欄版面，還包含表格與公式。
在那份 15 頁的 Attention 論文裡，五個章節標記——Abstract、Introduction、Background、Conclusion、References——都以文件順序出現在線性化後的 Markdown 中，儘管原始版面是雙欄的。所有內容關鍵詞（Transformer、encoder、BLEU、multi-head）也都在，而那幾張著名的多欄結果表被辨識成四張表。這就是真正的閱讀順序與欄位合併還原，也是做 RAG 分段時的核心價值——如果線性化器把雙欄頁面打散成亂七八糟的交錯文字，你根本沒辦法合理切塊。
時間結果也帶來一個反直覺的結論。每頁耗時主要取決於每頁有多少結構，而不是頁數本身。較密集的 9 頁報告每頁花了 14.95 秒——比 15 頁論文的 5.99 秒／頁 還慢——因為它每頁塞了更多表格與圖形：9 頁內有 3 張表，相較之下 15 頁論文有 4 張，而每一個結構都會觸發更多 layout 與 TableFormer 推理。這個差距其實不大，而且從絕對數量看，較密集文件的表格也更少，不是更多。所以在 CPU 上看「每頁幾秒」，反映的是結構密度，不是長度。再次強調，這只是單次 CPU 實測；它是上限，不是生產環境數字。
多格式支援與「無損 JSON」的說法
Docling 主打統一的多格式解析，所以我另外製作了一個 DOCX、一個 XLSX 和一個 PPTX，裡面都有已知內容與 ground-truth probe，接著檢查兩件事：這些 probe 是否出現在 Markdown 中，以及透過 export_to_dict() 轉 JSON 後是否還保留。
| 檔案 | 轉換時間（秒） | Markdown 中找到的 probe | Markdown 中的表格數 | JSON 是否保留 probe |
|---|---|---|---|---|
report.docx（標題 + 合併的 "Total" 表格 + 項目符號） | 0.137 | 7/7 | 1 | 是 |
workbook.xlsx（2 個工作表、空白欄） | 0.016 | 6/6 | 2 | 是 |
deck.pptx（3 張投影片、項目符號 + 表格） | 0.038 | 6/6 | 1 | 是 |
所有內容 probe 都有進入 Markdown，表格也都成功還原（包含 DOCX 裡合併的「Total」列，以及兩個 XLSX 工作表），而且每個 probe 在 export_to_dict() 之後也都還存在於 JSON 中——這就是支撐「無損 DoclingDocument」說法的證據，至少在乾淨輸入上是如此。這些格式走的是原生格式後端，而不是 ML 模型，所以處理只要幾十毫秒，而且可以完全離線運作。這個範圍是誠實的：每種格式各一個乾淨檔案，證明的是廣度，不是對病態 Office 檔案的壓力測試。
HTML：忠實，但不乾淨
這一點會直接決定 Docling 適不適合放進你的 RAG pipeline，所以請看仔細。Docling 會轉換 整個 HTML 文件，它不像 readability 那樣只擷取主內容。我透過統計 Docling 輸出中 nav、TOC、cookie 與 footer 標記行，來量化網站外殼（chrome）到底保留了多少。
| 頁面 | 非空 Markdown 行數 | Boilerplate 行數 | Boilerplate 比例 | 文章起始行 |
|---|---|---|---|---|
| Wikipedia「Web scraping」 | 255 | 34 | 13.3% | 28 |
| scrapethissite/forms | 63 | 1 | 1.6% | — |
| books.toscrape | 65 | 0 | 0.0% | — |
| quotes.toscrape | 35 | 0 | 0.0% | — |
在像 Wikipedia 這種外殼很多的頁面上，大約 13% 的 Markdown 行都是導覽、目錄或頁尾 boilerplate，而真正的文章要到第 28 行才開始——輸出一開頭是「move to sidebar / Contents / Toggle the table of contents」，結尾則是「CS1 maint… / Search Wikipedia。」在內容乾淨的頁面（books、quotes）則幾乎是 0%，所以這是模板外殼問題，不是每頁必須付出的固定成本。Docling 給你的是忠實的完整文件 Markdown，不是乾淨的主文章擷取。上游已經在 issue #1865（已關閉）與 #1930（開啟中）追蹤 HTML 外殼問題。
有兩點要講得公平。第一，針對 HTML，Docling 根本不會跑任何 ML 模型——它只是走一條以 BeautifulSoup 為基礎的簡單 pipeline。所謂「視覺模型在讀你的頁面」這件事，只適用於 PDF 和圖片；如果你丟給 Docling 的是 HTML，版面與 TableFormer 那套機制完全不會啟動。第二，PDF 路徑確實會做 header/footer 外殼分類，所以如果說「完全沒有做 boilerplate 去除」就太過頭了——真正把 chrome 原封不動交回來的，是 HTML 後端。
實際對比：Docling、Firecrawl，還有 Thunderbit 的位置
大家最常拿來跟 Docling 比的基準工具是 Firecrawl，所以這裡先放一張定位表。不過先講清楚一個前提，這很重要：這是文件層級的比較，不是同機基準測試。我沒有在這些測資上跑 Firecrawl。這裡只有 Docling 那一欄是實測，Firecrawl 那一欄則來自它的公開文件。
| 面向 | Firecrawl（依官方文件） | Docling（本文實測） |
|---|---|---|
| 核心工作 | 爬取 + 抓取即時網頁 → Markdown | 把你已持有的文件 → Markdown/JSON |
| 擷取 / JS 渲染 / 反機器人 | 有（託管瀏覽器） | 沒有——你自己提供檔案 |
| 主內容擷取 | 有 | 沒有——忠實輸出整份文件（Wikipedia 約 13% chrome） |
| PDF 表格結構（ML） | 有限 | 有——TableFormer（官方 TEDS 93.6；在本測資偵測到的表格上 cell recall 1.00、in-row 0.97–1.00） |
| 掃描 PDF / OCR | 有限 | 有——預設 RapidOCR（成功還原 0 字元文字層的掃描檔） |
| 格式廣度 | 網頁 | PDF/DOCX/PPTX/XLSX/HTML/EPUB/圖片 |
| 部署方式 | 託管 API（+ 可自架） | 本機 pip 套件，離線可用，不需要 API key |
| 安裝重量 | API key / 輕量客戶端 | 預設安裝 1.3 GB + 約 506 MiB 模型（或用 docling-slim） |
| 授權 | 商業／source-available | MIT |
一句話版本是這樣：如果你的資料在即時網路上，而且需要爬取、JS 渲染與主內容清理，那用 Firecrawl。若你手上已經有文件——尤其是 PDF、掃描檔、表格密集的 Office 檔——而你要的是忠實、離線、保留結構的轉換，以及真正的表格與 OCR 理解，那就用 Docling。它們是互補的。現實中的 pipeline 通常是一個負責爬，一個負責轉。
也因此，我得坦白談一下 Thunderbit，因為我在這裡工作；如果我假裝不是，大家反而更該懷疑。Thunderbit 和 Docling 做的不是同一件事，我不會硬把兩者說成等價。對開發者來說，Thunderbit 是 AI 抓取 API + MCP server + CLI，它處理的是 即時網頁：POST /distill 會把 URL 轉成乾淨、可直接餵給 LLM 的 Markdown（處理 JS 渲染、反機器人與 CAPTCHA，這些都是 Docling 明確不碰的），而 POST /extract 則會透過你定義的 JSON Schema 回傳符合結構的 JSON。這是 RAG pipeline 裡「抓取＋清理」的那一端。Docling 則是本機文件端——也就是你硬碟裡已經存在的 PDF、掃描檔、試算表。如果你的語料是網頁，就用 Thunderbit 的 API、MCP 工具（thunderbit_suggest_fields、thunderbit_distill、thunderbit_extract）或 CLI（npx @thunderbit/thunderbit-cli）。如果是 PDF 和掃描檔，就用 Docling。如果兩種都有——而這其實是大多數真實 pipeline 的情況——那就把它們搭配使用，兩邊都不用假裝自己是對方。
結論：先下暫定評語，但還有功課沒做完
我不打算直接給你一個 0–100 的總分，因為那樣會把 Docling 根本沒宣稱要做的事（例如爬網）也硬加進去，然後假裝彼此可比。若按維度來看，以下是我在這些測資上的結果：
- 安裝／首次執行： 偏重——1.3 GB 虛擬環境、約 506 MiB 模型、第一次 PDF 約 224 秒、熱啟動約 0.55 秒——但
docling-slim可以讓你避開這份重量。 - 表格保真度： 在表格有被偵測到時表現很強（5/5 的 cell recall 都是 1.00，in-row 介於 0.97–1.00），與官方 TEDS 敘述在這些測資上吻合。
- 表格偵測穩定度： 有稀疏頁陷阱——孤立表格可能被當成 Picture 丟掉。建議在轉換後檢查
doc.tables。 - 掃描件／OCR： 可用，預設是 RapidOCR；但在大規模下速度偏慢。
- 多格式： 穩定，而且 JSON round-trip 保留完整。
- HTML： 忠實，但不乾淨——沒有主內容擷取。
- 開發者體驗： API 簡潔，
DoclingDocument整理得很乾淨，但少了__version__。
適合誰：要為 PDF、掃描件與 Office 檔建立 RAG 或資料管線，而且希望離線、保留結構、並真正理解表格與 OCR 的團隊。不適合誰：需要即時網頁爬取或乾淨主文章 HTML 擷取的人——那是另一種工具。
而且既然這是一篇評測，不是新聞稿，限制就要寫在標籤上。這只是一次針對性的探測——7 個合成表格加 2 份真實 PDF，跑在一台僅 CPU 的機器上——不是 TEDS 規模的正式準確率基準。還有幾件事我沒測，而你在把 pipeline 壓到 Docling 上之前，最好自己先驗證：可選的 VLM（GraniteDocling）路徑、docling-slim 的實際 footprint、任何 GPU 執行、複雜與不規則的合併儲存格加上跨頁表格、公式轉 LaTeX 的保真度，以及——最容易在生產環境出意外的那個——大量批次轉換時的記憶體增長、thread/GIL 擴展能力與物件生命週期穩定性。Docling 在它聲稱的領域裡很強，這是量測出來的，不是行銷話術；但它也有真正的邊界，最好先畫清楚再拿去處理語料。先記住稀疏頁 caveat，預留首次下載的成本，並自行驗證大規模行為。
試用 Thunderbit 進行網頁資料擷取 Get Started Free
常見問題
Docling 是網頁爬蟲或爬行器嗎？ 不是。Docling 會把你已經擁有的文件——PDF、DOCX、PPTX、XLSX、HTML、圖片——轉成 Markdown 或 JSON。它不會抓取 URL、不會渲染 JavaScript，也不會處理反機器人機制。即時網路爬取是 Firecrawl 或 Thunderbit 網頁 API 這類工具的工作；Docling 是從你提供的檔案開始。
Docling 安裝包有多大？首次執行會下載多少？
預設 docling metapackage 會讓虛擬環境大約到 1.3 GB，因為它把完整 ML 堆疊都當硬依賴拉進來（光 torch 就有 536 MiB）。第一次 PDF 轉換會下載約 506 MiB 的版面與 TableFormer 模型到磁碟，外加約 40 MB 的 RapidOCR 權重，整體大約要 224 秒——幾乎全都花在下載。第二次轉換約 0.55 秒。如果你只需要輕量格式，可以用 docling-slim（約 50 MB 核心），避開這條重路徑。
Docling 會做 OCR 嗎？用的是哪個引擎？ 會。在沒有文字層的掃描 PDF 上，Docling 會自動啟動 OCR，而且我在測試中成功乾淨辨識出文字。預設引擎是 RapidOCR，不是 EasyOCR——這是舊文章很常寫錯的地方。EasyOCR 現在是可選安裝。OCR 在大規模下是慢路徑，尤其在 CPU 上更明顯。
為什麼 Docling 把我的表格變成圖片，或直接漏掉？
最可能的原因是稀疏頁效應。Docling 的 RT-DETR 版面模型會使用頁面上下文，而一個小表格如果孤零零地放在幾乎空白的頁面上，可能會被分類成 Picture 並直接丟掉，而且不報錯。同一張表只要周圍有內文，就能正常轉換。解法是讓版面模型有更多頁面上下文，或在轉換後檢查 doc.tables，如果某頁數量是零就標記出來。
Docling 跟 Firecrawl 要選哪個？ 它們做的是不同工作，所以通常不是二選一。Firecrawl 負責爬即時網頁、渲染 JavaScript、擷取主內容。Docling 負責轉換你手上的文件，並保留 PDF 表格結構與 OCR 能力，而且可完全離線。如果你的來源是網頁，就用網頁工具（Firecrawl，或 Thunderbit 的 API/MCP/CLI）。如果是 PDF、掃描檔或 Office 檔，就用 Docling。大多數真實 pipeline 兩者都會用到。
