Firecrawl anydoc：把Office文档转换成Markdown

把网页内容交给大模型处理相对简单，真正进入企业资料、知识库或RAG流程后，问题往往变成了另一种形式：文件可能是DOCX，也可能是十年前的DOC、PPT、XLS、EPUB或者PDF，而后续系统通常更希望拿到统一、结构清晰的纯文本或Markdown。

Firecrawl开源的anydoc就是围绕这个问题开发的。它的重点不是提供一个在线“Word转Markdown”页面，而是提供一套可以嵌入程序、命令行和AI Agent工作流的文档解析能力，把多种办公文档转换成统一的GitHub-Flavored Markdown。

截至2026年8月，anydoc项目仍在持续更新，当前GitHub Releases中的最新版本为0.1.9。项目采用MIT许可证，可以直接查看源码，也可以根据实际项目需求集成。

anydoc主要解决什么问题

很多文档转换工具只解决“文件能不能打开”的问题，但对AI应用来说，仅仅把文字抽出来通常还不够。

例如一份Word报告中可能包含标题层级、列表、表格、脚注和公式；PPT里可能存在演讲者备注；Excel里则存在大量表格结构。如果所有内容最后都被压缩成没有层级的纯文本，虽然大模型仍然能够读取，但原始文档中的结构信息已经损失了不少。

anydoc采用的方式是先把不同文件格式解析成统一的文档模型，再使用同一个Markdown序列化器输出内容。这样做的实际意义在于，DOCX、RTF、ODT等不同来源文件最终可以遵循相对一致的标题、表格、列表和转义规则。

对于需要接收大量来源不统一文件的系统，这种“输入格式不同、输出结构统一”的设计往往比单纯支持某一种Office格式更重要。

目前支持哪些文档格式

根据项目当前README，anydoc已经覆盖常见Microsoft Office格式、OpenDocument以及PDF、EPUB、CSV等文件。

这里比较值得注意的是旧版Office格式。很多新工具重点支持DOCX、XLSX和PPTX，但实际企业文件库里经常还存在DOC、XLS和PPT。对于需要批量清洗历史文件的项目，旧格式支持会直接影响工具是否能够真正进入生产流程。

转换后会保留哪些文档结构

anydoc并不是简单读取文档里的字符串。官方列出的转换范围包括标题、粗体、斜体、删除线、行内代码、代码块、链接、内部引用、项目列表、编号列表、嵌套列表、任务列表、表格、引用块、脚注和尾注等内容。

对于Word、PowerPoint、OpenDocument、EPUB和RTF中的公式，项目还会尝试将对应的OMML或MathML内容转换成Markdown中的LaTeX数学表达式。

这对技术文档、研究资料和课程资料尤其重要。普通文本抽取可能只得到公式附近的零散字符，而转换成LaTeX之后，更方便继续交给支持数学表达式的大模型、Markdown编辑器或知识库系统处理。

PPT中的speaker notes也在项目支持范围内。如果企业把培训资料、销售演示或内部会议PPT导入知识库，这些备注有时甚至比幻灯片上的几个关键词包含更多有效信息。

文件格式并不只看扩展名

实际处理用户上传文件时，经常会遇到扩展名错误的问题。例如文件名字写着.docx，里面却不是有效的DOCX内容，或者上传过程中扩展名被修改。

anydoc对多数格式会根据文件内容本身进行识别，而不是完全依赖文件名。项目会读取PDF Header、RTF结构、OLE Stream以及ZIP包中的MIME Type和Content Type等标记判断格式。

这种设计对API上传、邮件附件处理和自动化文档管道比较有意义，因为服务器不需要完全相信用户提供的文件扩展名。

CSV是一个例外。CSV本身没有类似PDF文件头这样的统一内容标志，因此仍然需要通过文件扩展名或显式指定格式来判断。

最简单的方式是直接使用CLI

如果只是需要把一个文件转换成Markdown，不一定要先建立Node.js或者Python项目。anydoc提供了命令行方式，可以直接通过npx执行。

npx @firecrawl/anydoc report.docx

默认情况下，转换后的Markdown会输出到终端。如果希望直接保存为文件，可以指定输出位置：

npx @firecrawl/anydoc slides.pptx -o slides.md

这种方式特别适合开发人员临时处理文件，或者在Shell脚本中批量完成转换。

如果长期使用，也可以全局安装：

npm install -g @firecrawl/anydoc

与在线转换网站相比，CLI最大的区别是它更容易加入现有自动化流程。例如定时扫描目录、处理上传附件或者把转换结果继续交给Embedding服务，都不需要人工打开网页上传文件。

Node.js和Python怎么接入

对于后端服务来说，anydoc目前已经提供Node.js和Python绑定，不需要开发者自己调用Rust程序。

Node.js可以安装对应npm包：

npm install @firecrawl/anydoc

然后直接读取文件并返回Markdown：

import { toMarkdown } from '@firecrawl/anydoc';

const markdown = await toMarkdown('report.docx');

Python版本的安装方式则是：

pip install firecrawl-anydoc

安装包名称是firecrawl-anydoc，但代码中导入的模块名称为anydoc：

import anydoc

markdown = anydoc.to_markdown("report.docx")

除了直接输出Markdown，Node.js、Python和其他接口还可以停留在项目自己的Document文档模型阶段。对于需要进一步提取图片、重新组织内容或者生成自定义输出格式的开发人员，这会比只能获得一段最终Markdown更加灵活。

浏览器里也可以直接运行

anydoc目前还提供WebAssembly版本，并有官方浏览器演示页面。官方说明中的演示转换直接在浏览器本地运行，文件不需要上传到服务器。

对于隐私要求较高的内部文档，这种运行模式具有比较直接的价值。例如企业可以自己开发一个简单前端页面，让员工把DOCX或XLSX转换成Markdown，而转换过程仍然发生在用户设备上。

开发者也可以安装WASM包：

npm install @firecrawl/anydoc-wasm

需要注意的是，浏览器本地转换能力并不等于浏览器可以完成所有OCR任务。文本型文件和扫描图片仍然是两个不同的问题。

PDF支持需要区分文本和扫描件

这是使用anydoc之前比较重要的边界。

项目本身可以在本地解析文本型PDF，并通过pdf-inspector完成PDF内容处理，不需要额外OCR服务。

但如果PDF实际上是扫描图片，例如扫描合同、书籍扫描件或者只有图片没有文本层的PDF，anydoc本地模式不会自行运行OCR，而会返回NeedsOcr错误。

CLI、Node.js和Python接口可以显式启用hosted OCR。例如CLI可以使用：

anydoc scan.pdf --ocr hosted

开启后，需要OCR的文档会发送给Firecrawl Parse处理，再返回Markdown结果。官方同时说明，只有确实需要OCR的文档才会走这个流程，但由于Firecrawl Parse目前没有按页选择机制，触发OCR时发送的是整个文档。

这意味着，如果处理的是敏感文件，并且业务要求所有内容必须完全留在本地，就不能简单把hosted OCR当作本地解析能力的一部分。此时应继续使用anydoc处理可本地读取的文档，并另外选择符合自身部署要求的OCR方案。

它为什么适合AI文档处理

anydoc官方把目标输出描述为适合LLM使用的Markdown，这并不意味着转换完成后就直接拥有了一个RAG系统。

更准确地说，它解决的是RAG和AI知识库前面的文档预处理步骤。

一种常见流程可以是：

1. 用户上传DOCX、PPTX、XLSX或PDF。

2. anydoc识别文件格式并转换成统一Markdown。

3. 程序按照标题、段落或其他规则进行Chunk切分。

4. 将切分后的内容生成Embedding并写入向量数据库。

5. 用户提问时检索相关片段并交给大模型生成答案。

这里anydoc主要负责前两步之间的格式差异。如果没有这一层，每增加一种文档类型，后端系统可能就需要维护一套独立的解析逻辑。

它同样适合AI Agent。项目本身提供Agent Skill，可以让兼容Agent通过anydoc CLI读取遇到的办公文件。官方目前列出的兼容示例包括Claude Code、Codex、Cursor和OpenCode等支持相应Agent Skill机制的工具。

性能数据应该怎么看

anydoc项目README提供了一组官方Benchmark，把自身与LibreOffice、Unstructured、MarkItDown、Pandoc、Docling和Mammoth等工具进行了比较。

在官方测试环境中，anydoc针对100份真实文档、14种格式进行测试，公布的单文档中位转换时间为4.4毫秒。在同一份官方测试表中，anydoc覆盖14种测试格式。

不过，这些数字更适合用来理解项目的设计方向，而不应该直接理解成所有电脑、所有文件都一定能在几毫秒完成转换。

官方测试运行在指定硬件和测试方法下，而且不同工具支持的格式数量并不完全一致。质量部分还使用LLM Judge根据完整度、结构、格式和整洁度进行评估。因此，在决定是否用于实际项目之前，更合理的方法仍然是拿自己的DOC、Excel、PPT和PDF样本跑一次。

特别是包含复杂合并单元格、特殊字体、嵌入对象、异常Office结构或者复杂PDF布局的文件，真实转换结果比任何综合分数更有参考价值。

参考资料

1. anydoc GitHub项目仓库

2. anydoc官方README

3. anydoc版本发布记录

4. anydoc Python使用文档

5. anydoc MIT许可证