📝

Firecrawl 团队开源的 anydoc，纯 Rust 实现，把 14 种办公文档格式（Word/PPT/Excel/OpenDocument/RTF/EPUB/CSV/PDF）转成干净 Markdown。核心设计：所有格式先解析成同一个 Document Model 中间表示，再共用同一套 GFM 序列化器——修一个格式的 bug 全部格式受益。Claude Sonnet 5 盲测 100 份文档：中位耗时 4.4ms（pandoc 102ms 的 1/23），综合 81 分碾压 LibreOffice 39 分。格式检测看内容不看扩展名。支持 Rust/Node/Python/WASM，内置 Agent Skill 让 Claude Code 直接读文档。

anydoc：4.4ms 干翻 LibreOffice 和 Pandoc 的 Rust 文档转换库，14 种格式统一转 Markdown

做 RAG 和 AI Agent 的同学应该都经历过这种绝望：业务方甩来一个压缩包，里面 Word、PPT、Excel、PDF 什么格式都有，任务是把它们全部转成干净的 Markdown 喂给 LLM。LibreOffice 转一份要等一秒多，Pandoc 快一点但只支持 5 种格式。最后只能每种格式单独写一套解析逻辑，维护成本高到怀疑人生。

anydoc 就是来终结这件事的。

它是什么

anydoc 是 Firecrawl 团队开源的一个文档转换库，纯 Rust 实现，能把 14 种办公文档格式转成干净的 GitHub Flavored Markdown。MIT 许可证，代码全公开。

Firecrawl 就是做网站转 Markdown API 的那家公司——anydoc 已经在生产环境跑了很久，Firecrawl Parse 的文档解析底层就是它。

类别	支持格式
Word	.doc / .docx / .docm
PowerPoint	.ppt / .pps / .pot / .pptx / .pptm / .ppsx / .ppsm
Excel	.xls / .xlsx / .xlsm / .xlsb
OpenDocument	.odt / .ods / .odp
其他	RTF / EPUB / CSV / PDF

最核心的设计：一个模型，统一输出

这是 anydoc 和所有竞品最本质的区别。

大多数转换工具是”每种格式单独写一个解析器直出 Markdown“——docx 走一套逻辑、pptx 走另一套、rtf 再走一套。输出质量参差不齐，修了一个格式的 bug，其他格式该有的问题还在。

anydoc 的做法完全不同：

文档字节 → 格式检测（基于内容特征，不靠扩展名）
        → 格式解析器（doc/docx/ppt/pptx/xls/xlsx/odt/ods/odp/rtf/epub/csv）
        → Document Model（统一中间表示：块/行内元素/表格/脚注/资源）
        → GFM 序列化器 → Markdown
PDF → pdf-inspector → 直接转 Markdown

每种格式的解析器先把文档解析成同一个中间表示（Document Model），然后所有格式共用同一个 Markdown 序列化器。

这意味着：一个表格转义规则的修复，同时修复了 docx、rtf、odt 等所有格式的输出。 输出的一致性有保障，维护成本也降到了最低。

Document Model 里保留的信息相当完整：带锚点的标题层级、粗体/斜体/删除线、行内代码和代码块、链接和内部交叉引用、带原始编号的各类列表、带合并单元格和表头的表格、块引用/脚注/尾注、演讲者备注。嵌入资源也处理得干净——图片渲染为 alt 文本，原始字节保留在 Document Model 中带 media type 标记，方便后续自行处理。

格式检测：不看扩展名，看内容

很多工具靠文件扩展名判断格式，但现实中扩展名经常被改错——明明是 PDF 却被人改成了 .doc。anydoc 的格式检测直接从文件内容读取特征：

PDF：读 PDF 头
RTF：读 RTF 开放标记
OLE 格式（.doc/.ppt/.xls）：读 OLE 流名称
ZIP 包格式（.docx/.pptx/.xlsx）：读 ZIP 包的 mimetype 和 content types
CSV 这种没有内嵌标记的格式，才需要显式指定扩展名或格式参数

Rust、Node.js 和 Python 都提供了 format_from_bytes / format_from_extension / format_from_path 三个 API。

性能：不是空谈，是碾压

官方 benchmark：100 份真实文档，对比 6 个同类工具。评分由 Claude Sonnet 5 盲测，从完整性、结构保留、格式保真度、输出整洁度四个维度打分，每对输出交换顺序评判两次消除位置偏差，总共 481 次判决。

工具	支持格式	中位耗时	综合得分
anydoc	14/14	4.4 ms	81
libreoffice	12/14	1129.5 ms	39
unstructured	8/14	572.9 ms	62
markitdown	6/14	134.8 ms	64
pandoc	5/14	102.1 ms	56
docling	4/14	513.6 ms	57
mammoth	1/14	52.5 ms	69

中位耗时 4.4 毫秒，比第二快的 pandoc（102ms）快了一个数量级。按这个速度，500 个 DOCX 文件大约 2.2 秒就能处理完。

anydoc 是唯一覆盖全部 14 种格式的工具，在每一个有对比的格式上都拿了最高分（docx 86 vs markitdown 73 / docling 71；rtf 88 vs libreoffice 54；pptx 75 vs markitdown 61…）。

测试环境：Ryzen 9 9950X3D、Windows 11、64GB DDR5-6400。anydoc 和 Python 库的计时排除了进程启动开销；CLI 工具则包含进程启动，因为那是实际使用方式。

PDF 支持：不依赖 OCR 服务

文本型 PDF：通过内置的 pdf-inspector 直接转换，不调用任何外部 OCR 服务。市面上大约 54% 的 PDF 是纯文本，这部分可以直接本地转换，零网络延迟、零 API 费用
扫描版/图片型 PDF：返回 Unsupported 错误，两种选择——先用其他 OCR 工具处理再喂给 anydoc，或用 Firecrawl 的托管 API 版本（自带 OCR 模型）

多语言绑定

方式	用法
CLI	`npx @firecrawl/anydoc report.docx`；stdin：`npx @firecrawl/anydoc - --format csv < data.csv`；全局：`npm install -g @firecrawl/anydoc`
Node.js	`toMarkdown('report.docx')`，线程池执行不阻塞事件循环
Python	`anydoc.to_markdown("report.docx")`，转换时释放 GIL
浏览器 (WASM)	`@firecrawl/anydoc-wasm`，文件本地转换不上传任何服务器，官方在线 Demo 也是这个
Rust	`anydoc::to_markdown("report.docx")?`

Agent Skill：AI 编程助手直接读文档

1	npx skills add firecrawl/anydoc

这条命令让 Claude Code、Codex、Cursor、OpenCode 等 AI 编程助手学会用 anydoc 读取文档。你的 Agent 遇到 Word 或 PDF 文件时，可以直接调用 anydoc 转成 Markdown 再处理。

错误处理：精细化的失败分类

错误类型	含义
`Unsupported`	未知格式或无法转换（如图片型 PDF）
`Malformed`	结构损坏，无法提取有意义内容
`Encrypted`	加密或密码保护
`ResourceLimit`	超出安全限制（解压、嵌套深度、节点数）
`MissingPart`	缺少必要部件
`Io`	文件读取失败

在生产 pipeline 里非常实用——你可以对不同错误做不同处理（比如把加密文件单独记录下来），而不是整个流程崩溃。

适用场景

RAG 系统的文档预处理
AI Agent 的文件读取能力
企业内部文档的索引构建
任意需要把办公文档转成 LLM 输入的环节

项目地址：github.com/firecrawl/anydoc

原文链接

https://mp.weixin.qq.com/s/XnVzKTtrKUad4rNctQqCEA