文档处理最烦的往往不是“转成 Markdown”而是 Word、PPT、Excel、PDF 每种格式都带着自己的脾气。anydoc 的思路很直接先把不同文件解析成同一个 Document 模型再从同一条出口生成干净 Markdown。如果你正在做 RAG、知识库、文档问答或 Agent 文件读取这个项目值得先收藏。本文只讲它解决了什么问题以及接入前必须知道的边界。文档转换最麻烦的从来不是“转”很多团队一开始会给每种文件找一个工具DOCX 用一个解析器PPTX 再接一个PDF 还要单独处理最后把结果拼到同一条 AI 流程里。问题很快就会出现标题、列表、脚注和表格在不同格式里表现不一致同一份内容经过不同工具后Markdown 规则、转义方式和空行习惯都不一样图片、嵌入对象和表格结构容易丢后面的 RAG 切分只能继续打补丁文件扩展名改了解析器可能就判断错但文件内容本身并没有变。真正难的是让“输入格式不同”不再影响“输出结构”。anydoc 到底是什么一句话理解anydoc 是一个用 Rust 编写的文档转换底座把多种办公文档统一转成 GitHub-Flavored Markdown。官方 README 列出的输入包括 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB、CSV 和 PDF同时提供 Rust、Node.js、Python、浏览器 WebAssembly 和 CLI 绑定。项目还附带 Agent Skill可以让兼容的编程 Agent 直接学会调用它读取文档。官方在线 Demo 还有一个很值得注意的细节浏览器版本使用 WebAssembly 在本地完成转换文件不会上传到服务器。对于内部资料、合同和本地知识库这个默认路径很有吸引力。它的核心不是“格式多”而是“中间模型统一”处理环节传统拼接式方案anydoc 的统一路线文件识别经常按扩展名分流根据文件内容标记判断格式解析结果每个工具一套结构汇入共享 Document 模型Markdown 输出各工具自己拼规则统一 GFM 序列化器表格、脚注、标题需要逐格式修补在统一输出层集中处理嵌入图片和对象容易在中间丢失模型保留资源字节和媒体类型这个设计带来的实际收益是修一次 Markdown 转义、表格或标题锚点问题多个输入格式都能一起受益。4 步看懂 anydoc 的工作流1. 读取文件字节支持从路径或内存中的 bytes 开始 2. 根据 PDF 头、RTF 标记、OLE 流、ZIP 包中的 MIME 等内容判断格式 3. 把标题、段落、列表、表格、脚注、图片资源等汇入共享 Document 模型 4. 通过统一的 GFM Markdown 序列化器输出结果或者停在 Document 模型继续加工。这条链路对 AI 应用尤其重要你可以把 Markdown 作为通用中间格式也可以保留 Document 模型里的图片和嵌入资源不必一开始就把所有内容压扁成纯文本。值得关注的 5 个能力1. 输入格式覆盖够广项目支持.doc、.docx、.docm多种 PowerPoint 和 Excel 格式以及 OpenDocument、RTF、EPUB、CSV、PDF。对于“用户随手上传什么都可能有”的系统这比只支持 DOCX 的解析器更省分流逻辑。2. 结构保留不止正文README 列出的结构包括标题锚点、粗体、斜体、删除线、行内代码、代码块、链接、内部交叉引用、嵌套列表、合并单元格、表头、引用、脚注、尾注和演讲者备注。3. 嵌入资源不会被简单丢掉图片和嵌入对象会在 Markdown 中以替代文本呈现同时原始字节会保留在 Document 模型中并带有媒体类型信息。做知识库时你可以根据业务决定只喂文字还是把图片资产一起入库。4. 本地、快速、少依赖项目强调纯 Rust、无机器学习模型、无外部服务。README 的基准测试中anydoc 在 100 份真实文档、14 种格式上给出的中位转换时间是 4.4ms。不过这是项目自己的测试结果真实耗时仍要用你的文件集回归。项目基准指标anydoc 结果覆盖格式14/14中位转换时间4.4ms综合得分81测试文档100 份5. Agent 接入成本很低它不仅是一个库还提供了 Agent Skillbash npx skills add firecrawl/anydoc安装之后Agent 可以把文档转换当成一个标准能力来调用。对 Codex、Claude Code、Cursor 这类需要读取项目资料和附件的工作流来说这个入口比每次手写解析脚本更容易复用。3 种最小接入方式CLI先快速验证一份文件bash npx firecrawl/anydoc report.docx npx firecrawl/anydoc slides.pptx -o slides.md npx firecrawl/anydoc - --format csv data.csvNode.js接入后端或构建脚本bash npm install firecrawl/anydocts import { toMarkdown, toMarkdownBytes } from firecrawl/anydocconst markdown await toMarkdown(report.docx) const fromBytes await toMarkdownBytes(bytes, csv) 浏览器本地转换文件bash npm install firecrawl/anydoc-wasmts import init, { toMarkdownBytes } from firecrawl/anydoc-wasmawait init() const markdown toMarkdownBytes(bytes) 它适合什么不适合什么适合多格式文件上传、知识库入库和 RAG 预处理Agent 读取 DOCX、PPTX、CSV 等用户资料需要统一 Markdown 输出的内容流水线想在浏览器本地完成基础文档转换的工具。不适合直接当成扫描件 PDF 的 OCR 引擎追求完全还原 Word 页面视觉效果的排版器对复杂图表、宏、密码保护文件零改动转换的万能工具不做真实文件回归就直接承诺所有业务文档都能完美解析的黑盒。项目边界与我的判断anydoc 解决的是文档结构归一化不是所有文档问题图片型 PDF 没有可提取文字时仍然需要独立 OCR 能力Markdown 本身无法完整表达 Word/PPT 的视觉布局样式还原和语义转换要分开评估加密、损坏、未知格式和超过安全限制的文件会返回明确错误业务层需要记录失败原因项目 benchmark 很亮眼但你的文件可能包含特殊字体、复杂合并单元格或嵌入对象必须建立自己的样本集。如果你的系统正在被“每种文件一个解析器”拖慢anydoc 值得作为统一入口试一轮。它最有价值的地方不是格式列表很长而是把格式差异压在解析层把后续 AI、搜索和入库流程统一起来。后续我会继续拆解它的 Document 数据结构、Node/Python 绑定和 Agent Skill 实际接入方式。项目地址https://github.com/firecrawl/anydoc