markitdown vs anydoc - 文档转 Markdown 工具深度对比
markitdown 和 anydoc 是当前最常被放在一起比较的两个开源"文档转 Markdown"工具——前者来自微软，后者来自 Firecrawl，都是免费的，都号称给 LLM 喂干净文本。但当你真的拿一批真实文档跑一遍，差距是数量级的。
本文基于 Firecrawl 官方基准（100 份真实文档、14 种格式、7 工具横向对比）做客观拆解，不吹不黑，先摆数据再给结论。
一图看懂：关键指标对比
| 指标 | anydoc | markitdown | 说明 |
|---|---|---|---|
| 所属 | Firecrawl（开源 Rust 库） | 微软（开源 Python 库） | 生态背景不同 |
| 格式覆盖 | 14/14 | 6/14 | 基准实测，anydoc 全支持 |
| 中位转换耗时 | 4.4ms | 134.8ms | 快 30 倍+ |
| 综合评分（100） | 81 | 33 | 完整度/结构/保真/干净度四维 |
| 完整度（信息保留） | 87 | 65 | 喂 LLM 最看重的一项 |
| 干净度 | 81 | 60 | 噪音剔除程度 |
| 结构还原 | 79 | 78 | 基本打平 |
| 格式保真 | 78 | 66 | anydoc 领先 |
| 语言绑定 | Rust/Node/Python/WASM/CLI | Python（有 CLI 和 .NET 端口） | anydoc 五端 |
| Agent 集成 | Agent Skill 一条命令 | 需自行封装 | anydoc 开箱即用 |
| 转换方式 | 纯本地，无依赖（无需 LibreOffice/OCR） | Python 生态，可扩展插件 | 部署复杂度不同 |
数据来源：anydoc 官方仓库 benchmark（100 份真实文档，含 doc/docx、ppt/pptx、xls/xlsx、odt/ods/odp、rtf、epub、csv、pdf 等）。
先说结论
- 追求"任何格式都能转、转得又快又干净、还要喂给 AI" → 选 anydoc。格式全覆盖、速度一个量级领先、质量全面占优，五端绑定 + Agent Skill 让它和 LLM 工作流天然契合。
- 已经在 Python 项目里、只需要转 Office 三件套（docx/xlsx/pptx）、想要微软生态周边 → markitdown 依然可用，社区久、插件丰富，但要在 6/14 的覆盖和 30 倍速度差距上做取舍。
定位差异：一个"Python 工具"，一个"转换引擎"
markitdown 是什么
微软开源（github.com/microsoft/markitdown），定位是"Python 库 + CLI"，把常见文档转成 Markdown 供 LLM 使用。它的优势：
- 生态成熟：2024 年开源后社区热度高，Python 开发者熟悉，文档和第三方集成多
- 可扩展：插件体系支持扩展新格式（如通过 OCR 插件处理图片型 PDF）
- 微软背书：在 Microsoft 生态（Copilot 相关工具链）里有应用
它的代价（基准实测）：
- 格式覆盖 6/14：Word、PPT、Excel、PDF、CSV、EPUB 等有覆盖，但 OpenDocument（odt/ods/odp）、RTF、xlsb 等缺失
- 中位耗时 134.8ms——比 anydoc 慢一个数量级，批量管道里体感明显
- 综合评分 33，其中完整度 65（信息丢失率偏高，喂 LLM 时这是硬伤）
- 强依赖 Python 运行时，部分格式走在线服务（如 image 格式通过 LLM 描述），需要网络
anydoc 是什么
Firecrawl 开源（github.com/firecrawl/anydoc），定位是"Rust 转换引擎 + 五端绑定"，也是 Firecrawl Parse 的底层引擎。它的优势：
- 格式全覆盖 14/14：基准里唯一全支持的转换器
- 毫秒级：4.4ms 中位耗时，纯本地 Rust 解析，无 LibreOffice、无 OCR 服务、无 ML 模型
- 质量全面占优：完整度 87 意味着最少的信息丢失——这正是"文档→LLM"场景的核心诉求
- 五端绑定：Rust / Node.js / Python / 浏览器（WebAssembly）/ CLI，同一套 API
- Agent 就绪：
npx skills add firecrawl/anydoc一条命令，Claude Code / Codex / Cursor 直接读办公文档
逐项深挖
1. 格式覆盖：14 vs 6，差距在"小众格式"
| 格式 | anydoc | markitdown |
|---|---|---|
| Word（.doc/.docx/.docm） | ✅ | ✅ |
| PPT（.ppt/.pptx 等 7 种） | ✅ | ✅ |
| Excel（.xls/.xlsx/.xlsm/.xlsb） | ✅ | ✅ |
| OpenDocument（.odt/.ods/.odp） | ✅ | ❌ |
| RTF | ✅ | ❌ |
| EPUB | ✅ | ✅ |
| CSV | ✅ | ✅ |
| PDF（文本型） | ✅ | ✅ |
日常只碰 Office 三件套，两者都够用；一旦遇到 OpenDocument、RTF、xlsb 这类"办公长尾格式"，markitdown 会直接不支持——而 anydoc 一条代码路径全包。
2. 速度：4.4ms vs 134.8ms
基准中位耗时：anydoc 4.4ms，markitdown 134.8ms——30 倍差距。背后的原因：
- anydoc 是纯 Rust 原生解析，无解释器开销、无进程边界
- 所有格式统一进一个文档模型、一个序列化器，没有"格式→格式"的中转
- 页眉页脚页码按设计剔除，不做无用功
在实时解析、批量管道、Agent 循环里，这个差距直接决定"能跑"还是"慢到不想用"。
3. 质量：81 vs 33，完整度是硬伤
基准的四维评分（满分 100）：
| 维度 | anydoc | markitdown |
|---|---|---|
| 完整度 Completeness | 87 | 65 |
| 结构 Structure | 79 | 78 |
| 保真 Fidelity | 78 | 66 |
| 干净度 Cleanliness | 81 | 60 |
| 综合 | 81 | 33 |
完整度差 22 分意味着什么？喂给 LLM 的 Markdown 会系统性丢信息——合并单元格、嵌套列表、脚注、演讲者备注这些结构细节，markitdown 丢失率明显更高。结构维度接近（78 vs 79），说明"能转的格式"两者都不错；差距主要在覆盖不足带来的整体拖累和信息保留率。
4. 生态与集成
- markitdown：Python 单生态；CLI + 库；插件扩展；微软官方维护；社区教程多
- anydoc：Rust 原生 + Node/Python/WASM/CLI 四端端口；浏览器端纯本地转换、文件不出设备；Agent Skill 一条命令接入 Claude Code / Codex / Cursor；MIT 协议与 markitdown 相同（MIT）都可商用
5. 对 LLM / Agent 工作流
- anydoc 的"完整度优先 + 噪音剔除"设计就是冲着 LLM 去的，且有 Agent Skill 直接打通
- markitdown 需要自己封装成工具函数，且完整度短板会在长文档上放大
场景选型建议
| 你的场景 | 推荐 | 理由 |
|---|---|---|
| 任何格式都要转（含 ODF/RTF/xlsb） | anydoc | 14/14 全覆盖 |
| 批量管道 / 实时转换 / 高吞吐 | anydoc | 快 30 倍 |
| 喂给 LLM / Agent 做文档理解 | anydoc | 完整度 87 + Agent Skill |
| 敏感文档，要求文件不出设备 | anydoc | 浏览器 WASM 本地转换 |
| Python 项目里只想转 Office 三件套 | markitdown 或 anydoc 均可 | 前者生态熟，后者更快更全 |
| 扫描版 PDF 需要 OCR | 都不行 → 用 Firecrawl Parse | anydoc 同源引擎 + OCR |
常见问题
可以同时用吗？
可以。anydoc 转 Office/PDF/ODF 全家桶，markitdown 的插件生态处理特殊场景（如 HTML 清洗），两者都是 MIT，混用无冲突。
markitdown 支持扫描版 PDF 吗？
markitdown 原生也不支持纯扫描 PDF，需要通过 OCR 插件/LLM 描述扩展；anydoc 明确不支持扫描 PDF（返回 Unsupported），需要 OCR 场景建议走 Firecrawl Parse（anydoc 同源转换链 + OCR）。
哪个上手更快？
论"一条命令开始转"：anydoc 的 CLI（npx @firecrawl/anydoc report.docx）和 Agent Skill 最快；markitdown 需要 pip install markitdown + Python 环境。论"Python 生态熟悉度"：markitdown 对 Python 开发者更亲切。
性能数据可信吗？
两个数据点交叉验证：Firecrawl 官方基准是公开可复现的（bench 脚本在仓库里），且 4.4ms vs 134.8ms 的差距与两者实现方式（Rust 原生 vs Python 解释执行）的工程常识一致。你也可以用自己的文档集跑一遍（anydoc 仓库自带 benchmark 工具）。