让 Agent 处理一份 2026 年的 .doc 合同、一个 .pptx 路演 PPT、一张 .xlsx 财务表——它无法直接处理，因为大多数 Agent 不能读取这些二进制格式。Firecrawl 8 月初开源的 anydoc，9 天拿到 1.5 万 Star，解决的问题只有一个：把办公文档转成 Agent 可直接读取的 Markdown，中位耗时 4.4 毫秒。
文档转 Markdown 为什么还是个问题
现有工具各有盲区：MarkItDown 只覆盖 6 种格式，Pandoc 不覆盖 Excel 转 Markdown，Mammoth 只认 docx；LibreOffice 虽然格式覆盖广，但安装包 300-400MB，且输出质量低。
实际业务中文档格式混杂——.doc 合同、.xlsx 报表、.pptx 方案同时出现，需要组合三四个工具才能覆盖，而且各工具的输出结构也不统一。目前没有单一工具能覆盖全部常见办公文档格式。
anydoc 做了什么
一次调用，14 种格式统一输出为 GitHub Flavored Markdown。
支持格式：Word（.doc/.docx/.docm）、PowerPoint（.ppt/.pps/.pot/.pptx/.pptm/.ppsx/.ppsm）、Excel（.xls/.xlsx/.xlsm/.xlsb）、OpenDocument（.odt/.ods/.odp）、RTF、EPUB、CSV、PDF。
格式检测基于文件内容本身而非扩展名：PDF 文件头、OLE 流名、RTF 文件开头的 {\rtf 标记、ZIP 包的 mimetype 和 content types。即使扩展名缺失或不匹配，也能正确识别格式。
除 PDF 外，其余 13 种格式解析后汇入同一个 Document 模型，再经过同一个 GFM 序列化器输出。PDF 单独经 pdf-inspector 子模块提取文本并输出 Markdown。共享序列化器的好处：修复一处序列化逻辑，改动自动生效于全部 13 种格式。
纯 Rust 实现，不依赖 ML 模型、外部服务或系统级依赖。Node.js 绑定在 libuv 线程池运行，不阻塞事件循环；Python 绑定在调用时释放 GIL，允许其他 Python 线程并行执行。
速度与质量横评
Firecrawl 官方基准测试：100 份真实文档，覆盖 14 种格式，LLM 盲评打分（Claude Sonnet），0 到 100 分。
几点说明：
Mammoth 评分 70，但仅覆盖 docx 一种格式；anydoc 评分 81，覆盖全部 14 种。各工具的综合评分是其支持格式的加权平均，覆盖范围不同，评分不能直接跨工具比较。按单一格式逐项对比更公平，anydoc 在每一个被评测的格式上均领先。速度差距是结构性的：anydoc 4.4ms，排名第二快的 Mammoth 也要 52.5ms（仅覆盖 docx），最慢的 LibreOffice 1129.5ms——anydoc 比单格式最快的 Mammoth 仍快 12 倍，比格式覆盖最接近的 LibreOffice 快约 256 倍。将综合评分按维度拆开，anydoc 在完整性（87）、结构（79）、排版（78）、整洁度（81）四项均居首位。评分方法：LLM 对两个工具的输出进行成对盲评，参照文档前 6 页的渲染截图打分；每对评判两次并交换输出顺序以消除位置偏差，共 482 次评判。
测试环境：Ryzen 9 9950X3D，Windows 11，64GB DDR5-6400。需注意，anydoc 的 Rust 库和 Python 绑定计时排除了进程启动开销，实际 CLI 调用耗时会更高；竞品计时均包含完整启动流程。
怎么用：四种方式
Agent Skill（最低接入成本）
npx skills add firecrawl/anydoc一行命令安装，Claude Code、Cursor、Codex、OpenCode 等 Agent 自动识别文档并调用 anydoc CLI 转换。Skill 中包含支持的格式列表、CLI 用法、退出码含义，以及建议大文件使用 -o 写入文件而非全量读入上下文。
CLI（最快上手验证）
npx @firecrawl/anydoc report.docx # Markdown 输出到 stdoutnpx @firecrawl/anydoc slides.pptx -o slides.md # 写入文件npx @firecrawl/anydoc - --format csv < data.csv # 从 stdin 读取无需预安装，npx 自动下载当前平台的预编译二进制。如需永久安装：npm install -g @firecrawl/anydoc。
编程调用（Node.js / Python / Rust）
三种语言共享同一个 to_markdown API：
Node.js：
import { toMarkdown } from'@firecrawl/anydoc';const markdown = awaittoMarkdown('report.docx');Python：
markdown = anydoc.to_markdown("report.docx")Rust：
let markdown = anydoc::to_markdown("contract.docx")?;在代码中直接调用函数，相比 CLI 省去进程启动开销。
浏览器（WebAssembly）
import init, { toMarkdownBytes } from'@firecrawl/anydoc-wasm';const markdown = toMarkdownBytes(bytes);纯前端运行，文件不离开用户设备。官方 Demo 页[1]即基于 WebAssembly 实现，可直接在浏览器中试用。
为什么这么快
三个结构性原因：
纯 Rust，零 GC，运行时开销极低。 Rust 没有垃圾回收停顿，也没有 Python 项目常见的启动延迟或 JIT 预热阶段。单次转换不涉及运行时附加开销。
无外部进程调用。 LibreOffice 需启动完整运行时，经 UNO API、渲染、导出、后处理等环节，链路长且资源占用大。MarkItDown 需要启动 Python 子进程。anydoc 所有逻辑在同一个进程内完成。
共享文档模型。 除 PDF 外，13 种格式各自的解析器产出同一个中间表示（Document 模型），序列化只走一个 GFM 序列化器。修一次共享序列化器，等于修了所有格式的同类问题。
