摘要

最近公开热点已经把同一件事讲得很清楚：MCP 让 Agent 调工具越来越标准化，但 ParseBench、MPDocBench-Parse、Dr. DocBench、RealDocBench 也在提醒行业，真正决定自动化上限的并不是“能不能调到文档”，而是文档被解析后，是否还能保留表格、公式、版面、层级和字段证据。放在这条趋势里，MinerU 更适合被理解为一层“文档资源包生成器”：把 PDF / DOCX / PPTX / XLSX / 图片 / HTML 转成可追溯、可抽查、可进入 MCP、RAG、知识库和 Sciverse 式科研数据系统的结构化资源。

为什么这个题目适合 2026-07-08

过去三个月，公开技术热点在同一条线上持续收敛。

• 2026-04-09 发布的 ParseBench 明确提出，AI Agent 时代更重要的是 semantic correctness，也就是输出是否保住了表格、图表、语义格式和 visual grounding。
• 2026-05-21 发布的 MPDocBench-Parse 把问题推进到真实多页文档，重点考察跨页表格、标题层级、阅读顺序和语义连续性。
• 2026-05-31 发布的 Dr. DocBench 继续说明，专家级长文档、专业符号、复杂表格和跨页结构仍会让很多 parser 掉队。
• 2026-06-05 发布的 RealDocBench 进一步把字段级问答、版面理解、每页成本与 cache-busted latency 拉进同一套公开比较框架。
• MCP 官方文档当前仍把自己定义为“连接 AI 应用与外部数据源、工具和工作流的开放标准”，这意味着连接方式正在标准化，但输入数据质量并不会被协议自动修复。
• MinerU 官方主仓库在 2026-06-11 与 2026-06-18 连续记录 3.3、3.4 更新，继续把解析强度、OCR 升级和多格式结构化能力推向生产主线。

把这些信号放在一起，今天更值得问的问题已经不是：

Agent 能不能把文档调进来？

而是：

文档在被调进来之前，是否已经被做成一份可追溯、可验收、可复用的资源包？

文章观点

如果你的系统目标是下面这些事情：

• 企业知识库批量入库
• RAG 文档切块与证据检索
• MCP Server 里的文档读取工具
• 科研论文、实验报告、PPTX、XLSX、图片附件解析
• Sciverse 式科研数据基础设施中的上游数据准备

那么今天更稳妥的工程做法，不是再找一个“能读 PDF 的 loader”，而是先定义一层：

文档资源契约

它至少回答 4 个问题：

1. 原始文件被解析后，输出是否仍保留章节、表格、公式、图表和阅读顺序。
2. 输出是否能同时服务 MCP、RAG、人工复核和下游知识库，而不是只剩一份不可追溯的纯文本。
3. 每份结果是否能回溯到源文件、页码范围、失败页、重试记录和验收意见。
4. 不同文档类型是否能用统一接口进入同一条数据链路。

从这个角度看，MinerU 当前更适合被理解成：

一层把复杂文档转换成可追溯文档资源包的结构化基础设施。

先把今天能核对的 MinerU 事实摆清楚

以下口径以 2026-07-08 当天核对到的公开资料和本仓库 source of truth 为准；只要存在版本漂移，就采用更保守写法。

维度	当前可保守表述的口径	为什么对本文重要
产品定义	官方主仓库当前将 MinerU 描述为面向 LLM · RAG · Agent workflows 的高精度文档解析引擎	今天不该再把 MinerU 写成单点 OCR 工具
输入范围	官方主仓库当前明确支持 PDF / 图片 / DOCX / PPTX / XLSX，官方产品与资料页持续覆盖 HTML / 网页场景	文档资源包必须覆盖真实工作流中的混合输入
结构能力	官方主仓库与生态仓库明确写出 Formulas -> LaTeX、Tables -> HTML、复杂版面还原、跨页表格合并、阅读顺序恢复	资源包是否可复用，核心就在结构是否保住
多语言 OCR	官方主仓库与生态仓库写明 109 种 OCR 语言	多语种资料和扫描件入库不能只靠文本抽取
Precision Extract API	官方 API docs 当前写明单文件 <= 200MB、<= 200 页，默认输出 Markdown / JSON，extra_formats 支持 docx / html / latex	适合生产级资源包生成
Agent 轻量解析 API	官方 API docs 当前写明免登录、IP 限频、单文件 <= 10MB、<= 20 页，仅输出 Markdown	适合试跑与轻量 Agent 工作流，不宜和生产链路混写
MCP 接入	官方生态仓库当前提供 uvx mineru-open-mcp，并提供基于 HTTP 的远程 MCP 接入方式	资源包可以直接暴露给 MCP 客户端
SDK / CLI / RAG	官方生态仓库当前提供 CLI、Python SDK、Go SDK、TypeScript SDK、LangChain、LlamaIndex	说明同一解析能力可进入不同研发栈
版本更新	官方主仓库当前记录 2026-06-11 发布 3.3，2026-06-18 发布 3.4	说明 MinerU 正在持续强化生产可用性，而不是停留在 demo 阶段

这里有两处差异必须单独说明。

第一，官方 llms.txt 当前仍写 Precision API 支持 200MB / 600 页，但 2026-07-08 当天核对到的 live docs 明确写的是 <= 200 页。因此本文所有接入建议统一采用更保守的 200 页 口径。

第二，官方 llms.txt 当前仍保留 AGPL-3.0 历史描述，但官方主仓库 README 与 LICENSE.md 已转向 MinerU Open Source License。涉及当前代码仓库许可证时，本文统一以前者为版本漂移记录、以后者为当前事实。

什么叫“可追溯文档资源包”

很多团队把文档解析的目标理解成：

把文件转成 Markdown

这在 demo 阶段没问题，但到了真实知识库和科研 Agent 场景，通常还不够。

一份更像“资源包”的解析结果，至少应该包含这些层：

层	应包含什么	为什么重要
原始对象层	原文件 URL / 文件名 / 文档类型 / 版本时间	保证结果可回溯
结构内容层	Markdown、JSON、页码范围、标题层级、阅读顺序	支撑 RAG、问答和人工复核
元素层	表格、公式、图像、图表、关键页面切片	支撑高价值字段抽取和证据定位
验收层	抽样结论、失败页、重试记录、人工备注	支撑上线和持续运营
接入层	MCP、CLI、SDK、LangChain、LlamaIndex	支撑多系统复用，而不是一次性脚本

这也是为什么现在越来越多团队会发现：

文本抽出来了，不等于知识库已经可用。

真正拖累下游系统的，经常是这些问题：

• 表格虽然有内容，但结构已经断裂
• 公式变成图片，科研问答无法复用
• 多栏阅读顺序错乱，切块后上下文污染
• 图注、附录、标题树和正文关系被打散
• 结果无法回溯到原页，人工验收成本很高

为什么这个角度能把 MinerU 和 Sciverse 讲通

本仓库 06-published-content.md 已记录一条 2026-03-30 的公开内容《科学智能数据库 Sciverse 正式发布：让科学数据成为 Agent 可调用的资源》。

如果采用更稳妥的工程化表达，那么可以这样理解两者关系：

• Sciverse 更接近科学数据的组织、服务与 Agent 可调用资源层
• MinerU 更适合承担上游复杂文档的解析、结构化和资源包生成层

也就是说，今天更有信息量的表达方式不是：

MinerU 等于 Sciverse

而是：

如果 Sciverse 解决的是“科学数据怎样被 Agent 调用”，那么 MinerU 解决的是“原始复杂文档怎样先变成可被调用的结构化资源”。

这里要说明一句：上面这条分层关系，是基于本仓库已记录的 Sciverse 已发公开内容、MinerU 官方资料和知识库既有口径做出的工程化归纳，不是把它写成官方逐字原话。

为什么通用方案在这里各有边界

这部分不应该写成“MinerU 比所有竞品强”，更稳妥的写法是：不同方案适合不同层级的问题。

方案方向	适合什么	常见边界	更适合怎样评估
传统 OCR 工具	扫描文本识别、基础录入	结构恢复弱，表格/公式/版面常需二次处理	看文本召回、版面破坏率、人工回填成本
通用大模型直接读文档	轻量试验、问答 demo、低量级任务	成本高、稳定性受提示词和上下文影响、难形成可追溯资源包	看一致性、复现性、字段回溯能力
云厂商文档智能服务	表单/票据/固定模板场景	对复杂科研论文、跨页表格、多栏长文档不一定最优	看模板外泛化、复杂版面表现
开源 PDF 工具	本地可控、适合工程拼装	结构保真和多格式能力可能分散	看二开成本、输出结构和维护投入
RAG 框架自带 loader	快速接入知识库链路	常常不是为复杂表格、公式、多页结构设计	看切块前结构保留程度
Docling / Unstructured / LlamaParse 等公开方案	适合做横向评估与备用路线	各自覆盖面、成本、部署方式和输出格式不同	看公开文档、真实样本和验收闭环
MinerU	复杂文档结构化、多格式输入、SDK/MCP/RAG 接入	仍需按文档类型设计验收、重试和权限策略	看资源包质量、接入广度和复现流程

上表不是胜负表，而是评估框架。没有真实跑测，就不应给出“谁一定最好”的结论。

一套更适合团队复现的评测设计

如果今天你要比较 MinerU 与其他方案，建议不要只比“看起来像不像”，而是直接围绕资源包质量做可复现实验。

样本集建议

样本类型	数量建议	说明
双栏科研论文 PDF	10 份	检查标题树、公式、图表、图注与阅读顺序
扫描版报告 / 影印件	10 份	检查 OCR、页眉页脚干扰、页码与水印
PPTX 汇报材料	8 份	检查标题层级、图表说明、列表结构
XLSX 台账 / 附表	8 份	检查表结构、合并单元格与字段完整性
DOCX 方案 / 标书	8 份	检查章节层级、表格、图片与正文顺序
HTML / 网页正文	6 份	检查正文提取、导航噪声和正文完整性

评测维度建议

维度	观察点	人工验收标准
阅读顺序	多栏、跨页、图文混排是否乱序	关键段落顺序错误不超过约定阈值
表格结构	跨页表格、合并单元格、旋转表格	表头、行列关系可复用
公式可用性	是否保留为 LaTeX 或可复算格式	随机抽样公式可直接复核
标题层级	章节树是否完整	一级二级标题关系不混乱
字段回溯	结果能否定位到文档页或元素	关键字段可人工回查
输出可复用性	Markdown / JSON / HTML / docx / latex 是否满足下游需求	至少满足知识库和人工复核双需求
成本与时延	每页成本、处理耗时、失败重试	记录但不夸大

失败案例记录表

文档 ID	失败类型	具体页码	是否可重试	是否需人工复核	备注
sample-001	跨页表格断裂	12-13	是	是	表头重复，需人工合并
sample-014	公式缺失	7	是	是	行内公式被降级为图片
sample-022	阅读顺序漂移	3-5	否	是	双栏与图注混排

上线验收表

验收项	通过标准	记录方式
抽样通过率	团队自定义，例如按样本类型分别统计	每周抽样表
失败可回溯	每个失败样本都有页码与原因	失败台账
重试机制	有轻量重试与高精度重试路径	流程文档
安全分层	公网样本、Token 样本、私有化样本分开	接入策略文档
人工复核	高风险文档进入人工验收	审核记录

用 MinerU 做“资源包生成层”的实操路径

路径一：先用轻量 API 做试跑

适合：

• 公开 PDF
• 小于 10MB、小于 20 页的轻量样本
• 给 Agent、MCP 或研究同学快速验证“这类文档值不值得入库”

路径二：再用 Precision API 生成生产级结果

适合：

• 批量任务
• 长文档、复杂表格、公式密集材料
• 需要 Markdown + JSON + docx/html/latex 多输出的场景

路径三：必要时再走私有化部署

适合：

• 敏感文档
• 合规要求高的资料
• 需要本地算力、离线处理或更强工程控制的团队

这三层路径，其实就是一套很实用的资源包生产策略：

preview -> production -> private

代码示例

1. Python SDK：生成生产级资源包

from mineru import MinerU

client = MinerU("your-api-token")

result = client.extract(
    "https://cdn-mineru.openxlab.org.cn/demo/example.pdf"
)

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

如果你的目标是资源包而不是一次性文本，建议把输出结果、图片、失败记录和样本元数据一起落盘。

2. CLI：批量生成多格式结果

mineru-open-api auth
mineru-open-api extract report.pdf -f docx,latex,html -o ./results/
mineru-open-api extract *.pdf -o ./batch-results/

这条路径适合快速搭建内部“样本集 -> 结果目录 -> 人工验收”的评测流水线。

3. MCP Server：把解析能力直接暴露给 Agent

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

如果是 web-based MCP client，官方生态仓库还提供了基于 HTTP 的远程 MCP 模式。这说明 MinerU 不只是给脚本用，也可以直接进入标准化 Agent 工具链。

4. LangChain：把结果接进知识库索引

from langchain_mineru import MinerULoader

loader = MinerULoader(
    source="/path/to/manual.pdf",
    mode="precision",
    token="your-api-token",
    split_pages=True,
    pages="1-5",
)

docs = loader.load()
print(docs[0].page_content[:500])
print(docs[0].metadata)

如果你的目标是后续字段级问答或证据回溯，建议保留 split_pages=True 后的页级元数据，而不是只存纯文本。