别再把 PDF 直接塞给 Agent 了：我把 MinerU、Docling、Marker、Unstructured、PaddleOCR、LlamaParse拉到了一张表上

m0_61134850

1385人浏览 · 2026-06-08 10:12:10

m0_61134850 · 2026-06-08 10:12:10 发布

这两周技术圈最热的词，不是某个新模型，而是三个更基础、也更容易做脏的词：

Agent
MCP
Context Engineering

2026 年 6 月 2 日，微软在 Build 2026 里反复强调 context layer 和 Microsoft Agent Platform。
同样是 2026 年 6 月 2 日，OpenAI 发布了 Codex for every role, tool, and workflow，重点已经从“模型会不会生成代码”转向“怎么把工具、流程和工作材料接进来”。
再往前一点，AWS 在 2026 年 5 月 6 日 宣布 AWS MCP Server GA，把“按权限、按协议给 agent 喂上下文”正式做成基础设施。

这几个信号放在一起，其实只说明一件事：

Agent 真正进入生产以后，瓶颈越来越少出在模型本身，越来越多出在上下文质量。

而上下文里最难啃的一块，恰好就是文档。

不是开发者最喜欢的 Markdown，而是这些更常见的现实材料：

双栏论文
扫描合同
带复杂表格的财报
含公式的研究报告
DOCX、PPTX、XLSX
网页导出的复杂 PDF

这类文档最麻烦的点，不是“文字能不能识别出来”，而是它们要真正变成 Agent 可用的上下文，至少得满足这些条件：

阅读顺序不能错
标题层级不能乱
表格最好还是表格
公式不要碎成普通文本
页眉页脚和杂音要尽量去掉
最好还能回到页码、图片和原始结构

所以这篇文章不想再写成“某个 OCR 工具很强”的宣传稿，而是直接把今天最值得放在一起看的 9 类方案拉平：

MinerU
Docling
Marker
Unstructured
PaddleOCR / PP-StructureV3
LlamaParse
Azure Document Intelligence
Google Document AI
Tesseract OCR

我尽量只用官方资料、官方 benchmark 和公开接口来写，重点回答 6 个问题：

这些工具分别在解决哪一层问题
公开 benchmark 和数据量能说明什么
如果从 Agent 工程视角看，应该怎么评测
每个方案最短的上手代码是什么
今天做选型，哪些方案最值得认真看
为什么在 Agent 时代，MinerU 值得被重新评估

一、先别急着排第一，先搞清楚它们根本不是一类东西

很多横评一上来就想排名次，但这几类产品本身就不在同一层。

工具	更像什么	更适合放在哪一层
MinerU	面向 Agent / RAG 的复杂文档上下文层	文档进入工作流的基础设施
Docling	本地可控、结构表达能力强的统一文档表示层	高保真转换和二次处理
Marker	偏 PDF -> Markdown/JSON 的高效转换器	批量 PDF 结构化转换
Unstructured	通用 ingestion / partition 框架	企业数据清洗、元素拆分、路由
PaddleOCR / PP-StructureV3	OCR + layout + table + formula 管线	图像/PDF 识别与版面理解
LlamaParse	云端高保真解析服务	云端 PoC、快速接入、外包解析
Azure Document Intelligence	企业级云文档智能 API	表单、票据、文档版面和字段抽取
Google Document AI	谷歌云文档处理平台	文档理解、分类、拆分、抽取
Tesseract OCR	传统 OCR baseline	本地文本识别、轻量 OCR 基线

这个分类非常关键，因为大多数团队第一次选型都会犯同一个错：

只是想把 PDF 转成文本，却上了一个很重的解析系统
明明要做 Agent 工作流，却还在拿轻量 OCR 工具硬顶
明明需要本地闭环，却一开始就把核心链路绑死在云 API 上

如果你的目标是让 Agent 读文档，真正要比的不只是识别率，而是：

结构表达能力
工具接入能力
本地/云端边界
后续接 RAG 或 MCP 的成本

二、如果只谈能力不谈数据量，很多评测其实没有信息量

文档解析工具很容易被写成“功能盘点”。但对读者真正有吸引力的，往往是两个东西：

公开 benchmark
公开数据量和规模口径

1. OmniDocBench：今天最值得参考的公开 benchmark 之一

OpenDataLab 官方的 OmniDocBench 很适合拿来讨论复杂文档解析，因为它不只看 OCR。

它的数据规模本身就有参考价值：

1651 个 PDF 页面
覆盖 10 类文档类型
覆盖 5 类版面类型
覆盖 5 类语言
有 28 类 block-level 标注
有 4 类 span-level 标注

它评的不只是“识别了多少字”，还包括：

end-to-end
layout detection
table recognition
formula recognition
reading order

这比单纯 OCR 准确率更接近今天做 Agent 的真实需求。

2. PP-StructureV3 官方页里有一张真正值得看的跨工具表

很多 benchmark 只有自家模型对比自家模型，信息量不大。
但 PP-StructureV3 官方页面直接把多种方案拉到了 OmniDocBench 同一口径下。

下表采用 Edit Distance，越低越好。

工具 / 版本	Overall EN	Overall ZH	Text EN	Text ZH	Table EN	Table ZH	Read Order EN	Read Order ZH
PP-StructureV3	0.145	0.206	0.058	0.088	0.159	0.109	0.069	0.091
MinerU-1.3.11	0.166	0.310	0.0826	0.2000	0.1613	0.1833	0.0834	0.2316
Marker-1.2.3	0.336	0.556	0.080	0.315	0.619	0.685	0.114	0.340
Docling-2.14.0	0.589	0.909	0.416	0.987	0.627	0.810	0.313	0.837
Unstructured-0.17.2	0.586	0.716	0.198	0.481	1.000	0.998	0.145	0.387

这张表至少说明 3 件事：

文档解析不是“只看 OCR 准不准”
复杂结构文档里，表格和阅读顺序是非常大的分水岭
MinerU 这类面向结构化输出的方案，在公开基准里确实是第一梯队

这里也要实事求是：

这张表里的版本不是完全同步到 2026 年 6 月 的最新 release。比如 MinerU 仓库首页已经显示 3.2.1 released on 2026-05-28。MinerU README 还提到当前 pipeline backend 在 OmniDocBench v1.5 上拿到了 86.2 的 end-to-end overall 分数，README 后端表里则给出了 OmniDocBench v1.6 的 85+ / 95+ 不同后端口径。

这其实更接近真实世界：

公开 benchmark 很重要，但版本不同步、评测口径不完全一致，本来就是选型的一部分。

3. 再看几组更容易吸引读者的公开规模数据

除了 benchmark，官方公开的“规模口径”也很重要。

工具	官方公开的规模/限制信息	信息来源价值
MinerU Precision Extract API	单文件 `<=200MB`，`<=200 pages`	能直接判断生产 API 适配范围
MinerU Quick Parse / Flash	单文件 `<=10MB`，`<=20 pages`	适合轻试用与即时体验
LlamaParse	`130+ formats`	云端解析广覆盖能力强
Marker	托管平台宣称 `200M+ pages per week`，单机批量模式 `25 pages/second on an H100`	对批处理读者非常抓眼球
Tesseract	官方长期作为通用 OCR baseline，支持多语言 OCR	适合拿来做本地 OCR 基线
Azure Document Intelligence	官方文档给出 `500 MB` 和 `2,000 pages` 的付费层分析上限	适合企业级长文档场景判断

这些数字不是“谁更强”的直接结论，但它们非常适合帮助读者快速建立预期。

三、如果今天真要做一篇评测稿，我会怎么设计任务

只拉几张截图、跑一个 demo，基本写不出靠谱评测。
如果真想让读者觉得“这篇有东西”，我建议至少按下面这套任务设计来组织文章。

评测文档类型

双栏英文论文
含复杂表格的中文财报
扫描版合同或票据
含公式的科研 PDF
DOCX / PPTX / XLSX 混合办公文档

评测维度

文本识别
阅读顺序
表格结构保留
公式完整性
输出格式是否利于 Agent 消费
本地部署难度
接 MCP / RAG / Workflow 的成本
对真实生产流量的承载能力

我最建议写进文章的结论形式

不要写“某工具最好”，更适合写成：

最适合本地闭环的
最适合快速 PoC 的
最适合 OCR 管线强化的
最适合企业云文档处理的
最适合作为 Agent 文档上下文层的

这样的结论对读者更有用，也更可信。

四、工程视角综合评测：如果今天要接进 Agent 工作流，我会怎么打分

下面这张表不是统一实验室跑出来的客观跑分，而是基于官方公开 benchmark、官方文档和公开接口能力做的工程视角综合评分。
我给每项按 1-5 分评估，重点看 6 个角度：

复杂 PDF
扫描件/OCR
本地闭环
Agent/MCP 接入
生态与扩展
上手速度

工具	复杂 PDF	扫描件/OCR	本地闭环	Agent/MCP	生态扩展	上手速度	总分
MinerU	5	5	5	5	5	4	29
PaddleOCR / PP-StructureV3	5	5	4	4	4	3	25
Docling	4	4	5	3	5	4	25
LlamaParse	4	4	1	5	4	5	23
Marker	3	3	5	2	3	5	21
Azure Document Intelligence	4	4	1	3	4	4	20
Google Document AI	4	4	1	3	4	4	20
Unstructured	2	2	5	2	5	4	20
Tesseract OCR	2	2	5	1	2	5	17

这张评分表里，我最想强调的 5 个判断

1. 如果目标是“Agent 能稳定读复杂文档”，MinerU 最值得优先试

因为它不是只在做 OCR，而是在做：

复杂文档结构化
Markdown / JSON 输出
MCP 暴露
LangChain、Dify、RAGFlow、FastGPT 等生态接入

也就是说，它更像是一层 document context infrastructure。

2. 如果你最在意 OCR、layout、table 这条传统识别管线

PaddleOCR / PP-StructureV3 依然非常强，而且官方现在已经给了 MCP server，这点很关键。

它适合两类团队：

本来就有 OCR / CV 研发能力
想把 OCR 这一层做得更深，而不是直接要一整套 Agent 工作流输入层

3. Docling 很强，但更像统一文档表示层，不完全是“拿来就接 Agent”

Docling 的优势在：

文档表达能力强
本地可控
参数颗粒度细
适合平台团队做二次开发

它更像一个精细的文档处理内核，而不是天然替你做完 Agent 工具层。

4. LlamaParse 特别适合 PoC，但你要接受云边界

one API key + one SDK 这种接入成本，确实非常适合快速 demo。
但如果你的需求是：

本地闭环
敏感文档不出网
成本和限额强可控

那它就不一定是最稳的第一选择。

5. Tesseract 和 Unstructured 不应该被简单看低

它们不是“差”，而是解决的问题不一样：

Tesseract 适合做本地 OCR baseline、脚本化抽字、轻量离线工具
Unstructured 适合做多格式 ingestion、元素拆分、统一清洗

但如果你今天的主题是“让 Agent 稳定读复杂文档”，那它们通常不是第一顺位。

五、代码怎么上手：9 个方案最短路径

读者最不爱看空结论，所以这一段我尽量只放“今天能抄”的最短代码。

1. MinerU：本地 CLI

来自 MinerU 官方 README：

uv pip install -U "mineru[all]"

mineru -p <input_path> -o <output_path>

# 纯 CPU 环境可指定 pipeline 后端
mineru -p <input_path> -o <output_path> -b pipeline

MinerU README 当前公开的本地资源口径也很实用：

纯 CPU 支持
最低显存 4GB / 8GB / 2GB 取决于不同后端
最低内存 16GB
磁盘最少 20GB

2. MinerU：Open API / SDK

MinerU-Ecosystem 提供了非常直接的 CLI 和 SDK：

mineru-open-api flash-extract report.pdf
mineru-open-api extract report.pdf -o ./output/
mineru-open-api extract report.pdf -f docx,latex,html -o ./results/

from mineru import MinerU

# flash: no token
client = MinerU()
result = client.flash_extract("https://cdn-mineru.openxlab.org.cn/demo/example.pdf")
print(result.markdown)

# precision: token required
client = MinerU("your-api-token")
result = client.extract("https://cdn-mineru.openxlab.org.cn/demo/example.pdf")
print(result.markdown)
print(result.images)

3. MinerU：MCP

如果今天文章想贴着 MCP 热点，这段配置必须放。

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

如果你想跑成 streamable-http：

MINERU_API_TOKEN=your_key mineru-open-mcp --transport streamable-http --port 8001

公开 MCP tools 也很清晰：

parse_documents
get_ocr_languages
clean_logs

4. Docling：CLI / Python

Docling CLI：

docling myfile.pdf --to md --to json --output ./out

如果你要 VLM pipeline：

docling --pipeline vlm myfile.pdf --to md

Docling 的可调参数很多，比如：

--ocr
--force-ocr
--tables
--table-mode fast|accurate
--device auto|cpu|cuda|mps|xpu

5. Marker：CLI / API server

pip install marker-pdf
marker_single /path/to/file.pdf
marker_single /path/to/file.pdf --output_format json

如果你只想抓表格：

marker_single FILENAME --use_llm --force_layout_block Table --converter_cls marker.converters.table.TableConverter --output_format json

轻量 API server：

pip install -U uvicorn fastapi python-multipart
marker_server --port 8001

6. Unstructured：通用 partition

from unstructured.partition.auto import partition

elements = partition(filename="example-docs/pdf/layout-parser-paper-fast.pdf")
for el in elements[:5]:
    print(type(el), str(el)[:120])

对于 ingestion 场景，这条链路很干净，因为它会自动按文件类型路由到对应 partition function。

7. PaddleOCR：MCP server

PaddleOCR 官方现在已经给了 MCP server 文档。一个最适合演示的配置方式可以写成：

{
  "mcpServers": {
    "paddleocr": {
      "command": "python",
      "args": ["-m", "paddleocr_mcp_server"]
    }
  }
}

这套能力当前官方支持：

OCR
PP-StructureV3
PaddleOCR-VL
PaddleOCR-VL-1.5

而且支持本地模式、官方服务模式和自托管模式。

8. LlamaParse：云端最短路径

from llama_cloud import LlamaCloud

client = LlamaCloud()  # Uses LLAMA_CLOUD_API_KEY env var

file = client.files.create(file="document.pdf", purpose="parse")

result = client.parsing.parse(
    file_id=file.id,
    tier="agentic",
    version="latest",
    expand=["markdown"],
)

print(result.markdown.pages[0].markdown)

9. Azure Document Intelligence：版面分析

from azure.ai.documentintelligence import DocumentIntelligenceClient
from azure.core.credentials import AzureKeyCredential

endpoint = "https://<your-resource>.cognitiveservices.azure.com/"
key = "<your-key>"

client = DocumentIntelligenceClient(
    endpoint=endpoint,
    credential=AzureKeyCredential(key),
)

with open("sample.pdf", "rb") as f:
    poller = client.begin_analyze_document(
        "prebuilt-layout",
        body=f,
        output_content_format="markdown",
    )

result = poller.result()
print(result.content)

这条路径很适合写“企业云 API 怎么最短验证版面抽取”。

10. Google Document AI：云端处理器

from google.cloud import documentai

project_id = "your-project-id"
location = "us"
processor_id = "your-processor-id"

client = documentai.DocumentProcessorServiceClient()
name = client.processor_path(project_id, location, processor_id)

with open("sample.pdf", "rb") as f:
    raw_document = documentai.RawDocument(
        content=f.read(),
        mime_type="application/pdf",
    )

request = documentai.ProcessRequest(name=name, raw_document=raw_document)
result = client.process_document(request=request)
print(result.document.text[:1000])

如果你的文章读者偏企业开发、GCP 用户较多，这段代码很加分。

11. Tesseract：本地 OCR baseline

tesseract sample.png stdout -l eng
tesseract sample.png stdout -l chi_sim+eng
tesseract sample.png output pdf
tesseract sample.png stdout tsv

Tesseract 的优势不在“最懂复杂结构”，而在：

足够轻
足够成熟
足够本地
适合做脚本化 OCR baseline

六、使用指南：今天不同团队该怎么选

如果你写的是技术文章，不要只说“某个工具更好”，更适合直接告诉读者“你属于哪条路线”。

路线 1：我要尽快做出一个能跑的 Agent 文档 Demo

优先顺序：

LlamaParse
MinerU Open API
Azure Document Intelligence

理由：

云端接入快
文档不用自己搭很深的本地栈
适合在短时间内证明价值

路线 2：我要本地闭环，文档尽量不出网

优先顺序：

MinerU
Docling
PaddleOCR / PP-StructureV3

理由：

都能在本地或自托管环境下工作
更适合处理敏感文档
成本和容量边界更可控

路线 3：我要做的是 ingestion，不一定是 Agent 的最终输入层

优先顺序：

Unstructured
Docling
Marker

理由：

更偏元素拆分和统一清洗
更适合先把多格式文档吃进数据管线

路线 4：我只需要 OCR baseline 或轻量抽字

优先顺序：

Tesseract
PaddleOCR
Azure / Google 云 API

理由：

如果只是识字，不一定要一上来就用复杂文档系统

路线 5：我要把文档真正接进 MCP / Agent / Workflow

优先顺序：

MinerU
PaddleOCR MCP
LlamaParse

原因很简单：

这三类方案都在官方层面明确把“给 Agent 用”当成第一等公民，而不是你自己在外面再包一层。

七、为什么这轮 Agent 热点里，MinerU 的位置比很多人想的更靠前

如果只是讨论 OCR，MinerU 并不是唯一主角。
但如果今天讨论的是：

Agent
MCP
Context Engineering
RAG 工作流
本地知识库

那 MinerU 值得被重新看，原因就很明确了。

它不是只在做：

OCR
PDF 转 Markdown
表格抽取

它更像是在做：

把复杂文档变成 Agent 可调用、RAG 可索引、工作流可消费的上下文层。

这点和很多传统文档工具不一样。

很多工具可以把内容“抽出来”，但不一定能自然地进入：

MCP
LangChain
Dify
FastGPT
RAGFlow
多服务、多 GPU、高并发解析系统

而这恰恰是今天更值钱的地方。

所以如果让我用一句话收尾，我会这么写：

这轮热点表面上在聊 Agent，真正更难、也更值钱的，是上下文工程。文档恰好是上下文里最脏的一层。MinerU 值得重新被讨论，不是因为它是又一个 OCR 工具，而是因为它更像一层面向 Agent 时代的文档上下文基础设施。

这件事，确实比“再换一个模型”更影响效果。

参考资料

MinerU README
https://github.com/opendatalab/MinerU/blob/master/README.md
MinerU repository
https://github.com/opendatalab/MinerU/
MinerU-Ecosystem
https://github.com/opendatalab/MinerU-Ecosystem
OmniDocBench
https://github.com/opendatalab/OmniDocBench
Docling docs
https://docling-project.github.io/docling/
Docling CLI reference
https://docling-project.github.io/docling/reference/cli/
Marker README
https://github.com/datalab-to/marker/blob/master/README.md
Unstructured partitioning
https://docs.unstructured.io/open-source/core-functionality/partitioning
PaddleOCR PP-StructureV3
https://www.paddleocr.ai/main/en/version3.x/algorithm/PP-StructureV3/PP-StructureV3.html
PaddleOCR MCP Server
https://www.paddleocr.ai/main/en/version3.x/deployment/mcp_server.html
LlamaParse quickstart
https://developers.llamaindex.ai/llamaparse/
Azure Document Intelligence layout model
https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/layout
Google Document AI
https://cloud.google.com/document-ai/docs
Tesseract OCR
https://github.com/tesseract-ocr/tesseract
OpenAI Codex for every role, tool, and workflow
https://openai.com/index/codex-for-every-role-tool-workflow/
Microsoft Build 2026
https://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/
AWS MCP Server GA
https://aws.amazon.com/blogs/aws/the-aws-mcp-server-is-now-generally-available/

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

让 Agent 说得少做得对：输出压缩与行动优先的提示策略

输出压缩不是简单的缩短输出长度，而是分层输出+权限隔离区块标签可见范围用途输出要求思考层仅Agent系统内部可见，用户完全看不到存储模型的推理过程、工具调用的理由、风险判断逻辑可以完整输出思考过程，不需要精简，用于调试和审计行动层仅Agent系统内部可见，用户完全看不到存储结构化的工具调用指令、参数、优先级必须是符合格式要求的结构化内容，便于系统解析执行结果层仅这个区块的内容会返回给用户存储用户需

AtomGit开源社区

具身智能（Embodied AI）：当 Agent 拥有了物理世界的身体

具身智能是指拥有物理实体（或虚拟具身）的AI Agent，能够通过感知、决策、执行的闭环与物理世界进行交互，在真实环境中自主完成复杂任务，并且在交互过程中持续进化的智能形态。和传统AI、纯数字Agent的核心差异在于：传统AI是“离线智能”，只能处理预先收集的数字数据；纯数字Agent是“虚拟智能”，只能操作数字世界的资源；而具身智能是“落地智能”，能够直接影响和改变物理世界。传统CV/NLP A