从 OCR 到 Context Engineering：用 MinerU 搭一个可复现文档解析评测

今年最火的不是"读 PDF"，而是"让 Agent 可靠地读懂 PDF"

过去我们说文档解析，很多人脑子里想的是 OCR：把图片里的字识别出来就行。

但到了 Agent 和 RAG 的场景，这个标准已经不够了。

一个研究型 Agent 要读论文，它不能只拿到一堆乱序文本；它还要知道标题层级、公式、表格、图注、跨页内容之间的关系。

一个财务 Agent 要读发票和报表，它不能只识别"金额"两个字；它要把表格结构、字段、单位、日期、合计项都抽对。

一个企业知识库要接入几十万份 PDF、Word、PPT 和 Excel，最怕的不是"解析慢一点"，而是解析出来的内容看似完整，实际丢了表格、打乱了阅读顺序，最后把 RAG 检索和回答一起带偏。

这也是为什么 2026 年的文档解析讨论开始明显转向三个关键词：

• Agentic Document Parsing
• MCP / Tool Calling
• Context Engineering

换句话说，文档解析已经不只是"看见文字"，而是"把复杂文档变成模型能稳定使用的上下文"。

今天这篇文章，我用 MinerU 搭一个小型可复现评测，看看一个文档解析工具在 Agent 场景下到底该怎么测。

先说结论

如果你只想要一句话：

MinerU 更适合被理解成"面向大模型和 Agent 工作流的文档解析入口"，而不是传统 OCR 工具。

它的价值不只在于把 PDF 转成 Markdown，而在于：

• 尽量保持阅读顺序
• 保留标题、列表、表格、公式等结构
• 支持 PDF、图片、DOCX、PPTX、XLSX 等主流文档输入
• 通过 CLI / SDK / MCP / LangChain / LlamaIndex 等方式进入 Agent 和 RAG 流程
• 在开源部署、在线 API、桌面客户端之间给不同团队留出选择空间

但也要说清楚边界：

• 复杂扫描件、手写、低清图片仍然需要人工抽样验收
• 图表类内容不应只看 OCR 字符准确率，要看数据和语义是否可用
• API 限制、页数、额度等实时信息，出稿前必须以 live docs 为准
• 不同产品入口的表现可能不同，开源能力不等于 SaaS 页面展示完全一致

为什么这个选题现在值得看

最近文档解析领域有几个很明显的风向。

第一，评测指标变了。新近的 ParseBench 把 Agent 场景下的文档解析拆成表格、图表、内容忠实度、语义格式、视觉 grounding 等维度，而不是只看文本相似度。

第二，MCP 和 Agent 工具生态让"文档解析"变成工具调用链的一环。Agent 不只是聊天，它会读取文件、调用 API、写入知识库、生成表格、发起后续任务。文档解析一旦错了，后面所有自动化都会跟着偏。

第三，RAG 正从"把文档切 chunk"走向更细的上下文工程。AgenticOCR 这类方向提出按需解析和区域级读取，说明大家已经意识到：把整页视觉内容粗暴塞给模型，既贵，也容易引入噪声。

所以今天测 MinerU，不应该只问"识别率多少"，而应该问：

• 结构还在不在？
• 表格还能不能被程序消费？
• 公式有没有变成乱码？
• 多栏论文有没有串行？
• 输出能不能直接进入 RAG / Agent / 知识库？

MinerU 是什么：不是 OCR 单点工具，而是文档解析平台

根据官方仓库当前说明，MinerU 可以把 PDF、图片、DOCX、PPTX、XLSX 等输入转换为 Markdown 和 JSON 等机器可读格式，用于检索、抽取和后续处理。

这句话背后的重点有两个。

第一，它面向的是"下游系统"，不是只给人看。

人看 PDF，靠眼睛可以补上下文；模型看文本，一旦顺序错、表格丢、公式乱，后面的检索和问答都会变差。

第二，它覆盖的是"文档结构"，不是只覆盖文字。

比如一个论文 PDF 里，正文、公式、表格、图片、图注、页眉页脚都混在一起。传统 OCR 可能把它们识别成一段长文本，但 RAG 需要的是更干净、更接近语义结构的结果。

评测设计：别只测 OCR，要测 Agent 能不能用

我建议把文档解析评测拆成 5 个维度。

维度	为什么重要	观察指标
阅读顺序	多栏论文、报告、合同最容易乱	标题和段落是否按人类阅读顺序排列
表格结构	RAG 和数据分析都依赖结构	表头、行列、合并单元格、跨页表格是否保留
公式与符号	科研、金融、工程文档很常见	是否输出 LaTeX，符号是否丢失
噪声清理	页眉、页脚、页码会污染检索	是否去掉重复页眉页脚和无意义文本
Agent 可消费性	输出不是给人复制，而是给工具链用	Markdown / JSON 是否能直接进入切分、检索、抽取

这 5 个指标比"识别了多少字"更贴近现在的热点：Agent 不是要一份看起来像文本的东西，而是要可靠上下文。

评测样本：用 5 类文档覆盖真实工作流

这里给一套最小可复现实验集。

样本	难点	推荐关注
双栏论文 PDF	双栏阅读顺序、公式、图注	标题层级、公式、图注是否跟随正文
扫描合同	OCR、印章、低清文本	关键条款是否完整，页眉页脚是否污染
财务报表 PDF	大表格、跨页、单位	表头、合计项、金额单位
产品介绍 PPTX	幻灯片层级、图文混排	每页标题、要点、图片说明
Excel 台账 XLSX	Sheet、表头、行列结构	表格是否还能被程序二次处理

如果你只想快速跑通，可以先用 3 份文档：

1. 一篇 arXiv 论文
2. 一份带表格的年报或招股书片段
3. 一份内部产品 PPT 或 Excel

快速上手：CLI 跑一个文件

如果你只是想快速看效果，可以先用 MinerU Open API 的 CLI。

# 安装 CLI
curl -fsSL https://cdn-mineru.openxlab.org.cn/open-api-cli/install.sh | sh

# 免 Token 快速解析，适合小文件预览
mineru-open-api flash-extract ./samples/paper.pdf -o ./outputs/paper-flash

# 登录后走精准解析，适合更完整的生产测试
mineru-open-api auth
mineru-open-api extract ./samples/paper.pdf -f md,json,docx,html -o ./outputs/paper-precision

一个合格的解析结果，不是"有一份 Markdown"就结束了。你至少要打开看看：

• Markdown 里的标题顺序是否自然
• 表格是不是表格，而不是散成一堆空格
• 公式是不是能读
• JSON 里是否能找到分块、页码或结构信息
• 是否有大量重复页眉页脚

用 Python 做一个小型自动评测

下面这个脚本不是为了替代专业 benchmark，而是给团队一个低成本检查器。

它会读取 MinerU 产出的 Markdown，粗略计算：

• 标题数量
• Markdown 表格数量
• 公式块数量
• 疑似页眉页脚重复行
• 与人工 gold 文本的关键词召回

from __future__ import annotations

import re
from collections import Counter
from pathlib import Path


def read_text(path: str) -> str:
    return Path(path).read_text(encoding="utf-8", errors="ignore")


def count_markdown_tables(text: str) -> int:
    lines = text.splitlines()
    count = 0
    for i in range(len(lines) - 1):
        if "|" in lines[i] and re.search(r"\|\s*:?-{3,}:?\s*\|", lines[i + 1]):
            count += 1
    return count


def count_formulas(text: str) -> int:
    block_math = len(re.findall(r"\$\$[\s\S]+?\$\$", text))
    inline_math = len(re.findall(r"(?<!\$)\$[^$\n]{2,}\$(?!\$)", text))
    latex_env = len(re.findall(r"\\begin\{(?:equation|align|matrix|cases)\}", text))
    return block_math + inline_math + latex_env


def repeated_noise_lines(text: str, min_repeat: int = 3) -> list[tuple[str, int]]:
    lines = [
        re.sub(r"\s+", " ", line.strip())
        for line in text.splitlines()
        if 6 <= len(line.strip()) <= 80
    ]
    counter = Counter(lines)
    return [(line, n) for line, n in counter.most_common() if n >= min_repeat][:20]


def keyword_recall(text: str, gold_keywords: list[str]) -> float:
    if not gold_keywords:
        return 0.0
    hit = sum(1 for kw in gold_keywords if kw.lower() in text.lower())
    return hit / len(gold_keywords)


def score_markdown(path: str, gold_keywords: list[str]) -> dict:
    text = read_text(path)
    return {
        "chars": len(text),
        "headings": len(re.findall(r"^#{1,6}\s+", text, flags=re.M)),
        "tables": count_markdown_tables(text),
        "formulas": count_formulas(text),
        "noise_lines": len(repeated_noise_lines(text)),
        "keyword_recall": round(keyword_recall(text, gold_keywords), 3),
    }


if __name__ == "__main__":
    gold = [
        "retrieval augmented generation",
        "table",
        "formula",
        "benchmark",
        "document parsing",
    ]
    result = score_markdown("./outputs/paper-precision/result.md", gold)
    for key, value in result.items():
        print(f"{key}: {value}")

这个脚本的重点不是分数本身，而是帮你快速发现三类问题：

• 表格没出来：tables 很低
• 公式没出来：formulas 很低
• 页眉页脚污染：noise_lines 很高

如果你在做公司内部知识库，可以把这个脚本接到 CI 或数据导入流程里。每批文档解析完，先跑质量门禁，再决定是否进入向量库。

示例评测表：应该怎么记录结果

下面是一张建议的记录表。注意，这里是示例模板，不代表官方成绩；你应该替换成自己的样本和实测结果。

文档	MinerU 输出	人工检查重点	结果判定
双栏论文 PDF	Markdown + JSON	双栏顺序、公式、图注	通过 / 待复核
扫描合同	Markdown	OCR、印章、条款完整性	通过 / 待复核
财务报表 PDF	Markdown + HTML 表格	表头、跨页、金额单位	通过 / 待复核
产品 PPTX	Markdown	标题、要点、图片说明	通过 / 待复核
Excel 台账	Markdown / JSON	Sheet 与行列结构	通过 / 待复核

更细一点，可以用 1 到 5 分记录。

维度	1 分	3 分	5 分
阅读顺序	大量串行	个别段落错位	基本符合人工阅读
表格结构	表格散掉	表头/行列部分可用	可直接二次处理
公式符号	大量丢失	主要公式可读	LaTeX / 符号较完整
噪声控制	页眉页脚严重污染	少量重复噪声	基本干净
Agent 可消费性	需要大量清洗	可进入人工半自动流程	可直接进入 RAG / Agent

代码示例：把 MinerU 接进 RAG

解析完成后，下一步通常是进入知识库。

下面是一个最小版流程：用 MinerU SDK 解析文档，再把 Markdown 切成 chunks。

from mineru import MinerU


def split_markdown(md: str, chunk_size: int = 1200, overlap: int = 150) -> list[str]:
    chunks = []
    start = 0
    while start < len(md):
        end = min(start + chunk_size, len(md))
        chunks.append(md[start:end])
        if end == len(md):
            break
        start = max(0, end - overlap)
    return chunks


client = MinerU("YOUR_MINERU_API_TOKEN")

result = client.extract(
    "./samples/report.pdf",
    model="vlm",
    extra_formats=["html"],
)

markdown = result.markdown
chunks = split_markdown(markdown)

print("chunks:", len(chunks))
print(chunks[0][:500])

真实生产里，你还会继续做这些事：

• 保留 source_file
• 保留 page
• 保留标题路径
• 保留表格 HTML 或结构化 JSON
• 给每个 chunk 记录解析模式和解析时间

否则后面排查问答错误时，你会不知道问题来自检索、模型，还是文档解析。

代码示例：用 MCP 让 Agent 直接调用 MinerU

如果你用 Cursor、Claude Desktop、Windsurf 等 MCP 客户端，可以把 MinerU 作为工具接进去。

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

接入后，你就可以在 Agent 里直接说：

帮我解析这份论文，提取方法、实验设置、表格结果，并生成一份 Markdown 摘要。

这就是 MinerU 很适合 Agent 时代的地方：它不是让你手动点一个转换按钮，而是作为工具被 Agent 调用，成为自动化链路的一环。

表格示例：解析结果应该长什么样

以财务报表为例，差的解析结果可能是这样的：

项目 2024 2025 增长率
收入 1000 1380 38%
毛利 420 621 47.9%

人能勉强看懂，但程序很难稳定处理。

更好的输出应该接近 Markdown 表格：

项目	2024	2025	增长率
收入	1000	1380	38.0%
毛利	420	621	47.9%
毛利率	42.0%	45.0%	+3.0pp

为什么这很重要？

因为 Agent 后面可以继续做：

• 计算同比
• 生成图表
• 写经营分析
• 对异常指标追问
• 把数据写入 Excel 或数据库

文档解析如果不能保持结构，Agent 后面看起来再聪明，也是在脏数据上跳舞。

什么场景下，我会优先选 MinerU

场景	推荐入口	原因
快速体验一份文件	在线网页 / Flash API	成本低，适合预览
批量处理企业文档	Precision API / SDK	更适合工程化接入
私有化和离线部署	开源仓库 / Docker	数据不出内网
Agent 工具调用	MCP / Skill	自然语言触发，适合自动化
RAG 知识库	LangChain / LlamaIndex / SDK	输出更容易进入检索链路
Office 文档解析	关注 3.1 后能力	DOCX / PPTX / XLSX 进入主流支持范围

也别神化：上线前必须做抽样验收

我不建议任何团队把文档解析工具当黑盒。

尤其是这些场景：

• 低清扫描件
• 手写批注
• 复杂跨页表格
• 图表数据读取
• 多语言混排
• 法律、金融、医疗等高风险材料

上线前至少做 3 件事：

1. 每类文档抽 20 份人工验收
2. 对表格、金额、日期、公式做单独校验
3. 把解析结果、模型回答、引用来源一起留痕

这样出了问题才能定位：到底是文档解析错了，检索错了，还是大模型回答错了。

最后：Agent 时代的文档解析，正在变成基础设施

过去，文档解析像一个工具：我上传 PDF，你给我文本。

现在，它更像一层基础设施：我有大量非结构化资料，你要把它们变成 Agent 可以调用、RAG 可以检索、业务系统可以消费的上下文。

这就是 MinerU 这类工具值得关注的原因。

它不只是"PDF 转 Markdown"，而是在回答一个更大的问题：

当企业和研究团队的大量知识仍然困在 PDF、PPT、Word、Excel 和扫描件里，Agent 到底怎么可靠地读懂它们？

如果你的团队正在做知识库、科研助手、企业 Agent、自动报告、合同审阅、财务票据处理，文档解析不应该是最后才补的一环。

它应该从第一天就进入技术选型和评测表。

参考资料

• MinerU 官方仓库：https://github.com/opendatalab/MinerU
• MinerU-Ecosystem 官方生态仓库：https://github.com/opendatalab/MinerU-Ecosystem
• MinerU 官方 llms.txt：https://mineru.net/llms.txt
• MinerU API 文档：https://mineru.net/apiManage/docs
• ParseBench: A Document Parsing Benchmark for AI Agents：https://arxiv.org/abs/2604.08538
• AgenticOCR: Parsing Only What You Need for Efficient Retrieval-Augmented Generation：https://arxiv.org/abs/2602.24134
• How are AI agents used? Evidence from 177,000 MCP tools：https://arxiv.org/abs/2603.23802