夜雨聆风把文档交给 AI，最麻烦的往往不是它读不读得出来，而是读出来以后还是一团乱。
双栏 PDF、扫描页、公式、表格、页眉页脚、脚注，这些东西人眼会自动跳过去，模型不会。资料一多，最后塞进上下文里的不是知识，而是一堆版面噪音。前面写 MarkItDown：文档别硬塞给 AI 时，重点还是“先统一格式”；MinerU 再往前走一步，想先把版面和结构也一起理顺。
MinerU 现在更像一层面向 RAG 和 Agent 的文档入口，它能把 PDF、图片、DOCX、PPTX、XLSX 转成 Markdown 和 JSON，顺手处理阅读顺序、标题层级、表格、公式、图片说明这些模型真正会用到的部分，而不是只吐一段干巴巴的 OCR 文本。
双栏、扫描页、表格和公式一起进上下文时，模型拿到的往往先是噪音
这也是 MinerU 和“能读 PDF”的普通工具差别最大的地方。官方文档把目标说得很直接，输出不是给人做高保真排版回看的，而是给后续检索、抽取和处理流程用的。页眉页脚会被清掉，文字尽量按人类阅读顺序重排，表格会转成 HTML，公式会转成 LaTeX。对知识库和 Agent 来说，这比单纯识字更有用，因为后面切块、索引、引用时，至少拿到的是比较成形的材料。
它更像把杂乱文档先整理成结构化材料，再送进检索和工作流
另外一个现实原因是，资料来源从来不只是一种格式。很多团队嘴上说在做 PDF 解析，手里实际混着投标书、扫描件、PPT、周报、表格和截图。MinerU 把这些输入放在同一条链上处理，确实更像今天 AI 工作流需要的入口层。官方首页现在把这件事讲得很清楚，除了本地 CLI，还给了 FastAPI、WebUI、REST API、MCP Server，以及和 LangChain、Dify、FastGPT 这类框架的接法。换句话说，它想做的不是孤零零一个解析命令，而是能接进整条资料处理流程。
不过这类项目最容易被高估的地方，也得提前说，MinerU 不是“文档理解一次到位”。官方 Quick Start 里提醒得很克制，复杂版面、扫描页、手写内容仍然可能解析不理想，最好先拿样本去试，再决定部署方式。这个态度是对的。文档解析最怕的就是还没看结果，就先把系统接进下游问答和自动化里。
更稳的路径不是先部署一大套，而是先试效果，再决定本地解析和工作流接入
如果只是想判断值不值得看，MinerU 现在给的试法比很多开源项目省心。按官方文档，先可以直接用线上版或桌面客户端看结果；真要落到本地，uv pip install -U "mineru[all]" 就能装，命令行入口也很短，mineru -p <input_path> -o <output_path>。设备不够跑高精度后端时，还能退到 pipeline，走纯 CPU 路线。官方在 Quick Start 里甚至把几种后端的准确率、内存和硬件门槛摊开写了，这点比只谈“效果很好”靠谱得多。
最近几个版本也能看出它在往实用层补。官方 changelog 里，2026 年 6 月的 3.3、3.4 版本主要在提 Hybrid 后端速度、OCR 流程、模型下载体验；更早一些的 2026 年 1 月，还在持续修跨页表格合并。这个更新方向挺说明问题，项目不是在追一个很花哨的演示，而是在补那些真正会影响资料入库质量的细节。
它更适合资料整理、知识库和 Agent 入口，不适合把高要求抽取任务一把包办
所以更稳的看法是，MinerU 适合放在“资料先过一遍”的位置上。混合文档要进知识库、RAG 或 Agent 流程时，它比只做 Markdown 转换更进一步，也比把原始文件直接扔进模型更可控。可如果目标是合同字段、票据审核、强合规抽取，或者必须逐页校对到很细的程度，那就别把它当终点，后面还得接更重的人工校验或专门系统。
如果你最近正被 PDF、PPT、Word 和扫描件一起拖慢，MinerU 值得先拿几份真资料试一下。先看它能不能把版面噪音收掉，再决定要不要接进后面的检索、知识库或 Agent 流程，这样更省弯路。
项目地址：
- GitHub: https://github.com/opendatalab/MinerU
- 官方文档: https://opendatalab.github.io/MinerU/
- 官方网站: https://mineru.net/
想先把资料入口收干净？
后面会继续写文档解析、知识库和 Agent 工作流，重点看哪些工具适合先接进资料入口，哪些场景还得另找方案。
微信里点顶部账号「哒哒_Fan」关注，后面更新会直接出现在订阅里。