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

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

• 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 个问题：

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

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

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

• 只是想把 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，越低越好。

这张表至少说明 3 件事：

这里也要实事求是：

这张表里的版本不是完全同步到 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，官方公开的“规模口径”也很重要。

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

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

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

评测文档类型

评测维度

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

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

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

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

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

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

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

这张评分表里，我最想强调的 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/