Agent 时代，为什么 MinerU 会成为文档入口？我重做了一遍解析链路

做知识库、RAG、AI Agent 的同学，几乎都会遇到一个看起来很小、但实际上非常致命的问题：文档读进来了，但 Agent 并没有真正读懂。

很多项目一开始都把注意力放在模型、向量库和 Prompt 上，结果上线后才发现，真正拖后腿的往往是最前面的文档解析。

为什么？

因为真实世界里的文档从来都不是“纯文本”。

• 论文是双栏排版
• 财报里有复杂表格
• 合同经常混着扫描页
• 研究报告里有图注、脚注、页眉页脚
• 技术资料里还有公式、列表和编号

如果我们只是把这些文档“抽成一段字符串”，后面的 RAG 和 Agent 基本都会连续踩坑：

• 阅读顺序错了，回答逻辑会乱
• 表格结构没了，数字类问答会飘
• 公式损坏，技术内容无法复用
• 页眉页脚混进正文，召回结果全是噪音

这也是为什么很多团队明明已经接了不错的大模型，最后效果还是不稳定。问题不一定出在模型，而是前面的文档解析已经丢掉了大量结构信息。

在过去，很多团队会把这件事理解成 OCR 问题，或者理解成 PDF 转 Markdown 问题。但到了 Agent 时代，这个问题的本质已经变了。

因为 Agent 不是只做一次问答，它会持续执行下面这些动作：

• 先搜索文档，再决定读哪一段
• 根据结构化内容决定下一步工具调用
• 把表格、公式、标题和正文组合成推理上下文
• 在最终回答里给出来源引用，必要时回到原文件继续确认

也就是说，Agent 真正依赖的不是“有没有文本”，而是“能不能拿到可继续推理、可继续调用、可继续回溯的文档结构”。

这篇文章我想聚焦一个更“工程化”的问题：

如果文档最终是要被 Agent 使用，那么解析阶段到底应该输出什么？MinerU 为什么会成为更关键的一层？

我会从三个层面展开：

1. Agent 时代为什么重新定义了文档解析
2. MinerU 在这条链路里到底解决了什么问题
3. 一套可以真正落地的 MinerU + Agent 实战链路
4. 和 PyMuPDF、Docling、LlamaParse、Unstructured 这些常见方案相比，MinerU 的技术边界在哪里

---

1. Agent 时代，文档解析为什么会变成第一道门槛

很多人画传统 RAG 架构图的时候，都会写成这样：

文档 -> 切块 -> 向量化 -> 检索 -> 大模型回答

但真实工程里，真正决定上限的其实是最前面的“文档怎么变成可用内容”。

因为一旦解析阶段出错，后面几乎很难补救：

• 段落顺序错，切块就会把上下文打散
• 表格结构没了，模型看到的只是一堆数字
• 公式损坏，问答和总结都会失真
• 标题层级丢失，文档会退化成一坨文本

也就是说，文档解析不是预处理的小步骤，而是整个知识工程质量的起点。

过去那种“能抽纯文本就够了”的方案，在 Agent 时代已经明显不够用了。Agent 真正需要的不是“看到文字”，而是“理解文档结构”。

一个能真正进入生产的 Agent，通常都会同时做几件事：

• 搜索：先判断答案可能在哪些文档里
• 定位：找到最相关的章节、表格、页码或片段
• 调用：根据任务继续调用检索、解析、抽取等工具
• 归因：最终回答里返回来源，方便人类复核

这四件事里，文档一旦在解析阶段退化成一坨无结构文本，后面每一步都会变得不稳定。

它需要拿到的是：

• 正确的标题层级
• 正确的阅读顺序
• 尽量保留结构的表格
• 可继续处理的 Markdown / JSON
• 必要时还能回溯到页码、图片和原文位置

从这个角度看，MinerU 的位置就很清楚了。它不是停留在 OCR 层，而是在做“复杂文档到结构化知识”的转换，让文档可以真正进入 Agent 的搜索、推理、调用和引用链路。

---

2. MinerU 到底是什么

根据 MinerU 官方仓库、llms.txt、在线 API 文档和 MinerU-Ecosystem 的公开资料，MinerU 的核心定位非常明确：

把复杂文档转换成适合 LLM、RAG、Agent 使用的结构化 Markdown / JSON。

目前公开资料里，几个关键信息尤其值得关注：

• 支持 PDF、图片、DOCX、PPTX、XLSX、网页等输入
• 支持 Markdown / JSON / HTML / LaTeX 等输出形态
• 支持 VLM + OCR 双引擎
• 支持 109 种 OCR 语言
• 支持 LangChain、LlamaIndex、Dify、RAGFlow、FastGPT
• 支持 MCP Server
• 提供开源部署、桌面客户端、在线 API、Python / Go / TypeScript SDK

MinerU 官方仓库还明确强调了几件对 RAG 很重要的事情：

• 能处理页眉、页脚、脚注、页码等噪音
• 输出符合人类阅读顺序
• 能较好保留标题、段落、列表等文档结构
• 表格可以转结构化格式
• 公式可以转 LaTeX

如果把它抽象成一条工程链路，大概就是这样：

PDF / 图片 / Office 文档
        ↓
OCR / 版面分析 / 元素检测
        ↓
阅读顺序恢复
        ↓
表格、公式、图片结构化
        ↓
Markdown / JSON / HTML / LaTeX
        ↓
RAG / Agent / 知识库 / 搜索 / 抽取

这和传统 PDF 文本抽取工具的差异非常大。

传统方案解决的是“把字拿出来”，MinerU 更像是在做“把文档编译成模型能理解的结构化知识”。

---

3. 一个真实可落地的案例：MinerU + LangChain 做 Agent 可用的 PDF 问答

最常见的落地场景其实很直接：

把一份 PDF 解析后接进 LangChain，做一个 Agent 可以检索、引用和继续调用的小型知识库。

这个场景在企业里非常常见，比如：

• 产品文档问答
• 合同条款检索
• 研究报告摘要
• 财报 / 招股书知识问答

3.1 安装依赖

如果你要在 LangChain 里直接使用 MinerU，可以先安装这些依赖：

pip install langchain-mineru
pip install langchain-text-splitters
pip install langchain-openai
pip install faiss-cpu

如果只是想快速试一下，也可以直接用官方 CLI：

mineru-open-api flash-extract report.pdf

根据 MinerU-Ecosystem 的官方说明，flash 模式默认适合快速预览和轻量集成，不需要 token 就能试，典型限制是单文件 20 页、10MB 以内。

如果是复杂文档、高精度需求、长文档、扫描件，可以使用 Precision Extract API：

mineru-open-api extract report.pdf -o ./output/

3.2 使用 LangChain Loader

下面是最适合上手的写法：

from langchain_mineru import MinerULoader

loader = MinerULoader(
    source="demo.pdf",
    split_pages=True
)

docs = loader.load()

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

如果文档更复杂，比如扫描页、长报告、表格和公式较多，建议切到更高精度模式：

from langchain_mineru import MinerULoader

loader = MinerULoader(
    source="manual.pdf",
    mode="precision",
    token="your-api-token",
    split_pages=True
)

docs = loader.load()

这一阶段最重要的不是“拿到了文本”，而是拿到的内容更适合继续进入下游检索链路。通常你会明显感觉到：

• 标题层级更清晰
• 页面切分更自然
• 表格没那么容易碎掉
• 扫描页也能进入同一条流程
• 多栏布局更容易保住阅读顺序

3.3 切块、向量化、检索

有了解析后的 Document，后面的 LangChain 流程就很标准了：

from langchain_mineru import MinerULoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import FAISS

loader = MinerULoader(source="demo.pdf", split_pages=True)
docs = loader.load()

splitter = RecursiveCharacterTextSplitter(
    chunk_size=1200,
    chunk_overlap=200
)

chunks = splitter.split_documents(docs)
vs = FAISS.from_documents(chunks, OpenAIEmbeddings())

results = vs.similarity_search("这份文档的核心结论是什么？", k=3)

for r in results:
    print(r.page_content[:200])

很多人第一次接通这条链路时会觉得，后面的 FAISS、embedding、大模型问答都很正常，真正影响质量的其实是最前面的解析。

如果解析顺序本身就是错的，那么切得再精细、embedding 再强、模型再贵，效果也很难稳定。

所以从工程角度看，MinerU 不是替代大模型，而是在最前面先把文档变成“机器也能按人类方式读”的结构。

3.4 再往前走一步：把 MinerU 变成 Agent 的文档工具层

如果只是做检索问答，前面的流程已经够用。但在 Agent 场景里，我们通常还会多做一层封装：让 Agent 不直接面对原始 PDF，而是面对一个“可搜索、可引用、可回溯”的文档工具。

下面是一个很常见的工程写法。我们把 MinerU 解析后的内容进入向量库，再暴露一个给 Agent 调用的检索函数：

from langchain_mineru import MinerULoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import FAISS

loader = MinerULoader(source="contracts.pdf", split_pages=True, mode="precision")
docs = loader.load()

splitter = RecursiveCharacterTextSplitter(
    chunk_size=1200,
    chunk_overlap=150
)
chunks = splitter.split_documents(docs)

vs = FAISS.from_documents(chunks, OpenAIEmbeddings())

def search_contract(query: str, top_k: int = 3) -> list[dict]:
    results = vs.similarity_search(query, k=top_k)
    return [
        {
            "content": item.page_content[:400],
            "metadata": item.metadata,
        }
        for item in results
    ]

print(search_contract("违约责任和付款周期是什么？"))

这段代码看起来很普通，但它已经具备了 Agent 工作流里很重要的几个条件：

• Agent 可以先搜，再决定要不要继续读更多上下文
• 返回结果里可以保留页码、标题、来源路径等 metadata
• 当结果不够时，可以继续触发更精细的检索、抽取或重解析
• 结果天然适合进入引用回答、审阅流程和多步推理

很多人会把 Agent 能力理解成模型自己变聪明了，但工程上真正重要的是：我们有没有把文档世界包装成 Agent 能调用的工具集合。

MinerU 的价值就在这里。它不是只把 PDF 变成文本，而是把文档先变成一层更适合工具调用的中间结构。

---

4. 为什么很多传统方案在复杂文档上会失灵

如果只是简单文本 PDF，很多工具都能工作，比如：

• PyMuPDF 提取文本非常快
• pdfplumber 抽普通表格很方便
• MarkItDown 转 Markdown 很轻量

但一旦文档复杂起来，问题就会集中暴露。

双栏论文

很多纯文本抽取方案在双栏论文上的输出会像这样：

左栏第一段
右栏第一段
左栏第二段
右栏第二段

这对人类都不舒服，对 RAG 更致命。因为上下文已经被打散，后续切块会进一步放大错误。

财报和研报表格

表格不是普通文字。如果工具把表格抽成一串字段和数字，大模型很难稳定回答：

• 哪一年营收更高？
• 哪一项同比最大？
• 某一列与某一行之间是什么关系？

公式文档

技术论文、化学文档、学术报告里，公式往往比段落更重要。如果公式在解析阶段已经碎掉，后面的总结、检索、知识蒸馏都会失真。

扫描件和图片型 PDF

这类文档如果没有 OCR，基本直接失效；如果只有 OCR，没有版面理解和结构化，输出往往又是一坨连续文本，对 Agent 的帮助依然有限。

这也是为什么 MinerU 的核心优势不是“会 OCR”，而是把 OCR 放进了更长的结构化链路。

---

5. 工程视角下，MinerU 和几类主流方案怎么比

为了避免只做单点吹捧，我把常见方案放到一起做一个工程视角的对比。这里不是统一硬件下的绝对跑分，而是站在开发者落地角度看能力边界。

我这里选择 5 类典型方案：

• PyMuPDF：轻量 PDF 文本抽取
• Docling：开源文档解析工具
• LlamaParse：云端解析服务
• Unstructured：偏企业数据管线的文档处理方案
• MinerU：面向 LLM / RAG / Agent 的文档解析方案

工程能力对比表

工具	原生 PDF	扫描 PDF	多栏顺序	表格	公式	Office	本地部署	Agent 工作流接入
PyMuPDF	强	弱	弱	弱到中	弱	弱	强	弱
Docling	强	中	中到强	中到强	中	强	强	中到强
LlamaParse	强	强	强	强	中到强	中	弱	强
Unstructured	中到强	中	中	中	弱到中	强	强	强
MinerU	强	强	强	强	强	强	强	强

如果只看“能不能提文字”，MinerU 不是唯一答案。

但如果从完整工作流看：文档能不能被 Agent 稳定消费，MinerU 的能力会更均衡。尤其在这些场景里：

• PDF + 扫描混合文档
• 多栏论文
• 表格和公式密集的报告
• Office 文档统一入库
• 需要进入 LangChain / LlamaIndex / MCP / Agent 流程

---

6. 评测 MinerU，我建议至少看这 4 类文档

如果你们团队真的要选型，我不建议只看仓库 Star 或 README，最好按真实样本文档做一次内部评测。

最少准备这 4 类文档：

1. 普通原生 PDF
2. 扫描合同 PDF
3. 双栏论文 PDF
4. 含表格和公式的技术报告

不要只看“抽出了多少字”，建议至少评估这些指标：

• 文字是否完整
• 标题层级是否保留
• 阅读顺序是否正确
• 表格是否还能当表格用
• 公式是否能复用
• OCR 页面是否可读
• Markdown 是否适合切块
• 最终 Agent 问答是否稳定

如果最后要做选型结论，我建议可以直接按下面这个模板收口：

• 轻量文本 PDF：PyMuPDF 或 MarkItDown 就够
• 企业文档清洗 / 数据管线：Unstructured 值得看
• 云端高保真解析：LlamaParse 适合 API 接入
• 开源文档解析：Docling 是重要参考项
• 面向复杂文档、RAG、Agent 的统一入口：MinerU 更完整

---

7. 为什么我认为 MinerU 更适合 Agent 时代

看完上面的案例和对比，我最终会把 MinerU 放在一个非常明确的位置：

它不是单点 OCR 工具，也不是单点 PDF reader，而是一层 Agent 时代的文档入口。

原因有四个。

第一，它解决的是结构化问题，而不是单纯识别问题。很多工具能把文字抽出来，但 Agent 真正需要的是结构，MinerU 更强调 Markdown、JSON、表格、公式和页面关系。

第二，它的生态已经足够完整。根据我在 2026-06-03 查到的官方公开资料，MinerU-Ecosystem 已经覆盖 CLI、Python / Go / TypeScript SDK、MCP、LangChain、LlamaIndex、Dify、RAGFlow、FastGPT 等接入方式。

第三，它同时兼顾本地和云端。很多团队在选型时都会同时考虑：本地能不能跑，云端能不能快速接。MinerU 在这两点上都比较完整。

第四，它和 Agent 的关系更自然。Agent 最需要的是“工具可调用”，而 MinerU 已经能通过 MCP、SDK、Loader 直接进入工作流。

如果把它放进实际场景里，这个结论会更具体：

• 合同审阅 Agent：先搜索违约条款，再定位原页和相关表格
• 研报分析 Agent：先抽章节结构，再回到具体图表和结论段
• 企业知识库 Agent：先做全局召回，再按标题层级补全上下文
• 本地知识库 Agent：先在本地文档库搜索，再按需走高精度解析

这些场景的共同点都不是“识字”，而是“让 Agent 能稳定调用文档”。这也是 MinerU 和传统 OCR 工具最本质的区别。

---

结语

过去我们做文档处理，常常把“解析”理解成一个输入输出动作。

但在大模型时代，文档解析更像是一道编译步骤。它把人类世界里格式混乱、结构复杂、版面丰富的文档，转换成机器可以检索、切块、引用、推理和生成的知识结构。

但到了 Agent 时代，解析已经不只是输入输出，而是文档进入工具链、进入检索链、进入推理链的第一层接口。

从这个角度看，MinerU 的价值不在于它是不是某一项单点能力最强，而在于它把复杂文档进入 AI 工作流这件事做得更完整。

如果你正在做文档问答、企业知识库、研究资料解析、合同检索、财报理解，或者任何需要“让大模型真正读懂文档”的事情，MinerU 很值得你认真上手一轮。

很多时候，Agent 的上限，不是由模型本身决定的，而是由它能否稳定获取高质量文档上下文决定的。而 MinerU，恰恰就在这道最容易被低估、却最关键的入口上。

参考资料

• MinerU 开源仓库：github.com/opendatalab…
• MinerU-Ecosystem：github.com/opendatalab…
• MinerU llms.txt：mineru.net/llms.txt
• MinerU API 文档：mineru.net/apiManage/d…
• OmniDocBench：github.com/opendatalab…
• Docling：www.docling.ai/
• LlamaParse：developers.api.llamaindex.ai/cloud/llama…
• Unstructured Partitioning：docs.unstructured.io/concepts/pa…
• PyMuPDF：pymupdf.readthedocs.io/