anydoc：Firecrawl 开源的「真·MarkItDown」

🔥 一句话结论：如果你的管线要吃「用户随手上传的任何办公文档」，anydoc 是目前最省事的一层——14 种格式、单一依赖、中位 4.4ms、质量还全面领先 MarkItDown。而 PDF 那半边由 pdf-inspector 顶着，Firecrawl /parse 把两者都封装好了。

背景：文档转 Markdown 这件事一直没被做好

做 RAG、做 Agent、做任何要「喂文档给模型」的系统，第一步永远是同一个脏活：把 PDF / docx / pptx / xlsx / epub / rtf / odt 变成干净的 Markdown。

现实是没有哪个库能一个人搞定全部：

• mammoth 只吃 docx，质量不错但覆盖面为 1/14
• pandoc 覆盖 5 种，docling 4 种
• 微软的 markitdown 覆盖 6 种
• libreoffice 覆盖最广（12 种），但慢得离谱

于是每个团队都在拼装四五个库，每个库输出形状不同、失败模式不同、依赖不同。这就是 anydoc 想终结的东西。

---

anydoc 是什么

Firecrawl 在 2026 年 8 月初开源的纯 Rust 文档解析引擎，MIT 协议，仓库 firecrawl/anydoc。开源当天就冲上万星量级，定位非常克制：把办公文档转成 GitHub-Flavored Markdown，别的什么都不干。

特点：

• 纯 Rust，没有 ML 模型、没有外部服务、没有系统依赖、不需要 API Key
• 14 种格式走同一套文档模型 + 同一个 Markdown 序列化器
• 中位转换时间 < 5ms
• 提供 Rust / Node.js / Python / WebAssembly（浏览器本地转换） 四套绑定
• 顺带以 Agent Skill 形式发布，npx skills add firecrawl/anydoc 就能让 Claude Code / Codex / Cursor 直接读文档

支持格式：

类别	扩展名
Word	.doc .docx .docm
PowerPoint	.ppt .pps .pot .pptx .pptm .ppsx .ppsm
Excel	.xls .xlsx .xlsm .xlsb
OpenDocument	.odt .ods .odp
RTF / EPUB / CSV	.rtf .epub .csv
PDF	.pdf（文本型，走 pdf-inspector）

---

和 MarkItDown 正面对比

anydoc 官方在 100 篇真实文档、14 种格式上跑了对比（质量由 LLM 盲评，双向交换消除位置偏差，共 482 次判定）：

工具	覆盖格式	中位耗时	综合分	完整性	结构	格式	干净度
anydoc	14/14	4.4ms	81	87	79	78	81
markitdown	6/14	134.8ms	65	78	66	60	52
mammoth	1/14	52.5ms	70	84	71	75	51
unstructured	8/14	572.9ms	63	76	59	51	63
docling	4/14	513.6ms	57	60	60	57	51
pandoc	5/14	102.1ms	56	74	57	56	38
libreoffice	12/14	1129.5ms	40	59	42	40	24

同格式的贴身肉搏（分数越高越好）：

格式	anydoc	markitdown
docx	88	71
pptx	74	66
xlsx	72	55
xls	80	62
epub	77	72
doc / docm / ppt / rtf / odt / ods / odp	74–88	不支持

差距的三个维度：

1. 覆盖面：MarkItDown 支持 6 种，anydoc 14 种全通。老掉牙的 .doc、2009 年导出的 .xls、.odp 演示稿，MarkItDown 直接不接。
2. 速度：134.8ms → 4.4ms，约 30 倍。批量场景差异是量级级别的（官方演示：500 个 docx 1.7 秒）。
3. 干净度：52 → 81 差得最多。MarkItDown 的输出经常带一堆噪声，需要额外清洗；anydoc 因为所有格式共用一个序列化器，转义、表格、标题锚点、脚注的行为完全一致。

⚖️ 公平说一句：这份 benchmark 的语料是 Firecrawl 自己的，且在「docx 完整性」这个单项上 mammoth（95 vs 87）比 anydoc 更强。但 mammoth 只支持 docx 一种格式。要单点极致选 mammoth，要覆盖全场景选 anydoc。

---

架构：为什么它能又快又稳

document bytes
  │
  ├─► 格式检测        → 读内容标记，不看扩展名
  │                     (PDF header / RTF open group / OLE 流名 / ZIP mimetype)
  │
  ├─► 各格式 parser   → doc, docx, ppt, pptx, xls, xlsx,
  │                     odt/ods/odp, rtf, epub, csv
  │        │
  │        └─► Document 共享模型（blocks / inlines / tables / footnotes / assets）
  │                │
  │                └─► GFM serializer → Markdown
  │
  └─► PDF → pdf-inspector → Markdown

两个关键设计：

• 共享文档模型。所有格式收敛到同一棵结构树，再走同一个序列化器。意味着「给 docx 修一个表格转义 bug」自动就是给 rtf、odt、pptx 都修好了。这是它质量能全面均衡的根因。
• 按内容检测格式。不信扩展名，读文件头部的规范标记。用户把 .docx 改名成 .pdf 上传也照样能转。

---

pdf-inspector：PDF 那一半

你喜欢的 Firecrawl PDF 转 Markdown，核心其实是另一个开源库 pdf-inspector。它做的事情很聪明：

大多数 PDF 管线都押了同一个错误的赌注——「假设每一页都可能是扫描件」，于是所有页面全部走 OCR。慢、贵，而且经常还不如 PDF 里本来就躺着的原生文本准确。

pdf-inspector 不渲染任何东西，只读 PDF 内部结构（字体编码、文本操作符、图像覆盖率），逐页判断：

• 文本型页面 → 直接原生抽取，保留阅读顺序
• 扫描 / 图像页 → 标记出来并给出原因，交给视觉管线

一份 200 页的报告里有 150 页是纯文本，那 150 页就完全不碰 GPU。这就是 Firecrawl 托管的 Fire-PDF 能比旧管线快 3.5–5 倍的原因。

纯文本 PDF 的话，pdf-inspector 一个库就是完整管线。

---

怎么用

CLI（最快上手）

npx @firecrawl/anydoc report.docx               # Markdown 输出到 stdout
npx @firecrawl/anydoc slides.pptx -o slides.md  # 输出到文件
npx @firecrawl/anydoc - --format csv < data.csv # 读 stdin

Node.js

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

const md = await toMarkdown('report.docx')

// 从字节流，格式由内容自动推断
const fromBytes = await toMarkdownBytes(bytes)

// CSV 这种没有签名的格式需要显式指定
const fromCsv = await toMarkdownBytes(bytes, 'csv')

// 只要文档模型（还带内嵌资源）
const doc = await toDocument(bytes)

转换跑在 libuv 线程池上，不阻塞事件循环；Python 绑定会释放 GIL。

浏览器（WASM）

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

await init()
const markdown = toMarkdownBytes(bytes)

💡 这条对做工具站特别香：文件完全不出浏览器，纯前端就能做一个「拖进来即转 Markdown」的工具，零后端成本、零隐私顾虑。官方 demo 页 firecrawl.github.io/anydoc 就是这么跑的。

Rust

let markdown = anydoc::to_markdown("report.docx")?;
let markdown = anydoc::to_markdown_bytes(&bytes, None)?;

托管 API

不想自己跑就直接用 Firecrawl /parse：上传文件字节，返回 Markdown / JSON / HTML / links / images / summary。PDF 走 pdf-inspector + Fire-PDF（含 OCR 模型），其余走 anydoc，不需要任何配置。单文件上限 50MB，支持 Zero Data Retention。

---

错误处理值得一提

只有在「实在产不出任何有意义的 Markdown」时才返回 Err，而且错误类型是明确枚举的：

变体	含义
Unsupported	未知格式，或纯图像 PDF 这类无法转换的
Malformed	结构损坏，抽不出有意义内容
Encrypted	加密 / 密码保护
ResourceLimit	触发安全上限（解压炸弹、嵌套深度、节点数）
MissingPart	缺少必要组成部分
Io	文件读不出来

批量处理时可以精确区分「这个文件跳过就行」和「这是真 bug 要中断」，而不是笼统地吃一个 exception。仓库里还有 fixture 快照测试、变异测试和 per-format 的 cargo-fuzz 目标——工程质量比大多数同类库认真得多。

---

和 MinerU 对比：两条完全不同的赛道

MinerU（上海 AI 实验室 OpenDataLab 开源）经常被拿来和 anydoc 一起比，但两者对「表格复原」这件事的难度定义根本不同：

• anydoc：表格结构在文件里本来就是显式的（docx 的 <w:tbl>、xlsx 的 sheet 网格、pptx 的 graphicFrame），它做的是读取 + 序列化，不需要「复原」。天花板高、成本极低。
• MinerU：主战场是 PDF / 扫描件 / 图片，表格只是一堆线条和文字块，必须靠视觉模型推断行列划分与合并关系，这才是真正的「复原」。所以要 GPU，也才需要 TEDS 这种指标。

🎯 一句话：结构还在 → 用 anydoc；结构已经被压成像素 → 用 MinerU。

整体对比：

维度	anydoc	MinerU (2.5)
出品	Firecrawl，MIT	上海 AI 实验室 OpenDataLab
技术路线	纯 Rust，规则解析，零 ML 模型	1.2B 视觉语言模型（VLM）+ 可选 pipeline 模式
输入格式	14 种办公格式 + 文本型 PDF	PDF、图片、DOCX、PPTX、XLSX
输出	GFM Markdown	Markdown / JSON / LaTeX / 中间格式
表格输出形态	Markdown 表格	HTML（可表达 rowspan / colspan）
扫描件 / 图像 PDF	❌ 返回 Unsupported	✅ 自动 OCR，109 种语言
公式	不处理	✅ 自动转 LaTeX
依赖	无，可跑浏览器 WASM	推荐 16GB+ 显存，CPU 模式可跑但慢
速度	中位 4.4ms / 文档	约 2.12 页 / 秒（GPU + vLLM，OmniDocBench 实测）

表格复原能力细看

表格场景	anydoc	MinerU
docx / xlsx / pptx 原生表格	✅ 直接读结构，几乎无损	✅ 也支持，但要过一遍模型，属于降维打击
合并单元格（跨行跨列）	⚠️ GFM Markdown 表达不了 rowspan / colspan，会被拍平	✅ 输出 HTML，能保留合并关系
文本型 PDF 里的表格	⚠️ pdf-inspector 只保阅读顺序，不重建行列	✅ 版面检测 + 表格识别
扫描 / 拍照的表格	❌	✅ 主要卖点
旋转 / 倾斜表格	❌	✅ 旋转角度检测 + 几何矫正
无框线表格	❌	✅ 模型推断（也是最容易出错的一类）
跨页续表	❌	⚠️ 部分场景仍会断开

MinerU 官方在 OmniDocBench 上的表格分数（TEDS 越高越好，100 为完全一致）：

评测集	TEDS	TEDS-S（仅结构）
OmniDocBench Full（元素级）	91.10	94.48
OmniDocBench Base（端到端）	94.49	96.64
OmniDocBench Hard（端到端）	92.46	—

TEDS-S 明显高于 TEDS，说明结构（合并、行列划分）还原得比单元格文字转录更好——行列错位少，但 OCR 字符错误仍需下游校验。同榜单上 PaddleOCR-VL 的 Table TEDS 约 93.5，这一档已经是几家在互相咬。

anydoc 那边没有 TEDS，因为它的表格误差不是「识别错」而是「表达不了」——LLM 盲评里 docx 88、xlsx 72、xls 80、ppt/odp 74–88，xlsx 分数偏低主要就是宽表和合并单元格被压平导致的。

推荐的组合路由

用户上传文件
   │
   ├─ docx/xlsx/pptx/odt/rtf/epub/csv ─► anydoc（4ms，零依赖）
   │
   ├─ PDF ─► pdf-inspector 逐页判定
   │            ├─ 文本页 ─► 原生抽取（不碰 GPU）
   │            └─ 图像页 ─► MinerU / Fire-PDF（OCR + 表格识别）
   │
   └─ 图片 / 扫描件 ─► MinerU

收益很直接：一份 200 页报告里 150 页是纯文本，那 150 页就完全不用进 GPU 队列。anydoc 削掉 90% 的廉价流量，MinerU 只处理真正需要视觉理解的那部分。

🧩 如果表格里有大量合并单元格，别用 Markdown 做中间层：anydoc 可以先 toDocument() 拿共享文档模型（保留 tables 结构），自己序列化成 HTML，绕开 GFM 表格的表达力上限——这比直接换成 MinerU 划算得多。

---

什么时候选它 / 不选它

选 anydoc：

• 用户上传「什么都有」的混合文档，需要一份一致的结构化 Markdown
• RAG 入库前的批量转换，延迟和成本敏感
• 需要在边缘 / 浏览器 / 无 GPU 环境本地跑
• Agent 需要能直接读办公文档

先别急：

• 只处理 docx 且只在乎完整性 → mammoth 单项更强
• 大量扫描件 / 图像型 PDF → anydoc 本地转不了，需要 OCR，走 Firecrawl /parse 或自建视觉管线
• 需要像素级还原给人看的高保真转换 → 这类工具（含 MarkItDown）目标都不是这个

---

更大的选型地图：这类工具到底怎么分

大部分选型纠结，是因为把三个不同的问题混在了一起：

层	问题本质	输入特征	代表工具
① 结构提取	结构已在文件里，只需读出来	docx / xlsx / pptx / odt / epub / csv	anydoc、mammoth、pandoc、python-docx
② 版面理解	结构被压成坐标和线条，需要推断	文本型 PDF、多栏排版、学术论文	MinerU、Docling、Marker、pdfplumber
③ 视觉识别	连文字都得先认出来	扫描件、拍照、手写、印章	PaddleOCR-VL、dots.ocr、olmOCR、Textract

💸 成本是数量级递增的：① 毫秒级 CPU，② 百毫秒级，③ 秒级 GPU。所以工程上最重要的不是「选哪个最强」，而是别让 ① 的流量走进 ③ 的管线。

按场景选

场景	推荐	理由 / 代价
用户上传混合办公文档（SaaS 附件、知识库导入）	anydoc	零依赖、4ms、可跑 WASM。这类流量常占 80%+，用 GPU 方案是纯浪费
中文 PDF / 论文 / 研报入 RAG	MinerU	中文语料充分，公式转 LaTeX，表格出 HTML。OmniDocBench v1.6 上 95.69 分是当前 SOTA 档位，代价是要 GPU
英文文档 + 企业级治理	Docling	IBM 开源，分块策略、元数据、LangChain / LlamaIndex 整合最顺
追求吞吐 / 显存预算紧	PaddleOCR-VL	0.9B，页吞吐比 MinerU2.5 高约 15.8%，显存比 dots.ocr 省约 40%，多语言 100+
扫描件、发票、手写、身份证	专门 OCR / IDP	开源选 dots.ocr / olmOCR-2 / Nanonets-OCR2；商业选 Azure DI、Textract、Rossum。注意真实诉求往往是「抽字段」而非「转 Markdown」
不想运维，按页付费	托管 API	LlamaParse、Reducto、Mistral OCR、Firecrawl /parse。约 $0.01–0.03 / 页，小团队常比养一台 GPU 便宜

同类工具速查

纯结构解析（无模型）

• anydoc — 14 格式，Rust，4.4ms
• mammoth — 只吃 docx，语义保留最好（docx 完整性 95 分）
• pandoc — 格式转换万金油，Markdown 质量一般
• markitdown — 微软，6 格式，Python 生态友好但输出噪声多
• pymupdf4llm — 文本型 PDF 快速抽取，无版面理解

版面理解 / 开源引擎

• MinerU — 中文最强，VLM + pipeline 双模式
• Docling — IBM，工程化好，有 Granite-Docling-258M 超轻量模型
• Marker — 基于 Surya，90+ 语言，速度快，可选 LLM 增强
• Unstructured — 输出语义元素而非 Markdown，天生适合分块
• Dolphin — 视觉驱动的结构还原

OCR / 文档 VLM

• PaddleOCR-VL — 0.9B，效率标杆，Table TEDS 约 93.5
• dots.ocr — 小红书开源 1.7B，复杂表格强
• olmOCR-2 — AI2，学术文档
• DeepSeek-OCR — 极致 token 压缩路线
• Chandra、Nanonets-OCR2、Qwen3-VL — 通用 VLM 也能直接干这活
• Tesseract — 老将，无版面理解，但零成本可控

托管 API

• LlamaParse、Reducto、Mistral OCR 3、Firecrawl /parse、LandingAI ADE
• 云厂商：AWS Textract、Google Document AI、Azure Document Intelligence

务实的选型建议

选型别只看榜单分数。MDPBench 的数据很说明问题：Gemini-3-Pro 在数字原生表格上准确率 75.9%，换成拍照表格就掉到 69.2%。也就是说在真实拍摄条件下，第一名也远没到「能闭眼用」的程度。

1. 先做流量分层，把结构完好的文件用规则方案吃掉——这一步收益最确定。
2. 拿自己的 20–50 份真实脏文档做 PoC，不要相信别人的语料。
3. 表格一律考虑输出 HTML 而非 Markdown，合并单元格是 Markdown 的硬伤。
4. 给下游留校验位：TEDS-S 高于 TEDS 是普遍现象，意味着结构对了但字符可能错，关键数字要能回溯到原文页码。

---

小结

MarkItDown 那个名字起得很好，但把「Any doc in, Markdown out」这句话真正兑现的是 anydoc。覆盖面 14/14、中位 4.4ms、质量在每个格式上都拿第一、MIT 开源、四套绑定、零依赖——这已经不是渐进改良，是把「文档转 Markdown」从一个拼装工程降级成一行 import。

配合 pdf-inspector 那套「按页路由、只让该上 GPU 的上 GPU」的思路，Firecrawl 这次开源的两个库基本覆盖了真实 AI 管线会遇到的全部文档形态。

参考链接

• anydoc: https://github.com/firecrawl/anydoc
• pdf-inspector: https://github.com/firecrawl/pdf-inspector
• 官方发布博客: https://www.firecrawl.dev/blog/anydoc-and-pdf-inspector
• 浏览器 Demo: https://firecrawl.github.io/anydoc/
• Firecrawl /parse 文档: https://docs.firecrawl.dev/features/parse