Build 2026 刚讲完 Agent，我反而重看了一遍 MinerU

王莎莎
0 阅读13分钟

写这篇文章的时间是 2026 年 6 月 4 日。

如果你这两天刷开发者社区，应该很难绕开三个信号：

这几件事放在一起看，其实已经很清楚了：

2026 年开发者圈最热的话题，不再是“哪个模型更强”，而是“怎么把 Agent 真正接进工作流”。

问题也随之变了。

过去我们问的是：

  • 模型会不会写代码
  • 模型能不能总结文档
  • 模型能不能做问答

现在更现实的问题是：

  • Agent 拿到的上下文到底干不干净
  • 工具链能不能让它稳定调用真实世界的数据
  • 一份 PDF、Word、PPT、扫描件，能不能变成 Agent 真能消费的输入

也正因为这个变化，我最近重新看了一遍 MinerU。

不是因为“文档解析”这个方向突然变得性感，而是因为在这波 Agent / MCP / 多工具编排 的热潮里，文档入口这件事，反而成了最容易被忽略、却最影响效果的一层。

1. 这轮 Agent 热潮，真正卡住团队的不是模型，而是上下文

这波 Agent 最大的变化，不是模型突然更聪明了，而是大家都在把它从“会聊天的窗口”变成“会工作的系统”。

从官方表述里已经能看到这个趋势：

  • 微软在 Build 2026 里强调的是 build, operate, optimize and observe，不是单点模型能力，而是完整的 Agent 平台与治理
  • OpenAI 在 6 月 2 日的两篇文章里，已经把 Codex 的使用人群从开发者扩展到了分析师、运营、研究、知识工作者
  • AWS MCP Server GA 的重点也不是“多一个协议”，而是把认证、审计、权限边界和观测能力一起做进来

说白了，行业已经不再满足于“让模型回答一个问题”，而是想让它：

  • 读取真实文件
  • 搜索资料
  • 调用内部系统
  • 返回带出处的结果
  • 在多步工作流里持续执行

这时候，Agent 的表现就不再只取决于模型 推理 ，而更取决于它拿到的上下文质量。

如果上下文是脏的，后面的推理再强也很难救。

这件事在代码场景里不算陌生。我们都知道，给 coding agent 一个脏仓库、坏测试、缺文档，它大概率也写不好。

文档场景也是同一个道理。

给 Agent 一份排版错乱的 PDF、一份公式碎掉的论文、一份表格抽平的财报、一份扫描效果很差的合同，它当然也会答，但那个答案大概率只是“看起来像那么回事”。

所以我越来越认同一个判断：

Agent 时代，最值钱的不是“多一个工具”，而是“把真实世界的数据先整理成工具能吃的样子”。

而文档，恰恰是这件事里最麻烦的一类输入。

2. 为什么文档是 Agent 最难处理的上下文

很多团队第一次做 Agent，都会有一个天然误区：

“文档嘛，不就是 OCR 一下，抽成文本，再丢给模型。”

这个思路在简单场景里勉强成立，但一上真实业务，很快就会露底。

因为文档从来都不只是“文字”。

它往往同时包含：

  • 双栏和跨栏排版
  • 页眉、页脚、页码、脚注
  • 复杂表格
  • 图片、图注、流程图
  • 公式、化学结构、特殊符号
  • 扫描页和原生页混排
  • Word、PPT、Excel、HTML 等不同格式

这类内容如果处理不好，Agent 常见的失败方式大概有几种。

2.1 阅读顺序错了，检索就已经偏了

双栏论文、研报、招股书特别容易出现这个问题。

人类读的时候会自然按版面走，但很多轻量文本抽取工具只会机械按坐标或顺序拼接。于是模型看到的内容，根本不是作者原本的表达顺序。

这时候你做 RAG ：

  • 切块会切错
  • embedding 会带上错位上下文
  • 检索召回会偏
  • 最终回答会“句子都对，但逻辑不对”

2.2 表格一旦被抽平，Agent 就很难再复原

这是财务、法务、医疗、供应链场景里最常见的问题。

模型并不是完全不会理解表格，但前提是你至少得把表格关系保住。

如果文档解析阶段就把：

  • 行列关系打散
  • 合并单元格丢掉
  • 表头错位
  • 跨页表拆裂

那 Agent 后面再怎么问，都只能对着一堆数字猜。

2.3 OCR 不是终点，结构化才是

很多团队会把 OCR 当作文档理解的全部，但对 Agent 来说，OCR 只是第一步。

真正关键的是：

  • 识别完之后怎么恢复文档结构
  • 怎么保留标题层级
  • 怎么处理表格和公式
  • 怎么输出成后续工具链能继续使用的格式

如果最后产出只是一大段连续文本，那它最多只是“看过了”，谈不上“能稳定调用”。

2.4 多格式混合，是生产系统绕不过去的问题

别看网上讨论 Agent 时经常举 PDF 例子，真实系统里，文档源头通常是混合的：

  • PDF
  • DOC/DOCX
  • PPT/PPTX
  • XLS/XLSX
  • 图片
  • 网页

如果一套系统只能处理其中一两类输入，后面你很快就会补一堆胶水层，最后维护成本远超模型本身。

这也是为什么，文档问题不是“模型看不看得懂”，而是“工程上有没有一层文档编译器”。

3. 这个时间点，我为什么会重看 MinerU

如果只把 MinerU 当作“又一个 OCR 工具”，那确实很难理解它为什么值得在今天讨论。

但如果把它放到 Agent / MCP / 可调用工作流 这个背景里看，它的位置就不一样了。

根据 MinerU 官方仓库、llms.txt、API 文档和 MinerU-Ecosystem 的公开资料，它现在更准确的定位应该是：

把复杂文档转换成适合 LLM、RAG、MCP、Agent 工作流使用的 Markdown / JSON。

这个表述很重要。

它意味着 MinerU 关注的不是“识字”本身，而是“文档如何进入下游系统”。

截至我在 2026 年 6 月 4 日 查看的官方公开资料，MinerU 这套体系有几个点是值得认真看的：

  • 支持 PDF、图片、Word、PPT、网页等输入
  • 输出形态面向机器可消费的 Markdown / JSON
  • 既能处理原生文档，也覆盖扫描文档
  • 强调阅读顺序恢复、页眉页脚移除、表格和公式结构保留
  • 生态层已经有 CLI、Python/Go/TypeScript SDK、LangChain Loader、MCP Server
  • MinerU-Ecosystem 明确把“Enable my AI agent to parse documents”当成一类官方场景来支持

这几点拼在一起，才是它今天有讨论价值的原因。

它其实不只是“把文档解析出来”，而是在做一件对 Agent 很关键的事：

把人类文档，提前整理成机器工作流可以直接接住的结构。

这一层如果缺失，很多团队表面上在做 Agent，实际上只是把模型接到了更脏的数据上。

4. 不是所有文档工具，都适合放进 Agent 工作流

为了避免把这篇写成“谁都比不过 MinerU”的广告稿，我更愿意用工程分类的方式来讲。

如果你站在 Agent 工作流的视角看，常见文档处理方案大概可以分成四类。

类型典型工具优点缺点更适合什么场景
纯 OCRTesseract、PaddleOCR 基础识别成熟、便宜、部署简单结构恢复有限，接入 Agent 还要补很多层图片识别、单字段抽取
轻量文本抽取PyMuPDF、pdfplumber、MarkItDown快、依赖少、简单 PDF 很顺手多栏、表格、公式、扫描件容易出问题简单 PDF 转文本
云端解析服务LlamaParse、部分 SaaS Parser接入方便，效果通常比纯抽文本好成本、可控性、格式边界、隐私约束快速 PoC、云端管线
面向 Agent 的复杂文档解析MinerU多格式、结构化输出、可进 MCP / RAG / Agent对简单文档不一定是最低成本方案复杂文档知识流、Agent 工作流

这里我想强调一句很现实的话：

MinerU 不是所有场景都该上。

如果你的输入非常规整：

  • 单栏 PDF
  • 纯文本为主
  • 没有复杂表格和公式
  • 不需要进入 Agent、多步调用、引用和深读

那用轻量工具完全可能更合适。

但如果你的目标变成了：

  • 让 MCP client 直接读文档
  • 让 Agent 从 PDF、Word、PPT 里稳定取上下文
  • 让文档进入 LangChain / LlamaIndex / RAGFlow / Dify
  • 让结构化结果被后续工具反复消费

这时 MinerU 的价值才开始真正出现。

换句话说，它不是“替代 OCR”，而是更像一层面向 Agent 的文档输入层。

5. 两种最实用的接入方式

这部分我只写两种最容易在今天落地的方式，一种给 Agent，一种给 RAG。

5.1 用 MCP，让 Agent 把 MinerU 当原生工具

这是最近最贴近热点的一种方式。

MinerU-Ecosystem 官方仓库已经给出了 MCP Server 方案，典型配置大概是这样：

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

它的意义不在于“又多一个接口”，而在于：

  • 文档解析变成了 Agent 可直接发现和调用的工具
  • 文档输入不再需要手工预处理后再贴给模型
  • 能比较自然地进入 Cursor、Claude Desktop、Windsurf 这类 MCP client 的工作流

如果你最近在折腾 MCP，这个接法其实很顺。

尤其在多格式资料场景里，Agent 不用自己硬啃 PDF，也不用你先手动做一遍“文档转文本”，而是先调用解析工具，再拿结构化结果做后续推理。

5.2 用 LangChain Loader，让文档直接进入检索链路

如果你更偏向 RAG 或知识库工程，那另一条路径是直接用 langchain-mineru。

官方仓库给出的思路很直接：

from langchain_mineru import MinerULoader

loader = MinerULoader(
    source="report.pdf",
    split_pages=True,
    mode="precision"
)

docs = loader.load()

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

这段代码真正重要的不是“能跑起来”，而是后面的 Document 质量更高：

  • 标题层级更接近原文
  • 页面切分更自然
  • 表格和复杂结构更不容易碎
  • metadata 更有机会保留页码、来源、结构信息

对检索系统来说，这意味着你后面的：

  • chunking
  • embedding
  • reranking
  • citation

都更有基础。

这一点在 Agent 场景里尤其重要。因为 Agent 不是只回答一次问题，它通常会：

  1. 先检索
  2. 再读局部
  3. 再决定要不要继续调用别的工具
  4. 最后返回答案和出处

前面的文档结构越稳，后面的链路就越稳。

6. 如果你今天要评估 MinerU，我建议不要只看“识别率”

很多团队评估文档解析时，还是习惯只看 OCR 准不准。

这在 2026 年其实有点不够了。

如果你的目标是给 Agent 用，我更建议按下面这几个维度来评估：

6.1 结构完整性

  • 标题层级是否保留
  • 多栏阅读顺序是否正确
  • 页眉页脚能否有效去噪
  • 图表、段落、列表能否分得开

6.2 机器可消费性

  • 输出是不是稳定的 Markdown / JSON
  • 结构字段是否适合后续程序处理
  • metadata 是否足够支撑页码和引用

6.3 工作流兼容性

  • 能不能直接接进 LangChain / LlamaIndex
  • 能不能通过 MCP 暴露给 Agent
  • 能不能和现有 RAG、知识库、自动化系统接起来

6.4 成本与复杂度

  • 简单文档是否值得用重方案
  • 复杂文档能不能用一套体系覆盖
  • 云端与本地的边界是否清楚

如果只看“识别几个字”，你很可能会低估 MinerU。

但如果把评估目标改成：

这份文档最后能不能稳定地进入 Agent 的检索、推理、调用、归因链路？

那它的价值就会更容易看清。

7. 一个更现实的判断：今天该不该写 MinerU

回到这篇文章开头的问题。

为什么我觉得 2026 年 6 月 4 日 这个节点，适合发一篇关于 MinerU 的深度技术文？

不是因为“文档解析”突然成了最热关键词。

而是因为这几天真正热的是：

  • Agent
  • MCP
  • 工作流编排
  • 知识工作自动化

而这些话题一旦真的往深处走，都会撞到一个现实问题：

上下文从哪里来？

代码上下文可以来自仓库。

业务上下文可以来自数据库、API、CRM、工单系统。

但大量关键知识，仍然躺在：

  • PDF
  • Word
  • PPT
  • 网页
  • 扫描件

这些文档里。

你不把这层打通，Agent 就永远只能在“会调用工具”和“真的拿到可用知识”之间反复打滑。

从这个角度看，今天写 MinerU，不是在蹭文档解析的热点，而是在蹭一个更大的主题：

当大家都在谈 Agent 时，哪些底层基础设施会变得更重要？

我的判断是，文档输入层一定会是其中之一。

而 MinerU，恰好是这个位置上少数已经把：

  • 复杂文档解析
  • 机器可读输出
  • MCP 接入
  • RAG 生态
  • Agent 工作流

这些点串起来的项目。

这也是它今天最值得讨论的地方。

8. 最后一句实话

我现在越来越少相信那种“某个模型、某个 Agent、一夜之间改变一切”的叙事。

真正能把系统跑起来的，往往不是最响亮的概念，而是那些不起眼但必须做对的中间层。

文档解析就是这种中间层。

过去它只是 OCR 工程、知识库预处理、搜索系统前置步骤的一部分。

但到了今天，它开始变成 Agent 真正工作的入口。

所以这篇文章如果只想留一个结论，我会写得很直接：

这轮 Agent 热潮里，很多人高估了模型本身，低估了文档上下文。

而 MinerU 值得重看，恰恰不是因为它“会解析文档”，而是因为它在试图解决一个更现实的问题：

怎么把复杂文档变成 Agent 真能用的输入。

这件事，可能比“再换一个更强的模型”更影响最后的效果。

参考资料

avatar
文章
阅读
粉丝