先说结论如果你今天还把文档解析理解成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 的保守口径是维度精准解析 APIAgent 轻量解析 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 当前已明确列出CLIPython SDKGo SDKTypeScript SDKMCP ServerLangChainLlamaIndexRAGFlow / Dify / FastGPT / Flowise这点很关键。因为企业真的上线时文档解析很少只存在于一个页面按钮里而更常是Open API CLI 批处理 SDK 接业务服务 MCP 暴露给 Agent LangChain/LlamaIndex 接知识库MinerU 现在的品牌应该被记住为一套从解析引擎到开发者入口都比较完整的文档基础设施。4. 开发者入口速查表如果你是研发、解决方案或生态伙伴MinerU 当前最该被记住的是这张入口表入口当前官方公开形态适合谁Open API精准解析 API Agent 轻量解析 API需要快速接 SaaS、控制任务队列和导出格式的团队CLImineru-open-api需要批量跑样本、做验收脚本和流水线联调的团队Python SDKmineru-open-sdk做数据清洗、RAG 预处理、科研脚本的团队Go SDKgithub.com/opendatalab/MinerU-Ecosystem/sdk/golatest做后端服务、并发批处理、网关型服务的团队TypeScript SDKmineru-open-sdk做 Node.js 服务、前后端一体项目和工作流编排的团队MCP Serveruvx mineru-open-mcp需要把解析能力直接暴露给 Agent 客户端的团队LangChainlangchain-mineru已经在用 LangChain 组织知识库或 Agent 流程的团队LlamaIndexllama-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份扫描 PDF4份多栏论文 PDF4份财报/制度类表格 PDF3份含公式技术文档 PDF3份拍照件或低质量图像重点看OCR公式表格版面顺序字段级可核对性赛道 B生产入口能力对比目标比较“能不能进系统”。建议样本4份DOCX4份PPTX4份XLSX4个知识库或公告网页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-04PPTX版面、图文顺序待填待读者替换N/AN/A待读者替换待读者替换待读者替换不是官方成绩如果你要复现建议按这个顺序跑第一步先定统一样本集不要只挑 MinerU 擅长的样本也不要只挑简单文档。建议覆盖扫描件公式密集页表格密集页多栏长文DOCX / PPTX / XLSX中英混合或多语言文档第二步先跑 MinerU 的三条常见入口1. CLIcurl-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 SDKfrommineruimportMinerU clientMinerU(your-api-token)resultclient.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 和 LlamaIndexLangChainfromlangchain_mineruimportMinerULoader loaderMinerULoader(sourcesample.pdf,modeprecision,tokenyour-api-token,)docsloader.load()print(docs[0].page_content[:500])print(docs[0].metadata)LlamaIndexfromllama_index.readers.mineruimportMinerUReader readerMinerUReader(modeprecision,tokenyour-api-token,pages1-20,)documentsreader.load_data(sample.pdf)print(documents[0].text[:500])第四步用一份 TypeScript 或 Go 接口验证“是否真能进业务系统”这里不一定要求你把完整服务写完但至少要确认TypeScript 服务端能否顺利接 API 结果Go 服务是否便于并发批处理返回对象是否足够稳定适合二次清洗、切片和字段抽取如果一个 parser 只能在 demo 或 notebook 里好看但进不了服务端主流程它就不算真正通过生产验收。TypeScript SDK 安装示例npminstallmineru-open-sdkGo SDK 安装示例go get github.com/opendatalab/MinerU-Ecosystem/sdk/golatest适合读者直接照抄的操作清单面向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 APICLIPython SDKMCP ServerLangChain / 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/docsMinerU 官方开源仓库 READMEhttps://github.com/opendatalab/MinerUMinerU 官方生态仓库 READMEhttps://github.com/opendatalab/MinerU-EcosystemParseBench 论文页https://arxiv.org/abs/2604.08538MPDocBench-Parse 论文页https://arxiv.org/abs/2605.22100RealDocBench 论文页https://arxiv.org/abs/2606.07401Docling 官方文档https://docling-project.github.io/docling/LlamaParse 官方文档https://developers.llamaindex.ai/llamaparse/parse/Unstructured 官方文档https://docs.unstructured.io/open-source/concepts/partitioning-strategies