夜雨聆风摘要：anydoc 的看点不是“又一个文档解析器”，而是把 Office、PPT、Excel、EPUB、CSV 和文本型 PDF 先变成统一 Markdown。对 AI Agent、RAG 导入和知识库上传来说，它补的是文件入口层：本地转换、无 API key、多语言绑定，还能装成 Agent Skill。
AI Agent 经常卡在第一步：读不到文件。用户扔来 Word、PPT、Excel、PDF、EPUB，各种格式要先变成干净文本，后面的检索、总结和问答才有意义。Firecrawl 的 anydoc 解决的就是这层入口问题。
anydoc 是一个本地 Rust 文档转换库，不覆盖完整 RAG 或 OCR。它先把常见办公文档和文本型 PDF 转成 GitHub-Flavored Markdown，再交给 Agent、知识库或后续流水线处理。
它先统一“读文件”的入口
anydoc 的官方口径很直接：Any document in. Markdown out. 这句话适合当标题钩子，但正文里要补上边界。这里的 document，主要指 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB、CSV，以及文本型 PDF。扫描件和图片型 PDF 不在它自己的能力范围内。
README 顶部能看到几个关键信息：它是 Rust 库，输出 GitHub-Flavored Markdown，提供 Node.js、Python、browser WebAssembly 入口，并且已经做成 Agent Skill。
从 README 顶部可以直接确认这些入口和定位。对普通开发者来说，最容易用的是 CLI：
npx @firecrawl/anydoc report.docx
npx @firecrawl/anydoc slides.pptx -o slides.md
npx skills add firecrawl/anydoc第三行更有意思。anydoc 还提供了 convert-documents-to-markdown 这个 Agent Skill。它告诉 Claude Code、Codex、Cursor、OpenCode 这类代理，遇到办公文档时可以用 anydoc CLI 转 Markdown，不必每次临时猜该装哪个转换器。
为什么统一转换层更省事
很多文档导入流程最麻烦的地方，是格式一多就开始拼工具：docx 找一个库，pptx 找一个库，xls 再找一个库，PDF 又是另一条路。每个工具的输出结构、表格处理、脚注、列表和错误类型都不一样，最后还要自己再清洗一遍。
anydoc 的做法是先把不同格式解析到同一个 document model，再统一序列化成 Markdown。这样一来，表格转义、标题锚点、脚注、列表这些输出细节，可以在同一层处理，而不是每种格式各改一套。
还有一个细节很实用：它优先按文件内容识别格式，不只看扩展名。PDF header、RTF 开头、OLE stream、ZIP package 里的 mimetype 和 content types，都会参与判断。只有 CSV 这种没有稳定签名的格式，才需要靠扩展名或显式指定 format。
这对真实上传场景很重要。用户经常会改错扩展名，或者系统里拿到的是一段 bytes。如果转换器只信文件名，第一步就可能走错解析器。
4.4ms 可以看，但别写成神话
官方 README 给了一组 benchmark：100 个真实文档，覆盖 14 个格式，anydoc 的 median conversion time 是 4.4ms，overall score 是 81。对比项包括 LibreOffice、unstructured、markitdown、pandoc、docling 和 mammoth。
这个数字很抓人，但来源要说清楚：这是 Firecrawl 官方 benchmark，不是第三方独立评测。样本 corpus 也没有随仓库重新分发。所以更准确的结论是：官方测试里，anydoc 在覆盖格式和速度上很突出；如果要放到生产导入流程，还是应该拿自己的文件集跑一遍。
更该注意的是它的能力边界。
anydoc 适合处理“本来有文本结构”的文档。扫描合同、图片型 PDF、手写内容、需要字段抽取的发票和复杂表单，不应该指望它单独完成。Firecrawl 自己也把这条边界分开：anydoc 负责本地转换，托管的 Firecrawl Parse 再处理 OCR、结构化 JSON 和更完整的文档解析。
它适合哪些人
anydoc 最适合三类人。
第一类，是做 AI Agent 文件读取的人。用户上传什么格式，你不一定能控制；但 Agent 需要的是稳定、干净、结构尽量一致的 Markdown。anydoc 可以先统一这一层输入。
第二类，是做知识库导入或 RAG ingestion 的团队。与其把 Office、PPT、表格、EPUB 和 PDF 拆成多条临时脚本，不如先用一个本地转换层统一输入，再把 chunking、embedding、字段抽取放到后面。
第三类，是对数据不出本地有要求的人。浏览器 WebAssembly demo 直接在本机转换，Node、Python、Rust 版本也不需要先把文件发到外部 API。内部资料、客户文档、临时报告这类场景，会更在意这一点。
anydoc 不是“文档智能”的终点。它负责格式转换，不负责判断文档内容是否正确。它把读不了、格式乱的文件先变成 Agent 能处理的 Markdown，为后面的总结、检索和结构化抽取提供稳定输入。
