Firecrawl 開源工具怎麼分工？從 anydoc 文件轉 Markdown，到 PDF、HTML 與 Agent 工作流

當手邊有一大批 docx、pptx、xlsx、PDF 或網頁檔案需要處理時，最棘手的往往不是「LLM 讀不讀得懂」，而是最前端的格式清洗與前置處理：檔案到底該轉成什麼格式？表格排版會不會跑掉？PDF 究竟是純文字還是掃描圖檔？內嵌的圖片又該怎麼保存？有沒有可能用同一個 pipeline，就同時搞定 Word、Excel 和簡報的處理？

Firecrawl 最近開源的 anydoc 正是為了解決這個痛點。它既不是新的爬蟲工具，也不是 OCR 模型，更不是一套完整的 RAG 框架，而是一個純 Rust 打造的文件轉換函式庫（library）。它的核心功能非常專一：將 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB、CSV 和 PDF 轉換為乾淨的 GitHub-Flavored Markdown (GFM)，並提供 Rust、Node.js、Python、WebAssembly、CLI 以及 Agent Skill 等多種對接管道。

單看專案名稱，很容易讓人誤以為它是 Firecrawl 網頁爬取 API 的延伸功能。但實際上，anydoc 的定位更像是整個 Firecrawl 生態系中的「本地文件導入層（local document ingestion layer）」：負責將各式檔案結構化、標準化為一致的 Markdown 或 document model，再交給後續的 chunking、embedding、LLM 資訊提取或 agent 工作流處理。

本文基於 firecrawl/anydoc 的 main 分支（commit 2d3f92397395a94cbeb6baf89e337425eae293e5，即 v0.1.5 版本），並結合 Firecrawl 官方組織下的相關專案，以及 Microsoft MarkItDown 官方 repository 的 README、source 與 package metadata 進行整理（MarkItDown 部分查核的是 main 分支的 commit fd239d5d2be43d9b68329730206b9312c7d5a388，即 v0.1.7 版本，查核時間為 2026-08-06）。由於專案與基準測試（benchmark）都在持續演進，文中提及的效能數據均為官方 README 揭露的報告結果，而非本機實測數據。

先看結論：anydoc 解決的是「檔案格式層」

這張表清楚劃分了 anydoc 的邊界。anydoc 並不是把 Firecrawl API 搬到本機執行，而是專門用來補足 Firecrawl 在網頁抓取之外、對於本地文件輸入的解析需求。

anydoc 到底是什麼？

anydoc 的核心處理流程如下：

文件 bytes
   ↓
格式偵測
   ↓
各格式 parser
   ↓
共用 Document model
   ↓
GFM Markdown serializer
   ↓
Markdown / document.assets

Word、PowerPoint、Excel、OpenDocument、RTF、EPUB 與 CSV 各自擁有獨立的解析器（parser），但最終都會被歸納到同一個文件模型（document model），再透過統一的 Markdown 序列化器（serializer）輸出。這種架構的優點在於：表格的跳脫處理（escaping）、標題錨點、清單與腳註的校正等邏輯，都能集中在共用的渲染層處理，省去為不同格式重複開發的成本。

不過 PDF 算是個例外。文字型 PDF 會直接透過 pdf-inspector 轉譯為 Markdown，並不會經過這套 Document 模型。因此，Rust API 中的 to_document 是不支援 PDF 的；如果需要 PDF 的 Markdown 輸出，建議直接呼叫 to_markdown_bytes 或其他高階 API。

支援哪些格式？

anydoc 著重保留的並非單純的純文字，而是完整的文件語意結構：

• 標題（headings）、錨點、粗體、斜體、刪除線；
• 行內程式碼（inline code）與程式碼區塊（code blocks）；
• 超連結與內部交叉引用（cross-reference）；
• 巢狀、編號、字母及工作清單（task lists）；
• 表格、合併儲存格與表頭列（header rows）；
• 區塊引言（blockquotes）；
• 腳註（footnotes）與尾註（endnotes）；
• PowerPoint 的簡報者備註（speaker notes）；
• 內嵌圖片與內嵌物件的資源元數據（asset metadata）。

在建置需要把文件餵給 LLM 的 pipeline 時，這種語意保留相當關鍵。因為模型不只需要段落文字，更需要理解表格、標題與備註之間的上下文關係。

格式偵測不是只看副檔名

anydoc 在識別檔案格式時，會優先檢查檔案內容中的容器標記（container markers）：

得益於這種機制，即使 OOXML 檔案被誤命名為 .bin，只要內容是合法的 ZIP 壓縮包，anydoc 依然能正確識別。相反地，CSV 因為缺乏這類檔案特徵（magic number），無法進行自動偵測，從標準輸入（stdin）讀取時就必須手動指定 --format csv。

以 Node.js 為例：

import {
  formatFromBytes,
  formatFromExtension,
  formatFromPath,
} from '@firecrawl/anydoc';

formatFromBytes(bytes);          // 'docx'，無法辨識時是 null
formatFromExtension('.pptm');    // 'pptx'
formatFromPath('report.odt');     // 'odt'

這套 API 的價值在於能將「副檔名是否可信」與「檔案真實格式」解耦。在批次導入外部附件時，這能提供一層基本的驗證過濾，不過這依然不能取代專業的惡意檔案安全檢測。

圖片不會神奇地變成 Markdown

由於 Markdown 語法本身無法直接封裝二進位檔案，anydoc 對內嵌圖片採取了以下處理機制：

1. 內嵌圖片會在 Markdown 文本中以替代文字（alt text）預留位置呈現；
2. 圖片的原始 bytes 則會保留在傳回的 document.assets 陣列中；
3. 每個 asset 都會附帶媒體類型（media type）以及來源區塊（source part）資訊；
4. 若圖片原本就使用外部 URL，則會直接輸出為一般的 Markdown 圖片語法。

這意味著我們必須自行設計圖片的保存與回填流程：

anydoc
  → Markdown body
  → document.assets
       ├── 存至 R2 / 物件儲存空間 (object storage)
       ├── 產生靜態 URL
       └── 回填 Markdown 圖片連結

如果只呼叫 toMarkdown，最終只會拿到文字結果。若想保留檔案內嵌的圖片，應改用 toDocument 並手動處理隨附的 assets。這部分需要自己動手，anydoc 並不會自動幫你上傳雲端或產生 CDN 網址。

安裝方式：四種 binding，加一個 CLI

CLI：最適合快速整合至批次處理 pipeline

無需全域安裝，就可以直接透過 npx 執行：

npx @firecrawl/anydoc report.docx
npx @firecrawl/anydoc slides.pptx -o slides.md
npx @firecrawl/anydoc - --format csv < data.csv

CLI 會將 Markdown 輸出至標準輸出（stdout），錯誤訊息則導向標準錯誤（stderr）。其結束代碼（exit codes）定義如下：

首次透過 npx 執行時，系統會自動下載對應平台的預編譯二進位檔（prebuilt binary）。若想在本地建立更穩定的執行環境，可以直接全域安裝：

npm install -g @firecrawl/anydoc
anydoc --help

針對超長文件，官方 Agent Skill 建議先使用 -o 參數將結果寫入檔案，再依需求分段讀取，避免一次把整份文件塞爆 LLM 的 context 視窗。

Node.js：適合整合至後端服務

npm install @firecrawl/anydoc

import {
  toDocument,
  toMarkdown,
  toMarkdownBytes,
} from '@firecrawl/anydoc';

const markdown = await toMarkdown('report.docx');
const fromBytes = await toMarkdownBytes(bytes);
const fromCsv = await toMarkdownBytes(bytes, 'csv');
const document = await toDocument(bytes);

Node.js 的 bindings 會在底層的 libuv 執行緒池（thread pool）中進行文件轉換，因此不會阻塞 Node.js 主執行緒的事件迴圈（event loop）。套件本身已內建 TypeScript 型別定義，0.1.5 版本要求 Node.js 環境為 >=20。

這很適合拿來整合到檔案上傳 API、佇列工作器（queue worker）或後台導入服務中。不過，一個單純的 library 核心並不等於一整套穩健的檔案處理 pipeline，像是檔案大小限制、暫存空間清理、病毒掃描、圖片二進位檔轉存、重試機制與資源監控，仍得由開發者在應用層自行補足。

Python：適合現有的資料科學與 RAG pipeline

pip install firecrawl-anydoc

import anydoc

markdown = anydoc.to_markdown("report.docx")
markdown = anydoc.to_markdown_bytes(data)
markdown = anydoc.to_markdown_bytes(data, "csv")
document = anydoc.to_document(data)

這裡有個小細節需要注意：安裝與 import 的名稱不同，pip 安裝時要用 firecrawl-anydoc，但在 Python 程式中則是 import anydoc。此套件要求 Python 環境為 >=3.10 並有隨附型別存根（type stubs）。由於底層核心是由 Rust 實現，轉換過程會釋放 Python 的全域解釋器鎖（GIL），方便在 Python worker 中進行多執行緒平行處理，不過實際的併發效能仍需根據自身主機資源進行壓測與調校。

Browser WASM：瀏覽器端的去中心化轉換

npm install @firecrawl/anydoc-wasm

import init, {
  formatFromBytes,
  toMarkdownBytes,
  toDocument,
} from '@firecrawl/anydoc-wasm';

await init();

const markdown = toMarkdownBytes(bytes);
const document = toDocument(bytes);
const format = formatFromBytes(bytes);

官方提供的 WASM 版本讓轉換程序能完全在瀏覽器端完成，檔案不用上傳到後端伺服器，對隱私敏感的企業內部工具或單純的 client-side 預覽非常方便。

不過，WASM API 目前屬於同步且單執行緒（single-threaded）的設計。如果直接在 UI 主執行緒轉換較大的檔案，可能會導致畫面瞬間凍結。為了維持良好的使用者體驗，建議一定要把 WASM 的運算工作移入 Web Worker 中執行。這是一項關鍵的效能限制。

Rust：直接存取核心底層

cargo add anydoc

目前 Cargo.toml 標示的最低 Rust 版本要求為 1.88。如果是想將轉換邏輯直接編譯進自家的解析服務、自訂 WASM 流程或任何 Rust 撰寫的資料處理層（data plane），直接依賴這個 Rust crate 可以獲得最無損的 API 操控與最完整的 document model。

Agent Skill：讓 AI Agent 具備文件閱讀能力

anydoc 專案內附帶了一個 Agent Skill 規格：

npx skills add firecrawl/anydoc

這個 Skill 的本質並不是用 prompt 來模擬轉換邏輯，而是教導 AI Agent 如何在執行環境中呼叫 anydoc CLI：

npx -y @firecrawl/anydoc <file>
npx -y @firecrawl/anydoc <file> -o out.md
npx -y @firecrawl/anydoc - --format csv < file.csv

同時，它也明確規範了幾條 Agent 的工作流守則：

• 執行環境需為 Node.js 20+；
• 格式優先依檔案內容自動偵測，僅在偵測失敗或處理 CSV 時才指定 --format；
• 面對超大檔案，應寫入暫存檔後再分段讀取；
• 轉換失敗時，應主動檢查 stderr 與 exit code；
• 掃描型或純圖片的 PDF 必須引導至 OCR 處理，anydoc 本身無法直接轉換；
• 在 Node.js、Python 或 Rust 專案中，應優先調用 bindings 進行整合，避免頻繁呼叫 shell 子行程（shell out）。

這個 Skill 主要扮演「工具發現機制（tool discovery）」與「執行規範」的角色，並不會自動為 anydoc 帶來 Agent 的記憶機制或多 Agent 協同編排。它只是把「文件轉 Markdown」的技能掛載到 Agent 的工具箱裡。

PDF 是最容易誤會的地方

anydoc 對文字型 PDF 的支援，在底層其實是整合了 pdf-inspector。pdf-inspector 專門用來處理 PDF 分類，並進行位置感知（position-aware）的文字擷取與 Markdown 轉換。它可以辨識出以下幾種類型：

• TextBased
• Scanned
• ImageBased
• Mixed

它可以利用字型、座標、文字流向與表格線索，盡可能還原出標題、清單、表格、多欄排版與正確的閱讀順序。但這點非常重要：它本身並非 OCR 引擎。如果是掃描文件或純圖片的 PDF，anydoc 是無法抽取文字的，並會直接回傳 unsupported 錯誤。

因此，設計上一個健全的 PDF 處理 pipeline 通常需要做前置分流：

PDF 檔案
  ↓
pdf-inspector 格式辨識
  ├── TextBased  → 本地 Markdown 抽取
  ├── Mixed      → 本地文字 + OCR 分流路由
  ├── Scanned    → 路由至 OCR 服務
  └── ImageBased → 路由至 OCR 服務

Firecrawl 官方將託管的 Firecrawl Parse 作為 OCR 的備援選項。雲端託管的 Parse 補足了 anydoc 在本地缺乏的 OCR 模型。這正是「本地開源 Library」與「雲端託管服務」的核心邊界。Parse 的當期費用需至官方 pricing 頁面查核，千萬不要因為 anydoc 是 MIT 開源，就誤以為 Parse 的雲端服務也是免費的。

Resource limits：它有安全上限，不是無限吃檔案

為了防止解壓縮炸彈（decompression bomb）、過深的巢狀結構、XML 無限展開以及過大的內嵌資源，anydoc 在原始碼中設計了幾個硬性的安全限制（Resource limits）：

這些數值是程式碼裡的「硬上限」，一旦在解析時超出限制，就會直接拋出 ResourceLimit 錯誤。一般正常大小的文件與試算表通常不會碰壁，但如果是批次處理大量來路不明的外部檔案，程式碼中務必妥善處理這個 Exception，避免系統因為未預期的錯誤而崩潰。

此外，在生產環境中，光靠 anydoc 的內建限制是不夠的，還是建議在架構層面規劃對應的防禦：

• 檔案上傳大小限制（upload size limits）；
• 請求超時時間（request timeouts）；
• 佇列能見度超時（queue visibility timeouts）；
• 整體 CPU 與記憶體配額；
• 單一用戶的併發限制；
• 暫存檔案過期清理機制；
• 隔離區（quarantine）機制以處理可疑檔案。

官方 benchmark 怎麼看？

anydoc 的 README 中提供了一組文件轉換的基準測試數據：涵蓋 14 種格式的 100 份真實文件（其中 94 份進入最終品質評估）。官方揭露的 anydoc 效能與品質指標如下：

這項測試對比了 LibreOffice、Unstructured、MarkItDown、Pandoc、Docling 和 Mammoth 等工具。品質部分是由 LLM (Claude Sonnet 5) 進行雙盲評審，比對轉換後的 Markdown 與對照組；速度測試則是在 Ryzen 9 9950X3D、Windows 11、64 GB DDR5-6400 的硬體規格下，測量 warm conversion 的耗時。

從這份官方報告中，可以看出 anydoc 的幾項設計取向：

1. 核心優勢在於「多格式支援、低延遲、一致的 Markdown 輸出」；
2. 它並非單純包裝既有的單一格式轉換器，而是試圖將多種 Office 格式、OpenDocument、EPUB、CSV 和 PDF 統一收攏在同一個流程中；
3. 官方主要強調其在特定測試集下的格式覆蓋率與結構還原度。

然而，請不要直接把這個 4.4 ms 當成實際 Production env 下的保證延遲。官方的效能測試排除了解析行程啟動（process spawn）的時間，且硬體規格極高，測試檔案集也沒有隨庫開源。加上這是在 warm conversion 狀態下的測試結果，無法代表處理超大檔案、冷啟動、WASM 環境、Python worker 併發或檔案傳輸時的實際表現。

若系統對延遲有嚴格要求，建議務必針對自家的檔案大小分佈、行程開銷與硬體規格，自行進行符合實際情境的壓力測試。

Firecrawl 開源工具怎麼分工？

Firecrawl 的 GitHub 組織底下有許多專案，它們在架構上大致可以分為以下五個層次：

另一個實力選手：Microsoft MarkItDown

提到本地文件轉 Markdown，很多人會聯想到微軟開源的 Microsoft MarkItDown。它與 anydoc 處在同一個問題空間，都是要把各種文件轉換為 Markdown 格式，以便後續餵給 LLM、做檢索或進行資料處理。

不過，兩者在架構設計與實作思路上有著明顯的差異：

MarkItDown 的實際使用方式

MarkItDown 的基本 CLI 安裝與使用路徑如下：

python -m venv .venv
source .venv/bin/activate
pip install 'markitdown[all]'
markitdown report.pdf -o report.md

如果不需要全部功能，也可以僅安裝特定格式的依賴：

pip install 'markitdown[pdf, docx, pptx]'

這是 MarkItDown 與 anydoc 在打包策略上很不一樣的地方。anydoc 直接將核心解析器編譯進 Rust crate 與各語言的 binding；而 MarkItDown 則將多數格式解析器設計為 Python 的選擇性依賴（optional extras）。如果使用 [all] 參數，將會安裝包括 python-pptx、mammoth、pandas、openpyxl、xlrd、pdfminer.six、pdfplumber、音訊／YouTube 相關套件，以及 Azure Document Intelligence／Content Understanding 等對接套件。

因此，看待 MarkItDown 所宣稱的「多格式支援」時，通常需要拆成三個層次來理解：

1. 內建核心已實現的轉換邏輯；
2. 需額外安裝 Python 依賴（extras）才能啟用的格式；
3. 需依賴外部網路、多模態 LLM 或 Azure 服務的整合路徑。

它並不是把所有能力都打包成單一個離線執行的 binary。以圖片為例，其內建轉換器主要讀取部分 EXIF 元數據，如果需要圖片的內容描述，原始碼中其實是去呼叫使用者提供的多模態 LLM Client。又以 OCR 為例，markitdown-ocr 是一個獨立的 plugin，會將 PDF、DOCX、PPTX、XLSX 中的圖片渲染後傳給相容於 OpenAI 規格的 Vision API。如果未配置 LLM Client，這項 OCR 步驟就會被直接跳過，退回到內建的純文字提取。

此外，微軟專案中也提供了 markitdown-mcp。這不是另一個解析器，而是將 MarkItDown 封裝成 MCP 伺服器，對外暴露 convert_to_markdown(uri) 工具，支援 http:、https:、file: 和 data: 等多種協定的 URI 輸入。官方 README 預設採用 STDIO 或 localhost 上的 Streamable HTTP／SSE 進行通訊，並特別提醒不要在不瞭解網路安全隱患的情況下，輕易將此伺服器綁定到 localhost 以外的公開網路介面上。

anydoc 和 MarkItDown 的 benchmark 怎麼看？

目前 anydoc 官方 README 提供的基準測試將 MarkItDown 納入了對比：

這可以作為 anydoc 專案本身在特定測試條件下的效能參考，但不宜直接解讀為「anydoc 在所有方面均優於 MarkItDown」。原因如下：

• 該基準測試是由 anydoc 維護者自行設計與執行，並非經由第三方獨立或中立機構主導的評測；
• 測試僅涵蓋 14 種特定的文件格式，MarkItDown 本身所支援的 HTML、圖像、音訊、ZIP、YouTube 連結、Outlook MSG 與 Azure 整合路徑等，並不在這十四種格式的測試範疇內；
• Anydoc 測試其 Python 程式庫時排除了處理序啟動（process spawn）的耗時，而對其他 CLI 工具卻將此耗時計入，因此在延遲（latency）的比較基準上並不完全等同。

比較務實的看法是：在 anydoc 維護者所挑選的 Office/文件測試集（corpus）中，anydoc 在格式覆蓋、熱啟動延遲以及結構化輸出上表現較為亮眼。這並不代表 anydoc 在 MarkItDown 其他專長領域（如多模態與雲端整合）有絕對優勢。目前 MarkItDown 的版本為 v0.1.7（本次查核 commit 為 fd239d5d2be43d9b68329730206b9312c7d5a388），anydoc 為 v0.1.5（commit 為 2d3f92397395a94cbeb6baf89e337425eae293e5）。由於兩個專案均處於快速迭代期，基準測試的結果也會隨時間改變。

到底該選哪個？

如果主要應用場景是混合的 Office 文件、電子書、CSV 與文字型 PDF，且希望藉由一個統一的核心，在 Node.js、Python、Rust 或瀏覽器 WASM 中獲得一致的 Markdown 格式輸出，那麼 anydoc 會是個很好的起點。其設計核心圍繞在共用的 document model、GFM 序列化、內嵌資源（embedded assets）擷取以及跨語言支援上。

相對地，如果需要的是快速、輕量地將各種來源（包含網頁、HTML、圖片、音訊或 YouTube 影片等）初步轉換為 Markdown 以供 LLM 閱讀，且不介意較多的 Python 套件依賴、plugin 擴充與外部雲端服務，那麼 MarkItDown 可能更貼近需求。它的內建轉換器種類較為多元，且自帶的 MCP 套件也能更方便地與本地 Agent 對接。

但如果是要處理「掃描版 PDF」的 OCR 需求，兩者的本地核心均無法直接在離線狀態下搞定：anydoc 明確將掃描 PDF 列為不支援，需導流至 OCR 服務；MarkItDown 則需額外搭配 markitdown-ocr，並配置 OpenAI-compatible Vision client，或改用 Azure 服務。若選擇雲端 provider，還要另外處理 credentials、API 成本與資料傳輸。此時的核心考量點應該在於：資料是否能傳輸至雲端、API 成本、資料隱私、網路延遲與錯誤重試機制，而非僅僅是比對哪一個 library 能跑出 Markdown 格式。

pdf-inspector：PDF 的本地基礎元件

pdf-inspector 與 anydoc 具有深厚的技術關聯。作為一個獨立的 Rust PDF 處理庫，它同樣提供了 Node.js、Python、WASM、Rust 與 CLI 等多種 bindings，其核心定位在於：

• 辨識 PDF 究竟是純文字、掃描文件、純圖片還是混合格式；
• 進行具備位置感知的文字擷取；
• 處理閱讀順序重建與多欄排版（multi-column layouts）；
• 在本地端重建表格、標題、清單與程式碼區塊等 Markdown 語意結構；
• 在不依賴任何外部 OCR 模型的情況下，高效解析原生的文字型 PDF。

若日常處理的資料多為原生電子財報、論文、發票或合約等文字型 PDF，先透過 pdf-inspector 來做檔案分類與初步提取是相當合理的做法。而 anydoc 則是把這項能力整合進了「多格式統一入口」的抽象層中。

html-extractor：必須已持有 HTML 原始碼

html-extractor 是一個純 Rust 實現的網頁主體內容提取器（page-type-aware content extractor），它的輸入是已經取得的 HTML 原始碼，輸出則是 Markdown、網頁類型分類、元數據以及內容提取品質評分。

它的核心處理流程如下：

HTML bytes 原始碼
  → 濾除 script / style / head / 註解等無用標籤
  → 分析並判斷網頁類型 (page type)
  → 根據文字與連結密度、標籤特徵與位置選取主樹 (subtree)
  → 遇異常時執行 fallback 降級鏈
  → 渲染並輸出 Markdown

需要特別釐清的是，它不具備網路請求或瀏覽器渲染能力，無法直接去爬取某個網址。這與 Firecrawl core 有著本質上的不同：html-extractor 的職責是「拿到了 HTML 後，如何去蕪存菁抽取主文」；而 Firecrawl 核心要解決的則是「如何成功把網頁抓下來（包括處理動態 JS 渲染、驗證碼、代理人、全站爬取與排程）」。

另外，官方標明 html-extractor 採用 Apache-2.0 授權，這與 anydoc 和 pdf-inspector 採用的 MIT 授權不同。若打算在商業專案中打包使用這些工具，別忘了留意不同元件的授權規範。

firecrawl：真正的網頁爬蟲與抓取層

Firecrawl core repo 則是定位為網頁上下文 API（web context API），解決的是爬網與抓取層面的問題，包含：

• Search（搜尋）
• Scrape（單頁抓取）
• Interact（動態瀏覽器互動）
• Agent（智慧代理路徑）
• Crawl（整站爬取）
• Map（產生網站地圖）
• Batch Scrape（批次抓取）

除了 Markdown 之外，它還可以輸出原始 HTML、網頁截圖（screenshot）與結構化 JSON。當你的應用場景涉及動態加載網頁、爬蟲模擬、瀏覽器點擊或大量網址的抓取時，才會調用到這一層。

簡單總結一下它們的定位：

• 本地檔案解析 -> 使用 anydoc
• 已取得的 HTML 內容過濾 -> 使用 html-extractor
• 網頁資料爬取與互動 -> 使用 firecrawl 核心

雖然它們最後可能都輸出 Markdown，但負責的生命週期完全不同，不應混淆。

firecrawl-mcp-server：將網頁能力橋接給 AI Agent

Firecrawl MCP Server 是一個網路能力的橋接器（adapter），而不是文件解析器。它的作用是將 Firecrawl 雲端服務的搜尋、網頁擷取、互動與分析能力，封裝成符合 MCP (Model Context Protocol) 規範的工具，以接入支援該協定的 AI Agent 系統中。

官方 README 中提供了以下啟動指令：

# 本機直接啟動
FIRECRAWL_API_KEY=fc-YOUR_API_KEY npx -y firecrawl-mcp

此外，亦可連接至官方託管的 MCP endpoint。需要注意的是，不帶 API key 的免費額度在 scrape、search、interact 等基礎工具上有著嚴格的速率限制（rate limits），而像是 crawl、map、agent、extract 等進階功能，通常需要配置有效的 API key 才能使用。

此工具的核心場景是讓 Cursor 或 Claude Code 等 Agent 能具備即時網頁搜尋與擷取能力。它無法替 Agent 讀取本地的 Word 檔案。若要實現本地檔案閱讀，依然得依賴 anydoc CLI、對應的 bindings 或 anydoc 專屬的 Agent Skill。

firecrawl/cli：終端機與 Agent Skill 的操作介面

Firecrawl CLI 主要是將網頁 API 的搜尋、爬取與抓取功能打包至終端機工具中，並用來輔助引導 skills、workflows 與 MCP 的設定：

npm install -g firecrawl-cli
firecrawl setup skills
firecrawl setup workflows
firecrawl setup mcp

這個 CLI 的設計重心在於 Firecrawl 雲端託管服務的串接與 onboard，因此執行時必須經過 Firecrawl 帳號的認證（authentication）。這點與完全離線執行、專注處理本地實體檔案的 anydoc CLI 在性質上完全不同。

web-agent 與 open-agent-builder：上層的應用編排

在整個生態的最上層，web-agent 是一個研究導向的 agent 基礎專案，其核心要素包括：

• 採用 Deep Agents 作為執行框架（harness）；
• 整合 Firecrawl AI SDK 工具箱；
• 引入 Skills、Subagents、結構化輸出與串流機制。

而 open-agent-builder 則是一套視覺化的工作流建構器，背後串接了 LangGraph、Convex、Clerk、E2B 與多個模型供應商。官方 README 明確標示該專案目前仍處於積極開發階段（active development），部分功能與介面仍在變動中。

這兩個專案並不是用來替代「文件轉換」這類底層工作的。它們的定位是在底層解析器與網頁 API 之上，建構出複雜的 Agent 決策流程、狀態管理、沙盒執行（sandbox）與可視化工作流，其系統架構複雜度與外部依賴程度均遠高於單一的檔案轉換元件。

最值得落地的三種架構組合

組合一：本地文件導入 -> RAG / 知識庫系統

上傳文件
  ↓
anydoc / pdf-inspector (本地解析)
  ↓
標準化 Markdown + document.assets
  ↓
清理 metadata、切 chunk
  ↓
計算 Embedding
  ↓
寫入向量資料庫 (Vector DB) / 全文檢索索引
  ↓
LLM 檢索生成 (提供精確來源引用)

適用情境：企業內部 Word、簡報、Excel、PDF、EPUB 等研發或營運資料的歸檔。

在這個架構中，anydoc 僅負責「文件結構的解析與標準化」這段起點。後續的 chunk 切分策略、表格結構扁平化（flattening）、內嵌圖片 OCR、embedding 模型的選用、權限控管與最終 RAG 引用來源標註，依然需要開發者在系統層自行規劃與串接。

組合二：網頁資訊 + 本地附件的混合研究流程

網頁 URL / 關鍵字搜尋
  → Firecrawl Search / Scrape / Crawl

電子郵件附件 / 使用者上傳檔案
  → anydoc / pdf-inspector

兩端資料收斂至統一的 Source Record schema
  ├── 來源網址或檔案 Hash 值
  ├── 標題 (Title)
  ├── 結構化 Markdown 文本
  ├── 圖片與物件資源 (Assets)
  ├── 擷取管道資訊 (Extraction method)
  └── 處理時間戳記 (Timestamp)

最後遞交給 LLM / 報告生成模組

這種分流架構比起「把所有不確定格式的資料一律塞進同一個入口」更為清晰。網路資訊與本地檔案各自經由專屬的讀取層解析，隨後在後端收攏為結構一致的 Source Record 資料結構，方便進行集中的語意分析或報告生成。

組合三：Agent 自主閱讀附件與網路檢索

AI Agent 決策迴圈
  ├── anydoc Agent Skill：負責本地檔案轉換 Markdown
  ├── Firecrawl MCP 適配器：負責網頁搜尋、抓取與互動
  ├── pdf-inspector 本地元件：負責 PDF 屬性分類與 OCR 分流
  └── 專案特化程式碼：負責資料整理、交叉引用與終端輸出

此模式適合用於打造自主研究型 Agent，但在工具配置上必須落實權限隔離與安全邊界：

• 本地檔案讀取工具應限縮在特定的 workspace 目錄內，避免 Agent 讀取系統敏感檔案；
• 網路爬取工具需限制存取域名、設定運算預算上限與速率限制；
• 由於 OCR 多涉及外部 API 呼叫，需考量隱私合規與對應的帳單開銷；
• 避免因為 Agent 具備了檔案讀取能力，就順便開放寫入、自動發送 PR 或直接修改生產環境程式碼等高風險操作。

費用怎麼看？Anydoc 本身和 Firecrawl hosted API 是兩條路

路線一：完全本地部署與維運

anydoc / pdf-inspector / html-extractor
  → 部署於自建伺服器 / 本地運算節點

Anydoc、pdf-inspector 和 html-extractor 都是開源專案。其中 anydoc 與 pdf-inspector 採用 MIT 授權，html-extractor 則採用 Apache-2.0 授權。走這條路線雖然沒有 SaaS 服務的 API 訂閱費用，但也需要將伺服器的運算資源（CPU/RAM）、硬碟空間、排隊佇列、備份策略與維運人力等實際隱性成本考量進去。

路線二：使用 Firecrawl 雲端託管服務

Firecrawl API / Parse / 託管型 MCP Endpoint
  → 依據官方方案、用量計費與 rate limit

Firecrawl Parse 定位為雲端託管的文件解析服務，並補足了本地 anydoc 所欠缺的 OCR 模型能力。由於官方方案與計費策略隨時可能調整，實際費用與限制請務必以官方當期的 pricing 頁面為準，不應將本地開源的 MIT 授權與託管 API 服務混為一談。同樣地，託管 MCP 服務提供的無金鑰測試額度也只適合前期開發，無法直接搬到生產環境使用。

在正式決定採用前，建議至官網重新確認以下項目：

• Parse 服務的計量方式（例如是依據文件頁數還是文件總數量計費）；
• OCR 處理是否會產生額外的附加費用；
• 各訂閱方案中所包含的基礎額度（included credits）；
• 託管 MCP 服務在各工具上的速率限制；
• 託管服務的資料保留政策（retention policy）、資料隱私與服務可用區域。

anydoc 適不適合你的情境？

總結與架構定位

從整體的工具佈局來看，Firecrawl 目前的開源專案並非疊床架屋的功能複製品，而是逐步收攏為一條層次分明的文件與網頁處理流水線：

flowchart TB
  F["Word / Excel / PowerPoint / PDF"] --> A["anydoc / pdf-inspector"]
  H["HTML bytes"] --> X["html-extractor"]
  U["URL / search / browser interaction"] --> C["Firecrawl core"]
  A --> N["Normalized Markdown + assets + provenance"]
  X --> N
  C --> N
  N --> I["RAG / knowledge-base index"]
  N --> M["CLI / MCP"]
  M --> G["Agent / workflow orchestration"]

在這一整套工具鏈中，anydoc 屬於最容易直接落地的底層元件。它的邊界定義非常明確，且運作時完全不需要依賴 Firecrawl 雲端 API：本地檔案進來，標準化的 Markdown 或 document model 出去，後續不論是要做 RAG 切片、計算 embedding、建立本地索引，還是作為 Agent 的上下文，完全交由開發者自由決定。

在實務上，建議將它放置在資料處理流程的最前端：

Word / Excel / PowerPoint / PDF
  → anydoc (結構化解析)
  → 輸出 Markdown 與 assets 元件
  ├── 用於原始資料的人工與自動化校驗 (Source verification)
  ├── 進行摘要與結構化資訊抽取 (Extraction)
  └── 最終產出：發佈至知識庫、RAG 檢索或生成報告

若資料來源是網頁，就調用 Firecrawl 核心；若遇到掃描版 PDF，則先透過 pdf-inspector 分類後導流至外部 OCR 服務；若要對接 AI Agent，就掛載專屬的 Agent Skill 或 MCP 服務。這種層次分明的架構設計，比起將所有「能輸出 Markdown」的工具籠統地視為爬蟲，在開發實作上更為清晰，也更容易精確控制整體的運算成本與安全邊界。

官方來源與查核範圍

Anydoc 與底層 parser

• firecrawl/anydoc：repo README、tree、license、benchmark、development workflow。
• @firecrawl/anydoc Node README：Node API、CLI、format detection、assets。
• firecrawl-anydoc Python README：Python API、Python version、GIL、package/import 名稱。
• Anydoc WASM README：browser API、同步執行、Web Worker 注意事項。
• Anydoc Agent Skill：CLI 入口、exit code、large document 和 OCR 邊界。
• src/lib.rs：Format、Markdown API、PDF direct conversion、to_document 邊界。
• src/package/limits.rs：固定 resource limits。
• firecrawl/pdf-inspector：PDF 分類、文字抽取、Markdown、OCR boundary。
• firecrawl/html-extractor：HTML main-content extraction、page type、quality、license。

Firecrawl web 與 agent 層

• firecrawl/firecrawl：Search、Scrape、Interact、Agent、Crawl、Map、Batch Scrape。
• firecrawl/firecrawl-mcp-server：MCP adapter、hosted endpoint、keyless tier、tool boundary。
• firecrawl/cli：CLI、skills、workflows、MCP setup、authentication。
• firecrawl/web-agent：Deep Agents、Firecrawl AI SDK、skills、subagents、structured output。
• firecrawl/open-agent-builder：visual workflow、LangGraph、Convex、Clerk、E2B 與目前的 development status。

版本與 license

• Anydoc v0.1.5 release
• Anydoc Cargo manifest：crate version、Rust version、MIT license。
• Anydoc npm package：Node package version and engine。
• Anydoc PyPI package：Python package version and >=3.10。
• microsoft/markitdown：README、支援格式、CLI、optional dependencies、plugin 與安全注意事項。
• markitdown pyproject.toml：Python version、MIT、package dependencies、entry point。
• markitdown converter source：PDF、圖片與其他 built-in converter。
• markitdown-ocr：LLM Vision OCR plugin 與掃描 PDF boundary。
• markitdown-mcp：local MCP server、URI contract 與 localhost security boundary。
• MarkItDown v0.1.7 release：目前查核到的 release ref。

本輪只做官方 repository、GitHub API、官方 package metadata 和官方產品頁的靜態查核，沒有實際安裝或執行 anydoc、pdf-inspector、MarkItDown、Firecrawl CLI、MCP server 或其他 repo。Benchmark、效能和開發中 workflow 均保留來源與版本邊界，不把 README 宣稱改寫為本機實測結果。