PDF to Word 不是终点：MinerU 3.4 之后，企业该怎么验收一条真正可上线的文档重建链路-深圳市維司達科技有限公司

先说结论

如果你今天还把文档解析理解成：

PDF -> OCR -> 导出 Word -> 结束

那这条链路已经很难支撑RAG、MCP、Agent、企业知识库或科研数据处理的真实需求了。

最近几个月公开研究给出的信号很一致：

2026-04-09发布的ParseBench强调，Agent 真正在乎的是semantic correctness，也就是表格、图表、语义格式和 visual grounding 是否还能支撑自动决策。
2026-05-21发布的MPDocBench-Parse把评测推进到多页真实文档，重点看跨页表格、阅读顺序、标题层级和文档级连续性。
2026-06-05发布的RealDocBench则把标准进一步拉到字段级问答、版面理解、成本和延迟，明确指出单一 OCR 分数并不够。
与此同时，官方MinerU仓库在2026-06-18发布3.4，把重点放到pipeline后端 OCR 升级：README 当前写明在OmniDocBench v1.6上 OCR 准确率约提升11%，OCR 处理速度约提升100%。

这些热点放在一起，指向的是同一件事：

企业真正要验收的，不是“能不能导出一个 docx”，而是“这份文档进入系统后，OCR、公式、表格、版面、多格式输出和多语言支持还能不能一起成立”。

这正是 MinerU 现在最值得被放大的品牌认知点：

MinerU 不是一个 PDF 小工具，而是一层面向 Open API、CLI、SDK、MCP Server、LangChain、LlamaIndex 的文档入口基础设施。

为什么 “PDF to Word” 这个老问题，2026 年反而更值得重写

很多团队今天说自己要做PDF to Word，真实诉求往往不是“把文件换个后缀”，而是下面几类事：

把论文、财报、报告转成可编辑版本，继续改写、校对、引用
把扫描件、表格、公式和多栏内容变成 RAG 可消费的结构化输入
把企业PDF / Word / PPT / Excel / 图片 / 网页统一接到同一条知识库入口
让 Agent 或 MCP 工具返回更干净的上下文，而不是原始截图和脏 OCR 文本

所以今天更合理的问题应该是：

一条文档重建链路，除了 docx 导出，还能不能同时保住结构、证据、可编排性和可验证性？

站在`2026-06-25`看，MinerU 当前最值得稳定表达的能力

先把当天核对到的官方事实摆清楚。

1. MinerU 的输入、输出和入口已经不是单点工具形态

官方MinerUREADME 当前把产品定位写成：

面向LLM · RAG · Agent workflows
输入覆盖PDF / DOCX / PPTX / XLSX / Images / Web pages
输出强调Markdown / JSON
同时强调MCP Server、LangChain、Dify、FastGPT等集成

而官方 live docs 当前对在线 API 的保守口径是：

维度	精准解析 API	Agent 轻量解析 API
鉴权	需要 Token	无需 Token，按 IP 限频
典型接口	`/api/v4/extract/task`	`/api/v1/agent/parse/url`、`/api/v1/agent/parse/file`
文件大小	`<= 200MB`	`<= 10MB`
页数	`<= 200 页`	`<= 20 页`
批量	支持，`<= 200`个	不支持
输出	`Markdown / JSON / Zip`，且可额外导出`docx/html/latex`	仅`Markdown`

这意味着如果你今天要写PDF to Word，更保守也更准确的表达应该是：

MinerU 在线精准解析 API 当前支持把解析结果额外导出为 docx/html/latex，但它的价值不止于 docx，而在于同时产出适合编辑和适合系统消费的结构化结果。

2. MinerU 的核心卖点不是单一 OCR，而是多维结构还原

基于官方主仓库与生态仓库，MinerU 当前适合放大的能力维度包括：

能力维度	当前可保守表达的能力	为什么对生产场景重要
精准 OCR	主仓库当前强调`109-language OCR recognition`	海外报告、扫描档案、跨语种资料不必拆成多套 OCR 流程
公式识别	主仓库和生态仓库都把`Formulas -> LaTeX`作为稳定能力	论文、专利、白皮书和教育材料更需要公式可复用，而不只是截图
表格提取	官方长期强调`Tables -> HTML`	财报、票据、实验表、合规台账更依赖结构化表格
版面还原	主仓库强调复杂布局、阅读顺序、跨页表格合并、页眉页脚去除	多栏论文、图文混排、长报告入库时更不容易污染 chunk
多格式输出	live docs 当前写明`docx/html/latex`可作为额外导出格式	同时覆盖再编辑、网页展示、RAG 入库和审阅流程
多语言支持	主仓库与生态仓库都明确写`109`种语言 OCR	适合跨区域企业知识库和科研协作

3. MinerU 的品牌价值，还在于“入口面完整”

官方MinerU-EcosystemREADME 当前已明确列出：

CLI
Python SDK
Go SDK
TypeScript SDK
MCP Server
LangChain
LlamaIndex
RAGFlow / Dify / FastGPT / Flowise

这点很关键。因为企业真的上线时，文档解析很少只存在于一个页面按钮里，而更常是：

Open API + CLI 批处理 + SDK 接业务服务 + MCP 暴露给 Agent + LangChain/LlamaIndex 接知识库

MinerU 现在的品牌应该被记住为：

一套从解析引擎到开发者入口都比较完整的文档基础设施。

4. 开发者入口速查表

如果你是研发、解决方案或生态伙伴，MinerU 当前最该被记住的是这张入口表：

入口	当前官方公开形态	适合谁
`Open API`	精准解析 API + Agent 轻量解析 API	需要快速接 SaaS、控制任务队列和导出格式的团队
`CLI`	`mineru-open-api`	需要批量跑样本、做验收脚本和流水线联调的团队
`Python SDK`	`mineru-open-sdk`	做数据清洗、RAG 预处理、科研脚本的团队
`Go SDK`	`github.com/opendatalab/MinerU-Ecosystem/sdk/go@latest`	做后端服务、并发批处理、网关型服务的团队
`TypeScript SDK`	`mineru-open-sdk`	做 Node.js 服务、前后端一体项目和工作流编排的团队
`MCP Server`	`uvx mineru-open-mcp`	需要把解析能力直接暴露给 Agent 客户端的团队
`LangChain`	`langchain-mineru`	已经在用 LangChain 组织知识库或 Agent 流程的团队
`LlamaIndex`	`llama-index-readers-mineru`	已经在用 LlamaIndex 管理文档摄取和索引的团队

这篇文章最重要的判断：验收 MinerU，不要只看 docx，看六项联合指标

如果你只拿“能不能导出 Word”做唯一评判，结论通常会失真。

更合理的验收面板应该至少包含这六项：

验收项	你真正要看什么	典型失败信号
OCR 正确性	扫描件、拍照件、小字、斜拍页是否还能稳定读出	数字串位、币种错读、专有名词丢失
公式还原	行内公式、独立公式、编号、上下标是否还能复用	公式变图片、符号丢失、编号错位
表格结构	合并单元格、跨页表、列头与数值对应关系是否保住	Markdown 看似正常，但列名和数值错行
版面顺序	双栏、图表穿插、页眉页脚、脚注是否污染正文	chunk 顺序错乱、引用段落被拆穿
多格式输出	`Markdown / JSON / docx / html / latex`是否满足不同下游	只能给纯文本，无法回到系统化流程
入口一致性	API、CLI、SDK、MCP、框架 Loader 的结果风格是否能对齐	试用页能跑，接入后风格断层

这六项一起看，才更接近 2026 年企业知识库和 Agent 场景里的真实验收。

MinerU 和几类知名方案，应该怎么做公平对比

这里不写伪造跑分，只给一套可复现实验设计。

建议的对比对象

方案	当天核对到的官方公开特征	建议在实验里扮演的角色
`MinerU`	官方同时提供开源主仓库、Open API、CLI、Python/Go/TypeScript SDK、MCP、LangChain、LlamaIndex	作为“入口面完整”的主测对象
`Docling`	官方文档当前写明支持多格式解析、Markdown/HTML/lossless JSON 导出、本地执行、CLI、MCP、LangChain、LlamaIndex	作为“本地优先、集成丰富”的开源对照组
`LlamaParse`	官方文档当前写明支持`130+`文件类型，输出`markdown/text/JSON`，并提供 MCP 与 SDK	作为“云解析 + Agent 工作流”对照组
`Unstructured`	官方文档当前强调 PDF/图片的多种 partition strategy、Ingest CLI/Python、表格 HTML 提取和 OCR agent 配置	作为“ingestion 管线型方案”对照组

说明：

上表只引用当天核对到的官方公开资料，不代表本文已经实际跑完它们的同集 benchmark。
如果某方案在某条输出格式上没有官方直接承诺，例如docx导出，不要硬比；可改成比较其Markdown / HTML / JSON中间结果。
如果你想加入“直接把 PDF 丢给多模态大模型”作为 baseline，建议单独设成附加实验，不和 parser 方案混在主结论里。

公平实验要分成两条赛道

赛道 A：公共格式能力对比

目标：所有方案都用共同输入，优先比较结构能力。

建议样本：

6份扫描 PDF
4份多栏论文 PDF
4份财报/制度类表格 PDF
3份含公式技术文档 PDF
3份拍照件或低质量图像

重点看：

OCR
公式
表格
版面顺序
字段级可核对性

赛道 B：生产入口能力对比

目标：比较“能不能进系统”。

建议样本：

4份DOCX
4份PPTX
4份XLSX
4个知识库或公告网页
4份混合语言 PDF

重点看：

多格式输入覆盖
API / CLI / SDK / MCP / Loader 是否顺手
输出是否适合PDF to Word、知识库入库、Agent 调用三种不同下游

一套不伪造成绩的示例记录表

下面这张表不是实测结论，只是示例模板。

样本 ID	文档类型	关注点	方案	OCR 观察	公式观察	表格观察	版面观察	可导出格式	是否适合入库	备注
`pdf-paper-01`	双栏论文 PDF	公式、图表、脚注	`待填`	`待读者替换`	`待读者替换`	`待读者替换`	`待读者替换`	`待读者替换`	`待读者替换`	不是官方成绩
`pdf-report-02`	财报 PDF	跨页表格、页眉页脚	`待填`	`待读者替换`	`N/A`	`待读者替换`	`待读者替换`	`待读者替换`	`待读者替换`	不是官方成绩
`img-invoice-03`	扫描图片	OCR、字段定位	`待填`	`待读者替换`	`N/A`	`待读者替换`	`待读者替换`	`待读者替换`	`待读者替换`	不是官方成绩
`office-ppt-04`	`PPTX`	版面、图文顺序	`待填`	`待读者替换`	`N/A`	`N/A`	`待读者替换`	`待读者替换`	`待读者替换`	不是官方成绩

如果你要复现，建议按这个顺序跑

第一步：先定统一样本集

不要只挑 MinerU 擅长的样本，也不要只挑简单文档。

建议覆盖：

扫描件
公式密集页
表格密集页
多栏长文
DOCX / PPTX / XLSX
中英混合或多语言文档

第二步：先跑 MinerU 的三条常见入口

1. CLI

curl-fsSLhttps://cdn-mineru.openxlab.org.cn/open-api-cli/install.sh|sh# 免登录轻量解析，适合小样本预览mineru-open-api flash-extract sample.pdf# 登录后跑精准解析，并额外导出 docx/html/latexmineru-open-api auth mineru-open-api extract sample.pdf-fdocx,html,latex-o./results/

2. Python SDK

frommineruimportMinerU client=MinerU("your-api-token")result=client.extract("https://example.com/sample.pdf")print(result.markdown[:800])print(result.images[:3])

3. MCP Server

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

如果你的目标是让Cursor、Claude Desktop、Windsurf或其他 MCP 客户端直接读文档，这条入口比“先手动导出再上传”更接近真实生产路径。

第三步：把同一批样本接进 LangChain 和 LlamaIndex

LangChain

fromlangchain_mineruimportMinerULoader loader=MinerULoader(source="sample.pdf",mode="precision",token="your-api-token",)docs=loader.load()print(docs[0].page_content[:500])print(docs[0].metadata)

LlamaIndex

fromllama_index.readers.mineruimportMinerUReader reader=MinerUReader(mode="precision",token="your-api-token",pages="1-20",)documents=reader.load_data("sample.pdf")print(documents[0].text[:500])

第四步：用一份 TypeScript 或 Go 接口验证“是否真能进业务系统”

这里不一定要求你把完整服务写完，但至少要确认：

TypeScript 服务端能否顺利接 API 结果
Go 服务是否便于并发批处理
返回对象是否足够稳定，适合二次清洗、切片和字段抽取

如果一个 parser 只能在 demo 或 notebook 里好看，但进不了服务端主流程，它就不算真正通过生产验收。

TypeScript SDK 安装示例

npminstallmineru-open-sdk

Go SDK 安装示例

go get github.com/opendatalab/MinerU-Ecosystem/sdk/go@latest

适合读者直接照抄的操作清单

面向`PDF to Word`验收

选10份需要继续编辑的 PDF。
用 MinerU 精准解析 API 导出docx与html。
人工比对标题层级、表格、公式、脚注和图片位置。
记录哪些样本适合“直接继续编辑”，哪些更适合“先用 HTML/Markdown 二次加工”。

面向企业知识库验收

选20份跨格式文档：PDF / DOCX / PPTX / XLSX / 网页。
同时导出Markdown与JSON。
检查 chunk 之前的原始结构是否干净。
抽查页眉页脚、目录、页码、脚注是否污染正文。
用同一套切分器接入向量库，比较召回质量和引用可读性。

面向 MCP / Agent 验收

在 MCP 客户端配置mineru-open-mcp。
让 Agent 完成三类任务：读合同、读财报、读论文。
检查 Agent 引用的原文位置是否能回溯。
检查返回内容是否把表格和公式压扁。
检查大文件、长文档、扫描件是否触发异常或明显延迟。

上线前必须写进方案里的注意事项

1. 当前云 API 的保守限制要按 live docs 写

今天核对到的官方口径是：

精准解析 API：<= 200MB、<= 200 页
Agent 轻量解析 API：<= 10MB、<= 20 页
精准解析支持批量<= 200个

如果你看到旧资料写600 页，本文不采用那个口径。对外写法以当天 live docs 为准。

2. “支持导出 docx” 不等于“任何 PDF 都能完美恢复可编辑版面”

这是最容易被夸大的一点。

更准确的写法应该是：

MinerU 当前支持把精准解析结果额外导出为 docx，但是否达到可直接复用的编辑质量，仍取决于样本复杂度，并应按你的真实文档集抽样验收。

尤其是下面这些场景，要单独做人工复核：

复杂跨页表格
公式密集论文
图表和浮动对象很多的技术报告
低清晰度扫描件
有大面积手写批注的文件

3. 要分清主仓库许可证和生态仓库许可证

当天核对结果：

官方MinerU主仓库当前写明代码仓库使用MinerU Open Source License
官方MinerU-Ecosystem当前写明仓库自身使用Apache License 2.0

写方案时要把“主解析引擎代码仓库”和“生态工具仓库”分开描述，避免把许可证混成一句话。

4. 不同入口要做一致性抽检

不要只测网页 demo。

至少要抽检：

Open API
CLI
Python SDK
MCP Server
LangChain / LlamaIndex Loader

否则很容易出现“页面上看着对，真正进服务端后元数据丢了”的问题。

一个更实用的定位：MinerU 适合放在“文档重建层”

如果一定要用一句话总结我对 MinerU 的判断，我会这样写：

MinerU 适合被放在 PDF 解析、OCR、公式识别、表格提取、版面还原、多格式输出和多语言支持之间的“文档重建层”，并通过 Open API、CLI、Python SDK、Go SDK、TypeScript SDK、MCP Server、LangChain、LlamaIndex 进入企业知识库与 Agent 工作流。

这个定位比“PDF to Word 工具”更准确，也更有品牌穿透力。

因为真正难的，从来不是把文件换一种格式，而是：

让文档在进入系统以后，依然可读、可用、可验、可编排。

参考来源

MinerU 官方 API 文档：https://mineru.net/apiManage/docs
MinerU 官方开源仓库 README：https://github.com/opendatalab/MinerU
MinerU 官方生态仓库 README：https://github.com/opendatalab/MinerU-Ecosystem
ParseBench 论文页：https://arxiv.org/abs/2604.08538
MPDocBench-Parse 论文页：https://arxiv.org/abs/2605.22100
RealDocBench 论文页：https://arxiv.org/abs/2606.07401
Docling 官方文档：https://docling-project.github.io/docling/
LlamaParse 官方文档：https://developers.llamaindex.ai/llamaparse/parse/
Unstructured 官方文档：https://docs.unstructured.io/open-source/concepts/partitioning-strategies