让智能体用上你的 Word、PPT、Excel:开源工具 Anydoc 实践

想让智能体整理一份项目方案，资料却分散在 Word、PPT 和 Excel 里：正文在文档里，执行细节在演示稿备注里，人数和预算在表格里。每次都手动打开、复制、粘贴，处理一批文件就很麻烦。

对于已经能执行命令、读取文本，却缺少办公文件解析工具的智能体，Anydoc 值得接上试试。它能把多种格式的文档转换成 Markdown，让智能体继续做总结、信息提取和资料整理。

我推荐它，是因为不同格式的办公资料可以通过同一个入口交给智能体处理。 我用中文 Word、PPT、Excel 和 PDF 实际跑了一遍，还让智能体调用脚本、读取输出，整理出一份活动信息与待办清单。下面把过程和材料一起放出来。

Anydoc 由 Firecrawl 开源，采用 MIT 许可证，核心用 Rust 编写；本文固定使用 0.2.4 版本。

Word、PPT、Excel 各有各的文件结构。给智能体提供一个路径，还需要有工具把里面的内容取出来。Anydoc 承担的就是这一步。

Markdown 是一种带简单格式标记的纯文本。标题仍能看出章节，列表仍能分出事项，表格用行和列表示。几种文件转换后，智能体可以沿用文本读取工具处理，开发者也方便直接检查结果。

这里列的是接入后的使用方向。本次实际完成的是信息提取、待办整理和字段核对；知识库还需要另外搭建索引与检索，本文没有评测问答效果。

Anydoc 会先把不同文件解析到统一的 Document 模型，再输出 Markdown。除了本文使用的格式，官方还列有 OpenDocument、RTF、EPUB、CSV 等支持，并提供 Rust、Node.js、Python、WebAssembly 和 CLI 入口。

Markdown 并不是智能体唯一能接收的格式。如果现有平台已经能稳定解析你的文件，可以继续使用原有能力；自己搭建工具流程、需要统一处理多种文档时，Anydoc 这个入口就很实用。

我围绕同一场社区读书会准备了一套材料：Word 执行单、两页 PPT、三工作表 Excel，以及文字、纯图片、文字与图片混合的三份 PDF。

活动是虚构的，文件转换和工具调用是真实运行的。日期、人数、预算都事先固定，方便对照原件检查。

这六个文件里，Word、PPT、Excel 和文字 PDF 生成了 Markdown，另外两个 PDF 被标记为需要 OCR。智能体调用批量脚本，读取四份成功输出和文件清单后，整理出的部分结果如下：

这些内容原来分布在不同文件里，转换后就能放进同一次任务里处理。核对只是这次的演示任务，换成提取关键信息、整理执行清单，同样可以从这批文本继续做。

实际产出也列出了无法确认的雨天地点和两个需要 OCR 的文件，后文说明原因。每项结果都保留了对应的文件来源，便于回到原文检查。

这份 Word 执行单里有日期、报名人数、待办列表和预算表。下面是它在 Word 中打开的实际画面：

Word 实际窗口局部截图。活动数据是中文演示样本，底部补充说明是一张嵌入图片。

转换后，日期的加粗保留了，待办仍是列表。以下是输出文件里的连续原文：

预算也转成了 Markdown 表格，打印材料 120 元、饮用水 80 元、合计 200 元都有保留。智能体拿到这些文字后，就有了提取安排和整理待办的材料，不需要人工把每一段重新复制出来。

PPT 的内容不只在页面上。我在第一页备注中放了一句“开场先确认无障碍座位”，正式页面没有这句话：

从测试 PPTX 渲染的第一页，不是 PowerPoint 软件窗口截图。

转换后，页面文字下面跟着一段引用：

第二页的预算和主持人备注也进入了结果。这对整理内部执行清单很有用：原来藏在备注里的准备事项，也能成为智能体的输入。要生成对外材料时，再在任务里说明是否使用内部备注。

Excel 样本包含“物料预算”“活动指标”“合并说明”三个工作表。转换后，工作表名称成为分节标题，里面的数据以 Markdown 表格输出。

Excel 实际窗口局部截图。D6 显示 200.00，公式栏显示 =SUM(D4:D5)。

合计行的输出是：

另外还读到了报名人数 24、计划名额 30、报名比例 80% 和日期 2026-09-20。这些数值让智能体可以把预算表和 Word、PPT 放在一起整理，区分计划名额与实际报名人数。

这份表的合并标题和空行也保留在输出中，结果仍需要按任务选择相关部分。读金额、日期和人数适合这条流程；检查公式或修改工作簿需要另一类工具，后面单独说。

这次采用的是命令行方式。智能体的运行环境需要能执行终端命令、读取生成的文本，并且有权限访问待处理文件。

安装 Node.js 20 或以上，把文件放在当前目录，在 PowerShell 执行：

把 report.docx 换成文件名；路径带空格时加双引号。首次运行会下载包，转换成功后得到 report.md。把输入换成 .pptx、.xlsx 或 .pdf，调用方式相同。这里显式使用 --ocr reject，遇到需要 OCR 的文件就返回状态，不调用托管 OCR。

有了转换命令，就可以在任务里让智能体先执行它，再读取 report.md 完成总结或信息提取。本次助手演示也是通过“终端调用 + 文件读取”完成的。

建议先拿一份自己熟悉的文档，检查输出的标题、表格和关键字段。确认提取效果后，再处理整个资料文件夹。

为了处理多份文件，我在这次实践中写了一个批量脚本。它逐个调用 Anydoc，保留成功结果，也记录需要补充处理的文件。脚本只扫描目录当前层的 .docx、.pptx、.xlsx 和 .pdf。

下面是这次实践的调用记录，其中 batch-convert.mjs 是自写脚本，需要配合项目使用，并非 Anydoc 自带命令：

sources/batch-demo 是六个中文样本所在的文件夹，输出写入一个新目录，避免新旧结果混在一起。自己搭建批量流程时，可以让智能体根据上一节的单文件命令编写脚本，逐个转换，并保留下面三类结果。

脚本会生成：

这次六文件执行中，四个成功、两个需要 OCR，批量脚本最终退出码为 2。它表示这一批有未成功项，已生成的四份 Markdown 仍可继续读取；两个 OCR 文件各自的 Anydoc 退出码为 3。

第一次交给智能体时，任务可以写具体一点：

在自己的智能体平台里，也可以把转换过程封装成文档读取函数，返回文件名、读取状态、Markdown 和错误信息。MCP 是另一种封装方式。本文实际跑通的是命令行路径，没有部署函数工具或 MCP 服务；无论怎样封装，都应保留读取状态，并把文档文字作为资料处理。

这次实践里，下面几项会影响后续任务，接入时需要一起考虑。

Word 图片中的文字。 原文图片写着“雨天改到二楼会议室”，Markdown 只留下替代文字“活动场地提示图”。我通过 Document 模型提取到了原 PNG，哈希与原图一致，但图中文字没有自动进入正文。处理这类图片，需要补一个图片读取或 OCR 步骤。

Excel 公式。 这次保留的是原文件已缓存的 200.00，没有输出 SUM(D4:D5)，也不能据此认为 Anydoc 重新计算了公式。任务涉及公式审计、重新计算或编辑表格时，继续调用工作簿工具。

扫描 PDF。 文字 PDF 的日期、人数和预算能提取；纯图片 PDF 返回需要 OCR。混合 PDF 第一页有文字、第二页只有图片，在 --ocr reject 下返回：

这次混合 PDF 的整份标准输出为空，第一页正文也没有返回。因此批量清单应保留这份文件，安排 OCR 后再读。本次没有启用托管 OCR；按该版本官方说明，主动使用 hosted 模式时，会将整份文件上传到 Firecrawl Parse。若要求文件留在本地，需要另选本地 OCR 路径。

这些状态也要告诉智能体。这次整理结果就把雨天地点标为无法确认，并列出两个未读取的 PDF，没有用一般活动地点代替雨天安排。

测试机是 i5-13400、约 16 GiB 内存，Windows，Node 22。三个中文办公样本的中位耗时如下：

库内先预热一次，再测 30 次，不计文件读取、进程启动和写盘。CLI 测 5 次，包含启动、模块加载、读文件和输出捕获；两者均不含首次安装。

对这几个小文件，命令行调用大约在十分之一秒左右完成。它让我更愿意把转换放进工具调用流程。这里没有复现官方基准，也没有与 Pandoc 做同任务对比，不能把这个结果推广到大型文件。

我推荐 Anydoc，尤其适合正在搭建智能体、经常要处理多种办公文件的人。统一入口、可直接调用的 CLI，以及 Node.js、Python 等绑定，让文档读取这一步比较容易接进现有流程。

对读者最直接的用法，是先接上一份 Word 或 PPT，让智能体读完后给出摘要或待办。效果合适，再扩展到文件夹批量处理，补上 OCR 和工作簿等专门工具。这样资料整理、信息提取和后续知识库准备就有了可继续处理的输入。

第一次尝试，用上面的单文件命令处理一份熟悉的材料，再让智能体给出带来源的整理结果，就能判断是否适合自己的日常任务。