--- title: "Firecrawl AnyDoc 评测：本地解析 14 种格式" canonical: https://wavect.io/zh/blog/firecrawl-anydoc-review/ language: zh description: "评测 Firecrawl AnyDoc：本地解析 14 种格式，核对 benchmark 与限制，并比较 Docling、MarkItDown 和托管 OCR。" image: "https://wavect.io/img/blog/headers/header_firecrawl-anydoc-review.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年8月10日 最近审核 2026年8月10日 [**下一篇**](/zh/blog/pdf-inspector-ocr-routing/) # Firecrawl AnyDoc 评测：14 种格式转 AI 可用 Markdown 要点速览 Firecrawl AnyDoc 是一款采用 MIT 许可证的 Rust 库，可把 benchmark 涵盖的 14 种 Office、OpenDocument、RTF、EPUB 和 CSV 格式转换为统一的 GitHub-Flavored Markdown，文本型 PDF 则通过 pdf-inspector 处理。Firecrawl 在自有 benchmark 中报告，100 份真实文档的转换时间中位数为 4.4 ms，质量总分也最高。但测试语料未公开，质量由 LLM 评审，因此团队仍需用自己的文件复测。当输入包含多种办公格式、低延迟和不传出数据很重要时，AnyDoc 很适合作为本地默认层。它不提供 OCR、语义字段提取、分块或完整 RAG 流水线。扫描件和复杂版式更适合 Docling，需要更宽的 Python 工具箱可考虑 MarkItDown，需要托管 OCR 与结构化输出时可评估 Firecrawl Parse。 **Firecrawl AnyDoc 是一款快速的本地文档转 Markdown 库，但不是完整的文档智能平台。**这个开源 Rust 项目用统一文档模型处理 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB 和 CSV，文本型 PDF 则交给 pdf-inspector。对于 RAG 入库、AI 智能体文件上传或企业知识导入，它的价值很直接：常规文档只需一个依赖，输出统一 Markdown，也不必调用外部 API。 我们在 2026 年 8 月 10 日核对代码、benchmark 方法和替代方案后得出的结论是：**如果办公文档占多数，而且本地处理很重要，AnyDoc 值得用真实语料试点。**如果主要输入是扫描件、手写内容、复杂视觉版式或需要按 schema 提取字段，它不适合作为默认方案。本文专门回答 AnyDoc、Docling、MarkItDown 与托管解析器之间的采购问题，并把 PDF 与 OCR 路由留给已有的专门文章。 ## Firecrawl AnyDoc 是什么？ **AnyDoc 先把文档 bytes 转换为共享结构模型，再把该模型序列化为 GitHub-Flavored Markdown。** [官方仓库和 API 参考](https://github.com/firecrawl/anydoc) 提供 Rust、Node.js、Python、CLI 与浏览器 WebAssembly 接口。它根据文件内容中的 marker 判断格式，而不是只相信扩展名。CSV 没有格式签名，因此需要扩展名或显式格式。 | 输入类别 | 示例 | 可用输出 | | --- | --- | --- | | Word | DOC、DOCX、DOCM | 标题、列表、表格、链接、注释与行内格式 | | PowerPoint | PPT、PPTX 及相关格式 | 幻灯片内容、表格、链接、媒体引用与讲者备注 | | Excel | XLS、XLSX、XLSM、XLSB | 旧版与新版工作簿都输出统一 Markdown 表格 | | OpenDocument | ODT、ODS、ODP | 与 Microsoft 格式共用同一个 serializer | | 其他结构化文件 | RTF、EPUB、CSV | 无需安装办公套件即可获得规范化文本 | | 文本型 PDF | 带可用文本层的 PDF | 通过 pdf-inspector 在本地输出 Markdown | 能力边界比格式数量更重要。嵌入资源会以 bytes 保留在文档模型中，Markdown 则使用 alt text 或引用表示它们。AnyDoc 不执行 OCR，不理解图表，不推断发票字段，不为 embedding 分块，也不评估检索质量。它解决的是这些步骤之前的格式转换。 ## 4.4 ms benchmark 到底证明了什么？ **Firecrawl 报告称，AnyDoc 在 14 种 benchmark 格式上的单文档转换时间中位数为 4.4 ms，质量总分为 81。** [官方发布说明与 benchmark 方法](https://www.firecrawl.dev/blog/anydoc-and-pdf-inspector) 称，该比较使用 100 份真实文档和六种替代工具。AnyDoc 是这次测试中唯一覆盖全部 14 种格式的工具。 | 公开数据 | 可以得出的结论 | 尚未证明的部分 | | --- | --- | --- | | 4.4 ms 中位数 | 在测试机器上，本地转换路径开销很低 | 冷启动、上传、p95 与你的容器规格 | | 质量总分 81 | 完整性、结构、格式与整洁度表现较好 | 独立人工评审与行业字段正确性 | | 100 份真实文档 | 测试比单个 DOCX demo 更广 | 语料不可公开，外部无法检查分布 | | LLM 盲评并交换输出顺序 | 方法尝试降低位置偏差 | 与专业人工判断的一致性，以及关键错误成本 | | 各工具覆盖格式不同 | 逐格式比较比一个总分更有用 | 所有工具都完整支持的同一份语料 | 这是一份值得参考的厂商证据，不是通用速度纪录。试点时要固定 AnyDoc 版本、硬件、预热方式和样本，并测量 p50、p95、结构验收率、内容缺失、人工更正分钟数与失败文档。一个几毫秒完成但损坏财务表格的 parser，在业务上并不快。 ## AnyDoc、Docling、MarkItDown 还是 Firecrawl Parse？ | 方案 | 最适合 | 主要代价 | | --- | --- | --- | | AnyDoc | 需要留在本地的混合 Office、OpenDocument、RTF、EPUB 与 CSV | 没有 OCR，也不做语义字段提取 | | Docling | 扫描件、图片、复杂 PDF 版式、表格与更丰富的无损文档模型 | 模型、依赖、配置与算力更多 | | MarkItDown | 需要广泛格式、插件与可选云集成的 Python 团队 | 不同格式有不同依赖，转换器质量也不同 | | Firecrawl Parse | 希望直接购买托管 OCR、摘要或 schema JSON 的团队 | 网络传输、供应商条款、按次成本与文档所列 50 MB 限制 | | 保留现有 parser | 当前验收率、成本与延迟已经达到产品目标 | 迁移前必须先证明收益足以覆盖开发与维护 | [Docling 当前支持格式文档](https://docling-project.github.io/docling/usage/supported_formats/) 列出 PDF、Office、OpenDocument、EPUB、图片、HTML、markup、音频和视频，工具包其他部分还提供 OCR 与结构化导出。这种广度很适合版式复杂或多模态语料，但不代表它一定是更轻量的 Office 转换器。 [Microsoft MarkItDown 官方文档](https://github.com/microsoft/markitdown/blob/main/README.md) 介绍了按格式安装的可选依赖、通过插件实现的 OCR，以及用于高质量版式和结构化提取的付费 Azure 路径。它适合重视扩展性的 Python 产品。AnyDoc 更适合需要聚焦、本地、多语言 binding 和统一办公文档输出的团队。 Firecrawl 的 [托管 Parse 文档](https://docs.firecrawl.dev/features/parse) 还提供 OCR 模式、摘要和 schema 引导 JSON。如果托管异常处理比让所有数据和 parser 都留在自己的边界更有价值，可以考虑该服务。虽然 AnyDoc 支撑其中一部分流程，但本地库与托管 API 不是同一种产品。 ## AnyDoc 应该放在 AI 智能体或 RAG 流水线的哪里？ 1. **限制接收范围：** 只允许必要格式，限制原始和解压后大小，替换用户文件名，并把上传放入隔离区。 2. **根据 bytes 识别：** 比较声明的扩展名与 AnyDoc 内容识别结果。不一致时应拒绝，除非产品有明确恢复路径。 3. **隔离解析：** 限制 CPU、内存、嵌套与执行时间。公开上传不能与 web 进程或凭据存储处于同一信任边界。 4. **保留来源：** 记录文件 hash、原始格式、parser 版本、提取时间、标题、表格与资源引用。 5. **验收 Markdown：** 入库前检查必要章节、字符质量、行数、合计、链接和空输出。 6. **路由例外：** 纯图片 PDF 与嵌入扫描页进入获批 OCR 或视觉路径。加密、损坏和不支持文件进入受控审核或拒绝队列。 7. **验收后再分块：** Parsing 只生成源文本。元数据、权限、embedding、检索与答案引用仍是独立责任。 8. **测量验收文档：** 记录端到端成本和审核时间，而不只看 parser 毫秒数。 PDF 专项请看我们的 [pdf-inspector 与 OCR 路由评测](/zh/blog/pdf-inspector-ocr-routing/) 。那篇文章负责原生文本判断、混合页面分流，以及何时开始 OCR。Markdown 验收之后，则由 [欧盟企业 RAG 生产就绪清单](/zh/blog/rag-production-readiness-checklist-eu/) 负责权限、检索评测和答案引用。清晰划分搜索意图可以避免内容相互竞争。 ## Node.js 快速接入与生产边界 ``` import { toMarkdownBytes } from "@firecrawl/anydoc" export async function parseAcceptedUpload(file) { enforceUploadLimits(file) const bytes = new Uint8Array(await file.arrayBuffer()) const markdown = await toMarkdownBytes(bytes, file.name) const result = validateDocument(markdown) if (!result.accepted) { return routeForReview(file, result.reasons) } return { markdown, sha256: await hash(bytes), parser: "anydoc@PINNED_VERSION", sourceName: safeDisplayName(file.name) } } ``` `enforceUploadLimits`、`validateDocument`、`routeForReview`、`hash` 和 `safeDisplayName` 都是产品代码，不是 AnyDoc API。架构估算必须保留这条边界。安装 parser 只是可靠文档入库功能中最小的一部分。 ## 哪些场景不适合 AnyDoc？ - **扫描件与照片：** AnyDoc 没有 OCR 模型，支持文本型 PDF 并不改变这个限制。 - **视觉语义：** 图表、签名、手写修改和空间表单需要视觉或文档理解层。 - **类型化业务字段：** 把发票转成 Markdown，并不等于按 schema 验证供应商、税额、明细与总计。 - **完美还原 Office：** 目标是干净的结构化文本，不是像素级复现工作簿或演示文稿。 - **无限制公开上传：** Rust 和库内资源限制有帮助，但不能替代 sandbox、队列限制、恶意软件检查与补丁责任。 - **必须有独立 benchmark：** 公开性能数据来自项目团队，测试语料也未公开。 OWASP 的 [文件上传安全指南](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) 建议采用多层防护：扩展名白名单、Content-Type 与签名检查、重命名、大小限制、隔离存储、恶意软件扫描和 parser 加固。本地转换减少一种数据传输风险，但不会让外部 Office 文件自动可信。 ## 十天 AnyDoc 评测计划 1. **抽取真实样本：** 至少选择 200 份文档，覆盖所有相关格式、语言、年代与来源，并加入损坏、加密、含宏与超大文件。 2. **定义验收：** 按文档类型标记必须保留的标题、备注、表格、合并单元格、链接、公式、页码与资源。 3. **建立当前基线：** 记录验收率、p50、p95、基础设施成本、人工审核分钟数与 fallback 比例。 4. **测试固定版本：** 使用同一指标，并把 warm parsing 与进程启动、上传时间分开。 5. **比较两种替代方案：** 在困难视觉子集上测试 Docling，在共有办公格式上测试 MarkItDown。 6. **攻击边界：** 在计划中的 sandbox 内测试伪装、压缩、嵌套和高资源消耗文件。 7. **计算 fallback：** 统计 OCR 调用、人工审核、拒绝和最终影响用户的失败。 8. **按验收行动决策：** 只有在质量与安全过线，并且总成本或延迟改善时才上线。 使用我们的 [AI 智能体单次行动成本模型](/zh/blog/ai-agent-cost-per-action-2026/) ，把重试和人工修复留在分母里。如果文档入库即将成为产品基础设施，Wavect 的 [AI enablement 服务](/zh/services/ai-enablement/) 可以帮助评测语料、构建路由层，并连接检索或流程自动化。 [Twinsoft AI 案例](/zh/case-studies/twinsoft-ai/) 展示我们如何约束并追踪 AI 输出， [MVP 技术栈选择指南](/zh/software-development-guide/how-to-choose-a-tech-stack-for-mvp/) 则帮助判断哪些解析层应由团队自持。 ## 常见问题 ### Firecrawl AnyDoc 是什么？ AnyDoc 是一款采用 MIT 许可证的 Rust 库，可把 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB 和 CSV 转成统一的 GitHub-Flavored Markdown。它提供 Rust、Node.js、Python、CLI 和浏览器 WebAssembly 接口，并通过 pdf-inspector 支持文本型 PDF。 ### AnyDoc 会执行 OCR 吗？ 不会。它能处理机器可读内容和文本型 PDF，但扫描件、照片和纯图片页面需要独立 OCR 或视觉路径。 ### AnyDoc 比 Docling 快吗？ 在 Firecrawl 公布的本地 benchmark 中，AnyDoc 的 4.4 ms 中位数更快。但两者覆盖的问题不同，语料也未公开。Docling 还提供 OCR、版式模型和更多多模态格式。应在各自负责的生产子集上测试。 ### 应该选 AnyDoc 还是 MarkItDown？ 如果需要一个覆盖混合办公格式，并提供 Rust、Node.js、Python 与 WebAssembly 接口的紧凑本地 parser，可选 AnyDoc。如果更看重 Python 插件生态、其他媒体和可选 Azure 提取路径，可选 MarkItDown。 ### AnyDoc 可以完全在浏览器运行吗？ 可以。WebAssembly 包接收文档 bytes，官方 demo 也在本地转换。大文件和外部文件仍需要 Web Worker、明确限制与拒绝路径，避免界面失去响应。 ### AnyDoc 足以构建 RAG 吗？ 不足。它可以提供结构化 Markdown，但生产 RAG 仍需验收、分块、元数据、权限、embedding、检索评测、答案引用、监控与删除处理。 ## 研究边界 *状态核对日期为 2026 年 8 月 10 日。本文 benchmark 数据来自厂商，不是 Wavect 实测。我们核对了公开仓库、benchmark 方法和替代方案官方文档，但没有拿到 AnyDoc 私有语料，也没有执行安全审计。版本、格式、托管限制与价格可能变化，采购前应固定并复核。* ## 最终思考 AnyDoc 消除了一类常被低估的基础设施成本：为用户上传的每种办公格式维护不同 parser 和不同输出。共享文档模型、本地执行与多语言 binding，使它有资格成为常规文档转 Markdown 的默认候选。 采购决策取决于异常集合。如果扫描件、视觉版式和类型化字段占多数，应选择更丰富或托管的流水线。如果原生办公文档占多数，就用最难的真实文件试点 AnyDoc，隔离 parser，保留来源，并测量验收文档。最快的 parser 应该降低整体审核和恢复成本，同时不削弱质量闸门。 ## 你可能也喜欢.. [**pdf-inspector：先解析 PDF，再按需 OCR** 针对原生、扫描与混合 PDF，按页面决定提取或 OCR 路线。](/zh/blog/pdf-inspector-ocr-routing/) [**AI enablement 与通用 AI 咨询** 比较部署在自有基础设施上的生产实现与只交付策略的咨询项目。](/zh/compare/ai-enablement-vs-generic-ai-consultancy/) 模型与基础设施 ## 继续浏览此集群 [从核心文章开始**在欧盟自托管 LLM：开放权重模型何时才真正划算**](/zh/blog/self-hosting-llms-eu-cost/) - [Muse Glimmer 30B：Meta 本地智能体模型能否用于生产？](/zh/blog/muse-glimmer-30b-local-agent-guide/) - [OmniRoute AI 路由：配置指南与生产检查清单](/zh/blog/omniroute-ai-routing-setup/) - [Gemini Robotics 2：全身控制与试点决策](/zh/blog/gemini-robotics-2-whole-body-control/) - [pdf-inspector 评测：先本地解析 PDF，再调用 OCR](/zh/blog/pdf-inspector-ocr-routing/) - [本地多模态 AI 编程助手：语音、OCR 与隐私架构](/zh/blog/local-multimodal-ai-coding-assistant/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年8月10日 最近审核 2026年8月10日 [**下一篇**](/zh/blog/pdf-inspector-ocr-routing/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/firecrawl-anydoc-review/#webpage", "@type": "WebPage", "dateModified": "2026-08-10", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-10", "url": "https://wavect.io/zh/blog/firecrawl-anydoc-review/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Firecrawl AnyDoc 是一款采用 MIT 许可证的 Rust 库，可把 benchmark 涵盖的 14 种 Office、OpenDocument、RTF、EPUB 和 CSV 格式转换为统一的 GitHub-Flavored Markdown，文本型 PDF 则通过 pdf-inspector 处理。Firecrawl 在自有 benchmark 中报告，100 份真实文档的转换时间中位数为 4.4 ms，质量总分也最高。但测试语料未公开，质量由 LLM 评审，因此团队仍需用自己的文件复测。当输入包含多种办公格式、低延迟和不传出数据很重要时，AnyDoc 很适合作为本地默认层。它不提供 OCR、语义字段提取、分块或完整 RAG 流水线。扫描件和复杂版式更适合 Docling，需要更宽的 Python 工具箱可考虑 MarkItDown，需要托管 OCR 与结构化输出时可评估 Firecrawl Parse。", "articleBody": " 博客概览/AI 与智能体/模型与基础设施 Firecrawl AnyDoc 评测：14 种格式转 AI 可用 Markdown 要点速览 Firecrawl AnyDoc 是一款采用 MIT 许可证的 Rust 库，可把 benchmark 涵盖的 14 种 Office、OpenDocument、RTF、EPUB 和 CSV 格式转换为统一的 GitHub-Flavored Markdown，文本型 PDF 则通过 pdf-inspector 处理。Firecrawl 在自有 benchmark 中报告，100 份真实文档的转换时间中位数为 4.4 ms，质量总分也最高。但测试语料未公开，质量由 LLM 评审，因此团队仍需用自己的文件复测。当输入包含多种办公格式、低延迟和不传出数据很重要时，AnyDoc 很适合作为本地默认层。它不提供 OCR、语义字段提取、分块或完整 RAG 流水线。扫描件和复杂版式更适合 Docling，需要更宽的 Python 工具箱可考虑 MarkItDown，需要托管 OCR 与结构化输出时可评估 Firecrawl Parse。 Firecrawl AnyDoc 是一款快速的本地文档转 Markdown 库，但不是完整的文档智能平台。这个开源 Rust 项目用统一文档模型处理 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB 和 CSV，文本型 PDF 则交给 pdf-inspector。对于 RAG 入库、AI 智能体文件上传或企业知识导入，它的价值很直接：常规文档只需一个依赖，输出统一 Markdown，也不必调用外部 API。 我们在 2026 年 8 月 10 日核对代码、benchmark 方法和替代方案后得出的结论是：如果办公文档占多数，而且本地处理很重要，AnyDoc 值得用真实语料试点。如果主要输入是扫描件、手写内容、复杂视觉版式或需要按 schema 提取字段，它不适合作为默认方案。本文专门回答 AnyDoc、Docling、MarkItDown 与托管解析器之间的采购问题，并把 PDF 与 OCR 路由留给已有的专门文章。 Firecrawl AnyDoc 是什么？ AnyDoc 先把文档 bytes 转换为共享结构模型，再把该模型序列化为 GitHub-Flavored Markdown。官方仓库和 API 参考提供 Rust、Node.js、Python、CLI 与浏览器 WebAssembly 接口。它根据文件内容中的 marker 判断格式，而不是只相信扩展名。CSV 没有格式签名，因此需要扩展名或显式格式。 输入类别示例可用输出 WordDOC、DOCX、DOCM标题、列表、表格、链接、注释与行内格式 PowerPointPPT、PPTX 及相关格式幻灯片内容、表格、链接、媒体引用与讲者备注 ExcelXLS、XLSX、XLSM、XLSB旧版与新版工作簿都输出统一 Markdown 表格 OpenDocumentODT、ODS、ODP与 Microsoft 格式共用同一个 serializer 其他结构化文件RTF、EPUB、CSV无需安装办公套件即可获得规范化文本 文本型 PDF带可用文本层的 PDF通过 pdf-inspector 在本地输出 Markdown 能力边界比格式数量更重要。嵌入资源会以 bytes 保留在文档模型中，Markdown 则使用 alt text 或引用表示它们。AnyDoc 不执行 OCR，不理解图表，不推断发票字段，不为 embedding 分块，也不评估检索质量。它解决的是这些步骤之前的格式转换。 4.4 ms benchmark 到底证明了什么？ Firecrawl 报告称，AnyDoc 在 14 种 benchmark 格式上的单文档转换时间中位数为 4.4 ms，质量总分为 81。官方发布说明与 benchmark 方法称，该比较使用 100 份真实文档和六种替代工具。AnyDoc 是这次测试中唯一覆盖全部 14 种格式的工具。 公开数据可以得出的结论尚未证明的部分 4.4 ms 中位数在测试机器上，本地转换路径开销很低冷启动、上传、p95 与你的容器规格 质量总分 81完整性、结构、格式与整洁度表现较好独立人工评审与行业字段正确性 100 份真实文档测试比单个 DOCX demo 更广语料不可公开，外部无法检查分布 LLM 盲评并交换输出顺序方法尝试降低位置偏差与专业人工判断的一致性，以及关键错误成本 各工具覆盖格式不同逐格式比较比一个总分更有用所有工具都完整支持的同一份语料 这是一份值得参考的厂商证据，不是通用速度纪录。试点时要固定 AnyDoc 版本、硬件、预热方式和样本，并测量 p50、p95、结构验收率、内容缺失、人工更正分钟数与失败文档。一个几毫秒完成但损坏财务表格的 parser，在业务上并不快。 AnyDoc、Docling、MarkItDown 还是 Firecrawl Parse？ 方案最适合主要代价 AnyDoc需要留在本地的混合 Office、OpenDocument、RTF、EPUB 与 CSV没有 OCR，也不做语义字段提取 Docling扫描件、图片、复杂 PDF 版式、表格与更丰富的无损文档模型模型、依赖、配置与算力更多 MarkItDown需要广泛格式、插件与可选云集成的 Python 团队不同格式有不同依赖，转换器质量也不同 Firecrawl Parse希望直接购买托管 OCR、摘要或 schema JSON 的团队网络传输、供应商条款、按次成本与文档所列 50 MB 限制 保留现有 parser当前验收率、成本与延迟已经达到产品目标迁移前必须先证明收益足以覆盖开发与维护 Docling 当前支持格式文档列出 PDF、Office、OpenDocument、EPUB、图片、HTML、markup、音频和视频，工具包其他部分还提供 OCR 与结构化导出。这种广度很适合版式复杂或多模态语料，但不代表它一定是更轻量的 Office 转换器。 Microsoft MarkItDown 官方文档介绍了按格式安装的可选依赖、通过插件实现的 OCR，以及用于高质量版式和结构化提取的付费 Azure 路径。它适合重视扩展性的 Python 产品。AnyDoc 更适合需要聚焦、本地、多语言 binding 和统一办公文档输出的团队。 Firecrawl 的托管 Parse 文档还提供 OCR 模式、摘要和 schema 引导 JSON。如果托管异常处理比让所有数据和 parser 都留在自己的边界更有价值，可以考虑该服务。虽然 AnyDoc 支撑其中一部分流程，但本地库与托管 API 不是同一种产品。 可选服务路径： 软件开发 MVP 开发 软件 QA Fractional CTO Fractional Co-Founder 看看生产环境中的应用: 债券分析平台 先做决定: 如何挑选软件开发公司 AnyDoc 应该放在 AI 智能体或 RAG 流水线的哪里？ 限制接收范围：只允许必要格式，限制原始和解压后大小，替换用户文件名，并把上传放入隔离区。 根据 bytes 识别：比较声明的扩展名与 AnyDoc 内容识别结果。不一致时应拒绝，除非产品有明确恢复路径。 隔离解析：限制 CPU、内存、嵌套与执行时间。公开上传不能与 web 进程或凭据存储处于同一信任边界。 保留来源：记录文件 hash、原始格式、parser 版本、提取时间、标题、表格与资源引用。 验收 Markdown：入库前检查必要章节、字符质量、行数、合计、链接和空输出。 路由例外：纯图片 PDF 与嵌入扫描页进入获批 OCR 或视觉路径。加密、损坏和不支持文件进入受控审核或拒绝队列。 验收后再分块：Parsing 只生成源文本。元数据、权限、embedding、检索与答案引用仍是独立责任。 测量验收文档：记录端到端成本和审核时间，而不只看 parser 毫秒数。 PDF 专项请看我们的 pdf-inspector 与 OCR 路由评测。那篇文章负责原生文本判断、混合页面分流，以及何时开始 OCR。Markdown 验收之后，则由欧盟企业 RAG 生产就绪清单负责权限、检索评测和答案引用。清晰划分搜索意图可以避免内容相互竞争。 Node.js 快速接入与生产边界 import { toMarkdownBytes } from \"@firecrawl/anydoc\" export async function parseAcceptedUpload(file) { enforceUploadLimits(file) const bytes = new Uint8Array(await file.arrayBuffer()) const markdown = await toMarkdownBytes(bytes, file.name) const result = validateDocument(markdown) if (!result.accepted) { return routeForReview(file, result.reasons) } return { markdown, sha256: await hash(bytes), parser: \"anydoc@PINNED_VERSION\", sourceName: safeDisplayName(file.name) } } enforceUploadLimits、validateDocument、routeForReview、hash 和 safeDisplayName 都是产品代码，不是 AnyDoc API。架构估算必须保留这条边界。安装 parser 只是可靠文档入库功能中最小的一部分。 哪些场景不适合 AnyDoc？ 扫描件与照片：AnyDoc 没有 OCR 模型，支持文本型 PDF 并不改变这个限制。 视觉语义：图表、签名、手写修改和空间表单需要视觉或文档理解层。 类型化业务字段：把发票转成 Markdown，并不等于按 schema 验证供应商、税额、明细与总计。 完美还原 Office：目标是干净的结构化文本，不是像素级复现工作簿或演示文稿。 无限制公开上传：Rust 和库内资源限制有帮助，但不能替代 sandbox、队列限制、恶意软件检查与补丁责任。 必须有独立 benchmark：公开性能数据来自项目团队，测试语料也未公开。 OWASP 的文件上传安全指南建议采用多层防护：扩展名白名单、Content-Type 与签名检查、重命名、大小限制、隔离存储、恶意软件扫描和 parser 加固。本地转换减少一种数据传输风险，但不会让外部 Office 文件自动可信。 十天 AnyDoc 评测计划 抽取真实样本：至少选择 200 份文档，覆盖所有相关格式、语言、年代与来源，并加入损坏、加密、含宏与超大文件。 定义验收：按文档类型标记必须保留的标题、备注、表格、合并单元格、链接、公式、页码与资源。 建立当前基线：记录验收率、p50、p95、基础设施成本、人工审核分钟数与 fallback 比例。 测试固定版本：使用同一指标，并把 warm parsing 与进程启动、上传时间分开。 比较两种替代方案：在困难视觉子集上测试 Docling，在共有办公格式上测试 MarkItDown。 攻击边界：在计划中的 sandbox 内测试伪装、压缩、嵌套和高资源消耗文件。 计算 fallback：统计 OCR 调用、人工审核、拒绝和最终影响用户的失败。 按验收行动决策：只有在质量与安全过线，并且总成本或延迟改善时才上线。 使用我们的 AI 智能体单次行动成本模型，把重试和人工修复留在分母里。如果文档入库即将成为产品基础设施，Wavect 的 AI enablement 服务可以帮助评测语料、构建路由层，并连接检索或流程自动化", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "官方仓库和 API 参考", "url": "https://github.com/firecrawl/anydoc" }, { "@type": "WebPage", "name": "官方发布说明与 benchmark 方法", "url": "https://www.firecrawl.dev/blog/anydoc-and-pdf-inspector" }, { "@type": "WebPage", "name": "Docling 当前支持格式文档", "url": "https://docling-project.github.io/docling/usage/supported_formats/" }, { "@type": "WebPage", "name": "Microsoft MarkItDown 官方文档", "url": "https://github.com/microsoft/markitdown/blob/main/README.md" }, { "@type": "WebPage", "name": "托管 Parse 文档", "url": "https://docs.firecrawl.dev/features/parse" }, { "@type": "WebPage", "name": "文件上传安全指南", "url": "https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html" } ], "dateModified": "2026-08-10", "datePublished": "2026-08-10", "description": "Firecrawl AnyDoc 是一款采用 MIT 许可证的 Rust 库，可把 benchmark 涵盖的 14 种 Office、OpenDocument、RTF、EPUB 和 CSV 格式转换为统一的 GitHub-Flavored Markdown，文本型 PDF 则通过 pdf-inspector 处理。Firecrawl 在自有 benchmark 中报告，100 份真实文档的转换时间中位数为 4.4 ms，质量总分也最高。但测试语料未公开，质量由 LLM 评审，因此团队仍需用自己的文件复测。当输入包含多种办公格式、低延迟和不传出数据很重要时，AnyDoc 很适合作为本地默认层。它不提供 OCR、语义字段提取、分块或完整 RAG 流水线。扫描件和复杂版式更适合 Docling，需要更宽的 Python 工具箱可考虑 MarkItDown，需要托管 OCR 与结构化输出时可评估 Firecrawl Parse。", "headline": "Firecrawl AnyDoc 评测：14 种格式转 Markdown", "image": "https://wavect.io/img/blog/headers/header_firecrawl-anydoc-review.svg", "inLanguage": "zh", "keywords": "AI 智能体, 文档处理", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/firecrawl-anydoc-review/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/firecrawl-anydoc-review/", "wordCount": 593 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/models-infrastructure/", "name": "模型与基础设施", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/firecrawl-anydoc-review/", "name": "Firecrawl AnyDoc 评测：本地解析 14 种格式 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "AnyDoc 是一款采用 MIT 许可证的 Rust 库，可把 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB 和 CSV 转成统一的 GitHub-Flavored Markdown。它提供 Rust、Node.js、Python、CLI 和浏览器 WebAssembly 接口，并通过 pdf-inspector 支持文本型 PDF。" }, "name": "Firecrawl AnyDoc 是什么？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不会。它能处理机器可读内容和文本型 PDF，但扫描件、照片和纯图片页面需要独立 OCR 或视觉路径。" }, "name": "AnyDoc 会执行 OCR 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "在 Firecrawl 公布的本地 benchmark 中，AnyDoc 的 4.4 ms 中位数更快。但两者覆盖的问题不同，语料也未公开。Docling 还提供 OCR、版式模型和更多多模态格式。应在各自负责的生产子集上测试。" }, "name": "AnyDoc 比 Docling 快吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "如果需要一个覆盖混合办公格式，并提供 Rust、Node.js、Python 与 WebAssembly 接口的紧凑本地 parser，可选 AnyDoc。如果更看重 Python 插件生态、其他媒体和可选 Azure 提取路径，可选 MarkItDown。" }, "name": "应该选 AnyDoc 还是 MarkItDown？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "可以。WebAssembly 包接收文档 bytes，官方 demo 也在本地转换。大文件和外部文件仍需要 Web Worker、明确限制与拒绝路径，避免界面失去响应。" }, "name": "AnyDoc 可以完全在浏览器运行吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不足。它可以提供结构化 Markdown，但生产 RAG 仍需验收、分块、元数据、权限、embedding、检索评测、答案引用、监控与删除处理。" }, "name": "AnyDoc 足以构建 RAG 吗？" } ] } ```