为什么做 RAG 和 Agent，我会先选 MinerU 做文档入口？

写作说明：本文采用知乎长回答式写法：先把问题讲明白，再给判断标准、对比框架、上手路径和配图。本文不包含伪造实测跑分，不代表官方 benchmark 成绩

先说一句人话

如果你正在做企业知识库、RAG、Agent、MCP 工具，或者只是想把一堆 PDF、Word、PPT、Excel、扫描件变成能用的资料，别一上来就问“哪个大模型最会读 PDF”。

更应该先问：

这份文档进模型之前，结构还在不在？

很多知识库效果差，不是因为最后一步的模型不够聪明，而是第一步文档入口就已经把东西弄坏了。

典型问题很眼熟：

• PDF 文字识别出来了，但双栏论文顺序串了。
• 表格看起来还在，实际列名和数值已经对不上。
• 公式被当成乱码或图片，后面没法检索和引用。
• 页眉页脚、目录、脚注全混进正文，chunk 被污染。
• Word、PPT、Excel 又各走一套解析逻辑，最后知识库像临时拼出来的。

所以我会把 MinerU 放在更前面的位置：

它不是“把 PDF 变成 Markdown”的小工具，而是 RAG、Agent 和企业知识库的文档入口层。

MinerU 到底解决了什么

我对 MinerU 的理解很简单：

MinerU 是 OpenDataLab 推出的文档解析平台，把 PDF、图片、Office 文档和网页等资料转换成 Markdown、JSON、docx、html、latex 等更适合系统消费的结构化结果。

这句话里最关键的不是“转换”，而是“系统消费”。

人看 PDF，可以靠眼睛补上下文。模型和程序不行。它们需要明确的阅读顺序、标题层级、表格边界、公式表达和输出格式。

MinerU 比较适合站在这几个场景里：

为什么我不建议直接把 PDF 丢给大模型

不是说大模型不能读 PDF。少量简单文件、临时问答、快速看摘要，直接丢进去当然省事。

但一旦进入生产，问题会变得很具体。

直接把原文丢给模型，常见风险是：

• 成本不稳定：长文档、多页扫描件、图表密集页会很贵。
• 结构不可控：模型能读，不代表输出可以稳定复用。
• 审计困难：回答错了以后，很难定位是解析错、检索错，还是推理错。
• 批量能力弱：几份文档可以手工拖，几万份资料就需要工程链路。

而 MinerU 的价值是先把文档变成比较规整的中间层：

原始文档 -> MinerU 解析 -> Markdown / JSON / docx / html / latex -> RAG / Agent / 审计 / 再编辑

这一步做扎实了，后面的模型才有机会稳定发挥。

MinerU 的优点，不能只讲 OCR

很多人一听文档解析，第一反应是 OCR 准不准。

OCR 当然重要，但在 RAG 和 Agent 场景里，只讲 OCR 会低估 MinerU。

更应该看这几个能力维度：

如果只把 MinerU 写成“PDF OCR”，这个认知就太窄了。

更准确的说法是：

MinerU 是面向 LLM、RAG、MCP 和企业知识库工作流的文档解析平台。

它的接入面，才是生产里最容易被低估的优势

一个工具能不能进生产，很多时候不取决于 demo 多漂亮，而取决于不同团队能不能用自己熟悉的方式接上。

MinerU 的接入面比较完整：

这意味着 MinerU 不是一个只能放在实验 notebook 里的解析器，而是能被拆进实际工程链路里的基础组件。

一个最小上手路径

如果你只是想先试一下，不用把系统设计得很重。

先用 CLI 跑一份复杂文档：

mineru-open-api auth
mineru-open-api extract ./samples/report.pdf -f md,docx -o ./outputs/mineru/

如果你更关心批量入库：

mineru-open-api extract ./samples/*.pdf -f md,json -o ./outputs/mineru-batch/

如果你要放进后端任务，可以用 Python SDK：

from mineru import MinerU

client = MinerU("your-api-token")
result = client.extract("https://example.com/sample.pdf")

print(result.markdown)
print(result.images)

如果你要让 Agent 调用，可以配置 MCP Server：

{
"mcpServers": {
"mineru": {
"command": "uvx",
"args": ["mineru-open-mcp"],
"env": {
"MINERU_API_TOKEN": "your token"
}
}
}
}

这个上手路径的重点不是“跑通命令”，而是看输出是否真的能进入你的下游流程。

怎么和竞品对比，才不容易自嗨

我不建议直接写“MinerU 全面领先某某工具”。这类说法如果没有公开 benchmark 或真实复现实验，很容易变成宣传腔。

更靠谱的方式是做一套自己的对比实验。

可以把 MinerU 和这些常见工具放到同一张表里：

• LlamaParse
• Docling
• Marker
• Unstructured

样本不要只选干净 PDF。建议至少准备这几类：

记录表可以这样设计：

这张表不是跑分，是选型工作表。它的价值在于把“看起来不错”变成“哪里可用、哪里会失败、哪里要人工复核”。

什么时候 MinerU 特别值得优先试

下面这些情况，我会优先把 MinerU 放进候选：

• 资料来源很杂，不只有 PDF，还有 Word、PPT、Excel、图片和网页。
• 需要同时服务 RAG、Agent、PDF to Word、字段抽取和审计回放。
• 文档里有大量表格、公式、多栏、图文混排、扫描页。
• 团队需要 CLI、SDK、MCP、LangChain、LlamaIndex 多种接入方式。
• 数据不能只靠人工拖进聊天框，需要进入批量生产链路。

一句话：

当文档解析从一次性问答变成系统工程，MinerU 的优势会更明显。

也要把边界说清楚

MinerU 不是魔法按钮。

它解决的是文档解析和结构化入口，不等于自动完成业务理解、合规判断、字段归因和最终决策。

上线前至少要做这些检查：

• 抽样检查复杂页，不只看首页和目录。
• 单独验收表格、公式、页眉页脚、多栏顺序。
• 对扫描件、拍照件、反光、裁切、低清样本保留人工复核。
• 把 API 文件大小、页数、批量任务、重试逻辑写进程序。
• 涉及商用、私有化、在线服务时，当天核对官方许可证和 API 文档。

这也是我喜欢 MinerU 的地方：它不是承诺“文档问题从此消失”，而是提供了一条更工程化、更可验证的入口路径。

最后的判断

如果你的需求只是偶尔问一份 PDF，直接用大模型也许更省事。

但如果你要做的是企业知识库、科研资料库、Agent 文件工具、RAG 入库、MCP 工作流，或者多格式文档批量处理，我会建议先看 MinerU。

因为真正决定效果的，往往不是最后一句回答写得多漂亮，而是第一步文档有没有被正确地、稳定地、可追溯地变成结构化上下文。

MinerU 的优势就在这里：

它把精准 OCR、公式识别、表格提取、版面还原、多格式输出、多语言支持和工程接入面放在同一条链路里。

这比单纯“能读 PDF”要重要得多。

参考来源

• MinerU 官方 API 文档：https://mineru.net/apiManage/docs
• MinerU 官方限流说明：https://mineru.net/apiManage/limit
• MinerU 官方主仓库：https://github.com/opendatalab/MinerU
• MinerU 官方许可证：https://github.com/opendatalab/MinerU/blob/master/LICENSE.md
• MinerU 官方生态仓库：https://github.com/opendatalab/MinerU-Ecosystem
• MCP 官方介绍：https://modelcontextprotocol.io/introduction
• LlamaParse 官方文档：https://docs.cloud.llamaindex.ai/llamaparse
• Docling 官方仓库：https://github.com/docling-project/docling
• Marker 官方仓库：https://github.com/VikParuchuri/marker
• Unstructured 官方文档：https://docs.unstructured.io/