Firecrawl AnyDoc 评测：14 种格式转 AI 可用 Markdown

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 没有格式签名，因此需要扩展名或显式格式。

能力边界比格式数量更重要。嵌入资源会以 bytes 保留在文档模型中，Markdown 则使用 alt text 或引用表示它们。AnyDoc 不执行 OCR，不理解图表，不推断发票字段，不为 embedding 分块，也不评估检索质量。它解决的是这些步骤之前的格式转换。

4.4 ms benchmark 到底证明了什么？

Firecrawl 报告称，AnyDoc 在 14 种 benchmark 格式上的单文档转换时间中位数为 4.4 ms，质量总分为 81。官方发布说明与 benchmark 方法称，该比较使用 100 份真实文档和六种替代工具。AnyDoc 是这次测试中唯一覆盖全部 14 种格式的工具。

这是一份值得参考的厂商证据，不是通用速度纪录。试点时要固定 AnyDoc 版本、硬件、预热方式和样本，并测量 p50、p95、结构验收率、内容缺失、人工更正分钟数与失败文档。一个几毫秒完成但损坏财务表格的 parser，在业务上并不快。

AnyDoc、Docling、MarkItDown 还是 Firecrawl Parse？

Docling 当前支持格式文档列出 PDF、Office、OpenDocument、EPUB、图片、HTML、markup、音频和视频，工具包其他部分还提供 OCR 与结构化导出。这种广度很适合版式复杂或多模态语料，但不代表它一定是更轻量的 Office 转换器。

Microsoft MarkItDown 官方文档介绍了按格式安装的可选依赖、通过插件实现的 OCR，以及用于高质量版式和结构化提取的付费 Azure 路径。它适合重视扩展性的 Python 产品。AnyDoc 更适合需要聚焦、本地、多语言 binding 和统一办公文档输出的团队。

Firecrawl 的托管 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 路由评测。那篇文章负责原生文本判断、混合页面分流，以及何时开始 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 评测计划

1. 抽取真实样本：至少选择 200 份文档，覆盖所有相关格式、语言、年代与来源，并加入损坏、加密、含宏与超大文件。
2. 定义验收：按文档类型标记必须保留的标题、备注、表格、合并单元格、链接、公式、页码与资源。
3. 建立当前基线：记录验收率、p50、p95、基础设施成本、人工审核分钟数与 fallback 比例。
4. 测试固定版本：使用同一指标，并把 warm parsing 与进程启动、上传时间分开。
5. 比较两种替代方案：在困难视觉子集上测试 Docling，在共有办公格式上测试 MarkItDown。
6. 攻击边界：在计划中的 sandbox 内测试伪装、压缩、嵌套和高资源消耗文件。
7. 计算 fallback：统计 OCR 调用、人工审核、拒绝和最终影响用户的失败。
8. 按验收行动决策：只有在质量与安全过线，并且总成本或延迟改善时才上线。

使用我们的 AI 智能体单次行动成本模型，把重试和人工修复留在分母里。如果文档入库即将成为产品基础设施，Wavect 的 AI enablement 服务可以帮助评测语料、构建路由层，并连接检索或流程自动化。Twinsoft AI 案例展示我们如何约束并追踪 AI 输出，MVP 技术栈选择指南则帮助判断哪些解析层应由团队自持。

研究边界

状态核对日期为 2026 年 8 月 10 日。本文 benchmark 数据来自厂商，不是 Wavect 实测。我们核对了公开仓库、benchmark 方法和替代方案官方文档，但没有拿到 AnyDoc 私有语料，也没有执行安全审计。版本、格式、托管限制与价格可能变化，采购前应固定并复核。