背景RAG 管道的解析瓶颈被低估了两年过去两年业界对 RAG 的关注集中在分块策略、重排序、嵌入模型——但 2026 年越来越多的团队意识到检索质量的上限往往被更上游的「文档解析」卡死。一个被合并单元格抹平成乱码的表格会污染下游所有 chunk再聪明的 reranker 也救不回来。更糟的是这件事没有银弹。.docx走 mammoth.xlsx走 openpyxl.pptx走 python-pptx2003 年的.doc和.xls要 shell 到 LibreOffice 转换……每个库有自己的依赖树、自己的输出风格、自己的失败模式。光是把它们按统一风格调一致就是一个 plumbing 项目。Firecrawl anydocgithub.com/firecrawl/anydocMIT2026-08-03 开源v0.1.9 2026-08-13就是冲着这个痛点来的。Firecrawl 把网页抓取做到 LLM 友好 Markdown 的能力延伸到本地文档——开源两周内 GitHub 收获 17k Star跻身 GitHub Trending 周榜。本文从架构、实战、基准解读、避坑清单四个角度做深度拆解。一、事实表anydoc 是什么字段值仓库github.com/firecrawl/anydoc许可证MIT最新版本v0.1.92026-08-13实现语言Rustfrom-scratch非套壳产物单一调用返回 GitHub-Flavored Markdown格式覆盖14 种非 PDF 文本型 PDFPDF 旁路走 pdf-inspector运行时Rust crate / Node.js / Python / WebAssembly / CLI依赖无系统依赖、无 API Key、无 ML 模型、无 GPUAgent Skillnpx skills add firecrawl/anydoc官方基准中位 4.4ms / 100 份真实文档 / 14 种格式 / 厂商自测支持的 14 种格式扩展名族Word.doc.docx.docmPowerPoint.ppt.pps.pot.pptx.pptm.ppsx.ppsmExcel.xls.xlsx.xlsm.xlsbOpenDocument.odt.ods.odp其他.rtf.epub.csvPDF经Format::Pdf走 pdf-inspector 旁路二、架构每格式一个解析器共享一个文档模型只有一个 Markdown 序列化器图1anydoc 架构流水线——每种格式解析为同一套Document结构再由唯一的 GFM 序列化器输出PDF 不进文档模型直接路由 pdf-inspector概念示意非运行截图整个流水线可以拆成四步加一个旁路内容级格式检测不看扩展名看内容签名——PDF header、RTF 开组、OLE 流名、ZIP mimetype。CSV 没有可靠签名所以仍要靠扩展名或显式指定格式。每格式独立解析器每个格式有自己的解析实现例如.xls*用calamine库但解析结果都被归一化到同一套Document结构blocks / inlines / tables / footnotes / assets。共享 Document 模型这是 anydoc 整套设计的核心。一处修表格转义14 种格式全部受益——README 原话「A table-escaping fix for docx is automatically a table-escaping fix for rtf, odt, and everything else」。单一 GFM 序列化器所有 Document 共用一段序列化代码标题锚点、列表编号、脚注、链接行为在所有格式下都一致。PDF 旁路Format::Pdf走pdf-inspector直接抽文本不进文档模型所以对 PDF 调to_document会报Unsupported。这种「解析器多、模型一、序列化器一」的设计 vs. 业内常见的「每格式一套独立输出」是个根本差异——前者是工程化统一后者是技术债。三、实战一CLI 三分钟上手# 安装即用npx 首次运行会下载预编译二进制 npx firecrawl/anydoc report.docx # 把 Markdown 输出到文件 npx firecrawl/anydoc slides.pptx -o slides.md # 从 stdin 读 npx firecrawl/anydoc - --format csv data.csvCLI 走的是 Node 包预编译二进制对小脚本很方便想固定版本就npm install -g firecrawl/anydoc。anydoc --help列出全部选项。四、实战二Python / Node / Rust 三种 API 同形Pythonpip install firecrawl-anydocimport anydoc 文件路径 md anydoc.to_markdown(contract.docx) 字节 自动检测 md anydoc.to_markdown_bytes(data) 显式指定格式CSV 必须因为无内容签名 md anydoc.to_markdown_bytes(data, csv) 拿到结构化文档注意 PDF 不支持 doc anydoc.to_document(data) 格式检测三兄弟 fmt anydoc.format_from_bytes(data) fmt anydoc.format_from_extension(XLSX) fmt anydoc.format_from_path(data/q3.xlsx)Nodenpm install firecrawl/anydocimport { toMarkdown, toMarkdownBytes, toDocument, formatFromBytes } from firecrawl/anydoc; const md await toMarkdown(contract.docx); const fromBytes await toMarkdownBytes(bytes); const fromCsv await toMarkdownBytes(bytes, csv); const doc await toDocument(bytes); const fmt formatFromBytes(bytes);Rustcargo add anydoclet md anydoc::to_markdown(contract.docx)?; let md anydoc::to_markdown_bytes(bytes, None)?; let md anydoc::to_markdown_bytes(bytes, anydoc::Format::Csv)?; let doc anydoc::to_document(bytes, None)?; let fmt anydoc::Format::from_bytes(bytes);注意调用前最好先from_bytes判一下再走to_markdown_bytes(bytes, format)——既给 CSV 这种无签名格式一个明确路径也方便做日志与降级。五、实战三浏览器 WASM Agent SkillWebAssemblynpm install firecrawl/anydoc-wasmimport init, { toMarkdownBytes, toDocument } from firecrawl/anydoc-wasm; await init(); const md toMarkdownBytes(bytes); const doc toDocument(bytes);官方在线演示anydoc by Firecrawl——拖入文件本地转换明确标注「文件永不离开你的机器」。WASM 镜像了 lib APIformatFromBytes/toMarkdownBytes/toDocument构建命令是wasm-pack build wasm --release --target web --scope firecrawl。Agent Skillnpx skills add firecrawl/anydocanydoc 以 Agent Skill 形式发布兼容 Claude Code、Codex、Cursor、OpenCode 等。安装后agent 碰到 doc/xls/ppt/epub 等文件时会自动调用 anydoc CLI 转 Markdown 再读入上下文——把「文档解析」从「上下文组装」阶段剥离出来由专业库负责。六、官方基准怎么读——诚实警示图2官方基准中位转换耗时对数刻度——anydoc 比次快工具快一个数量级LibreOffice 慢到 1129.5ms数据来源Firecrawl 官方博客基准表2026-08-06概念示意图非本文实测速度结论来自 Firecrawl 官方博客 2026-08-06100 份真实文档14 种格式工具格式覆盖中位耗时anydoc14/144.4 msmammoth1/1452.5 mspandoc5/14102.1 msmarkitdown6/14134.8 msdocling4/14513.6 msunstructured8/14572.9 mslibreoffice12/141129.5 ms质量结论LLM 评审Claude Sonnet 5双盲打分共 482 个判定图3质量维度拆解——anydoc 五项总分/完整性/结构/格式化/整洁度全部领先LibreOffice 覆盖广但整洁度仅 24 分数据来源Firecrawl 官方博客基准表概念示意图非本文实测工具总分完整性结构格式化整洁度anydoc8187797881mammoth7084717551markitdown6578666052unstructured6376595163docling5760605751pandoc5674575638libreoffice4059424024三句诚实警示——这组数据很好看但必须照原样看是厂商自测。基准是 Firecrawl 自己跑的不是第三方。是 LLM 评审。裁判是 Claude Sonnet 5质量分本质是「AI 觉得 AI 输出好不好」。语料不公开。README 原话「the corpus is ours」。也就是说「100 份真实文档」是 Firecrawl 选出来的没法在自家语料上重现。另外总分是各自支持格式的平均分——mammoth 70 只覆盖 docxanydoc 81 覆盖 14 种。跨工具横比应看「逐格式对比」在那张表里anydoc 在每个被评判的格式上都最高doc 87/docm 84/docx 88/epub 77/odp 86/ods 82/odt 80/ppt 80/pptx 74/rtf 88/xls 80/xlsm 76/xlsx 72。结论速度优势是数量级的可信质量优势是清晰的、有方向的但绝对分数请保守看待。建议在自己的真实语料上抽样复现。七、限制清单与避坑必读 README 后再集成可少踩 80% 的坑扫描/纯图像 PDF →Unsupportedanydoc 不做 OCR。混合 PDF部分页扫描需要走pdf-inspector标出的页面 外部 OCR 管线托管 API 用户可走 Firecrawl/parse它会拼 pdf-inspector 与 OCR。加密文件 →Encrypted错误。直接放弃不要试图用空口令。页眉、页脚、页码、日期/时间占位符默认排除但演讲者备注speaker notes始终包含——这是 PPT/PDF 转 Markdown 时一个常被忽略的事实。GFM 无非十进制列表语法。.docx里的罗马/字母编号会渲染成带字面标记的 bullet例如- iv. 介绍、- a. 步骤一。嵌入图像/对象在 Markdown 里只渲染为 alt 文本原字节保留在 Document 模型的assets字段里带媒体类型。需要图片请走to_document。电子表格仍有未关闭的开放项R17b数字格式渲染单元格的自定义数字格式如百分比、千分位当前会丢失。R17c超链接电子表格中的超链接尚未完整提取。引用自仓库 Phase 16/17 状态「S11 R17b/c 仍开放」R18 已延期。基准中 anydoc 仅评判 94/100 份文档——剩下 6 份因格式边缘或工具问题未进入计分。读 100% 全胜时要扣一点。to_document对 PDF 报 unsupported——它只走纯文本旁路。结构化 PDF 提取需要先转 PDF 文本/OCR。错误变体仅在无法产出有意义的 Markdown 时返回Unsupported/Malformed/Encrypted/ResourceLimit/MissingPart/Io。Node 与 WASM 包用error.code字符串Python 每一变体对应一个anydoc.ConvertError子类。版本号当前不一致。GitHub 显示v0.1.92026-08-13但中间穿插的0.3.02026-08-01版本号更高。pip 装的是firecrawl-anydoc、npm 是firecrawl/anydoc、crates.io 是anydoc用pip show/npm view确认当前 release不要想当然。八、何时该选它何时该留下旧栈适合你的 RAG / Agent 摄取管道要吃 14 种文档格式且希望「一处改风格、全部生效」。浏览器侧转换用户上传的合同/手册不出本机。给 agent 配npx skills add firecrawl/anydoc减少上下文失真。不想再为 mammoth openpyxl python-pptx LibreOffice shell 维护拼装。你的 RAG 已经能跑通只想要更稳的解析层。暂时别换主要场景是扫描/纯图像 PDF——anydoc 帮不了你需要 OCR 方案。强依赖电子表格的数字格式与超链接财务模型/数据目录等 R17b/c 关闭。需要 PDF 的版面级结构标题层级、阅读顺序、表格跨页——目前 PDF 走 pdf-inspector 旁路结构化能力有限。已经有跑得很稳的 LibreOffice shell 方案且流量不大1129ms 对 4.4ms 在 1 万份/月量级下成本差异并不显著。九、总结与延伸anydoc 的核心赌注是「RAG 时代文档解析的瓶颈不在某一个格式而在跨格式的输出不一致性。」用统一 Document 模型 单一 GFM 序列化器去解这个一致性是工程化思维而不是单点优化。再叠加上 4.4ms 数量级的中位转换速度、五个运行时同形 API、Agent Skill 集成它在 2026-08 这波文档解析趋势里占了相当扎眼的位置。但要避免被漂亮数据带偏基准是厂商自测、LLM 评审、语料未公开的电子表格数字格式、超链接、PDF 结构化都还有未关闭的开放项。先在你的真实语料上抽 50–200 份做 A/B再决定是否全量替换旧栈。官方资源仓库与 READMEhttps://github.com/firecrawl/anydoc配套 PDF 引擎https://github.com/firecrawl/pdf-inspector官方发布博客https://www.firecrawl.dev/blog/anydoc-and-pdf-inspectorWASM 在线演示anydoc by FirecrawlAgent Skill 注册npx skills add firecrawl/anydoc托管 APIFirecrawl/parse与/scrape已自动使用 anydoc pdf-inspector Firecrawl anydoc 实战拆解：用一个 Rust 依赖吃下 14 种文档格式
背景RAG 管道的解析瓶颈被低估了两年过去两年业界对 RAG 的关注集中在分块策略、重排序、嵌入模型——但 2026 年越来越多的团队意识到检索质量的上限往往被更上游的「文档解析」卡死。一个被合并单元格抹平成乱码的表格会污染下游所有 chunk再聪明的 reranker 也救不回来。更糟的是这件事没有银弹。.docx走 mammoth.xlsx走 openpyxl.pptx走 python-pptx2003 年的.doc和.xls要 shell 到 LibreOffice 转换……每个库有自己的依赖树、自己的输出风格、自己的失败模式。光是把它们按统一风格调一致就是一个 plumbing 项目。Firecrawl anydocgithub.com/firecrawl/anydocMIT2026-08-03 开源v0.1.9 2026-08-13就是冲着这个痛点来的。Firecrawl 把网页抓取做到 LLM 友好 Markdown 的能力延伸到本地文档——开源两周内 GitHub 收获 17k Star跻身 GitHub Trending 周榜。本文从架构、实战、基准解读、避坑清单四个角度做深度拆解。一、事实表anydoc 是什么字段值仓库github.com/firecrawl/anydoc许可证MIT最新版本v0.1.92026-08-13实现语言Rustfrom-scratch非套壳产物单一调用返回 GitHub-Flavored Markdown格式覆盖14 种非 PDF 文本型 PDFPDF 旁路走 pdf-inspector运行时Rust crate / Node.js / Python / WebAssembly / CLI依赖无系统依赖、无 API Key、无 ML 模型、无 GPUAgent Skillnpx skills add firecrawl/anydoc官方基准中位 4.4ms / 100 份真实文档 / 14 种格式 / 厂商自测支持的 14 种格式扩展名族Word.doc.docx.docmPowerPoint.ppt.pps.pot.pptx.pptm.ppsx.ppsmExcel.xls.xlsx.xlsm.xlsbOpenDocument.odt.ods.odp其他.rtf.epub.csvPDF经Format::Pdf走 pdf-inspector 旁路二、架构每格式一个解析器共享一个文档模型只有一个 Markdown 序列化器图1anydoc 架构流水线——每种格式解析为同一套Document结构再由唯一的 GFM 序列化器输出PDF 不进文档模型直接路由 pdf-inspector概念示意非运行截图整个流水线可以拆成四步加一个旁路内容级格式检测不看扩展名看内容签名——PDF header、RTF 开组、OLE 流名、ZIP mimetype。CSV 没有可靠签名所以仍要靠扩展名或显式指定格式。每格式独立解析器每个格式有自己的解析实现例如.xls*用calamine库但解析结果都被归一化到同一套Document结构blocks / inlines / tables / footnotes / assets。共享 Document 模型这是 anydoc 整套设计的核心。一处修表格转义14 种格式全部受益——README 原话「A table-escaping fix for docx is automatically a table-escaping fix for rtf, odt, and everything else」。单一 GFM 序列化器所有 Document 共用一段序列化代码标题锚点、列表编号、脚注、链接行为在所有格式下都一致。PDF 旁路Format::Pdf走pdf-inspector直接抽文本不进文档模型所以对 PDF 调to_document会报Unsupported。这种「解析器多、模型一、序列化器一」的设计 vs. 业内常见的「每格式一套独立输出」是个根本差异——前者是工程化统一后者是技术债。三、实战一CLI 三分钟上手# 安装即用npx 首次运行会下载预编译二进制 npx firecrawl/anydoc report.docx # 把 Markdown 输出到文件 npx firecrawl/anydoc slides.pptx -o slides.md # 从 stdin 读 npx firecrawl/anydoc - --format csv data.csvCLI 走的是 Node 包预编译二进制对小脚本很方便想固定版本就npm install -g firecrawl/anydoc。anydoc --help列出全部选项。四、实战二Python / Node / Rust 三种 API 同形Pythonpip install firecrawl-anydocimport anydoc 文件路径 md anydoc.to_markdown(contract.docx) 字节 自动检测 md anydoc.to_markdown_bytes(data) 显式指定格式CSV 必须因为无内容签名 md anydoc.to_markdown_bytes(data, csv) 拿到结构化文档注意 PDF 不支持 doc anydoc.to_document(data) 格式检测三兄弟 fmt anydoc.format_from_bytes(data) fmt anydoc.format_from_extension(XLSX) fmt anydoc.format_from_path(data/q3.xlsx)Nodenpm install firecrawl/anydocimport { toMarkdown, toMarkdownBytes, toDocument, formatFromBytes } from firecrawl/anydoc; const md await toMarkdown(contract.docx); const fromBytes await toMarkdownBytes(bytes); const fromCsv await toMarkdownBytes(bytes, csv); const doc await toDocument(bytes); const fmt formatFromBytes(bytes);Rustcargo add anydoclet md anydoc::to_markdown(contract.docx)?; let md anydoc::to_markdown_bytes(bytes, None)?; let md anydoc::to_markdown_bytes(bytes, anydoc::Format::Csv)?; let doc anydoc::to_document(bytes, None)?; let fmt anydoc::Format::from_bytes(bytes);注意调用前最好先from_bytes判一下再走to_markdown_bytes(bytes, format)——既给 CSV 这种无签名格式一个明确路径也方便做日志与降级。五、实战三浏览器 WASM Agent SkillWebAssemblynpm install firecrawl/anydoc-wasmimport init, { toMarkdownBytes, toDocument } from firecrawl/anydoc-wasm; await init(); const md toMarkdownBytes(bytes); const doc toDocument(bytes);官方在线演示anydoc by Firecrawl——拖入文件本地转换明确标注「文件永不离开你的机器」。WASM 镜像了 lib APIformatFromBytes/toMarkdownBytes/toDocument构建命令是wasm-pack build wasm --release --target web --scope firecrawl。Agent Skillnpx skills add firecrawl/anydocanydoc 以 Agent Skill 形式发布兼容 Claude Code、Codex、Cursor、OpenCode 等。安装后agent 碰到 doc/xls/ppt/epub 等文件时会自动调用 anydoc CLI 转 Markdown 再读入上下文——把「文档解析」从「上下文组装」阶段剥离出来由专业库负责。六、官方基准怎么读——诚实警示图2官方基准中位转换耗时对数刻度——anydoc 比次快工具快一个数量级LibreOffice 慢到 1129.5ms数据来源Firecrawl 官方博客基准表2026-08-06概念示意图非本文实测速度结论来自 Firecrawl 官方博客 2026-08-06100 份真实文档14 种格式工具格式覆盖中位耗时anydoc14/144.4 msmammoth1/1452.5 mspandoc5/14102.1 msmarkitdown6/14134.8 msdocling4/14513.6 msunstructured8/14572.9 mslibreoffice12/141129.5 ms质量结论LLM 评审Claude Sonnet 5双盲打分共 482 个判定图3质量维度拆解——anydoc 五项总分/完整性/结构/格式化/整洁度全部领先LibreOffice 覆盖广但整洁度仅 24 分数据来源Firecrawl 官方博客基准表概念示意图非本文实测工具总分完整性结构格式化整洁度anydoc8187797881mammoth7084717551markitdown6578666052unstructured6376595163docling5760605751pandoc5674575638libreoffice4059424024三句诚实警示——这组数据很好看但必须照原样看是厂商自测。基准是 Firecrawl 自己跑的不是第三方。是 LLM 评审。裁判是 Claude Sonnet 5质量分本质是「AI 觉得 AI 输出好不好」。语料不公开。README 原话「the corpus is ours」。也就是说「100 份真实文档」是 Firecrawl 选出来的没法在自家语料上重现。另外总分是各自支持格式的平均分——mammoth 70 只覆盖 docxanydoc 81 覆盖 14 种。跨工具横比应看「逐格式对比」在那张表里anydoc 在每个被评判的格式上都最高doc 87/docm 84/docx 88/epub 77/odp 86/ods 82/odt 80/ppt 80/pptx 74/rtf 88/xls 80/xlsm 76/xlsx 72。结论速度优势是数量级的可信质量优势是清晰的、有方向的但绝对分数请保守看待。建议在自己的真实语料上抽样复现。七、限制清单与避坑必读 README 后再集成可少踩 80% 的坑扫描/纯图像 PDF →Unsupportedanydoc 不做 OCR。混合 PDF部分页扫描需要走pdf-inspector标出的页面 外部 OCR 管线托管 API 用户可走 Firecrawl/parse它会拼 pdf-inspector 与 OCR。加密文件 →Encrypted错误。直接放弃不要试图用空口令。页眉、页脚、页码、日期/时间占位符默认排除但演讲者备注speaker notes始终包含——这是 PPT/PDF 转 Markdown 时一个常被忽略的事实。GFM 无非十进制列表语法。.docx里的罗马/字母编号会渲染成带字面标记的 bullet例如- iv. 介绍、- a. 步骤一。嵌入图像/对象在 Markdown 里只渲染为 alt 文本原字节保留在 Document 模型的assets字段里带媒体类型。需要图片请走to_document。电子表格仍有未关闭的开放项R17b数字格式渲染单元格的自定义数字格式如百分比、千分位当前会丢失。R17c超链接电子表格中的超链接尚未完整提取。引用自仓库 Phase 16/17 状态「S11 R17b/c 仍开放」R18 已延期。基准中 anydoc 仅评判 94/100 份文档——剩下 6 份因格式边缘或工具问题未进入计分。读 100% 全胜时要扣一点。to_document对 PDF 报 unsupported——它只走纯文本旁路。结构化 PDF 提取需要先转 PDF 文本/OCR。错误变体仅在无法产出有意义的 Markdown 时返回Unsupported/Malformed/Encrypted/ResourceLimit/MissingPart/Io。Node 与 WASM 包用error.code字符串Python 每一变体对应一个anydoc.ConvertError子类。版本号当前不一致。GitHub 显示v0.1.92026-08-13但中间穿插的0.3.02026-08-01版本号更高。pip 装的是firecrawl-anydoc、npm 是firecrawl/anydoc、crates.io 是anydoc用pip show/npm view确认当前 release不要想当然。八、何时该选它何时该留下旧栈适合你的 RAG / Agent 摄取管道要吃 14 种文档格式且希望「一处改风格、全部生效」。浏览器侧转换用户上传的合同/手册不出本机。给 agent 配npx skills add firecrawl/anydoc减少上下文失真。不想再为 mammoth openpyxl python-pptx LibreOffice shell 维护拼装。你的 RAG 已经能跑通只想要更稳的解析层。暂时别换主要场景是扫描/纯图像 PDF——anydoc 帮不了你需要 OCR 方案。强依赖电子表格的数字格式与超链接财务模型/数据目录等 R17b/c 关闭。需要 PDF 的版面级结构标题层级、阅读顺序、表格跨页——目前 PDF 走 pdf-inspector 旁路结构化能力有限。已经有跑得很稳的 LibreOffice shell 方案且流量不大1129ms 对 4.4ms 在 1 万份/月量级下成本差异并不显著。九、总结与延伸anydoc 的核心赌注是「RAG 时代文档解析的瓶颈不在某一个格式而在跨格式的输出不一致性。」用统一 Document 模型 单一 GFM 序列化器去解这个一致性是工程化思维而不是单点优化。再叠加上 4.4ms 数量级的中位转换速度、五个运行时同形 API、Agent Skill 集成它在 2026-08 这波文档解析趋势里占了相当扎眼的位置。但要避免被漂亮数据带偏基准是厂商自测、LLM 评审、语料未公开的电子表格数字格式、超链接、PDF 结构化都还有未关闭的开放项。先在你的真实语料上抽 50–200 份做 A/B再决定是否全量替换旧栈。官方资源仓库与 READMEhttps://github.com/firecrawl/anydoc配套 PDF 引擎https://github.com/firecrawl/pdf-inspector官方发布博客https://www.firecrawl.dev/blog/anydoc-and-pdf-inspectorWASM 在线演示anydoc by FirecrawlAgent Skill 注册npx skills add firecrawl/anydoc托管 APIFirecrawl/parse与/scrape已自动使用 anydoc pdf-inspector