为什么这个题目值得今天写最近这波文档智能热点已经不只是“谁 OCR 更准”。更值得注意的是两条同时发生的变化2026-02-27发布的AgenticOCR公开提出视觉文档 RAG 的问题不只是“能不能把整页识别出来”而是“是否有必要每次都把整页都塞进生成器”。MinerU官方仓库在2026-06-18发布3.4把pipeline后端的 OCR 升级到PP-OCRv6并明确写出在OmniDocBench v1.6上 OCR 准确率约提升11%、OCR 处理速度约提升100%。这两件事放在一起指向的是同一个工程判断企业知识库、科研数据处理、Agent 工作流接下来更需要的不是“全文无脑全量解析”而是“先把文档入口打干净再根据问题决定解析深度和送模粒度”。先说结论如果你的目标是做企业内部知识库问答论文与实验报告检索财报、招股书、专利、审计材料分析多文档 Agent 工作流那么更稳的做法通常不是文件 - 全量高成本解析 - 全文切块 - 统一塞给 RAG而是文件 - MinerU 做结构化入口 - 轻量检索/路由 - 对高价值页面或局部区域再做更深解析 - 交给 RAG / AgentMinerU 的技术价值恰好适合放在这条链路的前半段先把 PDF、图片、DOCX、PPTX、XLSX转成更适合系统消费的结构化结果让后续检索、重排、问题定位、MCP 工具调用不再直接面对原始文档噪声在需要时再决定走pipeline、vlm、MinerU-HTML或者走免登录的 Agent 轻量解析但 MinerU 不是“查询驱动 OCR”论文本身也不是完整 RAG 系统。它更像一个可落地、可接入、可路由的文档入口层。最近公开热点在说什么1. AgenticOCR 把讨论从“全文识别”推向“按需识别”AgenticOCR论文的核心观点不是再做一次传统 OCR 排名而是指出视觉文档 RAG 存在一个常见浪费页面级检索很方便但整页送进生成器会带来大量无关上下文视觉 token 预算有限整页压缩后反而更容易丢关键信息更合理的方式是按查询去找局部区域再做有针对性的识别这件事对企业知识库尤其重要因为很多真实问题只关心某张跨页表的某几列某页脚注里的限定条件某个图表旁边的一段解释合同某条款和附录之间的对应关系如果继续沿用“整页取回、整页塞模”的习惯RAG 质量很容易被无关上下文拖低。2. MCP 正在把“工具返回值干不干净”变成硬要求MCP 官方文档把它定义为连接 AI 应用与外部系统的开源标准强调它像 AI 应用的USB-C。这意味着一旦文档解析通过 MCP 暴露给 Agent工具返回值就不再只是“给人看看”而是要进入自动化链路。这时原始 PDF 页面截图、零散 OCR 文本、混乱阅读顺序都会直接变成 Agent 的上下文污染源。3. MinerU 最近版本变化让“先做入口层”这件事更现实截至2026-06-22能核对到的公开事实是3.1.0在2026-04-18明确完成PPTX/XLSX原生解析扩展并把当前代码仓库许可证切换到MinerU Open Source License3.3在2026-06-11新增 Hybrideffort强度参数3.4在2026-06-18重点升级 OCR 能力和处理速度这意味着今天写知识库方案时已经不该把 MinerU 简化成“只会读 PDF 的 OCR 工具”。截至 2026 年 6 月 22 日MinerU 当前有哪些适合写进方案的公开事实先把容易漂移的信息摆清楚避免写错项目2026-06-22 当天核对口径说明精准解析 API需要 Token适合生产接入、批量、结构化输出Agent 轻量解析 API免登录按 IP 限频更适合 Agent 工作流快速接入精准解析文件限制 200MB、 200 页来自 live docsAgent 轻量解析限制 10MB、 20 页来自 live docs精准解析支持格式PDF、图片、Doc/Docx、Ppt/PPTx、Xls/Xlsx来自 live docs每日高优先级额度1000 页/天来自 live docs开源主仓库当前输入格式PDF、图片、DOCX、PPTX、XLSX来自官方 GitHub README当前代码仓库许可证MinerU Open Source License以官方仓库 README / LICENSE 为准保守说明本仓库历史记录显示旧课件与早期摘要曾出现600 页、2000 页/天、AGPL-3.0等口径。本文对限制、许可证、支持格式一律采用2026-06-22当天核对到的官方 live docs 与官方 GitHub 仓库口径。本次未成功抓取mineru.net/llms.txt正文因此没有把它作为本文的限制项依据。更值得采用的架构先做“查询驱动解析分层”再做 RAG推荐把 MinerU 放在四层架构里理解层作用推荐做法第 1 层入口规范化把原始文档变成可检索、可路由的结构化结果用 MinerU 统一解析格式、阅读顺序、表格/公式/图片抽取第 2 层问题定位判断问题到底需要整篇、整页还是局部证据用关键词检索、向量检索、规则路由、页级召回第 3 层按需加深解析对高价值页或命中片段提高解析力度按场景选择pipeline/vlm/MinerU-HTML必要时补 OCR第 4 层生成与验证回答、摘要、抽取、Agent 执行输出前做引用、页码、字段级验证这套思路的重点不是“少解析”而是“把解析预算花在有证据价值的地方”。MinerU 在这套架构里最适合做什么1. 做统一文档入口MinerU 官方仓库当前明确覆盖PDF、图片、DOCX、PPTX、XLSX这很适合企业真实知识库因为上传源通常不是单一 PDF。2. 做 Agent 的文档工具层MinerU-Ecosystem当前公开提供mineru-open-sdklangchain-minerumineru-open-mcp面向Cursor、Claude Desktop、Windsurf的 MCP 配置方式这意味着你不必先自研一套“文档解析中间件”就能把 MinerU 挂到 Agent 流程里。3. 做“问题相关解析”的第一跳如果你要做的是先检索候选页再对命中页做更强解析最后把结构化结果送进 RAG / Agent那么 MinerU 比“截图 OCR 纯文本切块”更接近生产需求。一套不伪造跑分的可复现实验方案下面不是官方 benchmark也不是本文实测成绩。它是一套可以让读者自己复现的实验方案用来回答一个更现实的问题在你的知识库里查询驱动解析是否比全量全文解析更划算评测目标比较两条流程方案流程A. 全量解析基线所有文档直接做统一深度解析然后切块建库B. 查询驱动方案先做入口规范化和轻量索引只对命中页/命中段落再做更深解析样本设计建议至少准备 20 份文档覆盖 5 类类别样本建议关注点科研论文含公式、图表、附录的 PDF公式、跨页表、图注企业报告年报、白皮书、尽调材料页眉页脚、目录、多栏Office 文档DOCX/PPTX/XLSX原生格式入口是否稳定扫描件票据、合同扫描版OCR、倾斜、水印网页资料HTML 或公开网页是否需要MinerU-HTML任务集设计每类文档至少设计 5 个问题事实定位题答案落在单页单段表格定位题答案落在表格单元格或跨页表关系理解题答案依赖图表说明或脚注对比题答案跨 2 到 3 页干扰题检索容易召回错页记录指标指标记录方式首次可回答率问题第一次回答是否命中正确证据证据页准确率回答引用页码是否正确噪声上下文比例送入模型的总字符中无关内容占比平均送模长度每问实际送入 LLM 的字符数或 token 数追加解析次数为回答该问题额外触发深解析的次数人工复核耗时审核一问是否能在 1 分钟内确认对错示例记录表问题 ID文档类型方案 A 是否答对方案 B 是否答对证据页是否准确是否触发二次深解析备注P01科研论文待读者填写待读者填写待读者填写待读者填写公式与图注是否同时命中P07年报 PDF待读者填写待读者填写待读者填写待读者填写跨页表是否需要补解析P12合同扫描件待读者填写待读者填写待读者填写待读者填写水印是否影响条款抽取P18PPTX待读者填写待读者填写待读者填写待读者填写页内文本框顺序是否稳定一个最小代码示例先做入口解析再决定是否加深下面示例演示的是工程思路不是官方 benchmark 脚本。importosfromtypingimportListfrommineruimportMinerU clientMinerU(os.environ.get(MINERU_API_TOKEN))definitial_parse(url:str,model_version:strpipeline)-dict:第一跳先拿到结构化 Markdown/JSON用于索引和页级定位。resultclient.extract(url,model_versionmodel_version,)return{markdown:result.markdown,images:getattr(result,images,[]),meta:getattr(result,metadata,{}),}defnaive_page_retrieve(markdown:str,query:str)-List[int]:示例页级召回真实项目可替换为 BM25、向量检索或 rerank。hits[]fori,chunkinenumerate(markdown.split(\n\n)):ifany(token.lower()inchunk.lower()fortokeninquery.split()):hits.append(i)returnhits[:3]defdeep_parse_candidates(url:str)-dict:第二跳对候选页或候选裁剪片段做更深解析。 注意页范围裁剪通常由你自己的预处理或中间层完成 不要把这里当成官方 SDK 参数清单。 resultclient.extract(url,model_versionvlm,is_ocrTrue,extra_formats[html],)return{markdown:result.markdown,meta:getattr(result,metadata,{}),}defanswer_with_selective_parsing(url:str,query:str)-dict:baseinitial_parse(url,model_versionpipeline)top_hitsnaive_page_retrieve(base[markdown],query)ifnottop_hits:return{mode:base_only,pages:[],context:base[markdown][:4000],}# 真实工程中可先按 top_hits 裁剪候选页再调用更深解析。deepdeep_parse_candidates(url)return{mode:selective_reparse,pages:top_hits,context:deep[markdown],}这个示例要表达的重点只有一个不要一上来就把所有文档都走最重的解析路径。先做统一入口再根据问题触发更深解析通常更接近真实知识库成本结构。一个最小 MCP 接入示例如果你的 Agent 客户端支持 MCP可以直接采用MinerU-EcosystemREADME 里的配置方式{mcpServers:{mineru:{command:uvx,args:[mineru-open-mcp],env:{MINERU_API_TOKEN:your_key_here}}}}在这个模式下比较适合把 Agent 工作流设计成先让 Agent 调parse_documents获取结构化文档结果再做问题定位、页级召回或表格定位需要时二次触发更高成本解析或其他校验工具读者可直接复现的操作步骤路线 A用官方在线 API 做最小验证准备 5 到 20 份公开文档样本最好同时包含PDF、扫描件、DOCX/PPTX/XLSX。用精准解析 API 跑第一轮入口解析保存 Markdown、JSON、图片资源。为每份文档建立一个最小问题集至少 3 到 5 个问题。做一版“全量解析基线”所有问题都直接使用全文切块结果回答。再做一版“查询驱动方案”先做页级召回只对命中页做更深解析。用上文记录表填写结果不要补写不存在的数据。路线 B用 Agent MCP 做工作流验证在本地安装uv。按官方生态仓库配置mineru-open-mcp。让 Agent 先解析单篇文档再回答带页码要求的问题。记录 Agent 是否引用了正确页面、表格或图注。再加入“命中页才深解析”的规则比较上下文长度和人工复核效率。路线 C用 LangChain 做 RAG 接入验证安装langchain-mineru。先用flash或pipeline模式做轻量入口解析。建页级或段级索引。对高风险问题增加“二次解析”节点而不是只做一次性 ingest。对最终答案强制输出引用页码与证据片段。上线和验证时最容易漏掉的 8 件事不要把 API live docs 里的200 页限制写回旧版600 页口径。不要把当前代码仓库许可证继续写成AGPL-3.0。不要把PPTX/XLSX支持理解成所有前端或 SaaS 展现行为都完全等价。不要把“解析成功”误当成“RAG 回答可用”。不要只测文本页必须加入扫描件、表格页、图表页、跨页页。不要把整页 Markdown 全量塞给生成器后再抱怨模型引用不准。不要省略人工抽检文档问答系统最终还是证据系统。不要伪造基准分数宁可给复现实验表也不要杜撰跑分。这篇文章真正想说明什么当行业开始讨论AgenticOCR这类“按需解析”思路时MinerU 的价值反而更清楚了。它最值得被使用的地方不是被包装成“万能 RAG”而是作为多格式文档入口层Agent / MCP 的文档工具层查询驱动解析架构中的第一跳结构化能力如果你要做的是一个能长期上线的企业知识库或科研资料系统这种定位往往比“全量解析一次后面都靠切块和向量库硬扛”更稳。来源链接AgenticOCR 论文https://arxiv.org/abs/2602.24134MCP 官方文档https://modelcontextprotocol.io/docs/getting-started/introMinerU 官方仓库https://github.com/opendatalab/MinerUMinerU 官方 API 文档https://mineru.net/apiManage/docsMinerU-Ecosystem 官方仓库https://github.com/opendatalab/MinerU-Ecosystem来源说明本文未包含任何作者实测跑分。文中涉及3.4OCR 提升、3.1.0许可证与格式支持、API 文件大小/页数/额度、MCP 接入方式均来自2026-06-22当天可核对的公开来源。如果后续官方llms.txt、live docs、GitHub 仓库再次出现口径变化应优先以当日 live docs 与官方 GitHub 仓库重新核对。
RAG 开始嫌弃“整页喂模型”以后，MinerU 该怎么用：从 AgenticOCR 热点看查询驱动文档解析
为什么这个题目值得今天写最近这波文档智能热点已经不只是“谁 OCR 更准”。更值得注意的是两条同时发生的变化2026-02-27发布的AgenticOCR公开提出视觉文档 RAG 的问题不只是“能不能把整页识别出来”而是“是否有必要每次都把整页都塞进生成器”。MinerU官方仓库在2026-06-18发布3.4把pipeline后端的 OCR 升级到PP-OCRv6并明确写出在OmniDocBench v1.6上 OCR 准确率约提升11%、OCR 处理速度约提升100%。这两件事放在一起指向的是同一个工程判断企业知识库、科研数据处理、Agent 工作流接下来更需要的不是“全文无脑全量解析”而是“先把文档入口打干净再根据问题决定解析深度和送模粒度”。先说结论如果你的目标是做企业内部知识库问答论文与实验报告检索财报、招股书、专利、审计材料分析多文档 Agent 工作流那么更稳的做法通常不是文件 - 全量高成本解析 - 全文切块 - 统一塞给 RAG而是文件 - MinerU 做结构化入口 - 轻量检索/路由 - 对高价值页面或局部区域再做更深解析 - 交给 RAG / AgentMinerU 的技术价值恰好适合放在这条链路的前半段先把 PDF、图片、DOCX、PPTX、XLSX转成更适合系统消费的结构化结果让后续检索、重排、问题定位、MCP 工具调用不再直接面对原始文档噪声在需要时再决定走pipeline、vlm、MinerU-HTML或者走免登录的 Agent 轻量解析但 MinerU 不是“查询驱动 OCR”论文本身也不是完整 RAG 系统。它更像一个可落地、可接入、可路由的文档入口层。最近公开热点在说什么1. AgenticOCR 把讨论从“全文识别”推向“按需识别”AgenticOCR论文的核心观点不是再做一次传统 OCR 排名而是指出视觉文档 RAG 存在一个常见浪费页面级检索很方便但整页送进生成器会带来大量无关上下文视觉 token 预算有限整页压缩后反而更容易丢关键信息更合理的方式是按查询去找局部区域再做有针对性的识别这件事对企业知识库尤其重要因为很多真实问题只关心某张跨页表的某几列某页脚注里的限定条件某个图表旁边的一段解释合同某条款和附录之间的对应关系如果继续沿用“整页取回、整页塞模”的习惯RAG 质量很容易被无关上下文拖低。2. MCP 正在把“工具返回值干不干净”变成硬要求MCP 官方文档把它定义为连接 AI 应用与外部系统的开源标准强调它像 AI 应用的USB-C。这意味着一旦文档解析通过 MCP 暴露给 Agent工具返回值就不再只是“给人看看”而是要进入自动化链路。这时原始 PDF 页面截图、零散 OCR 文本、混乱阅读顺序都会直接变成 Agent 的上下文污染源。3. MinerU 最近版本变化让“先做入口层”这件事更现实截至2026-06-22能核对到的公开事实是3.1.0在2026-04-18明确完成PPTX/XLSX原生解析扩展并把当前代码仓库许可证切换到MinerU Open Source License3.3在2026-06-11新增 Hybrideffort强度参数3.4在2026-06-18重点升级 OCR 能力和处理速度这意味着今天写知识库方案时已经不该把 MinerU 简化成“只会读 PDF 的 OCR 工具”。截至 2026 年 6 月 22 日MinerU 当前有哪些适合写进方案的公开事实先把容易漂移的信息摆清楚避免写错项目2026-06-22 当天核对口径说明精准解析 API需要 Token适合生产接入、批量、结构化输出Agent 轻量解析 API免登录按 IP 限频更适合 Agent 工作流快速接入精准解析文件限制 200MB、 200 页来自 live docsAgent 轻量解析限制 10MB、 20 页来自 live docs精准解析支持格式PDF、图片、Doc/Docx、Ppt/PPTx、Xls/Xlsx来自 live docs每日高优先级额度1000 页/天来自 live docs开源主仓库当前输入格式PDF、图片、DOCX、PPTX、XLSX来自官方 GitHub README当前代码仓库许可证MinerU Open Source License以官方仓库 README / LICENSE 为准保守说明本仓库历史记录显示旧课件与早期摘要曾出现600 页、2000 页/天、AGPL-3.0等口径。本文对限制、许可证、支持格式一律采用2026-06-22当天核对到的官方 live docs 与官方 GitHub 仓库口径。本次未成功抓取mineru.net/llms.txt正文因此没有把它作为本文的限制项依据。更值得采用的架构先做“查询驱动解析分层”再做 RAG推荐把 MinerU 放在四层架构里理解层作用推荐做法第 1 层入口规范化把原始文档变成可检索、可路由的结构化结果用 MinerU 统一解析格式、阅读顺序、表格/公式/图片抽取第 2 层问题定位判断问题到底需要整篇、整页还是局部证据用关键词检索、向量检索、规则路由、页级召回第 3 层按需加深解析对高价值页或命中片段提高解析力度按场景选择pipeline/vlm/MinerU-HTML必要时补 OCR第 4 层生成与验证回答、摘要、抽取、Agent 执行输出前做引用、页码、字段级验证这套思路的重点不是“少解析”而是“把解析预算花在有证据价值的地方”。MinerU 在这套架构里最适合做什么1. 做统一文档入口MinerU 官方仓库当前明确覆盖PDF、图片、DOCX、PPTX、XLSX这很适合企业真实知识库因为上传源通常不是单一 PDF。2. 做 Agent 的文档工具层MinerU-Ecosystem当前公开提供mineru-open-sdklangchain-minerumineru-open-mcp面向Cursor、Claude Desktop、Windsurf的 MCP 配置方式这意味着你不必先自研一套“文档解析中间件”就能把 MinerU 挂到 Agent 流程里。3. 做“问题相关解析”的第一跳如果你要做的是先检索候选页再对命中页做更强解析最后把结构化结果送进 RAG / Agent那么 MinerU 比“截图 OCR 纯文本切块”更接近生产需求。一套不伪造跑分的可复现实验方案下面不是官方 benchmark也不是本文实测成绩。它是一套可以让读者自己复现的实验方案用来回答一个更现实的问题在你的知识库里查询驱动解析是否比全量全文解析更划算评测目标比较两条流程方案流程A. 全量解析基线所有文档直接做统一深度解析然后切块建库B. 查询驱动方案先做入口规范化和轻量索引只对命中页/命中段落再做更深解析样本设计建议至少准备 20 份文档覆盖 5 类类别样本建议关注点科研论文含公式、图表、附录的 PDF公式、跨页表、图注企业报告年报、白皮书、尽调材料页眉页脚、目录、多栏Office 文档DOCX/PPTX/XLSX原生格式入口是否稳定扫描件票据、合同扫描版OCR、倾斜、水印网页资料HTML 或公开网页是否需要MinerU-HTML任务集设计每类文档至少设计 5 个问题事实定位题答案落在单页单段表格定位题答案落在表格单元格或跨页表关系理解题答案依赖图表说明或脚注对比题答案跨 2 到 3 页干扰题检索容易召回错页记录指标指标记录方式首次可回答率问题第一次回答是否命中正确证据证据页准确率回答引用页码是否正确噪声上下文比例送入模型的总字符中无关内容占比平均送模长度每问实际送入 LLM 的字符数或 token 数追加解析次数为回答该问题额外触发深解析的次数人工复核耗时审核一问是否能在 1 分钟内确认对错示例记录表问题 ID文档类型方案 A 是否答对方案 B 是否答对证据页是否准确是否触发二次深解析备注P01科研论文待读者填写待读者填写待读者填写待读者填写公式与图注是否同时命中P07年报 PDF待读者填写待读者填写待读者填写待读者填写跨页表是否需要补解析P12合同扫描件待读者填写待读者填写待读者填写待读者填写水印是否影响条款抽取P18PPTX待读者填写待读者填写待读者填写待读者填写页内文本框顺序是否稳定一个最小代码示例先做入口解析再决定是否加深下面示例演示的是工程思路不是官方 benchmark 脚本。importosfromtypingimportListfrommineruimportMinerU clientMinerU(os.environ.get(MINERU_API_TOKEN))definitial_parse(url:str,model_version:strpipeline)-dict:第一跳先拿到结构化 Markdown/JSON用于索引和页级定位。resultclient.extract(url,model_versionmodel_version,)return{markdown:result.markdown,images:getattr(result,images,[]),meta:getattr(result,metadata,{}),}defnaive_page_retrieve(markdown:str,query:str)-List[int]:示例页级召回真实项目可替换为 BM25、向量检索或 rerank。hits[]fori,chunkinenumerate(markdown.split(\n\n)):ifany(token.lower()inchunk.lower()fortokeninquery.split()):hits.append(i)returnhits[:3]defdeep_parse_candidates(url:str)-dict:第二跳对候选页或候选裁剪片段做更深解析。 注意页范围裁剪通常由你自己的预处理或中间层完成 不要把这里当成官方 SDK 参数清单。 resultclient.extract(url,model_versionvlm,is_ocrTrue,extra_formats[html],)return{markdown:result.markdown,meta:getattr(result,metadata,{}),}defanswer_with_selective_parsing(url:str,query:str)-dict:baseinitial_parse(url,model_versionpipeline)top_hitsnaive_page_retrieve(base[markdown],query)ifnottop_hits:return{mode:base_only,pages:[],context:base[markdown][:4000],}# 真实工程中可先按 top_hits 裁剪候选页再调用更深解析。deepdeep_parse_candidates(url)return{mode:selective_reparse,pages:top_hits,context:deep[markdown],}这个示例要表达的重点只有一个不要一上来就把所有文档都走最重的解析路径。先做统一入口再根据问题触发更深解析通常更接近真实知识库成本结构。一个最小 MCP 接入示例如果你的 Agent 客户端支持 MCP可以直接采用MinerU-EcosystemREADME 里的配置方式{mcpServers:{mineru:{command:uvx,args:[mineru-open-mcp],env:{MINERU_API_TOKEN:your_key_here}}}}在这个模式下比较适合把 Agent 工作流设计成先让 Agent 调parse_documents获取结构化文档结果再做问题定位、页级召回或表格定位需要时二次触发更高成本解析或其他校验工具读者可直接复现的操作步骤路线 A用官方在线 API 做最小验证准备 5 到 20 份公开文档样本最好同时包含PDF、扫描件、DOCX/PPTX/XLSX。用精准解析 API 跑第一轮入口解析保存 Markdown、JSON、图片资源。为每份文档建立一个最小问题集至少 3 到 5 个问题。做一版“全量解析基线”所有问题都直接使用全文切块结果回答。再做一版“查询驱动方案”先做页级召回只对命中页做更深解析。用上文记录表填写结果不要补写不存在的数据。路线 B用 Agent MCP 做工作流验证在本地安装uv。按官方生态仓库配置mineru-open-mcp。让 Agent 先解析单篇文档再回答带页码要求的问题。记录 Agent 是否引用了正确页面、表格或图注。再加入“命中页才深解析”的规则比较上下文长度和人工复核效率。路线 C用 LangChain 做 RAG 接入验证安装langchain-mineru。先用flash或pipeline模式做轻量入口解析。建页级或段级索引。对高风险问题增加“二次解析”节点而不是只做一次性 ingest。对最终答案强制输出引用页码与证据片段。上线和验证时最容易漏掉的 8 件事不要把 API live docs 里的200 页限制写回旧版600 页口径。不要把当前代码仓库许可证继续写成AGPL-3.0。不要把PPTX/XLSX支持理解成所有前端或 SaaS 展现行为都完全等价。不要把“解析成功”误当成“RAG 回答可用”。不要只测文本页必须加入扫描件、表格页、图表页、跨页页。不要把整页 Markdown 全量塞给生成器后再抱怨模型引用不准。不要省略人工抽检文档问答系统最终还是证据系统。不要伪造基准分数宁可给复现实验表也不要杜撰跑分。这篇文章真正想说明什么当行业开始讨论AgenticOCR这类“按需解析”思路时MinerU 的价值反而更清楚了。它最值得被使用的地方不是被包装成“万能 RAG”而是作为多格式文档入口层Agent / MCP 的文档工具层查询驱动解析架构中的第一跳结构化能力如果你要做的是一个能长期上线的企业知识库或科研资料系统这种定位往往比“全量解析一次后面都靠切块和向量库硬扛”更稳。来源链接AgenticOCR 论文https://arxiv.org/abs/2602.24134MCP 官方文档https://modelcontextprotocol.io/docs/getting-started/introMinerU 官方仓库https://github.com/opendatalab/MinerUMinerU 官方 API 文档https://mineru.net/apiManage/docsMinerU-Ecosystem 官方仓库https://github.com/opendatalab/MinerU-Ecosystem来源说明本文未包含任何作者实测跑分。文中涉及3.4OCR 提升、3.1.0许可证与格式支持、API 文件大小/页数/额度、MCP 接入方式均来自2026-06-22当天可核对的公开来源。如果后续官方llms.txt、live docs、GitHub 仓库再次出现口径变化应优先以当日 live docs 与官方 GitHub 仓库重新核对。
