anydoc：Firecrawl 出的 Rust 文档转 Markdown，4ms 转换、14 种格式干翻 MarkItDown

项目名：anydoc（firecrawl/anydoc） GitHub：https://github.com/firecrawl/anydoc ｜在线 Demo：anydoc by Firecrawl 版本：持续更新中｜协议：MIT ｜ Star：18000+（截至 2026-08-24）语言：Rust ｜绑定：Node.js / Python / Rust / WebAssembly ｜适用：跨平台

开篇：MarkItDown 很好，但遇到老 `.doc` 和 2003 的 PPT 就歇菜

做 RAG、喂 AI 文档、处理知识库的人，大概率用过微软的 MarkItDown（我之前也专门写过一篇）。它把 Office 文档转 Markdown，日常够用，但有几个硬伤：

格式覆盖不全 ：老格式 .doc、.ppt、.xls、RTF、OpenDocument 很多转不动；
纯 Python 慢：一个稍大的文档要一两百毫秒甚至更久；
表格、公式、脚注经常丢：转出来的 Markdown 结构残缺，AI 读起来费劲。

最近 Firecrawl 团队（就是那个做网页抓取 Parse 的）开源了一个 Rust 重写 的文档转 Markdown 库，叫 anydoc，8 月初上线，不到一个月冲到 18k Star。它放出的 benchmark 很嚣张：

14 种格式全覆盖，中位转换时间 4.4ms，综合评分 81 分------全部干翻 MarkItDown（6/14 格式、134.8ms、65 分）。

这篇我从它强在哪、benchmark 细节、CLI/Node/Python/Rust 四种用法、Agent Skill、踩坑讲透。如果你正在做文档 → Markdown → AI 的链路，这篇值得看。

[anydoc 到底是什么](#anydoc 到底是什么)
[为什么比 MarkItDown 强：格式 + 速度 + 结构](#为什么比 MarkItDown 强：格式 + 速度 + 结构)
[Benchmark 逐项拆解](#Benchmark 逐项拆解)
[CLI 上手：一行命令转文档](#CLI 上手：一行命令转文档)
[Node.js / Python / Rust 三种绑定](#Node.js / Python / Rust 三种绑定)
[Agent Skill：让 AI 自己读 Office 文档](#Agent Skill：让 AI 自己读 Office 文档)
它强在哪：几个关键设计
常见坑和解决方案
[适合谁 / 不适合谁](#适合谁 / 不适合谁)

一、anydoc 到底是什么

官方一句话：

一个快速的 Rust 库，把 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB、CSV、PDF 转成干净的 GitHub 风格 Markdown（GFM）。

它有四个关键身份：

身份	说明
Rust 库	`cargo add anydoc`
Node.js 库	`npm install @firecrawl/anydoc`
Python 库	`pip install firecrawl-anydoc`
Agent Skill	`npx skills add firecrawl/anydoc`

它还是 Firecrawl Parse 的底层引擎------你没自己跑 anydoc 也没关系，Firecrawl 的托管 API 用的就是它，扫不动的扫描版 PDF 还会叠加他们自己的 OCR 模型。

二、为什么比 MarkItDown 强：格式 + 速度 + 结构

三个维度，逐个说。

2.1 格式覆盖：14/14 vs 6/14

anydoc 支持的格式（14 种，全）：

类别	扩展名
Word	`.doc` `.docx` `.docm`
PowerPoint	`.ppt` `.pps` `.pot` `.pptx` `.pptm` `.ppsx` `.ppsm`
Excel	`.xls` `.xlsx` `.xlsm` `.xlsb`
OpenDocument	`.odt` `.ods` `.odp`
RTF	`.rtf`
EPUB	`.epub`
CSV	`.csv`
PDF	`.pdf`

MarkItDown 只覆盖其中 6 种（老 .doc/.ppt/.xls、RTF、OpenDocument 都搞不定）。对历史文档多的企业知识库来说，格式覆盖是硬门槛。

2.2 速度：纯 Rust，无 ML、无外部服务

anydoc 是纯 Rust 实现，没有 ML 模型、不调外部服务 ，中位转换 4.4ms/文档。MarkItDown 是 Python，134.8ms。差一个数量级。

批量处理几百上千份文档时，这个差距就是「秒级」和「分钟级」的区别。

2.3 结构：完整 + 统一

统一输出 ：不管输入是 2003 的 .doc 还是昨天的 .pptx，都走同一个文档模型 + 同一个 Markdown 序列化器，转义、表格、标题锚点、脚注行为完全一致；
完整结构：标题锚点、粗斜体/删除线、行内代码和代码块、链接和内部交叉引用、有序/无序/嵌套/任务列表（保留原始编号）、合并单元格表格、引用块、脚注尾注、演讲者备注；
公式转 LaTeX ：Word/PowerPoint 的 OMML、OpenDocument/EPUB 的 MathML、RTF 公式，全转成 GitHub 风格 $...$ 和 $$ 块。

三、Benchmark 逐项拆解

官方在 100 份真实文档、14 种格式上，把 anydoc 和 6 个同类工具做了对比。评分 0-100（越高越好），速度是中位转换耗时。

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

几个关键结论：

anydoc 是唯一覆盖全部 14 种格式的工具；
每一种格式的评分都是第一（分格式表格里 docx 88、rtf 88、epub 77、pptx 74、xlsx 72...全部领先）；
速度比第二名快一个数量级（4.4ms vs mammoth 的 52.5ms，且 mammoth 只支持 1 种格式）。

评分方法也很硬核：用 Claude Sonnet 5 当 LLM 裁判，盲评两个工具的输出，跟 ground truth（文档前 6 页渲染图）对比，每对评两次交换顺序抵消位置偏差，共 482 次判决 。数据开源在仓库 bench/ 里，想复核自己去跑。

四、CLI 上手：一行命令转文档

4.1 用 npx（最省事）

复制代码

# 转 docx，输出到 stdout
npx @firecrawl/anydoc report.docx

# 转 pptx，写到文件
npx @firecrawl/anydoc slides.pptx -o slides.md

# 从 stdin 读 CSV
npx @firecrawl/anydoc - --format csv < data.csv

npx 第一次运行会自动下载你平台对应的预编译二进制。

4.2 全局安装

复制代码

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

4.3 在线 Demo（不装任何东西）

浏览器打开 anydoc by Firecrawl，它把库编译成了 WebAssembly，文件在本地转换，不会离开你的机器。适合先试一个文档看看效果。

五、Node.js / Python / Rust 三种绑定

5.1 Node.js

复制代码

npm install @firecrawl/anydoc

复制代码

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

const markdown = await toMarkdown('report.docx');      // 从文件路径
const fromBytes = await toMarkdownBytes(bytes);         // 从字节，自动检测格式
const fromCsv = await toMarkdownBytes(bytes, 'csv');    // CSV 这种无签名格式需要显式命名
const document = await toDocument(bytes);               // 停在文档模型，可拿嵌入资源

Node 转换跑在 libuv 线程池上，不阻塞事件循环。

5.2 Python

复制代码

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)

Python 转换会释放 GIL，其他线程照常跑。

5.3 Rust

复制代码

cargo add anydoc

复制代码

let markdown = anydoc::to_markdown("report.docx")?;
let markdown = anydoc::to_markdown_bytes(&bytes, None)?;
let markdown = anydoc::to_markdown_bytes(&bytes, Some(anydoc::Format::Csv))?;
let document = anydoc::to_document(&bytes, None)?;

六、Agent Skill：让 AI 自己读 Office 文档

这是 anydoc 最「AI 原生」的一点------它直接打包成了一个 Agent Skill：

复制代码

npx skills add firecrawl/anydoc

装上之后，你的 AI 编程工具（Claude Code、Codex、Cursor、OpenCode 等）遇到 Office 文档能自己转成 Markdown 再读，不用你手动转一遍。这个 Skill 教 agent 用 anydoc 的 CLI 干活。

做 RAG / 知识库 / AI 阅读文档类应用的人，这一条价值巨大：文档解析这条链路直接下沉成 agent 的一个技能了。

七、它强在哪：几个关键设计

7.1 基于内容的格式检测

格式是从文件内容本身 读出来的（PDF 头、RTF 分组、OLE 流名、ZIP 包 mimetype），不是看扩展名。所以扩展名标错的文档也能转对。

7.2 嵌入资源处理

图片和嵌入对象在 Markdown 里渲染成 alt 文本，原始字节仍保留在文档模型上，带 media type 标签；带外部 URL 的图片直接变成普通 Markdown 图片。

7.3 PDF 支持内置

文本型 PDF 通过它兄弟项目 pdf-inspector 本地转换，不需要 OCR 服务（扫描版 PDF 才需要 OCR，官方托管 API 里叠加了 OCR 模型）。

7.4 只在该报错时报错

转换只在「产不出任何有意义的 Markdown」时才返回 Err，并明确报出原因（ConvertError 会告诉你到底哪出了问题）。

八、常见坑和解决方案

Q1：npx 首次运行下载慢

npx @firecrawl/anydoc 首次要下预编译二进制，国内网络可能慢。可以：挂代理，或 npm install -g @firecrawl/anydoc 装一次长期用。

Q2：扫描版 PDF 转出来是空的

anydoc 对文本型 PDF 是本地转，扫描版（图片没有文字层）它读不出来。先跑 OCR（比如 ocrmypdf input.pdf output.pdf），再转。或直接用 Firecrawl 托管 API（自带 OCR）。

Q3：CSV 转不出来 / 报格式错

CSV 没有签名，得显式指定：--format csv（CLI）或 to_markdown_bytes(bytes, "csv")（绑定）。

Q4：想拿文档里的图片原始字节

用 to_document()（而不是 to_markdown()），返回的文档模型里带着嵌入资源，按 media type 取原始字节。

Q5：和 MarkItDown 怎么选

只转 .docx/.md/.html，图省事 → MarkItDown 也能用；
要处理老格式、批量、要结构完整、要快 → anydoc；
已经是 Firecrawl 用户 → 直接用它，Parse 底层就是 anydoc。

九、适合谁 / 不适合谁

✅ 适合

做 RAG / 知识库 / 文档问答，需要把各种 Office 文档喂给 AI；
要批量处理大量、格式杂乱的文档（尤其老 .doc/.xls/.ppt）；
写 Python/Node/Rust 服务，想把「文档转 Markdown」内嵌进自己的流水线；
想让 AI 编码工具「自己能读 Office 文档」。

❌ 不适合

只要转扫描版 PDF + 精准 OCR → 它不做 OCR，得配合 OCR 工具或用托管 API；
需要保留精确排版（转 Word 而不是 Markdown）→ 这是「转轻量结构」，不是排版还原。

最后总结

anydoc 是 2026 年「文档 → LLM-ready Markdown」这个细分方向里最亮眼的新星------Rust 重写、14 种格式全覆盖、4.4ms、评分全第一、还自带 Agent Skill。它把 MarkItDown 没解决好的「老格式、速度、结构完整」三个问题，一次性补齐了。

如果你正在做任何「文档进 AI」的事，npx @firecrawl/anydoc 你的文档.docx 试一下，大概率回不去 MarkItDown 了。

项目地址：https://github.com/firecrawl/anydoc 在线 Demo：anydoc by Firecrawl

anydoc：Firecrawl 出的 Rust 文档转 Markdown，4ms 转换、14 种格式干翻 MarkItDown

开篇：MarkItDown 很好，但遇到老 .doc 和 2003 的 PPT 就歇菜

目录

一、anydoc 到底是什么

二、为什么比 MarkItDown 强：格式 + 速度 + 结构

2.1 格式覆盖：14/14 vs 6/14

2.2 速度：纯 Rust，无 ML、无外部服务

2.3 结构：完整 + 统一

三、Benchmark 逐项拆解

四、CLI 上手：一行命令转文档

4.1 用 npx（最省事）

4.2 全局安装

4.3 在线 Demo（不装任何东西）

五、Node.js / Python / Rust 三种绑定

5.1 Node.js

5.2 Python

5.3 Rust

六、Agent Skill：让 AI 自己读 Office 文档

七、它强在哪：几个关键设计

7.1 基于内容的格式检测

7.2 嵌入资源处理

7.3 PDF 支持内置

7.4 只在该报错时报错

八、常见坑和解决方案

Q1：npx 首次运行下载慢

Q2：扫描版 PDF 转出来是空的

Q3：CSV 转不出来 / 报格式错

Q4：想拿文档里的图片原始字节

Q5：和 MarkItDown 怎么选

九、适合谁 / 不适合谁

✅ 适合

❌ 不适合

最后总结

开篇：MarkItDown 很好，但遇到老 `.doc` 和 2003 的 PPT 就歇菜