AnyDoc

它解决的是哪一层问题

它是单文档级别的转换库，不是抓取服务，不起服务、不跑模型。

定位一句话：把 office 文档变成 LLM 能直接用的干净 Markdown。

MIT 许可，Firecrawl 出品。它也是 Firecrawl Parse（在新标签页打开） 的底层实现——不想自己跑就用托管 API。

架构：一个模型，一个序列化器

这是理解它全部优势的钥匙：

text文档字节
  │
  ├─► 格式识别      → 看内容标记，不是看扩展名
  │
  ├─► 格式解析器     → 每种格式一个（doc, docx, ppt, pptx, xls,
  │                   xlsx, odt/ods/odp, rtf, epub, csv）
  │         │
  │         └─► Document  → 共享模型：块、行内元素、表格、
  │                          脚注、资源
  │               │
  │               └─► GFM 序列化器 → Markdown
  │
  └─► PDF → pdf-inspector → 直接出 Markdown

所有格式都汇进同一个文档模型和同一个序列化器，所以输出端的怪癖只修一次。

README 里那句原文很值得记住：

a table-escaping fix for docx is automatically a table-escaping fix for rtf, odt, and everything else.

给 docx 修的表格转义问题，对rtf、odt 和其他所有格式同时生效。

五套接入方式

Agent skill

bashnpx skills add firecrawl/anydoc

装完agent 就能读它遇到的任何 office 文档。兼容 Claude Code、Codex、Cursor、OpenCode 等。

CLI

bashnpx @firecrawl/anydoc report.docx               # 输出到stdout
npx @firecrawl/anydoc slides.pptx -o slides.md  # 输出到文件
npx @firecrawl/anydoc - --format csv < data.csv # 从 stdin 读
npx @firecrawl/anydoc scan.pdf --ocr hosted     # 扫描版走托管 OCR

npx 首次运行会下载对应平台的预编译二进制。要永久命令就 npm install -g @firecrawl/anydoc。

Node.js

bashnpm install @firecrawl/anydoc

javascriptimport { toDocument, toMarkdown, toMarkdownBytes } from "@firecrawl/anydoc";

// 从文件路径
const markdown = await toMarkdown("report.docx");

// 开OCR
const withOcr = await toMarkdown("report.docx", { ocr: "hosted" });

// 从字节，格式靠内容识别
const fromBytes = await toMarkdownBytes(bytes);

// 显式指定格式，CSV 这类无签名格式需要
const fromCsv = await toMarkdownBytes(bytes, "csv");

// 只要文档模型（内含嵌入资源）
const document = await toDocument(bytes);

Node 的转换跑在 libuv 线程池上，不阻塞事件循环。 TypeScript 类型随包发布。

Python

bashpip install firecrawl-anydoc

pythonimport anydoc

# 从文件路径
markdown = anydoc.to_markdown("report.docx")

# 开 OCR
markdown = anydoc.to_markdown("scan.pdf", ocr="hosted")

# 从字节，按内容识别格式
markdown = anydoc.to_markdown_bytes(data)

# 无签名格式需要显式指明
markdown = anydoc.to_markdown_bytes(data, "csv")

绑定会释放 GIL，所以其他线程照常运行。 带类型存根。

浏览器（WebAssembly）

bashnpm install @firecrawl/anydoc-wasm

javascriptimport init, { toMarkdownBytes, toDocument } from "@firecrawl/anydoc-wasm";

await init();

const markdown = toMarkdownBytes(bytes);
const fromCsv = toMarkdownBytes(bytes, "csv");
const document = toDocument(bytes);

这一条对隐私敏感场景最有用。 官方有个浏览器演示页（在新标签页打开），跑的就是 WASM 版本，文件在本地转换，完全不离开机器。

Rust

bashcargo add anydoc

crate 版本没有任何 OCR 选项，也从不联网——这一点后面还会再说。

支持的格式

14 种格式全覆盖是它在这轮基准里的唯一性优势——下面会看到其他工具都漏掉一部分。

格式识别：看内容，不看扩展名

格式从文件内容里读出来，用的是各规范指定的标记：

• PDF 的文件头
• RTF 的起始组
• OLE 流名
• ZIP 包的 mimetype 和 content types

所以扩展名标错的文件照样能正确转换。 这是真实世界里很常见的情况——从邮件附件或下载站拿到的文件，名字经常是错的。

CSV 没有这类标记，所以靠扩展名或显式指明格式。

rustFormat::from_bytes(&bytes);      // Some(Format::Docx)，或None
Format::from_extension("pptm"); // Some(Format::Pptx)
Format::from_path(Path::new("report.odt")); // Some(Format::Odt)

Node 和 Python 里有对应的三个函数。

基准：怎么读这张表

100 份真实文档、14 种格式、和其他6 个工具对比。任何一项分数都不能脱离它的评测方法看，所以先说方法：

• LLM 盲评：用 Claude Sonnet 5 把两个工具的输出匿名对照真值比较；真值是文档前六页用 LibreOffice 渲染成的图片。
• 每个输出按四个维度打分：completeness（完整性）、structure（结构）、formatting（格式）、cleanliness（洁净度）。
• 每对评判两次并交换输出顺序，以抵消位置偏差，共 482 次裁决。
• score 是该工具在它支持的格式上的均分。所以每一行平均的是不同的格式集合——mammoth 的 69 只来自 docx，anydoc 的 81 覆盖全部14 种。
• 速度是在 Ryzen 9 9950X3D 上每个文档一次预热转换的中位数。

总榜

两个数字要一起看：格式覆盖和速度。

• 覆盖上只有它做到 14/14，其他工具都漏格式。
• 速度 4.4ms，比次快的 mammoth（52.5ms）快一个数量级，比 pandoc（102ms）快约 23 倍。
• 总分 81 也是最高。

逐格式（公平比较要看这张）

这一张表才是真正公平的对比，因为所有工具在同一格式上直接比拼。

结论：它不是「某一类最强」，而是「每一类都最强」。 ODP 上86 对 libreoffice 的 23、RTF 上 88 对 53、XLSM 上 76 对 32，差距都很大。

这张基准的局限

要客观看，也得知道它测不出什么：

• 语料不可再分发，也不在仓库里，所以你没法自己复现这个结果。
• 评测是 LLM 盲评，不是人工评审，可能与你的实际判断有偏差。
• 语料构成未知。如果某一种格式占比很高，均分会受影响——这也是作者同时给出逐格式表的原因。

所以别只看那一个 81 分，看它在你的实际输入上的表现。 好在 WASM 版可以在浏览器里试跑真实文件。

OCR：这条边界必须提前确认

这是整份README 里最需要谨慎读的一节。

默认行为：本地读文本型 PDF，但完全不做 OCR。 扫描件或纯图片的 PDF 会以 NeedsOcr 失败。

显式选择加入后，这类文档才会发给 Firecrawl Parse（在新标签页打开） 做OCR，返回同样格式的 Markdown。

三个必须知道的事实：

1. 只有需要 OCR 的文档会离开机器——其他文档全程本地。
2. 但整份文档都上传，因为 Parse 没有页码选择功能。你不能只发第 5 页。
3. Rust crate 根本没有 ocr 选项，也从不联网。

如果 Parse 也转不了，Node 会以 code: "hosted" 拒绝，Python 抛 HostedError。

--api-url（或 apiUrl、api_url，也可用环境变量 FIRECRAWL_API_URL）可以指向别的 Parse 部署。不用注册也能用，只是额度低；要更高额度设 FIRECRAWL_API_KEY。

做隐私评估时记住这一条：一旦开了 OCR，粒度是整份文档。 一个100 页的扫描件里你只关心第 5 页，也得整份发出去。

错误处理

只有当完全无法从文件产出完整 Markdown 时才返回 Err。 ConvertError 会说明具体问题：

rustmatch anydoc::to_markdown(path) {
    Ok(markdown) => Some(markdown),
    Err(e) => {
        // 这类文件产不出文档，记录下来处理下一个
        None
    }
}

这个设计对批处理很友好：单个文件失败可以跳过并记录，不用中断整批。

质量保证

工程上的三件事值得知道：

• tests/fixtures/ 下有一套固定语料做快照测试。
• tests/robustness.rs 对每个 fixture 做变异测试。
• fuzz/ 按格式各有 cargo-fuzz 目标。

「按格式分别做 fuzz」这一点说明作者清楚解析器的风险在哪儿——畸形输入导致的崩溃是这类库的常见问题。

开发

bashcargo test
cd node && npm install && npm run build && npm test
cd python && pip install maturin && maturin develop && python -m unittest discover -s tests

版本号住在三个地方，发布时一起升：Cargo.toml（crate）、node/package.json（npm 包）、python/Cargo.toml（wheel）。

怎么选

1. 先在浏览器里试。 打开演示页（在新标签页打开），传几个你真实要处理的文档，看输出质量。这一步不用装任何东西，文件也不出本机。
2. 质量可以接受，就按你的技术栈选绑定：Node 用 libuv 线程池不阻塞，Python 会释放 GIL，都适合服务端。
3. 只需要 CLI 就用 npx，别为偶发转换装全套。
4. 如果输入里有扫描版 PDF，先确认「整份上传」你能接受。 不能接受就换 WASM 版并在本地做OCR。
5. 输入格式混杂且要统一输出，它是最合适的——别用格式覆盖不全的工具拼管线。

什么情况下别用它

• 扫描版 PDF 且文件不能出本机 —— 必须整份上传，没有页码选择。
• 只需要转一两个文件 —— npx 首次下载二进制反而更慢。
• 要它做 OCR —— 它本身不做，Rust crate更是完全不联网。
• 需要微调转换规则 —— 它是通用转换器，不提供可插拔的解析策略。